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

このチュートリアルでは、OpenTofu、つまりInfrastructure as Code (IaC) を介したTerraformのオープンソースフォークを使用して、AWS上にGitLabワークスペースのインフラストラクチャをセットアップする方法を説明します。

はじめる前

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

• 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. ワークスペースインフラストラクチャ設定AWSリポジトリに移動します。
2. リポジトリのフォークを作成します。詳細については、フォークを参照してください

AWS認証情報を設定する

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

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

1. IAMユーザーまたはIAMロールを作成します。

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. トークンとKASアドレスを保存して、後で使用できるようにします。
8. 次に進むを選択します。

GitLab OAuthを設定する

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

GitLab OAuthを設定するには:

1. ユーザー設定に移動します:

   1. プロファイル画像を選択し、設定を選択します。

2. 左側のサイドバーで、アプリケーションを選択します。

3. OAuth applications（OAuthアプリケーション）までスクロールダウンします。

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

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

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

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

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

8. 次に進むを選択します。

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 Kubernetesエージェントサーバーのアドレス。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（Amazon EKS）クラスター
• Kubernetes Helmリリース用GitLabエージェント。
• 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をサポートするカスタムワークスペースイメージを作成する