[譯] 一個 “小白” 眼中的容器
作者 | Aleksei Pushkin
譯者 | 無明
容器的非正統使用方法
容器的誕生改變了部署和託管 Web 應用程式的方式。在開始閱讀 Docker 入門指南之前，我就已知曉，但除此之外，我一無所知。直到開始使用容器之後，我才意識到這個容器的潛力所在，它遠比使用虛擬機器來託管 REST API 要強大得多。讓我們來談談容器如何讓你的生活變得更美好，即使你已經發誓永遠不會將你寶貴的寵物應用程式部署在除裸機之外的任何環境中。以下是我在過去六個月中發現的一些不那麼正統的容器使用方法。
將容器作為構建 / 部署伺服器
我的容器之旅就是從這裡開始的。
我喜歡 DevOps。在我職業生涯的某個階段，我遇見了 TeamCity 和 Octopus Deploy，這個充滿活力的組合讓我感受到了 CI/CD 的閃亮魔力。我是我們團隊中唯一一個願意花時間寫指令碼、維護開發伺服器和搭建新環境的人，這些工作對我來說非常有趣。唯一讓我抓狂的是我們的基礎設施是一堆物理伺服器和 Azure VM，而我通常沒有它們的訪問許可權。
不久前，我參與了一個 100％的雲原生新專案。我們達成的第一個共識是採用基礎設施即程式碼模式，並儘可能實現 CI/CD 的最佳實踐。我們都不想被公司內部網路的界限所束縛，於是決定所有的 Ops 技術也應該是基於雲的“XX 即服務”，這樣我們就可以隨時隨訪問 Docker、Git 和 NPM 儲存庫。於是我捲起袖子，開始尋找構建伺服器的最佳方案，這個時候我的腦子裡冒出了一個惱人的想法：“我該如何在沒有伺服器的情況下構建出一個構建伺服器”？我最擔心的是，如果無法線上建立理想的環境，我將無法控制局面，構建、交付和稽核工件的方式也將受到限制。有那麼一刻，我陷入了黑暗之中。
但我並沒有驚慌失措。首先，我知道我們需要一個基於雲的版本控制系統，儘管我對 GitLab 青睞有加，但經過討論，我們還是決定使用 Atlassian 的 Bitbucket（出於技術之外的一些原因）。我知道 GitLab 和 GitHub 都提供了 CI/CD 方面的產品，於是我看了一下 Bitbucket，然後發現了一個叫作 Bitbucket 管道的東西。
管道的概念是這樣的：你提供一系列命令以及說明為什麼以及何時執行這些命令的規則——這些就是所謂的管道。一個管道可能包含從構建和執行單元測試到生產環境部署和驗證部署的一系列操作。管道中包含的是 bash shell 命令，這些命令將在 Docker 容器中執行。過程如下：
這是我第一次學會如何在現實生活中使用容器。我個人認為，這種能夠在雲端擁有按需構建和部署的伺服器的想法是非常強大的，而且我覺得沒有什麼理由不將它應用於所有的雲部署。對我來說，這種方法的主要優點如下：
-
如果你使用 Dockerfile 建立映象，就可以輕鬆跟蹤 CI/CD 基礎設施的變更。由於已經採用基礎設施即程式碼，你可以將它們提交到版本控制系統中，這樣就可以更容易地找到錯誤，精確定位改進的部分，並將知識分享給團隊成員。
-
修改 Dockerfile 檔案比修改虛擬機器要容易得多。
-
不需要維護物理基礎設施，我想這是一個很明顯的優勢。
-
成本效益。在 Bitbucket 高階訂閱和工件儲存上花些錢是合情合理的，因為這樣就不需要花錢在硬體、許可費用上，Dev/Ops 也不需要花時間將這些東西連線起來，並在發生故障時修復故障。
雖然我只提到了 Atlassian 的管道，但還有其他產品可選擇，例如 Jenkins 或 GitLab CI。Bitbucket 的入門級賬戶是免費的，但如果因為某些原因你不喜歡 Atlassian，可以嘗試競爭對手的產品，但我相信這些產品都大同小異。
將容器作為開發工作區
大多數開發人員的機器上都安裝了很多開發工具。有時候我們甚至會忘了之前已經裝過同樣的工具，直到再次安裝時被告知要安裝的版本與已安裝的版本產生衝突。更糟糕的是，當我們升級或更換機器後，需要再次安裝所有的工具。大多數情況下，我們不停在尋找需要用到的工具、庫和外掛，而且有時候我們會陷入試錯的泥潭。比如：“裝上這個，裝上那個，看看可不可以成功構建專案。哦，不行！還缺了什麼？啊，為什麼我不乾脆包塊偏遠的瓜田做個農民？！”
當公司不斷有新開發人員加入時，這將變成一個更大的問題。他們都要經歷這個繁瑣的過程，實在是太浪費時間了。如果我們能夠在彈指揮手間快速配置和分發封裝好的開發工作區，一切都會變得更加容易。使用容器就可以搞定這一切。但是，一篇博文不足以完整地涵蓋這個主題，所以請參看 YouTube 視訊：https://youtu.be/vE1iDPx6-Ok。它差不多兩個小時，但完全值得一看。
我給這個過程畫了一張有意思的插圖。
當然，這個概念並不適合所有人。你可能需要在將哪些東西保留在機器上和使用容器執行哪些東西之間找到折衷。但不要忘了，軟體開發就是要不斷地尋找折衷方案！
將容器作為“隔離的工作區模組”
我必須承認，儘管我計劃實現一個類似於視訊中描述的解決方案，但還沒有這麼去做。一方面是因為我有點懶，一方面是因為沒有新開發人員需要我這麼去做。不過沒關係，最重要的是，它已經成為我靈感的源泉。
我現在仍然沒有一個包含了所有工具和基礎設施的 Docker 映象。不過，我還是建立了一系列包含 AWS CLI、無伺服器等內容的映象，因為我不想將這些東西直接安裝到我的機器上。我還將我的應用程式依賴的各種伺服器都放進容器中，例如 PostrgreSQL、Redis、ES 等。
儘管這種方式不如上一節中提到的完全自動化解決方案那樣高效，但它仍然有一些明顯的好處：
-
更乾淨的系統——容器中的應用程式都被隔離在當前容器內，不會給宿主系統帶來任何副作用。
-
因為我的容器使用相同的命令執行，可以執行在帶有 Linux/Unix shell 的任何機器上，所以還是具備了一定的可移植性。
-
自動化的潛力。我可以建立一些 shell 指令碼將不同的容器捆綁在一起。例如，只用一個命令就可以啟動和停止 Redis 伺服器、MySql 伺服器和 Koa 應用程式。
-
使用管道映象在本地構建專案，這樣就可以確保在本地和在“構建伺服器”上構建工件的方式是完全相同的。我還可以為 Docker 映象新增標籤，並對它們進行版本化，以確保每次構建程式碼的某個版本時都能獲得相同的結果。
-
能夠測試新的東西或有風險的東西。關於 IT 衛生（hygiene），有兩則有意思的軼事。首先是一個關於俄羅斯系統管理員的故事。這個管理員非常偏執，一定要在一個特殊的虛擬機器中開啟所有的電子郵件附件。另一個是兩年前我看到的一個推文。一位博主（也是一名安全研究員）釋出了一個 shell 指令碼，並聲稱這個指令碼可以播放一些令人咂舌的 ASCII 動畫，但實際上是將殭屍網路客戶端下載到受害者的機器上。在幾天的時間內，這個人就擁有了數萬個殭屍網路客戶端。好在這只是一次練習，旨在向人們展示來自網路的隨機程式碼有多危險。所以我的觀點是，雖然我們可能不像那個俄羅斯系統管理員那樣偏執和謹慎，但仍然可以使用隔離容器來試驗新事物——無論它們帶有多大的潛在風險。
我不得不說，我很遺憾沒有及早學習有關 Docker 的基礎知識，而是直接開始以這種方式使用容器——比如我的宿主系統中的獨立工作區。但這絕對可以幫我更好地組織我的工作區，最重要的是，它幫我節省了很多時間。
下面是我用來構建包含無伺服器框架、Newman、localstack 和 AWS CLI 的映象的 Dockerfile 檔案示例，我用它在本地執行無伺服器專案。最後一行是 shell 命令，用於在互動模式下執行這個映象的容器例項（假設映象叫作“my-dev-image-yo”）。
FROM amazonlinux:latest RUN curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.33.8/install.sh | bash RUN export NVM_DIR="$HOME/.nvm" && [ -s "$NVM_DIR/nvm.sh" ] \ && \. "$NVM_DIR/nvm.sh" && [ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion" \ && nvm install v6.10.0 \ && npm install serverless -g \ && npm install newman -g \ && npm install serverless-localstack -g # Installing pip RUN yum install -y python-pip RUN yum install -y python-setuptools RUN easy_install-2.6 pip RUN pip install awscli-local RUN echo "All done" # Run with docker run --rm -v /git:/git -it my-dev-image-yo
結論
如果你一直在問自己是否應該開始花費寶貴的時間來學習容器，我的答案是“是”。你絕對應該這麼做。如果你的公司堅持使用 COBOL 和基於 Teletype 的系統，你掌握的 Docker 技能仍然能夠派上用場。
Docker 的官方入門指南是一個很好的著手點，不過也不要忘了上面提到的視訊。 Docker 現在擁有龐大且不斷增長的社群，所以，如果你通過谷歌搜尋“如何在 Docker 容器中執行 XX”，搜尋結果一定不會讓你失望。
英文原文：https://itnext.io/containers-as-i-didnt-know-them-67cd4eaf3739
活動推薦
微服務架構提倡將單一應用程式劃分成一組小的服務，服務之間互相協調、互相配合，為使用者提供最終價值。企業轉型微服務，有哪些技術需要調整？業界有哪些最佳實踐？大企業在實踐微服務中如何成長？
InfoQ 主辦的第四屆 CNUTCon 全球運維技術大會，邀請了 Twitter、RIOT Games、BAT 等國內外一線專家，分享智慧時代下運維的新趨勢、新思路、新技術和實戰經驗，包括探討微服務的應用場景、企業整合架構的演進以及微服務轉型思路和技術決策考慮等內容。
目前，大會 8 折限時優惠，立減 720 元，團購更優惠！掃描下方二維碼或點選閱讀原文了解，有任何問題歡迎諮詢 Joy 小同學，電話：13269078023（微信同號）。
