Terraform から CloudFormation に切り替えて後悔しました

インフラストラクチャを反復可能なテキスト形式のコードとして表現することは、マウスを操作する必要のないシステムにとってのシンプルなベスト プラクティスです。 この習慣には名前があります - コードとしてのインフラストラクチャ、これまでのところ、特に AWS では、それを実装するための XNUMX つの人気のあるツールがあります。 テラフォーム и クラウドフォーメーション.

Terraform と CloudFormation のエクスペリエンスを比較する

に来る前に Twitch （別名 アマゾンジュニア） 私は働いた XNUMX回の起動で Terraform を XNUMX 年間使用しました。 新しい場所でも、私は Terraform を全力で使いましたが、会社は CloudFormation を含む Amazon 流のすべてへの移行を推進しました。 私は両方のベスト プラクティスを熱心に開発し、非常に複雑な組織全体のワークフローで両方のツールを使用してきました。 その後、Terraform から CloudFormation への移行の影響を慎重に比較検討した結果、おそらく Terraform が組織にとって最良の選択であると確信しました。

恐ろしいテラフォーミング

ベータ版ソフトウェア

Terraform はまだバージョン 1.0 さえリリースしていないため、これを使用しないのは十分な理由です。 初めて自分で試した時からは大きく変わりましたが、当時は terraform apply 多くの場合、数回の更新後、または単に数年間の使用後に故障します。 「今は何もかもが違う」と言いたいところですが…誰もがそう言いそうですよね？ 適切ではあるものの、以前のバージョンと互換性のない変更があり、リソース ストアの構文と抽象化が今必要なものであるようにさえ感じます。 楽器は本当に良くなったように見えますが... :-0

一方で、AWS は下位互換性の維持に優れた仕事をしてきました。 これはおそらく、サービスが組織内で徹底的にテストされ、その後初めて名前が変更されて公開されることが多いためです。 したがって、「彼らは一生懸命努力した」というのは控えめな表現です。 AWS のような多様で複雑なシステムの API との下位互換性を維持することは、非常に困難です。 これほど広く使用されているパブリック API を長年にわたって維持しなければならなかった人なら、それを維持することがいかに難しいかを理解するはずです。 しかし、私の記憶では、CloudFormation の動作は何年経っても変わっていません。

足に会う...それは弾丸だ

私の知る限りでは、リソースを削除します アウトサイダー CF スタックから CloudFormation スタックを取得することはできません。 Terraform についても同様です。 これにより、既存のリソースをスタックにインポートできます。 その機能は素晴らしいとも言えますが、大きな力には大きな責任が伴います。 スタックにリソースを追加するだけで済みます。スタックの操作中は、このリソースを削除したり変更したりすることはできません。 ある日、それが裏目に出てしまった。 ある日、Twitch で、何者かが悪意を持っていないにもかかわらず、誤って他人の AWS セキュリティ グループを自分の Terraform スタックにインポートしてしまいました。 いくつかのコマンドを入力したところ、セキュリティ グループが (受信トラフィックとともに) 消えてしまいました。

テラフォームグレート

不完全な状態からの回復

CloudFormation がある状態から別の状態に完全に移行できない場合があります。 同時に、以前のものに戻ろうとします。 これが常に実現できるわけではないのは残念です。 後で何が起こったのかをデバッグするのは非常に恐ろしいことです。たとえそれを修正するためであっても、CloudFormation がハッキングされても喜ぶかどうかはわかりません。 以前の状態に戻ることが可能かどうか、彼は実際に判断する方法を知らず、デフォルトでは奇跡を待ちながら何時間もハングアップします。

一方、Terraform は失敗した移行からより適切に回復する傾向があり、高度なデバッグ ツールを提供します。

ドキュメントの状態の変化がより明確に

「わかりました、ロードバランサー、変更中です。 でもどうやって？」

—不安なエンジニア、「承諾」ボタンを押す準備ができています。

場合によっては、ポート番号の追加やセキュリティ グループの変更など、CloudFormation スタックのロード バランサで何らかの操作を行う必要があります。 ClouFormation では変更が適切に表示されません。 私は、必要なものを削除していないか、不必要なものを追加していないかを確認するために、yaml ファイルを XNUMX 回再確認します。

