チュートリアル: AWSでワークスペースのインフラストラクチャをセットアップする

このチュートリアルでは、GitLabワークスペースのインフラストラクチャをAWS上に、OpenTofu（Terraformのオープンソースフォーク）とInfrastructure as Code（IaC）を使用して設定する方法を説明します。

はじめる前

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

• Amazon Web Services（AWS）アカウント。
• ワークスペース環境用のドメイン名。

GitLabワークスペースインフラストラクチャを設定するには:

1. リポジトリをフォークする
2. AWSの認証情報を設定する
3. ドメインと証明書を準備する
4. 必要なキーを作成する
5. Kubernetes向けGitLabエージェントのトークンを作成する
6. GitLab OAuthを設定する
7. CI/CD変数を設定する
8. Kubernetes向けGitLabエージェントの設定を更新する
9. パイプラインを実行する
10. DNSレコードを設定する
11. エージェントを承認する
12. ワークスペースを作成してセットアップを確認する

リポジトリをフォークする

まず、環境に合わせて設定できるように、インフラストラクチャセットアップリポジトリのコピーを作成する必要があります。

リポジトリをフォークするには:

1. Workspaces Infrastructure Setup AWSリポジトリにアクセスします。
2. リポジトリのフォークを作成します。

AWSの認証情報を設定する

次に、インフラストラクチャが適切にプロビジョニングされるように、AWSで必要な権限を設定します。

AWSの認証情報を設定するには:

1. IAM UserまたはIAM Roleを作成します。

2. 次の権限を割り当てます:

   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Sid": "VisualEditor0",
         "Effect": "Allow",
         "Action": [
           "ec2:*",
           "eks:*",
           "elasticloadbalancing:*",
           "autoscaling:*",
           "cloudwatch:*",
           "logs:*",
           "kms:DescribeKey",
           "kms:TagResource",
           "kms:UntagResource",
           "kms:ListResourceTags",
           "kms:CreateKey",
           "kms:CreateAlias",
           "kms:ListAliases",
           "kms:DeleteAlias",
           "iam:AddRoleToInstanceProfile",
           "iam:AttachRolePolicy",
           "iam:CreateInstanceProfile",
           "iam:CreateRole",
           "iam:CreateServiceLinkedRole",
           "iam:GetRole",
           "iam:ListAttachedRolePolicies",
           "iam:ListRolePolicies",
           "iam:ListRoles",
           "iam:PassRole",
           "iam:DetachRolePolicy",
           "iam:ListInstanceProfilesForRole",
           "iam:DeleteRole",
           "iam:CreateOpenIDConnectProvider",
           "iam:CreatePolicy",
           "iam:TagOpenIDConnectProvider",
           "iam:GetPolicy",
           "iam:GetPolicyVersion",
           "iam:GetOpenIDConnectProvider",
           "iam:DeleteOpenIDConnectProvider",
           "iam:ListPolicyVersions",
           "iam:DeletePolicy"
         ],
         "Resource": "*"
       }
     ]
   }

3. ユーザーまたはロール用のアクセスキーを作成します。

4. アクセスキーIDとシークレットアクセスキーを保存します。これらは、CI/CD変数を設定する以降の作業で必要になります。

ドメインと証明書を準備する

ワークスペースにアクセスできるようにするには、接続を保護するためのドメインとTLS証明書が必要です。

ドメインと証明書を準備するには:

1. ワークスペース環境用のドメインを購入するか、既存のドメインを使用します。
2. 次のTLS証明書を作成します:
   • GitLabワークスペースプロキシドメイン。たとえば、workspaces.example.devなどです。
   • GitLabワークスペースプロキシワイルドカードドメイン。たとえば、*.workspaces.example.devなどです。

詳細については、TLS証明書を生成するを参照してください。

必要なキーを作成する

次に、認証とSSH接続用のセキュリティキーを作成する必要があります。

必要なキーを作成するには:

1. ランダムな文字、数字、特殊文字で構成される署名キーを生成します。例: 以下を実行します:

   openssl rand -base64 32

2. SSHホストキーを生成します:

   ssh-keygen -f ssh-host-key -N '' -t rsa

Kubernetes向けGitLabエージェントのトークンを作成する

Kubernetes向けGitLabエージェントは、AWS KubernetesクラスターをGitLabに接続します。

