DevOps 工程師成長日記系列四：打包

原文地址：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 工程師一塊兒成長。