この点において、Terraform はより透明性が高くなります。 時々、彼は透明すぎる（つまり、迷惑な）ことさえあります。 幸いなことに、最新バージョンには変更の表示が改善されており、何が変更されているかを正確に確認できるようになりました。

柔軟性

ソフトウェアを逆方向に書きます。

端的に言えば、長寿命のソフトウェアの最も重要な特性は、変化に適応する能力です。 ソフトウェアを逆方向に記述します。 ほとんどの場合、私は「単純な」サービスを採用し、すべてを XNUMX つの CloudFormation または Terraform スタックに詰め込み始めるという間違いを犯しました。 そしてもちろん、数か月後、私の理解がすべて間違っていたことが判明し、そのサービスは実際には単純なものではありませんでした。 そして今度は、何らかの方法で大きなスタックを小さなコンポーネントに分割する必要があります。 CloudFormation を使用する場合、これは最初に既存のスタックを再作成することによってのみ行うことができますが、私はデータベースではこれを行いません。 一方、Terraform では、スタックを分析し、より理解しやすい小さな部分に分割することが可能になりました。

git のモジュール

Terraform コードを複数のスタック間で共有することは、CloudFormation コードを共有するよりもはるかに簡単です。 Terraform を使用すると、コードを git リポジトリに配置し、セマンティック バージョン管理を使用してアクセスできます。 このリポジトリにアクセスできる人は誰でも共有コードを再利用できます。 CloudFormation に相当するのは S3 ですが、同じ利点はなく、S3 を優先して git を放棄する必要がある理由はまったくありません。

組織が成長し、共通スタックを共有する機能が重要なレベルに達しました。 Terraform を使用すると、これがすべて簡単かつ自然になりますが、CloudFormation では、このような機能を実現する前に困難を乗り越える必要があります。

コードとしての操作

「スクリプトを書いてみましょう。それでOKです。」

—Terraform 自転車を発明する 3 年前のエンジニア。

ソフトウェア開発に関して言えば、Go や Java プログラムは単なるコードではありません。

コードとしてのコード

それが機能するインフラストラクチャもあります。

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

しかし、彼女はどこの出身ですか？ それを監視するにはどうすればよいですか? コードはどこに存在しますか? 開発者にはアクセス許可が必要ですか?

コードとしての操作

ソフトウェア開発者になるということは、コードを書くことだけを意味するわけではありません。

AWS だけではありません。おそらく他のプロバイダーを使用しているでしょう。 SignalFx、PagerDuty、または Github。 おそらく、CI/CD 用の内部 Jenkins サーバー、または監視用の内部 Grafana ダッシュボードがあるでしょう。 Infra as Code が選択される理由はさまざまですが、それぞれがソフトウェアに関連するすべてのものにとって同様に重要です。

私が Twitch で働いていたとき、Amazon の組み込みシステムと AWS の混合システム内のサービスを高速化しました。 私たちは多くのマイクロサービスを量産してサポートしており、運用コストが増加しました。 議論は次のようなものでした。

• Я: くそー、2 つのマイクロサービスをオーバークロックするにはたくさんのジェスチャーが必要です。 このゴミを使って AWS アカウントを作成する必要があります (私たちは XNUMX つのアカウントに行きました) マイクロサービス)、次にこれはアラートの設定用、これはコード リポジトリ用、これはメール リスト用、そしてこれは...
• 鉛: スクリプトを作成してみましょう。
• Я: わかりましたが、スクリプト自体は変更されます。 これらすべての組み込み Amazon ギズモが最新であることを確認する方法が必要になります。
• 鉛： いいですね。 そして、これのためのスクリプトを書きます。
• Я： 素晴らしい！ そして、おそらくスクリプトでパラメータを設定する必要があります。 彼はそれらを受け入れてくれるだろうか？
• 鉛: 彼にどこまでも連れて行ってもらいましょう!
• Я: プロセスが変更される可能性があり、下位互換性が失われます。 ある種のセマンティックなバージョン管理が必要になります。
• 鉛： いい案！
• Я: ツールはユーザー インターフェイス内で手動で変更できます。 これを確認して修正する方法が必要です。

…3年後：

• 鉛：そして、テラフォームを手に入れました。

