arrow_back

VM の移行: 計画

参加 ログイン
Test and share your knowledge with our community!
done
Get access to over 700 hands-on labs, skill badges, and courses

VM の移行: 計画

Lab 1時間 universal_currency_alt クレジット: 5 show_chart 中級
Test and share your knowledge with our community!
done
Get access to over 700 hands-on labs, skill badges, and courses

GSP616

Google Cloud セルフペース ラボ

概要

Google Cloud のクラウド移行パス方法論は、次の 4 ステップで構成されており、ユーザーを成功に導く明確で再現性のある移行方法を提供します。

4 ステップの移行パスの図

  1. 評価: 現在の環境を評価して、既存のリソースを確実に把握し、移行の移動グループを定義します。

  2. 計画: アプリをどのように移行するか、対応すべきワークロードを処理できる基本的なクラウド インフラストラクチャをどのように構築するかをプランニングします。たとえば、ID 管理、組織とプロジェクトの構造、ネットワーキング、アプリの分類、優先度に従った移行戦略などを計画します。

  3. デプロイ: Google の Velostrata や CloudEndure のライブ マイグレーション ツールなど、Google Cloud の推奨移行ツールのいずれかを活用して、既存のオンプレミス サーバーまたはクラウドベース サーバーを Google Cloud にデプロイします。

  4. 最適化: 新しく移行したワークロードを最適化して、Google Cloud による費用上のメリットや運用効率を最大限に引き出します。

このラボでは、計画フェーズと、基本的なインフラストラクチャを Google Cloud にデプロイする方法について詳しく学習します。

学習内容

Terraform は、インフラストラクチャを定義およびプロビジョニングする(Infrastructure as Code)ための一般的なオープンソース ツールです。このラボでは、事前に構築された Infrastructure as Code テンプレートを活用して、クラウド ネットワークの設定、アクセスの設定、最初のアプリケーションのデプロイを安全かつ自動化された方法で行います。

具体的には、次の方法について学びます。

  • Google Cloud で自動化のためのアクセス認証情報を作成する。
  • Terraform を使用するための機能環境を作成する。
  • 関連するファイアウォール ルールを使用して、カスタムモードの Virtual Private Cloud(VPC)ネットワークを作成する。
  • Compute Engine でイメージを作成する。
  • Terraform を使用してインスタンスを Compute Engine にデプロイする。
  • 複数の Terraform デプロイメントでリソースを参照する。

設定と要件

[ラボを開始] ボタンをクリックする前に

こちらの手順をお読みください。ラボの時間は記録されており、一時停止することはできません。[ラボを開始] をクリックするとスタートするタイマーは、Google Cloud のリソースを利用できる時間を示しています。

このハンズオンラボでは、シミュレーションやデモ環境ではなく、実際のクラウド環境を使ってご自身でラボのアクティビティを行うことができます。そのため、ラボの受講中に Google Cloud にログインおよびアクセスするための、新しい一時的な認証情報が提供されます。

このラボを完了するためには、下記が必要です。

  • 標準的なインターネット ブラウザ(Chrome を推奨)
注: このラボの実行には、シークレット モードまたはシークレット ブラウジング ウィンドウを使用してください。これにより、個人アカウントと受講者アカウント間の競合を防ぎ、個人アカウントに追加料金が発生することを防ぎます。
  • ラボを完了するために十分な時間を確保してください。ラボをいったん開始すると一時停止することはできません。
注: すでに個人の Google Cloud アカウントやプロジェクトをお持ちの場合でも、このラボでは使用しないでください。アカウントへの追加料金が発生する可能性があります。

