上篇中，我們主要介紹了使用docker-compose對Windows Docker單服務器進行遠程管理，編譯和部署鏡像，并且設置容器的自動啟動。但是，還有一些重要的問題沒有解決，這些問題不解決，就完全談不上運維：

問題一：如此部署的應用，在宿主機外部，只能通過宿主機的ip加一個個特定的端口來訪問每個容器內(nèi)的應用，這顯然是不滿足實際需求的。

問題二：相比于將應用直接部署在有UI界面的Windows Server，因為每個應用部署于自己的Windows Docker容器，當應用運行時發(fā)生各種問題時，比如，cpu高，內(nèi)存高，訪問變慢等等，如何才能方便地排查問題呢？即使你愿意一個個容器attach上去，也因為它沒有UI，遠沒有傳統(tǒng)有UI界面的Windows Server上容易。所以，我們必須有必要的工具來更方便的監(jiān)控容器的運行。

下篇

  • 負載均衡和反向代理

  • 日志解析和監(jiān)控

負載均衡和反向代理

要解決問題一：

  • 首先，我們需要一個機制，當用戶訪問我們的ip或域名時，服務器能根據(jù)不同的域名，或者不同的子路徑，在相同的端口比如80或者443，從每個應用容器返回內(nèi)容——這就是反向代理；

  • 接著，我們不希望我們的應用在更新、系統(tǒng)維護、或者局部故障時無法提供服務，所以，每個部署的應用不能是單點，那么，如果同一個應用部署了多個容器實例，如何才能讓他們Serve相同的域名和URL請求呢？——這就是負載均衡；

通常，支持反向代理的組件，往往也同時提供負載均衡功能。例如：F5、nginx、Apache2、HAProxy甚至IIS的ARR等。不同的方案可能側(cè)重點略有不同，我們可以根據(jù)實際情況選擇不同的方案。另外，既然我們的應用部署在Windows Docker服務器，那么最好我們所用的代理組件同樣能部署在Windows Docker容器，這樣我們就能用一致的流程和工具來管理。下面的示例中，我們選擇Apache2，實現(xiàn)一個部署于Windows Docker部署的反向代理加負載均衡器。

為了演示負載均衡，我們新建一個two-instances-demo目錄，其中docker-compose.yml里為iis-demo添加兩個不同內(nèi)部ip的容器實例，再添加一個apache容器，它的Dockerfile定義在apache目錄中。

version: "2.1"services:  apache:    build: .    image: "apache-proxy:1.0"    ports:
    - "80:80"    networks:      nat:
  iis-demo-1: