コードおよびTDDとしてのインフラストラクチャ

コードとしてのインフラストラクチャは、ビルドを自動化するツールを使用するように指示します。すごい。ansible、chef、puppet、salt stackなどのツールは、違いを解決しながら、インフラストラクチャがどのように見えるかを書くように私たちを促しています。

ソルトスタックでは、これらのビットは状態と呼ばれます。状態が現実と一致しない場合、ツールはそれを解決します。つまり、インフラストラクチャのテストを作成しており、テストが失敗した場合は、ツールが独自に修正します。少なくともそれは考えです。

XPはTDDの使用を教えてくれますが、問題はそれがインフラストラクチャに適用可能かどうかです。ツールはそれを示唆しています。

非常に役立つテストの種類はほとんど想像できません。

デプロイされたサービスにバンドルされているスモークテストを記述して、デプロイされたサービスが期待どおりに機能し、実行されることを確認します。これは、API呼び出しまたは/およびsystemctlチェックで、デプロイしたばかりのものが機能することを確認します。ansibleのようなツールには、サービスが実行されていることを確認するための状態があるため、この機能の多くは同じ状態でカバーできます。

dockerまたは別の一時的な仮想化エンジンに対して（ansibleがその状態を呼び出すときに）個々のロールを実行できるプロジェクトMoleculeがあります。これにより、役割の分離が強制され、作業中にプレイブックから分離して実行することができます。テストでは、ほとんどの場合、ロールが機能するはずの変数をモックできます。他の例は、ansibleエンジンの複製のように見えます（ファイルがユーザーに属していることをアサートします...）。

ThoughtWorksのハイテクレーダーは、今のようなツール賞賛INSPEC、serverspecやゴスをサーバーが仕様を満たしていることを検証するため。しかし、私たちはスペックを書いていますね？

インフラストラクチャを州/役割で説明している場合、インフラストラクチャをさらにテストすることに意味がありますか？これは、1つのチームが仕様を提供し、他のチームが従う大規模な組織でより必要になるか、または役割の大きなセットがある場合、それらのサブセットを実行してテストから速度のメリットを得たいと思うかもしれません。同じ質問に対する役割/状態が考えられるのに、なぜテストを書くのかを理解するのに苦労しています。

要するに、インフラストラクチャのテストには2つのカテゴリがあります。1）アプリケーションを実行するために必要なすべてのものがあるか、2）余分なものがないかです。

何よりもまず、実際のソフトウェアのテストスイートを、インフラストラクチャの一種の「メタテスト」として扱うことができます。テストの実行ごとにインフラストラクチャを最初から作成し、テストスイートがそのインフラストラクチャで完全に実行される（つまり、外部サービスを使用しない）限り、スイート全体が緑色であるという事実は、体系化されたインフラストラクチャでも十分であることを意味します。

次に、特にセキュリティの観点から、インフラストラクチャに対するテストを作成できます。つまり、インフラストラクチャの一部がLinuxを実行するVMである場合、そのVMに対してポートスキャンを実行するテストを記述して、意図しないapt-get install副作用によってインストールされた可能性のある意図しないポートが開いていないことを確認します。 。または、適切なテストスイートの完了後に予期しないファイルが変更されたかどうかをチェックするテストを作成することもできます。またはps、VMまたはDockerコンテナーの出力で予期しないプロセスなどをチェックし、ホワイトリストなどを作成して、一部のアップグレードでドキュメント化されていない（または気付かれていない方法で）サードパーティパッケージが変更された場合に自動通知を受け取ることができます。

これらの2番目のタイプのテストは、ある意味では、とにかく古典的なops設定で行うのと似ています。つまり、サーバーを強化して侵入をチェックし、完全なリソースを回避します。

私見IaaC状態の仕様で完全にカバーされている項目のTDDテストを書くのはかなり冗長です。そうすることは、IaaCの有効性が疑わしいことを意味します。そうであれば、なぜそれを使用するのですか？

別の将来のIaaC自体からそれを見る（適切に行われた場合）には、すでにテストされ、確実に機能していると見なされている機能が組み込まれています。これが魅力的であり、TDDマッチングテストの記述が冗長になります。

たとえば、SSHがインストールされているシステムを指定するIaaC構成には、SSHが正しくインストールされているかどうかの信頼できるチェックが組み込まれており、そうでない場合は、適切にインストールするためのメカニズムが組み込まれています。SSHが冗長にインストールされているかどうかをチェックするためのTDDテストを行います。IaaC構成で、特定のポートで開始およびリッスンするsshdも指定している場合、それぞれのポートで実行およびリッスンするsshdのTDDテストも冗長になります。

私の回答はTDDや、IaaC構成が全体として特定の目的に適合しているかどうかを確認するその他の種類のテストを対象としていないことに注意してください。これは引き続き有効であり、そのIaaC仕様の開発中のTDD、CI、または同様のチェックで使用できます。@ AnoEの回答はそのような場合に当てはまると思います。

ここの誰もがIACツールが常に期待どおりに実行されると想定しているようですが、私自身の経験から、これが常に当てはまるわけではないことがわかります。そうでない場合、ユニットテストは実際には役に立たないでしょう。

「Ansibleプレイブックが実行されました。すべてが正常です」という背景の建物が燃えているという絵を覚えています...

宣言的な状態を実行することと、サーバーをこの実際に宣言された状態にすることは、私の見方と経験から、2つの異なるものです。

複数のDCに広がっており、パブリックネットワークなどから到達可能な、広範で異機種環境。完全にまたは部分的に状態を適用できなかった理由はいくつかあります。

これらすべての理由により、ユニットテストの余地があり、実際のサーバーの状態のスナップショットを取得できます。これも、目的の状態とは異なる場合があります。

ですから、ユニットテストはIAC管理環境でも役立ちます。

編集

IaCコードベースのdevブランチの非回帰側についてはどうですか？だからあなたはdevブランチのコードに変更を加え、それをすべて破壊しないことを期待してprodブランチにマージしますか？単体テストはとても価値があり、通常は実装が簡単です。なぜこの機能なしでコーディングするのかわかりません。

リファレンス（フランス語で申し訳ありません）：https : //fr.slideshare.net/logilab/testinfra-pyconfr-2017

私の経験では、DevとOpsの主な違いの1つは「実行時の大きな依存関係」です。パッケージのインストールは、リポジトリ、ネットワーク、または有効なキーに大きく依存します。あるいは、新しいクラウドサーバーのインスタンスを作成するとします。それはプロバイダーのリソースに依存します。

サーバーのプロビジョニングに関しては、プロビジョニングコードを変更しなかった場合でも、イメージはほとんどの場合有効ですが、有効にならない場合もあります。ですから、作業イメージを提供するにはテストが本当に不可欠だと思います。

単一サーバーを超えると事態はさらに悪化します...ネットワーク設定全体で到達可能性をどのようにテストしますか？DNS解決、ルーティング、ファイアウォールが含まれていますか？IaaCプロバイダーAPIが期待どおりに機能する場合でも（この領域で有線の問題を確認しました）、この場合はTDDが本当に好きです。

この領域にはテストツールが見つからなかったので、空き時間に1つ作成しました：https : //github.com/DomainDrivenArchitecture/dda-serverspec-crate

したがって、TDDはDevOpsの世界では非常に重要だと思います。