将来の Terraform のインフラストラクチャの説明。 アントン・バベンコ (2018)

多くの人が Terraform を知っており、日常業務で使用していますが、そのベスト プラクティスはまだ確立されていません。 各チームは独自のアプローチと方法を発明する必要があります。

インフラストラクチャは、ほとんどの場合、少数のリソースと少数の開発者という単純なものから始まります。 時間が経つにつれて、それはあらゆる方向に成長します。 リソースを Terraform モジュールにグループ化する方法、コードをフォルダーに整理する方法、その他に問題が発生する可能性のあるものはありますか? （有名な最後の言葉）

時間が経つと、インフラストラクチャが新しいペットになったように感じますが、なぜでしょうか? インフラストラクチャの不可解な変更を心配し、インフラストラクチャやコードに触れるのを恐れます。その結果、新しい機能が遅れたり、品質が低下したりすることになります...

Github 上で AWS の Terraform コミュニティ モジュールのコレクションを管理し、実稼働環境で Terraform を長期保守してきた XNUMX 年間を経て、Anton Babenko が自身の経験を共有する準備ができました。将来的に問題がないよう TF モジュールを作成する方法について説明します。

講演が終わるまでに、参加者は、Terraform のリソース管理原則、Terraform のモジュールに関連するベスト プラクティス、およびインフラストラクチャ管理に関連する継続的統合の原則についてさらに理解できるようになります。

免責事項： このレポートの日付は 2018 年 2 月であることに注意してください。すでに 0.11 年が経過しています。 レポートで説明されている Terraform 2 のバージョンはサポートされなくなりました。 過去 2 年間に、多くの革新、改善、変更を含む XNUMX つの新しいリリースがリリースされました。 この点に注意してドキュメントを確認してください。

リンク：

• terraform コミュニティ モジュール + terraform-aws-モジュール
• antonbabenko/pre-commit-terraform — コードとドキュメントの自動フォーマット
• アントンバベンコ/スッポン — Terraform モジュール (WIP) のジェネレーター
• antonbabenko/modules.tf-lambda — ビジュアル ダイアグラムからの Terraform コード ジェネレーター (WIP)
• www.terraform-b​​est-practices.com
• Medium.com/@anton.babenko (新しい投稿は私の個人ウェブサイト www.antonbabenko.com/ にあります)
• @antonbabenko - Twitter、およびさまざまな Slacks

私の名前はアントン・バベンコです。 おそらく、私が書いたコードを使用した人もいるでしょう。 私は統計にアクセスできるので、これまで以上に自信を持ってこのことについて話します。

私は Terraform に取り組んでおり、2015 年以来、Terraform と Amazon に関連する多数のオープンソース プロジェクトに積極的に参加し、貢献してきました。

それ以来、私はそれを興味深い方法で表現するのに十分なコードを書きました。 そして、今からこれについてお話ししようと思います。

Terraform の操作の複雑さと詳細について説明します。 しかし、それは実際の HighLoad の主題ではありません。 そして今、あなたはその理由を理解するでしょう。

時間が経つにつれて、Terraform モジュールを書き始めました。 ユーザーが質問を書いたので、私がそれを書き直しました。 次に、コミット前フックなどを使用してコードをフォーマットするためのさまざまなユーティリティを作成しました。

興味深いプロジェクトがたくさんありました。 私はコード生成が好きです。私とプログラマーのためにコンピューターがどんどん作業を行ってくれるのが好きなので、現在はビジュアル ダイアグラムから Terraform コード ジェネレーターの開発に取り組んでいます。 もしかしたら見たことがある方もいるかもしれません。 矢印の付いた美しい箱です。 「エクスポート」ボタンをクリックして、すべてをコードとして取得できれば素晴らしいと思います。

私はウクライナ出身です。 私はノルウェーに長年住んでいます。

また、このレポートの情報は、私の名前を知っていて、ソーシャル ネットワークで私を見つけた人々から収集しました。 ほぼいつも同じあだ名をつけています。

https://github.com/terraform-aws-modules
https://registry.terraform.io/namespaces/terraform-aws-modules

前述したように、私は Terraform AWS モジュールのメインメンテナーです。Terraform AWS モジュールは、VPC、自動スケーリング、RDS などの最も一般的なタスクのモジュールをホストする GitHub 上の最大のリポジトリの XNUMX つです。

そして、今聞いたことは最も基本的なものです。 Terraform が何なのかを理解しているかどうか疑問がある場合は、別の場所に時間を費やしたほうがよいでしょう。 ここでは専門用語がたくさん出てきます。 そして私は、レポートのレベルが最高であると断言することに躊躇しませんでした。 これは、多くの説明なしで、考えられるすべての用語を使用して話すことができることを意味します。

