Cloud Composer を使用したインフラストラクチャの自動化

このチュートリアルでは、Cloud Composer を使用してクラウド インフラストラクチャを自動化する方法について説明します。例では、Compute Engine 仮想マシン(VM)インスタンスの自動バックアップをスケジュールする方法を示します。

Cloud Composer は、Google Cloud Platform(GCP)上のフルマネージドなワークフロー オーケストレーション サービスです。Cloud Composer では、Python API を使用してワークフローを作成し、自動実行または手動で開始するようにスケジュールし、グラフィカル UI を介してタスクの実行をリアルタイムでモニタリングできます。

Cloud Composer は Apache Airflow に基づいています。Google はこのオープンソースのオーケストレーション プラットフォームを Google Kubernetes Engine(GKE)クラスタ上で実行しています。このクラスタにより、必要に応じて Airflow が自動スケーリングされ、他の GCP プロダクトとの多数の統合機会が開かれます。

このチュートリアルは、インフラストラクチャの自動化と Cloud Composer のコア機能に関する技術的詳細の探求に関心がある運営担当者、IT 管理者、デベロッパーを対象としています。このチュートリアルは、エンタープライズ レベルの障害復旧(DR)ガイドやバックアップのベスト プラクティス ガイドではありません。自社用の DR 計画を作成する方法の詳細については、障害復旧計画ガイドをご覧ください。

アーキテクチャの定義

Cloud Composer ワークフローは、有向非巡回グラフ(DAG)を作成することによって定義されます。Airflow の観点から見ると、DAG は方向の相互依存性を反映するように編成されたタスクの集まりです。このチュートリアルでは、Persistent Disk のスナップショットを使用して Compute Engine 仮想マシン インスタンスをバックアップするために定期的に実行される Airflow ワークフローを定義する方法を学習します。

例として使用する Compute Engine VM は、ブート永続ディスクが関連付けられたインスタンスで構成されています。後述のスナップショットのガイドラインに従って、Cloud Composer バックアップ ワークフローは Compute Engine API を呼び出してインスタンスを停止し、永続ディスクのスナップショットを作成して、インスタンスを再起動します。これらのタスク間で、ワークフローは各オペレーションが完了するまで待ってから次に進みます。

次の図はアーキテクチャをまとめたものです。

インフラストラクチャを自動化するためのアーキテクチャ

チュートリアルを始める前に、次のセクションで Cloud Composer 環境を作成する方法を説明します。この環境の利点は複数の GCP プロダクトを使用することですが、それぞれを個別に構成する必要はありません。

  • Cloud Storage: Airflow DAG、プラグイン、ログは Cloud Storage バケットに保存されます。
  • Google Kubernetes Engine: Airflow プラットフォームはマイクロサービス アーキテクチャに基づいており、GKE での実行に適しています。
    • Airflow ワーカーは、プラグインとワークフローの定義を Cloud Storage から読み込み、Compute Engine API を使用して各タスクを実行します。
    • Airflow スケジューラは、構成された間隔かつ適切なタスク順序でバックアップが実行されるようにします。
    • Redis は Airflow コンポーネント間のメッセージ ブローカーとして使用されます。
    • Cloud SQL Proxy はメタデータ リポジトリと通信するために使用されます。
  • Cloud SQL と App Engine Flex: Cloud Composer は、メタデータ用の Cloud SQL インスタンスと、Airflow UI を提供する App Engine Flex アプリも使用します。これらのリソースは、Google が管理する別のプロジェクトに存在するため、図には示されていません。

詳細については、Cloud Composer の概要をご覧ください。

ワークフローのスケーリング

このチュートリアルで紹介するユースケースはシンプルです。固定スケジュールで単一の仮想マシンのスナップショットを作成します。ただし、実際のシナリオには、組織のさまざまな部分、つまりシステムのさまざまな層に属し、それぞれ異なるバックアップ スケジュールが必要な数百の VM が含まれる場合があります。スケーリングは、Compute Engine VM を使用したこの例だけでなく、スケジュールされたプロセスを実行する必要があるインフラストラクチャ コンポーネントにも適用されます。

Cloud Composer は、クラウドでホストされている Apache Airflow に基づいた本格的なワークフロー エンジンであり、Cloud Schedulercron の単なる代替ではないため、これらの複雑なシナリオで優れた性能を発揮します。

ワークフローを柔軟に表現する Airflow DAG は、単一のコードベースから実行されながら、実際のニーズに適応します。ユースケースに適した DAG を構築するには、次の 2 つの方法を組み合わせて使用します。

  • 同じスケジュールを使用してプロセスを開始できるインフラストラクチャ コンポーネントのグループに対して、1 つの DAG インスタンスを作成します。
  • 独自のスケジュールが必要なインフラストラクチャ コンポーネントのグループに対して、独立した DAG インスタンスを作成します。

DAG はコンポーネントを並列処理できます。タスクで各コンポーネントに対して非同期操作を開始するか、各コンポーネントを処理するブランチを作成する必要があります。DAG をコードから動的に構築し、必要に応じてブランチやタスクを追加または削除できます。

また、同じ DAG 内のアプリケーション層間の依存関係をモデル化することもできます。たとえば、アプリサーバー インスタンスを停止する前に、すべてのウェブサーバー インスタンスを停止します。

こうした最適化は、このチュートリアルでは扱いません。

スナップショットのベスト プラクティスの使用

Persistent Disk は、仮想マシン インスタンスに接続し、インスタンスのプライマリ ブートディスクとして、または重要なデータのセカンダリ非ブートディスクとして使用できる耐久性の高いブロック ストレージです。 PD は可用性が高く、書き込みごとに 3 つのレプリカが書き込まれますが、Google Cloud のお客様にはそのうちの 1 つのみが課金されます。

スナップショットは、特定の時点における永続ディスクの正確なコピーです。スナップショットは増分であり圧縮され、Cloud Storage に透過的に保存されます。

アプリの実行中に任意の永続ディスクのスナップショットを作成できます。スナップショットには、部分的に書き込まれたブロックは含まれません。ただし、バックエンドがスナップショットの作成リクエストを受信したときに複数のブロックにわたる書き込みオペレーションが実行中の場合、そのスナップショットには更新されたブロックの一部しか含まれない可能性があります。こうした不整合は、不完全なシャットダウンに対処するのと同じ方法で対処できます。

