执行./startFabric.sh无法启动peer0.org1.example.com容器求助

在Ubuntu 16.04.3 LTS + Hyperledger Composer 0.19.1的环境下，启动./startFabric.sh时遇到peer0.org1.example.com容器无法连接CouchDB的问题，这个错误我之前帮很多开发者排查过，本质是peer启动时CouchDB还没完全就绪，或者CouchDB本身启动异常导致的。下面给你几个靠谱的解决办法：

1. 给Peer加个“等待CouchDB就绪”的逻辑 #

默认的启动脚本没考虑到CouchDB启动需要一点时间，peer先起来了自然连不上。你可以修改startFabric.sh，在启动peer容器前加一段循环检测：

打开startFabric.sh，找到启动peer0.org1.example.com的代码段，在前面加上：

# 循环检测CouchDB是否就绪，直到能正常访问
until curl -s http://couchdb:5984/ > /dev/null; do
  echo "Waiting for CouchDB to finish starting up..."
  sleep 2
done

这样peer会等CouchDB完全能响应请求后再启动，就不会出现连接被拒绝的警告了。

2. 先排查CouchDB本身能不能正常启动 #

有时候问题出在CouchDB容器本身，先确认它的状态：

• 执行docker ps -a查看couchdb容器的状态，如果显示Exited，就看它的日志找原因：

docker logs couchdb

常见的坑包括5984端口被其他进程占用，或者CouchDB的配置文件有问题。如果是端口冲突，就去修改Fabric的docker-compose.yml，把CouchDB的端口映射改成比如5985:5984，同时更新peer配置里指向CouchDB的端口。

3. 给Docker Compose加依赖关系，强制先启动CouchDB #

在Fabric的docker-compose.yml（或者对应的配置文件）里，给peer0.org1.example.com的配置块加上depends_on，让Docker先启动CouchDB：

peer0.org1.example.com:
  # 其他配置...
  depends_on:
    - couchdb
  # 其他配置...

不过要注意，depends_on只保证容器启动顺序，不保证服务完全就绪，所以最好和步骤1的等待脚本配合使用，双保险。

4. 清理旧容器镜像，从头构建 #

有时候旧的容器缓存、损坏的镜像会导致各种奇怪问题，彻底清理后重新启动往往能解决：

# 停止并删除所有Fabric相关容器
docker stop $(docker ps -aq)
docker rm $(docker ps -aq)
# 删除Hyperledger相关镜像
docker rmi $(docker images | grep hyperledger | awk '{print $3}')
# 重新启动网络
./startFabric.sh

你之前加dns_search:.的思路是解决DNS解析问题，但从错误日志看，peer已经能解析到CouchDB的IP（172.18.0.4），所以问题不在DNS，而是CouchDB没准备好或者本身启动失败，试试上面的方法应该能解决。

内容的提问来源于stack exchange，提问作者T_murder