企业官网建设流程全解析

claude-howto の devops-automation プラグインで学ぶ Kubernetes ロールバック実践ガイド

【免费下载链接】claude-howtoA visual, example-driven guide to Claude Code — from basic concepts to advanced agents, with copy-paste templates that bring immediate value.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-howto

/rollbackコマンドとrollback.shを中心に、Claude Code 上で前回の安定版へ安全にロールバックする 5 ステップの運用フローを解説します。このガイドを読み終えると、devops-automation プラグインが提供するロールバック手順の全体像（対象リビジョンの特定、健全性検証、kubectl rollout undoによる実行、ヘルスチェック、チーム通知）を、実際のスクリプトと連携設定のレベルまで理解し、自前の CI/CD 運用に応用できるようになります。

ロールバックコマンドの位置づけ

rollback.md は、devops-automation プラグインが提供する 4 つのスラッシュコマンド（/deploy・/rollback・/status・/incident）のうち、デプロイ失敗時の復旧を担うコマンド定義です。プラグイン全体の構成は README.md にまとめられており、ロールバックは「自動デプロイ」「ロールバック手順」「ヘルスモニタリング」「インシデント対応」「Kubernetes 統合」という 5 つの機能群の中核のひとつに位置づけられています。

コマンド定義の先頭には、Claude Code のスラッシュコマンドとして認識させるためのフロントマターが付与されています。

--- name: Rollback description: 前回のデプロイへロールバックする ---

• name: スラッシュコマンドの名前。/rollbackとして呼び出されます。
• description: Claude Code がコマンドの用途を理解・提案するために使う説明文。

ロールバックの 5 ステップ全体像

rollback.md は、ロールバックを次の 5 ステップとして定義しています。この順序は「何に戻すかを決める → 戻り先が安全か確認する → 実行する → 検証する → 周知する」という、復旧作業の安全な手順を体現しています。

1. 前回のデプロイを特定— ロールバック対象となるリビジョンを確定する
2. ロールバック先が正常であることを確認— 戻り先のリビジョンが健全な状態であることを検証する
3. ロールバック手順を実行— 実際に前回バージョンへ切り戻す
4. ヘルスチェックを実行— API・DB・Pod の状態を確認し、復旧が完了したことを確かめる
5. チームに通知— ロールバックの実施と結果をチームへ共有する

以降の章では、この各ステップがscripts/rollback.sh や scripts/health-check.sh といった実際のスクリプトでどのように実装されているかを、ソースコードに沿って掘り下げます。

実行環境と前提条件

ロールバックを実行する前に、以下の環境が整っている必要があります（README.md の Requirements / Configuration より）。

• Claude Code 2.1 以上
• Kubernetes CLI（kubectl）がインストール済み
• クラスタへのアクセス権が設定済み

クラスタ接続情報は環境変数で渡します。

export KUBECONFIG=~/.kube/config

プラグイン自体は、Claude Code 内で次のようにインストールします。

/plugin install devops-automation

ステップ 1・3：ロールバック対象の特定と実行（rollback.sh）

rollback.md の「前回のデプロイを特定」と「ロールバック手順を実行」は、scripts/rollback.sh に自動化されています。スクリプト全体を確認してみましょう。

#!/bin/bash set -e echo "⏪ Starting rollback..." ENV=${1:-staging} echo "📦 Target environment: $ENV" # Get previous deployment PREVIOUS=$(kubectl rollout history deployment/app -n $ENV | tail -2 | head -1 | awk '{print $1}') echo "🔄 Rolling back to revision: $PREVIOUS" # Execute rollback kubectl rollout undo deployment/app -n $ENV # Wait for rollback echo "⏳ Waiting for rollback to complete..." kubectl rollout status deployment/app -n $ENV # Health check echo "🏥 Running health checks..." sleep 5 curl -f http://api.$ENV.example.com/health echo "✅ Rollback complete!"

要点 1：set -eによるフェイルファスト

