Hyperledger Fabric Java Chaincode 可以在没有 docker 的情况下安装和运行吗？

【问题标题】：Can Hyperledger Fabric Java Chaincode installs and runs without docker?Hyperledger Fabric Java Chaincode 可以在没有 docker 的情况下安装和运行吗？
【发布时间】：2021-09-02 17:06:16
【问题描述】：

我正在尝试在 Oracle Linux 8.4 上设置没有 docker 的 Hyperledger Fabric

我正在使用来自 github 版本的 Fabric 2.2.3。
https://github.com/hyperledger/fabric/releases/download/v2.2.3/hyperledger-fabric-linux-amd64-2.2.3.tar.gz

我也试图通过不使用fabric-ca来了解它是如何工作的。

到目前为止，我设法纯粹使用 OpenSSL 和那些 MSP 目录创建了自己的证书层次结构和链...... 有了证书链，我也设法

  • 使用 cryptotxgen 生成创世区块
  • 启动 orderer 并准备好服务
  • 使用 cryptotxgen 创建一个新通道（我将其命名为 orderer-channel）
  • 启动对等体并加入新频道

但是，我一直在链码上遇到问题。
我正在尝试使用两者来安装 Java 链代码
对等生命周期链代码包，对等生命周期链代码安装 VS 对等链代码包，对等链代码安装......没有任何运气
它不断提示我 docker 错误消息（请参阅下面的日志）

如何在没有 docker 的情况下部署我的链代码？ 我试过用 --peer-chaincodedev 启动对等点......但也没有任何运气

从下面的日志中，如果使用链码安装（没有生命周期）它报告安装成功，但在 docker 上失败。

因此，作为我的主题，是否可以在没有 docker 的情况下安装和运行链代码？
到目前为止，我已经在没有 docker 的情况下自行设置和配置，现在在最后一步似乎迫使我使用 docker >__

使用生命周期链码安装来自安装链码的日志：

[user@hyperledgerfabric ~]# /appl/hyperledger-fabric/bin/peer lifecycle chaincode install /appl/chaincode/TestHLF-1.0.0.tar.gz --peerAddresses localhost:7051 -o localhost:7050
Error: chaincode install failed with status: 500 - failed to invoke backing implementation of 'InstallChaincode': could not build chaincode: docker build failed: docker image inspection failed: Get "http://unix.sock/images/testhlf-1.0.0-da9445c8699c299812759f4072a8069875a786f4382b00591b87c1feab4c9599-721fab386a2ac9009bd0e40582127b7895df36b6a1d74dfb108713d1b4751cd5/json": dial unix /var/run/docker.sock: connect: no such file or directory

使用链码安装（无生命周期）安装链码的日志：

[user@hyperledgerfabric ~]# /appl/hyperledger-fabric/bin/peer chaincode install -l java -p /appl/chaincode/TestHLF -n TestHLF -v 1.0.0 --peerAddresses localhost:7051 -o localhost:7050
2021-09-01 17:45:02.804 +08 [chaincodeCmd] checkChaincodeCmdParams -> INFO 001 Using default escc
2021-09-01 17:45:02.804 +08 [chaincodeCmd] checkChaincodeCmdParams -> INFO 002 Using default vscc
Error: install failed with status: 500 - chaincode installed to peer but could not build chaincode: docker build failed: docker image inspection failed: Get "http://unix.sock/images/testhlf-1.0.0-0e6bfac3b09ead9a0bd3e887e68ea728650f7c9e87b335ec6f539517b834ba08/json": dial unix /var/run/docker.sock: connect: no such file or directory

[user@hyperledgerfabric ~]# /appl/hyperledger-fabric/bin/peer chaincode list -C orderer-channel --peerAddresses localhost:7051 --installed
Get installed chaincodes on peer:
Name: TestHLF, Version: 1.0.0, Path: /appl/chaincode/TestHLF, Id: c57c51536a53f01ee95324a2de8a564d9485ecf86c313c7baa9348cd8ec70d96

外部生成器和启动器的更新：

尝试使用 External Builder，但它似乎仍在我的同行中寻找我的 docker。
在 metadata.json 中，变量path，它是干什么用的？

[user@hyperledgerfabric TestHLF]# /appl/hyperledger-fabric/bin/peer lifecycle chaincode install --peerAddresses localhost:7051 /appl/chaincode-builder/TestHLF/TestHLF.tar.gz
Error: chaincode install failed with status: 500 - failed to invoke backing implementation of 'InstallChaincode': could not build chaincode: docker build failed: docker image inspection failed: Get "http://unix.sock/images/testhlf-5cb99feb2a9be27749bfc0f05d93cddaf8b23a9023c3bbc217aebcb703082141-941a0fbcc36e8019c4cd118263ce7a6ba266432dc0a4d7e6b5a07554ba3d1923/json": dial unix /var/run/docker.sock: connect: no such file or directory

