Docker 帶著 “Dockerize Everything” 的口號，以“軟件標準”的姿態展現于世人面前，不斷影響大家對于軟件的理解。然而現實是否就如想象中的那么飽滿，新的科技誕生之際，是摧枯拉朽之勢，還是循序漸進，皆有個過程，面對異軍突起的 Docker，軟件傳統的精髓又是何去何從？這些無一不是值得深思的話題。
　　在《存儲類 Docker 容器的明文密碼問題》一文中，我們初步領略了存儲類軟件與 Docker 結合時，存在的些許安全隱患，比如明文密碼問題。
　　過去數十年間，MySQL 數據庫的創建都在人機交互過程中完成，流程大致可以分為以下三個步驟：
　　運維人員創建機器，安裝并配置 MySQL 服務器；
　　DBA 負責管理 MySQL 數據庫，如 MySQL 數據庫的創建、刪除與權限更改等；
　　開發人員使用 DBA 交付的數據庫，對數據庫進行增刪改查等操作。
　　MySQL 歷經了許多年，形成了以上這種交付方式，在 Docker 誕生之前，沒有任何風吹草動。然而，在 Docker 誕生之后，MySQL 的 Docker 化路程似乎并不平坦。
　　常言道，Docker 橫空出世，極大地推動了DevOps的發展。雖然看似 MySQL 與 Docker 的結合并沒有對開發造成直接的影響，但是 Docker 化的 MySQL 的確加速了運維進度，原本冗長的人機交互，以及多方協調，如今一條簡易的docker run命令即可全部完成。無可否認，自動化的程度有了質的飛躍，然而當我們審視自動化流程時，我們也可以從中找到一些隱患——MySQL容器的明文密碼問題。
　　MySQL 容器的明文密碼問題，指的是：Docker 創建 MySQL 容器時，通過環境變量的方式傳遞 MySQL 存儲引擎的密碼，縱使 MySQL 會對密碼進行加密，然而環境變量的存在卻會泄漏密碼信息，因此存在安全隱患。
　　明文密碼解決方案
　　Docker 容器的明文密碼問題，在于控制流程的過于自動化，并且環境變量的方式又無可避免地使用明文記錄了密碼。在一個完整的 MySQL 容器創建過程中，環境變量和 MySQL 引擎密碼始終保持一致，假設我們可以做到用戶為 MySQL 設定的密碼最終可以落實到 MySQL 引擎處，而不存在于任何環境變量中，那就可以說明明文密碼可以解決。換言之，用戶為 MySQL 容器設定的密碼時，可以繞過環境變量。眾所周知，環境變量在 Docker 的世界中是配置環境最常用的方式，連完成容器間通信的docker link命令最終也是通過環境變量來完成。
　　繞過環境變量又是從何說起，首先讓我們分析下圖。
　　
　　上圖中，我們通過 Docker Daemon 創建了兩個 MySQL 容器，容器名分別為 MySQL1 和 MySQL2，并且兩個容器中的 MySQL 引擎的密碼分別為 mysql1 和 mysql2。創建容器時使用的命令分別為：
　　docker run -d -e MYSQL_ROOT_PASSWORD=daocloud --name MySQL1 mysql docker run -d -e MYSQL_ROOT_PASSWORD=docker --name MySQL2 mysql
　　假設一位用戶希望創建一個密碼不會泄漏的 MySQL 容器，密碼為 daocloud。為了彌合明文密碼問題，繞過環境變量，我們可以按照以下三個步驟來完成。
　　1.創建兩個 MySQL 容器 MySQL1 與 MySQL2，MySQL 的 root 密碼分別為 daocloud 與 docker；
　　2.待 MySQL1 啟動完畢，使用docker stop命令停止 MySQL1 容器，并將 MySQL1 容器的 volume1 全部拷貝出來，最終使用docker rm命令刪除 MySQL1 容器；
　　3.待 MySQL2 啟動完畢，使用docker stop命令停止 MySQL2 容器，并將 MySQL2 容器 volume2 內的文件全部刪除，接著將 volume1 的內容拷貝至 volume2 下，最終啟動 MySQL2。
　　通過以上三個步驟，我們直接交付 MySQL2 容器，此時 MySQL2 容器中 MySQL 的 root 密碼為 daocloud，即目標達成。雖然 MySQL2 容器的環境變量 MYSQLROOTPASSWORD 依舊是 docker，但是 MySQL 引擎使用的密文密碼已經轉變為 daocloud，交付完畢的 MySQL2 容器中不存在任何有關字符串 daocloud 的明文信息，同時無需再使用的 MySQL1 容器也被我們刪除。
　　上述流程的執行，可以很巧妙的通過替換volume的方式，完成密文的轉移，同時使得明文環境變量的失效。
　　Docker層與應用層
　　通過實踐，可以驗證解決方案的可行性。不過很多讀者看到這里，不禁會對上述方案產生一些質疑，是否替換 volume 就是一個合理的解決方案。
　　以下的觀點，相信很多人會認為同樣是合理的解決方案。
　　明文密碼固然是一個大問題，然而當 MySQL 容器創建完畢之后，用戶完全有權限通過 mysql-client 等工具登陸 MySQL 引擎，實現 MySQL 引擎 root 密碼的修改，最終的結果是：密碼修改同樣會作用到 volume 中的密文，使得充當明文密碼的 Docker 容器環境變量失效。
　　不可否認，上述觀點同樣具有可行性。仔細分析和對比兩種解決方案，可以看到兩者之間存在一些明顯的差異。
　　最大的差異性，當屬通用性。替換 volume的方式，雖然在容器創建流程中加入了部分額外的操作（比如創建兩個容器、啟動容器、替換 volume等），但是在通用性方面，優勢十分明顯。通用性的體現何在？本文舉例的是 MySQL 容器，其實其他存儲類 Docker 容器如 MongoDB、Redis 等，均可以采用這種方式。
　　換言之，對于存儲類 Docker 容器而言，Docker Daemon 的管理員無需獲知容器內部運行的是何種服務，機械化操作替換volume即可導致明文密碼失效。通過 mysql-client 修改密碼的方式，只能由容器的用戶來完成，而現實情況中， Docker Daemon 管理員與容器用戶很有可能并非同一個人，尤其是在公有云服務上。因此，Docker Daemon 交付出的容器，必須由用戶進行二次加工，才能真正滿足用戶需求，無疑在便捷性方面，無法盡如人意。
　　更為細致的比較，我們就能發現：其實兩者的實現的立足點不同。替換 volume則是從 Docker 層出發；而修改密碼則是站在應用層出發。
　　何為Docker層？Docker 是一款軟件，Docker 的世界中 Docker 鏡像、Docker 容器等，對于容器的管理（比如啟動停止、環境變量的設置等），筆者都認為是 Docker 層的概念。
　　何為應用層？此處的應用層，指的是與用戶鏡像內或者容器內與應用直接相關的內容。
　　依然以 MySQL 為例，通過 MySQL 鏡像啟動 MySQL 容器時，會使用MYSQL_ROOT_PASSWORD這個環境變量。環境變量是一個 Docker 層的概念，原因很簡單，Docker Daemon 會機械化地將所有用戶設置的環境變量作用到容器進程，而不會去關心具體哪個環境變量在容器中充當什么樣的角色。同樣的道理，名為MYSQL_ROOT_PASSWORD的環境變量就是一個應用層的概念，這個具體的環境變量，有可能會被容器內部的應用進程來使用，最終影響容器內部的應用。
　　同樣的道理，volume 是一個 Docker 層的概念，volume 內部的具體內容則是應用層的概念。因此，通過 volume 來操作容器，屬于 Docker 層的操作，不會涉及任何應用層的內容。而通過事先獲知容器內部應用的詳細情況，再針對應用進程做出相應的行為，則屬于應用層的操作。

普通下載普通下載

相關電子資料下載

• 如何在Windows系統上設置Docker鏡像源 55
• 機器學習需要掌握的九種工具盤點 16
• Docker鏡像國內加速的幾種方法 55
• VectorCAST|Docker場景下的代碼白盒測試實施 402
• 如何用Springboot整合Redis 118
• 如何在macOS系統中用Docker運行macOS鏡像呢？ 364
• 什么是Docker容器？為什么需要Docker容器？ 71
• 為什么需要Docker容器？Docker容器和VM有什么區別？ 323
• 如何使用 Docker容器化技術 1188
• Dockerfile定義Docker鏡像的構建過程 1088