Terraform:自動化の実践 - トップ開発者の例

以下のトランスクリプトを参照してください。

こんにちは、Alibaba Cloud オープン プラットフォーム自動化シリーズ AutoTalk へようこそ。今回のエピソードでは、トップ自動化開発者のケーススタディを紹介します。Alibaba Cloud オープン プラットフォームの Tiankai です。始める前に、インフラストラクチャの自動化を追求する理由と、インフラストラクチャの自動化とは何かを再確認しましょう。まず、2 つの核となる概念を紹介します。1 つ目は、インフラストラクチャの自動化とは、本質的にビジネスと反復的なタスクをさまざまなツールを通じてコードに変換し、マシンがこれらのタスクをより効率的かつ標準化された方法で実行できるようにすることです。2 つ目は、このプロセスにおいて、ツールの選択に関しては多くの選択肢があるということです。API、SDK、クラウド制御 API、または Terraform や ROS のようなツールを使用するかにかかわらず、最終的な目標は、組織がニーズに合った適切な技術スタックとソリューションを採用し、コードとしてのインフラストラクチャ (IaC) を実装し、効率を向上させることです。この図は、IaC の全体像を表しています。ただし、今日のトピックはトップ開発者に焦点を当てているため、組織のコラボレーション、プロセス、バージョン管理、コード管理に関する議論は脇に置いておきます。代わりに、独立した運用エンジニアまたは SRE として、自動化ツールを使用して個々の課題を解決できるかどうかについて詳しく見ていきます。組織の問題については、後で別のビデオで説明します。したがって、赤い枠で強調表示されているのは、例として使用する Terraform など、特定のツールを介して一連の IaC コードを活用することを指します。日々の運用で発生する一般的なシナリオを探ります。

技術的なシナリオについて議論する場合、誰もが日々の業務でさまざまな課題に直面していると信じています。トップ開発者の効率を向上させるために、重要な責任を個別に管理するすべての SRE または運用エンジニアにより良い技術サポートを提供することを目指しています。このようにして、彼らはより効率的かつ標準化され、より興味深いプロジェクトに取り組むための時間を確保できます。

シナリオについて言えば、ここにいくつかの典型的な例があります。1 つ目はサービスのアクティベーションです。ご存知のように、新しい Alibaba Cloud アカウントを作成してサービスを購入する場合、最初にサービスをアクティベートする必要があります。一部のサービスは、購入して使用する前にアクティベーションが必要です。これらのシナリオは、組織内では、プロジェクトのセットアップや従業員のオンボーディングなどの状況に対応しており、個人が手動でサービスをステップバイステップでアクティベートする必要があることがよくあります。このプロセスは実際には非常に簡単に自動化できます。後で例を詳しく見ていきます。

2 つ目のシナリオはアクセスの制御です。アクセスの制御は、従業員の権限の期間と、自動化された権限構成によって、メンテナンス、ビジネス、運用などのさまざまな役割を持つ従業員が組織に参加するとすぐに適切な権限が自動的に付与される方法に対処します。3 番目と 4 番目のシナリオは、クラウド インフラストラクチャに焦点を当てています。インフラストラクチャを迅速に構築できますか? これは自動化の主な目標の 1 つです。5 番目のシナリオは DevOps です。インフラストラクチャがデプロイされた後、DevOps プロセスを連携させてアプリケーションをインフラストラクチャにデプロイできますか? これにより、インフラストラクチャ層からアプリケーション層へのエンドツーエンドの自動化変換が可能になり、配信と変更の効率がさらに向上します。

それでは、最初のシナリオである新しいアカウントのサービスのアクティベートを見てみましょう。このシナリオは、Alibaba Cloud で新しいアカウントを作成する必要がある組織内の状況を指します。前述のように、特定のサービスは、Alibaba Cloud で購入して使用する前にアクティベートする必要があります。典型的なシナリオには、新しい従業員のオンボーディング、新しいビジネス ラインの立ち上げ、新しい部門の設立などがあり、これらはすべて新しいアカウントの作成が必要になる場合があります。

運用チームがこれらのアカウントをビジネスチームに引き渡す前に、これらのアカウントは適切に準備されていますか? 理想的には、ビジネスチームはサービスのアクティベーションなどの前処理手順について心配したり、処理したりする必要はありません。代わりに、アカウントはビジネス運用ですぐに使用できる状態になっている必要があります。私たちの目標は次のとおりです。運用チームの一員である場合、自動化を活用してこれらのタスクをコード化したいと考えています。各アカウントのコンソールをクリックして、プロセスを数十回繰り返したくありません。それは面倒で非効率的です。さらに、この手動プロセスでは、過剰な権限を付与したり、不要なサービスをアクティベートしたり、必要なサービスのアクティベートを逃したり、間違ったサービスをアクティベートしたりすることがあります。これらのミスは手戻りにつながり、効率をさらに低下させます。

