mcpField
G
gitlab-ci-patterns

gitlab-ci-patterns

github.com/ormus-solutionsクラウド・DevOps12377 回インストール4 週間前に更新
リポジトリ

gitlab-ci-patterns について

gitlab-ci-patternsは、GitLab CI/CDパイプラインの設計パターンをまとめたスキルです。自動化に取り組む開発者向けに、ステージ構成、キャッシュ、セキュリティスキャン、KubernetesやGitOpsを含むデプロイを扱います。

主な機能

  1. 01マルチステージパイプラインの構成
  2. 02Dockerのビルドとプッシュ
  3. 03複数環境へのデプロイ
  4. 04Terraformパイプラインのパターン
  5. 05セキュリティスキャンとキャッシュ
  6. 06動的な子パイプライン

活用シーン

  1. 01GitLabでテスト、ビルド、デプロイを自動化
  2. 02GitLabからKubernetesへデプロイ
  3. 03Terraformの検証と適用ステージを構成
  4. 04セキュリティスキャンと依存関係キャッシュを追加

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/ormus-solutions/libreuiux-claude-code --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:latest
  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

複数環境へのデプロイ

.deploy_template: &deploy_template
  image: bitnami/kubectl:latest
  before_script:
    - kubectl config set-cluster k8s --server="$KUBE_URL" --insecure-skip-tls-verify=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:latest
  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

参考ファイル

  • assets/gitlab-ci.yml.template - 完全なパイプラインテンプレート
  • references/pipeline-stages.md - ステージ構成のパターン

ベストプラクティス

  1. 具体的なイメージタグを使用する(node:latest ではなく node:20)
  2. 依存関係を適切にキャッシュする
  3. ビルド成果物にはアーティファクトを使用する
  4. 本番環境には手動承認ゲートを設ける
  5. デプロイ状況の追跡には環境を使用する
  6. マージリクエストパイプラインを有効にする
  7. 定期的なジョブにはパイプラインスケジュールを使用する
  8. セキュリティスキャンを実施する
  9. シークレットには CI/CD 変数を使用する
  10. パイプラインのパフォーマンスを監視する

関連スキル

  • github-actions-templates - GitHub Actions 向け
  • deployment-pipeline-design - アーキテクチャ向け
  • secrets-management - シークレットの取り扱い向け

コメント