コードとしてのインフラストラクチャ (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: __   __  ‍   作業中のリポジトリにアクセスできる Gitlab ユーザー名。 TF_USERNAME:    GitLab ユーザーから生成されたアクセス トークン。 TF_PASSWORD:   リモート状態のバックエンドの URL TF_ADDRESS:   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 を介して古いバージョンを表示/復元するには、 .そうでない場合は、GraphQL API を作成する必要があります。 .   GitLab プレミアムプラン リクエスト  ‍   GitLab で CI パイプラインを介して IaC を実行する方法 GitLab が提供する これには、公式の Terraform バイナリのシン ラッパー スクリプトである GitLab-Terraform が含まれています。または、次を使用することもできます ハシコープによる。 GitLab Terraform Image に関する詳細情報を見つけることができます . ドッカーのイメージ 公式 docker イメージ ここ  terraform 適用ジョブが実行されると、状態がいつ、どのパイプラインで使用されたかを確認できます。  __   __   がどのように見えるかについて詳しく知る .以下は、プロジェクト レベルで定義する必要がある変数です。 gitlab-ci.yml ここ  __   __ おまけのヒント: インフラコスト お気づきかもしれませんが、追加した gitlab-ci.yaml を見てください。 これにより、IaC に新しいリソースを定義するたびにコストの見積もりが提供されるため、クラウド請求をより詳細に制御できます。 Infracost の詳細については、詳細をご覧ください。 それが何を伴うか、そして私たちのステップバイステップについて Terraform と統合する方法について説明します。 インフラコスト 記事 ガイド 結論 Terraform の状態と CI を Gitlab で実行することは、GitOps のベスト プラクティスに従うための優れた方法です。どちらも、IaC の開発と展開に最適な組み合わせです。ほとんどの人はすでにリポジトリに GitLab を使用している可能性があるため、IaC を 1 つの屋根の下に配置し、GitLab に転送中および保管中の暗号化をサポートすることで Terraform の状態を管理させ、バージョニング、ロック、およびロック解除を行うことがはるかに簡単になります。州。 にも掲載されています。 ここ

Maximize revenue with cutting-edge nearshore software development services today!

このオーディオは、ストーリーの元の言語で制作されています。

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

About Author

コメント

ラベル

この記事は

Related Stories

Telegram: クリプト島と本土を結ぶ橋

ユーザー中心の暗号通貨製品の作成: 顧客からのフィードバックの重要性

海を航海する: データレイクを使用した本番環境レベルの RAG アプリケーションの開発

タップして稼ぐ：テレグラムはソラナより先に次の100億人の暗号通貨ユーザーを獲得する可能性がある

Telegram: クリプト島と本土を結ぶ橋

ユーザー中心の暗号通貨製品の作成: 顧客からのフィードバックの重要性

海を航海する: データレイクを使用した本番環境レベルの RAG アプリケーションの開発

タップして稼ぐ：テレグラムはソラナより先に次の100億人の暗号通貨ユーザーを獲得する可能性がある

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps