Terraform と gcloud CLI を使用した完璧な Google Cloud インフラストラクチャの構築

※この投稿は米国時間 2022 年 3 月 4 日に、Google Cloud blog に投稿されたものの抄訳です。

Terraform をはじめとする Infrastructure as Code（IaC）ツールの導入がデベロッパー コミュニティで急増しています。クラウド インフラストラクチャのデプロイと管理に関連する運用オーバーヘッドが大幅に簡素化されるとあれば、当然のことです。こうした傾向の高まりを受け、Google は本日、Google Cloud CLI による Terraform 向けの宣言型エクスポートのプレビュー版がリリースされたことをお知らせいたします。

宣言型エクスポートを使用すると、Google Cloud インフラストラクチャの現在の状態を、Terraform（HCL）や Google の KRM 宣言型ツールと互換性のある記述ファイルにエクスポートできます。その仕組みと、日々のクラウド開発ワークフローに役立つ理由については、以下をご覧ください。

これによって解決される問題

Google Cloud における IaC ワークフローで生じるずれの多くは、クラウド導入の開始時にそうしていない場合に、すべての Google Cloud リソースとその状態を記述した HCL Terraform ファイルを実際に作成する方法から生じるものです。たとえるなら、家が建ってしまってから、工程や順序に関する文書がないまま現場関係者が段階的に家の青写真を作成しようとするようなものです。

宣言型エクスポートを使用すると、既存の Google Cloud リソースを Terraform に簡単に移行できます。また、誤った構成やずれからも保護できます。

フォルダ内のすべてのリソースをローカル ディレクトリに Terraform 形式でエクスポートするには、次のコマンドを実行します。

ゾーン、リージョン、プロジェクトに gcloud のデフォルト値を使用して現在のディレクトリに main.tf ファイルを生成するには、次のコマンドを実行します。

このコマンドにより、Google Cloud の Terraform プロバイダを構成する main.tf ファイルが生成されます。

ローカル ディレクトリにエクスポートされたファイルに基づいて、import.sh というインポート スクリプトと modules.tf というモジュール ファイルを生成するには、次のコマンドを実行します。

Google Cloud CLI の宣言型エクスポート機能では、好きなツールを使用してクラウド インフラストラクチャを「構築」できます。たとえば、Cloud Console、CLI、既存の gcloud や Ansible スクリプトなどの方法が使えます。次に、宣言型エクスポートを使用して、すべてのリソースの現在の状態を記述した Terraform 互換ファイルを作成します。先程の家のたとえで言えば、建築済みの家を X 線撮影して、家を建てるために使用された元の設計図を再現するようなものです。

命令型アプローチのデメリット:

これまでデベロッパーとオペレータは、順次的または手続き的な一連のステップを通じてクラウド インフラストラクチャを構成、管理していました。たとえば、オペレータは最初に仮想マシンを起動し、次にディスク、ファイアウォール、ロード バランシング ルールなどを追加する場合があります。クラウド インフラストラクチャが複雑化するにつれ、こうした命令型アプローチは、必要な労力が増し、エラーが発生しやすくなっていきます。順不同で、間違ったリソースに対して、あるいは間違った手順によってステップが実施された場合、インフラストラクチャは目的の最終状態に至るまで正しく構成されません。

こうした複雑さが積み重なっていくと、開発チームの成長にともない、異なる担当者（またはスクリプト）が同じインフラストラクチャに変更を加える可能性も高まります。時間の経過とともに生じるずれは、デプロイ全体で予期しない動作を引き起こす可能性があります。変更内容も追跡しにくくなり、既知の良好な状態に戻す方法が大幅に制限されます。

IaC のメリット:

宣言型 IaC ツールの台頭により、デベロッパーは別のアプローチを採用できるようになりました。目的とするインフラストラクチャのターゲット状態を記述し、インフラストラクチャをその状態にする作業は IaC ツールに任せるという方法です。

