# 第8章 存儲Docker鏡像 如果讀者已經在開發環境或生產環境中使用過Docker就會知道，使用Docker鏡像可以很簡單地完成存儲鏡像的任務。Docker從創建的那天起就有一個中央倉庫可以讓用戶非常方便地存儲鏡像。這個中央模式簡化了鏡像的推送和拉取，同時方便工程師將代碼和服務變得高度可移植。存儲Docker鏡像有3種方式：公共的、私有的、保存/載入。每個選項都有其優缺點，因此選用何種方式取決于所處環境類型、哪個最管用以及公司的安全性要求。 對于開源或公共項目，建議使用公共倉庫。如果需要更高的安全性和更佳的性能，建議使用私有registry。如果需要定制某些東西，可以使用保存/載入。企業還應該考慮所存儲鏡像的數量和大小。在存儲器中鏡像大小通常有幾百兆，因此需要確保在配備新容器時倉庫具有高性能。 在使用Docker拉取或推送鏡像時，除非指定了本地倉庫，否則默認是Docker Hub。例如，以下命令會將鏡像直接推送到Docker Hub上。 `- docker push redis`如果在鏡像名稱之前指定命名空間，就可以重定向到一個內部私有倉庫。例如，如果repo.domain.com托管在內部，以下命令將推送到一個本地倉庫中。 `- docker push repo.domain.com/redis`讓我們來詳細了解一下存儲鏡像的各種方式。 對于開發環境和公共用途而言，存儲Docker鏡像最常見的方法是使用默認倉庫hub.docker.com（Docker Hub）。可以將Docker Hub當作Docker鏡像的GitHub。它提供了一個查看不同類型鏡像的極佳途徑，可以關注、收藏最好鏡像，查看Dockerfile的內容，甚至是查看對該鏡像用途的描述和評論。使用Docker Hub啟動和運行非常簡單。只需要創建一個賬號，就能獲得一個可以立即使用的單一倉庫。完成賬號設置后，就可以通過這個命令將新構建的鏡像推送到Dokcer Hub中。 `- docker push -t newrepository/webimage`從Docker Hub拉取鏡像也非常簡單： `- docker pull newrepository/webimage`在使用公共倉庫時，需要注意幾個安全設置。在使用Docker Hub時，鏡像可以簡單地置為公共或私有狀態。如果在鏡像中存儲了源代碼、安全密鑰或環境細節，那么將鏡像設置為公開狀態應該非常慎重。如果用戶的鏡像包含敏感信息，Docker Hub能通過私有化倉庫為鏡像進行加固（只能通過管理員或協作賬號訪問）。Docker Hub提供了認證服務以保護可以對用戶的倉庫進行修改的人，還可以為用戶的倉庫分配協作者。 如果對Docker Hub背后的技術感興趣，可以看一下Jér?me Petazzoni的\[演講視頻\](http://blog.heavybit. com/blog/2015/3/23/dockermeetup)。 如果剛開始使用Docker，可嘗試一些[官方鏡像](https://registry.hub.docker.com/search?q=library&f=official)。 Docker Hub提供了一個不太出名但卻非常有用的功能，用戶可以使用Docker Hub的服務器自動構建容器鏡像。要設置自動化構建，將Docker Hub倉庫指向一個包含Dockerfile的GitHub、Bitbucket倉庫或倉庫的一個路徑。 一旦設置了自動化構建，每當修改所配置的源代碼時，Docker Hub就會自動化構建新容器鏡像。接著，新構建的容器將被推送到registry中，并被標記為自動構建（automated build）以供下載。 自動化構建有以下優點： - 減少用戶或用戶的基礎設施工作量； - 自動化構建可以使用安全補丁自動更新基礎Docker庫鏡像； - 事件驅動方法（通過Webhooks）——鏡像反映了應用程序代碼的最新版本——對于開源項目這尤其有用。 存儲Docker鏡像的另一個常見方法是使用私有registry。Docker提供了一個開源服務器來存儲鏡像。私有registry讓企業可以安全地將鏡像保存在防火墻和VPN之后，以確保代碼及鏡像倉庫的安全。啟動并運行私有registry也非常簡單。這是一個入門鏈接：http://docs.docker.com/docker-hub-enterprise/install/。 在Docker剛起步時，私有registry就已經是Docker主代碼的一部分。由于Docker registry是其生態系統中極其重要的一部分，他們決定將私有registry抽出來作為獨立產品。Docker自此將代碼移動到自己的分支上，甚至將代碼轉化為可下載的Docker鏡像。在過去一年中，私有registry得到了更好的發展。如果讀者從早期就開始接觸Docker，會發現私有registry已經從原先的非常不穩定變成了現在具有多種改進的穩定狀態。 目前的私有倉庫已經相當穩定，很多公司因為其性能提升和更高的安全要求已經開始使用自有的內部registry。如果你剛剛上手，打算運行自己的私有registry時，應考慮幾個架構決策。需要考慮網絡帶寬、登錄憑證、SSL安全性、監控以及磁盤存儲要求。 私有倉庫有以下優點： - 速度——將倉庫放置在自有網絡內部可加快鏡像的推送與拉取； - 安全性。 企業剛開始使用私有registry時，將其快速安裝在服務器上后就放任不管了，任其運行。很快，企業就意識到鏡像會占用大量存儲空間、消耗大量網絡帶寬，并將遇到很多Docker所使用的不同類型文件系統所帶來的文件系統問題（見4.3節）。如果計劃在自有網絡中運行私有Docker registry，應將其作為最高等級的服務器來對待。 在運行自己的內部私有registry時，建議使用基于網絡的存儲，并對倉庫服務器做負載均衡以達成冗余。讓我們來看一個現實中生產環境的私有倉庫。 這個環境具有一個負載均衡器、兩個設置成自動擴展組中的倉庫Web服務器，并使用S3作為后端存儲。這個環境包含了倉庫中所有526 751個對象。對象由存儲在倉庫中的鏡像及標簽組成。這個環境的總大小是2 678 702 030 780字節，即可使用的存儲空間為2.43 TB。 這個環境能應對的突發網絡流量可以達到1 Gbit/s，不過通常在300 Mbit/s左右。這有采集Web服務器兩周進出的網絡吞吐量的多個鏡像。 擴展私有registry并不難，不過要長期持續使用Docker，應考慮好存儲及網絡吞吐量。希望讀者在實現自己的環境時，能從本書中得到一些與環境相關指標的靈感。讓我們來探索一些更深的領域。 閱讀Docker提供的[管理員手冊](http://docs.docker.com/docker-hub-enterprise/adminguide/)或[部署手冊](https://docs.docker.com/registry/deploying/)也大有裨益。 我們看到運行私有registry的大部分公司都使用S3來存儲自己的鏡像。Docker Hub也使用S3來存儲鏡像。其最大的優勢在于其幾乎無限的存儲以及管理的簡易性。如果使用的是AWS基礎設施，其速度也將非常快，因為流量將通過本地路由到S3服務上。因為這個配置的持久性存儲器是S3，這使得用戶的私有倉庫服務器保持不變，也可以對registry的Web部分進行自動擴展和負載均衡。在配置私有registry的設置時，可以使用S3存儲驅動程序。 本地存儲是運行私有registry的另一個常用方法。如果用戶更傾向這個選項或沒有亞馬遜賬號，可以將registry文件存儲在本地掛載點上，不過我們建議使用基于NFS或NAS的掛載點，以便在持續存儲新鏡像時能擴展讀、寫及容量。使用基于網絡的存儲也允許用戶對registry的Web部分進行擴展。容量要求可能很快就會失控，因此應確保做相應計劃。 由于網絡帶寬的要求，單一的Docker倉庫服務器可能逐漸不滿足要求。Docker非常聰明，決定在私有registry中提供一個可插拔的存儲驅動程序架構。可以在一個基于網絡的可擴展文件存儲器（如S3）中存儲鏡像，因此可以對倉庫的Web部分做負載均衡。企業可以將registry鏡像放置在用戶選定的負載均衡器之后。將倉庫放置在Web負載均衡器之后，可以輕松地擴展網絡帶寬，并減少單一倉庫服務器失敗帶來的單點故障。 隨著時間推移，用戶可能不再需要使用舊的鏡像及標簽。目前Docker倉庫還沒有自動清除的功能，因此可操作的最佳實踐是，定期清理不再使用的標簽和鏡像。鏡像或標簽的刪除無法通過[Docker API](https://docs.docker.com/registry/spec/api/)進行（截至1.6版本），因此需要使用SSH登錄到機器上，然后通過Docker CLI命令清除舊的鏡像。 還需要注意的是，Docker registry是個非常活躍的項目，因此需要留意其升級和新功能。請查閱最新文檔以使用正確的方法升級Docker倉庫。 Docker私有registry的網絡加固很簡單，因為用戶只需開放5000端口。不過，由于registry是個標準的Web服務器，將其重新配置到80或443端口上很容易。建議遵循公司的最佳實踐來配置防火墻，阻止非必需端口的訪問。 用戶可以使用SSL證書來保護鏡像，使其免于受到中間人攻擊。使用SSL證書加固registry傳輸有多種方法。用戶可以使用內置的Nginx服務器、配置TLS，或將證書部署在負載均衡器上。例如，如果用戶使用AWS，可以在彈性負載均衡器（ELB）上配置SSL證書，然后以http的方式傳輸到registry的Web服務器上。在Docker registry上安裝SSL證書十分簡單。這個鏈接可以帶讀者入門：https://docs.docker. com/registry/deploying/。 認證對于保護registry非常重要，可防止非法或不安全的鏡像被上傳。它同樣可保護源代碼的知識產權或鏡像所提供的信息。對于高保密性環境，這是需要考慮的一個重要因素。目前私有registry提供了兩種認證方式：silly和令牌（tohen）。[\[1\]](part0014.xhtml#anchor81) 基于令牌的認證方式是唯一可供選擇的安全選項。它是一個具有高度安全性的成熟范例，目前有很多公司正在使用。silly認證正如其名所暗示的那樣不安全。它只在HTTP請求中檢查是否存在Authorization頭。如果未提供頭信息，它依然需要認證。 存儲鏡像還有另外一種方法，使用Docker在1.0版本之前就已經實現的保存/載入功能。因為早期私有registry不穩定，有些公司采用了[Dogestry](https://github.com/dogestry)模式并一直使用它。如今，這是移動鏡像時最不受歡迎的方法，不過如果它適合用戶的環境，當然也是可以使用的。用戶可以通過Docker的內置命令使用其保存/載入功能。例如，可以這么做： - `docker build redis` - `docker save redis > /tmp/redis_docker_save.tar` - 將鏡像復制到遠程服務器中（或在本地使用） - `docker load < /tmp/redis_docker_save.tar` 通過使用`save/load`命令，用戶可以擁有足夠的靈活度。可以將鏡像保存為一個tar包，并上傳到倉庫或網絡共享中，以便集中使用。需要注意的是，用戶可以使用Docker的`export`命令。它跟`save`相比有輕微區別。`export`命令會合并鏡像，這意味著將丟失歷史和元數據。它可以將鏡像體積變得更小。在移動鏡像使用保存/載入方法時，應牢記這一點。 由于用于構建鏡像的依賴項不同，Docker鏡像體積可能會變得很大。例如，用戶使用Ubuntu作為基礎鏡像，然后使用apt-get更新了任何一些庫文件，同時安裝了一個軟件包，如nginx。apt-get將安裝一堆容器構建完成后不需要的緩存庫文件和依賴項。一個通用模式是刪除這些緩存文件和庫以盡量減小鏡像。如果用戶發現自己需要最小化Docker鏡像，那可以使用一個名為[docker-squash](https://github.com/jwilder/docker-squash)的優秀社區項目。以下是如何使用它的一個簡單示例。 `- docker save <鏡像id> | sudo docker-squash -t newtag | docker load`我們對mesosphere/marathon里的一個公共鏡像運行docker-squash，可以將其大小縮小11%。拉取下來的鏡像初始大小是831.7 MB。在對該鏡像運行docker-squash后，我們創建了一個大小是736.2 MB的新鏡像。隨著時間的累加空間性能逐步提升，同時節省了網絡寬帶，這將改善倉庫的存儲和性能。 如果想了解更多關于鏡像壓縮的信息，推薦看一下這篇博客文章：https://blog.jtlebi.fr/2015/04/25/how-i-shrunk-a-docker-image-by-98-8-featuring-fanotify/。 隨著Docker生態系統的不斷成長，在探索運行Docker的新環境時，讀者應留意一下其他的鏡像倉庫： - [Artifactory](https://www.jfrog.com/confluence/display/RTF/Docker+Repositories)； - [Quay](http://quay.io)； - 由New Relic更新的[Dogestry](https://github.com/dogestry)； - [Google容器倉庫](http://googlecloudplatform.blogspot.ca/2015/01/secure-hosting-of-private-Docker-repositories-in-Google-Cloud-Platform.html)； - Azure上的[Docker](http://azure.microsoft.com/blog/2014/10/15/new-windows-server-containers-and-azure-support-for-docker/)。 在第9章中，我們將講述如何結合Docker鏡像使用CI/CD系統。 - - - - - - [\[1\]](part0014.xhtml#ac81) 在2.1.0版本中增加了htpasswd認證方式。——譯者注