スナップショットの整合性を保つために、次のガイドラインに従うことをおすすめします。

  • スナップショット作成プロセス中は、ディスクへの書き込みを最小限に抑えるか回避します。バックアップをオフピーク時にスケジュールすることをおすすめします。
  • セカンダリ非ブートディスクの場合は、データを書き込むアプリとプロセスを一時停止し、ファイル システムをフリーズまたはマウント解除します。
  • ブートディスクの場合、ルート ボリュームをフリーズするのは安全でなく、実行できません。スナップショットを作成する前に仮想マシン インスタンスを停止することが適していると考えられます。

    仮想マシンのフリーズまたは停止によってサービスが停止するのを回避するために、高可用性アーキテクチャを使用することをおすすめします。詳細については、アプリケーションの障害復旧シナリオをご覧ください。

  • スナップショットには一貫した命名規則を使用します。たとえば、インスタンス、ディスク、ゾーンの名前と連結した、適切な粒度のタイムスタンプを使用します。

一貫したスナップショットの作成の詳細については、スナップショットのベスト プラクティスをご覧ください。

目標

  • Compute Engine 用のカスタムの Airflow オペレータとセンサーを作成します。
  • Airflow オペレータとセンサーを使用して Cloud Composer ワークフローを作成します。
  • Compute Engine インスタンスを定期的にバックアップするようにワークフローをスケジュールします。

料金

料金計算ツールを使用すると、予想使用量に基づいて費用の見積もりを作成できます。

始める前に

  1. Google アカウントにログインします。

    Google アカウントをまだお持ちでない場合は、新しいアカウントを登録します。

  2. GCP プロジェクトを選択または作成します。

    [リソースの管理] ページに移動

  3. プロジェクトに対して課金が有効になっていることを確認します。

    課金を有効にする方法について

  4. Cloud Composer 環境を作成します。コストを最小限に抑えるために、マシンタイプ g1-small とディスクサイズ 20 GB を選択してください。

    環境の作成ページに移動

    Cloud Composer 環境のプロビジョニングには通常 15 分ほどかかりますが、1 時間程度かかることもあります。

  5. このチュートリアルの完全なコードは GitHub にあります。参照しながらファイルを調べるには、Cloud Shell でリポジトリを開きます。

    Cloud Shell に移動
  6. Cloud Shell コンソールのホーム ディレクトリで、次のコマンドを実行します。
    git clone https://github.com/GoogleCloudPlatform/composer-infra-python.git

このチュートリアルの終了後は、作成したリソースを削除するとそれ以降課金されることがありません。詳細については、クリーンアップをご覧ください。

サンプル Compute Engine インスタンスの設定

最初のステップとして、バックアップするサンプルの Compute Engine 仮想マシン インスタンスを作成します。このインスタンスは、オープンソースのコンテンツ管理システムである WordPress を実行します。

Compute Engine で WordPress インスタンスを作成するには、次の手順に従います。

  1. Google Cloud Platform Marketplace で、WordPress Certified by Bitnami の起動ページに移動します。
  2. [Compute Engine 上で起動] をクリックします。
  3. ポップアップ ウィンドウにプロジェクトのリストが表示されます。このチュートリアル用に以前に作成したプロジェクトを選択します。

    GCP でプロジェクトに必要な API が構成され、しばらくすると WordPress Compute Engine インスタンスのさまざまな構成オプションを示す画面が表示されます。

  4. 必要に応じて、ブートディスクの種類を SSD に変更して、インスタンスの起動速度を上げます。

  5. [デプロイ] をクリックします。

    Deployment Manager の画面が表示され、デプロイのステータスを確認できます。

    WordPress Deployment Manager スクリプトは WordPress Compute Engine インスタンスを作成し、TCP トラフィックがポート 80 と 443 を介してインスタンスに到達できるように 2 つのファイアウォール ルールを作成します。このプロセスには数分かかることがあります。各アイテムがデプロイされ、進行状況アイコンが表示されます。

    プロセスが完了すると、WordPress インスタンスの準備が整い、ウェブサイトの URL にデフォルトのコンテンツが表示されます。Deployment Manager の画面にウェブサイトの URL(サイトアドレス)、管理コンソールの URL(管理 URL)、そのユーザーとパスワード、ドキュメントのリンク、推奨される次のステップが表示されます。

    デプロイされたインスタンスを示す Deployment Manager

  6. サイトアドレスをクリックして、WordPress インスタンスが起動して実行されていることを確認します。デフォルトの WordPress ブログページが表示されます。

サンプルの Compute Engine インスタンスの準備ができました。次のステップでは、そのインスタンスの永続ディスクの自動増分バックアップ プロセスを構成します。

カスタム Airflow オペレータの作成

テスト インスタンスの永続ディスクをバックアップするには、インスタンスを停止し、その永続ディスクのスナップショットを作成してインスタンスを再起動する、Airflow ワークフローを作成します。これらの各タスクは、カスタム Airflow オペレータを使用してコードとして定義されます。オペレータのコードは Airflow プラグインにグループ化されます。

このセクションでは、Compute Engine Python クライアント ライブラリを呼び出してインスタンスのライフサイクルを制御するカスタム Airflow オペレータを構築する方法を学習します。これを行うためには次のような別の方法もあります。

  • Airflow BashOperator を使用して gcloud compute コマンドを実行します。
  • Airflow HTTPOperator を使用して、Compute Engine REST API に対して直接 HTTP 呼び出しを実行します。
  • Airflow PythonOperator を使用して、カスタム オペレータを定義せずに任意の Python 関数を呼び出します。

このチュートリアルではこうした代替方法は取り上げません。

Compute Engine API への呼び出しを承認する

このチュートリアルで作成したカスタム オペレータは、Python クライアント ライブラリを使用して Compute Engine API を呼び出します。API へのリクエストは認証され、承認される必要があります。アプリケーションのデフォルト認証情報(ADC)と呼ばれる方式を使用することをおすすめします。

クライアント ライブラリから呼び出しが行われるたびに ADC 方式が適用されます。

  1. ライブラリは環境変数 GOOGLE_APPLICATION_CREDENTIALS でサービス アカウントが指定されているかどうかを確認します。
  2. サービス アカウントが指定されていない場合、ライブラリは Compute Engine または GKE によって提供されるデフォルトのサービス アカウントを使用します。

これらの 2 つの方法が失敗した場合、エラーが発生します。

このチュートリアルの Airflow オペレータは 2 番目の方法に該当します。Cloud Composer 環境を作成すると、GKE クラスタがプロビジョニングされます。このクラスタのノードは Airflow ワーカーポッドを実行します。次に、これらのワーカーは定義されたカスタム オペレータを使用してワークフローを実行します。環境の作成時にサービス アカウントを指定しなかったため、GKE クラスタノードのデフォルト サービス アカウントが ADC 方式で使用されます。

GKE クラスタノードは Compute Engine インスタンスです。そのため、オペレータ コードで Compute Engine のデフォルト サービス アカウントに関連付けられている認証情報を簡単に取得できます。

