摘要 Fabric 网络启动的过程中需要进行大量配置，新学时对各个配置的作用一无所知，这导致我曾在网络出问题时先对配置文件的内容进行排列组合后再祈祷它能在

前言 在实验Hyperledger Fabric无排序组织以Raft协议启动多个Orderer服务、TLS组织运行维护Orderer服务中，我们

在实验 Hyperledger Fabric无排序组织以Raft协议启动多个Orderer服务、多组织共同运行维护Orderer服务 中，我们已经完成了让普通组织运行维护 Orderer 服务，但是最后发现由于运行排序服务的组织需要较为开放的访问策略，可能会降低组织的安全性，所以本实验将尝试使用提供 TLS-CA 服务的 council 组织运行维护 Raft 协议的三个 orderer 节点。本文将在之前的实验基础上，启动一个没有 orderer 组织的 Fabric ，其中由 council 组织提供排序服务，其余三个组织维护着各自的 peer 节点，最后成功在其上部署运行链码。

在Hyperledger Fabric无系统通道启动及通道的创建和删除中，我们已经完成了以无系统通道的方式启动 Hyperledger Fabric 网络，并将链码安装到指定通道。但目前为止，实验中的 orderer 服务都是通过单独的排序组织来维护且只有一个，那能不能不要排序组织而使用普通组织来运行维护多个 orderer 服务呢？当然是可以的，本文将在之前的实验基础上，启动一个没有 orderer 组织的 Fabric 网络，网络中包含三个组织且每个组织运行维护着一个 orderer 节点，最后成功在其上部署运行链码。

在 Hyperledger Fabric组织的动态添加和删除 中，我们已经完成了在运行着的网络中动态添加和删除组织，但目前为止，我们启动 orderer 节点的方式都是通过系统通道的方式，这样自带系统通道的网络很不简洁优雅。好在 Fabric 2.3 以上就开始支持无系统通道创建应用通道的功能，本文将对此功能进行详细解释和介绍，然后通过无系统通道的方式启动联盟链网络并在此基础上完成通道的添加和删除。

在 Hyperledger Fabric组织的动态添加和删除 中，我们已经完成了在运行着的网络中动态添加和删除组织。本文将在其基础上，详细介绍了如何在 soft 组织上添加新的 peer2 节点，并在简要概述了删除节点的方法，本实验必要的准备工作和 DNS 配置请参考准备工作

在 Fabric定制联盟链网络工程实践 中，我们虚拟了一个工作室的联盟链网络需求，并根据此需求分析了整个网络的架构且已经完成了一个简单 fabric 网络的搭建。本文将在其基础上，在 mychannel 通道上添加新的 hard 组织，并在之后删除 soft 组织，本实验必要的准备工作和 DNS 配置请参考 准备工作。

总体来看，网络上成体系的可用的 Fabric 教程极少——不是直接在 Fabric 官网复制内容大谈基础理论就是在描述一个几乎无法复现的项目实践，以至于学习 Fabric 的效率极低，印象最深刻的就是我曾经花费几天时间尝试按照官方教程 CA Deployment steps 搭建自己的 CA 服务，却始终无法成功也找不到原因。因此，为了提高生产效率，本系列虚拟了一个工作室联盟链需求并将逐步实现，致力于提供一个易理解、可复现的工程项目，其中工程部署配置的各个环节都清晰可见，并且可以通过流程脚本能够快速复现在任何一台主机上。

在基于Debian搭建Hyperledger Fabric 2.4开发环境及运行简单案例中，我们已经完成了Fabric 2.4的环境搭建及fabric-samples/test-network官方案例的运行。毫无疑问test-network是一个优秀的入门项目，让我们仅仅通过几行命令就能搭建起常用的Fabric联盟链网络，但是其过度的封装反而不利于我们了解掌握其中各个操作的真实过程。为了进一步掌握Fabric，本文根据test-network中的几个Bash脚本源码，从启动流程、创建通道、部署链码等多个入口函数着手详细分析了脚本执行过程，对未来定制自己的Fabric网络提供参考。本文分析源码主要包含启动默认网络、启动CA网络、创建通道、部署链码四个方面，每节分为官方调用和过程详解：官方调用是使用官方Bash脚本实现对应功能、过程详解是该脚本的实际实现流程，根据过程详解中的代码能够搭建出完全可用的网络。

在最近某次更新博客时，突然觉得每次写完文章再登陆服务器将代码pull到服务器本地部署的过程好傻(尽管总共也花不了1分钟时间)，但作为一个表面的IT工作者怎么能忍受每次都进行这种重复工作呢，就想着有没有一种方法能够像之前Netlify那样push完就自动更新部署的方式。回忆起之前知乎划水时瞥见的CI/CD工具貌似能满足要求，于是在对比了几十种相关工具后，最终Drone以其开源、简易赢得了我的青睐，然后花了大概1-2天的时间入门、整理完成了本博客的自动化部署。