一千萬個為什麽

搜索

如何在Ansible設置中測試配置和配置?



著眼於試圖建立一些適應供應和配置的Ansible設置的彈性。

我了解了一些配置方面的測試方法,但我想知道如何在配置方面實現測試,以及是否有任何工具可以幫助實現這種配置。

目前我們的很多測試都是在劇本期間連續進行的,這對於諸如“有服務出現,是可用的vip,這個異步任務已完成”之類的東西具有很大的意義,但真正令我擔心的是我們能夠管理在應用程序和供應層都配置(例如VM配置)。我知道Ansible不是處理配置漂移的最佳工具,但我很想看到您自己的意見。

如果你有什麽可以更好地完成自動化過程。 (我們有幾個醜陋的腳本每天都會報告回來)。

Note: Right now we have a few conditions where a reprovision might occur (e.g. rebuild from backup, critical systems issue) but typically it just loops through some of the ansible configuring tasks and thinks no more of it.

轉載註明原文: 如何在Ansible設置中測試配置和配置?

一共有 4 個回答:

我見過的兩個工具是 InSpecServerSpec 。 Serverspec是基於Ruby的工具,基於 RSpec 。 InSpec受RSpec和ServerSpec的啟發。

我用過ServerSpec。這很酷,但可能不是100%穩定。我在Ubuntu上測試特定版本的軟件時遇到了問題。

我已閱讀InSpec文檔,但尚未深入挖掘。它與Serverspec基本上是一樣的。

根據Github提交的看法,看起來ServerSpec的工作已經有所變化,而InSpec只是越來越大。

那裏有一些選項..

Testing tools: Sorted by github stars

  • Serverspec - Ruby, most popular tool out there, built on ruby's rspec
  • Goss - YAML, simple, <10MB self-contained binary, extremely fast, can generate tests from system state
  • Inspec - Ruby, think of it as an improved serverspec, almost same syntax, made by the chef guys. Built to be easier to extend than serverspec
  • Testinfra - Python, has the cool feature of being able to use Ansible's inventory/vars

它們之間的主要差異:

最終,我建議花一整天的時間與他們一起試驗,在為自己決定之前感受他們。

  • With the exception of Goss, all the frameworks can run against a remote machine (ex. over ssh). Goss only runs locally or in docker w/ dgoss.
  • All frameworks can be run locally on a server, but require Python or ruby to be installed or embedded. Inspec provides a self-contained <150MB bundle with an embedded version of ruby. Goss is a single <10MB binary with no external dependencies.
  • Goss has built in support for nagios/sensu output, this allows for easier integration with monitoring tools.
  • Goss tests tend to be simpler, but less flexible since it's based on YAML. Other frameworks allow you to leverage the full power of the underlying language Python/Ruby to write tests or extend the tool's functionality. (simplicity vs flexibility)
  • Goss allows you to generate tests from current system state
  • Testinfra to my knowledge is the only one that has built-in support for ansible inventory and variables
  • Inspec is backed by Chef

連續/分歧測試:

  • Chef Compliance - works with inspec to continuously test your servers, paid product
  • Goss - Can be easily hooked into Nagios or Sensu. Also, supports exposing server tests as an http endpoint.

開發測試線束:

  • kitchen - Testing harness tool, launches instance, runs config management code, runs test suite. Made by the chef guys
  • Molecule - Similar to test kitchen, but written specifically for ansible

Full Disclosure: I'm the author of goss

使用配置管理工具(如Ansible)時,工具本身負責防止配置漂移。一旦您使用Ansible來設置特定配置,Ansible的重復執行將確保您的配置與您定義的一致。這也需要您的Ansible代碼以冪等性的方式書寫。

鑒於上述情況,可以通過在某個服務器的循環中執行您的Ansible劇本來實現測試配置。例如,cron作業或Jenkins可以每隔30分鐘執行一次劇本並報告任何故障。沒有故障意味著您的配置已經過檢查,出現故障意味著將服務器置於您的期望的狀態中存在問題。

在你不能相信你的代碼被編寫為冪等的情況下,因此你不能在一個自動服務器的循環中重復執行Ansible,所以存在一種解決方法。您可以像上面一樣執行(在循環中運行Ansible),但使用其 空運行模式。 Ansible每次報告需要進行更改時,Jenkins作業(或cron作業)都會通知您,您的配置配置已被更改,並且服務器未處於其期望狀態

為了確保你的Ansible代碼實際上在做你認為應該做的事情,Dave Swersky提到的解決方案也適用。 InSpecServerspec 是以不同的方式進行驗證的工具,以便您的劇本能夠真正實現您的意思。在測試環境(甚至碼頭集裝箱)中執行這些工具的一個好方法是使用 kitchen.ci ,它可以處理各種基礎單元測試工具之間的所有粘合劑,以及您的劇本/模塊/食譜的執行。

Kitchen.ci最初用於測試廚師食譜,但插件存在和其他CM工具以及。

Test Kitchen有一個可用於廚房的供應商插件,用於測試Ansible代碼。它不如廚師整合那麽深,但它確實為大多數情況完成了工作。還有最近的Molecule項目是一個專用的Ansible測試系統。