def get_compute_api_client(self):
  credentials = GoogleCredentials.get_application_default()
  return googleapiclient.discovery.build(
      'compute', 'v1', cache_discovery=False, credentials=credentials)

このコードはデフォルトのアプリケーション認証情報を使用して、Compute Engine API にリクエストを送信する Python クライアントを作成します。次のセクションでは、各 Airflow オペレータを作成するときにこのコードを参照します。

デフォルトの Compute Engine サービス アカウントを使用する代わりに、サービス アカウントを作成し、Airflow 管理コンソールで接続として構成することもできます。この方法は Airflow 接続の管理ページで説明されており、GCP リソースへのよりきめ細かいアクセス制御を可能にします。このチュートリアルではこの代替方法は取り上げません。

Compute Engine インスタンスを安全にシャットダウンする

このセクションでは、最初のカスタム Airflow オペレータ StopInstanceOperator の作成について分析します。このオペレータは Compute Engine API を呼び出して、WordPress を実行している Compute Engine インスタンスを停止します。

  1. Cloud Shell で、nano や vim などのテキスト エディタを使用して gce_commands_plugin.py ファイルを開きます。

    vi $HOME/composer-infra-python/no_sensor/plugins/gce_commands_plugin.py
    
  2. ファイルの先頭にあるインポートを確認します。

    import datetime
    import logging
    import time
    from airflow.models import BaseOperator
    from airflow.plugins_manager import AirflowPlugin
    from airflow.utils.decorators import apply_defaults
    import googleapiclient.discovery
    from oauth2client.client import GoogleCredentials

    注目すべきインポートは次のとおりです。

    • BaseOperator: すべての Airflow カスタム オペレータが継承する必要がある基本クラス。
    • AirflowPlugin: プラグインを形成するオペレータのグループを作成する基本クラス。
    • apply_defaults: オペレータ コンストラクタで引数が指定されていない場合、引数をデフォルト値で埋める関数デコレータ。
    • GoogleCredentials: アプリのデフォルト認証情報を取得するために使用されるクラス。
    • googleapiclient.discovery: 基礎となる Google API を検出できるようにするクライアント ライブラリのエントリ ポイント。この場合、クライアント ライブラリは Compute Engine API と対話するためのリソースを構築します。
  3. 次に、インポートの下の StopInstanceOperator クラスを確認します。

    class StopInstanceOperator(BaseOperator):
      """Stops the virtual machine instance."""
    
      @apply_defaults
      def __init__(self, project, zone, instance, *args, **kwargs):
        self.compute = self.get_compute_api_client()
        self.project = project
        self.zone = zone
        self.instance = instance
        super(StopInstanceOperator, self).__init__(*args, **kwargs)
    
      def get_compute_api_client(self):
        credentials = GoogleCredentials.get_application_default()
        return googleapiclient.discovery.build(
            'compute', 'v1', cache_discovery=False, credentials=credentials)
    
      def execute(self, context):
        logging.info('Stopping instance %s in project %s and zone %s',
                     self.instance, self.project, self.zone)
        self.compute.instances().stop(
            project=self.project, zone=self.zone, instance=self.instance).execute()
        time.sleep(90)

    StopInstanceOperator クラスには次の 3 つのメソッドがあります。

    • __init__: クラス コンストラクタ。プロジェクト名、インスタンスが実行されているゾーン、停止するインスタンスの名前を受け取ります。また、get_compute_api_client を呼び出して self.compute 変数を初期化します。
    • get_compute_api_client: Compute Engine API のインスタンスを返すヘルパー メソッド。GoogleCredentials によって提供される ADC を使用して API で認証し、後続の呼び出しを承認します。
    • execute: BaseOperator からオーバーライドされたメイン オペレータ メソッド。Airflow はこのメソッドを呼び出してオペレータを実行します。このメソッドは情報メッセージをログに出力した後 Compute Engine API を呼び出し、コンストラクタで受け取った 3 つのパラメータで指定された Compute Engine インスタンスを停止します。末尾の sleep() 関数はインスタンスが停止するまで待機します。本番環境では、オペレータ相互通信などのより確定的な方法を使用する必要があります。この手法については、このチュートリアルの後半で説明します。

Compute Engine API の stop() メソッドは仮想マシン インスタンスを完全にシャットダウンします。オペレーティング システムでは /etc/init.d/bitnami にある WordPress 用のスクリプトを含む init.d シャットダウン スクリプトが実行されます。このスクリプトにより仮想マシンの再起動時に WordPress の起動も処理されます。シャットダウンおよび起動構成を含むサービス定義を /etc/systemd/system/bitnami.service で確認できます。

一意の名前の増分バックアップ スナップショットを作成する

このセクションでは、2 番目のカスタム オペレータ SnapshotDiskOperator を作成します。このオペレータはインスタンスの永続ディスクのスナップショットを作成します。

前のセクションで開いた gce_commands_plugin.py ファイルで SnapshotDiskOperator クラスを確認します。

class SnapshotDiskOperator(BaseOperator):
  """Takes a snapshot of a persistent disk."""

  @apply_defaults
  def __init__(self, project, zone, instance, disk, *args, **kwargs):
    self.compute = self.get_compute_api_client()
    self.project = project
    self.zone = zone
    self.instance = instance
    self.disk = disk
    super(SnapshotDiskOperator, self).__init__(*args, **kwargs)

  def get_compute_api_client(self):
    credentials = GoogleCredentials.get_application_default()
    return googleapiclient.discovery.build(
        'compute', 'v1', cache_discovery=False, credentials=credentials)

  def generate_snapshot_name(self, instance):
    # Snapshot name must match regex '(?:[a-z](?:[-a-z0-9]{0,61}[a-z0-9])?)'
    return ('' + self.instance + '-' +
            datetime.datetime.now().strftime('%Y-%m-%d-%H%M%S'))

  def execute(self, context):
    snapshot_name = self.generate_snapshot_name(self.instance)
    logging.info(
        ("Creating snapshot '%s' from: {disk=%s, instance=%s, project=%s, "
         "zone=%s}"),
        snapshot_name, self.disk, self.instance, self.project, self.zone)
    self.compute.disks().createSnapshot(
        project=self.project, zone=self.zone, disk=self.disk,
        body={'name': snapshot_name}).execute()
    time.sleep(120)

