オペレーティング システムのアップグレードのベスト プラクティス

このドキュメントでは、Compute Engine インスタンスのオペレーティング システムをアップグレードするためのベスト プラクティスと戦略について説明します。不変インフラストラクチャ、インスタンスの再作成、インプレース ワークフローを使用して OS のメジャー バージョンをアップグレードする方法と、ルーティン セキュリティ パッチ適用を自動化する方法について説明します。

オペレーティング システムのバージョンがサポート終了（EOS）またはサポート終了（EOL）に近づくと、セキュリティ アップデート、ソフトウェアの互換性、 Cloud de Confiance by S3NS プラットフォーム統合を維持するために、サポートされている OS バージョンにアップグレードする必要があります。サポート フェーズの詳細については、オペレーティング システムのライフサイクルをご覧ください。

OS のメジャー バージョンのインプレース アップグレードのリスク

実行中のコンピューティング インスタンスで Debian 12 から 13、RHEL 9 から 10、Ubuntu 24.04 から 26.04 へのアップグレードなど、オペレーティング システムのメジャー インプレース アップグレードを実行すると、クラウド環境で重大な運用上のリスクが生じます。オンプレミスの物理サーバーとは異なり、コンピューティング インスタンスは、ハイパーバイザーと Compute Engine メタデータ サーバーと通信するために、ゲスト環境用の専用パッケージに依存しています。

オペレーティング システムをインプレース アップグレードすると、次の障害モードが発生する可能性があります。

• SSH と RDP 接続の喪失: ネットワーク サービス、ゲストレベルのファイアウォール ルール（ufw や firewalld など）、SSH デーモン設定の構成形式は、OS バージョン間で変更される可能性があり、リモート管理アクセスが遮断されることがあります。
• ゲスト環境の中断: google-guest-agent パッケージと google-oslogin パッケージは、SSH 認証鍵、ユーザー アカウント、ネットワーク インターフェース、メタデータとの同期を管理します。ディストリビューションのアップグレード中にパッケージ リポジトリまたは依存関係が破損すると、ゲスト エージェントが実行を停止し、それ以降のログインやネットワーク構成が妨げられる可能性があります。
• ストレージ ドライバとカーネル ドライバの非互換性: カーネル、initramfs、ディスク コントローラ（virtio-scsi や NVMe など）のドライバを変更すると、起動に失敗したり、コンピューティング インスタンスがアタッチされた Persistent Disk ボリュームを認識できなくなることがあります。
• リポジトリの構成の不整合: オペレーティング システム ベンダーは、レガシー パッケージ リポジトリと署名鍵を非推奨にしたり、置き換えたりすることがよくあります。これにより、パッケージ マネージャーがアップグレード中に失敗し、オペレーティング システムが復元不可能な半インストール状態になる可能性があります。

これらのリスクを回避するには、本番環境のコンピューティング インスタンスで OS のメジャー バージョンをインプレース アップグレードするのではなく、不変インフラストラクチャ モデルを使用します。

適切なアップグレード戦略を選択する

ワークロードがステートレスかステートフルかに応じて、次のいずれかの戦略を選択します。

不変のインフラストラクチャ

オペレーティング システムをアップグレードする最も安全で信頼性の高い方法は、イミュータブル インフラストラクチャ モデルを使用することです。実行中のコンピューティング インスタンスを変更する代わりに、更新された公開 OS イメージまたはカスタム OS イメージから新しいコンピューティング インスタンスを構築し、以前のインスタンスを置き換えます。

ワークロードがマネージド インスタンス グループ（MIG）で実行されている場合は、サービス停止なしでこのロールアウトを自動化できます。

更新されたイメージを作成する

1. サポートされているオペレーティング システムの詳細リストから最新の公開 OS イメージを選択するか、Image Builder または Packer や Ansible などの自動化ツールを使用してカスタム ベースイメージを作成します。
2. 非本番環境のテスト環境で、アプリケーションと依存関係が新しい OS バージョンにインストールされ、正常に実行されることを確認します。
3. カスタム OS イメージを作成するか、新しい公開イメージ ファミリーを参照します。詳細については、イメージ ファミリーのベスト プラクティスをご覧ください。

更新されたインスタンス テンプレートを作成する

更新された OS イメージを参照する新しいインスタンス テンプレートを作成します。

gcloud compute instance-templates create NEW_TEMPLATE_NAME \
    --image-family=IMAGE_FAMILY \
    --image-project=IMAGE_PROJECT \
    --machine-type=MACHINE_TYPE \
    --region=REGION

次のように置き換えます。

• NEW_TEMPLATE_NAME: 新しいインスタンス テンプレートの名前。
• IMAGE_FAMILY: ターゲット OS のイメージ ファミリー（debian-12 や ubuntu-2404-lts など）。
• IMAGE_PROJECT: イメージをホストするプロジェクト（debian-cloud、ubuntu-os-cloud など）。
• MACHINE_TYPE: インスタンスのマシンタイプ。
• REGION: テンプレートを作成する Compute Engine リージョン。

MIG でローリング置換を実行する

更新したテンプレートをマネージド インスタンス グループに適用し、ローリング置換を開始します。

