「Ansibleのコードとしてのインフラストラクチャ」 コースの将来の学生と 興味のあるすべての人のために、私たちは有用な資料の翻訳を用意しました。
また、「Kubesprayを使用したKubernetesの管理」というトピックに関する公開レッスンにサインアップすることをお勧めします 。
お帰りなさい！これは、Continoによるコードとしてのインフラストラクチャに関する一連のterraformおよびkubernetesの記事のもう1つの技術記事です。
TL; DR
コマンドのサイズは関係ありません。いずれにせよ、優れたテラフォームインフラストラクチャ構成分析とエンドツーエンドの健全性テストの実装は、時間のかかる複雑なプロセスである必要はありません。
私はエキサイティングな課題に直面しました。インフラストラクチャリリースパイプラインの一部として、テラフォームコードベースに適したオープンソースのテストフレームワークを調査、開発、および提示することです。 「すべての品質管理」の原則は決して新しいものではありません。しかし、その実装は、組織のインフラストラクチャの成熟度と許容可能なリスクのレベルに依存します-[何らかの方法で]完成品に到達する段階まで。
インフラストラクチャコードのテストの分野を新たに検討することで、最新のテストフレームワークに精通し、知識を更新することができました。
確かに、私の旅の初めに、私はそのような「エンタープライズクラスの品質管理」の準備と実施が労働集約的である可能性があるという偏見に苦しんでいました。
結局のところ、Hashicorp Terraformには、コードベースを検証および検証するのに十分な機能があり ます。
- コード品質管理-
terraform fmt -check
およびterraform validate
。 - プレビュー-
terraform plan
。 - 構築-
TFLOG=debug terraform apply
綿密な検証のため。
Terraform静的コード分析ツール
Googleの櫛は、潜在的に有用なテラフォームテストツールの膨大な配列を明らかにしました。
しかし、最初に、私たちの要件のリストを見てみましょう。
- テラフォームリソース構成でユニットテストを行い、そのような一般的なベストプラクティスのリストを拡張する機能*特定のクラウドプロバイダーをチェックします。さらに、すぐに使い始めることができる使いやすいツールにも関心があります。
* 0.0.0.0/0ワールドに公開されたec2インスタンスの欠如-など。
- — «» , . , , , EKS.
- , , — , , . , , .
- , . , , Go Python. , , , , . , , . , .
スポットライト：Terraformテストツールとプラットフォームの分析と比較
次のリストにより、静的なコードとしてのインフラストラクチャの分析と品質管理の作業が容易になることを願っています。これは、私が見つけたすべての関連するテラフォームテストツールの完全なリストであり、構成の妥当性テスト、コード品質管理、およびユニットテストを使用したsecOpsに焦点を当てたベストプラクティスを組み合わせたものであることに注意してください。このリストを以下に示します。
- tflint - github.com/terraform-linters
- テラファーマ - github.com/wayfair/terrafirma
- tfsec - github.com/liamg/tfsec
- terrascan — github.com/cesar-rodriguez/terrascan ( TF 0.13)
- checkov — github.com/bridgecrewio/checkov
- conftest — github.com/instrumenta/conftest
まとめましょう。テラフォームリソースコンポーネントの標準化されたユニットテストと、結果に対して検証するためにリソース構成を取得する、よりカスタマイズ可能な一連のテストを見つけようとしました
terraform plan
。
各プラットフォームの長所と短所を確認した後、私は
checkov
非常に適切な名前のツールとプラットフォーム を選択しました
terraform-compliance
。どちらもpythonで記述されています。それらは上記の私の要件をすべて満たしていました。
コードリリースパイプラインとしてのインフラストラクチャは、一般的には次のようになります。
これらのプラットフォームを徹底的に掘り下げた後、私は必然的に自分の経験を修正し、議論中のトピックに関して次の関連する結論に達しました。
- .
- , , , .
- , , , - « » « ».
— Checkov BridgeCrew
www.checkov.io
Checkovは、コードとしてのインフラストラクチャ用の静的コード分析ツールです。
Terraform、Cloudformation、Kubernetes、Serverless、またはARMテンプレートでプロビジョニングされたクラウドインフラストラクチャをスキャンし、セキュリティとコンプライアンスの設定ミスを特定します。
テラフォームコードリポジトリをスキャンするときに実行されるデフォルトのユニットテストがいくつかあり、ベストプラクティスからの逸脱が示されます。たとえば、セキュリティ構成に従って、ポート22に仮想マシンが公開されている場合（0.0.0.0/0）。
すべてのテストは、このGitHubリンクにあります。
プラットフォームを使い始めるのはとても簡単です。
- バイナリをインストールします。
- terraforminitを使用してterraformディレクトリを初期化します。
- このディレクトリでchechovを実行します。
デフォルトで実行されるすべてのユニットテストは、コマンドラインに一覧表示できます。さらに、checkovが実行されると、プラットフォームはデフォルトですべての合格および不合格のユニットテストを返します。非常に便利で、使い始めやすいです。Terraformの高度なメソッドがテストされていますが、すべてではありません。これは根本的な違いです。
Chechovはあなたのコードだけを喜んで評価します
terraform
。プラットフォームは、の直後に機能し
terraform init
ます。彼女はあなたのことを気にしません
terraform plan
-すべての長所と短所があります。プラットフォームは、述べられていること、つまり「静的コード分析」を実行します。リソースに起こりうる結果と、ロジックに関する考慮事項に注意してください。
checkov .
深いPython開発を行う準備ができている場合は、追加のユニットテストを作成できます。プラットフォーム開発言語は私の要件の1つでした。なぜなら、テストのコードベースを分析して、[必要に応じて]そのような追加のメソッドを作成することがどれほど難しいかを見積もる必要があるからです。この瞬間は、グループ全体のサービスの問題と相まって、同じ結果を得ることができる代替プラットフォームよりもこのプラットフォームを選択する主な要因になりました。
要約すると、checkovプラットフォームは静的コード分析の分野で優れています。特に、最初に定義されたIPサブネットをホワイトリストに登録する必要がある場合。ただし、このオプションは、個別のテストプラットフォームを必要とするe2eテストには適していません。
一方、解決策として、ユニットテストを複製し、サブネット/ IP設定をハードコーディングすることができます。そして、複数のインスタンスとプロジェクトがある場合はどうなりますか？必要な場合でも、このテストをスキップしてください。多分。またはそうでないかもしれません。
ここで、2番目のテストプラットフォームが役立ちます-
terraform-compliance
。
Terraform-コンプライアンス
terraform-compliance.com
Terraform-compliance は、Terraformのセキュリティおよびコンプライアンス監査用に設計された軽量のテストプラットフォームであり、インフラストラクチャがコードと同じくらいネガティブにテストされていることを確認します。
バックグラウンド
繰り返しになりますが、動作テストのエンドツーエンド開発（BDD）がテストフレームワークとして最近使用されるようになり、ユニバーサルテストフレームワークの必要性が浮き彫りになりました。しかし、これだけがメリットではありません。シンプルさ。
実際、BDDは十分な注目を集めていないように思えます。主にソフトウェア開発環境に深く根ざしたテスト駆動型開発（TDD）について聞いたことがあるかもしれません。しかし、これはBDDのようなプラットフォームが追加のロジックの作成を容易にし、平均的なインフラストラクチャメンテナに、特別な新しいプログラミング言語を深く学ぶことなく、エンドツーエンドのカスタムテストを開発するためのよりシンプルで簡潔で反復可能な方法を提供します。
実際、コードは世界中のすべてを記述できますが、最終的にはすべてが管理性、コードの複雑さを理解する能力（広範なドキュメントの準備が必要になる場合があります）、およびサポートとメンテナンスに依存します。 BDDについて詳しくは、こちらをご覧ください。
Cucumber.io は単なる言語ではなく、WYSIWYGアプローチを使用して設計、理解、および保守をテストすることにより、テストを容易にするシステムです。これらの例は開発前に決定され、受け入れ基準として使用されます。
それらは定義の一部です。
Terraform準拠でのテスト
各プラットフォームのメリットが確認され、その機能とニュアンスを最大限に活用できる場所が詳細に調査されます。今後は、どちらのプラットフォームも使用できると言えます。
これは、
terraform-compliance
BDDプラットフォームを使用して開発されたそのようなテストの例です 。これにより、かなり複雑なエンドツーエンドのテストを実行できます。
プラットフォーム
terraform-compliance
は出力を使用します
terraform plan
..。その結果、完全なリリースの「計画」と徹底的なテストが可能になります。たとえば、[クラウドプロバイダーの]正しい暗号化キーペアがアカウントや環境などに使用されるように制御します。クリエイティブの自由度が高く、最も重要なのは、プラットフォームが非常に使いやすいことです。
以下の手順と例を確認してください。
- 手順1.terraformディレクトリを初期化します。＃terraform init
- ステップ2.次のコマンドを使用して、テラフォームプランをすばやく生成できます。＃terraform plan -out = plan.out
- ステップ3.いくつかのテストを作成します。それは簡単なことです-例のあるフォルダがすでにあります。私のテラフォームプランの出力に基づいて書かれた、以下の私自身のテスト例を見ていきましょう。
これは
terraform
、指定された起動グループでEKSを作成するテラフォーム構成プランのスニペットです 。コード
terraform
がインフラストラクチャを使用せず
instancetype
、「承認済み」
a1.xlarge
またはを 使用し ていることを確認しましょう
a1.2xlarge
。
次に、
t2.small
テストの失敗をシミュレートするために、意図的に変更し ます。
この要件が正常に検証されていることを確認するためのテストを作成しましょう。
- ステップ4.
terraform-compliance
テストシナリオを使用してボードを評価してみましょう。#terraform-compliance -p plan.out -f ./<test-cases-folder>
テストの実行
合格と不合格の結果の例
Terraformフレームワークコードが正しいものを使用している場合
instancetype
、すべての結果は緑色の成功になります。
Terraformインフラストラクチャコードが正しくないために要件に違反している
instancetype
場合、結果は赤のFAILになります。
さらに多くのテストを書いてみましょう 。examples
ディレクトリから取得したいくつかの簡単なテスト：
1つが失敗すると、ヘルプとデバッグの目的で取得および表示される「actual_value」が表示されます。
試験結果
すべてのテストが実行されると、合格および不合格のすべてのテストの便利な要約が表示されます。これには、不合格のテストも含まれます。厳密なテストの長いリストを作成できるだけでなく、どのテストがいつ失敗したかについて明確な情報を提供できるので、私はそれが好きです。さらに、失敗した場合は、
@warning
次の例に示すように、タグを使用して一部のテストをスキップでき ます。
habrastorage.org/getpro/habr/upload_files/c22/910/cb9/c22910cb95fb4ccc7555d44bd8b5436b
結果
間違いなく、これは、Terraformフレームワークとしてコードに使用できる優れた検証およびテストフレームワークのいくつかを新たに見直す絶好の機会でした。
私はこれらのプラットフォームの両方を見るのを楽しみました、そしてcheckovの統合の容易さ、そして
e2e terraform plan
それが提供する驚くべき検証とカスタムテストオプションに特に驚い ていました
terraform-compliance
。
後者は、私が過去に使用したもう1つの優れたBDD e2ekubernetesテストフレームワークであるbehaveの動作を思い出させます 。
完全にPythonで記述されたテストフレームワークにより、プラットフォーム間でPythonの知識を共有しやすくなり、将来のテストの維持と開発に必要な頭脳の量を減らすことができます。
テラフォームプランが必要ないときに構成をチェックするベストプラクティスが必要な場合は、checkovがおそらく必要なものです。それ以外の場合、答えは
terraform-compliance
、検証機能の豊富なセットを備えたプラットフォームである可能性があり ます
terraform plan
。何よりも、BDDプラットフォームであることは
terraform-compliance
非常に簡単に習得できます。
ユニットテストが最初に来ます。パイと同じくらい簡単です。 BridgecrewioのCheckovプラットフォームは、箱から出してチェックするベストプラクティスコンプライアンスを可能にします。
グループの規模に関係なく、これらの品質管理テストをスキップする正当な理由はありません。特に、それらを実装するために適用する必要のあるわずかな人件費を考慮すると（記事の例を参照）。
PS Continoには、かなりの数の素晴らしいプロジェクトがあります。超近代的なインフラストラクチャプロジェクトに取り組みたい場合、または深刻なタスクを探している場合は、お問い合わせください！私たちはスタッフを雇い、あらゆるレベルで明るい心を探しています。 Continoでは、中堅企業から大企業まで、最先端のクラウド変革プロジェクトを開発することに誇りを持っています。
«Infrastructure as a code in Ansible».
« Kubernetes Kubespray».