我已经更新了我的 peer 中的 core.yaml 以指向外部构建器。

[user@hyperledgerfabric TestHLF]# grep externalBuilder -A3 /appl/blockchain/_config/core.yaml
#    externalBuilders: []
    externalBuilders:
        - path: /appl/chaincode-builder/TestHLF
          name: testhlf-builder

这里是 tar 的内容，以及重要文件的内容。

[user@hyperledgerfabric TestHLF]# tar -tvf /appl/chaincode-builder/TestHLF/TestHLF.tar.gz
-rw-r--r-- fabric/fabric    61 2021-09-02 10:29 metadata.json
-rw-r--r-- fabric/fabric   229 2021-09-02 10:29 code.tar.gz

[user@hyperledgerfabric TestHLF]# tar -tvf /appl/chaincode-builder/TestHLF/code.tar.gz
-rw-r--r-- fabric/fabric   150 2021-09-02 10:29 connection.json

[user@hyperledgerfabric TestHLF]# cat /appl/chaincode-builder/TestHLF/metadata.json
{
  "path": "",
  "type": "external",
  "label": "TestHLF"
}

[user@hyperledgerfabric TestHLF]# cat /appl/chaincode-builder/TestHLF/connection.json
{
  "address": "localhost:9999",
  "dial_timeout": "10s",
  "tls_required": "false",
  "client_auth_required": "false"
}

[user@hyperledgerfabric TestHLF]# ls -l bin
total 12
-rwxr-xr-x. 1 fabric fabric 307 Sep  2 10:42 build
-rwxr-xr-x. 1 fabric fabric 243 Sep  2 10:29 detect
-rwxr-xr-x. 1 fabric fabric 219 Sep  2 10:42 release

External Builder & Launcher 的更新 (2)：

以下是有关检测、构建和发布可执行文件的更多详细信息。
从之前的更新中，可执行文件的权限为 755。
还有用于测试它是否有效的可执行文件，我没有进行检查，只是尝试输出值。
在我看来，它甚至没有调用可执行文件。

[user@hyperledgerfabric bin]# cat build
#!/bin/bash

CHAINCODE_SOURCE_DIR=$1
CHAINCODE_METADATA_DIR=$2
BUILD_OUTPUT_DIR=$3

echo "CHAINCODE_SOURCE_DIR = $CHAINCODE_SOURCE_DIR"
echo "CHAINCODE_METADATA_DIR = $CHAINCODE_METADATA_DIR"
echo "BUILD_OUTPUT_DIR = $BUILD_OUTPUT_DIR"

touch /appl/chaincode-builder/TestHLF/touch02.txt

exit 0




[user@hyperledgerfabric bin]# cat detect
#!/bin/bash

CHAINCODE_SOURCE_DIR=$1
CHAINCODE_METADATA_DIR=$2

echo "CHAINCODE_SOURCE_DIR = $CHAINCODE_SOURCE_DIR"
echo "CHAINCODE_METADATA_DIR = $CHAINCODE_METADATA_DIR"

touch /appl/chaincode-builder/TestHLF/touch01.txt

exit 0




[user@hyperledgerfabric bin]# cat release
#!/bin/bash

BUILD_OUTPUT_DIR=$1
RELEASE_OUTPUT_DIR=$2

echo "BUILD_OUTPUT_DIR = $BUILD_OUTPUT_DIR"
echo "RELEASE_OUTPUT_DIR = $RELEASE_OUTPUT_DIR"

touch /appl/chaincode-builder/TestHLF/touch03.txt

exit 0

External Builder & Launcher 的更新 (3)：

我使用FABRIC_LOGGING_SPEC=debug打开调试模式
这是调试日志，我在调用我的可执行文件时看不到任何日志。

在对等体上调试日志：