Terraform は、インフラストラクチャをコードとして作成、計画、管理できるユーティリティとして 2014 年に登場しました。 ここでの重要な概念は「コードとしてのインフラストラクチャ」です。

先ほども言ったように、すべてのドキュメントは次のように書かれています。 terraform.io。 ほとんどの人がこのサイトのことを知っていて、ドキュメントを読んでいることを願っています。 もしそうなら、あなたは正しい場所にいます。

通常の Terraform 構成ファイルは次のようになります。最初にいくつかの変数を定義します。

今回は「aws_region」を定義します。

次に、どのようなリソースを作成するかを説明します。

依存関係とプロバイダーを読み込むために、いくつかのコマンド、特に「terraform init」を実行します。

そして、「terraform apply」コマンドを実行して、指定した構成が作成したリソースと一致するかどうかを確認します。 これまで何も作成していないため、Terraform はこれらのリソースを作成するように求めます。

これを確認します。 したがって、seasnail と呼ばれるバケツを作成します。

同様のユーティリティもいくつかあります。 Amazon を使用している人の多くは、AWS CloudFormation、Google Cloud Deployment Manager、または Azure Resource Manager を知っています。 それぞれのパブリック クラウド プロバイダーには、それぞれのパブリック クラウド プロバイダー内のリソースを管理するための、ある種の独自の実装があります。 Terraform は、100 を超えるプロバイダーを管理できるため、特に便利です。 (詳細はこちら ここで)

Terraform が当初から追求してきた目標:

• Terraform は、リソースの単一ビューを提供します。
• すべての最新のプラットフォームをサポートできます。
• そして、Terraform は、インフラストラクチャを安全かつ予測どおりに変更できるようにするユーティリティとして最初から設計されました。

2014 年、この文脈では「予測可能」という言葉は非常に珍しいものに聞こえました。

Terraform は汎用ユーティリティです。 API がある場合は、すべてを完全に制御できます。

• 120 を超えるプロバイダーを使用して、必要なものすべてを管理できます。
• たとえば、Terraform を使用して GitHub リポジトリへのアクセスを記述することができます。
• Jira でバグを作成して閉じることもできます。
• New Relic メトリクスを管理できます。
• 本当に必要な場合は、Dropbox にファイルを作成することもできます。

これはすべて、Go で記述できるオープン API を備えた Terraform プロバイダーを使用して実現されます。

前のスライドで示したように、Terraform を使い始め、サイト上のドキュメントを読み、ビデオを見て、main.tf を書き始めたとします。

VPC を作成するファイルができました。

VPC を作成する場合は、約 12 行を指定します。 どのリージョンに作成するか、IP アドレスのどの cidr_block を使用するかを記述します。 それだけです。

当然、プロジェクトは徐々に成長していきます。

そして、そこにたくさんの新しいものを追加することになります: リソース、データ ソース、新しいプロバイダーと統合すること、突然 Terraform を使用して GitHub アカウント内のユーザーを管理することなどが必要になります。 DNS プロバイダーはあらゆるものに対応します。 Terraform を使用するとこれが簡単になります。

次の例を見てみましょう。

VPC のリソースにインターネットにアクセスできるようにするため、internet_gateway を徐々に追加します。 これは良いアイデアですね。

結果は次の main.tf になります。

これは main.tf の先頭部分です。

これは main.tf の下部です。

次に、サブネットを追加します。 NAT ゲートウェイ、ルート、ルーティング テーブル、その他のサブネットを追加する時点では、38 回線ではなく、約 200 ～ 300 回線になります。

つまり、main.tf ファイルは徐々に大きくなります。 そして、多くの場合、すべてを 10 つのファイルに入れる人がいます。 main.tf には 20 ～ 10 Kb が表示されます。 20 ～ 10 Kb がテキスト コンテンツであると想像してください。 そして、すべてはすべてとつながっています。 これでは徐々に作業が困難になってきます。 20 ～ XNUMX KB が適切なユーザー ケースであり、場合によってはそれ以上です。 そして、人々は必ずしもこれが悪いとは考えません。

コードとしてのインフラストラクチャではなく、通常のプログラミングと同様に、私たちはさまざまなクラス、パッケージ、モジュール、グループを使用することに慣れています。 Terraform を使用すると、ほぼ同じことができます。

• コードは増え続けています。
• リソース間の依存関係も増大しています。

そして、私たちには大きなニーズがあります。 私たちは、もうこのようには生きていけないことを理解しています。 私たちのコードは膨大なものになってきています。 もちろん、10 ～ 20 Kb はそれほど広大ではありませんが、ここではネットワーク スタックについてのみ話します。つまり、ネットワーク リソースを追加しただけです。 ここで話しているのは、100 Kb を簡単に組み込むことができる Application Load Balancer、デプロイメント ES クラスター、Kubernetes などの話ではありません。 これをすべて書き留めると、Terraform が Terraform モジュールを提供していることがすぐにわかります。

