[譯]如何在六個月或更短的時間內成爲 DevOps 工程師，第四部分：打包

• 原文地址：How To Become a DevOps Engineer In Six Months or Less, Part 4: Package
• 原文做者：Igor Kantor
• 譯文出自：掘金翻譯計劃
• 本文永久連接：github.com/xitu/gold-m…
• 譯者：Raoul1996
• 校對者：7Ethan

如何在六個月或更短的時間內成爲 DevOps 工程師，第四部分：打包

「Packages」 由 chuttersnap 拍攝並發表在 Unsplash 上

快速回顧

在第 1 部分，咱們聊了聊 DevOps 的文化和所須要的基礎：

• [譯] 如何在六個月或更短的時間內成爲 DevOps 工程師（系列文章第一篇）

在第 2 部分，咱們討論瞭如何爲部署未來的代碼奠基基礎：

• [譯] 如何在六個月或更短的時間內成爲 DevOps 工程師，第二部分：配置

在第 3 部分，咱們探討了如何組織部署代碼：

• [譯] 如何在六個月或更短的時間內成爲 DevOps 工程師，第三部分：版本控制

這個部分，咱們將說一說怎麼打包你的代碼以便於部署和後續執行。

做爲參考，這裏是咱們的旅程：

打包

注意：你能夠看到每一部分如何前一部分之上，併爲後續部分奠基基礎。這很重要而且是有目的的。

緣由是，不管你與如今的老闆仍是之後的老闆交談，你都得能清楚表達出什麼是 DevOps 而且爲什麼它這麼重要。

你經過講述一個連貫的故事來作到這一點 —— 這個故事講述瞭如何既好又快地把代碼從開發者的筆記本電腦上發送到能賺錢的生產環境（prod）部署。

所以，咱們正在學習的並非一堆割裂的、時髦的 DevOps 工具，咱們正在學習的是是一系列受業務需求驅動，由技術工具支持的技能。

好了，嗶嗶夠了，讓咱們開始吧！

虛擬化入門

還記得物理服務器嗎？你必須等待幾周才能得到 PO 批准，發貨，數據中心接收，上架，聯網，安裝操做系統以及打補丁。

是的，那些都是之前的方式。

設想一下，假如得到住所的惟一方式是建造一座全新的房子。當咱們須要一個住的地方的時候，那不是要等很長時間麼？有點意思。然而每一個人都有房子，但也不是真的由於建造房子須要很長時間。在這個類比中，物理服務器就像一個房子。

而後人們對花了這麼長的時間去作這堆事情感到惱火，有些很是聰明的人提出了 虛擬化 的想法：如何在一臺單獨的物理機上運行一堆假裝的「機器」，並讓每臺假機器假裝成一臺真機。天才！

因此，若是你真的想要一套房子，你能夠建造你本身的並等待 6 周。或者你能夠住在公寓樓裏和其餘租戶共享資源。或許不是很棒可是足夠好了。可是更重要的是，不須要等待！

這種狀況持續了一段時間，而且 VMWare 公司在這方面擁有了霸主地位。

直到其餘聰明的人認爲將一堆虛擬機填充到物理機還不夠好：咱們須要壓縮更多的程序以更緊湊的方式打包到更少的資源中。

在這一點上，房子太貴了，公寓也太貴了。若是咱們只須要暫時租用一間屋子呢？這太棒了，我能夠隨時出入！

因而，Docker 應運而生。

Docker 的誕生

Dokcer 是新的可是 Docker 背後的思想是很古老的。一個叫 FreeBSD 的系統有一個 jails 的概念，其可回溯到 2000 年！誠然一切新的都是舊的。

當時和如今的想法都是在同一個操做系統中隔離單個進程，即所謂的「操做系統級虛擬化」。

注意：這和「徹底虛擬化」不一樣，後者是在同一物理主機上並行運行虛擬機。

這實際上意味着什麼？

實際上，這意味着 Docker 的興起巧妙地反映着微服務的興起 —— 一種軟件工程的方法，其中軟件被分解成多個獨立的組件。

而且這些組件須要一個家。單獨部署他們，部署獨立的 Java 應用程序或者二進制可執行文件很是痛苦：你管理 Java 應用程序的方式和管理 C++ 應用程序的方式不一樣，這和管理 Golang 應用程序的方式也是不一樣的。

相反，Docker 提供單一的管理界面，讓軟件工程師以一致的方式打包（！）、部署、運行各類各樣的應用程序。

這是一個里程碑！

OK，咱們一塊兒來聊聊 Docker 更多的好處。

Docker 的好處

進程隔離

Docker 容許每一個服務有徹底的進程隔離。服務 A 和本身全部的依賴一塊兒存在於本身的小容器之中，服務 B 也和本身的依賴存在於本身的容器中，並且兩者沒有衝突！

此外，若是一個容器掛了，只有該容器會被影響。其他的（應該）將會繼續愉快地運行着。

這對於安全的好處也是顯而易見的。若是容器被泄露，那麼離開容器並破解宿主系統是很是困難的（並不是不可能！）。

最後，若是容器發生了故障（佔用了太多的 CPU 或者內存），則能夠僅僅將爆炸半徑」包含「到該容器，而不會影響系統其它部分。

部署

想一想實際上如何構建不一樣的應用程序。

