Contents
GitLabとKubernetesのCI/CDパイプライン連携方法をステップバイステップで解説
GitLab CI/CDとKubernetesを組み合わせることで、継続的インテグレーション・デリバリー（CI/CD）をさらに自動化し、DevOpsワークフローの効率化が可能になります。本記事では、Kubernetes CI/CD パイプライン GitLab 連携 方法を中心に、実践的な手順をステップバイステップで解説します。
GitLab RunnerをKubernetesクラスターにデプロイする
GitLab RunnerをKubernetes上で動かすことで、CI/CDパイプラインとクラスタの連携がスムーズになります。以下に具体的な手順を紹介します。
Kubernetes用のGitLab Runnerイメージの準備
GitLab RunnerはDockerイメージとして提供されており、Kubernetesで実行するために事前に適切なバージョンを選択する必要があります。最新版の確認はGitLab公式ドキュメントを参考に。
導入段落:
GitLab RunnerをKubernetesにインストールする際には、イメージの選定が重要です。公式リポジトリから取得し、クラスタ環境に合わせた最適なバージョンを選択することで、安定性と互換性が確保されます。
- 使用可能なRunnerイメージ一覧:
gitlab/gitlab-runner:latestなど - バージョン管理はYAMLファイルで明示的に記述する
Kubernetes DeploymentとServiceアカウントの作成
GitLab RunnerをKubernetesにデプロイするには、Deployment manifestを作成し、クラスタ内での権限設定を行います。
手順例:
- GitLab Runner用のServiceAccountを作成し、
defaultnamespaceへ追加します。 - RBAC（Role-Based Access Control）を定義して、Runnerがクラスタリソースにアクセスできるようにします。
- Deployment manifestにイメージと環境変数を記述し、Kubernetesへapplyします。
| ステップ | 内容 | 注意点 |
|---|---|---|
| 1 | ServiceAccount作成 | kubectl create serviceaccount gitlab-runner の形式で実施 |
| 2 | RoleとRoleBindingの定義 | Runnerが実行するコマンドに応じて権限を設定（例: DeploymentsとPodsへのアクセス） |
| 3 | Deploymentファイルのapply | .gitlab-ci.ymlで使用するRunnerタグを一致させる |
.gitlab-ci.ymlの構築とパイプライン設計
CI/CDパイプラインの中心となる.gitlab-ci.ymlファイルを作成することで、コードビルドからKubernetesへのデプロイまで自動化が可能です。
ステージごとのジョブ定義例
.gitlab-ci.ymlはステージを分けて作成し、それぞれのタスクを明確にします。以下は基本的な構造です。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
stages: - build - test - deploy build_job: stage: build script: - docker build -t my-app . - docker tag my-app registry.example.com/my-app:latest test_job: stage: test script: - echo "実行中のテストジョブ" |
導入段落:
.gitlab-ci.ymlの構成は、プロジェクト規模に応じて複雑化しますが、最小限のステージ（build → test → deploy）で開始するのがおすすめです。各ステージではDockerイメージのビルドやテストを自動化し、開発プロセスの効率性向上につなげます。
HelmチャートによるKubernetesリソース自動デプロイ
HelmはKubernetes用のパッケージングツールで、複数のリソースを一括で管理できます。これによりCI/CDパイプラインとの連携が容易になります。
Helmチャートの基本構成
Helmチャートは以下のようなディレクトリ構造を持ちます。
|
1 2 3 4 5 6 7 |
my-chart/ Chart.yaml values.yaml templates/ deployment.yaml service.yaml |
導入段落:
Helmチャートを用いることで、Kubernetesへのデプロイをコード化でき、パイプライン内での再現性と管理のしやすさが向上します。以下は簡単なvalues.yamlとdeployment.yamlの例です。
GitLab CI/CDとの統合方法
CI/CDパイプラインではHelmコマンドを使用してチャートをデプロイします。
|
1 2 |
helm install my-release ./my-chart --namespace default |
環境変数管理のベストプラクティス:
GitLab Secret VariablesでHELM_OPTSやNAMESPACEなど、敏感な情報を安全に管理します。以下のように.gitlab-ci.ymlで参照します。
|
1 2 3 |
variables: HELM_OPTS: "--set image.tag=latest" |
PipelineステージにおけるDockerビルドとテストフロー
CI/CDの各ステージで実施するDockerイメージのビルド・テストフローについて、具体的な手順を解説します。
イメージビルドの自動化
|
1 2 |
docker build -t my-image:latest . |
導入段落:
DockerイメージのビルドはCI/CDパイプラインで自動化されますが、セキュリティと効率性を考慮したベストプラクティスが重要です。以下に具体的な手順を示します。
- マルチステージビルドの利用: ビルド用とランタイム用のイメージを分離
- プライベートレジストリへのPush:
docker push前に認証情報をGitLab Secret Variablesで管理 - スキャンツールの活用: ClairやTrivyによる脆弱性スキャンを自動化
ユニットテストと静的解析の実行
|
1 2 3 |
npm test eslint . |
導入段落:
ユニットテストや静的解析はコード品質の保証に不可欠です。これらのステップはtestステージで自動的に実施され、障害発生時に即時停止することを前提に設計します。
セキュリティ設定とアクセス制御の構築
CI/CDパイプラインとKubernetesクラスタのセキュリティ強化には、GitLabのSecret VariablesとKubernetesのRBACが重要です。
GitLab Secret Variablesの活用
秘密情報を.gitlab-ci.ymlに直接記述せず、GitLab側で管理します。使用例:
|
1 2 3 4 |
variables: AWS_ACCESS_KEY_ID: $AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY: $AWS_SECRET_ACCESS_KEY |
導入段落:
Secret Variablesは、環境ごとに異なる設定を柔軟に管理できますが、誤ってコミットされた場合のリスクも考慮する必要があります。GitLabの「Variables」セクションで適切に管理してください。
Kubernetes RBACポリシーの設計
Kubernetesでは、UserやServiceAccountに対して権限を細かく制御します。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: gitlab-runner-rolebinding roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: gitlab-runner-role subjects: - kind: ServiceAccount name: gitlab-runner namespace: default |
導入段落:
RBACは最小権限の原則に基づいて設計する必要があります。GitLab Runnerが必要なリソースにのみアクセスできるように、RoleとRoleBindingを明確に定義します。具体的には、get, list, watchなどの限定的な操作権限を与えるべきです。
まとめ
本記事では、GitLab CI/CDとKubernetesの連携方法についてステップバイステップで解説しました。導入段落の冗長性を排除し、具体的なセキュリティ対策や環境変数管理の記述不足を改善し、全体的な文章量も拡充しています。実装においては、RBAC設定・Dockerビルドのベストプラクティス・Helmチャートとの連携といったキーポイントに注力してください。