GitLabをAWSのコントロールプレーンに：OpenTofuとArgo CDで実現する完全自動化

クラウド環境の構築は簡単ではありません。ネットワーク、サブスクリプション、各種サービス、そして基盤インフラを構成するあらゆる要素を考慮する必要があるためです。手作業でのセットアップはミスが起こりやすく、環境ごとに差異が生まれ、同じ状態を再現するのも困難です。

本記事では、GitLabを運用の中枢に据えて、完全に自動化されたクラウド環境を構築する方法を紹介します。クラウドインフラはすべてコードとして定義してGitLab上で管理し、GitLab CI/CDパイプラインからOpenTofuを使ってAWSにデプロイ。さらに同じパイプラインが、Argo CDによるGitOpsの手法で、実際のWebアプリケーションのビルドとデプロイまで担います。

なぜInfrastructure as CodeとGitOpsなのか

まずは、Infrastructure as Code（IaC）とGitOpsがなぜ重要なのか、そしてGitLabがこれらの手法を単一のプラットフォームでどう統合するのかを押さえておきましょう。

IaCによって、環境は次の特性を備えます。

• 再現性：同じ構成をどこにでもデプロイできる
• バージョン管理：すべての変更をバージョン管理システム（VCS、多くの場合はGit）で追跡できる
• 自動化：人の手を介する必要がない

GitOpsは、この考え方をアプリケーションのライフサイクルにまで広げたもの。Kubernetesクラスター（やその他のインフラ）に手作業で変更を適用するのではなく、アプリケーションのあるべき状態をGitに置きます。あとはArgo CDのようなGitOpsオペレーターが、リポジトリの内容とクラスターの状態を継続的に一致させる仕組みです。これによって得られるメリットは次のとおり。

• 環境間の一貫性
• 迅速な復旧：コミットをリバートするだけでロールバックが完了
• コラボレーションの向上：マージリクエスト経由で変更をレビュー・承認できる
• セキュリティの強化：デベロッパーがクラスターに直接アクセスしなくてもデプロイできる

こうしたアプローチに必要な機能は、すべてGitLabに揃っています。

• ソースコード管理：インフラのコードとアプリケーションのコードを一箇所で管理
• CI/CDパイプライン：OpenTofuによるプロビジョニングと、Kubernetesマニフェストによるデプロイを自動化
• Terraformステート：インフラのステートファイルを安全に保管・管理
• コンテナレジストリ：コンテナイメージをコードやパイプラインと同じ場所でビルド・保存・管理

クラウドインフラのプロビジョニングからアプリケーションの配信まで、GitLabならすべてが1つのプラットフォーム上で完結します。

本チュートリアルを進めるには、以下が必要です。

• GitLab CI/CDパイプラインとGitの基礎知識
• IaC（TerraformまたはOpenTofu）とGitOpsに関する基本的な理解
• AWSアカウント
• Kubernetesクラスター（本チュートリアルではEKSをプロビジョニングします）
• サンプルWebアプリケーション用のDockerfile

本チュートリアルで扱う手順は次のとおりです。

• OpenTofuでネットワークとEKSを含むAWS環境一式をプロビジョニングする
• Argo CDとCertManagerなどのKubernetesツールを自動で構成する
• Argo CDのGitOpsでサンプルWebアプリケーションをデプロイする
• GitLab CI/CDでサンプルWebアプリケーションをビルドしパッケージ化する

この例をご自身のGitLab環境で再現する方法を、順に見ていきましょう。サンプルのソースコードはSATEC Public Demo Groupで公開しています。

OpenTofuでネットワークとEKSを含むAWS環境一式をプロビジョニングする

最初のステップは、OpenTofu（Terraformのオープンソースフォーク）によるクラウドインフラのプロビジョニングです。ネットワークコンポーネントを宣言的に定義し、Amazon EKSクラスターを作成します。

このプロセスに再現性と安全性を持たせるため、値をハードコードせずGitLab CI/CD変数を使います。これにより、複数のパイプラインをまたいでAWS環境を動的に設定できます。

必要な環境変数は以下のとおりです。すべてのプロジェクトに継承させるため、親グループの**「設定 > CI/CD > 変数」**で定義します。

• TF_VAR_region：インフラを作成するAWSリージョン（例：eu-west-1）
• TF_VAR_instance_type：ワーカーノード用のEC2インスタンスタイプ（例：t3.medium）
• TF_VAR_instance_count：クラスター内のワーカーノード数
• TF_VAR_cluster_name：プロビジョニングするEKSクラスターの名前
• AWS_ACCESS_KEY_ID：認証用のAWSアクセスキー
• AWS_SECRET_ACCESS_KEY：認証用のAWSシークレットキー