ラボを開始して Google Cloud コンソールにログインする方法

  1. [ラボを開始] ボタンをクリックします。ラボの料金をお支払いいただく必要がある場合は、表示されるポップアップでお支払い方法を選択してください。 左側の [ラボの詳細] パネルには、以下が表示されます。

    • [Google コンソールを開く] ボタン
    • 残り時間
    • このラボで使用する必要がある一時的な認証情報
    • このラボを行うために必要なその他の情報(ある場合)
  2. [Google コンソールを開く] をクリックします。 ラボでリソースが起動し、別のタブで [ログイン] ページが表示されます。

    ヒント: タブをそれぞれ別のウィンドウで開き、並べて表示しておきましょう。

    注: [アカウントの選択] ダイアログが表示されたら、[別のアカウントを使用] をクリックします。
  3. 必要に応じて、[ラボの詳細] パネルから [ユーザー名] をコピーして [ログイン] ダイアログに貼り付けます。[次へ] をクリックします。

  4. [ラボの詳細] パネルから [パスワード] をコピーして [ようこそ] ダイアログに貼り付けます。[次へ] をクリックします。

    重要: 認証情報は左側のパネルに表示されたものを使用してください。Google Cloud Skills Boost の認証情報は使用しないでください。 注: このラボでご自身の Google Cloud アカウントを使用すると、追加料金が発生する場合があります。
  5. その後次のように進みます。

    • 利用規約に同意してください。
    • 一時的なアカウントなので、復元オプションや 2 要素認証プロセスは設定しないでください。
    • 無料トライアルには登録しないでください。

その後このタブで Cloud Console が開きます。

注: 左上にある [ナビゲーション メニュー] をクリックすると、Google Cloud のプロダクトやサービスのリストが含まれるメニューが表示されます。 ナビゲーション メニュー アイコン

Cloud Shell をアクティブにする

Cloud Shell は、開発ツールと一緒に読み込まれる仮想マシンです。5 GB の永続ホーム ディレクトリが用意されており、Google Cloud で稼働します。Cloud Shell を使用すると、コマンドラインで Google Cloud リソースにアクセスできます。

  1. Google Cloud コンソールの上部にある「Cloud Shell をアクティブにする」アイコン 「Cloud Shell をアクティブにする」アイコン をクリックします。

接続した時点で認証が完了しており、プロジェクトに各自の PROJECT_ID が設定されます。出力には、このセッションの PROJECT_ID を宣言する次の行が含まれています。

Your Cloud Platform project in this session is set to YOUR_PROJECT_ID

gcloud は Google Cloud のコマンドライン ツールです。このツールは、Cloud Shell にプリインストールされており、タブ補完がサポートされています。

  1. (省略可)次のコマンドを使用すると、有効なアカウント名を一覧表示できます。
gcloud auth list
  1. [承認] をクリックします。

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

出力:

ACTIVE: * ACCOUNT: student-01-xxxxxxxxxxxx@qwiklabs.net To set the active account, run: $ gcloud config set account `ACCOUNT`
  1. (省略可)次のコマンドを使用すると、プロジェクト ID を一覧表示できます。
gcloud config list project

出力:

[core] project = <project_ID>

出力例:

[core] project = qwiklabs-gcp-44776a13dea667a6 注: Google Cloud における gcloud ドキュメントの全文については、gcloud CLI の概要ガイドをご覧ください。

タスク 1. 環境を設定する

  1. Terraform が Cloud Shell 環境にインストールされていることを確認します。
terraform -v

コマンド出力:

Terraform v0.15.3 注: バージョンは若干異なる場合があります。上記のような出力である場合は続行してください。
  1. 次のコマンドを実行して、ラボコードを含む git リポジトリのクローンを作成します。
git clone https://github.com/terraform-google-modules/cloud-foundation-training.git
  1. 現在のディレクトリをネットワーキング ディレクトリに変更します。
cd cloud-foundation-training/other/terraform-codelab/lab-networking

タスク 2. 変数を設定する

このセクションでは、Terraform 構成の変数を設定します。変数により、Terraform 構成をパラメータ化して再利用できます。

変数が設定されていない場合、Terraform の実行時に変数を設定するように求められます。

