EKSにGitLab環境をHelmを使ってデプロイしてみた(2025版)

佐藤雅樹
2025.02.03
この記事で最終的に実現できることは、ほぼ以下の記事と同じです。
https://dev.classmethod.jp/articles/deploy-the-gitlab-on-eks-with-helm/
GitLab側もアップデートがあり、上記の記事が作成された時点より簡単にデプロイできました。
ドキュメントを参考に、GitLabをEKS上にインストールしてみます。
Installing GitLab by using Helm | GitLab
 前提条件手順を実行するには、以下のツールが必要です。
kubectl
Helm
eksctl
AWS CLI
GitLabを公開し、アクセスするには、ドメインも必要です。
GitLab chart prerequisites | GitLab
 注意事項この記事では、デフォルトのHelmチャートをベースにしています。
デフォルトのHelmチャート構成は、本番環境向けではありません。
本番環境はリファレンスアーキテクチャに沿った形で構成することをお勧めします。
 EKS Clusterの構築Preparing EKS resources for the GitLab chart | GitLab
 EKS Cluster作成EKS Cluster作成用のスクリプトが用意されています。
スクリプトがあるリポジトリをCloneします。
その後、Cloneしたリポジトリに移動します。
git clone git@gitlab.com:gitlab-org/charts/gitlab.git
cd gitlab
任意の手段でAWS認証情報コンソールにセットします。
#例
export AWS_ACCESS_KEY_ID=<アクセスキー>
export AWS_SECRET_ACCESS_KEY=<シークレットアクセスキー>
export AWS_SESSION_TOKEN=<セッショントークン>
スクリプトを実行します。
Cluster名やRegion等引数を渡すことで、作成するクラスターの設定ができます。
 ./scripts/eks_bootstrap_script -m t3.xlarge -c gitlab-cluster-blog -r us-east-1 up
少しでも料金を抑えるため、インスタンスタイプを変更してクラスターを作成しました。(デフォルトは、m5.xlarge)
Cluster名もブログ用とわかりやすいように、gitlab-cluster-blogとしました。
ちなみに、スクリプトの引数はhelpで確認できます。
./scripts/eks_bootstrap_script help
 EBS CSIアドオンインストール永続ボリュームの管理のために、EBS CSIアドオンをインストールします。
以下のコマンドを実行します。
./scripts/eks_bootstrap_script -m t3.xlarge -c gitlab-cluster-blog -r us-east-1 add_ebs_csi_driver
コマンドを実行することで、以下が行われます。
必要なServiceAccount・IAM Role作成・紐づけ
EBS CSIアドオンのインストール
 ALB Controllerのインストール今回の構成では、GitLabをALBを使用して公開します。
ALB Ingressを利用するために、ALB Controllerをインストールします。
手順は以下のドキュメントの通りです。
AWS Load Balancer Controller で Helm をインストールする - Amazon EKS
 ACMの設定HTTPSで接続するために、証明書が必要です。
ACMでパブリックなワイルドカード証明書を発行します。(利用ドメインがexample.comだったら、*.example.comで発行)
ACM 証明書を作成する - Research and Engineering Studio
 GitLabのインストールHelmを使って、GitLabをインストールします。
以下のファイルを用意します。
「ドメイン名」と「ACM ARN」は環境にあったものに置き換えてください。
 values.yaml
nginx-ingress:
  enabled: false
