開發環境組件信息

• 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。