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


33

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

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

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

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

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



Ansibleはプロビジョニング時に一度だけ実行されますか?そうでない場合は、どの頻度で実行されていますか?ソリューションを提供する前に問題を理解しようとしています。
ウッドランドハンター

こんにちは@Naphtaのいずれかの回答があなたの質問を解決しました。チェックマークをクリックして受け入れてください。これは、あなたが解決策を見つけたことをより広いコミュニティに示し、回答者とあなた自身の両方にある程度の評判を与えます。これを行う義務はありません。
リチャードスレーター

I'm aware Ansible isn't the best tool for working with configuration drift 説明してください。
030

回答:


19

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

テストツール: 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以降では、商用/オープンソースの混合ライセンスが使用されます-コメントを参照してください。


4
少し偏っているのはわかりますが、inspecでは定期的にコンプライアンスを実行する必要はありません。また、管理する依存関係はありません。必要なすべてのライブラリとフレームワーク(ruby)は、ssh / winrmを介して実行するときに各ノードにローカルにインストールできるパッケージにバンドルされています。あなたは排他的な外部コマンドについて指摘しますが、これは真実ではなく、多くのテストは内部ルビーコードによって行われます。(注意する価値があると思います)
天柴街

外部コマンドを修正するために回答を更新し、inspecにルビーをバンドルしました。inspecを単独で使用してドリフトを検出/報告する方法を説明するリンクを明確にするか、リンクを送信してください。
アーメドエルサバヒ

さて、報告の部分はあなたの手にあります、それは実際に表現をすることがコンプライアンス目標です。ただし、crontabでinspecを実行し、警告が表示されないテストがある場合(たとえば)crontabメールに依存することができます。
テンシバイ

全体として、編集に苦労します。これは、ツールや他のツールの公正な説明に聞こえます。これはすぐに時代遅れになるのではないかと思いますが、とにかくリストとポインタについては+1です。
テンシバイ

ああ、そうです。すべてのツールをそのように活用できます。より良いレポートを提供するツール(またはツールとの統合)を提供しようとしていました。私の知る限り、コンプライアンスがあるか、nagios / sensu / some-other-monitoring-toolフレンドリーになるようにツールをラップします。例:slideshare.net/m_richardson/… 最初は偏っていたとしても、それが意図されていなかったので申し訳ありません。
アーメド・エルサバヒ

13

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

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

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

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

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


1
「Ubuntuのソフトウェアの特定のバージョンのテストで問題が発生しました。」:私はSOにそれについての質問に気付いた後、これを固定stackoverflow.com/questions/42417864/...
マットSchuchard

少し明確にするために、InSpecはRSpecをエミュレートしますが、RSpecには基づいていません。
-coderanger

1
@MattSchuchardその参照をありがとう!
デイブSwersky

テストツールのためのよくない「100%の安定」とは、任意の良い音ではありません
ᴳᵁᴵᴰᴼ

InSpecはテストツールとして非常に優れており、サーバーに何もインストールするのが簡単になりますが、ServerSpecは追加の作業を行うだけでこれを実行できます。ただし、InSpecでAnsibleインベントリを使用するにはいくつかの作業が必要になります-インベントリがYAML形式(Ansible 2.4+)の場合はおそらく簡単です。
-RichVel

10

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ツール用のプラグインも存在します。


5

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


0

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


1
DevOps.se Alexeyへようこそ。この場合、あなたのツールはユーザーに役立つかもしれませんが、これが答えになるためには、これが質問にどのように関連するかを伝えるためにもう少しあるはずです。それ以外の場合は、リンクのみの広告のように見えます。

こんにちは!確かに、詳細が与えられました。
アレクセイ・メレジク

私の観点からすると、これはrundeckでできること以外は何もせず、この質問の範囲外です。特に、その答えは、1000台のサーバーの監査を解決し、ドリフトを警告したり、解析可能な出力を提供することで監査人に人間が読めるレポートを提示したりする方法を説明していません。私が今読んだものからは、inspecでできること(例)よりも多くはなく、大規模で使用可能な出力が少なくなりますが、仕事をするために多くの外部ツールが必要になり、移植性が低下します。
Tensibai

「それは千のサーバーを監査解決することができますどのように」 -私は、問題の数千台のサーバーについては何も見つけることができた
アレクセイMelezhik

「ドリフトのアラートを受け取るか、解析可能な出力を提供することにより、監査人に人間が読めるレポートを提示します。」どちらも私は質問でこれを見つけませんでした。漂流の明白なアラートは、テストが失敗し始めているという事実です...
アレクセイMelezhik
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.