Terraform モジュールは、グループとして管理される自己完結型の Terraform 構成です。 Terraform モジュールについて知っておく必要があるのはこれだけです。 これらはまったくスマートではなく、何かに依存して複雑な接続を行うことはできません。 これはすべて開発者の肩にかかっています。 つまり、これはすでに作成したある種の Terraform 構成にすぎません。 また、それをグループとして呼び出すこともできます。

したがって、10 ～ 20 ～ 30 Kb のコードをどのように最適化するかを理解しようとしています。 いくつかのモジュールを使用する必要があることに徐々に気づき始めています。

最初に遭遇するモジュールのタイプはリソース モジュールです。 彼らは、インフラストラクチャが何であるか、ビジネスが何であるか、場所と状況が何であるかを理解していません。 これらはまさに、私がオープンソース コミュニティと協力して管理し、インフラストラクチャの最初の構成要素として提案したモジュールです。

リソースモジュールの例。

リソース モジュールを呼び出すときは、そのコンテンツをどのパスからロードするかを指定します。

どのバージョンをダウンロードするかを指定します。

そこに大量の引数を渡します。 それだけです。 このモジュールを使用するときに知っておく必要があるのはこれだけです。

最新バージョンを使用すればすべてが安定すると多くの人が考えています。 しかし、そうではありません。 インフラストラクチャはバージョン管理する必要があり、このコンポーネントまたはそのコンポーネントがどのバージョンにデプロイされたかを明確に答える必要があります。

このモジュール内のコードは次のとおりです。 セキュリティグループモジュール。 ここでスクロールは 640 行目まで進みます。 考えられるあらゆる構成で Amazon にセキュリティ グループ リソースを作成することは、非常に簡単な作業ではありません。 単にセキュリティ グループを作成し、それに渡すルールを指示するだけでは十分ではありません。 それはとても簡単なことでしょう。 Amazon 内には何百万もの異なる制限があります。 たとえば、次のように使用すると、 VPCエンドポイント、プレフィックスリスト、各種API これらすべてを他のすべてと組み合わせようとすると、Terraform ではこれを実行できません。 また、Amazon API ではこれも許可されていません。 したがって、この恐ろしいロジックをすべてモジュールに隠し、次のようなコードをユーザーに提供する必要があります。

ユーザーは内部でどのように作られているかを知る必要はありません。

リソース モジュールで構成される 0.11 番目のタイプのモジュールは、ビジネスにより適用可能な問題をすでに解決しています。 多くの場合、これは Terraform の拡張機能であり、会社の標準に合わせてタグにいくつかの厳密な値を設定する場所です。 Terraform で現在使用が許可されていない機能をそこに追加することもできます。 これが今です。 現在、バージョン XNUMX は過去のものになりつつあります。 それでも、プリプロセッサ、jsonnet、cookiecutter、その他多数のものは、本格的な作業に使用する必要がある補助メカニズムです。

次に、その例をいくつか示します。

インフラストラクチャ モジュールはまったく同じ方法で呼び出されます。

コンテンツをダウンロードするソースが示されます。

一連の値が渡され、このモジュールに渡されます。

次に、このモジュール内で、VPC または Application Load Balancer を作成するため、またはセキュリティ グループまたは Elastic Container Service クラスター用の作成するために、一連のリソース モジュールが呼び出されます。

モジュールには XNUMX 種類あります。 このレポートでグループ化した情報のほとんどはドキュメントに記載されていないため、これを理解することが重要です。

そして、現在の Terraform のドキュメントには、これらの機能があり、使用できるとだけ書かれているため、非常に問題があります。 しかし、彼女はこれらの機能の使い方や、なぜそれらを使ったほうが良いのかについては語っていません。 したがって、非常に多くの人が耐えられないことを書いています。

次に、これらのモジュールの作成方法を見てみましょう。 次に、それらを呼び出す方法とコードを操作する方法を見ていきます。

Terraform レジストリ - https://registry.terraform.io/

ヒント #0 は、リソース モジュールを作成しないことです。 これらのモジュールのほとんどはすでに作成されています。 先ほども述べたように、これらはオープンソースであり、ビジネス ロジックは含まれておらず、IP アドレスやパスワードなどのハードコードされた値もありません。このモジュールは非常に柔軟です。 そしてそれはおそらくすでに書かれているでしょう。 Amazon のリソースには多くのモジュールがあります。 約650。そのほとんどが高品質です。

この例では、誰かがあなたのところに来てこう言いました。「データベースを管理できるようになりたいです。 データベースを作成できるようにモジュールを作成してください。」 その人は Amazon や Terraform の実装の詳細を知りません。 彼は単に「MSSQL を管理したい」と言いました。 つまり、モジュールを呼び出し、そこにエンジン タイプを渡し、タイム ゾーンを示すことを意味します。