この話の教訓は次のとおりです。 アマゾンのすべてにおいて真っ逆さまの場合、AWS 以外のものを依然として使用しており、これらのサービスには、設定言語を使用してその状態の同期を保つ状態があります。

CloudFormation lambda と git モジュール terraform

lambda は、カスタム ロジックの問題に対する CloudFormation のソリューションです。 ラムダを使用すると、次のことができます マクロを作成する または ユーザーリソース。 このアプローチでは、Terraform の git モジュールのセマンティック バージョニングには存在しない複雑さがさらに加わります。 私にとって、最も差し迫った問題は、これらすべてのユーザー ラムダ (これらは数十の AWS アカウント) のアクセス許可を管理することでした。 もう XNUMX つの重要な問題は、「鶏が先か、卵が先か?」という問題で、ラムダ コードに関連していました。 この機能自体はインフラストラクチャでありコードであり、それ自体の監視と更新が必要です。 最後の釘は、ラムダコードの変更を意味的に更新するのが難しいことでした。 また、直接コマンドを使用しないスタック アクションが実行間で変化しないことを確認する必要もありました。

かつて、クラシック ロード バランサーを使用して Elastic Beanstalk 環境のカナリア デプロイメントを作成したいと思ったことを思い出します。 最も簡単な方法は、実稼働環境の隣に EB の XNUMX 番目のデプロイメントを作成し、さらに一歩進んで、自動スケーリングのカナリア デプロイメント グループとデプロイメント LB を実稼働環境に結合することです。 そして、Terraform は ASG Beantalk の結論として、これには、Terraform で 4 行の追加のコードが必要になります。 CloudFormation に同等のソリューションがあるかどうか尋ねたところ、デプロイメント パイプラインなどを備えた git リポジトリ全体を教えてくれました。すべては、貧弱な 4 行の Terraform コードで実行できる何かを目的としていたのです。

ドリフトをより良く検出します

現実が期待と一致していることを確認してください。

ドリフト検出 これは、現実が期待と一致していることを確認するのに役立つため、非常に強力なコードとしての操作機能です。 CloudFormation と Terraform の両方で利用できます。 しかし、本番スタックが成長するにつれて、CloudFormation でのドリフトの検索により誤検出が増えていきました。

Terraform を使用すると、ドリフト検出のためのより高度なライフサイクル フックが利用できます。 たとえば、次のコマンドを入力すると、 無視する_変更 ECS デプロイメント全体への変更を無視せずに、特定のタスク定義への変更を無視したい場合は、ECS タスク定義内で直接実行します。

CDK と CloudFormation の将来

CloudFormation は、大規模なクロスインフラストラクチャ規模での管理が困難です。 これらの困難の多くは認識されており、ツールには次のようなものが必要です。 aws-cdk、コードでクラウド インフラストラクチャを定義し、AWS CloudFormation を通じて実行するためのフレームワークです。 aws-cdk の将来がどうなるかは興味深いところですが、Terraform の他の強みと競合するのは難しいでしょう。 CloudFormation を最新の状態にするには、グローバルな変更が必要になります。

Terraform の期待を裏切らないように

これは「コードとしてのインフラストラクチャ」であり、「テキストとして」ではありません。

Terraform に対する私の第一印象はかなり悪かったです。 ただアプローチが理解できていなかっただけだと思います。 ほとんどすべてのエンジニアは、これを目的のインフラストラクチャに変換する必要があるテキスト形式であると無意識のうちに認識します。 このような方法は行わないでください。

優れたソフトウェア開発の自明の理は、Terraform にも当てはまります。

優れたコードを作成するために採用された多くのプラクティスが、Terraform では無視されているのを見てきました。 あなたは優れたプログラマーになるために何年も勉強してきました。 Terraform を使用しているからといって、この経験を諦めないでください。 優れたソフトウェア開発の自明の理は、Terraform にも当てはまります。

コードを文書化できないのはなぜでしょうか?

まったくドキュメントのない巨大な Terraform スタックを見てきました。 ドキュメントがまったくない状態で、どのようにしてページ内にコードを記述することができるでしょうか? を説明するドキュメントを追加します。 コー​​ド Terraform (「コード」という単語を強調)、このセクションが非常に重要な理由、およびその内容。

