混沌と手動ルーチンに対処するための Terraform のパターン。 マキシム・コストリキン（イクテンス）

Terraform 開発者は、AWS インフラストラクチャを操作するための非常に便利なベスト プラクティスを提供しているようです。 ただニュアンスがあります。 時間の経過とともに、それぞれに独自の機能を持つ環境の数が増加します。 アプリケーション スタックのほぼコピーが隣接領域に表示されます。 そして、Terraform コードを慎重にコピーして、新しい要件に従って編集するか、スノーフレークを作成する必要があります。

大規模で長期にわたるプロジェクトにおける混乱と手動ルーチンに対処するための Terraform のパターンに関するレポートです。

ビデオ：

私は 40 歳で、IT 業界で 20 年間働いています。 私は Ixtens で 12 年間働いています。 私たちはeコマースを中心とした開発に取り組んでいます。 そして私は 5 年間 DevOps プラクティスを実践してきました。

私の話は、秘密保持契約の陰に隠れて、名前は言いませんが、ある会社でのプロジェクトでの私の経験についてになります。

プロジェクトの規模を理解するために、スライド上の数字を示します。 そして、私が次に話すことはすべてアマゾンに関連しています。

私は4年前にこのプロジェクトに参加しました。 そして、プロジェクトが成長したため、インフラストラクチャのリファクタリングが本格化しました。 そして、使用されていたパターンは適切ではなくなりました。 そして、プロジェクトの計画的な成長を考慮すると、何か新しいものを考え出す必要がありました。

昨日ドドピザで何が起こったかを教えてくれたマトベイに感謝します。 これは4年前にここで起こったことです。

開発者がやって来て、インフラストラクチャ コードを作成し始めました。

これが必要となった最も明白な理由は、市場投入までの時間でした。 展開中に DevOps チームがボトルネックにならないようにする必要がありました。 とりわけ、Terraform と Puppet は最初のレベルで使用されました。

Terraform は、HashiCorp のオープンソース プロジェクトです。 これが何なのかさえ知らない人のために、次のいくつかのスライドをご覧ください。

コードとしてのインフラストラクチャとは、インフラストラクチャを記述し、記述したリソースを確実に受け取るようにいくつかのロボットに依頼できることを意味します。

たとえば、仮想マシンが必要です。 いくつかの必須パラメーターについて説明し、追加します。

この後、コンソールで Amazon へのアクセスを設定します。 そしてTerraformプランをお願いしていきます。 Terraform プランは、「わかりました。あなたのリソースに対してこれらのことを実行できます。」と表示します。 そして、少なくとも XNUMX つのリソースが追加されます。 そして、変化は期待されません。

すべてに満足したら、Terraform に申請を依頼すると、Terraform がインスタンスを作成し、クラウドに仮想マシンを受け取ります。

私たちのプロジェクトはさらに発展しています。 そこにいくつかの変更を加えています。 さらにインスタンスを要求し、53 エントリを追加します。

そして繰り返します。 計画してください。 どのような変更が計画されているかがわかります。 申請します。 こうして私たちのインフラは成長していきます。

Terraform は状態ファイルと呼ばれるものを使用します。 つまり、Amazon に送信されるすべての変更をファイルに保存します。このファイルには、説明したリソースごとに、Amazon で作成された対応するリソースが存在します。 したがって、リソースの説明が変更されると、Terraform は Amazon で何を変更する必要があるかを正確に認識します。

これらの状態ファイルは、元々は単なるファイルでした。 そしてそれらを Git に保存しましたが、これは非常に不便でした。 誰かが常に変更をコミットするのを忘れ、多くの衝突が発生しました。

バックエンドを使用できるようになりました。つまり、Terraform をどのバケットにどのキーで状態ファイルを保存するかを指定します。 そして、Terraform 自体がこの状態ファイルの取得を処理し、すべての魔法を実行して最終結果を戻します。

私たちのインフラは成長しています。 これが私たちのコードです。 そして今、私たちは仮想マシンを作成するだけでなく、テスト環境も必要としています。

Terraform を使用すると、モジュールのようなものを作成することができます。つまり、同じものをどこかのフォルダーに記述することができます。

そして、たとえばテストでは、このモジュールを呼び出して、モジュール自体で Terraform apply を実行した場合と同じ結果を取得します。 テスト用にこのコードがあります。

本番環境では、テストでは大きなインスタンスは必要ないため、いくつかの変更をそこに送信できますが、本番環境では大きなインスタンスが役に立ちます。

そしてプロジェクトに戻ります。 計画されたインフラストラクチャは非常に大規模であり、それは困難な作業でした。 そして、このコードのメンテナンスを行う人にとっても、変更を加える人にとっても、誰にとっても便利になるように、何らかの方法ですべてのコードを配置する必要がありました。 そして、開発者は誰でも、プラットフォームの担当部分の必要に応じてインフラストラクチャを修正できるようにすることが計画されました。

これは、大規模なプロジェクトがあり、インフラストラクチャ全体をいくつかの小さな部分に分割し、各部分を別個のフォルダーに記述することが合理的である場合に、HashiCorp 自体が推奨するディレクトリ ツリーです。