SnapshotDiskOperator クラスには次のメソッドがあります。

  • __init__: クラス コンストラクタ。StopInstanceOperator クラスのコンストラクタと似ていますが、このコンストラクタはプロジェクト、ゾーン、インスタンス名に加えて、スナップショットの作成元となるディスクの名前を受け取ります。これは、1 つのインスタンスに複数の永続ディスクを接続できるためです。
  • generate_snapshot_name: このサンプル メソッドはインスタンスの名前、日付、秒単位の時間を使用して、各スナップショットの単純な一意の名前を作成します。必要に応じて名前を調整します。たとえば、インスタンスに複数のディスクを接続する場合はディスク名を追加したり、個々のスナップショット作成リクエストに対応するために時間粒度を上げたりします。
  • execute: BaseOperator からオーバーライドされたメイン オペレータ メソッド。このメソッドは Airflow ワーカーによって実行されると、generate_snapshot_name メソッドを使用してスナップショット名を生成します。次に情報メッセージを出力し、Compute Engine API を呼び出して、コンストラクタで受け取ったパラメータを使用してスナップショットを作成します。

Compute Engine インスタンスを起動する

このセクションでは、3 番目の最後のカスタム オペレータ StartInstanceOperator を作成します。このオペレータは Compute Engine インスタンスを再起動します。

前に開いた gce_commands_plugin.py ファイルで、ファイルの下の方にある SnapshotDiskOperator クラスを確認します。

class StartInstanceOperator(BaseOperator):
  """Starts a virtual machine instance."""

  @apply_defaults
  def __init__(self, project, zone, instance, *args, **kwargs):
    self.compute = self.get_compute_api_client()
    self.project = project
    self.zone = zone
    self.instance = instance
    super(StartInstanceOperator, self).__init__(*args, **kwargs)

  def get_compute_api_client(self):
    credentials = GoogleCredentials.get_application_default()
    return googleapiclient.discovery.build(
        'compute', 'v1', cache_discovery=False, credentials=credentials)

  def execute(self, context):
    logging.info('Starting instance %s in project %s and zone %s',
                 self.instance, self.project, self.zone)
    self.compute.instances().start(
        project=self.project, zone=self.zone, instance=self.instance).execute()
    time.sleep(20)

StartInstanceOperator クラスには次のメソッドがあります。

  • __init__: クラス コンストラクタ。StopInstanceOperator クラスのコンストラクタと似ています。
  • execute: BaseOperator からオーバーライドされたメイン オペレータ メソッド。前のオペレータとの違いは、コンストラクタ入力パラメータに示されたインスタンスを起動する適切な Compute Engine API を呼び出すことです。

Airflow ワークフローの定義

これまで 3 つのオペレータを含む Airflow プラグインを定義しました。これらのオペレータは、Airflow ワークフローの一部を構成するタスクを定義します。ここに示すワークフローは単純で線形ですが、Airflow ワークフローは複雑な有向非巡回グラフにすることもできます。

このセクションでは、3 つのオペレータを公開するプラグイン クラスを作成し、次にこれらのオペレータを使用して DAG を作成し、DAG を Cloud Composer にデプロイして DAG を実行します。

プラグインを作成する

これまでのところ、gce_commands_plugin.py ファイルには起動、スナップショット、停止のオペレータが含まれています。これらのオペレータをワークフローで使用するには、プラグイン クラスに含める必要があります。

  1. gce_commands_plugin.py ファイルの下部にある GoogleComputeEnginePlugin クラスを確認します。

    class GoogleComputeEnginePlugin(AirflowPlugin):
      """Expose Airflow operators."""
    
      name = 'gce_commands_plugin'
      operators = [StopInstanceOperator, SnapshotDiskOperator,
                   StartInstanceOperator]

    AirflowPlugin から継承したこのクラスはプラグインに内部名 gce_commands_plugin を付け、3 つのオペレータを追加します。

  2. gce_commands_plugin.py ファイルを閉じます。

有向非巡回グラフを構成する

DAG は Airflow が実行するワークフローを定義します。バックアップするディスクを DAG に認識させるには、いくつかの変数を定義する必要があります。ディスクが接続されている Compute Engine インスタンス、インスタンスが実行されているゾーン、すべてのリソースが使用可能なプロジェクトです。

これらの変数は DAG ソースコード自体にハードコードすることもできますが、Airflow 変数として定義することをおすすめします。この方法では、構成変更をコードのデプロイとは無関係に一元的に管理できます。

DAG 構成を定義します。

  1. Cloud Shell で Cloud Composer 環境のロケーションを設定します。

    LOCATION=[CLOUD_ENV_LOCATION]
    

    ロケーションは、Cloud Composer 環境が配置されている Compute Engine リージョンです(us-central1europe-west1 など)。これは環境の作成時に設定され、Cloud Composer コンソール ページで確認できます。

  2. Cloud Composer の環境名を設定します。

    ENVIRONMENT=$(gcloud composer environments list \
        --format="value(name)" --locations $LOCATION)
    

    --format パラメータは、結果のテーブルから name 列のみを選択するために使用されます。1 つの環境のみが作成されているとみなすことができます。

  3. 現在の GCP プロジェクトの名前を使用して Airflow で PROJECT 変数を作成します。

    gcloud composer environments run $ENVIRONMENT --location $LOCATION \
        variables -- --set PROJECT $(gcloud config get-value project)
    

    ここで

    • gcloud composer environments run は Airflow CLI コマンドを実行するために使用されます。
    • variables Airflow コマンドは、PROJECT Airflow 変数を gcloud config によって返される値に設定します。
  4. WordPress インスタンスの名前を使用して Airflow で INSTANCE 変数を作成します。

    gcloud composer environments run $ENVIRONMENT --location $LOCATION \
        variables -- --set INSTANCE \
        $(gcloud compute instances list \
        --format="value(name)" --filter="name~'.*wordpress.*'")
    

    このコマンドは --filter パラメータを使用して、name が文字列 wordpress を含む正規表現と一致するインスタンスのみを選択します。この方法では、そのようなインスタンスが 1 つだけ存在し、インスタンスとディスクの名前の一部に「wordpress」が含まれていると想定しています。これは、デフォルト値をそのまま使用した場合に該当します。

  5. WordPress インスタンスのゾーンを使用して、Airflow で ZONE 変数を作成します。

    gcloud composer environments run $ENVIRONMENT --location $LOCATION \
        variables -- --set ZONE \
        $(gcloud compute instances list \
        --format="value(zone)" --filter="name~'.*wordpress.*'")
    
  6. WordPress インスタンスに接続されている永続ディスクの名前を使用して、Airflow で DISK 変数を作成します。

    gcloud composer environments run $ENVIRONMENT --location $LOCATION \
        variables -- --set DISK \
        $(gcloud compute disks list \
        --format="value(name)" --filter="name~'.*wordpress.*'")
    
  7. Airflow 変数が正しく作成されたことを確認します。

    1. GCP Console で、Cloud Composer ページに移動します。

      Cloud Composer ページに移動

    2. [Airflow ウェブサーバー] 列で [Airflow] リンクをクリックします。Airflow ウェブサーバーのメインページを表示する新しいタブが開きます。

    3. [Admin] をクリックしてから、[Variables] クリックします。

      リストに DAG 構成変数が表示されます。

      DAG 構成変数

