开发环境组件信息

• nginx proxy
• java1 server
• java2 server
• java3 server
• a Postgres database

其实在一台开发服务器上运行这些服务没什么大不了的，但是对于中小型公司，往往一台高配置开发服务器经常被多人占用，服务吗？少不了对外提供端口，少不了其它人的数据修改；当然这些问题也都是小问题，比如，我服务刚才还跑的好好的，怎么忽然不能用了呢？一顿操作猛如虎.....最后发现系统一个底层依赖被卸载了，这些环境问题，看似简单，其实排查起来非常费劲，因为错误信息大多不在你的认知范围之内，要不然怎么一直有运维都是玄学的说法呢？

另外生产环境已经部署了Kubernetes平台，少不了提供镜像，所以开发环境 docker-compose。

Docker-compose运行一堆Docker容器

Docker Compose允许你在一个名为docker-compose.yml的文件中运行一堆可以相互通信的Docker容器。编排文件如下所示：

version: "3.3"
services:
  db:
    image: postgres
    volumes:
      - ./tmp/db:/var/lib/postgresql/data
    environment:
      POSTGRES_PASSWORD: password
  java_server1:
    image: java1
    volumes:
      - .:/app/
  java_server2:
    image: java2
    volumes:
      - .:/app/
java_server3:
    image: java
    volumes:
      - .:/app/
  web:
    image: nginx
    ports:
      - "8777:80"

• 配置已经包含在镜像里面，有时我可能因为需要临时修改配置，这样的话，我会通过进入到容器或者把容器内部配置挂载到宿主机上修改。

• 其中服务之间交互的部分我通过服务名称调用。

• 通过使用docker-compose，网络配置也变得非常简单，例如我的nginx部分配置如下所示：

location ~ /java1* {
    proxy_pass http://java_server1:8080;
}
location java2 {
    proxy_pass http://java_server2:8081;
}

• 公司太小以至于连个horbour都没有部署，镜像没有存放的位置，那你可以考虑使用数据卷挂载本地文件到镜像内部，而compose本身只是提供了一个编排和启动、以及枚举你所有服务的框架。

启动方式

我一直在通过运行docker-compose build来启动我的容器，然后运行docker-compose up来运行一切。

当然有时可能只改动了其中一个镜像，你也可以通过使用docker-compose create java_server2docker-compose start java_server2单独启动。

yaml文件中可以设置depends_on，以便更好地控制容器何时开始，但是对于我的服务开始顺序并不重要，所以我没有这样做。

测试环境

对于功能测试环境，部署方式跟开发环境并没有什么区别，但是对于测试人员来说，在接入了docker-compose之后变得更爽了；假设我们已经有一套自动化测试脚本，每次上线之前就可以实现在完全独立的环境下进行覆盖测试，测试完成之后直接销毁容器即可。不用考虑数据、环境、配置等影响。特别对于中小型公司，服务不多，发布频繁，并且接入了CI/CD持续集成持续部署的企业，建议采用此种方式。

生产环境

目前为止，我尝试着用docker-compose在生产环境中使用这个东西。虽然我可以容忍它的启动速度慢的问题，但是在使用过程仍然会碰到一些问题，比如：多个容器之间启动的先后顺序导致bug，但是你可以采用https://github.com/vishnubob/wait-for-it脚本，控制一个容器必须在另外一个容器完全启动之后再启动；另外没有调度、保活等功能，改来改去发现还不如使用shell脚本启动。当然如果你只是部署一个小型网站、一些简单的无状态服务，还可以考虑使用docker-compose。对于大量微服务（超过50个以上）还是建议采用Kubernetes。