Fbric、Ansible、Docker、Chaos Monkey：DevOps工具的年中回顧

【編者按】近日，Cyber Engineering Solutions Group 技術經理 Hasan Yasar 在 SEI 攥文盤點了當下流行的 DevOps 思想和工具，其中包括Fabric、Ansible、Docker、Chaos Monkey等。本文系 OneAPM 聯合高效運維聯合編譯整理：

在2014年年底，SEI 部落格發表了一系列有關 DevOps 的部落格文章，提供指南，實用的建議和教程。這些帖子針對越來越多的採用 DevOps 的企業（2011年以來，高達26％）。根據最近的研究，這些組織部署變更程式碼比傳統的方式快30倍。儘管 DevOps 的好處顯而易見，但是許多企業仍不敢採用 DevOps，因為這需要轉變心態、文化和技術要求，對於傳統企業是非常大的挑戰。鑑於這些障礙，CERT 研究人員的文章主要集中在介紹 Amazon和 Netflix DevOps 的成功案例，以及一些 DevOps 流行技術的教程，如 Fabric、Ansible 和 Docker。這個帖子介紹了過去六個月，10個最流行的 DevOps 相關文章（根據訪問次數排序）。

1. DevOps 技術：Fabric 與 Ansible

這篇部落格文章 DevOps 技術：Fabric 與Ansible 中，CERT 研究人員 Tim Palko 重點描述了使用 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，提供了豐富的操作（我以後再討論這篇文章）。我們將通過這篇文章中的例子來說明。

閱讀完整的文章 DevOps 技術：Fabric 與 Ansible 請訪問 http://blog.sei.cmu.edu/post.cfm/devops-technologies-fabric-or-ansible。

2. DevOps 之 Docker

3.使用Dokcer做開發

Docker 這些日子在 DevOps 社群是相當火爆，這有很好的理由。Docker 容器使開發和部署應用軟體達到可控制的、隔離的、靈活的和高度可移植的基礎設施。在 DevOps 和 Docker 這篇文章中，CERT 研究員 Joe Yankel 介紹了使用 Docker 開發和部署軟體應用程式的可擴充套件性，資源效率，以及彈性。

以下為摘錄:

Linux 容器技術（LXC），為 Docker 的建立提供了基礎，然而這並不是一個新想法。LXC 早已出現在 Linux 核心2.6.24版本中，當控制族群（或 cgroups）正式被整合時。實際上谷歌早在2006就使用了 Cgroups 技術，因為谷歌一直在尋找，在共享硬體上進行資源隔離和執行的方式。事實上，谷歌承認每週會啟動200萬個容器，使用自己釋出的 LXC 容器 imctfy 。

不幸的是，這種技術並不容易被採用，直到 Docker 來簡化容器技術，使它更易於使用。在沒有 Docker 的時代，開發者很難訪問，實現，更不用說要理解 LXC 的優點。DotCloud創始人、現任技術長 Solomon Hykes 發現 Docker 的潛力，在2013年三月份Docker作為開源專案被髮布。Docker的易用性是由於其高層次抽象的API以及文件，使得 DevOps 社群充滿力量，並建立 Docker 教程、官方化應用程式和許多其他的技術。通過降低進入容器技術的門檻，Docker 已經改變了開發人員共享、測試和部署應用程式的方式。

在這篇文章使用 Docker 開發中，Yankel 描述瞭如何開始使用 Docker 在一個普通的軟體開發環境開發相應的軟體，通過啟動一個資料庫容器（MongoDB），一個 Web 服務容器（Python Bottle APP），並配置它們可以互相訪問。這是一個多容器應用程式。

以下為摘錄:

如果你沒有事先了解過 Docker，你應該去官方教程學習一下教程再在這裡繼續。

在開始教程之前，你需要有一個虛擬機器或其他相容 Docker 的主機。按照下面的說明建立演示程式所需的原始檔。為方便起見，從我們的 GitHub 庫上下載所有原始檔並跳轉到演示部分。我們的原始碼包含一個 Vagrant 的配置檔案，自動配置能夠執行的正確環境。這裡可以看看我們有關Vagrant的帖子。

閱讀完整的文章，DevOps 和Docker，請訪問 http://blog.sei.cmu.edu/post.cfm/devops-docker-015

閱讀完整的使用 Docker 開發，請訪問 http://blog.sei.cmu.edu/post.cfm/development-with-docker

4.DevOps 示例：Amazon AWS

