Skip to main content

GitLab ci-cd でコンテナデプロイを自動化する方法

2026年5月27日by Kubo Team #GitLab #ci-cd #Kubernetes #コンテナ #Auto DevOps #デプロイ自動化

GitLab ci-cd は、月間 4 億分以上のパイプライン実行を処理し、3,000 万人以上の開発者に利用されている統合 DevOps プラットフォームです。ソースコード管理、ci-cd、コンテナレジストリ、セキュリティスキャンが一体化されており、Kubernetes へのコンテナデプロイを効率的に自動化できます。Kubo は GitLab ci-cd との連携にも対応しており、エンタープライズグレードのデプロイパイプラインを構築できます。本記事では、GitLab ci-cd によるコンテナデプロイの実践的な手順を解説します。

GitLab Kubernetes Agent によるセキュアなクラスタ接続

従来の Kubernetes 連携では、クラスタの API サーバーをインターネットに公開する必要がありましたが、GitLab Kubernetes Agent はクラスタ内部からの接続を確立することで、セキュリティを大幅に向上させています。

Agent のアーキテクチャ

GitLab Agent は Pull ベースのアーキテクチャ を採用しています。Agent がクラスタ内で動作し、GitLab サーバーに対してアウトバウンド接続を確立します。これにより、Kubernetes API サーバーを外部に公開する必要がありません。

Agent の設定手順

  1. Agent の登録: GitLab プロジェクトで Agent を登録し、トークンを取得
  2. Helm でのインストール:
bash
helm repo add gitlab https://charts.gitlab.io
helm repo update
helm upgrade --install gitlab-agent gitlab/gitlab-agent \
  --namespace gitlab-agent --create-namespace \
  --set config.token=<agent-token> \
  --set config.kasAddress=wss://kas.gitlab.com
  1. Agent 設定ファイル (.gitlab/agents/<agent-name>/config.yaml):
yaml
ci_access:
  projects:
    - id: your-group-your-project
  groups:
    - id: your-group

最大 500 のプロジェクトまたはグループを 1 つの Agent に紐づけられます。

Impersonation によるアクセス制御

GitLab の公式ドキュメントによれば、デフォルトでは ci-cd ジョブは Agent インストール時の ServiceAccount の全権限を継承します。本番環境では必ず Impersonation を設定し、ジョブごとに最小権限を適用してください。

yaml
ci_access:
  projects:
    - id: your-group-your-project
      default_namespace: production
      access_as:
        impersonate:
          username: gitlab-ci-deploy
          groups:
            - deployers

Captain.AI では、このような複雑なアクセス制御設定も AI が支援します。

.gitlab-ci.yml によるパイプライン構築

GitLab ci-cd のパイプラインは .gitlab-ci.yml で定義します。コンテナデプロイの典型的なパイプライン構成を見ていきましょう。

基本パイプライン構成

yaml
stages:
  - build
  - test
  - scan
  - deploy-staging
  - deploy-production

variables:
  IMAGE_TAG: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
  KUBE_CONTEXT: your-group/your-project:production-agent

build:
  stage: build
  image: docker:27
  services:
    - docker:27-dind
  script:
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
    - docker build -t $IMAGE_TAG .
    - docker push $IMAGE_TAG

test:
  stage: test
  image: $IMAGE_TAG
  script:
    - npm ci
    - npm test

container-scan:
  stage: scan
  image:
    name: aquasec/trivy:latest
    entrypoint: [""]
  script:
    - trivy image --exit-code 1 --severity HIGH,CRITICAL $IMAGE_TAG

deploy-staging:
  stage: deploy-staging
  image:
    name: bitnami/kubectl:latest
    entrypoint: [""]
  script:
    - kubectl config use-context $KUBE_CONTEXT
    - kubectl set image deployment-my-app app=$image_tag -n staging
    - kubectl rollout status deployment-my-app -n staging
  environment:
    name: staging

deploy-production:
  stage: deploy-production
  image:
    name: bitnami/kubectl:latest
    entrypoint: [""]
  script:
    - kubectl config use-context $KUBE_CONTEXT
    - kubectl set image deployment-my-app app=$image_tag -n production
    - kubectl rollout status deployment-my-app -n production
  environment:
    name: production
  when: manual
  only:
    - main

GitLab Container Registry の活用