リソースの広範なライブラリがあるため、テストと運用環境でほぼ同じものを呼び出すことができます。

私たちの場合、開発者またはテスト用のテスト スタックを何らかの方法で簡単に取得する必要があったため、これは完全には適切ではありませんでした。 しかし、フォルダーを調べて必要な順序で適用したり、データベースが起動し、その後このデータベースを使用するインスタンスが起動することを心配したくありませんでした。 したがって、すべてのテストは XNUMX つのフォルダーから起動されました。 そこでは同じモジュールが呼び出されていますが、すべてが XNUMX 回の実行で完了しました。

Terraform はすべての依存関係を処理します。 また、常にシーケンス内でリソースが作成されるため、たとえば新しく作成されたインスタンスから IP アドレスを取得し、この IP アドレスを Route53 レコードで取得できます。

さらに、プラットフォームは非常に大きいです。 そして、テスト スタックを起動するのは、たとえ 8 時間であっても、XNUMX 時間であっても、かなりの費用がかかる作業です。

そして私たちはこの問題を自動化しました。 そして、Jenkins ジョブによりスタックを実行できるようになりました。 その中で、開発者がテストしたい変更を含むプル リクエストを開始し、必要なオプション、コンポーネント、ディメンションをすべて指定する必要がありました。 パフォーマンス テストが必要な場合は、さらに多くのインスタンスを実行できます。 フォームが開くことを確認するだけであれば、最低賃金から始めることもできます。 また、クラスターが必要かどうかなども示します。

そして、Jenkins はシェル スクリプトをプッシュし、Terraform フォルダー内のコードをわずかに変更しました。 不要なファイルを削除し、必要なファイルを追加しました。 そして、Terraform apply を XNUMX 回実行すると、スタックが増加しました。

そして、踏みたくない他のステップがありました。

テストでは本番環境よりももう少し多くのオプションが必要だったので、モジュールのコピーを作成して、そのコピーにテストのみに必要な機能を追加する必要がありました。

そしてたまたま、テスト中に、最終的に本番環境に導入される変更をテストしたいと思うようになりました。 しかし実際には、テストされたものは XNUMX つあり、運用環境ではわずかに異なるものが使用されました。 そして、本番環境ではすべての変更が運用チームによって適用されるというパターンに小さな破綻がありました。 また、テストから本番環境に移行するはずだった変更が別のバージョンに残っていることが判明することもありました。

また、既存のサービスとは少し異なる新しいサービスが追加されるなどの問題もありました。 また、既存のモジュールを変更する代わりに、そのコピーを作成して必要な変更を追加する必要がありました。

基本的に、Terraform は実際の言語ではありません。 これは宣言です。 何かを宣言する必要がある場合は、それを宣言します。 そしてそれはすべてうまくいきます。

ある時点で、私のプル リクエストの XNUMX つが議論されていたとき、同僚の XNUMX 人が、スノーフレークを作成する必要はないと言いました。 私は彼が何を意味するのか疑問に思いました。 科学的事実として、世界に同じ雪の結晶は XNUMX つ存在せず、すべてわずかに異なります。 これを聞いてすぐに、Terraform コードの重みをすぐに感じました。 バージョン間を移行する必要がある場合、Terraform では破壊的なチェーン変更が必要でした。つまり、コードは次のバージョンと互換性がなくなったためです。 そして、インフラストラクチャを次のバージョンの Terraform に移行するには、インフラストラクチャ内のファイルのほぼ半分をカバーするプル リクエストを作成する必要がありました。

そして、そのような雪の結晶が現れた後、私たちが作成したすべての Terraform コードは、大きな大きな雪の山になりました。

操作の外部にいる外部開発者にとって、これは彼にとってあまり重要ではありません。なぜなら、彼はプル リクエストを作成し、リソースが開始されたからです。 それですべてです、それはもう彼の関心事ではありません。 そして、すべてが正常であることを確認する DevOps チームは、これらすべての変更を行う必要があります。 そして、雪片が追加されるたびに、これらの変更のコストは非常に非常に増加しました。

ゼミの学生が黒板にチョークで正円を２つ描いたという話があります。 そして先生は、コンパスなしでどうやってあんなにスムーズに絵を描くことができたのか驚いています。 学生はこう答えます。「とても簡単です。私は軍隊で XNUMX 年間肉挽き機を回していました。」

そして、このプロジェクトに関わった XNUMX 年間のうち、約 XNUMX 年間は Terraform に取り組んでいます。 そしてもちろん、Terraform コードを簡素化し、プログラミング言語のように操作し、このコードを最新の状態に保つ必要がある開発者の負担を軽減する方法について、いくつかのコツやアドバイスがあります。

まず始めたいのはシンボリックリンクです。 Terraform には繰り返しコードがたくさんあります。 たとえば、インフラストラクチャを作成するほぼすべてのポイントでのプロバイダーへの呼び出しは同じです。 そして、それを別のフォルダーに置くのが論理的です。 そして、プロバイダーがこのファイルへのシンボリックリンクを作成する必要がある場合はどこでも。

