Terraform の状態を GitLab CI/CD に移行するための便利なガイド

コードとしてのインフラストラクチャ (IaC) を扱うソフトウェア プロフェッショナルとして、あなたは多くの作業を行っている可能性があります。テラフォーム.新しいクライアントが IaC を使用するのを支援する場合、物事を簡素化するのが一般的ですが、Terraform 状態ファイルの管理は最初に直面する課題です。基本的に、Terraform の状態には、ソース管理によって保存されるべきではない機密情報が含まれていますが、同時に、複数のユーザーが同じ Terraform の状態で作業している場合はスケーリングされません。その答えは？バックエンド。

その状態ファイルを S3 バケットに保存し、DynamoDB を使用してロック状態を管理できることに注意してください。ただし、このアプローチでは追加のリソースを作成する必要があり、特にクライアントが GitLab を使用している場合は複雑なオプションになります。 GitLab は最近、Terraform の状態を保存および管理する方法と、その周りに CI をセットアップする簡単な方法を提供することで、Terraform の統合への参入障壁を下げました。

このブログ投稿では、Terraform 状態ファイルとは何か、GitLab に移行する方法、CI パイプラインを設定する方法について説明します。リポジトリにアクセスできますここ.

目次

• Terraform の状態とは
• GitLab に Terraform の状態を管理させる方法
• GitLab で CI パイプラインを介して IaC を実行する方法
• おまけのヒント: インフラコスト
• 結論

Terraform ステートとは

Terraform は、状態ファイルを介して、コードで定義されたインフラストラクチャに関するすべての情報を記録します。 JSON で記述され、基本的に、Terraform コードから作成された実際のリソースへのマッピングを記録します。以下は、terraform.tfstate がどのように見えるかの例です。

主に、Terraform を実行するたびに、EC2 インスタンスの最新のステータスが取得され、Terraform 構成と比較されて、適用する必要がある変更が決定されます。

 { "version": 4, "terraform_version": "0.12.0", "serial": 1, "lineage": "1f2087f9-4b3c-1b66-65db-8b78faafc6fb", "outputs": {}, "resources": [ { "mode": "managed", "type": "aws_instance", "name": "example", "provider": "provider.aws", "instances": [ { "schema_version": 1, "attributes": { "ami": "ami-0c55b159cbfafe1f0", "availability_zone": "us-west-2a", "id": "i-00a123a0accffffff", "instance_state": "running", "instance_type": "t2.micro", "(...)": "(truncated)" } } ] } ] }

デフォルトでは、この terraform.tfstate は、Terraform ファイルがある場所にローカルに保存され、変更を計画して適用します。いくつかのテストを実行するだけの個人的なプロジェクトの場合、これは問題ありませんが、推奨される方法ではありません。理由は次のとおりです。

• 共有場所に保存:この状態ファイルをローカル ワークステーションでホストしていて、別のエンジニアと作業しなければならない場合、事態は複雑になります。両方とも最新バージョンの状態を使用していることを確認する必要があり、Terraform プランを実行したり、同時に適用したりすると、競合状態に陥る可能性があります。
• 機密情報の保護:生成された状態ファイルには、暗号化キーとインフラストラクチャ パスワードを含めることができます。ただし、状態ファイルは既定では暗号化されないため、機密情報をプレーン テキストで保存することはお勧めできません。
• ロック:ほとんどのバージョン管理システムは、2 人のチーム メンバーが同じ状態ファイルに対して Terraform 適用を同時に実行することを防止するロックの形式をサポートしていません。これが、ソース管理によって管理される状態ファイルが表示されないもう 1 つの理由です。

‍

GitLab で Terraform の状態を管理する方法

Terraform がクラウド インフラストラクチャ プロビジョニングの標準と見なされているため、GitLab が Terraform の状態を保存および管理する方法を提供し始めてから 1 年ほどが経ちました。このため、最近 GitLab を使用して IaC を管理し始めたので、移行プロセスを共有したいと思いました。