有向非巡回グラフを作成する

DAG 定義は専用の Python ファイルにあります。次のステップでは、プラグインから 3 つのオペレータをつないで DAG を作成します。

  1. Cloud Shell で、nano や vim などのテキスト エディタを使用して backup_vm_instance.py ファイルを開きます。

    vi $HOME/composer-infra-python/no_sensor/dags/backup_vm_instance.py
    
  2. ファイルの先頭にあるインポートを確認します。

    import datetime
    from airflow import DAG
    from airflow.models import Variable
    from airflow.operators import SnapshotDiskOperator
    from airflow.operators import StartInstanceOperator
    from airflow.operators import StopInstanceOperator
    from airflow.operators.dummy_operator import DummyOperator

    これらのインポートの概要は次のとおりです。

    • DAG は Airflow によって定義された有向非巡回グラフクラスです。
    • DummyOperator はワークフローの可視化を向上させるために、処理を実行しないオペレータの開始と終了の作成に使用されます。より複雑な DAG では DummyOperator を使用してブランチを結合しSubDAG を作成できます。
    • DAG では前のセクションで定義した 3 つのオペレータが使用されます。
  3. オペレータ コンストラクタに渡すパラメータの値を定義します。

    INTERVAL = '@daily'
    START_DATE = datetime.datetime(2018, 7, 16)
    PROJECT = Variable.get('PROJECT')
    ZONE = Variable.get('ZONE')
    INSTANCE = Variable.get('INSTANCE')
    DISK = Variable.get('DISK')

    ここで

    • INTERVAL はバックアップ ワークフローの実行頻度を定義します。上記のコードは Airflow cron プリセットを使用して毎日の繰り返しを指定します。異なる間隔を使用する場合は、DAG Runs リファレンス ページをご覧ください。このスケジュールとは別に手動でワークフローをトリガーすることもできます。
    • START_DATE はバックアップの開始予定時刻を定義します。この値を変更する必要はありません。
    • 残りの値は、前のセクションで構成した Airflow 変数から取得されます。
  4. 次のコードを使用して、以前に定義したパラメータのいくつかで DAG を作成します。このコードでは DAG の名前と説明も指定し、どちらも Cloud Composer UI に表示されます。

    dag1 = DAG('backup_vm_instance',
               description='Backup a Compute Engine instance using an Airflow DAG',
               schedule_interval=INTERVAL,
               start_date=START_DATE,
               catchup=False)
  5. DAG にタスクを追加します。これはオペレータ インスタンスです。

    ## Dummy tasks
    begin = DummyOperator(task_id='begin', retries=1, dag=dag1)
    end = DummyOperator(task_id='end', retries=1)
    
    ## Compute Engine tasks
    stop_instance = StopInstanceOperator(
        project=PROJECT, zone=ZONE, instance=INSTANCE, task_id='stop_instance')
    snapshot_disk = SnapshotDiskOperator(
        project=PROJECT, zone=ZONE, instance=INSTANCE,
        disk=DISK, task_id='snapshot_disk')
    start_instance = StartInstanceOperator(
        project=PROJECT, zone=ZONE, instance=INSTANCE, task_id='start_instance')

    このコードはワークフローに必要なすべてのタスクをインスタンス化し、定義されたパラメータを対応するオペレータ コンストラクタに渡します。

    • task_id 値は Cloud Composer UI に表示される一意の ID です。後でこれらの ID を使用してタスク間でデータをやり取りします。
    • retries は失敗するまでにタスクを再試行する回数を設定します。DummyOperator タスクの場合、これらの値は無視されます。
    • dag=dag はタスクが以前に作成された DAG に関連付けられていることを示します。このパラメータはワークフローの最初のタスクでのみ必要です。
  6. ワークフロー DAG を構成する一連のタスクを定義します。

    # Airflow DAG definition
    begin >> stop_instance >> snapshot_disk >> start_instance >> end
    
  7. gce_commands_plugin.py ファイルを閉じます。

ワークフローを実行する

オペレータ DAG によって表されるワークフローを Cloud Composer で実行できるようになりました。Cloud Composer は関連する Cloud Storage バケットから DAG とプラグインの定義を読み取ります。このバケットと、対応する dags および plugins ディレクトリは、Cloud Composer 環境を作成したときに自動的に作成されました。

Cloud Shell を使用して、DAG とプラグインを関連する Cloud Storage バケットにコピーできます。

  1. Cloud Shell で、バケット名を取得します。

    BUCKET=$(gsutil ls)
    echo $BUCKET
    

    gs://[REGION]-{ENVIRONMENT_NAME]-{ID}-bucket/. という形式の名前を持つ単一のバケットがあります。

  2. 次のスクリプトを実行して、DAG ファイルとプラグイン ファイルを対応するバケット ディレクトリにコピーします。

    gsutil cp $HOME/composer-infra-python/no_sensor/plugins/gce_commands_plugin.py "$BUCKET"plugins
    gsutil cp $HOME/composer-infra-python/no_sensor/dags/backup_vm_instance.py "$BUCKET"dags
    

    バケット名にはすでに末尾のスラッシュが含まれているため、$BUCKET 変数を二重引用符で囲みます。

  3. GCP Console で、Cloud Composer ページに移動します。

    Cloud Composer ページに移動

  4. [Airflow ウェブサーバー] 列で [Airflow] リンクをクリックします。Airflow ウェブサーバーのメインページを表示する新しいタブが開きます。2〜3 分待ってからページを再読み込みします。ページの準備ができるまでに、待機と再読み込みを数回繰り返すことが必要な場合があります。

    次のような新しく作成された DAG を示すリストが表示されます。

    DAG リスト

    コードに構文エラーがある場合は、DAG テーブルの上部にメッセージが表示されます。ランタイム エラーがある場合は、[DAG Runs] の下にマークが付きます。続行する前にエラーを修正してください。その場合の最も簡単な方法は、GitHub リポジトリからバケットにファイルを再コピーすることです。

  5. より詳細なスタック トレースを確認するには、Cloud Shell で次のコマンドを実行します。

    gcloud composer environments run $ENVIRONMENT --location $LOCATION list_dags
    
  6. [Dag Runs] 列の下に表示されているように、Airflow はすぐにワークフローの実行を開始します。

    ワークフローはすでに進行中ですが、再度実行する必要がある場合は、次の手順で手動でトリガーできます。

    1. [Links] 列で、前のスクリーンショットの矢印の付いた最初のアイコン [Trigger Dag] をクリックします。
    2. [Are you sure?] という確認のポップアップで [OK] をクリックします。

      数秒後にワークフローが開始され、新しい実行が [DAG Runs] の下に薄い緑色の円で表示されます。

  7. [Links] 列で、前のスクリーンショットの矢印の付いた [Graph View] アイコンをクリックします。

    Cloud Composer のスクリーンショット

    [Graph View] にはワークフローが表示されます。正常に実行されたタスクは濃い緑色の枠線、実行中のタスクは薄い緑色の枠線、保留中のタスクは枠線なしで表示されます。タスクをクリックしてログを表示し、詳細を確認したり、他の操作を実行したりできます。

  8. 実行を追跡するには、右上隅にある更新ボタンを定期的にクリックします。

    これで、Cloud Composer の最初のワークフロー実行が完了しました。ワークフローが終了すると、Compute Engine インスタンスの永続ディスクのスナップショットが作成されます。

  9. Cloud Shell で、スナップショットが作成されていることを確認します。

    gcloud compute snapshots list
    

    また、GCP Console メニューを使用して Compute Engine の [スナップショット] ページに移動することもできます。

    Compute Engine の [スナップショット] ページ