そして、このモジュール内に 0.11 つの異なるリソースを作成することを人は知らないはずです。XNUMX つは MSSQL 用、もう XNUMX つはその他すべて用です。これは、Terraform XNUMX ではタイム ゾーン値をオプションとして指定できないためです。

そして、このモジュールの終了時に、人は単にアドレスを受け取ることができます。 彼は、どのデータベース、どのリソースからこれらすべてを内部で作成しているのかを知りません。 これは隠蔽の非常に重要な要素です。 そして、これはオープンソースで公開されているモジュールだけでなく、プロジェクトやチーム内で作成するモジュールにも当てはまります。

これは XNUMX 番目の引数であり、Terraform をしばらく使用している場合には非常に重要です。 会社のすべての Terraform モジュールを配置するリポジトリがあります。 そして、時間の経過とともに、このプロジェクトのサイズが XNUMX メガバイトまたは XNUMX メガバイトに増加するのはごく普通のことです。 これで大丈夫です。

しかし、問題は、Terraform がこれらのモジュールをどのように呼び出すかです。 たとえば、モジュールを呼び出して各ユーザーを作成すると、Terraform はまずリポジトリ全体をロードし、次にその特定のモジュールが配置されているフォルダーに移動します。 この方法では、毎回 100 メガバイトをダウンロードすることになります。 200 人または 100 人のユーザーを管理している場合は、200 メガバイトまたは XNUMX メガバイトをダウンロードして、そのフォルダーに移動します。 したがって、当然のことながら、「Terraform init」を押すたびに大量のものをダウンロードする必要はありません。

https://github.com/mbtproject/mbt

この問題には XNUMX つの解決策があります。 XNUMX つ目は、相対パスを使用することです。 このようにして、コード内でフォルダーがローカル (./) であることを示します。 そして、何かを起動する前に、このリポジトリの Git クローンをローカルで作成します。 この方法なら一度で済みます。

もちろん、欠点もたくさんあります。 たとえば、バージョン管理は使用できません。 そして、これは時には生きていくのが難しいことです。

3番目の解決策。 多数のサブモジュールがあり、何らかの確立されたパイプラインがすでにある場合は、モノリポジトリからさまざまなパッケージを収集して S1.0.0 にアップロードできる MBT プロジェクトがあります。 これはとても良い方法です。 したがって、このリソースを作成するコードは非常に小さいため、iam-user-1.zip ファイルの重さはわずか XNUMX KB になります。 そして、それははるかに速く動作します。

モジュールで使用できないものについて説明しましょう。

なぜこれがモジュールに悪影響を与えるのでしょうか? 最悪なのはユーザーを想定することです。 user は、さまざまな人が使用できるプロバイダー認証オプションであると想定します。 たとえば、私たちは全員でその役割を同化します。 つまり、Terraform がこの役割を担うことになります。 そして、このロールを使用して他のアクションを実行します。

そして、問題は、Vasya がデフォルトの環境変数を使用するなど、一方の方法で Amazon に接続することを好み、Petya が秘密の場所にある共有キーを使用することを好む場合、両方を指定することはできないことです。テラフォーム。 そして、彼らが苦しみを経験しないように、モジュール内でこのブロックを示す必要はありません。 これはより高いレベルで示す必要があります。 つまり、リソース モジュール、インフラストラクチャ モジュール、およびその上にコンポジションがあります。 そして、これはどこか高いところに示されるべきです。

XNUMX番目の悪はプロビショナーです。 ここでの悪事はそれほど簡単ではありません。なぜなら、コードを書いてそれがうまく機能するのであれば、それが機能するのであれば、なぜそれを変更する必要があると考えるかもしれないからです。

問題は、まず、このプロビジョナーをいつ起動するかを常に制御できるわけではないことです。 そして第二に、aws ec2 が何を意味するのかを制御することはできません。つまり、今話しているのは Linux なのか Windows なのか。 したがって、異なるオペレーティング システムや異なるユーザー ケースでも同じように動作するものを書くことはできません。

最も一般的な例は、公式ドキュメントにも示されていますが、aws_instance を記述して多数の引数を指定した場合、そこでプロビジョナー「local-exec」を指定して ansible を実行すれば問題はありません。プレイブック。

実際、はい、それは何も問題ありません。 しかし文字通りすぐに、この local-exec というものが、たとえば launch_configuration には存在しないことに気づくでしょう。

また、launch_configuration を使用し、XNUMX つのインスタンスから自動スケーリング グループを作成する場合、launch_configuration には「プロビジョナー」の概念がありません。 「ユーザーデータ」という概念があります。

したがって、より普遍的な解決策は、ユーザー データを使用することです。 そして、インスタンスがオンになったときにインスタンス自体で起動されるか、自動スケーリング グループがこの launch_configuration を使用するときに同じユーザー データ内で起動されます。