たとえば、運用環境では、何らかの外部 Amazon アカウントへのアクセス権を取得できるようにする役割を使用します。 XNUMX つのファイルを変更すると、リソース ツリー内の残りのすべてのファイルに必要な権限が与えられ、Terraform はどの Amazon セグメントにアクセスするかを認識できるようになります。

シンボリックリンクはどこで失敗するのでしょうか? 先ほども述べたように、Terraform には状態ファイルがあります。 そして、彼らはとてもとてもクールです。 ただし、問題は、Terraform が最初にバックエンドを初期化するということです。 また、これらのパラメータでは変数を使用できず、常にテキストで記述する必要があります。

その結果、誰かが新しいリソースを作成するときに、コードの一部を他のフォルダーからコピーすることになります。 そして彼は鍵やバケツを間違えるかもしれません。 たとえば、彼はサンドボックスからサンドボックスのものを作成し、それを本番環境で作成します。 そのため、本番環境のバケットがサンドボックスから使用されることが判明する可能性があります。 もちろん、彼らはすぐに見つけます。 これを何らかの方法で修正することは可能ですが、それでも時間と、ある程度はリソースの無駄です。

次に何ができるでしょうか？ Terraform を使用する前に、Terraform を初期化する必要があります。 初期化時に、Terraform はすべてのプラグインをダウンロードします。 ある時点で、モノリスからよりマイクロサービスのアーキテクチャに分かれました。 そして、すべてのモジュールとすべてのプラグインをプルアップするために、常に Terraform init を実行する必要があります。

また、シェル スクリプトを使用すると、まずすべての変数を取得できます。 シェルスクリプトにはいかなる制限もありません。 そして第二に、パスです。 リポジトリ内にあるパスを状態ファイルへのキーとして常に使用する場合、それに応じて、ここでのエラーは解消されます。

データはどこで入手できますか? JSONファイル。 Terraform を使用すると、hcl (HashiCorp 構成言語) だけでなく、JSON でもインフラストラクチャを作成できます。

JSON はシェル スクリプトから簡単に読み取ることができます。 したがって、バケット付きの設定ファイルをどこかに置くことができます。 そして、このバケットを Terraform コードと初期化用のシェル スクリプトの両方で使用します。

Terraform 用のバケットが重要なのはなぜですか? リモート状態ファイルというものがあるからです。 つまり、リソースを生成するときに、Amazon に「インスタンスを生成してください」と伝えるためには、多くの必須パラメーターを指定する必要があります。

これらの識別子は別のフォルダーに保存されます。 そして、「Terraform、そのリソースの状態ファイルにアクセスして、これらの識別子を取得してください。」と言うことができます。 したがって、異なる地域や環境の間にある種の統一性が現れます。

リモート状態ファイルを常に使用できるとは限りません。 たとえば、VPC を手動で作成したとします。 また、VPC を作成する Terraform コードはさまざまな VPC を作成するため、非常に時間がかかり、一方を他方に調整する必要があるため、次のトリックを使用できます。

つまり、VPC を作成するように見えるモジュールを作成し、いわば識別子を提供しますが、実際には、同じインスタンスの作成に使用できるハードコードされた値を含むファイルが存在するだけです。

状態ファイルをクラウドに保存する必要は必ずしもありません。 たとえば、モジュールをテストする場合、バックエンドの初期化を使用できます。この場合、ファイルはテスト時にディスクに保存されるだけです。

ここでテストについて少し説明します。 Terraform では何をテストできますか? おそらく多くのことが考えられますが、私はこの 4 つのことについて話します。

HashiCorp は、Terraform コードをどのようにフォーマットすべきかを理解しています。 そして、Terraform fmt を使用すると、この信念に従って編集するコードをフォーマットできます。 したがって、テストでは、括弧などの位置を変更する必要がないように、フォーマットが HashiCorp が遺したものに対応しているかどうかを必ずチェックする必要があります。

次はTerraformの検証です。 これは構文をチェックするだけで、すべての括弧がペアになっているかどうかをチェックします。 ここで何が重要ですか? 私たちのインフラは非常に広範囲にわたっています。 中にはいろんなパパがいます。 そして、それぞれで Terraform validate を実行する必要があります。

したがって、テストを高速化するために、パラレルを使用して複数のプロセスを並行して実行します。

パラレルは非常に優れた機能なので、ぜひ活用してください。

しかし、Terraform が初期化されるたびに、HashiCorp にアクセスして「最新のプラグインのバージョンは何ですか?」と尋ねます。 そしてキャッシュにあるプラグインは正しいものですか、それとも間違っているものですか?」 そしてこれはステップごとに遅くなりました。

プラグインの場所を Terraform に伝えると、Terraform は次のように言います。 私はどこにも行きません。すぐに Terraform コードの検証を開始します。」

必要なプラグインをフォルダーに入れるために、初期化するだけで済む非常に単純な Terraform コードがあります。 もちろん、ここではコードに何らかの形で参加しているすべてのプロバイダーを指定する必要があります。指定しないと、Terraform は「キャッシュにないため、特定のプロバイダーがわかりません」と表示します。

