DevOps 工程師成長日記系列五：部署

原文地址： https://medium.com/@devfire/how-to-become-a-devops-engineer-in-six-months-or-less-part-5-deploy-83e790545c23
原文做者： Igor Kantor
翻譯君：CODING 戴維奧普斯

讓咱們簡要回顧下咱們的 DevOps 之旅：
在第一篇，咱們介紹了 DevOps 文化以及相關的基礎技能；
在第二篇，咱們討論瞭如何爲未來的代碼部署奠基基礎；
在第三篇，咱們討論瞭如何有組織地管理代碼；
在第四篇，咱們討論如何簡單地打包代碼。
如下是咱們貫穿先後的路線圖：

若是在上圖每列的技術棧上花費一個月左右的話，那麼咱們如今處於第 4 個月。基於前文的學習，咱們已經知道了如何配置將要運行代碼的服務器基礎架構、如何正確地對代碼進行版本管理、如何將代碼打包以備部署。今天咱們要討論如何部署代碼。

部署代碼

注意到了嗎？我沒有說「如何輕鬆地部署代碼」，由於代碼從開發環境到正確部署仍然是一個充滿了錯誤和失敗的痛苦過程。

緣由不少，但在我看來，這主要歸結爲差別。具體而言，建立代碼的環境與實際代碼運行的環境之間存在差別。我認爲減小這些差別意味着你不只能夠在總體代碼部署中實現最大的改進，還能夠在代碼部署後的運行時達到必定的優化。那麼，咱們如何減小或消除生產和非生產環境之間的差別呢？

在個人機器上明明是能夠跑的

若是你的開發基礎設施是這樣的：

用「溫柔的愛和關懷」手工組裝而成的開發基礎設施

但你的生產環境基礎設施看起來像這樣：

那你就會遇到麻煩。

若是你使用基礎設施即爲代碼的方式而不是手動配置，那麼差別這事兒你已經搞定得七七八八了。若是不是，請不要絕望 —— 你並不孤單。花一個下午，找出你所碰到的全部差別（培訓、文化、人員、流程等），並逐一消除它們。

最重要的是，若是你仍在手動配置，那你可能很難去管理現代技術棧。所以你須要作的第一件事是確保涉及產品的全部內容都是由部署服務器構建的版本化軟件包。假設上述事情你已經完成，我會告訴你部署代碼的最佳方法是不部署代碼。

現代化的代碼部署

將代碼部署到生產環境機器是一件很是 90 年代的事情。

現有技術的「代碼部署裝置」

將代碼部署到一組固定生產環境機器的最大問題是：你的生產環境服務器（代碼運行的地方）與你的開發環境服務器（編寫代碼的地方）不一樣。這就難怪在部署後會當即出現大量問題。

所以，你須要盡一切可能確保構建產物（而不是一小段代碼）一直處在運行環境當中。換句話說，將代碼一次性部署到開發環境，克隆運行代碼的整個機器環境，而後將其複製到須要的任何位置。這被稱爲「不可變部署」，是一個很是強大的模式，能夠避免你數小時部署後的頭痛。固然，若是你運行容器，一樣的想法也是適用的：在任何地方部署相同的容器便可。

「可是個人生產環境和開發環境就是不一樣的！」你可能會說。數據庫用戶名密碼，鏈接字符串，S3 存儲桶位置等等，這些都是不一樣的。解決這個問題的方法是使用 12 因子應用配置原則。全部配置都須要外部化並做爲環境變量傳遞到服務器。

例如，若是在 AWS，可使用 SSM 做爲外部參數存儲，它很好地集成了 CloudFormation。直接經過 aws ssm cli 命令行工具設置環境變量也很是容易。固然，其它雲廠商也提供了相似的機制。

當出現問題時，你須要壓制「修理」生產環境機器的衝動。這些機器是不可變的，這意味着你所作的任何修復都必須來自開發環境。事實上，你的終極目標應該是根本不容許任何在生產環境服務器上的接入。沒有 ssh、沒有 scp、沒有人有任何訪問權限，不是你，更不是覬覦中的黑客。

但若是我須要日誌來解決問題呢？因此日誌也應該外部化。理想狀況下能夠經過ElasticSearch / Logstash / Kibana（ELK）技術棧或商業軟件（如 SumoLogic 或Datadog）將日誌轉儲到其它地方。

不管你作什麼，你的產品都是「黃牛」 —— 它們會在出現最輕微的不健康信號時就被替換。它們不是「寵物」，須要耗費數小時進行故障排除來恢復健康。我知道這個比喻被太多人使用了，而且我聽到那些真正養牛的人說過實際上他們的工做原理和咱們剛所討論的不一樣，但重點事務確實如此。不要「修復」你的生產環境機器，而是修復你的開發環境並從新部署。