この時点で 1 つのスナップショットが表示されます。指定されたスケジュールに従って手動または自動でトリガーされる後続のワークフローの実行により、さらにスナップショットが作成されます。

スナップショットは増分です。最初のスナップショットのサイズは、Persistent Disk のすべてのブロックが圧縮形式で含まるため、最大になります。連続するスナップショットには、前のスナップショットから変更されたブロックと、変更されていないブロックへの参照のみが含まれます。したがって、後続のスナップショットは最初のスナップショットよりも小さく、作成にかかる時間も短く、コストもかかりません。

スナップショットが削除されると、そのデータは次の対応するスナップショットに移され、スナップショット チェーンに格納されている連続したデルタの一貫性が保たれます。すべてのスナップショットが削除された場合にのみ、バックアップされたすべてのデータが永続ディスクから削除されます。

カスタム Airflow センサーの作成

ワークフローを実行しているときに、各ステップを完了するまで少し時間がかかることに気付いたかもしれません。この待ち時間は、Compute Engine API が次のタスクを開始する前に作業を終了する時間を与えるために、オペレータの最後に sleep() 命令が含まれるためです。

ただし、この方法は最適ではなく、予期しない問題が発生する可能性があります。たとえば、スナップショットの作成中、増分スナップショットを作成するための待ち時間が長くなりすぎることがあります。これは、すでに終了したタスクを待って時間を無駄にしていることを意味します。または待ち時間が短くなりすぎることがあります。この場合、マシンの起動時にインスタンスが完全に停止されていないことや、スナップショット プロセスが完了していないことが原因で、ワークフロー全体が失敗したり、信頼できない結果が生じたりする可能性があります。

前のタスクが完了したことを次のタスクに伝える必要があります。解決策の 1 つとして、いくつかの基準が満たされるまでワークフローを一時停止する Airflow センサーを使用します。この場合、基準は前回の Compute Engine オペレーションが正常に終了したことです。

タスク間で相互通信データを共有する

タスクが相互に通信する必要がある場合、Airflow は XCom、つまり「相互通信」と呼ばれるメカニズムを提供します。タスクは XCom を使用して、キー、値、タイムスタンプで構成されるメッセージを交換できます。

XCom を使用してメッセージを渡す最も簡単な方法は、オペレータが execute() メソッドから値を返すことです。値には、Python で pickle モジュールを使用してシリアル化できる任意のオブジェクトを指定できます。

前のセクションで説明した 3 つのオペレータが Compute Engine API を呼び出します。これらの API 呼び出しは、いずれもオペレーション リソース オブジェクトを返します。これらのオブジェクトは、Airflow オペレータのリクエストなどの非同期リクエストを管理するために使用されます。各オブジェクトには、Compute Engine オペレーションの最新の状態をポーリングするために使用できる name フィールドがあります。

オペレーション リソース オブジェクトの name を返すようにオペレータを変更します。

  1. Cloud Shell で、nano や vim などのテキスト エディタを使用して、今回は sensor/plugins ディレクトリから gce_commands_plugin.py ファイルを開きます。

    vi $HOME/composer-infra-python/sensor/plugins/gce_commands_plugin.py
    
  2. StopInstanceOperator の execute メソッドで、次のコードがどのようになるか確認します。

    self.compute.instances().stop(
        project=self.project, zone=self.zone, instance=self.instance).execute()
    time.sleep(90)

    次のコードに置き換えられます。

    operation = self.compute.instances().stop(
        project=self.project, zone=self.zone, instance=self.instance).execute()
    return operation['name']

    ここで

    • 最初の行は API 呼び出しから operation 変数への戻り値を取得します。
    • 2 行目は execute() メソッドからオペレーションの name フィールドを返します。この命令は pickle を使用して名前をシリアル化し、XCom のタスク内共有スペースに push します。この値は後で後入れ先出し順に pull されます。

    タスクが複数の値を push する必要がある場合、値を返す代わりに xcom_push() を直接呼び出すことによって XCom に明示的な key を与えることができます。

  3. 同様に、SnapshotDiskOperator の execute メソッドで、次のコードがどのようになるか確認します。

    self.compute.disks().createSnapshot(
        project=self.project, zone=self.zone, disk=self.disk,
        body={'name': snapshot_name}).execute()
    time.sleep(120)

    次のコードに置き換えられます。

    operation = self.compute.disks().createSnapshot(
        project=self.project, zone=self.zone, disk=self.disk,
        body={'name': snapshot_name}).execute()
    return operation['name']

    このコードには無関係な名前が 2 つあります。最初の名前はスナップショット名、2 番目はオペレーション名です。

  4. 最後に、StartInstanceOperator の execute メソッドで、次のコードがどのようになるか確認します。

    self.compute.instances().start(
        project=self.project, zone=self.zone, instance=self.instance).execute()
    time.sleep(20)

    次のコードに置き換えられます。

    operation = self.compute.instances().start(
        project=self.project, zone=self.zone, instance=self.instance).execute()
    return operation['name']
  5. この時点で、gce_commands_plugin.py ファイル全体を通して sleep() メソッドへの呼び出しはありません。ファイルで sleep を検索して、これが本当であることを確認します。そうでない場合は、このセクションの前のステップをもう一度確認してください。

    sleep() への呼び出しがコードから行われないため、ファイルの先頭にある imports セクションから次の行が削除されました。

    import time
    
  6. gce_commands_plugin.py ファイルを閉じます。

センサーを実装して公開する