この記事では、ローカル状態を使用していて、AWS S3 バケットまたは別のバックエンド ソリューションで状態を管理していると想定しています。

まず、HTTP を使用するように backend.tf を変更する必要があります。

 terraform { backend "http" {} }

次に、ターミナルで 4 つの変数を設定する必要があります。

• PROJECT_ID:プロジェクトの概要ページでリポジトリに移動すると、これを簡単に見つけることができます

__ __

‍

• TF_USERNAME:作業中のリポジトリにアクセスできる Gitlab ユーザー名。
• TF_PASSWORD: GitLab ユーザーから生成されたアクセス トークン。
• TF_ADDRESS:リモート状態のバックエンドの URL

 PROJECT_ID="28450092" TF_USERNAME="florianpialoux" TF_PASSWORD="123456789" TF_ADDRESS="https://gitlab.com/api/v4/projects/${PROJECT_ID}/terraform/state/aws-buckets"

次のコマンドを使用して、Terraform の状態を以前の場所から GitLab に移動する移行コマンドを実行できます。

 terraform init \ -migrate-state \ -backend-config=address=${TF_ADDRESS} \ -backend-config=lock_address=${TF_ADDRESS}/lock \ -backend-config=unlock_address=${TF_ADDRESS}/lock \ -backend-config=username=${TF_USERNAME} \ -backend-config=password=${TF_PASSWORD} \ -backend-config=lock_method=POST \ -backend-config=unlock_method=DELETE \ -backend-config=retry_wait_min=5

GitLab が状態ファイルの管理を開始できるように、「はい」で確認を行う必要があります。ローカル状態から GitLab への例を次に示します。

__ __

s3 から GitLab への例

__ __

これで、GitLab インターフェイスからInfrastructure > Terraformに移動して、状態を確認できます。

__ __

以前に実行した migrate-state コマンドを使用した後でも、s3 から持っていた状態ファイルの一部が空白になることに気付きました。この場合、これを実行できます。

 terraform state pull > aws-buckets.json

s3 状態からコンテンツをコピーして貼り付け、プッシュを実行します。

 terraform state push -lock=true aws-buckets.json

GitLab は Terraform 状態ファイルのバージョン管理をサポートしていますが、WebUI を介して古いバージョンを表示/復元するには、 GitLab プレミアムプラン.そうでない場合は、GraphQL API を作成する必要があります。リクエスト.

‍

GitLab で CI パイプラインを介して IaC を実行する方法

GitLab が提供するドッカーのイメージこれには、公式の Terraform バイナリのシン ラッパー スクリプトである GitLab-Terraform が含まれています。または、次を使用することもできます公式 docker イメージハシコープによる。 GitLab Terraform Image に関する詳細情報を見つけることができますここ.

terraform 適用ジョブが実行されると、状態がいつ、どのパイプラインで使用されたかを確認できます。

__ __

gitlab-ci.ymlがどのように見えるかについて詳しく知るここ.以下は、プロジェクト レベルで定義する必要がある変数です。

__ __

おまけのヒント: インフラコスト

お気づきかもしれませんが、追加した gitlab-ci.yaml を見てください。インフラコストこれにより、IaC に新しいリソースを定義するたびにコストの見積もりが提供されるため、クラウド請求をより詳細に制御できます。 Infracost の詳細については、詳細をご覧ください。記事それが何を伴うか、そして私たちのステップバイステップについてガイドTerraform と統合する方法について説明します。

結論

Terraform の状態と CI を Gitlab で実行することは、GitOps のベスト プラクティスに従うための優れた方法です。どちらも、IaC の開発と展開に最適な組み合わせです。ほとんどの人はすでにリポジトリに GitLab を使用している可能性があるため、IaC を 1 つの屋根の下に配置し、GitLab に転送中および保管中の暗号化をサポートすることで Terraform の状態を管理させ、バージョニング、ロック、およびロック解除を行うことがはるかに簡単になります。州。