変数値は、Terraform の実行時に自動的に読み込まれる terraform.tfvars ファイルに保存できます。

  1. Cloud Shell で terraform.tfvars ファイルを作成します。
touch terraform.tfvars
  1. コードエディタで terraform.tfvars ファイルを開きます。
edit terraform.tfvars 注: vinano などの CLI コードエディタを使い慣れている場合は、それらを使用することもできます。
  1. 以下を terraform.tfvars ファイルに貼り付けます。
project_id="<プロジェクト ID>"
  1. コマンドの <プロジェクト ID> は Qwiklabs のプロジェクト ID に置き換えてください。たとえば、<プロジェクト ID>qwiklabs-gcp-xx-xxxxxxxxxxxx に置き換えます。

タスク 3. Google Cloud のアクセス認証情報を設定する

このセクションでは、Google Cloud のアクセス認証情報として使用するサービス アカウント キーを作成してダウンロードします。また、これらのアクセス認証情報を使用するようにテンプレート ファイルを更新します。

Terraform を使用するには、Google Cloud のプロジェクトや環境へのアクセス権が必要です。Terraform Google Cloud プロバイダでは認証情報を指定する方法が複数ありますが、このラボでは、Google Cloud サービス アカウントに関連付けられた認証情報ファイルを作成してダウンロードします。Google Cloud サービス アカウント認証を使用するのが、おすすめの方法です。

デフォルトのサービス アカウント アクセス認証情報を作成してダウンロードする

  1. Cloud Shell セッションで次のコマンドを実行して、Terraform を実行するためのサービス アカウントを作成します。
gcloud iam service-accounts create terraform --display-name terraform

コマンド出力:

Created service account [terraform].
  1. サービス アカウントを一覧表示して、新しい Terraform アカウントのメールアドレスを取得します。
gcloud iam service-accounts list

コマンド出力:

DISPLAY NAME: Compute Engine default service account EMAIL: 631585931190-compute@developer.gserviceaccount.com DISABLED: False DISPLAY NAME: Qwiklabs User Service Account EMAIL: qwiklabs-gcp-02-8eb8debc8fd5@qwiklabs-gcp-02-8eb8debc8fd5.iam.gserviceaccount.com DISABLED: False DISPLAY NAME: terraform EMAIL: terraform@qwiklabs-gcp-02-8eb8debc8fd5.iam.gserviceaccount.com DISABLED: False
  1. Terraform サービス アカウントを使用するためのキーを作成してダウンロードします。<サービス アカウントのメールアドレス> は、前のコマンドで出力された Terraform のメールアドレスに置き換えてください。
gcloud iam service-accounts keys create ./credentials.json --iam-account <サービス アカウントのメールアドレス>

コマンド出力:

created key [...] of type [json] as [./credentials.json] for [terraform@.iam.gserviceaccount.com]

完了したタスクをテストする

[進行状況を確認] をクリックして、実行したタスクを確認します。サービス アカウントおよびキーが正常に作成された場合は、評価スコアが表示されます。

サービス アカウントとキーを作成する(サービス アカウント名: terraform)
  1. 次のコマンドを実行して、プロジェクトに対するオーナーのロールをサービス アカウントに付与します。<プロジェクト ID> は Qwikalbs のプロジェクト ID に、<サービス アカウントのメールアドレス> は terraform サービス アカウントのメールアドレスに置き換えてください。
gcloud projects add-iam-policy-binding <プロジェクト ID> --member=serviceAccount:<サービス アカウントのメールアドレス> --role=roles/owner

完了したタスクをテストする

[進行状況を確認] をクリックして、実行したタスクを確認します。プロジェクトに対するオーナーのロールがサービス アカウントに正常に付与された場合は、評価スコアが表示されます。

プロジェクトに対するオーナーのロールをサービス アカウントに付与する

タスク 4. リモート状態を設定する

