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

0x7e2發表於2018-12-19
dev工程師

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

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

“Packages” 由 chuttersnap 拍攝並發表在 Unsplash 上

快速回顧

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

在第 2 部分，我們討論瞭如何為部署將來的程式碼奠定基礎：

在第 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、前端、後端、區塊鏈、產品、設計、人工智慧等領域，想要檢視更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。

相關文章