イメージ管理のベスト プラクティス

このソリューションは、Google Compute Engine イメージの管理方法に関する詳細なガイドとして使用できます。イメージは、Compute Engine で実行されるアプリケーションの基礎となるオペレーティング環境を提供します。また、これはアプリケーションが迅速かつ信頼性を持ってデプロイおよびスケーリングするのに不可欠なものです。災害復旧やロールバックといったシナリオに応じたアプリケーション バージョンをアーカイブするために、イメージを使用することもできます。

イメージについて

Compute Engine 内のイメージは、不変のディスクへのリファレンスを提供するクラウド リソースです。ディスクの表現は、いくつかのデータ形式を使用してカプセル化されます。

イメージについて

イメージとは、事前にデータが取り込まれているハードディスク デバイスの作成に使用される生のバイトの集合体です。フォーマットされているディスクには必ず、データを含む 1 つまたは複数のパーティションをポイントするパーティション テーブルが書き込まれています。イメージをブータブルにするには、マスター ブートレコードと起動可能パーティションが含まれている必要があります。ディスクを Compute Engine のイメージとしてインポートするには、ディスクのバイトが disk.raw という名前のファイルに書き込まれている必要があります。

ディスクからバイトの完全なシーケンスがファイルに書き込まれると、ファイルは tar 形式でアーカイブされ、GZIP 形式を使用して圧縮されます。そして、この圧縮された *.tar.gz ファイルを Google Cloud Storage にアップロードし、イメージとして Compute Engine に登録できます(上の図)。イメージを登録した後は、そのイメージを使用して、元のディスクとまったく同じレプリカを Google Cloud Platform の任意のリージョンに作成できるようになります。新たに登録されたイメージは、Compute Engine インスタンスのブート ボリュームとして使用されることもよくあります。

Compute Engine の用語に関する基本的な説明については、ドキュメントの仮想マシン インスタンスイメージをご覧ください。

ブートイメージを選択する

Compute Engine で最初に行うことは、仮想マシン(VM)インスタンスのオペレーティング システムにするイメージを選択することです。これには Google Cloud Platform が提供しているパブリック イメージを使用できます。パブリック イメージは定期的に更新されています。Cloud Platform には Debian、Ubuntu、CentOS などさまざまなオペレーティング システムが提供されており、追加費用なしで使用できます。Red Hat Enterprise Linux や Microsoft Windows などのオペレーティング システムはプレミアム イメージとして提供されており、インスタンスを実行する時間ごとに追加料金がかかります。

自動更新ポリシー、セキュリティ パッチ、サポート チャネルなど、特定のイメージの詳細については、製品資料のオペレーティング システムの詳細に関するセクションをご覧ください。

イメージのブート

Compute Engine のインスタンスのブートに Cloud Platform のパブリック イメージを使用できます。その上で、実行するアプリケーションに合わせてこのインスタンスをカスタマイズできます。

インスタンス構成のアプローチとして、起動スクリプトを使用し、ブート時にアプリケーションをデプロイするコマンドが実行されるようにする方法があります。このスクリプトはインスタンスがブートするたびに実行されるため、一貫性のない状態や一部しか構成されていない状態になってしまうことを防止するために、スクリプトはべき等性にする必要があります。インスタンスがマネージド インスタンス グループに含まれている場合、インスタンス グループ アップデータを使用してインスタンスを再起動または再作成し、それによって起動スクリプトを再実行することができます。起動スクリプトを使用して、Chef や Ansible などの構成管理ツールを実行するのが一般的な方法です。

カスタマイズ イメージを作成する

インフラストラクチャをプロビジョニングする方法として、インスタンスの起動スクリプトを使用する方法も有効ですが、パブリック イメージに構成を組み込んだカスタム イメージを新たに作成するほうがより効率的です。次の方法でイメージをカスタマイズできます。

  • 手動設定
  • 自動
  • インポート

カスタム イメージを作成するプロセスを「焼き付け」と呼びます。

イメージの焼き付けには、以下の利点があります。

  • ブートからアプリケーションの準備が整うまでの時間が短縮されます。
  • アプリケーションのデプロイの信頼性が高まります。
  • 以前のバージョンへのロールバックがより簡単になります。
  • アプリケーションのブートストラップ中の外部サービスへの依存が少なくなります。
  • スケールアップすることで、同一のソフトウェア バージョンを含むインスタンスが作成されます。