代碼部署機制

因此你知道要作些啥了，但怎麼作呢？

「不幸」的是，這就是 Jenkins 的用武之地，Jenkins 是最受歡迎的開源部署自動化服務器之一。我說「不幸」是由於 Jenkins（及其前任 Hudson）已經存在了近十年，而且在漫長的使用過程中咱們發現了：它的設置很複雜，維護起來更復雜。它帶有數以百萬計的可疑質量插件。這些插件每每會在最不合適的時候崩潰，把全部事情搞砸。實際上，真正具備彈性的分佈式 Jenkins 設置不多見，一般只有最大的研發組織裏才能看到。

那爲何我還建議你從 Jenkins 開始呢？由於儘管存在各類缺陷，它仍然很是受歡迎，而且在咱們的行業中被大量使用。瞭解 Jenkins，特別是 Jenkinsfile 的結構，對就業前景會是一個巨大而且不容忽視的好處。當你學習 Jenkins 時，請確保你遵循較新的 Pipeline BlueOcean 技術路徑，而不是更舊的「Jenkins jobs」。

參考閱讀：
Jenkinsfile：https://jenkins.io/doc/book/pipeline/jenkinsfile/
Pipeline BlueOcean：https://jenkins.io/doc/book/blueocean/

當你但願 CI/CD 流水線被直接包含在代碼倉庫當中後，持續集成工具會變得很是重要，這樣的話流水線自己就是一段版本化的代碼。

一切都是代碼

你的應用程序如何被部署、監控、配置等等——說到底最終都化做爲存儲在代碼倉庫裏被正確版本化的代碼片斷。

咱們的目標是爲核心開發人員（編寫功能代碼的軟件工程師）建立一個真正無摩擦的環境。例如，我應該可以編寫我本身的微服務、添加我認爲必要的測試、添加監控即代碼的配置、在一些「env.yaml」 文件中指定個人參數、將它們所有存儲在一個代碼倉庫中；經過 CI/CD 流水線自動觸發構建、測試、部署（金絲雀發佈或藍綠髮布），並在完成後給我發送電子郵件。事實上，這是 DevOps 工程師核心使命的本質。

Jenkins 的替代品

就像我以前說過的那樣，Jenkins 已經被廣大開發者使用很長一段時間了。如今還有其它的工具，在我看來更好，即便沒有 Jenkins 那麼爲人所知。

• 一個是 AWS 本身的 CodeDeploy 服務。它有侷限性，但 CodeDeploy 背後的開發人員在過去一年作了很大的改進，若是你在用 AWS，建議你試一試。
• 另外一個是 GitLab CI。若是你的研發組織運行在 GitLab 上，你能夠考慮使用，由於它與 GitLab 的其它部分良好地集成在一塊兒。
• 去年十月 GitHub 宣佈了 Actions（目前仍處在公測中），用於 GitHub 用戶的自動化工做流場景。

我認爲這裏的工具並非最重要的。重要的是要記住包括代碼部署流水線在內的全部內容都是版本化的軟件部件，它首先得來自於開發環境，而不是生產環境。

若是你從 Jenkins 開始學習持續集成，請嘗試將其設置爲容器模式。這並非一件很是困難的事情，反而會是一個很不錯的學習機會，你能夠找到彈性的、容器化的 Jenkins 機器節點來部署容器化的 Jenkins。

你也徹底能夠從簡單的、沒有任何容器編排的方式開始，這是下一篇文章的主題，敬請關注。

寫在最後

原文做者給咱們介紹了一個很是重要的實踐：在部署環境遇到的問題要去調整和修改開發環境，讓生產環境與開發環境保持一致，修改生產環境治標不治本。同時也給咱們介紹了一些他喜歡的國外持續集成工具。針對國內的工具，譯者推薦你還能夠考慮使用 CODING 持續集成，它是 CODING 提供的一站式 DevOps 解決方案中重要的一環。其構建腳本在語法上全面兼容 Jenkins，又免除開發者部署和維護持續集成環境的繁瑣事務。

同時 CODING 支持包括 Docker 鏡像、Jar、APK 等軟件包的構建，預置了主流開發語言的構建環境：Java、PHP、Go、Python 等等；開啓緩存加速功能能夠平均提升 300% 的構建速度。對於包括 Maven，NPM 在內的主流鏡像源有專用網絡優化，保證拉取速度； 支持單項目並行構建，以知足重度持續集成用戶的需求。對不太喜歡腳本的同窗還提供了完善的圖形化編排能力，以下降使用門檻。

CODING 還對構建產物提供了統一的製品庫管理，目前製品庫已支持 Docker 鏡像、NPM、Helm 等常見包類型的製品管理。後續 CODING 會逐步支持多種主流的軟件包類型來進一步完善 DevOps 工做流，敬請期待。