エージェントのトークンを作成するには:

1. あなたのグループに移動します。
2. 上部のバーで、検索または移動先を選択して、プロジェクトを見つけます。
3. 左サイドバーで、操作 > Kubernetesクラスターを選択します。
4. クラスターに接続を選択します。
5. エージェントの名前を入力し、以降の作業で使用するために保存します。たとえば、gitlab-workspaces-agentk-eksなどです。
6. 作成して登録を選択します。
7. トークンとGitLab Relay (KAS) アドレスを後で使用するために保存します。
8. 続行するを選択します。

GitLab OAuthを設定する

次に、ワークスペースに安全にアクセスするためにOAuth認証を設定します。

GitLab OAuthを設定するには:

1. 右上隅で、アバターを選択します。

2. プロファイルを編集を選択します。

3. 左サイドバーで、アクセス > アプリケーションを選択します。

4. OAuth applicationsまでスクロールします。

5. 新しいアプリケーションを追加を選択します。

6. 次の設定を更新します:

   • 名前: GitLabワークスペースプロキシ
   • リダイレクトURI: たとえば、https://workspaces.example.dev/auth/callbackなどです。ユーザー定義ドメインに置き換えます。
   • 非公開チェックボックスを選択します。
   • スコープ: api、read_user、openid、およびprofile。

7. アプリケーションを保存を選択します。

8. CI/CD変数のために、アプリケーションIDとシークレットを保存します。

9. 続行するを選択します。

CI/CD変数を設定する

次に、インフラストラクチャパイプラインが実行できるように、必要な変数をCI/CDの設定に追加する必要があります。

CI/CD変数を設定するには:

1. 上部のバーで、検索または移動先を選択して、プロジェクトを見つけます。

2. 左サイドバーで、設定 > CI/CDを選択します。

3. 変数を展開します。

4. プロジェクト変数セクションで、次の必須変数を追加します:

   変数	値
   AWS_ACCESS_KEY_ID	AWSアクセスキーID。
   AWS_SECRET_ACCESS_KEY	AWSシークレットアクセスキー。
   TF_VAR_agent_token	Kubernetes向けGitLabエージェントトークン。
   TF_VAR_kas_address	GitLab Relay (KAS) アドレス。GitLab Self-Managedインスタンスの場合に必須です。たとえば、wss://kas.gitlab.comなどです。
   TF_VAR_workspaces_proxy_auth_client_id	OAuthアプリケーションクライアントID。
   TF_VAR_workspaces_proxy_auth_client_secret	OAuthアプリケーションシークレット。
   TF_VAR_workspaces_proxy_auth_redirect_uri	OAuthコールバックURL。たとえば、https://workspaces.example.dev/auth/callbackなどです。
   TF_VAR_workspaces_proxy_auth_signing_key	生成された署名キー。
   TF_VAR_workspaces_proxy_domain	ワークスペースプロキシのドメイン。
   TF_VAR_workspaces_proxy_domain_cert	プロキシドメインのTLS証明書。
   TF_VAR_workspaces_proxy_domain_key	プロキシドメインのTLSキー。
   TF_VAR_workspaces_proxy_ssh_host_key	生成されたSSHホストキー。
   TF_VAR_workspaces_proxy_wildcard_domain	ワークスペースのワイルドカードドメイン。
   TF_VAR_workspaces_proxy_wildcard_domain_cert	ワイルドカードドメインのTLS証明書。
   TF_VAR_workspaces_proxy_wildcard_domain_key	ワイルドカードドメインのTLSキー。

5. オプション。デプロイをカスタマイズするには、次のいずれかの変数を追加します:

   変数	値
   TF_VAR_region	AWSリージョン。
   TF_VAR_zones	AWSアベイラビリティゾーン。
   TF_VAR_name	リソースの名前プレフィックス。
   TF_VAR_cluster_endpoint_public_access	クラスターエンドポイントへのパブリックアクセス。
   TF_VAR_cluster_node_instance_type	Kubernetesノード用のEC2インスタンスタイプ。
   TF_VAR_cluster_node_count_min	最小ワーカーノード数。
   TF_VAR_cluster_node_count_max	最大ワーカーノード数。
   TF_VAR_cluster_node_count	ワーカーノード数。
   TF_VAR_cluster_node_labels	クラスターノードに適用するラベルのマップ。
   TF_VAR_agent_namespace	エージェント用のKubernetesネームスペース。
   TF_VAR_workspaces_proxy_namespace	ワークスペースプロキシ用のKubernetesネームスペース。
   TF_VAR_workspaces_proxy_ingress_class_name	Ingressクラス名。
   TF_VAR_ingress_nginx_namespace	Ingress-NGINX用のKubernetesネームスペース。