かつては XNUMX つの大きな main() 関数だったサービスをどのようにデプロイできるでしょうか?

非常に複雑な Terraform スタックが単一のモジュールとして提示されているのを見てきました。 この方法でソフトウェアを導入してみませんか? なぜ大きな関数を小さな関数に分割するのでしょうか? 同じ答えが Terraform にも当てはまります。 モジュールが大きすぎる場合は、より小さなモジュールに分割する必要があります。

あなたの会社ではライブラリを使用していませんか?

私は、エンジニアが Terraform を使用して新しいプロジェクトを立ち上げ、他のプロジェクトの巨大な部分を愚かにも自分のプロジェクトにコピーペーストし、それが機能し始めるまでいじくり回す様子を見てきました。 あなたの会社で「戦闘」コードを使用してこのように作業しますか? 私たちは図書館だけを利用しているわけではありません。 はい、 すべてがライブラリである必要はありませんが、 しかし、原則として共有ライブラリがなければどこに行くのでしょうか?!

PEP8とかgofmtとか使ってないんですか？

ほとんどの言語には、標準で受け入れられている書式設定スキームがあります。 Python では、これは PEP8 です。 Goでは - gofmt。 Terraform には独自のものがあります。 terraform fmt。 健康のためにぜひお楽しみください！

JavaScript を知らずに React を使用しますか?

Terraform モジュールを使用すると、作成する複雑なインフラストラクチャの一部を簡素化できますが、まったくいじれないという意味ではありません。 リソースを理解せずに Terraform を正しく使用したいですか? あなたは運命にあります。時間が経っても、Terraform をマスターすることは決してできないでしょう。

シングルトンまたは依存性注入を使用してコーディングしていますか?

依存関係の注入はソフトウェア開発のベスト プラクティスとして認識されており、シングルトンよりも推奨されます。 これは Terraform でどのように役立つのでしょうか? リモート状態に依存する Terraform モジュールを見てきました。 リモート状態を取得するモジュールを作成する代わりに、パラメーターを受け取るモジュールを作成します。 そして、これらのパラメータをモジュールに渡します。

あなたのライブラリは XNUMX の優れた機能を備えていますか? それとも XNUMX つの優れた機能を備えていますか?

最もうまく機能するライブラリは、非常にうまく機能する XNUMX つのタスクに焦点を当てたライブラリです。 一度にすべてを実行しようとする大規模な Terraform モジュールを作成するのではなく、XNUMX つのことを適切に実行するモジュールの一部を構築します。 そして必要に応じてそれらを組み合わせます。

下位互換性を持たずにライブラリに変更を加えるにはどうすればよいでしょうか?

一般的な Terraform モジュールは、通常のライブラリと同様、下位互換性を持たずに何らかの方法で変更をユーザーに伝える必要があります。 このような変更がライブラリで発生するのは迷惑ですが、下位互換性のない変更が Terraform モジュールで行われる場合も同様に迷惑です。 Terraform モジュールを使用する場合は、git タグと semver を使用することをお勧めします。

実稼働サービスはラップトップ上で実行されていますか?それともデータセンターで実行されていますか?

Hashicorp には次のようなツールがあります テラフォームクラウド Terraform を実行します。 これらの一元化されたサービスにより、Terraform の変更の管理、監査、承認が簡単になります。

テストも書かないんですか？

エンジニアはコードをテストする必要があることを認識していますが、Terraform を使用する場合、エンジニア自身がテストのことを忘れてしまうことがよくあります。 インフラストラクチャにとって、これは危険な瞬間を伴います。 私のアドバイスは、CI/CD 中にテスト用に正しくデプロイできるモジュールを使用してスタックを「テスト」または「サンプルを作成」​​することです。

Terraform とマイクロサービス

マイクロサービス企業の生死は、新しいマイクロサービス ワークスタックの速度、革新性、破壊性にかかっています。

マイクロサービス アーキテクチャに関連する最も一般的なマイナス面は、コードではなく作業に関連しており、これを取り除くことはできません。 Terraform をマイクロサービス アーキテクチャのインフラストラクチャ側のみを自動化する単なる方法として考えると、システムの真の利点を逃すことになります。 今はもう すべてはコードのようなもの.

出所： habr.com