変数はすべてGitLab上で保護変数として定義し、AWSシークレットアクセスキーのような機密性の高いものにはマスクも設定します。こうすることで、安全なCI/CDコンテキストでのみ値が参照される状態を保てます。セキュリティをさらに高めたい場合は、CI/CD変数のチュートリアルもご覧ください。コードと設定を分離しておけば、パイプラインは柔軟さを保ったまま、特定の環境に依存しなくなります。

設定が完了すれば、OpenTofuパイプラインを自動実行して次の処理を行えます。

• ネットワークリソース（VPC、サブネット、ゲートウェイ、ルーティングテーブル）のプロビジョニング
• EKSコントロールプレーンとワーカーノードグループのプロビジョニング
• 新しいクラスターにArgo CDとCertManagerをデプロイするパイプラインのトリガー

上の図は、インフラのプロビジョニングプロセスの流れを示したものです。

1. Terraform/OpenTofuの設定ファイルを格納したインフラリポジトリから、GitLabパイプラインをトリガー。
2. GitLab CI/CDがOpenTofuコマンドを実行。統合されたTerraformステート管理バックエンドを使い、ステートファイルをGitLab内で安全に管理します。
3. OpenTofuが設定済みのプロバイダー経由でAWSに接続し、VPC、サブネット、ゲートウェイ、ロードバランサー、複数のアベイラビリティーゾーンに分散配置したAmazon EKSクラスターなど、必要なリソースをすべて作成します。

この段階が終わると、AWS環境とKubernetesクラスターのプロビジョニングは完了し、すぐに運用できる状態になります。

このプロセスの最後（ポストデプロイ）に行うのが、専用リポジトリに置いた2つ目のGitLabパイプラインのトリガーです。このパイプラインが、Helmプロバイダーを使ってArgo CDとCertManagerを新しいEKSクラスターへ自動的にデプロイします。

Argo CDとCertManagerなどのKubernetesツールを自動で構成する

AWSインフラとEKSクラスターのプロビジョニングが済んだら、次は環境の運用に欠かせないKubernetesツール、すなわちArgo CD、CertManager、Ingress NGINX Controllerの構成です。

この工程は、別リポジトリに置いた2つ目のGitLabパイプラインによって完全に自動化されています。

2つ目のパイプラインは、OpenTofuのプロビジョニングステージが正常に完了した時点で、インフラパイプラインのトリガージョブから自動的に実行されます。

つまり、これらのコアコンポーネントのデプロイは、エンドツーエンドの同じワークフローの一部としてシームレスに進み、手作業は一切不要。デプロイ自体はOpenTofuがHelmプロバイダー経由で実行するため、HelmチャートをGitLab上でコードとして宣言的に管理できます。

ワークフローを簡略化すると、次のようになります。

1. 1つ目のパイプラインがEKSクラスターを用意し、GitLabのトリガージョブで2つ目のパイプラインを起動します。
2. 2つ目のパイプラインが、OpenTofuとHelmプロバイダーを使って次の処理を実行します。
   • EKSクラスターからkubeconfigを取得
   • Argo CDのインストール（GitOps管理用）
   • CertManagerのインストール（TLS証明書の自動管理用）
   • Ingress NGINX Controllerのインストール（Ingressトラフィックのルーティング用）（注：Ingress NGINX ControllerはKubernetesエコシステムで非推奨化が進んでいます。新規のデプロイでは、TraefikやAPIゲートウェイベースのアプローチといった代替手段の検討をおすすめします）
3. 各HelmリリースはOpenTofuの設定内で定義するため、アップグレードやロールバックも通常のインフラコードの変更として対応可能。
4. 最後に3つ目のパイプラインがトリガーされ、サンプルWebアプリケーションをデプロイします。このパイプラインは、Webアプリとその関連リソースを定義したArgo CDのアプリケーションマニフェストを適用します。

Argo CDのGitOpsでサンプルWebアプリケーションをデプロイする

コアとなるKubernetesコンポーネント（Argo CD、CertManager、Ingress NGINX Controller）のインストールが完了すると、自動化パイプラインの最終ステージが始まります。この工程は、Helmチャートのインストール完了直後に自動で実行される仕組みです。

ここでトリガーされる3つ目のGitLabパイプラインが、Argo CD経由でサンプルWebアプリケーションを新しいEKSクラスターにデプロイします。