素晴らしいです！インフラストラクチャのデプロイに必要なすべての変数を設定しました。

Kubernetes向けGitLabエージェントの設定を更新する

次に、Kubernetes向けGitLabエージェントがワークスペースをサポートするように設定する必要があります。

エージェントの設定を更新するには:

1. フォークしたリポジトリで、.gitlab/agents/gitlab-workspaces-agentk-eks/config.yamlファイルを開きます。

   config.yamlファイルを含むディレクトリは、Kubernetes向けGitLabエージェントのトークンを作成するステップで作成したエージェント名と一致している必要があります。

2. 次の必須フィールドでファイルを更新します:

   remote_development:
     enabled: true
     dns_zone: "workspaces.example.dev"  # Replace with your domain

   その他の設定オプションについては、ワークスペースの設定を参照してください。

3. これらの変更をリポジトリにコミットしてプッシュします。

パイプラインを実行する

インフラストラクチャをデプロイする時が来ました。CI/CDパイプラインを実行して、AWSに必要なすべてのリソースを作成します。

パイプラインを実行するには:

1. GitLabプロジェクトで新しいパイプラインを作成します:
   1. 左サイドバーで、ビルド > パイプラインを選択します。
   2. 新しいパイプラインを選択し、再度新しいパイプラインを選択して確認します。
2. planジョブが成功したことを確認し、applyジョブを手動でトリガーします。

OpenTofuコードが実行されると、AWSに次のリソースが作成されます:

• Virtual Private Cloud（VPC）。
• Amazon Elastic Kubernetes Service（EKS）クラスター。
• Kubernetes向けGitLabエージェントHelmリリース。
• GitLabワークスペースプロキシHelmリリース。
• Ingress NGINX Helmリリース。

素晴らしい！インフラストラクチャが現在デプロイされています。これには時間がかかる場合があります。

DNSレコードを設定する

インフラストラクチャがデプロイされたので、新しい環境を指すようにDNSレコードを設定する必要があります。

DNSレコードを設定するには:

1. パイプラインの出力からIngress-NGINXロードバランサーのアドレスを取得します:

   kubectl get services -n ingress-nginx ingress-nginx-controller

2. ドメインをこのアドレスにポイントするDNSレコードを作成します。例:

   • workspaces.example.dev → ロードバランサーのIPアドレス
   • *.workspaces.example.dev → ロードバランサーのIPアドレス

エージェントを承認する

次に、Kubernetes向けGitLabエージェントがGitLabインスタンスに接続することを承認します。

エージェントを承認するには:

1. 上部のバーで、検索または移動先を選択して、グループを見つけます。
2. 左サイドバーで、設定 > ワークスペースを選択します。
3. グループエージェントセクションで、すべてのエージェントタブを選択します。
4. 利用可能なエージェントのリストから、ステータスがブロック済みのエージェントを見つけて、許可を選択します。
5. 確認ダイアログで、エージェントを許可するを選択します。

ワークスペースを作成してセットアップを確認する

最後に、テストワークスペースを作成して、すべてが正常に機能していることを確認しましょう。

ワークスペースのセットアップを確認するには:

1. ワークスペースを作成するの手順に従って、新しいワークスペースを作成します。
2. プロジェクトから、コードを選択します。
3. ワークスペース名を選択します。
4. Web IDEを開く、ターミナルにアクセスする、またはプロジェクトファイルを変更することで、ワークスペースを操作します。

おつかれさまでした。AWS上にGitLabワークスペースインフラストラクチャを正常にセットアップしました。これで、ユーザーは自分のプロジェクト用に開発ワークスペース環境を作成できるようになりました。

イシューが発生した場合は、ログで詳細を確認し、ワークスペースのトラブルシューティングを参照してガイダンスを得てください。

関連トピック

• ワークスペース
• ワークスペースを設定する
• ワークスペースの設定
• チュートリアル: 任意のユーザーIDをサポートするカスタムワークスペースイメージを作成する