次にTerraform計画です。 先ほども述べたように、発展には循環があります。 コードに変更を加えます。 次に、インフラストラクチャに対してどのような変更が計画されているかを確認する必要があります。

また、インフラストラクチャが非常に大規模な場合は、XNUMX つのモジュールを変更し、テスト環境または特定の領域を修正し、隣接する領域を破壊することができます。 したがって、Terraform 計画はインフラストラクチャ全体に対して作成され、どのような変更が計画されているかを示す必要があります。

これを賢く行うことができます。 たとえば、依存関係を解決する Python スクリプトを作成しました。 そして、Terraform モジュールまたは特定のコンポーネントのみの変更内容に応じて、依存するすべてのフォルダーの計画を作成します。

Terraform プランはリクエストに応じて作成する必要があります。 少なくともそれが私たちのやっていることです。

もちろん、変更ごと、コミットごとにテストを行うのは良いことですが、計画にはかなりの費用がかかります。 そしてプルリクエストでは「計画を教えてください」と言います。 ロボットが起動します。 そして、コメントを送信するか、変更から予想されるすべての計画を添付してください。

プランというのはかなりお金がかかるものです。 Terraform が Amazon に行き、「このインスタンスはまだ存在しますか?」と尋ねるため、時間がかかります。 この自動スケールにはまったく同じパラメータがありますか?」 これを高速化するために、refresh=false などのパラメータを使用できます。 これは、Terraform が S3 から状態をダウンロードすることを意味します。 そして、その状態が Amazon にあるものと正確に一致すると信じます。

このような Terraform 計画ははるかに高速に実行されますが、状態はインフラストラクチャに対応している必要があります。つまり、どこかで、いつか Terraform の更新を開始する必要があります。 Terraform の更新はまさにそれを行います。つまり、状態が実際のインフラストラクチャ内の内容と一致します。

そして安全性についても話し合う必要があります。 ここから始めなければなりませんでした。 Terraform を実行する場合、および Terraform がインフラストラクチャ上で実行される場合には、脆弱性が存在します。 つまり、実質的にコードを実行していることになります。 また、プル リクエストに何らかの悪意のあるコードが含まれている場合、アクセスが多すぎるインフラストラクチャ上で実行される可能性があります。 したがって、Terraform プランを実行する場所には注意してください。

次にお話したいのは、ユーザーデータのテストについてです。

ユーザーデータとは何ですか? Amazon では、インスタンスを作成するときに、インスタンスに特定のレター (メタデータ) を送信できます。 インスタンスが起動すると、通常、cloud init は常にこれらのインスタンスに存在します。 Cloud init はこの手紙を読み、「わかりました。今日は私がロード バランサーです。」と言います。 そしてこれらの契約に従って、彼はいくつかの行動を実行します。

しかし、残念なことに、Terraform 計画を立てて Terraform を適用すると、ユーザー データはこのようなドロドロした数値のようになります。 つまり、彼は単にハッシュを送信するだけです。 そして、計画で確認できるのは、変更があるかどうか、またはハッシュが同じままであるかどうかだけです。

これに注意を払わないと、壊れたテキスト ファイルが Amazon の実際のインフラストラクチャ上に置かれてしまう可能性があります。

あるいは、実行時にインフラストラクチャ全体ではなく、テンプレートのみを指定することもできます。 そして、コード内で「このテンプレートを画面に表示してください」と記述します。 その結果、Amazon でデータがどのように表示されるかを印刷することができます。

もう XNUMX つのオプションは、モジュールを使用してユーザー データを生成することです。 このモジュールを適用します。 ファイルをディスク上で受け取ります。 参考資料と比べてみましょう。 したがって、誰かがユーザーデータを少し修正することを決定した場合、テストでは「OK、あちこちに変更があります。これは正常です」と表示されます。

次にお話したいのは、Terraform 適用の自動化についてです。

もちろん、Terraform を自動的に適用するのは非常に恐ろしいことです。なぜなら、そこにどのような変更が加えられ、それが生活インフラにどれほど破壊的な影響を与えるかは誰にも分からないからです。

テスト環境では、これはすべて正常です。 つまり、テスト環境を作成する仕事は、すべての開発者に必要なものです。 そして、「すべてがうまくいきました」などの表現は面白いミームではなく、ある人が混乱してスタックを上げ、このスタックでいくつかのテストを実行したことの証拠です。 そして彼は、すべてが正常であることを確認して、「わかりました。私がリリースするコードはテストされました。」と言いました。

実稼働環境、サンドボックス環境、その他のビジネスクリティカルな環境では、誰かが死ぬことはないため、一部のリソースを部分的に非常に安全に使用できます。 これらは、自動スケール グループ、セキュリティ グループ、ロール、route53 であり、そのリストは非常に大きくなる可能性があります。 ただし、何が起こっているかに注意し、自動化されたアプリケーション レポートを読んでください。

適用するのが危険または恐ろしい場合、たとえば、これらがデータベースの永続リソースである場合、インフラストラクチャの一部に適用されていない変更があるというレポートを受け取ります。 そして、エンジニアは監督の下で、適用するジョブを開始するか、コンソールからそれを実行します。