Terraform では、構成と作成されたリソースとの間のマッピングが Terraform の状態に保存されます。この状態はデフォルトでローカル ファイルに保存されますが、Cloud Storage にリモートで保存することをおすすめします。

このセクションでは、Terraform の状態を保存する Cloud Storage バケットを作成し、このバケットを指すように Terraform 構成を更新します。

Cloud Storage バケットを作成して構成する

  1. Terraform の状態を保存するための新しいバケットを作成します。Cloud Storage バケットはグローバルに一意である必要があるため、下のコマンドに示されているように、Qwiklabs の Google Cloud プロジェクト ID を名前の前に付けてください。
gsutil mb gs://<プロジェクト ID>-state-bucket

コマンド出力:

Creating gs://-state-bucket/...

完了したタスクをテストする

[進行状況を確認] をクリックして、実行したタスクを確認します。Cloud Storage バケットが正常に作成されている場合は、評価スコアが表示されます。

Cloud Storage バケットを作成して構成する
  1. backend.tf に保存されているバックエンド構成を開きます。
edit backend.tf
  1. 設定した名前と一致するようにバケット名を更新し、ファイルを保存します。
terraform { backend "gcs" { bucket = "my-state-bucket" # これを <プロジェクト ID>-state-bucket に変更します prefix = "terraform/lab/network" } }

タスク 5. Terraform を実行する

認証情報とリモート状態を設定したので、いつでも Terraform を実行できます。次の図に示されているように、Terraform を使用する場合は通常、以下の手順に沿って環境をデプロイしてクリーンアップします。

まず構成ファイルをセットアップし、デプロイを準備、計画します。次に、リソースをデプロイ、適用し、デプロイを確認してから、リソースをクリーンアップして破棄します。

Terraform を初めて実行する

  1. まず、Terraform を初期化して、Google および Random プロバイダの最新バージョンをダウンロードします。そのためには、Cloud Shell で次のコマンドを実行します。
terraform init
  • このコマンドの実行時に Cloud Storage バケットが存在しないというエラーが表示された場合は、backend.tf が正しい名前であることを確認してください。その後、下のコマンドを実行します。
rm -rf .terraform/ terraform init

これにより、ローカルの Terraform の状態がクリーンアップされ、正常に初期化されます。

  1. plan ステップを実行して構成の構文を検証し、作成される内容のプレビューを表示します。
terraform plan

plan の出力で、Terraform がネットワーク用に 8 つのリソースを作成することが示されます。

  1. 次に、terraform apply を実行して、これらの変更を適用します。
terraform apply

次のような出力が表示されます。

Plan: 8 to add, 0 to change, 0 to destroy. Do you want to perform these actions? Terraform will perform the actions described above. Only 'yes' will be accepted to approve. Enter a value:
  1. プロンプトに「yes」と入力します。適用が終了すると、次のような出力が表示されます。
Apply complete! Resources: 8 added, 0 changed, 0 destroyed.
  1. 変更の適用後、show コマンドを使用して、Terraform の状態に含まれているリソースのリストを表示できます。
terraform show

完了したタスクをテストする

[進行状況を確認] をクリックして、実行したタスクを確認します。Terraform の初回実行が正常に完了した場合は、評価スコアが表示されます。

Terraform を初めて実行する

タスク 6. サブネットを追加する

ダウンロードしたリポジトリには、ネットワークとサブネットを定義するモジュールが含まれています。移行された VM をホストするためのサブネットを新たに追加します。

追加のネットワークを作成する

  1. network.tf に保存されているネットワーク構成を開きます。このファイル内のネットワーク構成は、ネットワーク モジュールを使用して管理します。
edit network.tf
  1. ファイルの subnets ブロックに追加のサブネットを書き加えます(40 行目)。10.10.30.0/24 など、独自の名前と CIDR 範囲を選択できます。
module "vpc" { ... subnets = [ ... { # {{{project_0.default_region|Region}}} に最初のサブネットを作成し、その範囲を定義します subnet_name = "my-first-subnet" subnet_ip = "10.10.10.0/24" subnet_region = "{{{project_0.default_region|Region}}}" }, # ここにサブネットを追加します { subnet_name = "my-third-subnet" subnet_ip = "10.10.30.0/24" subnet_region = "{{{project_0.default_region|Region}}}" }, ] }
  1. また、サブネットのセカンダリ範囲を定義するセクションを追加する必要があります(49 行目)。これは空のリストにすることもできます。
secondary_ranges = { my-first-subnet = [] my-gke-subnet = [ { # Kubernetes Pod で使用するセカンダリ範囲を定義します range_name = "my-gke-pods-range" ip_cidr_range = "192.168.64.0/24" }, ] # この行の下にサブネットのセカンダリ範囲を追加します my-third-subnet = [] }
  1. terraform apply を実行して、新しいサブネットを追加します。
terraform apply 注: Error waiting to create Subnetwork」というエラーが表示された場合は、上記のコマンドを再実行してください

次のような出力が表示されます。

Plan: 1 to add, 0 to change, 0 to destroy. Do you want to perform these actions? Terraform will perform the actions described above. Only 'yes' will be accepted to approve. Enter a value:
  1. プロンプトに「yes」と入力します。適用が終了すると、次のような出力が表示されます。
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

完了したタスクをテストする

[進行状況を確認] をクリックして、実行したタスクを確認します。Terraform スクリプトを使用してサブネットを追加するための変更が正常に適用された場合は、評価スコアが表示されます。

サブネットを追加する

タスク 7. HTTPS トラフィックを許可する

このラボには、Terraform でファイアウォール ルールを管理するためのコードが含まれています。このコードを拡張して、受信トラフィックまたは送信トラフィックに関するファイアウォール ルールを追加できます。

  1. firewall.tf に保存されているファイアウォールの設定を開きます。
edit firewall.tf
  1. allow-http ルールを編集して、ポート 443 上の HTTPS トラフィックも許可します(51 行目)。
resource "google_compute_firewall" "allow-http" { name = "allow-http" network = module.vpc.network_name project = google_project_service.compute.project allow { protocol = "tcp" ports = ["80", "443"] # この行を編集します } # http-server タグを使用してあらゆる場所からインスタンスに送信されるトラフィックを許可します source_ranges = ["0.0.0.0/0"] target_tags = ["allow-http"] }
  1. terraform apply を実行して、ファイアウォール ルールを更新します。
terraform apply

次のような出力が表示されます。

Plan: 0 to add, 1 to change, 0 to destroy. Do you want to perform these actions? Terraform will perform the actions described above. Only 'yes' will be accepted to approve. Enter a value:
  1. プロンプトに「yes」と入力します。適用が終了すると、次のような出力が表示されます。
Apply complete! Resources: 0 added, 1 changed, 0 destroyed.

完了したタスクをテストする

[進行状況を確認] をクリックして、実行したタスクを確認します。Terraform スクリプトを使用してファイアウォール ルールを更新するための変更が正常に適用された場合は、評価スコアが表示されます。

HTTPS トラフィックを許可する

タスク 8. Terraform 出力を追加する

Terraform 出力を使用すると、環境に関する非常に重要で有用な情報をキャプチャして、人間と機械の両方が利用できます。これには、主要な IP アドレス、インスタンス名などの情報が含まれることもあります。

このセクションでは、新しいサブネットの ID を共有するための出力を追加します。

  1. outputs.tf に保存されているネットワーク構成を開きます。
edit outputs.tf
  1. 既存の出力に基づいて、新しいサブネットの名前を出力するセクションを追加します。サブネットにはゼロから始まる番号が付けられることに注意してください。
# この行の下に新しい出力を追加します output "my_subnet_name" { value = module.vpc.subnets_names[2] }
  1. terraform apply を実行して、ファイアウォール ルールを更新します。
terraform apply
  1. 値を入力するように求められたら、「yes」と入力します。

  2. terraform output コマンドを使用して出力を確認します。

terraform output

コマンド出力:

first_subnet_name = "my-first-subnet" my_subnet_name = "my-third-subnet" network_name = "my-custom-network"

タスク 9. 最初の VM を作成する

VM を作成してネットワークにデプロイすることにより、これまでに完了した作業を拡張します。また、ベースイメージを作成し、VM の構成情報を動的に階層化する方法についても学びます。

イメージを作成するには、最初に、イメージに含めるソフトウェアのインストール先となる VM を起動する必要があります。

最初の VM を起動する

  1. 最初のサブネットワークで gcloud を使用して VM を起動します。
gcloud compute instances create build-instance --zone={{{project_0.default_zone|zone}}} --machine-type=e2-standard-2 --subnet=my-first-subnet --network-tier=PREMIUM --maintenance-policy=MIGRATE --image=debian-10-buster-v20221206 --image-project=debian-cloud --boot-disk-size=100GB --boot-disk-type=pd-standard --boot-disk-device-name=build-instance-1 --tags=allow-ssh
  1. VM に SSH 接続します。
gcloud compute ssh build-instance --zone={{{project_0.default_zone|zone}}}

コマンド出力:

WARNING: The public SSH key file for gcloud does not exist. WARNING: The private SSH key file for gcloud does not exist. WARNING: You do not have an SSH key for gcloud. WARNING: SSH keygen will be executed to generate a key. This tool needs to create the directory [/home/user/.ssh] before being able to generate SSH keys. Do you want to continue (Y/n)?
  1. 「Y」と入力し、パスフレーズの入力を求められたら Enter キーを 2 回押します。

  2. Apache を VM にインストールします。

sudo apt-get update && sudo apt-get install apache2 -y
  1. SSH セッションを終了します。
exit

タスク 10. ベースイメージをキャプチャする

必要なソフトウェアを実行するマシンが用意できたので、そのマシンをベースイメージとしてキャプチャして、追加の同一の仮想マシンをスピンアップできます。

イメージを作成する

  1. VM を停止します。できるだけ、VM を停止してからイメージをキャプチャするようにしてください。
gcloud compute instances stop build-instance --zone={{{project_0.default_zone|zone}}}
  1. ブートディスクからイメージを作成します。
gcloud compute images create apache-one \ --source-disk build-instance \ --source-disk-zone {{{project_0.default_zone|zone}}} \ --family my-apache-webserver

ここでは、family パラメータを含めて、イメージをファミリーに結び付けています。これにより、そのファミリーから簡単に情報を取得したり、最新のイメージをデプロイしたりすることができます。

  1. gcloud を使用して、最新の my-apache-webserver イメージに関する情報を取得します。
gcloud compute images describe-from-family my-apache-webserver

完了したタスクをテストする

[進行状況を確認] をクリックして、実行したタスクを確認します。ブートディスクからイメージが正常に作成された場合は、評価スコアが表示されます。

ブートディスクからイメージを作成する

タスク 11. Terraform 構成を更新する

基となるイメージが用意できたので、Terraform を介してこのイメージをデプロイします。ただし、おすすめの方法は、Terraform 構成を論理単位に、VM インスタンスをアプリケーション層項目に分離することです。

そのため、新しいアプリケーション固有の Terraform 構成に切り替えてそこで更新を行い、ネットワーキング Terraform はそのままにします。

アプリケーション用の Terraform 構成を設定する

  1. Cloud Shell のアプリケーション ラボ ディレクトリに切り替えます。
cd ../lab-app
  1. ネットワーキング構成から認証情報と変数ファイルをコピーします。
cp ../lab-networking/credentials.json . cp ../lab-networking/terraform.tfvars .
  1. backend.tf を編集して、アプリケーション用の Terraform コードのバックエンド構成を更新します。
edit backend.tf 注: 同じ Cloud Storage バケットを再利用すると、アプリケーション状態用に別の プレフィックスを付けるだけで済みます。ここでは、前に使用したバケットと一致するようにバケット設定を更新してください。 terraform { backend "gcs" { bucket = "<プロジェクト ID>-state-bucket" # lab-networking/backend.tf ファイルと一致するようにこの行を編集します prefix = "terraform/lab/vm" } }
  1. Terraform リモート状態のデータソースも更新する必要があります。Terraform リモート状態は、複数のプロジェクト間で情報や出力を共有するのに役立ちます。たとえば、中央ネットワーキング チームがアプリケーション チームとサブネット情報を共有する場合などに非常に便利です。ここでは、前に使用したバケットと一致するようにバケット設定を更新してください。
data "terraform_remote_state" "network" { backend = "gcs" config = { bucket = "<プロジェクト ID>-state-bucket" # これも更新します prefix = "terraform/lab/network" } }

タスク 12. Terraform を介して VM をデプロイする

これで、インスタンスを起動するために作成したイメージを指すように Terraform を設定できます。インスタンスを起動する前に、この Terraform 構成の詳細を調べてみましょう。

VM 構成を確認する

  1. VM の Terraform 構成は vm.tf に保存されています。
edit vm.tf
  1. 目的のイメージをイメージ ファミリーにタグ付けしたため、Terraform によってそのファミリーから最新のイメージを取得できます。必要に応じて、指定したイメージ ファミリー名と一致するようにこのデータソースを更新します。
data "google_compute_image" "apache" { family = "my-apache-webserver" project = var.project_id }
  1. また、参照を使用して、デプロイ先のサブネット名を選択することもできます。data.terraform_remote_state.network.my_subnet_name の宣言では、前に作成したネットワーキング構成から my_subnet_name の出力が自動的に取得されます。
resource "google_compute_instance" "app" { ... network_interface { subnetwork = data.terraform_remote_state.network.my_subnet_name subnetwork_project = var.project_id access_config { # このセクションを記述して、外部 IP アドレスを VM に付与します } } ... } 注: ゾーンは、vm.tf ファイルのゾーンに置き換えてください。
  1. この構成ですべてが適切であれば、Terraform を使用して VM をデプロイできます。
terraform init terraform apply
  1. 値を入力するように求められたら、「yes」と入力します。

VM の外部 IP が出力されます。

Apply complete! Resources: 1 added, 0 changed, 0 destroyed. Outputs: ip = "35.185.255.154"
  1. ウェブブラウザで http://<自分の IP アドレス> を開いて、ウェルカム メッセージを確認します。

完了したタスクをテストする

[進行状況を確認] をクリックして、実行したタスクを確認します。Terraform を使用して VM インスタンスが正常にデプロイされた場合は、評価スコアが表示されます。

VM をデプロイする

タスク 13. アプリケーション VM を更新する

Terraform を介して VM 構成を定義することにより、Terraform 構成を微調整するだけで、アプリケーションの構成を宣言的に変更できます。

  1. vm.tf ファイルを開きます。
edit vm.tf
  1. 新しいウェルカム メッセージが表示されるように metadata_startup_script を変更します。
resource "google_compute_instance" "app" { ... metadata_startup_script = "echo '<!doctype html><html><body><h1>New message!</h1></body></html>' | sudo tee /var/www/html/index.html" # この行を編集します tags = ["allow-ping", "allow-http", "allow-ssh"] }
  1. Terraform を実行して、新しい構成で VM を再作成します。
terraform apply
  1. 値を入力するように求められたら、「yes」と入力します。

次のような出力が返されます。

Apply complete! Resources: 1 added, 0 changed, 1 destroyed. Outputs: ip = 34.83.209.192
  1. VM が完全に再作成された後、ウェブブラウザで http://<自分の IP アドレス> を開いて、新しいウェルカム メッセージを確認します。
注: Apply cancelled.」というメッセージが表示された場合は、「terraform apply」を再度入力します。

タスク 14. インフラストラクチャを破棄する

Terraform 構成を使用すると、インフラストラクチャを使い終わった後に簡単に破棄することもできます。これは、一時的な開発やテスト用のインフラストラクチャに特に役立ちます。

VM 構成を更新する

  1. Terraform を介して VM インフラストラクチャを破棄します。
terraform destroy

VM の破棄を確認するメッセージが表示されます。

An execution plan has been generated and is shown below. Resource actions are indicated with the following symbols: - destroy Terraform will perform the following actions: - google_compute_instance.app Plan: 0 to add, 0 to change, 1 to destroy. Do you really want to destroy all resources? Terraform will destroy all your managed infrastructure, as shown above. There is no undo. Only 'yes' will be accepted to confirm. Enter a value: yes
  1. 値を入力するように求められたら、「yes」と入力します。

「yes」と入力すると、Terraform によってインフラストラクチャの破棄が開始されます。

google_compute_instance.app: Destroying... (ID: my-app-instance) google_compute_instance.app: Still destroying... (ID: my-app-instance, 10s elapsed) google_compute_instance.app: Still destroying... (ID: my-app-instance, 20s elapsed) google_compute_instance.app: Still destroying... (ID: my-app-instance, 30s elapsed) google_compute_instance.app: Destruction complete after 36s Destroy complete! Resources: 1 destroyed.
  1. ネットワーキング インフラストラクチャもいつでも破棄できます。ネットワーキング インフラストラクチャは、ラボの有効期限が切れると自動的に破棄されます。

まとめ

これで、セルフペース ラボ「データセンターの移行: 自動化された基盤とデプロイ」は終了です。このラボでは、Google Cloud でネットワーク リソースのデプロイを自動化するワークフロー全体を完了しました。アクセス認証情報の設定、Terraform の設定、VPC ネットワーク、サブネット、ファイアウォール ルールなどのリソースの作成、既存のリソースの変更、それらのリソースの機能に関する十分な確認、およびその出力を行いました。

また、最初の VM の作成方法、ベースイメージのキャプチャ方法、Terraform 構成の更新方法、Terraform による VM のデプロイ方法についても学びました。

クエストを完了する

このセルフペース ラボは、「VM Migration」クエストの一部です。クエストとは学習プログラムを構成する一連のラボのことで、完了すると成果が認められてバッジが贈られます。バッジは公開して、オンライン レジュメやソーシャル メディア アカウントにリンクできます。このラボの修了後、次のクエストに登録すれば、すぐにクレジットを受け取ることができます。受講可能な全クエストについては、Google Cloud Skills Boost カタログをご覧ください。

次のラボを受講する

Migrate for Anthos: Qwik Start に進んでクエストを続けるか、別の Google Cloud Skills Boost ラボ(VM の移行: StratoZone の評価の概要など)をご確認ください。

次のステップと詳細情報

さらに知識を深めるには、Terraform での管理に使用できる次のリソースをご覧ください。

Google Cloud トレーニングと認定資格

Google Cloud トレーニングと認定資格を通して、Google Cloud 技術を最大限に活用できるようになります。必要な技術スキルとベスト プラクティスについて取り扱うクラスでは、学習を継続的に進めることができます。トレーニングは基礎レベルから上級レベルまであり、オンデマンド、ライブ、バーチャル参加など、多忙なスケジュールにも対応できるオプションが用意されています。認定資格を取得することで、Google Cloud テクノロジーに関するスキルと知識を証明できます。

マニュアルの最終更新日: 2023 年 12 月 8 日

ラボの最終テスト日: 2023 年 12 月 8 日

Copyright 2024 Google LLC All rights reserved. Google および Google のロゴは Google LLC の商標です。その他すべての企業名および商品名はそれぞれ各社の商標または登録商標です。