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

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 官方博客。