Amazon には終了保護のようなものがあります。 また、場合によっては、必要のない変更から保護することもできます。 つまり、Terraform は Amazon に行き、「別のインスタンスを作成するには、このインスタンスを強制終了する必要があります。」と言いました。 するとアマゾンはこう言った。「申し訳ありませんが、今日はだめです。 私たちは終了保護を持っています。」

さらに重要なのは、コードの最適化です。 Terraform コードを使用する場合、非常に多くのパラメーターをモジュールに渡す必要があります。 これらは、ある種のリソースを作成するために必要なパラメータです。 そして、特にモジュールがネストされている場合、コードは、モジュールからモジュール、モジュールからモジュールに渡す必要があるパラメータの大きなリストになります。

そしてとても読みにくいです。 これをレビューするのは非常に困難です。 そして、一部のパラメータが見直しを受け、それらがまさに必要なものではないことが判明することがよくあります。 そして、これを後で修正するには時間とお金がかかります。

したがって、特定の値のツリーを含む複雑なパラメーターとしてこのようなものを使用することをお勧めします。 つまり、ある環境に必要なすべての値が含まれるある種のフォルダーが必要です。

そして、このモジュールを呼び出すことで、XNUMX つの共通モジュール、つまりインフラストラクチャ全体で同じように動作する共通モジュールで生成されたツリーを取得できます。

このモジュールでは、Terraform の最近の機能をローカルとして使用して、いくつかの計算を実行できます。 次に、XNUMX つの出力で、配列ハッシュなどが含まれる可能性のある複雑なパラメーターを指定します。

これで私の最高の発見はすべて終わりました。 そしてコロンブスについての話をしたいと思います。 彼がインドを発見するための遠征費を探していたとき（当時彼はそう思っていた）、誰も彼のことを信じず、それは不可能だと思われました。 それから彼は、「卵が落ちないように注意してください。」と言いました。 銀行家たちは皆、大金持ちでおそらく賢い人たちで、なんとか卵を置こうとしたが、卵は落ち続けた。 それからコロンブスは卵を取り、少し押しました。 殻はくしゃくしゃになり、卵は動かなかった。 彼らは「ああ、それは簡単すぎる！」と言った。 するとコロンブスはこう答えました。 そして私がインドを開くと、誰もがこの貿易ルートを利用するでしょう。」

そして、私が今お話したことは、おそらく非常に単純で些細なことです。 そして、それらについて学び、使い始めると、物事は順調に進みます。 ぜひご利用ください。 そして、これらがあなたにとってまったく普通のことであるなら、あなたは少なくとも卵が落ちないように卵を置く方法を知っています。

まとめてみましょう：

• 雪の結晶を避けるようにしてください。 また、雪の結晶が少ないほど、大規模なインフラストラクチャ全体に変更を加えるために必要なリソースが少なくなります。
• 絶え間ない変化。 つまり、コードに何らかの変更が発生した場合、できるだけ早くインフラストラクチャをこれらの変更に準拠させる必要があります。 誰かが XNUMX ～ XNUMX か月後に Elasticsearch を調べに来て Terraform 計画を立てたところ、予想外の変更が数多く発生するという状況はあってはならないはずです。 そして、すべてを元の状態に戻すには、非常に時間がかかります。
• テストと自動化。 コードがテストや機能でカバーされるほど、すべてが正しく行われているという自信が高まります。 また、自動配信はあなたの信頼を何倍にも高めます。
• テスト環境と運用環境のコードはほぼ同じである必要があります。 実際には、本番環境はまだ少し異なり、テスト環境を超えたニュアンスがまだいくつかあるためです。 しかし、それでも、プラスかマイナスかにかかわらず、これは確保できます。
• また、大量の Terraform コードがあり、このコードを最新の状態に保つのに時間がかかる場合でも、リファクタリングして適切な状態にするのに遅すぎるということはありません。

• 不変のインフラストラクチャ。 AMI は予定どおり配信されます。
• 多数のエントリがあり、それらを一貫した順序にしたい場合の、route53 の構造。
• API レート制限との戦い。 このとき、Amazon は「以上です。これ以上のリクエストは受け付けられません。お待ちください。」と言います。 そして、オフィスの半分はインフラストラクチャを立ち上げるまで待っています。
• スポットインスタンス。 Amazon は決して安いイベントではありませんが、スポットを利用するとかなりの金額を節約できます。 そしてそこで、それに関するレポート全体を伝えることができます。
• セキュリティと IAM の役割。
• 失われたリソースを探していると、アマゾンに起源不明のインスタンスが存在すると、お金を食べてしまいます。 インスタンスの費用が月額 100 ～ 150 ドルだとしても、年間では 1 ドルを超えます。 そのようなリソースを見つけることは収益性の高いビジネスです。
• そして予約されたインスタンス。

以上です。 Terraform はとてもクールなので、ぜひ使ってみてください。 ありがとう！

質問

ご報告ありがとうございます！ 状態ファイルは S3 にありますが、複数の人がこの状態ファイルを取得して拡張しようとする可能性がある問題をどのように解決しますか?

