このソリューションでは、Compute Engine イメージの管理方法に関する詳細なガイダンスを提供します。イメージは、Compute Engine で実行されるアプリケーションの基礎となるオペレーティング環境を提供します。また、アプリケーションを迅速かつ確実にデプロイおよびスケーリングするのに不可欠なものです。障害復旧やロールバックといったシナリオに応じたアプリケーション バージョンをアーカイブするために、イメージを使用することもできます。
イメージについて
Compute Engine 内のイメージは、不変のディスクへのリファレンスを提供するクラウド リソースです。ディスクの表現は、いくつかのデータ形式を使用してカプセル化されます。
イメージとは、事前にデータが取り込まれているハードディスクの作成に使用される未加工のバイトの集合体です。フォーマットされているディスクには必ず、データを含む 1 つ以上のパーティションをポイントするパーティション分割テーブルが書き込まれています。イメージを起動可能にするには、次のものが含まれている必要があります。
- パーティション分割テーブル: マスター ブートレコードまたは GUID パーティション分割テーブル
- 起動可能なパーティション
ディスクを Compute Engine のイメージとしてインポートするには、ディスクのバイトが disk.raw という名前のファイルに書き込まれている必要があります。
ディスクからバイトの完全なシーケンスがファイルに書き込まれると、ファイルは tar 形式でアーカイブされ、GZIP 形式を使用して圧縮されます。その後、この圧縮された *.tar.gz ファイルを Cloud Storage にアップロードし、イメージとして Compute Engine に登録できます（上の図）。イメージを登録した後は、そのイメージを使用して、元のディスクとまったく同じレプリカを Google Cloud の任意のリージョンに作成できるようになります。新たに登録されたイメージは、Compute Engine インスタンスのブート ボリュームとして使用されることもよくあります。
Compute Engine の用語に関する基本的な説明については、ドキュメントの仮想マシン インスタンスとイメージをご覧ください。
ブートイメージを選択する
Compute Engine で最初に行うことは、仮想マシン（VM）インスタンスのオペレーティング システムにするイメージを選択することです。これには Google Cloud が提供している公開イメージを使用できます。公開イメージは定期的に更新されています。Google Cloud では Debian、Ubuntu、CentOS などさまざまなオペレーティング システムが提供されており、追加費用なしで使用できます。Red Hat Enterprise Linux や Microsoft Windows などのオペレーティング システムはプレミアム イメージとして提供されており、インスタンスを実行する時間ごとに追加料金がかかります。
自動更新ポリシー、セキュリティ パッチ、サポート チャネルなど、特定のイメージの詳細については、プロダクト ドキュメントのオペレーティング システムの詳細に関するセクションをご覧ください。
セキュリティを強化するために、信頼できるイメージ機能を使用して、特定の公開イメージ プロジェクトのイメージがブートイメージの作成で使用されないようにする組織のポリシーを定義することもできます。
Compute Engine のインスタンスのブートに Google Cloud の公開イメージを使用できます。そのうえで、実行するアプリケーションに合わせてこのインスタンスをカスタマイズできます。
インスタンス構成のアプローチとして、起動スクリプトを使用し、ブート時にアプリケーションをデプロイするコマンドが実行されるようにする方法があります。このスクリプトはインスタンスがブートするたびに実行されるため、一貫性のない状態や一部しか構成されていない状態になってしまうことを防止するために、スクリプトはべき等性にする必要があります。インスタンスがマネージド インスタンス グループに含まれている場合、インスタンス グループ アップデータを使用してインスタンスを再起動または再構築し、それによって起動スクリプトを再実行できます。起動スクリプトを使用して、Chef や Ansible などの構成管理ツールを実行するのが一般的な方法です。
カスタマイズ イメージを作成する
インフラストラクチャをプロビジョニングする方法として、インスタンスの起動スクリプトを構成する方法も有効ですが、パブリック イメージに構成を組み込んだカスタム イメージを新たに作成するほうがより効率的です。次の方法でイメージをカスタマイズできます。
- 手動
- 自動
- インポート
カスタム イメージを作成するプロセスを「焼き付け」と呼びます。
イメージの焼き付けには、以下の利点があります。
- ブートからアプリケーションの準備が整うまでの時間が短縮されます。
- アプリケーションのデプロイの信頼性が高まります。
- 以前のバージョンへのロールバックがより簡単になります。
- アプリケーションのブートストラップ中の外部サービスへの依存が少なくなります。
- スケールアップすることで、同一のソフトウェア バージョンを含むインスタンスが作成されます。
手動で焼き付ける
公開イメージから新しい VM インスタンスを作成して、使用するアプリケーションと設定でインスタンスを構成し、そのインスタンスからカスタム イメージを作成することで、簡単なカスタム イメージを作成できます。自動の焼き付けや既存のイメージのインポートを行う代わりに、最初から手動でイメージを構成できる場合は、この方法を使用します。
以下の手順で簡単なカスタム イメージを作成できます。
- パブリック イメージからインスタンスを作成します。
- インスタンスに接続します。
- ニーズに合ったインスタンスをカスタマイズします。
- インスタンスを停止します。
- そのインスタンスのブートディスクからカスタム イメージを作成します。このプロセスでは、インスタンスを削除してブートディスクを保持する必要があります。
自動で焼き付ける
手動での焼き付けは、イメージの数が少ない場合は簡単に開始できる方法ですが、イメージの数が多い場合には監査や管理が困難になります。Packer は、イメージの作成の再現性と監査性を高め、構成可能で、信頼性のあるものにするオープンソースのツールです。Packer を Spinnaker パイプラインの一部として使用し、インスタンスのクラスタにデプロイされるイメージを作成することもできます。
既存のイメージをインポートする
仮想ディスク インポート ツールを使用して、既存のインフラストラクチャから Compute Engine にブートディスク イメージをインポートできます。これにより、イメージのインポート プロセスを自動化します。Linux マシンについては、RAW ディスク イメージ、Amazon Machine Images（AMI）、VirtualBox イメージの手動での移行に関する詳細なガイドをご覧ください。
既存のイメージをインポートするには、Migrate to Virtual Machines を使用することもできます。
Migrate to Virtual Machines は、ブロックレベルのレプリケーションを継続的に使用して、最小限のダウンタイムでプラットフォームからプラットフォームへのマシン移行を容易にするツールチェーンおよびサービスです。マシンを Compute Engine に移行してから、手動で焼き付けてイメージを作成できます。
イメージを暗号化する
Compute Engine 内のすべてのディスクは、デフォルトで Google の暗号鍵を使用して暗号化されます。ディスクから作成されたイメージも暗号化されます。あるいは、ディスクの作成時に独自の暗号鍵を提供できます。ディスクを作成した後、イメージ作成コマンドに暗号鍵を提供することで、暗号化されたイメージを作成できます。保存時の暗号化や、顧客指定の暗号鍵の詳細については、Google Cloud ドキュメントの保存時の暗号化をご覧ください。
イメージのライフサイクル
イメージ構築パイプラインを設定すると、イメージを使用してアプリケーションのインスタンスを確実に起動できます。このパイプラインでイメージの作成を処理することはできますが、デプロイメント メカニズムで必ず最新バージョンのイメージが使用されるようにする必要もあります。最後に、古く、廃止されたイメージが間違って使用されないように、イメージを選択するプロセスも必要です。
イメージ ファミリー
イメージ ファミリーを利用すると、関連するイメージをグループ化して、特定のイメージ バージョン間でのロールのフォワードとロールバックができるため、プロジェクト内のイメージの管理に役立ちます。詳しくは、イメージ ファミリーのベスト プラクティスをご覧ください。
イメージの使用を中止する
管理者は、次のコマンドを使用してイメージの使用を中止し、イメージ ファミリーがポイントするイメージのロールバックを行うこともできます。
gcloud compute images deprecate my-application-v3-20161011 --state DEPRECATED
次のような、さまざまな使用中止状態から選択できます。
| 状態 | 説明 |
|---|---|
| DEPRECATED | 最新ではないイメージ。ただし、その場合でもユーザーはイメージを起動できます。ユーザーには、最新のイメージを使用していないことを示す警告が起動時に表示されます。 |
| OBSOLETE | ユーザーまたは自動機能から起動されるべきではないイメージ。これらのイメージからインスタンスを作成しようとすると、失敗します。このイメージ状態を使用してイメージをアーカイブすると、ブートディスク以外としてマウントする場合に、それらのデータを使用できるようになります。 |
| DELETED | すでに削除されたか、将来削除されるようにマークが付けられているイメージ。これらを起動することはできません。可能な限り早急にこれらを削除する必要があります。 |
ライフサイクル ポリシーの適用
gcloud compute images deprecate コマンドを使用して、イメージに deletion や obsolescence のマークを付けることができます。メタデータをイメージにアタッチして、--delete-in または --delete-on のいずれかのフラグを付け、将来削除されるようにマークを付けることができます。メタデータをアタッチして将来使用中止になるマークをイメージに付けるには、--obsolete-in または --obsolete-on のフラグを付けます。このコマンドをイメージ構築プロセスに組み込み、プロジェクト内で最新ではないイメージや期限切れのイメージが増大するのを制限するイメージ ライフサイクル ポリシーを適用できます。たとえば、イメージ構築パイプラインの最後に、使用中止または削除する必要のあるイメージに対する追加チェックを含めて、それらのアクションを明示的に実行できます。
使用中止および削除されたイメージはデフォルトで API や UI を介して表示されることはなくなりますが、--show-deprecated フラグを指定して表示することもできます。イメージとそのデータを完全に削除するには、対象のイメージに対して明示的に delete コマンドを送信する必要があります。
プロジェクト間でのイメージの共有
組織では、リソース、環境、ユーザー アクセスを分割する目的で、複数の Google Cloud プロジェクトを作成することがよくあります。リソースをプロジェクトに分離することで、課金の細分化、セキュリティの強化、ネットワークの分離が可能になります。大部分のクラウド リソースは複数のプロジェクトで展開する必要はありませんが、複数のプロジェクトにわたって共有する場合は、イメージを使用すると便利です。イメージの共有セットを使用することで、共通のプロセスに従って、セキュリティ、承認、パッケージ管理、および組織の他の部分に対して事前構成された運用に関するベスト プラクティスを提供できます。
イメージを共有するには、IAM ロールを組織のプロジェクトに割り当てます。他のプロジェクトに共有するイメージを含むプロジェクト（上記の図では「Image Creation Project」として示されている）には、次の IAM ロールとポリシーが適用されている必要があります。
- 「Image User Group」のユーザーに
compute.imageUserロールを付与して、それらのユーザーがイメージからインスタンスを作成できるようにします。 - 「Image Creation User」に
compute.instanceAdminロールを付与して、このプロジェクトでインスタンスを作成できるようにします。 - 「Image Creation User」に
compute.storageAdminロールを付与して、このプロジェクトでイメージとディスクを作成できるようにします。
共有イメージを使用できるようにするプロジェクトでは、compute.imageUser ロールを持つユーザーに compute.instanceAdmin ロールを割り当てることで、それらのユーザーがインスタンスを作成できるようにする必要があります。
プロジェクト間でのイメージの共有については、Compute Engine ドキュメントでプロジェクト間でのイメージの共有に関する説明をご覧ください。
次のステップ
- 画像のインポート オプションを確認する
- ブートイメージを操作する
- カスタム イメージを操作する