Ansibleセットアップでプロビジョニングと構成をテストする方法

プロビジョニングと構成を扱うAnsibleセットアップに回復力を組み込むことを検討しています。

私は物事の構成側でいくつかのテスト方法を理解していますが、物事のプロビジョニング側でテストを実装する最善の方法と、このタイプの実装に役立つツールがあるかどうか疑問に思っています。

現在、私たちのテストの多くは、プレイブック中に連続して行われます。これは、「サービスが出てきました。VIPが利用可能です。この非同期タスクが終了しました」などです。アプリケーション層とプロビジョニング層の両方での構成（VM構成など）。Ansibleは構成のドリフトを処理するための最良のツールではないことは承知していますが、あなた自身の意見を知りたいと思います。

プロセスをさらに完全に自動化するものがあれば。（毎日スラックで報告するいくつかのいスクリプトがあります）。

注：現在、再プロビジョニングが発生する可能性があるいくつかの条件（バックアップからの再構築、重要なシステムの問題など）がありますが、通常はいくつかのansible構成タスクをループし、それ以上は考えません。

いくつかのオプションがあります。

テストツール： GitHubスターで並べ替え

• Serverspec -rubyのrspecに基づいて構築された、最も一般的なツールであるRuby
• ゴス -YAML、シンプル、<10MBの自己完結型バイナリ、非常に高速、システム状態からテストを生成可能
• Inspec -Ruby、それは改善されたserverspecで、ほぼ同じ構文で、シェフたちによって作られたものだと考えてください。serverspecよりも簡単に拡張できるように構築
• Testinfra -Python、Ansibleのインベントリ/変数を使用できるというクールな機能

それらの主な違い：

最終的には、自分で決定する前に、それらのすべてを試して一日を過ごして、それらの感覚をつかむことをお勧めします。

• Gossを除き、すべてのフレームワークはリモートマシンに対して実行できます（例：ssh経由）。ゴスは、ローカルでのみ、またはdgossを備えたドッカーで実行されます。
• すべてのフレームワークはサーバー上でローカルに実行できますが、PythonまたはRubyをインストールまたは埋め込む必要があります。Inspecは、組み込みバージョンのrubyを含む自己完結型の<150MBバンドルを提供します。ゴスは、外部依存関係のない単一の<10MBバイナリです。
• ゴスにはnagios / sensu出力のサポートが組み込まれているため、監視ツールとの統合が容易になります。
• ゴステストは単純になる傾向がありますが、YAMLに基づいているため柔軟性が低くなります。他のフレームワークを使用すると、基礎となる言語Python / Rubyのフルパワーを活用して、テストを記述したり、ツールの機能を拡張したりできます。（シンプルさと柔軟性）
• Gossでは、現在のシステム状態からテストを生成できます
• 私の知る限りでは、Insible InfrasibleとVariablesのサポートが組み込まれているのはTestinfraだけです
• InspecはChefによって支援されています

連続/発散テスト：

• Chef Compliance -inspecと連携して、サーバー、有料製品を継続的にテストします
• ゴス -NagiosまたはSensuに簡単にフックできます。また、サーバーテストをhttpエンドポイントとして公開することもサポートしています。

開発用のテストハーネス：

• kitchen-ハーネスツールのテスト、インスタンスの起動、構成管理コードの実行、テストスイートの実行。シェフたちが作った
• 分子 -テストキッチンに似ていますが、特にansible向けに記述されています

完全な開示：私はゴスの著者です

更新： InSpec 4.x以降では、商用/オープンソースの混合ライセンスが使用されます-コメントを参照してください。

私はこのために見てきた2つのツールがあるスペックとServerSpec。Serverspecは上に構築のRubyベースのツールであるRSpecの。InSpecは、RSpecおよびServerSpecに触発されています。

ServerSpecを使用しました。クールですが、100％安定しているとは限りません。Ubuntu上のソフトウェアの特定のバージョンのテストで問題が発生しました。

InSpecのドキュメントを読みましたが、深く掘り下げていません。Serverspecと本質的に同じことを行います。

Githubのコミットから判断すると、ServerSpecでの作業は多少落ち着いているように見えますが、InSpecは増え続けています。

更新： InSpec 4.x以降では、商用/オープンソースの混合ライセンスが使用されます-コメントを参照してください。

Ansibleなどの構成管理ツールを使用する場合、ツール自体が構成のずれを防ぐ責任があります。Ansibleを使用して特定の構成を設定した後、Ansibleを繰り返し実行すると、構成が定義どおりになっていることが保証されます。また、Ansibleコードをbe等の方法で記述する必要があります。

上記を考慮すると、サーバーからループでAnsibleプレイブックを実行することで、プロビジョニングのテストを実現できます。たとえば、cronジョブ、またはJenkinsは、30分ごとにプレイブックを実行し、失敗を報告できます。障害がないということは、構成がチェックされていることを意味し、障害があるということは、サーバーを希望する状態にするのに問題があることを意味します。

コードがべき等として記述されることを信頼できないため、自動サーバーからループ内で実際にAnsibleを繰り返し実行できない場合には、回避策が存在します。上記と同じことを実行できます（ループでAnsibleを実行します）が、その予行モードを使用します。変更が必要であるとAnsibleが報告するたびに、Jenkinsジョブ（またはcronジョブ）は、プロビジョニングされた構成が変更され、サーバーが望ましい状態にないことを通知できます。

あなたのAnsibleコードがあなたがすべきと思うことを実際に行っていることを確認するために、Dave Swerskyが言及した解決策が適用されます。どちらのスペックとServerspecはで検証ツールです異なるあなたのプレイブックは、実際にあなたが何を意味している方法。これらの種類のツールをテスト環境（ドッカーコンテナーも含む）で実行する優れた方法は、さまざまなインフラユニットテストツール間のすべての接着剤を処理するkitchen.ciを使用し、プレイブック/モジュール/クックブックの実行です。

Kitchen.ciはもともとChefクックブックのテストに使用されていましたが、Ansibleや他のCMツール用のプラグインも存在します。

Test Kitchenには、Ansibleコードをテストするためのキッチン対応のプロビジョニングプラグインがあります。Chefの統合ほど深くはありませんが、ほとんどの場合、仕事は完了します。専用のAnsibleテストシステムである最近のMoleculeプロジェクトもあります。

Outthenticを使用すると、構成/インフラストラクチャの不一致/ドリフトを追跡できます。目的の状態を「修正」し、不要な変更を追跡する必要があるたびに再実行するテストスイートを簡単に作成できます。