まず第一に、私たちは急いでいません。 XNUMX 番目に、コードの一部に取り組んでいることを報告するフラグがあります。 つまり、インフラストラクチャが非常に大規模であるという事実にもかかわらず、誰かが常に何かを使用しているという意味ではありません。 アクティブなフェーズがある場合、これが問題でした。状態ファイルは Git に保存されていました。 これは重要でした。そうしないと誰かが状態ファイルを作成してしまい、すべてを続行するには手動で状態ファイルをまとめる必要がありました。 今ではそのような問題はありません。 一般に、Terraform はこの問題を解決しました。 何かが常に変化している場合は、ロックを使用して、発言した内容を防ぐことができます。

オープンソースを使用していますか? それともエンタープライズを使用していますか?

エンタープライズではありません。つまり、すべてを無料でダウンロードできます。

私の名前はスタニスラフです。 ちょっとした追加を加えたかったのです。 インスタンスを強制終了できないようにする Amazon の機能について話しました。 これは Terraform 自体にもあり、Life Second ブロックでは変更の禁止または破壊の禁止を指定できます。

時間は限られていました。 いい視点ね。

私も二つ聞きたいことがありました。 まず最初にテストについてお話しました。 何かテストツールを使用しましたか? Test Kitchen プラグインについて聞きました。 おそらく、さらに何かがあるでしょう。 それから、ローカルバリューについてもお伺いしたいと思います。 これらは入力変数と根本的にどう違うのでしょうか? また、ローカル値を介してのみパラメータ化できないのはなぜでしょうか? このトピックについて理解しようとしましたが、どういうわけか自分では理解できませんでした。

この部屋の外でもっと詳しく話すことができます。 私たちのテストツールは完全に自作です。 そこにはテストするものは何もありません。 一般に、自動テストがどこかのインフラストラクチャを検出し、それが正常であることを確認してから、インフラストラクチャがまだ良好な状態にあるというレポートを表示してすべてを破棄する場合、オプションがあります。 テストスタックは毎日実行されるため、これはありません。 それで十分です。 そして、何かが壊れ始めたら、私たちがどこかで確認することなく壊れ始めます。

Local Values については、部屋の外で会話を続けましょう。

こんにちは！ ご報告ありがとうございます！ とても有益です。 インフラストラクチャを記述するために同じ種類のコードが多数あるとおっしゃいました。 このコードを生成することを検討しましたか?

素晴らしい質問です、ありがとう！ 重要なのは、インフラストラクチャをコードとして使用するときは、コードを見て、そのコードの背後にどのようなインフラストラクチャがあるかを理解していると想定しているということです。 コードが生成される場合、どのようなインフラストラクチャがあるかを理解するには、どのようなコードが生成されるかを想像する必要があります。 コードを生成してコミットしても、本質的には同じことが起こります。 それで、私たちが書いた道をたどって、それを見つけました。 さらに、発電機は私たちが作り始めた少し後に登場しました。 そして、変えるにはすでに遅すぎました。

jsonnetについて何か聞いたことがありますか?

いいえ。

見てください、これはとても素晴らしいことです。 これを適用してデータ構造を生成できる具体的なケースがわかりました。

シェービングマシンのジョークにあるように、発電機はあると便利です。 つまり、最初は顔が違いますが、その後は全員が同じ顔になります。 発電機は非常にうまく機能します。 しかし、残念なことに、私たちの顔は少し異なります。 これは問題です。

ちょっと見てください。 ありがとう！

私の名前はマキシム、ズベルバンク出身です。 Terraform をプログラミング言語と同等のものにしようとしていることについて少し話しました。 Ansibleを使ったほうが簡単ではないでしょうか？

これらは全く異なるものです。 Ansible でリソースを作成でき、Puppet は Amazon でリソースを作成できます。 しかし、Terraform は徹底的に研ぎ澄まされています。

アマゾンしかないんですか？

Amazonしかないわけではありません。 ほぼAmazonしかありません。 しかし重要な機能は、Terraform が記憶していることです。 Ansible では、「インスタンスを 5 つください」と言うと、インスタンスが呼び出され、「そして今、3 つ必要です」と言います。 そして、Terraform は「わかりました、2 つ削除します」と言い、Ansible は「わかりました、3 つあげます」と言います。 合計8個。

こんにちは！ ご報告ありがとうございます！ Terraform について聞くのはとても興味深かったです。 Terraform にはまだ安定リリースがないため、Terraform の取り扱いには十分な注意が必要であるという事実について、すぐに少しコメントしたいと思います。

夕食にぴったりのスプーンです。 つまり、解決策が必要な場合、不安定なものなどを後回しにすることがありますが、それはうまく機能し、私たちを助けてくれました。

質問はこれです。 リモート バックエンドを使用し、S 3 を使用します。なぜ公式バックエンドを使用しないのですか?

正式？

テラフォームクラウド。

彼はいつ現れましたか?

約4ヶ月前。

もしそれが 4 年前に登場していたら、私はおそらくあなたの質問に答えていたでしょう。