手動で焼き付ける

パブリック イメージから新しい VM インスタンスを作成して、使用するアプリケーションと設定でインスタンスを構成し、そのインスタンスからカスタム イメージを作成することで、簡単なカスタム イメージを作成できます。自動の焼き付け既存のイメージからのインポートを行う代わりに、最初から手動でイメージを構成できる場合は、この方法を使用します。

以下の手順で簡単なカスタム イメージを作成できます。

  1. パブリック イメージからインスタンスを作成します。
  2. インスタンスに接続します。
  3. ニーズに合ったインスタンスをカスタマイズします。
  4. インスタンスを停止します。
  5. そのインスタンスのブートディスクからカスタム イメージを作成します。このプロセスでは、インスタンスを削除してブートディスクを保持する必要があります。

自動で焼き付ける

手動での焼き付けは、イメージの数が少ない場合は簡単に開始できる方法ですが、イメージの数が多い場合には監査や管理が困難になります。Packer は、イメージの作成の再現性と監査性を高め、構成可能で、信頼性のあるものにするオープンソースのツールです。自動イメージ作成パイプラインを作成する方法の詳細については、Jenkins、Packer、Kubernetes ソリューションを使用した自動イメージ作成をご覧ください。Packer を Spinnaker パイプラインの一部として使用し、インスタンスのクラスタにデプロイされるイメージを作成することもできます。

既存のイメージからインポートする

既存のインフラストラクチャから Compute Engine にイメージをエクスポートすることで、イメージを移行できます。Linux マシンについては、RAW ディスク イメージ、Amazon Machine Images(AMI)、VirtualBox イメージの移行に関する詳細なガイドをご覧ください。

既存のイメージをインポートするためのもう 1 つのオプションは、CloudEndure などの有料移行サービスを使用する方法です。CloudEndure は、継続的なブロックレベルのレプリケーションを使用することでダウンタイムを最小限に抑えながら、あるプラットフォームから別のプラットフォームにマシンを移行する作業を促進するツールチェーンのオンライン サービスです。CloudEndure によってマシンを Compute Engine に移行してから、手動で焼き付けてイメージを作成できます。

イメージを暗号化する

Compute Engine 内のすべてのディスクは、デフォルトで Google の暗号鍵を使用して暗号化されます。ディスクから作成されたイメージも暗号化されます。あるいは、ディスクが作成されるときに独自の暗号鍵を提供することができます。ディスクを作成した後、イメージ作成コマンドに暗号鍵を提供することで、暗号化されたイメージを作成できます。保存時の暗号化や、ユーザーによって提供される暗号鍵の詳細については、Cloud Platform の資料内の保存時の暗号化をご覧ください。

イメージのライフサイクル

イメージ作成パイプラインをセットアップすると、イメージを使用してアプリケーションのインスタンスを信頼性を持って起動できます。このパイプラインでイメージの作成を処理することはできますが、デプロイメント メカニズムで必ず最新バージョンのイメージが使用されるようにする必要もあります。最後に、古く、廃止されたイメージが間違って使用されないように、イメージを選択するプロセスも必要です。

イメージ ファミリを使用する

Compute Engine では、自動化システムとユーザーが確実に最新イメージを使用するようにするために、イメージ ファミリを使用できます。管理者は、同じアプリケーションまたはユースケースに属する一連のイメージを、イメージ ファミリとしてグループ化することができます。このようにすると、イメージのユーザーは正確なイメージ名ではなく、イメージ ファミリの名前を追跡し続けるだけで済みます。イメージ名は一意にする必要があるため、多くの場合、イメージ作成パイプラインではアプリケーション名、日付、バージョンなど、エンコードされている情報を使用してイメージ名が作成されます(my-application-v3-20161011 など)。特定の名前を他のシステムに伝達することで最新イメージにコンシューマが振り向けられるように、自動化されたツールを変更するということをしなくても、イメージ ファミリ名を参照するだけで、ファミリ内の最新イメージ(my-application など)が確実に返されるようになります。

イメージ ファミリ