gcloud compute instance-groups managed rolling-action replace MIG_NAME \
    --max-surge=20% \
    --max-unavailable=0 \
    --region=REGION

次のように置き換えます。

• MIG_NAME: マネージド インスタンス グループの名前。
• REGION: MIG が配置されているリージョン。ゾーン MIG の場合は、--region=REGION を --zone=ZONE に置き換えます。

Persistent Disk を使用してコンピューティング インスタンスを再作成する

アプリケーションが構成とデータを Persistent Disk ボリュームに保存するステートフルなスタンドアロン コンピューティング インスタンスを実行している場合は、データディスクを保持しながら、新しいブートディスクを使用してコンピューティング インスタンスを再作成することで、オペレーティング システムをアップグレードできます。

すべてのディスクをバックアップする

インフラストラクチャを変更する前に、ブートディスクとアタッチされているすべての Persistent Disk ボリュームの標準スナップショットまたはリージョン スナップショットを作成します。

gcloud compute disks snapshot BOOT_DISK_NAME \
    --snapshot-names=SNAPSHOT_NAME \
    --zone=ZONE

次のように置き換えます。

• BOOT_DISK_NAME: バックアップするブートディスクの名前。
• SNAPSHOT_NAME: 新しい Persistent Disk スナップショットの名前。
• ZONE: ディスクが配置されているゾーン。

詳細については、スナップショットの作成と管理をご覧ください。

アプリケーション データをブートディスクから分離する

アプリケーション データ、データベース ファイル、トランザクション ログが、ブートディスクではなく、セカンダリ Persistent Disk ボリュームまたは外部サービス（Cloud Storage や Cloud SQL など）に存在することを確認します。

代替コンピューティング インスタンスを作成する

1. データを一貫性を保つため、以前のコンピューティング インスタンスを停止します。

   gcloud compute instances stop LEGACY_INSTANCE_NAME --zone=ZONE
   

2. セカンダリ データディスクを以前のコンピューティング インスタンスから切断します。

   gcloud compute instances detach-disk LEGACY_INSTANCE_NAME \
       --disk=DATA_DISK_NAME \
       --zone=ZONE
   

3. 移行先の OS バージョンで新しいコンピューティング インスタンスを作成します。

   gcloud compute instances create NEW_INSTANCE_NAME \
       --image-family=IMAGE_FAMILY \
       --image-project=IMAGE_PROJECT \
       --zone=ZONE \
       --machine-type=MACHINE_TYPE
   

4. 既存のセカンダリ データディスクを新しいコンピューティング インスタンスにアタッチします。

   gcloud compute instances attach-disk NEW_INSTANCE_NAME \
       --disk=DATA_DISK_NAME \
       --zone=ZONE
   

5. 新しいコンピューティング インスタンスに接続し、データディスクにファイル システムをマウントして、アプリケーション サービスを開始します。

6. 必要に応じて、静的外部 IP アドレスまたは DNS レコードを再割り当てして、新しいコンピューティング インスタンスを指すようにします。

次のように置き換えます。

• LEGACY_INSTANCE_NAME: アップグレードする既存のコンピューティング インスタンスの名前。
• DATA_DISK_NAME: 切断して再アタッチするセカンダリ Persistent Disk ボリュームの名前。
• NEW_INSTANCE_NAME: 新しい置換コンピューティング インスタンスの名前。
• IMAGE_FAMILY: ターゲット OS バージョンのイメージ ファミリー（debian-13 や ubuntu-2604-lts など）。
• IMAGE_PROJECT: イメージを提供するプロジェクト（debian-cloud、ubuntu-os-cloud など）。
• MACHINE_TYPE: 新しいコンピューティング インスタンスのマシンタイプ。
• ZONE: コンピューティング インスタンスが配置されているゾーン。

インプレース OS アップグレード

複雑な手動構成のためにコンピューティング インスタンスを再作成できず、インプレース アップグレードを実行する必要がある場合は、アップグレード前のチェックを完了し、ディストリビューション固有の手順に注意深く従ってください。

アップグレード前のチェックリスト

インプレース アップグレードを開始する前に、このチェックリストのすべての手順を完了します。

1. アップグレード コマンドを実行する前に、ブートディスクのスナップショットを作成します。これは、アップグレードが失敗した場合の主な復元メカニズムです。

2. Cloud de Confianceの現在のすべてのパッケージとゲスト環境を、現在の OS リリースで利用可能な最新バージョンに更新します。

   • Debian と Ubuntu の場合: sudo apt update && sudo apt dist-upgrade -y
   • RHEL、CentOS、Rocky Linux の場合: sudo dnf upgrade -y
   • SLES の場合: sudo zypper update

   google-guest-agent パッケージと google-oslogin パッケージがアクティブであることを確認します。

   sudo systemctl status google-guest-agent
   

3. アップグレード中に SSH またはネットワーキングが機能しなくなった場合に、トラブルシューティングとログインができるように、コンピューティング インスタンスでインタラクティブ シリアル コンソールを有効にします。

   gcloud compute instances add-metadata INSTANCE_NAME \
       --metadata=serial-port-enable=TRUE \
       --zone=ZONE
   

   次のように置き換えます。

   • INSTANCE_NAME: コンピューティング インスタンスの名前。
   • ZONE: コンピューティング インスタンスが配置されているゾーン。

   詳細については、シリアル コンソールとのやり取りをご覧ください。