すでに組み込み関数とロックがあり、状態ファイルを保存できます。 試してみる。 しかし、私もテストしていません。

私たちは高速で移動する大きな電車に乗っています。 そして、数台の車をただ取り出して捨てることはできません。

雪の結晶について話しましたが、なぜ枝を使わなかったのですか? なぜそのようにうまくいかなかったのでしょうか？

私たちのアプローチは、インフラストラクチャ全体が XNUMX つのリポジトリ内にあるというものです。 Terraform、Puppet、これに何らかの形で関連するすべてのスクリプトは、すべて XNUMX つのリポジトリにあります。 このようにして、増分変更を次々にテストすることができます。 多数のブランチの場合、そのようなプロジェクトを維持するのはほぼ不可能になります。 半年が経ち、二人の意見は大きく乖離し、それはただの罰としか思えない。 これは、リファクタリングする前に回避したかったことです。

それでうまくいかないのですか？

これはまったく機能しません。

ブランチではフォルダーのスライドを切り出しました。 つまり、テスト スタックごとにこれを行う場合、たとえばチーム A には独自のフォルダーがあり、チーム B には独自のフォルダーがある場合、これも機能しません。 私たちは、誰もが満足できる柔軟性を備えた統合テスト環境コードを作成しました。 つまり、XNUMX つのコードを提供しました。

こんにちは！ 私の名前はユラです！ ご報告ありがとうございます！ モジュールについての質問です。 モジュールを使用していると言います。 あるモジュールに別の人の変更と互換性のない変更が加えられた場合、問題をどのように解決しますか? 何らかの方法でモジュールをバージョン管理しているのでしょうか、それとも XNUMX つの要件を満たすために素晴らしいワッフルを導入しようとしているのでしょうか?

これは大きな積雪の問題です。 これは、無害な変更によってインフラストラクチャの一部が破壊される可能性があるときに、私たちが悩まされることです。 そして、これはしばらく経ってから初めて顕著になります。

つまり、まだ解決していないということですか？

ユニバーサルモジュールを作成します。 雪片を避けてください。 そしてすべてがうまくいくでしょう。 レポートの後半では、これを回避する方法について説明します。

こんにちは！ ご報告ありがとうございます！ 明確にしておきたいと思います。 舞台裏には私が来た大きな山がありました。 Puppet と役割分散はどのように統合されますか?

ユーザーデータ。

つまり、ファイルを吐き出して何らかの方法で実行するだけですか？

ユーザーデータはメモです。つまり、イメージのクローンを作成すると、デーモンがそこに立ち上がり、自分が誰であるかを理解しようとして、自分がロードバランサーであるというメモを読みます。

つまり、これは別のプロセスが提供されるのでしょうか?

私たちが発明したわけではありません。 私たちはそれを使っています。

こんにちは！ ユーザーデータについて質問があります。 そこには問題があり、誰かが間違った場所に何かを送信する可能性があるとあなたは言いました。 ユーザーデータが何を参照しているのかを常に明確にするために、同じ Git にユーザーデータを保存する方法はありますか?

テンプレートからユーザーデータを生成します。 つまり、そこでは一定数の変数が使用されます。 そして、Terraform が最終結果を生成します。 したがって、テンプレートを見て何が起こるかを言うことはできません。すべての問題は、開発者がこの変数に文字列を渡していると考えているのに、そこでは配列が使用されているという事実に関連しているからです。 そして彼は、バムと私は、誰々、誰々、次の行で、すべてが壊れました。 これが新しいリソースであり、人がそれを手に取り、何かが機能していないことに気付いた場合、それはすぐに解決されます。 この自動スケール グループが更新されると、ある時点で自動スケール グループ内のインスタンスが置き換えられ始めます。 そして、何かがうまくいきません。 それは痛い。

唯一の解決策はテストすることだと判明しましたか?

はい、問題が見つかったので、そこにテスト ステップを追加します。 つまり、出力をテストすることもできます。 あまり便利ではないかもしれませんが、いくつかのマークを付けることもできます。ユーザーデータがここに固定されていることを確認してください。

私の名前はティムールです。 Terraform を適切に整理する方法に関するレポートがあるのは非常に素晴らしいことです。

始まってもいないのに。

おそらく次回のカンファレンスでも開催されると思います。 素朴な疑問があります。 なぜ tfvars を使用せずに別のモジュールで値をハードコーディングしているのですか。つまり、値を持つモジュールが tfvars よりも優れているのはなぜですか?

つまり、ここ (スライド: Production/environment/settings.tf) に次のように記述する必要があります。domain = variable、domain vpcnetwork、variable vpcnetwork、stvars – 同じものを取得できますか?

まさにそれが私たちのやっていることです。 たとえば、設定ソースモジュールを参照します。

本質的に、これはそのような tfvars です。 Tfvars はテスト環境で非常に便利です。 大規模なインスタンス用と小規模なインスタンス用の tfvars があります。 そして、そのフォルダーにファイルを XNUMX つ放り込みました。 そして、欲しかったものを手に入れました。 インフラストラクチャを切断するときは、すべてを見てすぐに理解できるようにしたいと考えています。 したがって、ここを見てから tfvars を確認する必要があることがわかりました。