前のセクションでは、Compute Engine のオペレーション名を返すように各オペレータを修正しました。このセクションでは、オペレーション名を使用して、各オペレーションの完了について Compute Engine API をポーリングする Airflow センサーを作成します。

  1. Cloud Shell で、nano や vim などのテキスト エディタを使用して gce_commands_plugin.py ファイルを開きます。sensor/plugins ディレクトリを使用してください。

    vi $HOME/composer-infra-python/sensor/plugins/gce_commands_plugin.py
    

    import セクションの上部の、from airflow.models import BaseOperator 行のすぐ下にある次のコード行を確認します。

    from airflow.operators.sensors import BaseSensorOperator
    

    すべてのセンサーは BaseSensorOperator クラスから派生しており、その poke() メソッドをオーバーライドする必要があります。

  2. 新しい OperationStatusSensor クラスを調べます。

    class OperationStatusSensor(BaseSensorOperator):
      """Waits for a Compute Engine operation to complete."""
    
      @apply_defaults
      def __init__(self, project, zone, instance, prior_task_id, *args, **kwargs):
        self.compute = self.get_compute_api_client()
        self.project = project
        self.zone = zone
        self.instance = instance
        self.prior_task_id = prior_task_id
        super(OperationStatusSensor, self).__init__(*args, **kwargs)
    
      def get_compute_api_client(self):
        credentials = GoogleCredentials.get_application_default()
        return googleapiclient.discovery.build(
            'compute', 'v1', cache_discovery=False, credentials=credentials)
    
      def poke(self, context):
        operation_name = context['task_instance'].xcom_pull(
            task_ids=self.prior_task_id)
        result = self.compute.zoneOperations().get(
            project=self.project, zone=self.zone,
            operation=operation_name).execute()
    
        logging.info(
            "Task '%s' current status: '%s'", self.prior_task_id, result['status'])
        if result['status'] == 'DONE':
          return True
        else:
          logging.info("Waiting for task '%s' to complete", self.prior_task_id)
          return False

    OperationStatusSensor クラスには次のメソッドがあります。

    • __init__: クラス コンストラクタ。このコンストラクタはオペレータのパラメータと似たパラメータを受け取りますが、例外として prior_task_id があります。このパラメータは前のタスクの ID です。
    • poke: BaseSensorOperator からオーバーライドされたメインセンサー メソッド。Airflow は True が返されるまで 60 秒ごとにこのメソッドを呼び出します。True が返された場合にのみ、ダウンストリーム タスクの実行が許可されます。

      この再試行の間隔は、コンストラクタに poke_interval パラメータを渡すことによって構成できます。timeout を定義することもできます。詳細については、BaseSensorOperator API リファレンスをご覧ください。

      上記の poke メソッドの実装では、最初の行は xcom_pull() への呼び出しです。このメソッドは、prior_task_id によって識別されるタスクの最新の XCom 値を取得します。値は Compute Engine オペレーションの名前で、operation_name 変数に格納されています。

      次にコードは zoneOperations.get() メソッドを実行し、パラメータとして operation_name を渡してオペレーションの最新の状態を取得します。ステータスが DONE の場合、poke() メソッドは True を返し、それ以外の場合は False を返します。前者の場合、ダウンストリーム タスクが開始されます。後者の場合、ワークフローの実行は一時停止したままになり、poke() メソッドが poke_interval 秒後に再度呼び出されます。

  3. ファイルの一番下で、GoogleComputeEnginePlugin クラスが更新され、プラグインによってエクスポートされたオペレータのリストに OperationStatusSensor が追加されたことを確認します。

    class GoogleComputeEnginePlugin(AirflowPlugin):
      """Expose Airflow operators and sensor."""
    
      name = 'gce_commands_plugin'
      operators = [StopInstanceOperator, SnapshotDiskOperator,
                   StartInstanceOperator, OperationStatusSensor]
  4. gce_commands_plugin.py ファイルを閉じます。

ワークフローを更新する

プラグインでセンサーを作成したら、センサーをワークフローに追加できます。このセクションでは、ワークフローを最終状態に更新します。この状態には、3 つのオペレータすべてとその間のセンサータスクが含まれます。その後、更新したワークフローを実行して確認します。

  1. Cloud Shell で、nano や vim などのテキスト エディタを使用して、今回は sensor/dags ディレクトリから backup_vm_instance.py ファイルを開きます。

    vi $HOME/composer-infra-python/sensor/dags/backup_vm_instance.py
    
    
  2. imports セクションで、新しく作成されたセンサーが from airflow operators import StartInstanceOperator 行の下にインポートされていることを確認します。

    from airflow.operators import OperationStatusSensor
    
  3. ## Wait tasks コメントに続く行を調べます。

    ## Wait tasks
    wait_for_stop = OperationStatusSensor(
        project=PROJECT, zone=ZONE, instance=INSTANCE,
        prior_task_id='stop_instance', poke_interval=15, task_id='wait_for_stop')
    wait_for_snapshot = OperationStatusSensor(
        project=PROJECT, zone=ZONE, instance=INSTANCE,
        prior_task_id='snapshot_disk', poke_interval=10,
        task_id='wait_for_snapshot')
    wait_for_start = OperationStatusSensor(
        project=PROJECT, zone=ZONE, instance=INSTANCE,
        prior_task_id='start_instance', poke_interval=5, task_id='wait_for_start')

    このコードでは OperationStatusSensor を再利用して 3 つの中間の「待機タスク」を定義しています。これらの各タスクは前のオペレーションが完了するのを待機します。次のパラメータがセンサー コンストラクタに渡されます。

    • すでにファイルに定義されている WordPress インスタンスの PROJECTZONEINSTANCE
    • prior_task_id: センサーが待機しているタスクの ID。たとえば、wait_for_stop タスクは、ID stop_instance のタスクが完了するのを待機します。

    • poke_interval: センサーの poke() メソッドへの再試行呼び出しの間に Airflow が待機する秒数。つまり、prior_task_id がすでに完了したかどうかを検証する頻度です。

    • task_id: 新しく作成された待機タスクの ID。

  4. ファイルの一番下で、次のコードがどのようになるか確認します。

    begin >> stop_instance >> snapshot_disk >> start_instance >> end
    

    次のコードに置き換えられます。

    begin >> stop_instance >> wait_for_stop >> snapshot_disk >> wait_for_snapshot \
            >> start_instance >> wait_for_start >> end
    

    これらの行は完全バックアップ ワークフローを定義します。

  5. backup_vm_instance.py ファイルを閉じます。