global:
  hosts:
    domain: <ドメイン名>
  ingress:
    # Common annotations used by kas, registry, and webservice
    annotations:
      alb.ingress.kubernetes.io/backend-protocol: HTTP
      alb.ingress.kubernetes.io/certificate-arn: <ACM ARN>
      alb.ingress.kubernetes.io/group.name: gitlab
      alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS": 443}]'
      alb.ingress.kubernetes.io/scheme: internet-facing
      alb.ingress.kubernetes.io/target-type: ip
      kubernetes.io/ingress.class: alb
      nginx.ingress.kubernetes.io/connection-proxy-header: "keep-alive"
    class: none
    configureCertmanager: false
    enabled: true
    path: /*
    pathType: ImplementationSpecific
    provider: aws
    tls:
      enabled: false
gitlab:
  kas:
    enabled: true
    ingress:
      # Specific annotations needed for kas service to support websockets
      annotations:
        alb.ingress.kubernetes.io/healthcheck-path: /liveness
        alb.ingress.kubernetes.io/healthcheck-port: "8151"
        alb.ingress.kubernetes.io/healthcheck-protocol: HTTP
        alb.ingress.kubernetes.io/load-balancer-attributes: idle_timeout.timeout_seconds=4000,routing.http2.enabled=false
        alb.ingress.kubernetes.io/target-group-attributes: stickiness.enabled=true,stickiness.lb_cookie.duration_seconds=86400
        alb.ingress.kubernetes.io/target-type: ip
        kubernetes.io/tls-acme: "true"
        nginx.ingress.kubernetes.io/connection-proxy-header: "keep-alive"
        nginx.ingress.kubernetes.io/x-forwarded-prefix: "/path"
    # k8s services exposed via an ingress rule to an ELB need to be of type NodePort
    service:
      type: NodePort
  webservice:
    enabled: true
    service:
      type: NodePort
  # gitlab-shell (ssh) needs an NLB
  gitlab-shell:
    enabled: false
registry:
  enabled: false
Helmリポジトリの追加及び、上記ファイルを使ってHelmインストールを実行します。
helm repo add gitlab https://charts.gitlab.io/
helm install gitlab gitlab/gitlab -f values.yaml
Test the GitLab chart on GKE or EKS | GitLab
Configure the GitLab Helm charts | GitLab
examples/aws/alb-full.yaml · master · GitLab.org / charts / GitLab Chart · GitLab
 Route53レコードにALBを登録インストール完了後に、以下のコマンドを実行するとALBのDNS名が表示されます。
kubectl get ingress -lrelease=gitlab

NAME                        CLASS    HOSTS                                ADDRESS                                                        PORTS   AGE
gitlab-kas                  <none>   kas.example.com      k8s-gitlab-41213c1842-1373918712.us-east-1.elb.amazonaws.com   80      17m
gitlab-minio                <none>   minio.example.com   k8s-gitlab-41213c1842-1373918712.us-east-1.elb.amazonaws.com   80      17m
gitlab-webservice-default   <none>   gitlab.example.com  k8s-gitlab-41213c1842-1373918712.us-east-1.elb.amazonaws.com   80      17m
Route53でレコードを作成して、ALBをエイリアスレコードで登録します。
レコード名: gitlab
レコードタイプ: A
エイリアス: はい
値: <ALB DNS名>
 アクセスの確認rootユーザーでログインします。
初期パスワードは以下のコマンドで取得できます。
kubectl get secret gitlab-gitlab-initial-root-password -ojsonpath='{.data.password}' | base64 --decode ; echo
gitlab.<ドメイン名>にアクセスし、以下の情報でログインします。
ユーザー: root
パスワード: 上記のコマンドの結果
無事にログインできました。
 後片付け helmでデプロイしたリソースの削除helm uninstall gitlab
kubectl delete pvc,pv -l release=gitlab
 EKS Cluster削除./scripts/eks_bootstrap_script -c gitlab-cluster-blog -r us-east-1 down
 ACM・レコード削除必要に応じて、ACMで作成した証明書やGitlab用のRoute53 レコードを削除してください。
 おわりにEKS上にGitLabをインストールしてみました。
今回はALBで公開してみることを目標に最小限の設定を行いました。
GitLabは多機能で、Helmチャート側で対応するリソースを起動するか制御できます。
機能によっては追加でAWSリソースが必要だったりします。(例: GitLab ShellでサーバーにSSHアクセスするために、NLBが必要等)
デフォルトでは、すべてのサービスがクラスター上にデプロイされます。
今回作った構成では「永続データをどう扱うか」といった課題があるため、ドキュメントを読みつつ、この辺も検証して行きたいと思います。
以上、AWS事業本部の佐藤(@chari7311)でした。