gitlab-ci-patterns について
自動テスト、ビルド、デプロイのためにGitLab CI/CDパイプラインを構築するスキルです。ステージ構成、キャッシュ、セキュリティスキャン、Terraform、Kubernetesデプロイ、動的な子パイプラインのパターンを紹介します。
主な機能
- 01複数ステージのパイプライン構成
- 02Dockerのビルドとプッシュのパターン
- 03複数環境へのKubernetesデプロイ
- 04Terraformパイプラインの例
- 05セキュリティスキャンと依存関係のキャッシュ
- 06動的な子パイプライン生成
活用シーン
- 01GitLabでのテストとデプロイの自動化
- 02複数環境へのKubernetesデプロイ
- 03Terraformの検証、計画、適用ステージの実行
- 04セキュリティスキャンの追加とビルド依存関係のキャッシュ
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/ / github.com/ wshobson/ agents --skill gitlab-ci-patternsインストール後、Claude Code で/gitlab-ci-patternsを入力して読み込まれたか確認します。
詳細
GitLab CI パターン
自動テスト、ビルド、デプロイのための包括的な GitLab CI/CD パイプライン パターン。
目的
適切なステージ構成、キャッシュ、デプロイ戦略を備えた効率的な GitLab CI パイプラインを作成します。
使用する場面
- GitLab ベースの CI/CD を自動化する
- マルチステージ パイプラインを実装する
- GitLab Runner を構成する
- GitLab から Kubernetes にデプロイする
- GitOps ワークフローを実装する
基本的なパイプライン構造
stages:
- build
- test
- deploy
variables:
DOCKER_DRIVER: overlay2
DOCKER_TLS_CERTDIR: "/certs"
build:
stage: build
image: node:20
script:
- npm ci
- npm run build
artifacts:
paths:
- dist/
expire_in: 1 hour
cache:
key: ${CI_COMMIT_REF_SLUG}
paths:
- node_modules/
test:
stage: test
image: node:20
script:
- npm ci
- npm run lint
- npm test
coverage: '/Lines\s*:\s*(\d+\.\d+)%/'
artifacts:
reports:
coverage_report:
coverage_format: cobertura
path: coverage/cobertura-coverage.xml
deploy:
stage: deploy
image: bitnami/kubectl:1.31
script:
- kubectl apply -f k8s/
- kubectl rollout status deployment/my-app
only:
- main
environment:
name: production
url: https://app.example.com
Docker ビルドとプッシュ
build-docker:
stage: build
image: docker:24
services:
- docker:24-dind
before_script:
- docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
script:
- docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
- docker build -t $CI_REGISTRY_IMAGE:latest .
- docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
- docker push $CI_REGISTRY_IMAGE:latest
only:
- main
- tags
マルチ環境デプロイ
クラスタの CA 証明書を含む GitLab ファイル変数として KUBE_CA_CERT_FILE を設定し、
保護されたマスク済み CI 変数を通じて KUBE_TOKEN を提供します。ファイル変数には、
kubectl が API サーバー証明書を検証するために使用するパスが含まれます。デプロイ ジョブが
保護されたトークンを読み取れるように、develop と main の両方を保護してください。
.deploy_template: &deploy_template
image: bitnami/kubectl:1.31
before_script:
- kubectl config set-cluster k8s --server="$KUBE_URL" --certificate-authority="$KUBE_CA_CERT_FILE" --embed-certs=true
- kubectl config set-credentials admin --token="$KUBE_TOKEN"
- kubectl config set-context default --cluster=k8s --user=admin
- kubectl config use-context default
deploy:staging:
<<: *deploy_template
stage: deploy
script:
- kubectl apply -f k8s/ -n staging
- kubectl rollout status deployment/my-app -n staging
environment:
name: staging
url: https://staging.example.com
only:
- develop
deploy:production:
<<: *deploy_template
stage: deploy
script:
- kubectl apply -f k8s/ -n production
- kubectl rollout status deployment/my-app -n production
environment:
name: production
url: https://app.example.com
when: manual
only:
- main
Terraform パイプライン
stages:
- validate
- plan
- apply
variables:
TF_ROOT: ${CI_PROJECT_DIR}/terraform
TF_VERSION: "1.6.0"
before_script:
- cd ${TF_ROOT}
- terraform --version
validate:
stage: validate
image: hashicorp/terraform:${TF_VERSION}
script:
- terraform init -backend=false
- terraform validate
- terraform fmt -check
plan:
stage: plan
image: hashicorp/terraform:${TF_VERSION}
script:
- terraform init
- terraform plan -out=tfplan
artifacts:
paths:
- ${TF_ROOT}/tfplan
expire_in: 1 day
apply:
stage: apply
image: hashicorp/terraform:${TF_VERSION}
script:
- terraform init
- terraform apply -auto-approve tfplan
dependencies:
- plan
when: manual
only:
- main
セキュリティ スキャン
include:
- template: Security/SAST.gitlab-ci.yml
- template: Security/Dependency-Scanning.gitlab-ci.yml
- template: Security/Container-Scanning.gitlab-ci.yml
trivy-scan:
stage: test
image: aquasec/trivy:0.58.0
script:
- trivy image --exit-code 1 --severity HIGH,CRITICAL $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
allow_failure: true
キャッシュ戦略
# Cache node_modules
build:
cache:
key: ${CI_COMMIT_REF_SLUG}
paths:
- node_modules/
policy: pull-push
# Global cache
cache:
key: ${CI_COMMIT_REF_SLUG}
paths:
- .cache/
- vendor/
# Separate cache per job
job1:
cache:
key: job1-cache
paths:
- build/
job2:
cache:
key: job2-cache
paths:
- dist/
動的子パイプライン
generate-pipeline:
stage: build
script:
- python generate_pipeline.py > child-pipeline.yml
artifacts:
paths:
- child-pipeline.yml
trigger-child:
stage: deploy
trigger:
include:
- artifact: child-pipeline.yml
job: generate-pipeline
strategy: depend
ベスト プラクティス
- 特定のイメージ タグを使用する (node:latest ではなく node:20)
- 依存関係を適切にキャッシュする
- ビルド出力に成果物を使用する
- 本番環境に手動ゲートを実装する
- デプロイ追跡に環境を使用する
- マージ リクエスト パイプラインを有効にする
- 定期的なジョブにパイプライン スケジュールを使用する
- セキュリティ スキャンを実装する
- シークレットに CI/CD 変数を使用する
- パイプラインのパフォーマンスを監視する
関連スキル
github-actions-templates- GitHub Actions 向けdeployment-pipeline-design- アーキテクチャ向けsecrets-management- シークレットの取り扱い向け
コメント
Markdown 対応