Sep 02 17:04:35 hyperledgerfabric peer[1588]: 2021-09-02 17:04:35.254 +08 [lifecycle] InstallChaincode -> DEBU 49d received invocation of InstallChaincode for install package 1f8b08001c9130610003cb4d2d494c492c49d4cb2acecf63a00d300002331313106d68...
Sep 02 17:04:35 hyperledgerfabric peer[1588]: 2021-09-02 17:04:35.254 +08 [ccprovider] MetadataAsTarEntries -> DEBU 49e Created metadata tar
Sep 02 17:04:35 hyperledgerfabric peer[1588]: 2021-09-02 17:04:35.255 +08 [chaincode] handleMessage -> DEBU 49f [a0343dde] Fabric side handling ChaincodeMessage of type: COMPLETED in state ready
Sep 02 17:04:35 hyperledgerfabric peer[1588]: 2021-09-02 17:04:35.255 +08 [chaincode] Notify -> DEBU 4a0 [a0343dde] notifying Txid:a0343ddee86f669b143923992bd36e6b735b39de681dfb8f230c10af3f469410, channelID:
Sep 02 17:04:35 hyperledgerfabric peer[1588]: 2021-09-02 17:04:35.255 +08 [chaincode] Execute -> DEBU 4a1 Exit
Sep 02 17:04:35 hyperledgerfabric peer[1588]: 2021-09-02 17:04:35.255 +08 [endorser] callChaincode -> INFO 4a2 finished chaincode: _lifecycle duration: 1ms channel= txID=a0343dde
Sep 02 17:04:35 hyperledgerfabric peer[1588]: 2021-09-02 17:04:35.255 +08 [comm.grpc.server] 1 -> INFO 4a3 unary call completed grpc.service=protos.Endorser grpc.method=ProcessProposal grpc.peer_address=[::1]:35628 grpc.code=OK grpc.call_duration=1.805332ms
Sep 02 17:04:35 hyperledgerfabric peer[1588]: 2021-09-02 17:04:35.257 +08 [grpc] infof -> DEBU 4a4 transport: loopyWriter.run returning. connection error: desc = "transport is closing"
Sep 02 17:04:35 hyperledgerfabric peer[1588]: 2021-09-02 17:04:35.257 +08 [grpc] infof -> DEBU 4a5 transport: loopyWriter.run returning. connection error: desc = "transport is closing"

调用生命周期链代码安装时的调试日志：

2021-09-02 17:04:35.245 +08 [msp] setupSigningIdentity -> DEBU 01a Signing identity expires at 2041-08-24 07:42:50 +0000 UTC
2021-09-02 17:04:35.246 +08 [msp] GetDefaultSigningIdentity -> DEBU 01b Obtaining default signing identity
2021-09-02 17:04:35.248 +08 [grpc] Infof -> DEBU 01c parsed scheme: ""
2021-09-02 17:04:35.248 +08 [grpc] Infof -> DEBU 01d scheme "" not registered, fallback to default scheme
2021-09-02 17:04:35.248 +08 [grpc] Infof -> DEBU 01e ccResolverWrapper: sending update to cc: {[{localhost:7051  <nil> 0 <nil>}] <nil> <nil>}
2021-09-02 17:04:35.249 +08 [grpc] Infof -> DEBU 01f ClientConn switching balancer to "pick_first"
2021-09-02 17:04:35.249 +08 [grpc] Infof -> DEBU 020 Channel switches to new LB policy "pick_first"
2021-09-02 17:04:35.249 +08 [grpc] Infof -> DEBU 021 Subchannel Connectivity change to CONNECTING
2021-09-02 17:04:35.249 +08 [grpc] Infof -> DEBU 022 Subchannel picks a new address "localhost:7051" to connect
2021-09-02 17:04:35.249 +08 [grpc] UpdateSubConnState -> DEBU 023 pickfirstBalancer: HandleSubConnStateChange: 0xc00040f7f0, {CONNECTING <nil>}
2021-09-02 17:04:35.249 +08 [grpc] Infof -> DEBU 024 Channel Connectivity change to CONNECTING
2021-09-02 17:04:35.251 +08 [grpc] Infof -> DEBU 025 Subchannel Connectivity change to READY
2021-09-02 17:04:35.251 +08 [grpc] UpdateSubConnState -> DEBU 026 pickfirstBalancer: HandleSubConnStateChange: 0xc00040f7f0, {READY <nil>}
2021-09-02 17:04:35.251 +08 [grpc] Infof -> DEBU 027 Channel Connectivity change to READY
2021-09-02 17:04:35.251 +08 [grpc] Infof -> DEBU 028 parsed scheme: ""
2021-09-02 17:04:35.251 +08 [grpc] Infof -> DEBU 029 scheme "" not registered, fallback to default scheme
2021-09-02 17:04:35.251 +08 [grpc] Infof -> DEBU 02a ccResolverWrapper: sending update to cc: {[{localhost:7051  <nil> 0 <nil>}] <nil> <nil>}
2021-09-02 17:04:35.251 +08 [grpc] Infof -> DEBU 02b ClientConn switching balancer to "pick_first"
2021-09-02 17:04:35.251 +08 [grpc] Infof -> DEBU 02c Channel switches to new LB policy "pick_first"
2021-09-02 17:04:35.251 +08 [grpc] Infof -> DEBU 02d Subchannel Connectivity change to CONNECTING
2021-09-02 17:04:35.251 +08 [grpc] Infof -> DEBU 02e Subchannel picks a new address "localhost:7051" to connect
2021-09-02 17:04:35.251 +08 [grpc] UpdateSubConnState -> DEBU 02f pickfirstBalancer: HandleSubConnStateChange: 0xc000283ec0, {CONNECTING <nil>}
2021-09-02 17:04:35.252 +08 [grpc] Infof -> DEBU 030 Channel Connectivity change to CONNECTING
2021-09-02 17:04:35.252 +08 [grpc] Infof -> DEBU 031 Subchannel Connectivity change to READY
2021-09-02 17:04:35.252 +08 [grpc] UpdateSubConnState -> DEBU 032 pickfirstBalancer: HandleSubConnStateChange: 0xc000283ec0, {READY <nil>}
2021-09-02 17:04:35.252 +08 [grpc] Infof -> DEBU 033 Channel Connectivity change to READY
2021-09-02 17:04:35.253 +08 [msp.identity] Sign -> DEBU 034 Sign: plaintext: 0ACB080A6108031A0B08A3A7C2890610...05A36014D00F00005318644000280000
2021-09-02 17:04:35.253 +08 [msp.identity] Sign -> DEBU 035 Sign: digest: 6C40B4067E4B357821801A1314B2D276BCD3E5B60AF86CDD11AC93776F0A0EBE
Error: chaincode install failed with status: 500 - failed to invoke backing implementation of 'InstallChaincode': could not build chaincode: docker build failed: docker image inspection failed: Get "http://unix.sock/images/testhlf-d092ae78b2f02de3ae597e09cfe84543dc97a65588b2f78e2dd0260811963252-84293d54f47de427b969eef63391a9deca67ecff063052fda66e267832490491/json": dial unix /var/run/docker.sock: connect: no such file or directory