一緒に例を見てみましょう。Terraform は実際には非常に便利なツールです。Alibaba Cloud のお客様に、新しいアカウントのバッチ アクティベーション専用に構築されたモジュールを提供します。この Terraform モジュールは GitHub リポジトリにあります。多くの変更を加えることなく、コードをローカル環境に適応させることができます。

まずコードをプルダウンしてみましょう。一緒に詳しく見ていきましょう。examples フォルダには、main ファイル、outputs ファイル、variables ファイルがあります。outputs ファイルには、アクティベートするサービスを表す変数のリストが表示されます。サービスが必要ない場合は、コメントアウトするだけです。たとえば、このデモでは、これら 2 つのサービスをアクティベートする必要がない場合は、コメントアウトします。残りが「on」とマークされている場合は、アカウント アクティベーションのベースラインの一部として残します。このようにして、新しいアカウントが作成されるたびに、このスクリプトを実行すると、そのアカウントに必要なサービスが自動的にアクティベートされます。

これはデモ環境であるため、AccessKey ペアを使用しています。AccessKey ペアをコピーします。ただし、これは単なるデモであることを強調することが重要です。実際のアプリケーションと本番環境では、ファイル内に AccessKey ペアをプレーンテキストで保存することは強くお勧めしません。代わりに、ローカル キャッシング、ランタイム環境変数、または AccessKey ペア管理サービスを使用して、AccessKey ペアをより効果的に保護し、定期的なキーのローテーションを管理できます。それでは、init フェーズに移りましょう。このプロセス中に、小さなミスをしました。プロバイダー ファイルを保存するのを忘れたため、ファイルが見つからないというエラーが発生しました。これを早送りします。プロバイダー ファイルを保存した後、コマンドをもう一度実行します。

これでプレビュー結果が表示されます。Terraform は plan コマンドと apply コマンドをサポートしているため、プレビュー フェーズでは、どのサービスがアクティベートされるかを確認できます。次に、apply コマンドを実行して、現在のアカウントでこれらのサービスをアクティベートします。ご覧のとおり、サービスがアクティベートされています。プロセス全体は非常にシンプルで、軽量な方法で実装されています。

2 つ目のシナリオは、自動化を使用してクラウド インフラストラクチャを迅速に作成することです。ご存知のように、クラウド時代では、インフラストラクチャの相互作用の効率が急速に向上しています。インターネット ビジネス、ゲーム ビジネス、特定の専門ビジネスでは、市場の変化が速いため、配信時間の短縮に対する需要が高まっています。

このシナリオでは、ビジネスチームは運用チームに 2 週間ごとに環境を作成する必要があります。テストが完了したら、環境を速やかにリリースする必要があります。次に、次の 2 週間のサイクルで、環境を再作成する必要があります。自動化がないと、環境の頻繁な削除と再構成は運用チームにとって非常に苦痛な場合があります。さらに、複数のビジネスチームが同時に環境をリクエストすると、非常にイライラする運用エクスペリエンスになります。運用チームは迅速な配信だけでなく、ベースラインの精度の向上も期待しています。

運用エンジニアとして、このタスクが自分の肩にかかっている場合、どうしますか? このシナリオでは、運用チームが日々のアーキテクチャを体系的に整理することを期待しています。たとえば、ECS、インターネット向け SLB インスタンス、VPC、セキュリティグループ、Auto Scaling などのよく使用されるサービスはすべて、自動化されたコードに変換できます。一緒にコードを見てみましょう。

このシナリオでは、運用チームはビジネスチームに、VPC、vSwitch、セキュリティグループ、およびインバウンド ポリシーを含む一連のコードを提供しています。パブリック IP アドレスが割り当てられ、ポート 8080 がアプリケーションをデプロイするために開かれています。この時点で、環境の構成は半分完了しています。次に、Auto Scaling グループを構成し、そのルールを定義します。これを完了した後、Auto Scaling に「hello world」アプリケーションをデプロイします。見てみましょう。まず、Terraform init コマンドを実行します。Terraform が環境を初期化したら、Terraform にインフラストラクチャを構築させます。プレビュー フェーズでは、9 つのリソースが作成されることがわかります。これら 9 つのリソースは何ですか?

