devops-automation

DevOps の自動化

GitHub Actions ワークフローの構成

name: CI/CD
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: 'npm'
      - run: npm ci
      - run: npm run lint

  test:
    runs-on: ubuntu-latest
    needs: lint
    strategy:
      matrix:
        node-version: [20, 22]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
          cache: 'npm'
      - run: npm ci
      - run: npm test -- --coverage
      - uses: actions/upload-artifact@v4
        with:
          name: coverage-${{ matrix.node-version }}
          path: coverage/

  deploy:
    runs-on: ubuntu-latest
    needs: test
    if: github.ref == 'refs/heads/main'
    environment: production
    steps:
      - uses: actions/checkout@v4
      - run: ./deploy.sh

主なパターン：

• concurrency を使って古い実行をキャンセルする
• セットアップアクションの cache オプションで依存関係をキャッシュする
• ジョブの依存関係には needs を使う
• environment の保護ルールでデプロイを制御する
• バージョンをまたいだテストにはマトリックスを使う

Docker のマルチステージビルド

FROM node:22-alpine AS deps
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci --production

FROM node:22-alpine AS builder
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci
COPY . .
RUN npm run build

FROM node:22-alpine AS runner
WORKDIR /app
RUN addgroup -g 1001 appgroup && adduser -u 1001 -G appgroup -S appuser
COPY --from=deps /app/node_modules ./node_modules
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/package.json ./
USER appuser
EXPOSE 3000
HEALTHCHECK --interval=30s --timeout=3s CMD wget -qO- http://localhost:3000/health || exit 1
CMD ["node", "dist/server.js"]

ルール：

• 具体的なイメージタグを使い、latest は決して使わない
• 非 root ユーザーとして実行する
• 最終ステージには必要なファイルだけをコピーする
• オーケストレーターとの連携用に HEALTHCHECK を追加する
• .dockerignore を使って node_modules、.git、テストを除外する

Kubernetes デプロイメントマニフェスト

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server
  labels:
    app: api-server
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api-server
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  template:
    metadata:
      labels:
        app: api-server
    spec:
      containers:
        - name: api
          image: registry.example.com/api:v1.2.3
          ports:
            - containerPort: 3000
          resources:
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              cpu: 500m
              memory: 512Mi
          readinessProbe:
            httpGet:
              path: /health
              port: 3000
            initialDelaySeconds: 5
            periodSeconds: 10
          livenessProbe:
            httpGet:
              path: /health
              port: 3000
            initialDelaySeconds: 15
            periodSeconds: 20
          env:
            - name: DATABASE_URL
              valueFrom:
                secretKeyRef:
                  name: api-secrets
                  key: database-url

リソースのリクエストと上限は必ず設定してください。readiness プローブと liveness プローブを必ず定義してください。ダウンタイムなしでデプロイするには、maxUnavailable: 0 を指定してください。

Helm チャートの構成

chart/
  Chart.yaml
  values.yaml
  values-staging.yaml
  values-production.yaml
  templates/
    deployment.yaml
    service.yaml
    ingress.yaml
    hpa.yaml
    _helpers.tpl

# values.yaml
replicaCount: 2
image:
  repository: registry.example.com/api
  tag: latest
  pullPolicy: IfNotPresent
resources:
  requests:
    cpu: 100m
    memory: 128Mi
  limits:
    cpu: 500m
    memory: 512Mi
ingress:
  enabled: true
  host: api.example.com
autoscaling:
  enabled: true
  minReplicas: 2
  maxReplicas: 10
  targetCPUUtilization: 70

環境ごとに values-{env}.yaml のオーバーライドを使ってください。helm lint でチャートをリントしてください。デプロイ前に helm template でテストしてください。

ArgoCD の GitOps パターン

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: api-server
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/org/k8s-manifests
    targetRevision: main
    path: apps/api-server
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

GitOps の原則：

• クラスターの状態を管理する唯一の信頼できる情報源は Git です
• すべての変更は PR を通じて行います（本番環境で kubectl apply を実行しない）
• ArgoCD が Git からクラスターへ自動同期します
• 手動によるクラスター変更を元に戻すには、selfHeal を有効にします
• アプリケーションコードのリポジトリとデプロイメントマニフェストのリポジトリを分けます

モニタリングスタック

# Prometheus ServiceMonitor
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: api-server
spec:
  selector:
    matchLabels:
      app: api-server
  endpoints:
    - port: metrics
      interval: 15s
      path: /metrics

公開する主なメトリクス：

• http_request_duration_seconds（ヒストグラム）- ルートとステータス別のリクエスト遅延
• http_requests_total（カウンター）- ルートとステータス別のリクエスト数
• process_resident_memory_bytes（ゲージ）- メモリ使用量
• db_query_duration_seconds（ヒストグラム）- データベースクエリの遅延

次の場合にアラートを発行します：エラー率が 1% 超、P99 遅延が 2 秒超、メモリ使用量が上限の 80% 超、10 分間のポッド再起動が 3 回超。

パイプラインのベストプラクティス

1. CI は 10 分以内に収めます（ジョブを並列化し、積極的にキャッシュします）
2. テストの前にリントと型チェックを実行します
3. PR のプレビューには一時的な環境を使います
4. すべてのアクションのバージョンはタグではなく SHA に固定します
5. シークレットは GitHub Secrets に保存し、ワークフローファイルには決して記載しません
6. クラウドプロバイダーの認証には OIDC を使います（長期間有効なキーは使いません）
7. イメージには latest ではなく git SHA のタグを付けます
8. CI でコンテナーイメージに対するセキュリティスキャン（Trivy、Snyk）を実行します