senior-devops

シニア DevOps

最新のツールとベストプラクティスを備えた、シニア DevOps 向けの包括的なツールキットです。

クイックスタート

主な機能

このスキルでは、自動化スクリプトを通じて3つの主要な機能を提供します。

# Script 1: Pipeline Generator — scaffolds CI/CD pipelines for GitHub Actions or CircleCI
python scripts/pipeline_generator.py ./app --platform=github --stages=build,test,deploy

# Script 2: Terraform Scaffolder — generates and validates IaC modules for AWS/GCP/Azure
python scripts/terraform_scaffolder.py ./infra --provider=aws --module=ecs-service --verbose

# Script 3: Deployment Manager — generates deployment manifests + runbooks with rollback support
python3 scripts/deployment_manager.py deploy --env=staging --image=app:1.2.3 --strategy=blue-green --verbose --json

主な機能

1. パイプラインジェネレーター

GitHub Actions または CircleCI 向けの CI/CD パイプライン設定をひな形から作成します。ビルド、テスト、セキュリティスキャン、デプロイの各ステージを含みます。

例 — GitHub Actions のワークフロー：

# .github/workflows/ci.yml
name: CI/CD Pipeline
on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npm run lint
      - run: npm test -- --coverage
      - name: Upload coverage
        uses: codecov/codecov-action@v4

  build-docker:
    needs: build-and-test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build and push image
        uses: docker/build-push-action@v5
        with:
          push: ${{ github.ref == 'refs/heads/main' }}
          tags: ghcr.io/${{ github.repository }}:${{ github.sha }}

  deploy:
    needs: build-docker
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - name: Deploy to ECS
        run: |
          aws ecs update-service \
            --cluster production \
            --service app-service \
            --force-new-deployment

使用方法：

python scripts/pipeline_generator.py <project-path> --platform=github|circleci --stages=build,test,deploy

2. Terraform スキャフォルダー

Terraform モジュールを生成、検証し、プランを作成します。モジュール構造の一貫性を保ち、apply の前に必ず terraform validate と terraform plan を実行します。

例 — AWS ECS サービスモジュール：

# modules/ecs-service/main.tf
resource "aws_ecs_task_definition" "app" {
  family                   = var.service_name
  requires_compatibilities = ["FARGATE"]
  network_mode             = "awsvpc"
  cpu                      = var.cpu
  memory                   = var.memory

  container_definitions = jsonencode([{
    name      = var.service_name
    image     = var.container_image
    essential = true
    portMappings = [{
      containerPort = var.container_port
      protocol      = "tcp"
    }]
    environment = [for k, v in var.env_vars : { name = k, value = v }]
    logConfiguration = {
      logDriver = "awslogs"
      options = {
        awslogs-group         = "/ecs/${var.service_name}"
        awslogs-region        = var.aws_region
        awslogs-stream-prefix = "ecs"
      }
    }
  }])
}

resource "aws_ecs_service" "app" {
  name            = var.service_name
  cluster         = var.cluster_id
  task_definition = aws_ecs_task_definition.app.arn
  desired_count   = var.desired_count
  launch_type     = "FARGATE"

  network_configuration {
    subnets          = var.private_subnet_ids
    security_groups  = [aws_security_group.app.id]
    assign_public_ip = false
  }

  load_balancer {
    target_group_arn = aws_lb_target_group.app.arn
    container_name   = var.service_name
    container_port   = var.container_port
  }
}

使用方法：

python scripts/terraform_scaffolder.py <target-path> --provider=aws|gcp|azure --module=ecs-service|gke-deployment|aks-service [--verbose]

3. デプロイマネージャー

ブルー／グリーンまたはローリング戦略向けの Kubernetes デプロイメントマニフェストと、順序立てた kubectl ランブックを生成します。トラフィック切り替え前のヘルスチェックゲートと、ロールバック用ランブックも含みます。このツールはマニフェストを書き込み、コマンドを表示しますが、クラスターに適用することはありません。そのため、すべての変更を人が確認できます。

例 — Kubernetes のブルー／グリーンデプロイ（blue-slot 固有の要素）：

# k8s/deployment-blue.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-blue
  labels:
    app: myapp
    slot: blue      # slot label distinguishes blue from green
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
      slot: blue
  template:
    metadata:
      labels:
        app: myapp
        slot: blue
    spec:
      containers:
        - name: app
          image: ghcr.io/org/app:1.2.3
          readinessProbe:       # gate: pod must pass before traffic switches
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 10
            periodSeconds: 5
          resources:
            requests:
              cpu: "250m"
              memory: "256Mi"
            limits:
              cpu: "500m"
              memory: "512Mi"

使用方法：

python scripts/deployment_manager.py deploy \
  --env=staging|production \
  --image=app:1.2.3 \
  --strategy=blue-green|rolling \
  --health-check-url=https://app.example.com/healthz

python scripts/deployment_manager.py rollback --env=production --to-version=1.2.2
python scripts/deployment_manager.py --analyze --env=production   # audit current state

リソース