コマンドを実行したら、コーヒーや温かい飲み物を飲みながら、スクリプトの実行が完了するまで待つことができます。依存関係に基づいて、VPC から始まり、セキュリティグループ、次にインターネット向け SLB インスタンスへと順番にリソースが作成されていることがわかります。Auto Scaling グループを起動し、対応するルールを構成し、「hello world」アプリケーションをインフラストラクチャにデプロイします。この簡略化されたシナリオは、基本的に、アプリケーションの自動デプロイに関して前述したことを実現しています。ただし、実際のビジネスプロセスでは、通常、インフラストラクチャの自動化とインフラストラクチャ管理のシナリオから始めます。作成が完了すると、パブリック IP アドレスが生成されていることがわかります。このパブリック IP アドレスは、「hello world」アプリケーションがデプロイされている場所です。サーバーの起動には時間がかかり、この期間中はプロセスが単にリフレッシュされるため、時間を節約するためにスキップします。

ここで、アプリケーションがサーバーに正常にデプロイされたと仮定すると、「hello world」アプリケーションが稼働していることがわかります。このシナリオでは、運用チームはインフラストラクチャとそのメタデータをアプリケーションチームに引き渡して、定期的に使用できます。この時点で、将来独自の CMDB またはマルチクラウド管理プラットフォームを構築する場合、このメタデータは基礎となり、非常に重要になります。次に、環境をリリースする必要があります。

2 時間のテストの後、ビジネスチームは「この環境はもう必要ありません」と言うかもしれません。組織のコストを節約するために、環境を速やかにリリースするように運用チームにリクエストします。このプロセスでは、運用チームは destroy コマンドを実行するだけで済みます。アプリケーション フォームでリクエストされたリソースは、事前に定義された削除ロジックに基づいて破棄されます。これにより、作成から破棄までのリソースのライフサイクル全体が完了します。削除が完了するまで待ちましょう。

SLB、セキュリティグループ、vSwitch、そして最後のリソース。削除が完了したら、Web サイトにアクセスして、以前にデプロイした「hello world」アプリケーションにまだアクセスできるかどうかを確認することで、結果を確認できます。ご覧のとおり、9 つのリソースを作成し、現在は同じ 9 つのリソースを削除しています。コンソールに戻ると、サービスとパブリック IP アドレスが存在しないことがわかり、クリーンアップが完了したことが確認されます。それでは先に進みましょう。

3 つ目のシナリオは、単一インスタンス上のクラウドリソースのベースライン管理に焦点を当てています。なぜ単一インスタンスなのでしょうか? それは今日のテーマ、つまり開発者または個々の運用エンジニアに最初にサービスを提供することに合致しているからです。既存のリソースの管理は、多くの場合、苦痛を伴う課題です。IaC と自動化ツールを採用する前は、多くの組織がすでにクラウドでリソースを実行しています。通常はビジネスが優先され、IaC フレームワークは後で構築されます。したがって、クラウドリソースをコードにリバースエンジニアリングし、その IaC コードを管理することが重要になります。

ここでの目標は、運用エンジニアが既存のクラウドリソースをローカル環境にインポートし、そのライフサイクル全体を管理することです。デモを見てみましょう。デモ 2 では、前のシナリオでデモした 9 つのリソースを使用して環境を再作成します。

デモ 3 では、デモ 2 で作成された 9 つのリソースは、コンソールからの既存のリソースを表していると仮定します。このプロセス中に、これらのコンソールリソースのインポートを構成します。インポートプロセスは簡単です。リソースタイプとリソース ID を定義してコマンドを実行するだけです。Terraform は対応する IaC コードを生成し、リソースメタデータを含む tfstate ファイルを作成します。これらが調整されると、インフラストラクチャをさらに管理し、既存のインフラストラクチャのベースラインに合わせることができる好循環に入ります。

デモ 3 で実行されるこのコマンドは、ID に基づいて一連のリソースをインポートします。まれに不一致が発生する場合があります。たとえば、オンライン値が 0 ですが有効値が 20 ～ 60 の場合は、環境に合わせてサイズを調整します。インポートするリソースが 9 つあることがわかります。Terraform apply を実行すると、正常にインポートされ、現在のベースラインと一致します。この時点で、デモ 2 とデモ 3 の tfstate ファイルは同期されます。これで、どのプロジェクトで作業しているかに関係なく、自動化されたベースライン全体を管理できます。このベースラインを確立することで、日々の運用の効率、精度、標準化が大幅に向上します。今回のエピソードはこれで終わりです。クラウドの自動化について質問やアイデアがある場合は、画面下部の QR コード をスキャンして DingTalk グループに参加し、ご連絡ください。フィードバックをお待ちしております。次のエピソードでお会いしましょう。