Terraform では、このような IaC ソリューションを数年間提供してきました。Terraform は Hashicorp 独自の構文（HCL）を使用して、特定のクラウド リソースと目的の最終状態を記述します。これらのファイルを微調整して最終状態に必要な変更を記述し、Terraform で再適用して、インフラストラクチャを記述された状態に変えるために必要なものをすべて有効にできます。ツール自体が目標の達成に必要な特定の呼び出しを決定するため、オペレータが多くのサブステップやその順序を管理する必要がなくなります。

また、インフラストラクチャの状態をテキストファイルとして表現するため、このファイルをリポジトリにチェックインして、リポジトリ管理のすべてのメリット（差分、競合解決、commit メモ、タイムスタンプなど）を得ることも可能です。これにより、デベロッパーは履歴から既知のリビジョンを選択し、その特定の HCL ファイルを Terraform で適用することでそのリビジョンに「スナップ」できます。

宣言型エクスポートの主なユースケース

HCL ファイルは、プランを実行し、Terraform に適用するために使用できます。これにより、インフラストラクチャが記述されたターゲット状態になります。

宣言型エクスポートの想定される用途:

• インフラストラクチャのずれの解決: 時間の経過とともに、特に組織を代表する数人の担当者がインフラストラクチャ構成に関わっている場合、インフラストラクチャは既知の正確で適切な元の状態から逸脱していきます。Google Cloud CLI の宣言型エクスポートを使用すれば、ずれが生じる前に既知の良好な状態をキャプチャしておくことで、オペレータが後で Terraform を利用して、ずれのあるインフラストラクチャを既知の良好な状態に戻すことができます。

• 環境のクローン作成: 複雑なスタックを適切に構成するには、数時間から数日かかる場合があります。すべてのステップを手動でやり直したり、ステップのスクリプトを作成するために労力をかけたりすることなく、環境全体の宣言型の表現をエクスポートするだけで、Terraform を使用してクローンを作成できます。ユースケースの例としては、クローン作成によるステージング環境の生成や、スタックのクローンの別のリージョンへの作成などが挙げられます。このような場合、ゾーンやリージョンを変更してから再適用するなど、HCL ファイルに微調整を適用します。

• テンプレート化されたソフトウェア スタックのデプロイ: SaaS プロダクトとして販売するスタックか、社内で承認されたアプリケーション インスタンスに使用するスタックが事前定義されている会社向けの用途です。好きなツールを使用して「完璧な」Google Cloud インフラストラクチャ構成を設定し、マルチリソースのインスタンスをオンデマンドで再作成できます。

• トラブルシューティングや緊急時の復元: 問題の正確な発生タイミングがわかる場合、関連する HCL ファイルと以前の HCL ファイルの差分を比較して、原因となっている可能性がある変更を正確に特定できます。または、良好であるとわかっている HCL を適用して作業状態に戻し、緊急事態のエスカレーションを解除することで、より系統的な修復が可能になります。

• 日々のワークフローでの宣言型ツールの使用: Cloud Console や CLI を使用してインフラストラクチャ全体に変更を加える場合と比較して、HCL ファイルを編集する方が生産性が向上する場合があります。

このプレビュー リリースの現在の制限:

• 多くの Google Cloud リソースに対応していますが、すべてが対象ではありません。my-project プロジェクト内のエクスポート可能なすべてのリソースタイプを json 形式で一覧表示するには、次のコマンドを実行します。

• Terraform で手動適用します。gcloud および terraform コマンドを同時に使用し、Terraform ファイルを「インポート」して適用、実行します。

次のステップ

今後、上記のステップは、gcloud beta resource-config terraform generate-import などを使用して gcloud CLI 内から直接簡略化される予定です。また、参考情報のサポートも引き続き追加してまいります。

ご意見・ご感想:

この機能の活用法や、Google で実施できる改善のアイデアについて、ご意見をお待ちしています。