4. OS Login またはゲスト エージェントによって管理される SSH 認証鍵を使用している場合は、sudo passwd USERNAME などの方法で、管理者権限を持つローカル ユーザー アカウントのパスワードを設定します。これにより、アップグレード中に OS Login が一時的に使用できなくなった場合に、シリアル コンソールからログインできます。USERNAME は、ローカル ユーザー アカウントの名前に置き換えます。

5. ルート パーティション / とブート パーティション /boot に、新しいパッケージをダウンロードして解凍するのに十分な空き容量があることを確認します。少なくとも 5 GB の空き容量が推奨されます。

   df -h / /boot
   

6. セキュリティ、バックアップ、モニタリング用のサードパーティ エージェント（Google Cloud Ops エージェントを含む）が、オペレーティング システムのターゲット バージョンをサポートしていることを確認します。

インプレース アップグレードの手順

以降のセクションでは、一般的なオペレーティング システムの概要レベルのワークフローについて説明します。アップグレードする前に、必ずオペレーティング システムの公式アップグレード ドキュメントを参照してください。

マイナー アップデートのパッチ管理を自動化する

メジャー OS バージョンのアップグレードと、ルーティン マイナー アップデートおよびセキュリティ パッチを区別します。ソフトウェアの定期的なメンテナンス、パッケージの更新、CVE のパッチ適用には、VM Manager Patch を使用して、コンピューティング インスタンスのフリート全体へのパッチのデプロイを自動化します。

パッチを自動的に管理するには、次のベスト プラクティスに従ってください。

• ラベルを使用してインスタンスを整理する: env:dev、env:prod、tier:frontend などのメタデータを含むラベルを割り当てて、パッチの特定のコンピューティング インスタンス グループをターゲットにします。
• ゾーン単位でデプロイ: ゾーンとリージョン間でパッチジョブを分散します。本番環境では、すべてのゾーンに同時にパッチジョブを適用しないでください。
• パッチ適用前スクリプトとパッチ適用後スクリプトを使用する: パッチ適用前スクリプトを構成して、接続を安全にドレインするか、サービスを一時停止します。また、パッチ適用後スクリプトを構成して、インスタンスをサービスに戻す前にヘルスチェックを実行します。
• パッチ コンプライアンスをモニタリングする:Cloud de Confiance コンソールの VM Manager のダッシュボードを使用して、コンピューティング インスタンスのフリート全体でパッチのコンプライアンスと脆弱性のステータスを追跡します。

詳細については、パッチジョブを作成するをご覧ください。

アップグレード後の検証とトラブルシューティング

アップグレードが完了したら、次の検証手順を行います。

1. SSH または RDP が正常に接続されることを確認します。

2. ゲスト エージェントと OS Login のサービスがアクティブで、正常なステータスを報告していることを確認します。

   sudo systemctl status google-guest-agent
   sudo systemctl status google-oslogin-cache
   

3. コンピューティング インスタンスがインスタンス メタデータ サーバーにクエリできることを確認します。

   curl -H "Metadata-Flavor: Google" http://metadata.google.internal/computeMetadata/v1/instance/id
   

4. アプリケーション サービスが起動し、ロードバランサからのヘルスチェックで正常なインスタンスが報告されていることを確認します。

接続の切断に関するトラブルシューティング

インプレース アップグレード後にコンピューティング インスタンスへの SSH または RDP アクセスが失われた場合は、次のトラブルシューティング手順を行います。

1. コンソールログで、カーネル パニック、サービス起動時のエラー、ネットワーク初期化時の障害を確認します。

   gcloud compute instances tail-serial-port-output INSTANCE_NAME \
       --zone=ZONE
   

2. アップグレード前にインタラクティブ シリアル コンソールを有効にしていた場合は、ターミナルに直接接続します。

   gcloud compute connect-to-serial-port INSTANCE_NAME \
       --zone=ZONE
   

   ローカル ユーザーの認証情報を使用してログインし、journalctl -xe でシステムログを検査して、ネットワーキングまたは google-guest-agent サービスを再起動します。

   次のように置き換えます。

   • INSTANCE_NAME: トラブルシューティングを行うコンピューティング インスタンスの名前。
   • ZONE: コンピューティング インスタンスが配置されているゾーン。

3. オペレーティング システムを起動または復元できない場合は、アップグレード前に取得したスナップショットから新しい Persistent Disk ボリュームを作成し、コンピューティング インスタンスのブートディスクとしてアタッチします。復元手順の詳細については、スナップショットを新しいディスクに復元するをご覧ください。

次のステップ

• オペレーティング システムのライフサイクル ステージと非推奨ポリシーについて学習する。
• イメージ管理のベスト プラクティスを確認する。
• ゲスト環境のコンポーネントとデーモンを理解する。
• VM Manager を使用して自動パッチジョブを設定する。
• Windows Server のインプレース アップグレードを実行します。