先頭のset -eにより、途中のコマンドが失敗した時点でスクリプト全体が即座に異常終了します。ロールバック作業中にエラーを握りつぶして「不完全な復旧」を放置しないための安全機構です。

要点 2：対象リビジョンの特定

PREVIOUS=$(kubectl rollout history deployment/app -n $ENV | tail -2 | head -1 | awk '{print $1}')

kubectl rollout historyの出力から直前のリビジョン番号を抽出しています。tail -2 | head -1で「最後の行の 1 つ前」つまり現在デプロイされているリビジョンの直前を選び、awk '{print $1}'でリビジョン番号列を取り出します。これにより「何に戻すか」が機械的に確定します。

要点 3：kubectl rollout undoによる切り戻し

kubectl rollout undo deployment/app -n $ENV

Kubernetes のローリングアップデート履歴を使って、アプリケーションを前回のリビジョンへ切り戻します。環境（namespace）は第 1 引数で切り替えでき、デフォルトはstagingです。本番へは/rollback productionのように指定します。

kubectl rollout undo deployment/app -n production

要点 4：完了待ちとヘルスチェック

kubectl rollout statusでロールバックの完了を待機した後、sleep 5でコンテナ起動を待ってから HTTP ヘルスエンドポイントへcurl -fでアクセスし、疎通を確認します。この 1 連の流れが、rollback.md のステップ 3 と 4 に対応します。

ステップ 2：ロールバック先の健全性検証

rollback.md の「ロールバック先が正常であることを確認」は、ロールバック前に戻り先のリビジョンが健全かどうかを確認する工程です。プラグインでは、デプロイ系フロー全体の前後を hooks/pre-deploy.js と hooks/post-deploy.js が担っており、これらが検証の実装例になります。

pre-deploy.jsは kubectl の存在とクラスタ接続を検証します。

// Check if kubectl is installed execSync('which kubectl', { stdio: 'pipe' }); // Check if connected to cluster execSync('kubectl cluster-info', { stdio: 'pipe' });

post-deploy.jsは Pod が Ready になるまで待機し、スモークテストを実行します。

execSync('kubectl wait --for=condition=ready pod -l app=myapp --timeout=300s', { stdio: 'inherit' });

ロールバック運用では、「戻す先のリビジョンが以前正常に動いていたという事実」と「クラスタ自体が今アクセス可能か」を分けて確認するのが実践的なアプローチです。ロールバック前にkubectl cluster-infoでクラスタ疎通を確認し、rollback.sh実行後にpost-deploy.js相当の Pod Ready 待機を行う、という組み合わせが、上記フック群から読み取れる運用パターンです。

ステップ 4：ヘルスチェックの仕組み（health-check.sh）

ステップ 4 の「ヘルスチェックを実行」は、scripts/health-check.sh として独立したスクリプトに切り出されています。ロールバック後に限らず、/statusコマンドの実行やインシデント対応時にも再利用できる設計です。

#!/bin/bash echo "🏥 System Health Check" echo "====================" ENV=${1:-production} # Check API echo -n "API: " if curl -sf http://api.$ENV.example.com/health > /dev/null; then echo "✅ Healthy" else echo "❌ Unhealthy" fi # Check Database echo -n "Database: " if pg_isready -h db.$ENV.example.com > /dev/null 2>&1; then echo "✅ Healthy" else echo "❌ Unhealthy" fi # Check Pods echo -n "Kubernetes Pods: " PODS_READY=$(kubectl get pods -n $ENV --no-headers | grep "Running" | wc -l) PODS_TOTAL=$(kubectl get pods -n $ENV --no-headers | wc -l) echo "$PODS_READY/$PODS_TOTAL ready" echo "===================="

このスクリプトは次の 3 系統をチェックします。

デフォルトの環境はproductionになっている点がrollback.sh（デフォルトstaging）と異なり、本番復旧後の最終確認に使われることを想定した設計であることがうかがえます。ロールバックの成否は「スクリプトが成功したか」ではなく「このヘルスチェックで API・DB・Pod がすべて Healthy と出たか」で判断するのが、このプラグインの運用モデルです。