プロビジョナーは接着コンポーネントであるため、それでもプロビジョナーを実行したい場合は、リソースが XNUMX つ作成された時点でプロビジョナー、コマンドを実行する必要があります。 そういう状況はたくさんあります。

そして、これに最も正しいリソースは null_resource と呼ばれます。 Null_resource は、実際には作成されないダミーのリソースです。 API や自動スケーリングなど、何も影響しません。 ただし、コマンドをいつ実行するかを制御できます。 この場合、コマンドは作成中に実行されます。

リンク http://bit.ly/common-traits-in-terraform-modules

いくつかの兆候があります。 すべての兆候について詳しく説明するつもりはありません。 これに関する記事があります。 しかし、Terraform を使用したり、他の人のモジュールを使用したりしたことがある場合は、オープン ソースのほとんどのコードと同様に、多くのモジュールが各自のニーズに合わせて人々によって作成されていることによく気づきます。 ある男がそれを書いて問題を解決した。 GitHub に保存して、そのままにしておきました。 それは存続しますが、そこにドキュメントやサンプルがなければ、誰もそれを使用しません。 そして、特定のタスク以外のことを解決できる機能がなければ、誰もそれを使用しません。 ユーザーを失う方法はたくさんあります。

人々に使ってもらえるように何かを書きたい場合は、次の標識に従うことをお勧めします。

彼らは以下のとおりです。

• ドキュメントと例。
• 完全な機能。
• 妥当なデフォルト。
• クリーンなコード。
• テスト。

テストは書くのが非常に難しいため、状況は異なります。 私はドキュメントと例をもっと信じています。

そこで、モジュールの書き方を検討しました。 引数は XNUMX つあります。 XNUMX つ目は、これが最も重要ですが、できることなら書かないことです。なぜなら、多くの人がすでにこれらのタスクをあなたより前に行っているからです。 次に、それでも決定する場合は、モジュールとプロビジョナーでプロバイダーを使用しないようにしてください。

これはドキュメントの灰色の部分です。 あなたは今こう考えているかもしれません。 納得いかない。」 しかし、XNUMXか月以内にわかります。

次に、これらのモジュールを呼び出す方法について説明します。

私たちはコードが時間の経過とともに増大することを理解しています。 ファイルは 20 つではなく、すでに XNUMX 個あります。 それらはすべて XNUMX つのフォルダー内にあります。 あるいは XNUMX つのフォルダーかもしれません。 おそらく、何らかの方法で地域ごと、いくつかのコンポーネントごとに分類し始めているのかもしれません。 これで、同期とオーケストレーションの基礎がいくつかできたことがわかります。 つまり、ネットワーク リソースを変更した場合に何をすべきか、残りのリソースをどうすべきか、これらの依存関係を引き起こす方法などを理解する必要があります。

両極端があります。 最初の極端な場合は、オールインワンです。 マスターファイルは XNUMX つあります。 当面は、これが Terraform Web サイトの公式ベスト プラクティスでした。

しかし、現在は非推奨として削除されていると書かれています。 時間の経過とともに、Terraform コミュニティは、人々がプロジェクトをさまざまな方法で使用し始めたため、これがベスト プラクティスとは程遠いことに気づきました。 そして問題もある。 たとえば、すべての依存関係を XNUMX か所にリストする場合です。 「Terraform プラン」をクリックすると、Terraform がすべてのリソースの状態を更新するまでにかなりの時間がかかる場合があります。

多くの時間は、たとえば 5 分です。 人によっては、これはとても長い時間です。 15分かかった例も見たことがあります。 AWS API は、各リソースの状態で何が起こっているかを把握するのに 15 分を費やしました。 これは非常に広いエリアです。

そして、当然のことながら、15 か所で何かを変更したい場合、関連する問題が表示されます。その後 0.11 分待つと、いくつかの変更を含むキャンバスが表示されます。 唾を吐き、「はい」と書いたら、何か問題が発生しました。 これは非常に現実的な例です。 Terraform は問題からユーザーを保護しようとはしません。 つまり、書きたいことを書きます。 問題はあるでしょう、あなた自身の問題です。 Terraform 0.12 は何の役にも立ちませんが。 XNUMX には、「Vasya、本当にこれが欲しいのですが、正気に戻ってくれますか?」と言うことができる興味深い場所がいくつかあります。

XNUMX 番目の方法は、この領域を減らすことです。つまり、ある場所からの通話が別の場所から接続されにくくなります。

唯一の問題は、より多くのコードを記述する必要があることです。つまり、多数のファイルに変数を記述し、これを更新する必要があります。 それを好まない人もいます。 これは私にとって普通のことです。 そして、「これを別々の場所に書く必要はない。すべてを XNUMX か所にまとめよう」と考える人もいます。 これは可能ですが、これは XNUMX 番目の極端です。