經常閱讀 DevOps 部落格的讀者會發現這個系列中會反覆出現的主題：DevOps 本質上是通過精心的構建組織過程、加強溝通和工作流程來提升質量。通過學習知名高科技公司的技術管理和軟體工程，我們的系列文章，可以從真實世界的案例中獲得非常大的價值和相關的結果。這些案例也為 DevOps 從業者的提供非常優秀案例。在 DevOps 示例：Amazon AWS ，C. Aaron Cois 分享了 Amazon DevOps 的經驗。

以下為摘錄:

Amazon 是當今最多產的科技公司之一。Amazon 在2006年時做了轉變，從一個線上零售商，轉變成一個科技巨頭，併發布了（AWS），成為雲服務的先鋒，AWS 提供了廣泛使用的一種按需配置的基礎設施服務（IaaS）。Amazon 的 AWS 承受了大量的風險。通過開發第一個大規模的公共雲服務，他們瞭解了很多的挑戰都是未知的，有許多未經證實的解決方案去證實。要學習亞馬遜的成功，我們需要問正確的問題。亞馬遜採取什麼措施來減少這種固有風險的風險？亞馬遜工程師如何定義他們的過程，以確保質量？

幸運的是，當谷歌工程師Steve Yegge（前亞馬遜工程師）意外地公開了一份內部備忘錄，概述了他所瞭解的谷歌平臺工程的失敗（亞馬遜的成功）。這使我們可以大致瞭解 Amazon 成功的過程。這本備忘錄（這 Yegge 特別允許可以在網路上傳播）概述了具體決策，描述了執行長 Jeff Bezos 的基本原則，這些原則我們現在稱之為 DevOps，以及 AWS 平臺的質量屬性：互操作性、可用性、可靠性和安全。

閱讀完整的文章， DevOps 示例：Amazon AWS， 請訪問 http://blog.sei.cmu.edu/post.cfm/devops-casestudy-amazon-aws-036.

5. DevOps 示例：Netfix的Chaos Monkey

DevOps 經常被運用在如敏捷開發、自動化和持續交付，DevOps 的精神可以應用在很多方面。在這篇部落格中，C. Aaron Cois分享了另外一個具有開創性的 DevOps 案例研究，Netflix的一些開箱即用的方式。

以下為摘錄:

Netflix 是一個奇妙的案例研究，因為他們的 DevOps 軟體工程過程，展示了一個對 DevOps 本質的瞭解，專注通過 DevOps 自動化輔助過程來達到質量要求。DevOps 從業者信奉一種注重質量屬性的驅動來滿足業務需求，利用自動化過程實現一致性和效率。

Netflix 的流媒體服務是一個託管在 AWS 的大型分散式系統。由於這麼多元件一起工作，為各個地區的客戶提供可靠的視訊流，Netflix 工程師需要側重於服務端-客戶端元件質量屬性的可靠性和魯棒性的。總之，他們得出結論認為，處理失敗的唯一方法是不斷實踐失敗。為了實現如此可信賴的，質量達標的水平，使用 DevOps 的風格，Netflix 公司的工程師開始使用自動化故障方案。

閱讀完整的文章 DevOps 示例：Netfix 的 Chaos Monkey，請訪問 http://blog.sei.cmu.edu/post.cfm/devops-case-study-netflix-and-the-chaos-monkey。

6.DevOps 和敏捷開發

Melvin Conway ，一個傑出的電腦科學家和程式設計師，創造了康威定律，康威定律說：設計系統的組織，最終產生的設計等同於組織之內、之間的溝通結構。因此，一個公司的前端、後端和資料庫團隊可能會傾向於使用三層架構。在很大程度上，應用程式的結構，是由組織溝通後產生。簡而言之，形式是交流的產物。

在文章 DevOps 和敏捷開發中，C. Aaron Cois學習康威定律並應用到自己的組織。

以下為摘錄:

傳統的，但不足的，瀑布式開發模式已經為我們的應用程式定義一個特定的溝通結構：開發開發人員讓（QA）團隊測試並質量保證，QA 讓運維（OPS）團隊去部署。這種方式的溝通，是非敏捷的，加重了我們有缺陷的組織結構，這又是一個印證了康威定律的例子：組織結構決定產品。

閱讀完整的文章 DevOps 和敏捷開發，請訪問 https://blog.sei.cmu.edu/post.cfm/devops-agile-317。

7. DevOps 團隊需要 ChatOps