ステップ 5：チームへの通知とインシデント連携

ステップ 5 の「チームに通知」について、devops-automation プラグインの README ではデプロイワークフロー中に「Slack への通知」を行うことが示されています。ロールバック時も同様に、実施の事実とヘルスチェック結果をチームへ共有するのが想定される運用です。

より大規模な障害時には、commands/incident.md（/incident）を組み合わせることで、agents/incident-commander.md によるインシデント調整、agents/alert-analyzer.md によるシステム健全性分析というサブエージェント群へ引き継ぐ流れになります。ロールバックは単独のコマンドではなく、/status（commands/status.md）や/incidentと連動する「復旧フローの一部」として位置づけられています。

ロールバックを支える Kubernetes MCP 連携

ロールバックを含むデプロイ系フローは、Kubernetes クラスタの状態をリアルタイムに参照しながら進行します。その接続設定が mcp/kubernetes-config.json です。

{ "mcpServers": { "kubernetes": { "command": "npx", "args": ["@modelcontextprotocol/server-kubernetes"], "env": { "KUBECONFIG": "${KUBECONFIG}" } } } }

ここでは@modelcontextprotocol/server-kubernetesを npx で起動し、KUBECONFIG環境変数をそのまま MCP サーバへ渡しています。これにより Claude Code はクラスタの状態（Pod 数、リビジョン履歴、ヘルス状況）を直接参照しながら、rollback.shの実行可否を判断できます。README の「Example Workflow」では、/deploy production実行時に「Kubernetes MCP 経由でデプロイ進行を監視する」流れが示されており、ロールバックも同じ監視基盤を共有すると読み取れます。

デプロイとロールバックの対比で見る運用フロー

ロールバックの位置づけを明確にするため、scripts/deploy.sh のデプロイフローと対比してみます。

#!/bin/bash set -e ENV=${1:-staging} echo "📦 Target environment: $ENV" # Pre-deployment checks npm run lint npm test # Build npm run build # Deploy kubectl apply -f k8s/$ENV/ # Health check sleep 10 curl -f http://api.$ENV.example.com/health echo "✅ Deployment complete!"

両スクリプトは共通の設計パターンを持っています。

• set -eによるフェイルファスト
• 第 1 引数で環境を切り替え（デフォルトstaging）
• 末尾でcurl -fによるヘルスチェック
• 成功時に絵文字付きの完了メッセージを出力

つまり「新バージョンへ進める道（deploy.sh）と、前回の安定版へ戻す道（rollback.sh）が、同じ安全性の基準で設計されている」ことが、ソースコードから直接確認できます。この対称性が、このプラグインのロールバック運用を現場で使いやすくしている要点です。

ロールバック運用の実践ポイントまとめ

rollback.md の 5 ステップを、実際のスクリプト・設定ファイルと対応づけて整理すると、次の運用指針が導けます。

実運用で応用する際は、以下の点を自前の環境に合わせて調整してください。

• deployment/appという Deployment 名やapi.$ENV.example.comというエンドポイントはサンプル値なので、自身のリソース名・ドメインに置き換える必要があります。
• pg_isreadyによる DB チェックは PostgreSQL 前提です。他の DB を使う場合は、その DB 向けの疎通確認に差し替えます。
• sleep 5/sleep 10の待機時間は環境の起動速度に依存するため、kubectl rollout statusやkubectl wait --for=condition=readyを併用するのがより堅牢です。

Claude Code の/rollbackコマンドをきっかけに、この 5 ステップがスクリプトとして自動化されることで、手順の取り違えや検証漏れといったヒューマンエラーを防ぎつつ、素早く安定版へ切り戻せる体制が手に入ります。この記事で紹介したスクリプトと設定はすべて 07-plugins/devops-automation 配下に実物があるため、ぜひ実際のコードを開きながら、ご自身のデプロイパイプラインへの適用を検討してみてください。

【免费下载链接】claude-howtoA visual, example-driven guide to Claude Code — from basic concepts to advanced agents, with copy-paste templates that bring immediate value.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-howto