helm rollback でロールバックする

アップグレードの失敗は誰にでも起こります。Helm は履歴を保持しているため、焦ってデバッグする代わりに helm rollback で元に戻せます。🛟

リリース名だけを指定して helm rollback を実行すると、直前のリビジョンに戻ります。直前のミスを取り消す最も速い方法です。

復元する正確な revision を指定することもできます。helm history で番号を確認し、その番号を渡してください。

ロールバックしても履歴は削除されません。選択した対象と同じ内容を持つ新しいリビジョンが作成されます。履歴は増え続けます。

ロールバックでは、対象リビジョンのチャートと values が一緒に復元されるため、リリースはその時点とまったく同じ構成に戻ります。

--wait を追加すると、復元された Pod が準備完了になるまで Helm が待機します。これにより、ロールバックでサービスが本当に復旧したことを確認できます。✅

ロールバックで何が生成されるかを先に確認したい場合は、--dry-run を追加してください。稼働中のリリースを変更せずに結果を生成できます。

デフォルトでは、ロールバック時にフックはスキップされます。明示的に指定するには --no-hooks を追加し、ロールバック用フックを設計どおり実行するにはこのフラグを省略してください。

ロールバック後に helm status または helm history をもう一度実行し、deployed になっているリビジョンが想定どおりか確認してください。

失敗したアップグレードで --atomic を使用していた場合、Helm がすでに自動でロールバックしています。手動ロールバックは、後から問題が見つかった場合に行います。

ロールバックするには、戻り先として保存されたリビジョンが必要です。履歴が削除されていると復元するものがないため、history の保持が安全策になります。

リリースはリビジョン 6 で問題ありません。helm rollback my-app 4 を実行すると、リビジョン数はどうなりますか？

これで helm rollback を使ってすばやく復旧できるようになりました。1 つ前の状態に戻すことも、特定のリビジョンを指定することもできます。ロールバックのたびに新しいリビジョンが作成され、チャートと values が復元されます。history や --atomic と組み合わせて使いましょう。🚀