【问题讨论】：

    标签： hyperledger-fabric hyperledger hyperledger-chaincode


    【解决方案1】：

    您对 docker 的问题似乎是对等方没有找到它期望启动链码容器的 Docker daemon socket。

    peer 内部的 docker 守护进程位置是通过环境变量配置的：

          - CORE_VM_ENDPOINT=unix:///host/var/run/docker.sock

    它通常通过一个卷从运行对等容器的文件系统映射：

          - /var/run/:/host/var/run/

    因此，如果您的对等节点正在运行 docker daemon Unix 套接字的机器上运行，那么通过查找套接字（并检查其权限）并配置您的对等节点应该很容易解决此问题。

    作为替代方案，您也可以在CORE_VM_ENDPOINT 中配置Docker TCP endpoint，而不是Unix 套接字。

    如果这一切在您的环境中是不可能的（如果您使用某种限制性环境），您始终可以在您的对等设备上启用External Builders and Launchers 并适当地部署您的链代码。这将是对您的问题标题的具体回答：是，通过外部构建器和启动器。但这比适当地配置对 docker 守护进程的访问要复杂。

    您的所有 CA 考虑因素都不会影响您的问题。但是，在您的生产环境中，您应该使用某种 CA...

    【讨论】：

    • 我知道它找不到我的 docker，因为我没有安装任何 docker，因为我的意图是在没有 docker 的情况下运行它。让我尝试使用外部构建器和启动器。将再次更新结果。
    • 我已经更新了我在 External Builder 上的测试，但似乎仍然有同样的问题，它仍在寻找我的 docker。感谢您的下一次指导。
    • 你的外部构建器没有被执行（因为它没有被适当地配置），所以你的对端尝试安装传统的方式。您的core.yamlexternalBuilders 配置必须指向包含合适的build、detect 和release 可执行文件的文件夹（检查它们的权限）。这是一个很好的完整示例（适用于 Go，不适用于 Java）：github.com/hyperledger/fabric-samples/tree/master/…。 A 我已经说过了，这不是一个简单的配置。
    • When an externalBuilder configuration is present, the peer will iterate over the list of builders in the order provided, invoking bin/detect until one completes successfully. If no builder completes detect successfully, the peer will fallback to using the legacy Docker build process implemented within the peer. This means that external builders are completely optional.
    • 我更新了可执行文件的内容：构建、检测和发布，如我的帖子所示，权限为 755，因此这不应该是任何文件权限问题。我也故意没有做任何检查，只是打印始终退出 0 的值。但在我看来，它甚至没有调用我的可执行文件。如何调试调用我的可执行文件的结构？
    猜你喜欢
    • 2023-01-14
    • 2019-02-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2023-01-15
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多
    热门标签
    Java Python linux javascript Mysql C# Docker 算法 前端 SpringBoot Redis Vue spring 设计模式 .net core .net kubernetes c++ 数据库 数据结构 大数据 js 机器学习 微服务 Android Go 程序员 面试 JVM ASP.net core 云原生 人工智能 后端 PHP git CSS golang k8s Nginx Django mybatis 深度学习 多线程 React 架构 devops 爬虫 云计算 Spring Boot LeetCode