次に、関連する Cloud Storage バケットから DAG とプラグインをコピーする必要があります。

  1. Cloud Shell で、バケット名を取得します。

    BUCKET=$(gsutil ls)
    echo $BUCKET
    

    gs://[REGION]-[ENVIRONMENT_NAME]-[ID]-bucket/ という形式の名前を持つ単一のバケットがあります。

  2. 次のスクリプトを実行して、DAG ファイルとプラグイン ファイルを対応するバケット ディレクトリにコピーします。

    gsutil cp $HOME/composer-infra-python/sensor/plugins/gce_commands_plugin.py "$BUCKET"plugins
    gsutil cp $HOME/composer-infra-python/sensor/dags/backup_vm_instance.py "$BUCKET"dags
    

    バケット名にはすでに末尾のスラッシュが含まれているため、$BUCKET 変数を二重引用符で囲みます。

  3. 更新したワークフローを Airflow にアップロードします。

    1. GCP Console で、Cloud Composer ページに移動します。

      Cloud Composer ページに移動

    2. [Airflow] 列で [Airflow ウェブサーバー] リンクをクリックして [Airflow] メインページを表示します。

    3. Airflow でプラグインとワークフローが自動的に更新されるまで 2〜3 分待ちます。DAG テーブルが一時的に空になる場合があります。[Links] セクションが常に表示されるまで、ページを数回再読み込みします。

    4. エラーが表示されていないことを確認し、[Links] セクションの [Tree View] をクリックします。

      Cloud Composer の [Tree View] ページのスクリーンショット 左側には、ワークフローがボトムアップ ツリーとして表されています。右側には、さまざまな日付のタスク実行のグラフがあります。緑の四角形は、その特定のタスクがその日付に正常に実行されたことを意味します。白い四角形は、タスクが実行されていないことを意味します。DAG を新しいセンサータスクで更新したため、それらのタスクはすべて白で表示される一方、Compute Engine のタスクは緑で表示されます。

    5. 更新されたバックアップ ワークフローを実行します。

      1. トップメニューで、[DAGs] をクリックしてメインページに戻ります。
      2. [Links] 列で [Trigger DAG] をクリックします。
      3. [Are you sure?] という確認のポップアップで [OK] をクリックします。新しい workflowA の実行が開始され、[DAG Runs] 列に薄い緑色の円で表示されます。
    6. [Links] の下で [Graph View] アイコンをクリックして、ワークフローの実行をリアルタイムで観察します。

    7. タスクの実行を追跡するには、右側の更新ボタンをクリックします。前のタスクが終了するのを待つために各センサータスクでワークフローがどのように停止するかに注意してください。待ち時間は、ハードコードされたスリープ値に依存せず、各タスクのニーズに合わせて調整されます。

    Cloud Composer のタスク実行のスクリーンショット

  4. 必要に応じて、ワークフロー中に GCP Console に戻って [Compute Engine] メニューを選択し、[VM インスタンス] をクリックして仮想マシンを停止および再起動する方法を確認します。[スナップショット] をクリックして、新しいスナップショットが作成されていることを確認することもできます。

これで、Compute Engine インスタンスからスナップショットを作成するバックアップ ワークフローを実行しました。このスナップショットはベスト プラクティスに従い、センサーを使用してフローを最適化します。

スナップショットからのインスタンスの復元

スナップショットを利用できるようにすることは、バックアップの一部にすぎません。もう 1 つの部分は、スナップショットからインスタンスを復元できるようにすることです。

スナップショットを使用してインスタンスを作成するには:

  1. Cloud Shell で、利用可能なスナップショットのリストを取得します。

    gcloud compute snapshots list
    

    出力は次のようになります。

    NAME                              DISK_SIZE_GB  SRC_DISK                            STATUS
    wordpress-1-vm-2018-07-18-120044  10            us-central1-c/disks/wordpress-1-vm  READY
    wordpress-1-vm-2018-07-18-120749  10            us-central1-c/disks/wordpress-1-vm  READY
    wordpress-1-vm-2018-07-18-125138  10            us-central1-c/disks/wordpress-1-vm  READY
    
  2. スナップショットを選択し、そこからスタンドアロンのブート永続ディスクを作成します。かっこで囲まれたプレースホルダを独自の値に置き換えます。

    gcloud compute disks create [DISK_NAME] --source-snapshot [SNAPSHOT_NAME] \
        --zone=[ZONE]
    

    ここで

    • DISK_NAME は新しいスタンドアロンのブート永続ディスクの名前です。
    • SNAPSHOT_NAME は前の出力の最初の列から選択したスナップショットです。
    • ZONE は新しいディスクが作成される計算ゾーンです。
  3. ブートディスクを使用して新しいインスタンスを作成します。[INSTANCE_NAME] を、作成するインスタンスの名前に置き換えます。

    gcloud compute instances create [INSTANCE_NAME] --disk name=[DISK_NAME],boot=yes \
        --zone=ZONE --tags=wordpress-1-tcp-443,wordpress-1-tcp-80
    

    コマンドで 2 つのタグを指定すると、最初の WordPress インスタンスに対して作成された既存のファイアウォール ルールにより、インスタンスは自動的にポート 443 と 80 で着信トラフィックを受信できます。

    前のコマンドで返された新しいインスタンスの外部 IP をメモします。

  4. WordPress が新しく作成されたインスタンスで実行されていることを確認します。新しいブラウザタブで、外部 IP アドレスに移動します。WordPress のデフォルトのランディング ページが表示されます。

  5. または、コンソールからスナップショットを使用してインスタンスを作成します。

    1. GCP Console で [スナップショット] ページに移動します。

      [スナップショット] ページに移動

    2. 最新のスナップショットをクリックします。

    3. [インスタンスを作成] をクリックします。

    4. [新規 VM インスタンス] フォームで、[管理、セキュリティ、ディスク、ネットワーク、単一テナンシー] をクリックして、[ネットワーキング] をクリックします。

    5. タグを入力するたびに Enter キーを押して、[ネットワーク タグ] フィールドに wordpress-1-tcp-443wordpress-1-tcp-80 を追加します。これらのタグについては、上記の説明をご覧ください。

    6. [作成] をクリックします。

      最新のスナップショットに基づいて新しいインスタンスが作成され、コンテンツを提供できるようになりました。

  6. Compute Engine インスタンスのページを開き、新しいインスタンスの外部 IP をメモします。

  7. WordPress が新しく作成されたインスタンスで実行されていることを確認します。新しいブラウザタブで外部 IP に移動します。

詳しくは、スナップショットからのインスタンスの作成をご覧ください。

クリーンアップ

  1. GCP Console で [プロジェクト] ページに移動します。

    プロジェクト ページに移動

  2. プロジェクト リストで、削除するプロジェクトを選択し、[削除] をクリックします。
  3. ダイアログでプロジェクト ID を入力し、[シャットダウン] をクリックしてプロジェクトを削除します。

次のステップ

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

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