これだけのことを一か所に住んでいるのは誰ですか？ XNUMX人、XNUMX人、XNUMX人、つまり誰かが使っています。

そして、XNUMX つの特定のコンポーネント、XNUMX つのブロック、または XNUMX つのインフラストラクチャ モジュールを誰が呼ぶのでしょうか? ５人から７人くらい。 これはカッコいい。

最も一般的な答えはその中間です。 プロジェクトが大規模な場合、適切なソリューションがなく、すべてがうまくいくわけではないという状況がよくあり、最終的には混合したものになります。 両方に利点があることを理解している限り、これに問題はありません。

スタック VPC で何かが変更され、その変更を EC2 に適用したい場合、つまり、新しいサブネットがあったために自動スケーリング グループを更新したい場合、私はこの種の依存関係オーケストレーションを呼び出します。 解決策はいくつかあります。誰が何を使うのか?

どのような解決策があるかを提案できます。 Terraform を使用して魔法を実行することも、Makefile を使用して Terraform を使用することもできます。 そこで何かが変更されたかどうかを確認し、ここで起動できます。

この決定をどう思いますか? これが素晴らしい解決策だと信じる人はいますか? 笑みを浮かべているが、どうやら疑いが込み上げてきたようだ。

もちろん、家ではこれを試さないでください。 Terraform は、Terraform から実行されるように設計されていません。

ある報告では、彼らは私にこう言いました。「いいえ、これはうまくいきません。」 重要なのは、それが機能してはいけないということです。 Terraform を Terraform から起動し、次に Terraform を起動できると非常に印象的ですが、それは行わないでください。 Terraform は常に簡単に起動できるはずです。

https://github.com/gruntwork-io/terragrunt/

XNUMX か所で何かが変更されたときにオーケストレーションを呼び出す必要がある場合は、Terragrunt があります。

Terragrunt は、Terraform のアドオンであるユーティリティであり、インフラストラクチャ モジュールへの呼び出しを調整およびオーケストレーションできるようにします。

一般的な Terraform 構成ファイルは次のようになります。

呼び出す特定のモジュールを指定します。

モジュールにはどのような依存関係がありますか?

そして、このモジュールはどのような引数を受け入れますか。 Terragrunt について知っておくべきことはこれですべてです。

ドキュメントはそこにあり、GitHub には 1 のスターがあります。 しかし、ほとんどの場合、これを知っておく必要があります。 これは、Terraform の使用を開始したばかりの企業でも非常に簡単に実装できます。

つまり、オーケストレーションはTerragruntです。 他のオプションもあります。

次に、コードの操作方法について説明します。

コードに新しい機能を追加する必要がある場合、ほとんどの場合、これは簡単です。 新しいリソースを作成しているのですが、すべてが簡単です。

事前に作成したリソースがある場合 (たとえば、AWS アカウントを開設した後で Terraform について知り、すでに持っているリソースを使用したい場合)、この方法でモジュールを拡張するのが適切です。既存のリソースの使用をサポートします。

ブロックリソースを使用した新しいリソースの作成をサポートしました。

出力では、使用された内容に応じて出力 ID を常に返します。

Terraform 0.11 の XNUMX 番目の非常に重要な問題は、リストの操作です。

問題は、そのようなユーザーのリストがある場合です。

そして、ブロックリソースを使用してこれらのユーザーを作成すると、すべてがうまくいきます。 リスト全体を調べて、それぞれのファイルを作成します。 すべて順調。 次に、たとえば、真ん中にいる user3 をここから削除する必要があります。その後、インデックスが変更されるため、彼の後に作成されたすべてのリソースが再作成されます。

ステートフル環境でのリストの操作。 ステートフル環境とは何ですか? これは、このリソースが作成されるときに新しい値が作成される状況です。 たとえば、AWS アクセス キーまたは AWS 秘密キー、つまりユーザーを作成すると、新しいアクセス キーまたは秘密キーを受け取ります。 ユーザーを削除するたびに、このユーザーは新しいキーを持つことになります。 しかし、これは風水ではありません。誰かがチームを離れるたびに新しいユーザーを作成してしまうと、そのユーザーは私たちと友達になることを望まなくなるからです。

これが解決策です。 これは Jsonnet で書かれたコードです。 Jsonnet は Google のテンプレート言語です。

このコマンドを使用すると、このテンプレートを受け入れることができ、テンプレートに従って作成された json ファイルが出力として返されます。

テンプレートはこんな感じです。

Terraform では、HCL と Json の両方を同じ方法で操作できるため、Json を生成できる場合は、それを Terraform に組み込むことができます。 拡張子が .tf.json のファイルは正常にダウンロードされます。

そして、通常どおり、terraform init、terramorm apply を使用して作業します。 そして XNUMX 人のユーザーを作成します。

