Hyperledger fabric 为什么每个endoser对等机都运行带有nodejs链码的ccenv容器

我们知道链码安装在每个endoser对等机上，并且只在一个endoser对等机上实例化

1, so other peer will copy dev* image of chaincode and run it when needed?

另外，我发现，当使用composer部署/升级链码时，每个endoser对等机都会运行一个ccenv docker容器

2, just the ccenv to build the chaincode, why not just use one peer to build the image and copy to other peer?
3, the ccenv build the chaincode, will be included in install step or the instantiate step for more clear instruction?

---

因为我发现有太多的ccenv同时运行，通常其中一个会失败。

Fabric是一个分布式系统，因此期望对等点作为独立组件运行，而不是在同一台机器上的同一docker网络中。例如，这不是一个有效的部署场景，只是一个开发场景。这就是为什么每个对等方都需要构建和运行其链码容器的实例，您不能让一个对等方构建链码，因为其他处于其自己环境中的对等方将无法访问它

Hyperledger Composer将向通道上的所有对等方发送实例化请求，以便所有这些对等方在实例化时都将构建链码版本，以便可以运行实例化事务模拟

---

ccenv是包含构建链码所需组件的容器映像，它不用于运行链码。

我了解了ccenv的用法。因此，如何理解这一点？链码在一个通道中仅实例化一次。1，在编写器情况下，这是否意味着链码在一个通道中多次实例化？2、链码在对等机的一个通道中仅实例化一次，当另一个对等机尝试运行dev*链码docker时会发生什么？它只是复制实例化的链码docker，并对其重命名？您似乎将实例化与对等方能够认可事务模拟的过程混淆了。这些是不同的事情。实例化是将链码绑定到通道ie，说明通道将在指定版本使用此链码包。只做一次。实例化过程需要运行事务模拟。对于要签署事务的对等方，它必须运行该版本的链码，因此它创建链码映像并启动链码生成器，并在实例化期间向通道上的每个对等方发送txn，因此，每个对等方都需要模拟该事务，因此必须构建并启动作为实例化一部分定义的版本的链码容器，以执行txn模拟。这是composer中的预期行为，无法更改。如果您想要更多的控制，那么不应该使用composer。事实上，你现在真的应该离开composer了谢谢，是的，我被composer中的升级命令弄糊涂了。现在，我正试图摆脱composer，因为它已经被弃用了。我记不起我是否向您指出了这一点，但如果没有，您可能会发现这对从composer进行移植很有帮助