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

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

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

1. DevOps 技術：Fabric 與 Ansible

這篇博客文章 DevOps 技術：Fabric 與Ansible中，CERT 研究人員 Tim Palko 重點描述了使用 DevOps 部署過程相關的情況，包括評估資源需求、設計生產(chǎn)系統(tǒng)、配置和生產(chǎn)服務器的配置、同步代碼等等。

以下為摘錄:

部署代碼的工作流程幾乎和代碼本身一樣古老。有許多與部署過程相關聯(lián)的用例，包括評估資源需求、設計一個生產(chǎn)系統(tǒng)、配置和配置生產(chǎn)服務器、同步代碼等等。在這篇博客文章中，我將會專注于配置一個遠程服務器上的軟件包和必要的軟件來執(zhí)行您的代碼。這個用例可以使用許多不同的，相互競爭的技術完成，如：Chef、Puppet、Fabric、Ansible、Salt、Foreman，這些只是少數(shù)你可能已經(jīng)聽到過的有關 DevOps 自動化運維之路的技術。所有這些技術都有提供倉庫，可以提交腳本到倉庫，并完成任務。這篇文章更深入的探討了Fabric 和 Ansible。要了解更多關于其他基礎設施即代碼的解決方案，看看Joe Yankel 關于 Docker 的文章或我的關于 Vagrant 的文章。

Fabric 和 Ansible 之間的一個區(qū)別是，Fabric 會讓你在幾分鐘內看到結果，而 Ansible 需要付出更多的努力去理解。通常來說，Ansible 是更強大的，因為它提供了更深入和更復雜的多層架構模型的語義，如 Web 和數(shù)據(jù)庫主機陣列。從運維的角度看，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做開發(fā)

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

以下為摘錄:

Linux 容器技術（LXC），為 Docker 的建立提供了基礎，然而這并不是一個新想法。LXC 早已出現(xiàn)在 Linux 內核2.6.24版本中，當控制族群（或 cgroups）正式被集成時。實際上谷歌早在2006就使用了 Cgroups 技術，因為谷歌一直在尋找，在共享硬件上進行資源隔離和運行的方式。事實上，谷歌承認每周會啟動200萬個容器，使用自己發(fā)布的 LXC 容器imctfy。

不幸的是，這種技術并不容易被采用，直到 Docker 來簡化容器技術，使它更易于使用。在沒有 Docker 的時代，開發(fā)者很難訪問，實現(xiàn)，更不用說要理解 LXC 的優(yōu)點。DotCloud創(chuàng)始人、現(xiàn)任首席技術官 Solomon Hykes 發(fā)現(xiàn) Docker 的潛力，在2013年三月份Docker作為開源項目被發(fā)布。Docker的易用性是由于其高層次抽象的API以及文檔，使得 DevOps 社區(qū)充滿力量，并創(chuàng)建 Docker 教程、官方化應用程序和許多其他的技術。通過降低進入容器技術的門檻，Docker 已經(jīng)改變了開發(fā)人員共享、測試和部署應用程序的方式。

在這篇文章使用 Docker 開發(fā)中，Yankel 描述了如何開始使用 Docker 在一個普通的軟件開發(fā)環(huán)境開發(fā)相應的軟件，通過啟動一個數(shù)據(jù)庫容器（MongoDB），一個 Web 服務容器（Python Bottle APP），并配置它們可以互相訪問。這是一個多容器應用程序。

以下為摘錄:

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

在開始教程之前，你需要有一個虛擬機或其他兼容 Docker 的主機。按照下面的說明創(chuàng)建演示程序所需的源文件。為方便起見，從我們的 GitHub 庫上下載所有源文件并跳轉到演示部分。我們的源代碼包含一個 Vagrant 的配置文件，自動配置能夠運行的正確環(huán)境。這里可以看看我們有關Vagrant的帖子。

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

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

4.DevOps 示例：Amazon AWS

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

以下為摘錄:

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

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

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

5.DevOps 示例：Netfix的Chaos Monkey

DevOps 經(jīng)常被運用在如敏捷開發(fā)、自動化和持續(xù)交付，DevOps 的精神可以應用在很多方面。在這篇博客中，C. Aaron Cois分享了另外一個具有開創(chuàng)性的 DevOps 案例研究，Netflix的一些開箱即用的方式。

以下為摘錄:

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

Netflix 的流媒體服務是一個托管在AWS的大型分布式系統(tǒng)。由于這么多組件一起工作，為各個地區(qū)的客戶提供可靠的視頻流，Netflix 工程師需要側重于服務端-客戶端組件質量屬性的可靠性和魯棒性的?？傊?#xff0c;他們得出結論認為，處理失敗的唯一方法是不斷實踐失敗。為了實現(xiàn)如此可信賴的，質量達標的水平，使用 DevOps 的風格，Netflix 公司的工程師開始使用自動化故障方案。

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

6.DevOps 和敏捷開發(fā)