今では誰かがチームを離れても恐れることはありません。 json ファイルを編集するだけです。 ヴァシャ・パプキンは去り、ペティア・ピャトチキンは残った。 Petya Pyatochkin は新しいキーを受け取りません。

Terraform を他のツールと統合することは、実際には Terraform の仕事ではありません。 Terraform はリソースを作成するためのプラットフォームとして作成されました。それだけです。 そして、後で出てくることはすべて、Terraform の関心事ではありません。 そして、そこにそれを織り込む必要はありません。 必要なことはすべて実行できる Ansible があります。

しかし、Terraform を拡張し、何かが完了した後にコマンドを呼び出したい場合に状況が発生します。

最初の方法。 このコマンドを記述した場所に出力を作成します。

次に、シェルの terraform 出力からこのコマンドを呼び出し、必要な値を指定します。 したがって、コマンドはすべての置換値を使用して実行されます。 とても快適です。

XNUMX番目の方法。 これは、インフラストラクチャの変更に応じた null_resource の使用です。 リソースの ID が変更されるとすぐに、同じ local-exe を呼び出すことができます。

当然のことながら、Amazon は他の公共プロバイダーと同様、独自のエッジケースを多数抱えているため、机上ではすべてスムーズに進みます。

最も一般的なエッジケースは、AWS アカウントを開くときに、どのリージョンを使用するかが重要になるということです。 この機能はそこで有効になっていますか? おそらく 2013 年 XNUMX 月以降にオープンしたと思われます。 VPC などでデフォルトを使用している可能性があります。多くの制限があります。 そして、Amazon はそれらをドキュメント全体に散在させました。

避けるべきことがいくつかあります。

まず、Terraform プランまたは Terraform CLI 内の非シークレット引数をすべて避けます。 これらはすべて、tfvars ファイルまたは環境変数に入れることができます。

ただし、この魔法のコマンドをすべて覚える必要はありません。 Terraform 計画 – var そして出発です。 最初の変数は var、XNUMX 番目の変数は var、XNUMX 番目、XNUMX 番目の変数です。 私が最も頻繁に使用するコードとしてのインフラストラクチャの最も重要な原則は、コードを見るだけで、何がそこにどのような状態で、どのような値でデプロイされているかを明確に理解できる必要があるということです。 そのため、ドキュメントを読んだり、Vasya がクラスターの作成に使用したパラメーターを尋ねたりする必要はありません。 多くの場合環境に一致する tfvars 拡張子を持つファイルを開いて、そこにあるものをすべて確認するだけです。

また、スコープを減らすためにターゲット引数を使用しないでください。 このためには、小さなインフラストラクチャ モジュールを使用する方がはるかに簡単です。

また、並列処理を制限したり増やしたりする必要はありません。 150 のリソースがあり、Amazon の並列処理をデフォルトの 10 から 100 に増やしたい場合、おそらく何か問題が発生します。 あるいは、今はうまくいっているかもしれませんが、Amazon から電話をかけすぎていると言われたら、問題が発生するでしょう。

Terraform はこれらの問題のほとんどを再起動しようとしますが、ほとんど何も達成されません。 Parallelism=1 は、AWS API 内または Terraform プロバイダー内で何らかのバグに遭遇した場合に使用する重要なものです。 次に、Parallelism=1 を指定し、Terraform が XNUMX つの呼び出しを終了し、次に XNUMX つ目、さらに XNUMX つ目の呼び出しを完了するまで待機する必要があります。 彼はそれらを一つずつ発射します。

「なぜ Terraform ワークスペースが悪だと思うのですか?」とよく尋ねられます。 インフラストラクチャ・アズ・コードの原則は、どのようなインフラストラクチャがどのような値で作成されたかを確認することだと思います。

ワークスペースはユーザーによって作成されたものではありません。 これは、ユーザーが GitHub の問題に、Terraform ワークスペースなしでは生きていけないと書いたことを意味するものではありません。 いいえ、そうではありません。 Terraform Enterprise は商用ソリューションです。 HashiCorp の Terraform はワークスペースが必要であると判断し、ファイルに保管しました。 別のフォルダーに入れておいたほうが簡単だと思います。 その後、ファイルは少し増えますが、より明確になります。

コードをどのように操作するか? 実際、リストの操作が唯一の苦痛です。 Terraform をもっと簡単に利用できます。 これはあなたにとってすべての素晴らしいことをもたらすものではありません。 ドキュメントに書かれていることをすべてそこに押し込む必要はありません。

報告書のテーマは「未来に向けて」と書かれていました。 これについては非常に簡単に説明します。 将来的には、0.12 が間もなくリリースされることを意味します。

0.12 には新しいものがたくさんあります。 通常のプログラミングを行ってきた場合は、あらゆる種類のダイナミック ブロック、ループ、正しい条件付き比較演算 (左辺と右辺が同時に計算されるのではなく、状況に応じて計算される) を見逃してしまいます。 あなたはそれをよく見逃しているので、0.12 がそれを解決します。

