原文地址：https://medium.com/@devfire/how-to-become-a-devops-engineer-in-six-months-or-less-part-4-package-47677ca2f058
原文作者：Igor Kantor
翻譯君：CODING 戴維奧普斯
前情提要
在這個系列的第一篇文章中，我們詳細地介紹了 DevOps 相關的文化和基礎技能；在第二篇文章中，我們進入 DevOps 中各個模塊並大致指明瞭如何爲代碼部署搭建基礎；在第三篇文章中，我們討論瞭如何合理的整理已經部署的代碼；本篇文章中，我們將討論如何打包代碼以便於後續部署和執行。
現在我們已經來到了 DevOps 週期中關於代碼打包的環節。
注意：你可以看到每個部件如何構建在前一部分上，併爲後續部分奠定基礎，這一點很重要。
因爲無論你是在與現在還是將來的僱主交談，你都必須能夠清楚地表達出 DevOps 是什麼以及它爲何如此重要。而這就需要你通過講述一個連貫的故事來達成——這個故事講述瞭如何最好地、快速有效地將代碼從開發人員的筆記本電腦發送到能賺錢的生產環境部署。
這也就是爲什麼我們不僅僅是在學習一些比較流行的 DevOps 工具。我們是在學習一整套被當前商業環境所需求的 DevOps 的理念和技術，以及在他們背後支持着的技術工具。
然後請記住，其實每個部分都需要將近一個多月的學習，一整套內容學習下來應該需要將近六個月的時間。
在虛擬化出現之前
還記得那些物理服務器麼？就是必須等待幾周才能發貨，數據中心收到，放在機架上，再花時間搞網絡、安裝操作系統和修補的那些？
沒錯，他們先來的。
舉個例子，擁有居住地的唯一方法是建造一座全新的房子。需要一個住的地方？想想蓋個房子需要多久吧！雖然這個主意不錯，是因爲至少每個人都有房子了，而不是因爲建房子需要很長時間。在這個類比中，物理服務器就像一個房子。
不久人們就對這些事情花了太長時間而感到惱火，於是一些牛人就提出了虛擬化的想法：在一臺物理機器上運行一堆僞裝的“假機器”，讓每臺假機器都像一臺真機。這樣如果你想要一棟房子，你可以建立自己的房子並等待六週；或者你可以直接住到公寓樓裏與其他租戶分享資源。這個想法也許不是完美的但已經足夠，最重要的是開箱即用。
這種情況持續了一段時間，相關公司（像 VMware）也因此收割了很多利益。
直到又有人認爲將一堆虛擬機填充到物理機器中還不夠好：我們需要將更多進程更緊湊地打包到更少的資源中。
就像你覺得，房子太貴了，公寓也太貴了。如果只想暫時租一個房間怎麼辦？還想要那種能隨時搬進搬出的。
於是 Docker 出現了。
Docker 的誕生
Docker 是一個新的東西，但其實 Docker 的理念很早就出現了。在 2000 年的時候，有一個叫 FreeBSD 的系統就提出過相似的概念。當時和現在的想法是隔離同一操作系統中的各個進程，即所謂的“操作系統級虛擬化”。
這在實踐中意味着什麼？
實際上，這意味着 Docker 的受歡迎程度急劇提升巧妙地映射了微服務的興起——一種將軟件分解爲許多單獨組件的軟件工程方法。
而這些組件需要一個家。單獨部署獨立的 Java 應用程序或二進制可執行文件是十分痛苦的：管理 Java 應用程序的方式與管理 C++ 應用程序的方式不同，這與你管理 Golang 應用程序的方式不同。然而 Docker 能提供單一管理界面，允許軟件工程師以一致的方式打包，部署和運行各種應用程序。
對於那個時候來說，這是具有跨時代意義的。
Docker 的優勢
進程隔離
Docker 允許每個服務都具有完全的進程隔離。服務 A 存在於自己的小容器中，具有所有依賴關係；服務 B 存在於其容器中，具有所有依賴性。而且兩者完全不會衝突。
此外，如果一個容器崩潰，只有該容器受到影響，其餘的容器（應該！）仍然能繼續愉快地跑着。這也有利於安全，如果容器被泄露，那麼離開該容器並破解基本操作系統是非常困難的（但並非不可能！）。
最後，如果容器行爲不當（消耗太多 CPU 或內存），則可以僅將爆炸半徑“壓縮”到該容器內，而不會影響系統的其餘部分。
部署
想想在實踐中各種不同的應用是怎麼搭建的。
如果它是一個 Python 的應用程序，它將有各種 Python 包。一些將被作爲 pip 模塊安裝，另一些是 rpm 或 deb 軟件包，其他的則是簡單的 git clone 安裝。或者如果使用 virtualenv，它將是 virtualenv 目錄中所有依賴項的 zip 文件。
另外，如果它是一個 Java 應用程序，它將具有一個 gradle 構建，並將其所有依賴項拉到適當的位置。
所以將各種使用不同語言和不同運行方式的應用程序，部署到生產環境進行構建將是一項重大挑戰。
這樣我們該如何確保各個獨立進程的安全呢？
更有甚者，如果出現衝突就會變得更加麻煩。比如一個服務需要 Python 依賴庫 v1，而另一個服務是基於 Python 依賴庫 v2 的，因爲 v1 和 v2 不能同時在同一臺機器上安裝，問題就產生了。
這時候，就需要 Docker。
Docker 不僅允許完全進程隔離，還允許完全依賴性隔離，在同一個操作系統上並排運行多個容器是完全可能和常見的，每個容器都可有自己的衝突的依賴庫和包。
運行管理
同樣，我們管理不同應用程序的方式因應用程序而異。Java 代碼的日誌記錄不同，啓動方式不同，監視方式與 Python 不同，而 Python 與 Golang 也不同等等。
通過 Docker，我們獲得了一個統一的管理界面，允許我們啓動，監控，集中日誌，停止和重啓許多不同類型的應用程序。這是一個巨大的勝利，並大大降低了運行生產系統的運維開銷。
說了這麼多 Docker 的好處，也是時候說說 Docker 的侷限性了。
進入 Lambda 時代
首先，運行 Docker 仍在運行服務器。服務器很脆弱，必須對它們進行管理，修補和其他方面的保護。
其次，Docker 並非 100％ 安全，至少不像虛擬機那樣。大公司在虛擬機內部運行託管容器而不是在裸機之上，這樣做是有原因的——他們想要容器的快速啓動時間和虛擬機的安全性。
第三，沒有人真正按原樣運行 Docker。相反，它幾乎總是作爲複雜的容器編排結構的一部分進行部署，例如 Kubernetes，ECS，docker-swarm 或 Nomad。這些是相當複雜的平臺，需要專職人員來操作。
但是，如果我是開發人員，我只想編寫代碼並讓其他人管運行的事，Docker，Kubernetes 和其他繁瑣的東西都不是簡單的東西——所以我真的需要學麼？這就要具體問題具體分析了。
對於那些只想讓其他人幫忙運行其代碼的人來說，AWS Lambda（以及其他類似的解決方案）就是答案：
AWS Lambda 允許你在不配置或管理服務器的情況下運行代碼。只需爲你消耗的計算時間付費——當代碼未運行時不收取任何費用。
如果你聽說過“serverless”，這就是它！不再需要運行的服務器或要管理的容器，只需編寫代碼，將其打包成 zip 文件，上傳到亞馬遜並讓他們處理那些煩人的問題。
此外，由於 Lambda 是瞬時的，沒有什麼可以破解的，所以 Lambda 在設計上也是非常安全。
這樣看來像 Lambda 這類的 serverless 功能真的挺不錯的，但是即使這樣，也是有缺點的。
第一，就現階段而言，Lambda 暫時不支持長時間的進程。
其次，Lambda 是功能即服務（Functions-as-a-Service），這意味着你的應用必須完全分解爲微服務的形式，並與其他複雜的 PaaS 服務（如 AWS Step Functions）協調。並非每個企業都處於或者能轉變成這種水平的微服務架構。
第三，對 Lambda 進行故障排除是很困難的。作爲雲原生的應用，所有的 bug 修復都需要在亞馬遜生態系統中修復，這通常挺煩人的且不直觀。
簡單來說魚和熊掌不能兼得，要根據自己的實際情況進行選擇。
總結
Docker 和 Lambda 是時下最流行的雲原生對應用進行包裝、運行和管理的方式。它們通常是互補的，適用於不同的用例和應用場景。
無論如何，現代 DevOps 工程師必須精通兩者。因此，學習 Docker 和 Lambda 是很好的短期和中期的成長目標。
到目前爲止，在我們的系列中，我們已經處理了初級到中級 DevOps 相關主題。在後續章節中，我們將開始討論更適合中級到高級 DevOps 工程師的技術。但是，與往常一樣，沒有捷徑可循，需要一步一步腳踏實地！
譯後記
CODING 近期正式推出了 CODING 2.0 致力於幫助大型企業和項目以最低的成本和精力推動 DevOps 轉型，同時也上線了製品庫和全新的持續集成功能，爲企業搭建 DevOps 的核心樞紐。有效解決研發團隊解決應用管理管理粗獷和版本追蹤混亂的問題。在 CODING 2.0 的 DevOps 自動化流水線當中，持續集成的構建物自動存入製品庫中，在部署時按需獲取對應的版本，製品庫讓研發團隊真正做到 deploy anytime anywhere。
同時，CODING 也會持續關注並分享軟件研發領域最新理念與技術，與 DevOps 工程師一起成長。