• パターンリファレンス：references/cicd_pipeline_guide.md — CI/CD パターン、ベストプラクティス、アンチパターンの詳細
• ワークフローガイド：references/infrastructure_as_code.md — IaC の手順、最適化、トラブルシューティング
• 技術ガイド：references/deployment_strategies.md — デプロイ戦略の設定、セキュリティ上の考慮事項、スケーラビリティ
• ツールスクリプト：scripts/ ディレクトリ

開発ワークフロー

1. インフラストラクチャの変更（Terraform）

# Scaffold or update module
python scripts/terraform_scaffolder.py ./infra --provider=aws --module=ecs-service --verbose

# Validate and plan — review diff before applying
terraform -chdir=infra init
terraform -chdir=infra validate
terraform -chdir=infra plan -out=tfplan

# Apply only after plan review
terraform -chdir=infra apply tfplan

# Verify resources are healthy
aws ecs describe-services --cluster production --services app-service \
  --query 'services[0].{Status:status,Running:runningCount,Desired:desiredCount}'

2. アプリケーションのデプロイ

# Generate or update pipeline config
python scripts/pipeline_generator.py . --platform=github --stages=build,test,security,deploy

# Build and tag image
docker build -t ghcr.io/org/app:$(git rev-parse --short HEAD) .
docker push ghcr.io/org/app:$(git rev-parse --short HEAD)

# Deploy with health-check gate
python scripts/deployment_manager.py deploy \
  --env=production \
  --image=app:$(git rev-parse --short HEAD) \
  --strategy=blue-green \
  --health-check-url=https://app.example.com/healthz

# Verify pods are running
kubectl get pods -n production -l app=myapp
kubectl rollout status deployment/app-blue -n production

# Switch traffic after verification
kubectl patch service app-svc -n production \
  -p '{"spec":{"selector":{"slot":"blue"}}}'

3. ロールバック手順

# Immediate rollback via deployment manager
python scripts/deployment_manager.py rollback --env=production --to-version=1.2.2

# Or via kubectl
kubectl rollout undo deployment/app -n production
kubectl rollout status deployment/app -n production

# Verify rollback succeeded
kubectl get pods -n production -l app=myapp
curl -sf https://app.example.com/healthz || echo "ROLLBACK FAILED — escalate"

マルチクラウドの相互参照

クラウド固有の詳細については、以下の関連スキルを使用してください。

スキル	クラウド	使用する場面
aws-solution-architect	AWS	ECS/EKS、Lambda、VPC 設計、コスト最適化
azure-cloud-architect	Azure	AKS、App Service、Virtual Networks、Azure DevOps
gcp-cloud-architect	GCP	GKE、Cloud Run、VPC、Cloud Build (近日公開)

マルチクラウドと単一クラウドの選択：

• 単一クラウド（デフォルト）— 運用の複雑さを軽減し、マネージドサービスとの統合を深め、コミットメント割引によるコスト削減効果を高めます
• マルチクラウド — コンプライアンス／データレジデンシーの要件、異なるクラウドを利用する企業の買収、または各プロバイダーの最適なサービスの組み合わせが必要な場合（例：コンピューティングに AWS、ML に GCP）に必要です
• ハイブリッド — オンプレミスとクラウドの併用です。規制対象のワークロードをオンプレミスに置く必要がある一方、バーストワークロードや非機密ワークロードはクラウドで実行する場合に使用します

まずは単一クラウドから始めてください。理論上の冗長性のためではなく、具体的なビジネス上またはコンプライアンス上の要件がある場合にのみ、2つ目のクラウドを追加してください。

---

クラウドに依存しない IaC

Terraform / OpenTofu（デフォルトの選択肢）

Terraform（またはそのオープンソースフォークである OpenTofu）は、ほとんどのチームに推奨される IaC ツールです。

• AWS、Azure、GCP、その他3,000以上のプロバイダーで共通の言語（HCL）を使用できます
• リモートバックエンド（S3、GCS、Azure Blob）によるステート管理に対応しています
• apply 前にプランを確認するワークフローにより、予期しないドリフトを防ぎます
• モジュール構造、ステートの分離、CI/CD との統合については、terraform-patterns を参照してください

Pulumi（プログラミング言語による IaC）

チームが HCL よりも TypeScript、Python、Go、または C# を強く希望する場合は、Pulumi を選択してください。

• 完全なプログラミング言語なので、ループ、条件分岐、単体テストを標準で利用できます
• Terraform と同等のクラウドプロバイダーをカバーしています
• HCL の習得に抵抗がある開発チームでも、オンボーディングが容易です

クラウドネイティブな IaC を使うタイミング

ツール	使用するタイミング
CloudFormation	AWS のみを利用している場合。AWS ネイティブのサポート（StackSets、Service Catalog）が必要な場合
Bicep	Azure のみを利用している場合。ARM テンプレートよりもシンプルな構文を使いたい場合
Cloud Deployment Manager	GCP のみを利用している場合。まれです。ほとんどの GCP チームは Terraform を好みます

経験則： 単一のクラウドに完全にコミットしており、かつクラウドネイティブツールに Terraform では再現できない機能（例：AWS Service Catalog との統合）がある場合を除き、Terraform/OpenTofu を使用してください。

---

トラブルシューティング

包括的なトラブルシューティングのセクションについては、references/deployment_strategies.md を確認してください。