全体の流れは以下の図のとおりです。

このステージでは、GitLabがOpenTofuの生成したkubeconfigを使ってクラスターに接続し、Webアプリケーションのあるべき状態を定義したArgo CDのアプリケーションマニフェストを適用します。

パイプラインが行う処理は次のとおりです。

• kubeconfigの取得と更新：EKSクラスターへの接続に使用します
• 認証情報とリポジトリ情報の動的な更新：CI/CD変数を利用します
• Kubernetesネームスペースの作成：アプリケーション用（aws-summit-app）
• Argo CDマニフェストの適用：repository.yaml、application.yaml、cluster-issuer.yaml
• コンテナレジストリのシークレット作成：アクセストークンを使い、アプリケーションがGitLabから安全にイメージをプルできるようにします

これらの処理はすべてGitLab CI/CDによって自動的に行われ、手作業は発生しません。

マニフェストが適用されると、Argo CDコントローラーがそれを検知し、アプリケーションの状態をリポジトリと同期。サンプルWebページがEKSクラスターにデプロイされます。

こうして出来上がるのは、次のような形で稼働するKubernetes環境です。

• インフラはOpenTofuでプロビジョニング
• クラスターのツールはHelmで宣言的にインストール
• アプリケーションはArgo CDを使ったGitOpsでデプロイ・管理

このアプローチにより、エンドツーエンドの自動化、トレーサビリティ、再現性が確保され、そのすべてをGitLabで管理できます。

GitLab CI/CDでサンプルWebアプリケーションをビルドしパッケージ化する

Argo CDでアプリケーションをデプロイする前に、まずはビルドし、コンテナ化して、GitLabコンテナレジストリに公開しておく必要があります。

この工程は専用のCI/CDパイプラインで管理し、ソースコードとKubernetesマニフェストを別々のリポジトリに置くGitOps向けのリポジトリ構成に従います。

この構成では、GitLabグループを大きく2つに分けます。

• Apps/：アプリケーションのソースコードリポジトリを格納
  • 例：aws-summit-app/webにサンプルWebページのソースコードを配置
• Deployments/：アプリケーションごとのKubernetesマニフェストのリポジトリを格納
  • 例：Deployments配下のaws-summit-app/webで、Webページをデプロイするためのマニフェスト（deployment.yaml、ingress.yaml、service.yamlなど）を定義

この分離によって、アプリケーションコードとデプロイ設定は互いに独立しながらも自動化を通じて同期し、見通しのよいGitOpsワークフローが実現します。

アプリケーションリポジトリに定義したCI/CDパイプラインは、次のタスクを自動化します。

• **ビルドとパッケージ化：**ソースコードをコンパイルし、用意したDockerfileでDockerイメージをビルドします
• **GitLabコンテナレジストリへの公開：**イメージに自動でタグを付け、統合されたGitLabコンテナレジストリにプッシュします
• **デプロイマニフェストの更新：**イメージの公開後、対応するデプロイリポジトリ（Deployments/aws-summit-app/web配下）内のイメージ参照を更新するジョブを実行します

これらは、新しいイメージタグのコミット、またはマージリクエストの作成という形で自動的に行われます。

コミットやマージリクエストが作成されると、Argo CDがデプロイリポジトリの変更を自動的に検知し、更新後のマニフェストをKubernetesクラスターと同期します。新しいバージョンのアプリケーションは、手作業を挟むことなくデプロイされます。

まとめ

本記事では、GitLabを中心に据えた完全自動のクラウド環境の構築方法を紹介しました。冒頭で掲げた目標、つまり再現性があり、バージョン管理され、自動化されたインフラという要件を満たす構成です。インフラのプロビジョニングにOpenTofu、パイプラインのオーケストレーションにGitLab CI/CD、GitOpsベースのアプリケーション配信にArgo CDを組み合わせれば、クラウドリソースから稼働中のアプリケーションまで、ライフサイクル全体を1つのプラットフォームで管理できます。

クラウドインフラとDevSecOpsの実践に深い知見を持つGitLabパートナーとして、Clober（SATECグループ）は、各組織のニーズに合わせた自動化環境の導入を支援しています。

注：本記事は、Clober（SATECグループ）のDevSecOpsチームがAWS Summit Madrid 2025で実施したライブデモをもとにしています。

関連リンク

• GitLab CI/CDコンポーネント
• GitLabコンテナレジストリ
• GitLabが管理するTerraformステート管理