GitLab には組み込みのコンテナレジストリが含まれており、追加のレジストリサービスを構築する必要がありません。$CI_REGISTRY、$CI_REGISTRY_USER、$CI_REGISTRY_PASSWORD といった定義済み変数で、シームレスに認証できます。

Auto DevOps による自動パイプライン

GitLab Auto DevOps は、.gitlab-ci.yml を一切書かなくても、アプリケーションの言語とフレームワークを自動検出してパイプラインを構築する機能です。

Auto DevOps のステージ

ステージ機能ツール
Auto BuildDockerfile またはビルドパック検出Cloud Native Buildpacks
Auto Test言語固有のテスト実行言語固有ツール
Auto Code Qualityコード品質分析Code Climate
Auto SAST静的セキュリティテストGitLab SAST
Auto Container Scanningコンテナ脆弱性スキャンTrivy
Auto DeployKubernetes デプロイHelm
Auto Monitoring実行時監視Prometheus

Kubernetes Agent との連携

Auto DevOps で Kubernetes Agent を使用する場合、KUBE_CONTEXT 変数でエージェントのコンテキストを指定します。

yaml
# ci-cd Variables で設定
KUBE_CONTEXT: your-group/your-project:staging-agent  # ステージング用
# production 環境では別の Agent を指定可能

Kubo のマネージド環境では、Auto DevOps の設定が事前最適化されており、プロジェクト作成後すぐに自動パイプラインを開始できます。

マルチ環境デプロイ戦略

実践的なデプロイでは、環境ごとに異なる設定と承認フローが必要です。

環境スコープ変数

yaml
# GitLab ci-cd Variables（UI で設定）
# Environment: staging
REPLICAS: 1
DB_HOST: staging-db.internal

# Environment: production
REPLICAS: 3
DB_HOST: production-db.internal

Review Apps による動的環境

yaml
review:
  stage: deploy-staging
  script:
    - kubectl config use-context $KUBE_CONTEXT
    - helm upgrade --install review-$ci_commit_ref_slug .-chart \
        --namespace review \
        --set image.tag=$CI_COMMIT_SHA \
        --set ingress.host=$CI_COMMIT_REF_SLUG.review.example.com
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    url: https://$CI_COMMIT_REF_SLUG.review.example.com
    on_stop: stop-review
  only:
    - merge_requests

stop-review:
  stage: deploy-staging
  script:
    - kubectl config use-context $KUBE_CONTEXT
    - helm uninstall review-$CI_COMMIT_REF_SLUG --namespace review
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    action: stop
  when: manual

マージリクエストごとに動的な Review 環境が作成され、レビュアーが実際のアプリケーションを確認できます。マージ後に自動または手動でクリーンアップされます。

パイプラインの高速化とコスト最適化

キャッシュ戦略

yaml
build:
  stage: build
  cache:
    key: $CI_COMMIT_REF_SLUG
    paths:
      - node_modules/
      - .npm/
  script:
    - npm ci --cache .npm --prefer-offline
    - npm run build

DAG（Directed Acyclic Graph）による並列化

yaml
stages:
  - build
  - test
  - deploy

lint:
  stage: test
  needs: []  # build を待たずに実行
  script:
    - npm run lint

unit-test:
  stage: test
  needs: ["build"]
  script:
    - npm test

e2e-test:
  stage: test
  needs: ["build"]
  script:
    - npm run e2e

needs キーワードで DAG パイプライン を構築し、不要な待機時間を排除します。

GitLab Runner のスケーリング

Amazon EKS Auto Mode との統合により、Spot インスタンスの活用で最大 90% のコスト削減が可能です。Kubo でも同様のランナー最適化が組み込まれています。

まとめ: Kubo で GitLab ci-cd を始めよう

GitLab ci-cd は、統合 DevOps プラットフォームとしてコンテナデプロイの自動化に強力な機能を提供します。Kubernetes Agent によるセキュアな接続、Auto DevOps による自動パイプライン、Review Apps による動的環境など、エンタープライズグレードのデプロイフローを実現できます。

Kubo は GitLab ci-cd との統合を標準サポートしており、Agent の設定からマルチ環境デプロイまで、スムーズに導入できます。Captain.AI の AI アシスタントがパイプラインの最適化を支援し、GitLab ci-cd の生産性をさらに引き上げます。コンテナデプロイの自動化に取り組みたい方は、ぜひお問い合わせください。

← Back to all posts