first-network工程在github上的fabric-sample下比较齐全的流程。
fabric-sample下载地址:https://github.com/hyperledger/fabric-samples
我将围绕这些文件解析一遍。包括一些常见问题,错误,总结起来。
docker-compose文件一些配置请查看上一章docker的网址进行学习,这里不再赘述。
该文件就是启动docker的所有节点的配置文件。
启动所有节点的命令
docker-compose -f docker-compose-cli.yaml up -d
疑问1:启动网络为什么是叫net_byfn?是docker-compose-cli.yaml的network吗?
我们通过docker查询网络列表
docker network list
答案:不是的。是在base/peer-base.yaml的environment下:
- CORE_VM_DOCKER_HOSTCONFIG_NETWORKMODE
=${COMPOSE_PROJECT_NAME}_byfn进行配置
疑问2:欸,那请问疑问1中 COMPOSE_PROJECT_NAME
又在哪里出现的?
这时候我们使用linux的ll
命令,查看当前目录的所有文件,在下图中可以看到两个隐藏文件。
.env*
文件内容如下图:
这时就知道网络名称是怎么设置的了。
注意: 在first-network中的网络名称设置是net_byfn。而如果不在全局.env*
设置,则以当前目录的文件名作为前缀。而后缀呢,根据docker-compose设置的network变量来进行设置,docker-compose默认不写则以default为后缀,因为在docker-compose-cli设置了network的名称为byfn,所以在- CORE_VM_DOCKER_HOSTCONFIG_NETWORKMODE
必须也是byfn 。不然网络相互不匹配,就会报错。【下图做一个示例】
疑问3:docker-compose-cli.yaml文件里的network与volumes的意思是什么?
volumes
就是卷标,就是将docker容器的数据存储,docker持久化的数据。
疑问4:紧接着解释下volume又是怎么命名?
扩展知识点:
在first-network中是有进行卷存储操作也就是图中的
【Creating volume “net_orderer.example.com” with default driver】卷操作主要的原因是为了保护本地文件不被攻击,并且它的完整性,卷操作可以随意操作,不影响本地文件。
讲解下volumes: docker-compose中有两种方式可以设置volumes,并且都是可持久化的。
查看所有卷标:
docker volume ls
docker volume inspect net_orderer.example.com[卷名称]
进入对应的路径:(查看卷文件):
--volumes
:删除卷
--remove-orphans
:移除未在compose文件中定义的容器
docker-compose -f [docker-compose文件名称] down --volumes --remove-orphans
具体的参数详细解释去docker.io官网查看文档
这时我们将卷进行注释,就会报错。如下图:
该错误翻译过来可以看出该volumes没有定义,我们在看回docker-compose-cli.yaml下的services中orderer.example.com
继承父类的base/docker-compose-base.yaml,这看下该文件
那么做个实验:(如下图,将orderer.example.com改成orderer1.example.com)
而/var/hyperledger/production/orderer
就是卷标的路径了。
疑问6:tty是什么??stdin_open又是干什么用的??
网上是说为了解决【docker-compose启动容器秒退】这种情况
那么,又是为什么会导致这种原因出现?
打个比方假设现在在cli下没有tty
与stdin_open
这两个字段
然后执行docker-compose up -d
-------->也就是在后台启动网络(如下图结果如下)
会发现容器是有启动过的,但关闭了(我有过启动程序然后容器是启动过某个节点,docker ps找不到,docker ps -a 找到,而且显示前几秒刚刚自动关闭,我也不知道当时是怎么回事,没解决掉)
(网址:https://tsov.net/uupee/24667/ )
通过查找资料
原因:docker 容器的生命周期是同容器中的前置进程相关在一起的,这也是我们平时可能会遇到一些容器只是运行几秒便自动退出的原因:因为容器中没有一个常驻的前置进程,前置进程运行结束后,容器便自动退出了。那怎样可以让容器不自动退出呢?比如我们想登入一个纯净的 OS容器 alpine/centos/ubuntu 之类的,在其基础上安装一些服务组件,然后在 commit 成自己的镜像。看网上有不少方法是创建容器时执行一个 while(true) 的死循环(当然,sleep 一下)或者用 tail -f /dev/null 一类的,反正就是以开启一个可以常驻的前置进程为目的。其实我们可以更优雅的使用 docker 容器的 interactive 和 tty 参数来将 sh/bash (*nix 系统必有)命令作为前置命令开启常驻运行,如此容器便不会自动退出了。
所以需要添加tty=true与stdin_open=true
一些难找到的docker-compose指令如下图。(比较好的)
疑问7:sys_channel(系统通道)是什么?
首先我们先看一下byfn.sh文件它也没有涉及到sys_channel这个问题?流程怎么走的 (不细讲,后续在讲)
上图我们可以知道在创建区块时指定了该通道。
疑问8:那么最大的问题就是为什么创建区块用的sys_channel而tx文件却是channel_name(也就是自定义通道)?
那么我将byfn.sh文件的初始区块的-channelID $SYS_CHANNEL改成 $CHANNEL_NAME会怎么样呢?
当然结果肯定是报错了。(如下图)
这里就有关于fabric通道的知识点。
解释fabric通道的知识网址:https://blog.csdn.net/taifei/article/details/82966851
我大概自己解释下:
实际上通道是有两个的(系统通道与应用通道)
排序节点(orderer)通过系统通道来管理应用通道,用户的交易信息通过应用通道传递。对一般用户来说,通道是指应用通道。
而本质上在configtxgen.yaml上profile是有配置的(系统通道与应用通道)(如下图)
我们在进一步验证: 再将genesis.block文件转化成json格式查看一下。
转换代码:
configtxgen -inspectBlock channel-artifacts/genesis.block > genesis.block.json
或者还有另一种方案
先启动configtxlator
工具,再curl -X POST --data-binary @要转的文件路径 configtxlatode服务器的地址:端口/protolator/decode/common.Block > 名称.json 【以下代码为例子】
configtxlator start
curl -X POST --data-binary @jiuxi-channel.block https://127.0.0.1:7059/protolator/decode/common.Block > jiuxi-channel.json
上图是之前没有改之前截图的,所以还是byfn.sh配置下的系统通道名称也就是byfn_sys_channel
那如果genesis.block不写 -channelD 呢?
这就证明结论是对的了。
疑问9:关于/var/run/docker.sock参数是什么?
详细解析:https://blog.csdn.net/boling_cavalry/article/details/92846483
补充:什么是unix socket?
unix socket可以让一个程序通过类似处理一个文件的方式和另一个程序通信,这是一种进程间通信的方式(IPC)。
当你在host上安装并且启动好docker,docker daemon 会自动创建一个socket文件并且保存在/var/run/docker.sock目录下。docker daemon监听着socket中即将到来的链接请求(可以通过-H unix:///var/run/docker.sock设定docker daemon监听的socket文件,-H参数还可以设定监听tcp:port或者其它的unix socket),当一个链接请求到来时,它会使用标准IO来读写数据。
还有- CORE_VM_ENDPOINT=unix:///host/var/run/docker.sock
三个/代表什么?(有时候老忘…QAQ)----->前两个就是类似https://www…的两个下划线,后面一个指文件路径/host/var/run/docker.sock
疑问10:为什么first-network执行完orderer容器能执行orderer命令(工具),而peer命令不行?反之peer只能执行peer,orderer不能执行?
这里就要涉及到images,就以first-network为例子
Orderer下的镜像是hyperledger/fabric-orderer
Peer下的镜像是hyperledger/fabric-peer
CLi下的镜像是hyperledger/fabric-tools
如果orderer是peer镜像呢?peer是orderer镜像呢?(当时就是好奇换一下会怎么样QAQ) 执行结果如下图:
Orderer容器:
Peer容器:
说明容器能不能执行命令与镜像有关!
到这里就讲完docker-compose-cli.yaml文件与涉及到的知识,本人才大二这方面学的不多QAQ,如果有讲错,请一定要在留言框回复我,有很多也是猜想,比较简单的也敢于猜想与证明。这些就是我关于docker-compose-cli.yaml遇到的所有疑问。
第零章:区块链-Hyperledger-Fabric-技术栈: https://blog.csdn.net/qq_44423523/article/details/107409075
第二章:区块链-fabric-sample/first-network之crypto-config.yaml
正在持续更新…