しかし！ 既製のモジュールやサードパーティのソリューションを使用して、ますますシンプルに記述する場合は、待つ必要はなく、0.12 が来てすべてが修正されることを期待する必要はありません。

ご報告ありがとうございます！ あなたはコードとしてのインフラストラクチャについて話し、テストについて文字通り一言言いました。 モジュール内でテストが必要ですか? これは誰の責任ですか? 自分で書く必要があるのでしょうか、それともモジュールの責任でしょうか?

来年は、すべてをテストすることを決定したという報告でいっぱいになるでしょう。 何をテストするかが最大の問題です。 さまざまなプロバイダーからの依存関係や制限がたくさんあります。 あなたと私が話しているときに、あなたが「検査が必要です」と言ったとき、私は「何を検査しますか?」と尋ねます。 あなたはあなたの地域でテストすると言っています。 それから私は、これは私の地域では機能しないと言います。 つまり、これに関しては同意することすらできないのです。 技術的に多くの問題があることは言うまでもありません。 つまり、これらのテストを適切に作成するにはどうすればよいかということです。

私はこのトピック、つまり、作成したインフラストラクチャに基づいてテストを自動的に生成する方法を積極的に研究しています。 つまり、このコードを作成した場合は、それを実行する必要があり、これに基づいてテストを作成できます。

テラテスト は、Terraform の統合テストを作成できるようにする、最も頻繁に言及されるライブラリの XNUMX つです。 これはユーティリティの XNUMX つです。 私は、rspec などの DSL タイプを好みます。

アントンさん、報告ありがとうございます！ 私の名前はヴァレリーです。 少し哲学的な質問をさせてください。 条件付きで、プロビジョニングとデプロイメントが存在します。 プロビジョニングによってインフラストラクチャが作成され、デプロイメントでは、サーバーやアプリケーションなどの有用なものをインフラストラクチャに追加します。私の頭の中では、Terraform はプロビジョニングに適しており、Ansible はデプロイメントに適していると考えています。Ansible は物理的なインフラストラクチャにも対応しているためです。 nginx、Postgresをインストールできます。 しかし同時に、Ansible では、たとえば Amazon や Google のリソースのプロビジョニングも可能になっているようです。 ただし、Terraform では、そのモジュールを使用して一部のソフトウェアをデプロイすることもできます。 あなたの観点から見ると、Terraform と Ansible の間にある種の境界線はありますか? どこで何を使用するのがより良いでしょうか? それとも、たとえば、Ansible はすでにゴミなので、すべてに Terraform を使用する必要があると思いますか?

いい質問ですね、ヴァレリー。 Terraform の目的は 2014 年から変わっていないと思います。 インフラストラクチャのために作られ、インフラのために消滅しました。 構成管理 Ansible は今でも必要であり、今後も必要です。 課題は、launch_configuration 内にユーザー データが存在することです。 そして、そこに Ansible をプルするなどです。これが私が最も気に入っている標準的な区別です。

美しいインフラストラクチャについて話している場合は、この画像を収集する Packer のようなユーティリティがあります。 次に、Terraform はデータ ソースを使用してこのイメージを検索し、launch_configuration を更新します。 つまり、この方法では、最初に Tracker をプルし、次に Terraform をプルするパイプラインになります。 そして、ビルドが発生すると、新しい変更が発生します。

こんにちは！ ご報告ありがとうございます！ RBS社のミーシャと申します。 リソースの作成時にプロビジョナー経由で Ansible を呼び出すことができます。 Ansible には、動的インベントリーと呼ばれるトピックもあります。 そして、最初に Terraform を呼び出し、次に Ansible を呼び出すことができます。これにより、状態からリソースが取得されて実行されます。 何が良いでしょうか？

人々は両方を使用して同等の成功を収めています。 自動スケーリング グループのことを除けば、Ansible の動的インベントリは便利なもののように思えます。 自動スケーリング グループには、launch_configuration と呼ばれる独自のツールキットがすでに存在するためです。 launch_configuration では、新しいリソースを作成するときに起動する必要があるものをすべて記録します。 したがって、Amazon の場合、動的インベントリを使用して Terraform ts ファイルを読み取るのは、私の意見ではやりすぎです。 また、「自動スケーリング グループ」の概念がない他のツールを使用する場合、たとえば、自動スケーリング グループがない DigitalOcean またはその他のプロバイダーを使用する場合は、そこで API を手動でプルし、IP アドレスを検索し、作成する必要があります。動的インベントリー ファイル、Ansible はすでにそのファイル内をさまよっています。 つまり、Amazon には launch_configuration があり、その他すべてには動的在庫があります。

出所： habr.com