データベース移行によるローリングアップデートを処理する場合、Kubernetes はこれをどのように処理しますか?
たとえば、app-v1 から app-v2 に更新されるアプリがあり、これには既存のテーブルを変更する移行手順が含まれています。つまり、db:migrateデプロイしたら、Rails アプリのようなものを実行する必要があります。
3 つのレプリカ セットでローリング デプロイメントが行われると、1 つのポッドから別のポッドにデプロイされます。新しいバージョンのアプリがない POD が壊れる可能性があります。
このシナリオは、それほど頻繁に起こるものではありませんが、起こる可能性は十分にあります。このシナリオに最適な/推奨されるアプローチについて学びたいと思います。
ベストアンサー1
古いバージョンが壊れるのを防ぐ 1 つの方法は、移行を複数のステップに分割することです。
たとえば、データベース内の列の名前を変更したいとします。列の名前を直接変更すると、アプリの古いバージョンが壊れてしまいます。これは複数のステップに分割できます。
- 新しい列を挿入するDB移行を追加する
- すべての書き込みが古い列と新しい列に行われるようにアプリを変更します
- 古い列から新しい列にすべての値をコピーするタスクを実行します
- 新しい列から読み取るアプリを変更する
- 古い列を削除する移行を追加する
残念ながら、これはかなり面倒ですが、メンテナンス ページがアップされている間のダウンタイムを防ぐことができます。