GCEのディスク容量の更新をするため、マネージド インスタンス グループ（MIG）の Updater 機能 を使用したが、その際に最小アクション（minimal-action）のオプションが問題になった
そもそもマネージド インスタンス グループ（MIG）からよくわかっていなかったので調べた
情報はほぼここと cloud.google.com
ここから
言葉の定義
GCEにおける言葉の定義をおさらいする
インスタンスグループ
単一のエンティティとして管理できる VM インスタンスの集まり
マネージド インスタンス グループ（MIG）
複数の同一 VM でのアプリケーション操作が可能
自動スケーリング、自動修復、リージョン（マルチゾーン）デプロイメント、自動更新などの自動化 MIG サービスを活用することで、スケーラブルで可用性に優れたワークロード処理を実現する
マネージド インスタンス グループ（MIG）
ステートレスのサービス提供側のワークロード（ウェブサイト フロントエンドなど）や、高性能または高スループットのバッチ処理用コンピューティング ワークロード（キューからの画像処理など）に適している
利点
- 高可用性
- インスタンスが常時実行される
- 自動修復
- リージョン（マルチゾーン）対応
- 負荷分散
- スケーラビリティ
- 自動更新
MIG の Updater機能
MIG のインスタンスを更新することができる
MIG Updater を使用すると、新しいバージョンのソフトウェアをマネージド インスタンス グループのインスタンスにデプロイでき、さらにデプロイの速度、サービス中断のレベル、更新の範囲を制御できる
主なメリットは、次の 2 つ
- 更新のロールアウトは指定に従って自動的に実行され、最初のリクエストの後にユーザーが新たに入力する必要がない
- 部分的にロールアウトを実行して、テストすることが可能
手動でやるよりはるかに楽
更新の種類：追従型更新と先行型更新
先行型更新
Compute Engine は積極的にアクションをスケジュールし、必要に応じてリクエストされた更新をインスタンスに適用する
追従型更新
選択したインスタンスの更新を手動で開始したい場合に行う更新
システムが不安定になることは可能な限り避けたい場合など
今回は追従型更新でGCEのディスク容量を増やしたテンプレートを使ったインスタンスグループに更新した
選択したインスタンスの更新
更新の特性によっては、インスタンスの状態が損なわれる可能性がある
たとえば、インスタンスのマシンタイプを変更するには VM の再起動が必要になる一方、VM のブートイメージを変更するにはインスタンスを削除して置き換える必要がある
そのときに、最小アクション（minimal-actionフラグ）を設定すると、Updater でグループ内のインスタンスを更新するために実行する必要のある最小アクションを制御することができる
たとえば、最小アクションとして REPLACE を設定すると、影響を受けるすべてのインスタンスが、必要かどうかに関係なく削除され、新しいインスタンスで置き換えられる
とりうるアクションは以下
| アクション | 説明 | 更新可能なインスタンス プロパティ |
|---|---|---|
| NONE | インスタンスを一切中断しません。 | なし。 |
| REFRESH | インスタンスを停止しません。 | セカンダリ ディスク、インスタンス メタデータ、ラベル。 |
| RESTART | インスタンスを停止して再起動します。 | マシンタイプ |
| REPLACE | インスタンスを削除して再作成します。 | インスタンス テンプレートに保存されているすべてのインスタンス プロパティ。 |
そして、このようにupdate-instances サブコマンドを使用して特定のインスタンスに更新を適用する
gcloud beta compute instance-groups managed update-instances [インスタンスグループ名] \
--instances [インスタンス名] \
--minimal-action [最小アクション]
今回はディスクの容量の変更だけだったが RESTARTではうまくいかず REPLACE にしたらうまく更新ができた
理由は別の機会に調査する