すべてを XNUMX か所にまとめることは可能ですか?

はい、tfvars はコードが XNUMX つの場合です。 そして、さまざまな場所で異なるニュアンスで使用されます。 次に、tfvars をスローしてニュアンスを取得します。 そして、私たちは最も純粋な形のコードとしてのインフラストラクチャです。 見て理解しました。

こんにちは！ Terraform の作成にクラウド プロバイダーが干渉する状況に遭遇したことがありますか? メタデータを編集するとします。 SSHキーがあります。 そして Google は常にメタデータとキーをそこに置きます。 そして、Terraform は常に変更があることを書き込みます。 実行するたびに、たとえ何も変化がなかったとしても、彼は常にこのフィールドを今すぐ更新すると言います。

キーを使用しますが、はい、インフラストラクチャの一部がこれによって影響を受けます。つまり、Terraform は何も変更できません。 私たちの手では何も変えることはできません。 今のところはそれで生きていきます。

つまり、このようなことに遭遇しましたが、何も思いつきませんでした。彼はどうやってそれを行い、自分でそれを行いますか？

残念ながらそうです。

こんにちは！ 私の名前はスターコフ・スタニスラフです。 郵便。 るグループ。 ... でタグを生成する問題をどのように解決しますか?、それを内部に渡すにはどうすればよいですか? 私の理解では、User - data を通じてホスト名を指定し、Puppet をオンに設定しますか? そして質問の後半部分。 SG でこの問題をどのように解決しますか。つまり、SG を生成するとき、同じタイプのインスタンスが何百も生成される場合、それらの正しい名前は何ですか?

私たちにとって非常に重要なインスタンスには、美しい名前を付けます。 必要のないものには、これが自動スケール グループであるという注記があります。 そして理論的には、問題を解決して新しいものを入手することができます。

タグの問題については、そんな問題はないのですが、そういう作業があります。 また、インフラストラクチャは大規模で高価であるため、私たちはタグを非常に頻繁に使用します。 そして、お金がどこに使われたのかを確認する必要があるため、タグを使用すると、何がどこに使われたのかを細分化できます。 そして、それに応じて、ここでは多額のお金が費やされることを意味するものの検索が行われます。

他にどんな質問がありましたか?

SG が何百ものインスタンスを作成する場合、それらを何らかの方法で区別する必要がありますか?

いいえ、やめてください。 各インスタンスには、問題があることを報告するエージェントがいます。 エージェントが報告した場合、エージェントはその人のことを知っており、少なくとも彼の IP アドレスが存在することになります。 もう逃げてもいいよ。 次に、Discovery には Consul を使用しますが、Kubernetes は使用しません。 また、Consul にはインスタンスの IP アドレスも表示されます。

つまり、ホスト名ではなく、IP に特に焦点を当てていますか?

ホスト名でナビゲートすることは不可能です。つまり、ホスト名が多数あります。 AE などのインスタンス識別子があります。それはどこかで見つけることができ、検索に投入できます。

こんにちは！ Terraform はクラウドに合わせて調整されている優れものであることに気づきました。

だけでなく、

これはまさに私が興味を持っている質問です。 たとえば、すべてのインスタンスをまとめて Bare Metal に移行することにした場合はどうでしょうか? 問題がありますか？ それとも、ここで説明したのと同じ Ansible など、他の製品を引き続き使用する必要がありますか?

Ansible は少し別のものです。 つまり、インスタンスが開始された時点で Ansible はすでに動作しています。 そして、Terraform はインスタンスが開始される前に動作します。 ベアメタルへの切り替え - いいえ。

今はそうではありませんが、ビジネスがやって来て「さあ」と言うでしょう。

別のクラウドに切り替える – はい、ただし、ここには少し異なるトリックがあります。 より少ない労力で他のクラウドに切り替えることができるような方法で Terraform コードを作成する必要があります。

当初、当社のインフラストラクチャ全体が不可知論的である、つまり、どのクラウドも適しているという課題が設定されていましたが、ある時点で企業は諦めてこう言いました。アマゾンから」

Terraform を使用すると、フロントエンド ジョブの作成、PagerDuty、データ ドキュメントなどの構成が可能になります。これには多くのテールがあります。 彼は実質的に全世界を支配することができます。

ご報告ありがとうございます！ 私も Terraform を 4 年間使用しています。 Terraform、インフラストラクチャ、宣言的記述へのスムーズな移行の段階で、誰かが手作業で何かを行っており、計画を立てようとしている状況に直面しました。 そして、そこで何らかのエラーが発生しました。 このような問題にはどのように対処しますか? リストに記載されている紛失したリソースをどのように見つけますか?

主に手と目を使って、レポートに何か奇妙なものを見つけたら、そこで何が起こっているのかを分析するか、単に殺すだけです。 一般に、プル リクエストは一般的なものです。

エラーが出たらロールバックするんですか？ これをやってみましたか？

いいえ、これは問題を見たときのその人の決断です。

出所： habr.com