Melvin Conway，一個杰出的計算機科學家和程序員，創(chuàng)造了康威定律，康威定律說：設計系統(tǒng)的組織，最終產(chǎn)生的設計等同于組織之內、之間的溝通結構。因此，一個公司的前端、后端和數(shù)據(jù)庫團隊可能會傾向于使用三層架構。在很大程度上，應用程序的結構，是由組織溝通后產(chǎn)生。簡而言之，形式是交流的產(chǎn)物。

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

以下為摘錄:

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

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

7.DevOps 團隊需要 ChatOps

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

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

以下為摘錄:

在最近的一篇博客中，Eric Sigler寫道，ChatOps，一詞起源于GitHub上，都是關于基于對話的驅動開發(fā)方式?！鞍涯愕墓ぞ邘У侥臏贤ㄟ^程中，并使用一個聊天機器人修改關鍵的插件和腳本工作，團隊可以自動執(zhí)行任務和協(xié)作工作，使工作更好、更便捷、更快”Sigler寫道。

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

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

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

8.DevOps之Vagrant

環(huán)境等同是一個理想的狀態(tài)，在不同的環(huán)境中執(zhí)行代碼都將正常運行。缺乏環(huán)境等同會使軟件開發(fā)陷入令人沮喪的困境。部署和開發(fā)都經(jīng)常會陷入這樣的陷阱，降低了穩(wěn)定性、可預測性和生產(chǎn)力。當環(huán)境不等同時，這使得故障難以排除，而且難以協(xié)作。這種缺乏環(huán)境等同使開發(fā)人員和運維人員負擔太多。

在這篇博客中DevOps 之 Vagrant，CERT研究員 Tim Palko 描述了 Vagrant，這是一個開發(fā)者使用的工具，提供了一個虛擬化和環(huán)境配置，Vagrant 為開發(fā)者提供了一個單一的，聲明式腳本，以及一個簡單的命令行界面。通過使用相同的預先配置的 Vagrant 腳本，Vagrant 為所有開發(fā)者統(tǒng)一了線上的環(huán)境。Vagrant 的消除了“環(huán)境不同”的借口，在應用開發(fā)生命周期過程中。

以下為摘錄:

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

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

這就是Vagrant出現(xiàn)的意義。Vagrant是一個面向開發(fā)者的工具，基本上Vagrant提供了一個虛擬化環(huán)境，提供了一個單一的，聲明式的腳本和一個簡單的命令行界面。Vagrant通過啟動一個虛擬機（VM），去除繁重的工作，消除了人工配置或運行，例如，chef-server和chef-client。Vagrant的隱藏這一切，提供一個簡單的腳本給開發(fā)人員，一個名叫Vagrantfile無擴展項文件，可隨著代碼簽入到源代碼控制。

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

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

在計算系統(tǒng)中，上下文切換發(fā)生在，操作系統(tǒng)保存一個應用程序線程的狀態(tài)，停止線程并恢復其他線程的狀態(tài)（之前停止線程），使其他線程恢復執(zhí)行。上下文切換管理的開銷，發(fā)生在處理狀態(tài)的保存和恢復，這個過程會對操作系統(tǒng)產(chǎn)生負荷，并影響應用程序的性能。在博客使用DevOps解決上下文切換的不利影響中，CERT研究員Todd Waits描述了如何使用DevOps改善負面影響，減少項目之間的“上下文切換”對軟件工程團隊效率的影響。

以下為摘錄:

Quality Software Management: Systems Thinking, Gerald Weinberg在這本書中討論了，上下文切換的概念是如何適用于一個工程團隊。從人力勞動力的角度來看，上下文切換是一個項目停止工作的過程，并在不同的項目上完成不同的任務后，將其重新?lián)炱饋怼＞拖裼嬎銠C系統(tǒng)一樣，在多個項目之間進行上下文切換時，團隊成員通常會產(chǎn)生開銷。

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

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

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

10.什么是 DevOps？

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

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

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

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

以下為摘錄:

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

• 不同項目團隊人員之間的合作
• 基礎設施即為代碼
• 自動化任務、過程和工作流程
• 監(jiān)控應用和基礎設施

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

組織良好的團隊會發(fā)現(xiàn)（或創(chuàng)建）工具和技術，使他們的組織實踐 DevOps。每個組織都是不同的，有不同的需求，不同的但是必須滿足的需求。DevOps 的關鍵，并不是一個殺手級的工具或腳本，而是合作文化和傳遞價值的終極承諾。

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

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

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

OneAPM 是應用性能管理領域的新興領軍企業(yè)。想技術文章，請訪問 OneAPM 官方博客。

轉載于:https://www.cnblogs.com/oneapm/p/4719077.html

總結

以上是生活随笔為你收集整理的Fbric、Ansible、Docker、Chaos Monkey：DevOps工具的年中回顾的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內容還不錯，歡迎將生活随笔推薦給好友。