一千萬個為什麽

搜索

配置管理工具是否適合用作部署工具?



關於我的回答後面的問題: DevOps如何幫助改進軟件托管過程? Tensibai有這樣的問題:

什麽將需要在傀儡或廚師之上的Capistrano?

我的回應是發布一個鏈接到諾亞吉布斯的文章“我們是否需要Capistrano和廚師?”。就我個人而言,我仍然贊同諾亞的觀點,認為最適合:

  • 使用Capistrano等專業部署工具進行部署。
  • 使用Chef等專業配置管理工具進行配置管理。

每種工具用於完成其任務的基本方法都非常不同:

  • 配置管理工具 - 關於創建和維護系統的期望狀態,它們本質上具有冪等性。配置管理工具的示例是廚師PuppetAnsiblePowerShell DSC鹽堆

  • 部署工具- 是關於將軟件版本提供到托管環境,它們提供了在多臺機器上維護多個版本的軟件的功能,並管理版本是“當前的”,它們在本質上本質上是必不可少的。部署工具的示例是 CapistranoOctopus Deploy部署人員Command.io

我確實認為配置管理工具可以完成部署工具的工作,對於不可變基礎結構,它們是最適合工作的工具,因為不需要維護目標上的軟件版本。

Question: Have configuration management tools such as Chef, Ansible and Puppet matured to the point that they are capable of fulfilling both the idempotent and imperative models?

轉載註明原文: 配置管理工具是否適合用作部署工具?

一共有 5 個回答:

在這種情況下,典型的建議應立即適用:為工作使用正確的工具。

但是現在你也不能忽視軟件工具幾乎有毒的傾向,以便將功能擴展到更多或更少的相關領域,並且實際上由於各種原因成為工具集:很酷的功能,擁有,擴大客戶群,賺取更多收入等。

例如,許多文件管理工具包括圖像查看功能,而許多圖像處理工具包括文件管理功能。您可以移動文件,並且可以使用任何一種工具查看圖像,通常也是如此。

正因為如此,即使軟件開發過程的主要特征/功能不同,也很有可能通過多個工具(集合)覆蓋/重疊軟件開發過程的整個部分。

所以它真的歸結為想要在你的特定過程中實現的功能,以及一個工具或另一個工具在你的上下文中的工作情況 EM>。包括主觀性/偏好/便利。

提出這個問題主要是基於意見的;)

配置管理工具用於使系統進入已知狀態。部署工具將新的程序文件和程序數據部署到系統中。在一天結束時,這兩種類型的工具都會進行以下組合:

  • 確定系統的當前狀態。
  • 傳輸文件到系統。
  • 添加或更改持久性數據(例如配置文件,數據庫數據,註冊表設置)
  • 啟動或重新啟動程序。

配置管理工具具有指定系統狀態的聲明性語言。部署工具具有告訴系統執行任務的命令式語言。 DevOps人員需要同時執行這兩項操作。

使用部署工具Capistrano,使用其語言來告訴系統確保Web服務器處於活動狀態是很笨拙的。您必須發出命令重新啟動Web服務器,另一個則檢查Web服務器是否啟動。將網絡服務器置於已知狀態是一件棘手的事情。

使用配置管理工具Ansible,重新啟動Web服務器很笨拙。該語言可讓您告知Web服務器“啟動”,但如果您特別希望重新啟動該服務器,則必須將其狀態設置為“重新啟動”。但是,沒有簡單的方法來檢查Web服務器是否已重新啟動。這是Ansible中的一項功能,可以實現一次性操作。

有些人喜歡用一種工具來完成這兩種工作,並且在粗糙的邊緣工作。其他人更喜歡有兩種工具來做幾乎相同的事情,但沒有粗糙的邊緣。為了回答這個問題,“適當性”是一個有趣的問題。這個答案解釋了原因。

TL;DR: Just use Ansbile, it is both configuration and deployment tool :)

有幾種類型的部署:

  • 基於應用程序(文件,檔案包)

  • 基於容器(包括VM,Habitat,LXC,Docker)

  • 基於(微服務/ Lambdas /函數)

我假設在這種情況下,我們只說服務器上的應用程序更新。


對於部署,您需要發生兩件事情:

  1. 正確的文件或包需要移動到服務器。
  2. 需要更改配置和服務狀態。

現在對於(1)你可以使用多種策略:

  • 工件存儲庫/同步
  • 軟件包存儲庫/軟件包管理器
  • 版本控制系統/更新+編譯(可選)
  • 文件傳輸協議(scp,rsync,ftp)
  • 部署工具

對於(2)你可以使用:

  • 配置管理工具
  • 部署工具

所以雖然部署工具是一種全面部署的方式,但它們並不總是最好的策略。有時候您想要將這些方式結合使用進行部署。您很可能已經至少在您的服務器上使用軟件包管理器了。無論如何,你很可能會運行配置工具。一些配置工具的問題是多個服務器之間的適當協調,但現在即使Chef和Puppet也可以很好地完成這項工作。 Ansible一直擅長這一點。

個人經驗 ,我已經使用了所有組合,但目前我們使用Capistrano進行部署,使用Ansible同步進行配置管理,並使用VCS和包存儲庫進行文件傳輸,但Capistrano存在問題,計劃脫離它來統一Ansible的部署,維護和配置管理。

應用程序部署是很難確定的,因為它有很多子問題。配置管理系統在建模任務方面非常出色,這些任務是趨同的,並且與“系統的期望狀態”一致。在應用程序部署的情況下,這對於將位部署到機器,管理配置文件和設置系統服務等方面非常有用。對於固有的程序性問題,尤其是數據庫遷移和服務重啟,這是非常糟糕的。我通常會嘗試將聚合邏輯放在Chef中,並讓外部過程工具(通常是Fabric)處理剩下的幾個位,並對實際收斂進行排序。

所以,基本上,你應該使用他們最擅長的作品。

對於軟件和將代碼部署到現有服務器或Docker容器中,答案相對簡單 - 不,您不需要兩者,但是如果另一個工具或實用程序增加了值,是該工作的正確工具,但是當您部署服務器和操作系統時,事情會變得更加復雜。

DevOps思想的一個附加價值是將基礎架構視為代碼,並經常在高度彈性化的環境中部署或銷毀虛擬機,甚至裸機。您的配置管理系統無法輕松地為您啟動和啟動服務器,並且無法在部署期間或部署後或在某些情況下為許可證和授權管理存儲庫,軟件包和更新/修補程序。

對於亞馬遜網絡服務,大多數情況下,API可以非常方便地進行管理,但對於那些必須管理我們自己的數據中心的我們來說,這不是一種選擇。出於這個原因,工頭項目(和紅帽重新推出這個產品)發現有必要捆綁 KatelloCandlepin 以及配置管理員,如Ansible,Foreman或部署 Katello場景時的木偶。

因此,雖然您可能能夠避開在開發者的Dev側使用配置管理工具進行軟件代碼部署,但在Ops方面,有幾種情況下答案是響亮的“不,配置管理工具是< em> not 適合用作部署工具“這樣做需要對車輪進行重新發明並且不切實際。您必須改用您的配置管理工具來啟動其他工具的部署。