專案團隊關鍵利益相關者之間的對話（例如，開發人員、業務分析員、專案經理、安全團隊），平臺之間的溝通，可以對協作產生深遠的影響。較差的或甚至沒有使用通訊工具，導致溝通不暢，重複的工作，或錯誤的實現。另一方面，開發和業務基礎設施相結合的通訊工具，可以加快向組織交付業務價值。一個團隊如何組織基礎設施結構，如何溝通，將直接影響團隊的效率。

在文章 DevOps 團隊需要 ChatOps 中，CERT研究員 Todd Waits 介紹了 ChatOps，DevOps 的一個分支，關注 DevOps 團隊的溝通。ChatOps 包括了團隊的溝通和協作工具：通知、聊天伺服器、機器人、問題跟蹤系統等等。

以下為摘錄:

在最近的一篇部落格中，Eric Sigler寫道，ChatOps，一詞起源於GitHub上，都是關於基於對話的驅動開發方式。“把你的工具帶到您的溝通過程中，並使用一個聊天機器人修改關鍵的外掛和指令碼工作，團隊可以自動執行任務和協作工作，使工作更好、更便捷、更快”Sigler寫道。

大多數團隊在聊天伺服器上都有一定程度的合作。聊天伺服器可以作為一個城市廣場一樣容納開發團隊、促進團隊之間的凝聚力、討論實際問題以及潛在解決方案等。我們希望所有的團隊成員使用聊天伺服器。在我們的團隊中，為了避免一般聊天室的灌水聊天，我們也建立專用聊天室，每個專案，專案團隊成員可以談論專案的細節，不涉及其他的團隊。

和其他簡單的溝通介質不一樣，聊天伺服器可以智慧化，開發的基礎設施，向團隊傳遞通知，團隊執行命令並反饋回基礎設施。我們的聊天伺服器是通知的樞紐，與我們的基礎設施快速互動。專案團隊通過聊天伺服器接到通知（還有其他方法），關注基礎設施任何生成狀態，他們關注：構建失敗、構建成功、超時等。

閱讀完整的文章DevOps團隊需要ChatOps，請訪問 http://blog.sei.cmu.edu/post.cfm/chatops-in-devops-team-029。

8.DevOps之Vagrant

環境等同是一個理想的狀態，在不同的環境中執行程式碼都將正常執行。缺乏環境等同會使軟體開發陷入令人沮喪的困境。部署和開發都經常會陷入這樣的陷阱，降低了穩定性、可預測性和生產力。當環境不等同時，這使得故障難以排除，而且難以協作。這種缺乏環境等同使開發人員和運維人員負擔太多。

在這篇部落格中 DevOps 之 Vagrant ，CERT研究員 Tim Palko 描述了 Vagrant，這是一個開發者使用的工具，提供了一個虛擬化和環境配置，Vagrant 為開發者提供了一個單一的，宣告式指令碼，以及一個簡單的命令列介面。通過使用相同的預先配置的 Vagrant 指令碼，Vagrant 為所有開發者統一了線上的環境。Vagrant 的消除了“環境不同”的藉口，在應用開發生命週期過程中。

以下為摘錄:

運維團隊的作業通常包括在所有部署環境中實施全面的校驗，例如用於測試、分段和上線。相反，開發團隊幾乎完全自己負責配置開發機器。為了達到百分之100的環境等同，兩個團隊必須使用相同的語言，使用相同的資源。

Chef和Puppet，這兩個都是為運維而生，對一個繁忙的開發人員來說可能不太友好。Chef和Puppet都有一個比較陡的學習曲線，並沒有真正解決環境等同的問題：開發者仍然需要和線上環境同步。所有這些額外的工作會帶來一個相當大的開銷，而你只想好好的寫業務程式碼！

這就是Vagrant出現的意義。Vagrant是一個面向開發者的工具，基本上Vagrant提供了一個虛擬化環境，提供了一個單一的，宣告式的指令碼和一個簡單的命令列介面。Vagrant通過啟動一個虛擬機器（VM），去除繁重的工作，消除了人工配置或執行，例如，chef-server和chef-client。Vagrant的隱藏這一切，提供一個簡單的指令碼給開發人員，一個名叫Vagrantfile無擴充套件項檔案，可隨著程式碼簽入到原始碼控制。

閱讀完整的文章DevOps之Vagrant，請訪問 https://blog.sei.cmu.edu/post.cfm/devops-technologies-vagrant-345。

9.使用DevOps解決上下文切換的不利影響