若是它是一個 Python 應用程序，它會有各類各樣的 Python 包。一些做爲 pip 模塊安裝，另外一些是 rpm 或者 deb 包，其它則是簡單的 git clone 安裝。或者使用 virtualenv，它將是 virtualenv 目錄中全部的 zip 文件。

另外一方面，若是它是一個 Java 應用程序，他將用 gradle 構建，其全部依賴關係被拉取並放到適當的位置。

你抓住了關鍵點。在將這些應用程序部署到 prod 環境中時，各類應用程序，使用不一樣語言和不一樣運行時（runtime）構建都是一項挑戰。

咱們怎麼樣才能保持全部的依賴關係都知足呢？

另外，若是存在衝突，問題會更加嚴重。若是服務 A 依賴於 Python 庫 v1，可是服務 B 依賴 Python 庫 v2 怎麼辦？如今存在衝突，由於 v1 和 v2 不能再同一臺機器上共存。

選擇 Docker。

Docker 不只容許徹底進程隔離，還容許徹底的依賴隔離。在同一個操做系統上並排運行多個容器是徹底可行並常見的，每一個容器都有本身衝突着的庫和包。

運行時管理

一樣，咱們管理不一樣應用程序的方式因應用程序而異。Java 代碼的日誌記錄方式不一樣，啓動方式不一樣，監控方式和 Python 不一樣，Python 和 GoLang 等也不一樣。

經過 Docker，咱們獲得了一個統一的管理界面，容許咱們啓動、監控、收集日誌、中止和重啓多種不一樣類型的應用程序。

這是一個里程碑，並大大下降了運行生產系統的運營開銷。

選擇 Lambda

伴隨着 Docker 的偉大，它也有缺點。

首先，Docker 仍在運行服務器上。服務器很脆弱，必須對它們進行管理，修補和其餘方面的保護。

其次，沒有人按照原樣運行 Docker（譯者注：這裏的意思應該指的是並無徹底像前面提到的徹底進程隔離，不相互影響之意）。相反，它幾乎老是做爲複雜容器編排結構的一部分進行部署。例如 Kubernetes、ECS、docker-swarm 或者 Nomad。這些是至關複雜的平臺，須要專門的人員來操做（稍後將詳細介紹這些解決方案）。

可是，若是我是開發人員，我只想編寫代碼並讓其餘人爲我運行它。Docker、Kubernetes 和全部的這些」爵士樂「都不是簡單易學的東西 —— 我真的須要嗎？

簡而言之，這取決於！

對於那些只是想讓其餘人運行他們的代碼的人，AWS Lambda（或者相似的解決方案）是問題的答案：

AWS Lambda 容許你在不配置或者管理服務器的狀況下運行代碼。你只須要爲你消耗的計算時間付費 —— 當你的代碼未運行時不收取任何費用。

若是你據說過整個 」serverless「 運動，那就是它。再也不須要運行着的服務器或者要管理的容器。只須要編寫代碼，將其打包成 zip 文件，上傳到 Amazon 而且讓他們處理頭痛（的運維）！

此外，因爲 Lambda 很是短暫，沒有什麼能夠破解的 —— Lambda 在設計上很是安全。

太棒了，不是嗎？

可是（驚不驚喜！）有警告。

首先，Lambda 最多隻能運行 15 分鐘（截止 2018 年 11 月）。這意味着長時間運行的進程，如 Kafka consumers 或者數字運算應用程序沒法在 Lambda 中運行。

其次，Lambda 是功能即服務（Function-as-a-Service），這意味着你的應用程序必須徹底分解成微服務，而且和其餘複雜的 PaaS 服務協調，如 AWS Step Functions。並不是每一個企業都處於這種微服務架構的水平。

第三，對於 Lambda 進行故障排除很困難。他們是在雲原生（cloud-native）運行時，全部的錯誤修復都發生在 Amazon 生態系統中。這一般具備挑戰性且不直觀。

簡言之，沒有免費的午飯。

注意：如今還有 」serverless「 的雲容器解決方案。AWS Fargate 就是這樣的方法。可是，我忽略了這一點。由於這些每每至關昂貴而且使用要當心。

總結

Docker 和 Lambda 是打包、運行和管理生產應用程序的兩種最流行的現代雲原生方法。

他們一般是互補的，每種都適用於略有不一樣的場景和應用程序。

不管如何，現代 DevOps 工程師必須精通二者。所以，學習 Docker 和 Lambda 是很好的短時間和中期目標。

注意：到目前爲止，在咱們的系列中，咱們已經涉及了初級到中級 DevOps 工程師都應該知道的主題。在後續章節中，咱們將討論更適合中級到高級 DevOps 工程師的技術。可是，和往常同樣，沒有捷徑可言！

若是發現譯文存在錯誤或其餘須要改進的地方，歡迎到 掘金翻譯計劃 對譯文進行修改並 PR，也可得到相應獎勵積分。文章開頭的 本文永久連接 即爲本文在 GitHub 上的 MarkDown 連接。

---

掘金翻譯計劃 是一個翻譯優質互聯網技術文章的社區，文章來源爲 掘金 上的英文分享文章。內容覆蓋 Android、iOS、前端、後端、區塊鏈、產品、設計、人工智能等領域，想要查看更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。