年度十佳 DevOps 博客文章（後篇）

時間 2019-11-17

標籤年度十佳 devops 博客文章简体版

原文原文鏈接

若是說 15 年你尚未將 DevOps 真正應用起來，16 年再不實踐也未免太落伍了。在上篇文章中咱們瞭解到 15 年十佳 DevOps 博客文章的第 6-10 名，有沒有哪一篇抓住了您的眼球，讓您有所收穫呢？接下來讓咱們來看一看排名前五的文章，到底是不是妙筆生花，鞭辟入裏！html

本文是「年度十佳 DevOps 博客文章（前篇）」的後半部分，譯自 Hasan Yasar 的文章 the Top 10 Devops Posts of 2015 .git

2015 年 8 月，DevOps 博客推出了本身的平臺。DevOps 博客針對愈來愈多采用 DevOps 的企業（自 2011 年來佔比高達 26%），提供各類指南、實用建議和教程。根據近期研究，這些企業變動代碼的速度比傳統企業快 30 倍。儘管 DevOps 的優點顯而易見，不少企業仍然不敢欣然採用，由於這不只須要轉變觀念，還要改變文化和技術要求，後者對孤立的豎井式企業而言，是極大的挑戰。考慮到這些障礙，CERT 研究人員的文章主要集中介紹 Amazon 和 Netflix 的 DevOps 成功案例，以及 Fabric、Ansible 和 Docker 等流行 DevOps 技術的教程。本文則介紹了 2015 年 10 篇最受歡迎的 DevOps 文章中的第 1-5 名（倒序）。github

5.DevOps 案例分析：Netflix 和 Chaos Monkey

DevOps 常常被用在敏捷開發、自動化和持續交付等實踐中，但 DevOps 的精神卻能夠應用在不少方面。在這篇博文中，C. Aaron Cois 剖析了另外一個影響深遠的 DevOps 思惟案例分析 - Netflix 的開箱即用方式。sql

下面是這篇文章的摘錄：mongodb

對於 DevOps 來講，Netflix 是一個奇妙的案例，由於 Netflix 軟件工程過程顯示了對 DevOps 思惟本質的深入理解和經過自動化輔助過程對質量屬性的關注。DevOps 從業者信奉以一種注重質量屬性的驅動知足業務需求，充分利用自動化過程實現一致性和高效率。docker

Netflix 的流媒體服務是一個託管在 AWS 上的大型分佈式系統。衆多組件必須一塊兒工做，才能爲使用各類設備的客戶提供可靠的視頻流。過去， Netflix 工程師須要同時重點關注服務器和客戶端組件這兩者的可靠性和魯棒性等質量屬性。簡而言之，他們得出結論，正確應對失敗的惟一方法是不斷失敗。爲了實現確實符合 DevOps 風格、預期的信賴水準和質量水平，Netflix 工程師開始採用自動化故障方案。數據庫

閱讀原文： DevOps 案例分析：Netflix 和 Chaos Monkey服務器

4.用 Docker 進行開發

在用 Docker 進行開發這篇文章中，Joe Yankel 分享了一份利用 Docker 在軟件開發通用環境中進行開發的入門教程：啓動一種數據庫容器 (MongoDB) 和一種網絡服務容器（一款 Python Bottle 應用），而後對兩者進行通訊配置，造成實用的多容器應用。網絡

下面是這篇文章的摘錄：架構

若是您還不瞭解 Docker 的基本知識，請先點擊此處學習 Docker 的官方教材再繼續閱讀本文。

入門前，您須要有一臺虛擬主機或其餘兼容 Docker 的主機。根據下面的操做說明來建立演示程序所需的源文件。

爲方便起見，請從咱們的 github 資源庫下載全部源文件，而後跳轉到演示部分。咱們的源代碼包含一份 Vagrant 配置文件，可在適用環境下運行演示。請點擊此處查看咱們對 Vagrant 的介紹。

閱讀原文：用 Docker 進行開發 & 推薦文章爲何 Cloud Insight 要支持監控 Docker

3.DevOps 的持續集成

人們首次展望敏捷軟件開發模式時，核心原則是：更快地實現軟件更改迭代、經過探索肯定適當的路徑，本質上來講，就是力求「故障快速修復 (fail fast)」並將正確性做爲基本項目目標進行迭代。有人認爲，因爲對客戶認識不足以及沒法預期客戶不斷變化的需求，在項目開始時開發人員缺乏正肯定義長期項目要求的必要信息，所以，敏捷過程應運而生。近期的研究繼續凸顯出軟件開發週期中規劃、設計和執行階段之間的斷層問題，爲這一結論提供了有力證實。在 DevOps 的持續集成這篇文章中，C. Aaron Cois 強調須要進行持續集成以免斷層，從而下降軟件開發項目的風險。

下面是這篇文章的摘錄：