イメージ ファミリにイメージを追加するには、または新しくイメージ ファミリを作成するには、イメージ作成ステップに --image-family フラグを追加する必要があります。次に例を示します。

gcloud compute images create my-application-v3-20161011 --source-disk my-application-disk-1 --source-disk-zone us-central1-f --family my-application

このコマンドを実行すると、イメージ my-application に基づいてインスタンスを実行するすべてのコールは、新たに作成されたイメージ my-application-v3-20161011 をポイントするようになります。

イメージの使用を中止する

管理者は、次のコマンドを使用してイメージの使用を中止し、イメージ ファミリがポイントするイメージのロールバックを行うこともできます。

 gcloud compute images deprecate my-application-v3-20161011 --state DEPRECATED

次のような、さまざまな使用中止状態から選択できます。

状態 説明
DEPRECATED 最新ではないイメージ。ただし、その場合でもユーザーはイメージを起動できます。ユーザーには、最新のイメージを使用していないことを示す警告が起動時に表示されます。
OBSOLETE ユーザーまたは自動機能から起動されるべきではないイメージ。これらのイメージからインスタンスを作成しようとすると、失敗します。このイメージ状態を使用してイメージをアーカイブすると、ブートディスク以外としてマウントする場合に、それらのデータを使用できるようになります。
DELETED すでに削除されたか、将来削除されるようにマークが付けられているイメージ。これらを起動することはできません。可能な限り早急にこれらを削除する必要があります。

ライフサイクル ポリシーの強制

gcloud compute images deprecate コマンドを使用して、イメージに delete や obsolete のマークを付けることができます。メタデータをイメージに追加して、--delete-in または --delete-on のいずれかのフラグを付け、将来削除するようにマークを付けることができます。メタデータを追加して将来使用中止になるマークをイメージに付けるには、--obsolete-in または --obsolete-on のフラグを付けます。このコマンドをイメージ作成プロセスに組み込み、プロジェクト内で最新ではないイメージや期限切れのイメージが増大するのを制限するイメージ ライフサイクル ポリシーを強制できます。たとえば、イメージ作成パイプラインの最後に、廃止または削除する必要のあるイメージに対する追加チェックを含めて、それらのアクションを明示的に実行できます。

廃止および削除されたイメージはデフォルトで API や UI を介して表示されることはなくなりますが、--show-deprecated フラグを指定して表示することもできます。イメージとそのデータを完全に削除するには、対象のイメージに対して明示的に delete コマンドを送信する必要があります。

プロジェクト間でのイメージの共有

組織では、リソース、環境、ユーザー アクセスを分割する目的で、複数の Cloud Platform プロジェクトを作成することがよくあります。リソースをプロジェクトに分離することで、課金の細分化、セキュリティの強化、ネットワークの分離が可能になります。大部分のクラウド リソースは複数のプロジェクトで展開する必要はありませんが、複数のプロジェクトにわたって共有する場合は、イメージを使用すると便利です。イメージの共有セットを使用することで、共通のプロセスに従って、セキュリティ、承認、パッケージ管理、およびオペレーションに関するベスト プラクティスを事前構成したイメージを組織全域に提供することができます。

イメージ共有

イメージを共有するには、IAM 役割を組織のプロジェクトに割り当てます。他のプロジェクトに共有するイメージを含むプロジェクト(上記の図では「Image Creation Project」として示されている)には、次の IAM 役割とポリシーが適用されている必要があります。

  1. 「Image User Group」のすべてのユーザーに役割 compute.imageUser を付与して、それらのユーザーがイメージからインスタンスを作成できるようにします。
  2. 「Image Creation User」に役割 compute.instanceAdmin を付与して、このプロジェクトでインスタンスを作成できるようにします。
  3. 「Image Creation User」に役割 compute.storageAdmin を付与して、このプロジェクトでイメージとディスクを作成できるようにします。

共有イメージを使用できるようにするプロジェクトでは、役割 compute.imageUser を持つユーザーに役割 compute.instanceAdmin を割り当てることで、それらのユーザーがインスタンスを作成できるようにする必要があります。

プロジェクト間でのイメージの共有について詳しくは、Compute Engine ドキュメントでプロジェクト間でのイメージの共有に関する説明をご覧ください。

次のステップ

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...