在計算系統中，上下文切換髮生在，作業系統儲存一個應用程式執行緒的狀態，停止執行緒並恢復其他執行緒的狀態（之前停止執行緒），使其他執行緒恢復執行。上下文切換管理的開銷，發生在處理狀態的儲存和恢復，這個過程會對作業系統產生負荷，並影響應用程式的效能。在部落格使用DevOps解決上下文切換的不利影響中，CERT研究員Todd Waits描述瞭如何使用DevOps改善負面影響，減少專案之間的“上下文切換”對軟體工程團隊效率的影響。

以下為摘錄:

Quality Software Management: Systems Thinking, Gerald Weinberg在這本書中討論了，上下文切換的概念是如何適用於一個工程團隊。從人力勞動力的角度來看，上下文切換是一個專案停止工作的過程，並在不同的專案上完成不同的任務後，將其重新撿起來。就像計算機系統一樣，在多個專案之間進行上下文切換時，團隊成員通常會產生開銷。

當團隊成員被分配到多個專案時，上下文切換通常會發生。上下文切換的合理理由是，邏輯上來講，為團隊成員分配專案任務，比為每個專案分配專用資源更省時省力。這似乎是合理的假設，將一個人的精力平分，對每個專案，兩者之間的專案收益率百分之50。此外，如果一個團隊成員只在一個單獨的專案中，如果這個專案正在等待處理某些事情，比如等待書面工作審批、審查等，該小組成員將是空閒的，沒有充分利用。

使用我們計算系統的隱喻，任務之間的切換類似多執行緒概念，如果一個執行緒因為某些事情阻塞，其他執行緒可以執行其他工作，而不是等待第一個執行緒直到恢復。如果所有的工作只分配給第一個執行緒，進展很慢。雖然多執行緒在計算系統中很合理，問題是，人類並不總是能很好分配精力。因此效率會在上下文切時損失，生產力可能會在精力分散在更多的專案的時候下降。

閱讀完整的文章使用 DevOps 解決上下文切換的不利影響，請訪問 http://blog.sei.cmu.edu/post.cfm/addressing-detrimental-effects-context-switching-devops-064。

10.什麼是 DevOps？

通常，當我們設想一個實現了 DevOps 的組織，我們可以想象一個自動化運轉良好的機器

• 基礎設施配置
• 程式碼測試
• 應用部署

最終，這些做法的結果是運用 DevOps 的方法和工具。DevOps 適合所有規模的團隊，從一個一個人的團隊到一個企業組織。在這篇博文中，什麼是 DevOps ，CERT 研究員 Todd Waits 介紹了 DevOps 的基礎。

DevOps 可以看作是敏捷方法的推廣。它要求掌握相當多的知識和技能，包括一個專案從開始到持續，到被一個專門的專案小組負責。組織壁壘必須打破。只有這樣才能有效地緩解專案風險。

以下為摘錄:

然而嚴格來說，DevOps 並不是持續整合，交付或部署。DevOps 的做法能使團隊達到協調，理解必要的自動化基礎設施、測試和部署。特別是，DevOps 提供了組織如何保證：

• 不同專案團隊人員之間的合作
• 基礎設施即為程式碼
• 自動化任務、過程和工作流程
• 監控應用和基礎設施

商業價值驅動 DevOps 的發展。如果沒有 DevOps 的心態，組織經常發現他們的運維、開發和測試團隊，目光短淺，只致力於建立方便自己的基礎設施、測試套件或產品增量。一旦一個組織打破了這些孤島，把這些領域的專業知識整合起來，就可以把重點放在共同致力於提供商業價值的基本目標上。

組織良好的團隊會發現（或建立）工具和技術，使他們的組織實踐 DevOps。每個組織都是不同的，有不同的需求，不同的但是必須滿足的需求。DevOps 的關鍵，並不是一個殺手級的工具或指令碼，而是合作文化和傳遞價值的終極承諾。

閱讀完整的什麼是DevOps，請訪問 https://blog.sei.cmu.edu/post.cfm/what-is-devops-324。

每兩週，SEI 會發布一篇新的部落格，為那些嘗試採用 DevOps 的組織提供指南，實用的建議和教程。我們歡迎您對本系列文章提供反饋，以及對未來內容的建議。請在下面的評論部分反饋意見。

原文連結：Fabric, Ansible, Docker, and Chaos Monkey: The DevOps Mid-Year Review

OneAPM 是應用效能管理領域的新興領軍企業，能幫助企業使用者和開發者輕鬆實現：緩慢的程式程式碼和 SQL 語句的實時抓取。想閱讀更多技術文章，請訪問 OneAPM 官方部落格。