持續集成 (CI) 是 DevOps 的基石。持續集成技術由 Grady Booch 開發並命名，可持續合併來自團隊全部開發人員的最新源代碼並造成共享主線。持續的合併能夠防止其餘成員新增代碼時開發人員的軟件項目本地複本偏離主題過遠，從而避免災難性的合併衝突。實際應用中，CI 會有一臺中央服務器，在開發人員提交新的源碼或從頭構建軟件應用時，這臺服務器會持續地歸入全部源碼的修改狀況，並將此過程當中的任何故障告知團隊。若是發現故障，開發團隊應該從新將精力集中在故障修改，直到修復完成才能提交新的代碼修改。雖然看起來有些混亂，但實際上 CI 使開發團隊專一於單一的穩定性指標：行之有效的軟件自動構建。

DevOps 方法的關鍵要素是消除理解斷層和影響力斷層，企業必須派遣一位或多位相關專家與開發團隊展開全面交流，鞏固域中心觀點。要消除開發和維護之間的斷層，DevOps 從業人員一開始就將開發團隊中的 IT 運維專業人員視爲團隊正式成員。一樣地，爲了確保軟件質量，在整個項目週期內質量管理人員都必須做爲團隊成員。換句話說，DevOps 意識到，確保高質量開發須要與多位技術專家（包括質量管理專家和運維專家）持續交流並積極聽取專家意見，繼而以敏捷爲原則擴展現其應用範圍。

閱讀原文

2.DevOps 與 Docker

Docker 是 DevOps 社羣近來的熱門話題，這天然是有充分理由的。Docker 容器提供的工具可在可控、獨立、靈活同時高度可移植的基礎架構中開發和部署軟件應用。在 DevOps 與 Docker 這篇文章中，CERT 研究人員 Joe Yankel 將 Docker 介紹爲一個對可擴展性、資源利用率和彈性都有極大好處的軟件應用開發和部署工具。

下面是這篇文章的摘錄：

Linux 容器技術 (LXC) 做爲 Docker 的構建基礎，已經不是什麼新理念了。自 2.6.24 版起，LXC 就是 Linux 內核的一部分，該版本正式集成了控制組（Control Groups，簡稱 cgroups）。實際上，早在 2006 年，谷歌就開始使用 Cgroups，這是由於谷歌一直設法分離在共享硬件上運行的資源。事實上，谷歌認可一週啓動超過 20 億臺容器，同時發佈了谷歌版 LXC 容器並命名爲 lmctfy，即「讓我容納你的程序 (Let Me Contain That For You)」。

不幸的是，在 Docker 出現並簡化容器技術以前，容器技術一直難以採用。在 Docker 出現以前，開發人員一度難以使用、實施甚至理解 LXC 技術，更別提意識到 LXC 的系統管理程序優點了。DotCloud 創始人兼 Docker 現任首席技術官 Solomon Hykes 啓動 Docker 項目並於 2013 年 3 月將其做爲開源軟件公之於世，這無疑是一個偉大的行動。Docker 的易用性源於其高水平 API 和文檔支持，這使得 DevOps 社羣全速發展，進而建立出各類教程和官方集成化應用，並衍生了衆多附加技術。Docker 下降了容器技術領域的准入門檻，改變了開發人員共享、測試和部署應用程序的方式。

閱讀原文 & 推薦文章 Docker 監控實戰

1.DevOps 技術：Fabric 仍是 Ansible

在 DevOps 技術：Fabric 仍是 Ansible 這篇文章中，CERT 研究人員 Tim Palko 特別介紹了 DevOps 部署過程的用例，包括評估資源要求、設計產品系統、配置產品服務器和推送代碼等。

下面是這篇文章的摘錄：

部署代碼的工做流程幾乎和代碼自己的歷史同樣久遠。與 DevOps 部署過程相關的用例不少，舉幾個例子，包括評估資源要求、設計產品系統、配置生產服務器和推送代碼等。在這篇文章中，我會重點介紹一個配置遠程服務器的用例，以及執行代碼必需的數據包和軟件。這一用例獲得了衆多不一樣競爭技術的支持，包括 Chef、Puppet、Fabric、Ansible、Salt 和 Foreman 等，而這些只是你在 DevOps 的自動化之路上可能見到的滄海一慄而已。全部這些技術都提供了免費版，你能夠將他們加入本身的資源庫以完成工做。本文更深刻地探討了 Fabric 和 Ansible。要了解更多其餘基礎架構即代碼的解決方案，請查看 Joe Yankel 撰寫的關於 Docker 文章或我對 Vagrant 的介紹。

Fabric 和 Ansible 的一個區別是，Fabric 能夠在幾分鐘內見效，而 Ansible 則須要多花些時間去理解。通常來講，Ansible 更爲強大，這是由於它爲多層架構建模了提供更深刻更復雜的語義，例如 Web 和數據庫主機陣列。從運維人員的角度來講，Fabric 的 API 更基本也更符合字面意義，同時使用 Python 進行創做，而 Ansible 則使用 YAML 並提供更豐富的行爲（這一點稍後討論）。咱們會在這篇文章中仔細分析 Fabric 和 Ansible 的例子。

閱讀原文