クラウドサービスとは? メリデメや種類についてポイント解説!
AWSやMicrosoft Azureなどのクラウドサービスとは、ストレージやデータベースなどの機能をインターネット上で利用できるサービスのことです。この記事では、クラウドサービス全体の特徴やメリット、クラウドサービスの種類などについて解説しています。
COLUMN
Terraformをクラウドゲートウェイサーバーホスティングで使ってみた
本コラムでは、Terraformの概要と、NTT東日本が提供するクラウドゲートウェイサーバーホスティング (以下「CGH」とします。)にてTerraformを用いてみた簡単な実施例を紹介します。
Terraformとは？
Terraformは、インフラを構成するクラウドのリソースをコードベースで安全かつ効率的に構築、変更、バージョン管理するためのコマンドラインツールです。
ここで、クラウドのリソースとは仮想化されたサーバーやネットワークなどを指します。
Terraformは、HashiCorp社よりオープンソース版とエンタープライズ版（有償版)が提供されており、Windows、Linux、Macなどに対応しています。
※オープンソース版のダウンロードページはこちらです。
https://www.terraform.io/downloads.html
※エンタープライズ版（有償版)は以下の公式サイトをご確認下さい。
https://www.terraform.io/docs/enterprise/index.html
本コラムでは、Windowsのオープンソース版バージョン「Terraform 0.12.8」を使用しています。お使いのバージョンによっては、本コラムとは異なる設定や動作となる場合がありますのでご注意下さい。
Terraform Custom Provider for Enterprise Cloud 2.0
Terraformは、Amazon Web Services、Microsoft Azure、Google Cloud Platformなど様々なクラウドプラットフォームに対応しています。
NTT東日本が提供するCGHでも、2019年4月24日より公開されている「Terraform Custom Provider for Enterprise Cloud 2.0」を利用することで、Terraformで管理することができるようになります。
Terraformでは管理できるクラウドなどのプラットフォームをプロバイダと呼びます。プロバイダには、Terraformにあらかじめビルトインされているプロバイダと、ビルトインされていないプロバイダがあります。ビルトインされていないプロバイダは、プロバイダなどが提供するカスタムプロバイダという「プラグイン」を導入することで管理することができます。
「Terraform Custom Provider for Enterprise Cloud 2.0」は、ここでいうカスタムプロバイダになります。
Infrastructure as code（コードとしてのインフラ）によるメリット
Terraformはコードベースでクラウドのリソースを扱うため、Infrastructure as codeに分類されます。
クラウドへ配置するリソースを宣言的に定義するための言語として、HashiCorp社が開発したJSON形式と互換性のあるHashiCorp Configuration Language(以下「HCL」とします。)を使用します。
Terraformを利用してコードベースでインフラを管理することで、
- GUIを使用しないインフラの変更
- 第三者によるコードの検証
- GitHubなどのバージョン管理系クラウドサービスでの管理
- 作成済みのコードの再利用
ができるようになり、
- インフラ構築の自動化により、人的ミスの減少と作業時間の短縮が期待できる。
- インフラの構成確認や変更履歴などの管理が容易となる。
- インフラ構成の複製や変更が容易に行える。
というようなメリットを受けることができるようになります。
Terraformのコマンド
Terraformのコマンドでは、HCLで記述したコードを元にリソースの作成・削除・変更を行う以外にリソース同士の関連図の作成、変数の代入、コードのインデント自動調整などのさまざまな機能が提供されています。ここでは、主な一部機能のみの紹介となりますが、ここにない機能については、以下で確認することができます。
https://www.terraform.io/docs/commands/index.html
terraform init
主に作業用ディレクトリを初期化するコマンドです。
terraform version
Terraformのバージョンを確認できます。
terraform plan
リソースの作成・削除・変更を事前に確認するコマンドです(これを「Dry-Run」といいます。)。Dry-Runを行うことで、定義したコードに間違いはないか、意図した内容となっているのかを確認することできます。
以下はキーペア作成を確認する“terraform plan”を実行した結果の一部抜粋です。
+ resource "ecl_compute_keypair_v2" "kp_1" {
+ fingerprint = (known after apply)
+ id = (known after apply)
+ name = "keypair-1"
+ private_key = (known after apply)
+ public_key = (known after apply)
+ region = (known after apply)
}
Plan: 1 to add, 0 to change, 0 to destroy.
新しく作成されるリソース”ecl_compute_keypair_v2”に記号「＋」が付与されています。
planの実行結果で、定義したリソースに対して付与される以下の記号によって、実際に行われる動作を事前に確認することができます。
「+」・・・新規にリソースを作成
「-」・・・既存リソースを削除
「~」・・・既存リソースの設定を変更
「-/+」・・既存リソースを削除し、新しいリソースを作成
最後の行には、作成(add)、変更(change)、削除(destroy)される予定のリソースの数が表示されます。
terraform apply
コードで定義したリソースの作成・削除・変更を行います。
terraform destroy
Terraformで作成したリソースを一括で削除するコマンドです。
terraform graph
リソース間の依存関係をdot言語で記述したテキストファイルへ出力するコマンドです。
出力したテキストファイルはGraphviz（http://www.graphviz.org/）を利用し、画像ファイルへ変換します。
設定ファイルの構成
Terraformを利用するには、拡張子を“.tf”とするファイル（以下、「tfファイル」とします。）を作成します。
tfファイルには、インフラを構成するリソースを前述のHCLを用いて定義します。
ひとつのtfファイルに全てのリソースを定義することも、リソース毎に複数のファイルに分けることも可能です。
tfファイルでは、以下3つのセクションで構成されます。
- providerセクション
- resourceセクション
- dataセクション
providerセクション
providerセクションでは、「プロバイダ」の認証情報を定義します。
CGHを利用するためには以下のように記述します。
provider "ecl" {
auth_url = "https://keystone-<リージョン>-ecl.api.ntt.com/v3/"
user_name = "<API鍵>"
password = "<API秘密鍵>"
tenant_id = "<テナントID>"
user_domain_id = "default"
project_domain_id = "default"
}
Terraformで管理するテナントの<リージョン>、<API鍵>、<API秘密鍵>、<テナントID>はCGHのポータル画面で確認します。
本コラムでは、割愛しますが、プロバイダを複数記述することで異なるクラウドのインフラを管理することも可能です。
※ここでは、認証情報を直接記述していますが、後ほど変数として記述する方法を説明します。
resourceセクション
resourceセクションではTerraformで管理するリソースを、リソース単位で以下のように定義します。
resource “リソースタイプ” “リソース名” {
属性名 = 属性の値
}
ボリュームをリソースとする例で各要素を説明します。
resource "ecl_compute_volume_v2" "volume_1" {
name = "volume-1"
size = “15”
}
ボリューム名を“volume-1”とする容量15GBのボリュームを作成するリソース定義の例です。
- ボリュームを表すリソースタイプの“ecl_compute_volume_v2”は「Terraform Custom Provider for Enterprise Cloud 2.0」が定めた値を使用します。
- リソース名には任意の値が記述可能ですが、同じリソースタイプ内では、ユニークとする必要があります。
- “name”と“size”が属性名、“volume-1”と“15”がそれらに対応する属性の値になります。属性名は複数書くことが可能です。
※Terraform Custom Provider for Enterprise Cloud 2.0がサポートするリソースやリソース毎に指定可能な属性名、属性の値はGitHub上に公開されています。
https://github.com/nttcom/terraform-provider-ecl/tree/master/website/docs/r
data セクション
dataセクションは、必須の定義ではありませんが、dataセクションを定義することでTerraformを用いずに、ポータルなどから作成したリソースの値を、resource セクションで定義したリソースへパラメータとして動的に渡すことができるようになります。
OSイメージなどクラウドが用意しているリソースもdataセクションで利用することができます。
※dataセクションで定義するこれらのリソースをTerraform管理外のリソースといいます。逆に、resourceセクションで定義するリソースは、Terraform管理のリソースといいます。
※Terraform管理のリソースの値であれば、dataセクションを利用しなくても動的に渡すことができます。詳しくは後ほど説明します。
dataセクションでは、以下のようにTerraform管理外のリソースを定義します。
data "リソースタイプ" "リソース名" {
検索条件(リソース)
}
Terraform管理外のロジカルネットワークをデータソースとする例でdataセクションの各要素を説明します。
data “ecl_network_network_v2” “network” {
name = “test”
}
リソース名“test”のロジカルネットワークからIDなどの情報を取得するdataセクションの記述例です。
- ロジカルネットワークを表すリソースタイプの“ecl_network_network_v2”は Terraform Custom Provider for Enterprise Cloud 2.0が定めた値を使用します。
- リソース名には、任意の値が記述可能で、リソースから取得したIDなどの情報が格納されます。
- 検索条件にはキーとなる属性名を左辺、その属性の値を右辺とし、“=”で結合して記述します。この例では、属性名を“name”、その値を“test”とする検索条件を記述しています。複数の検索条件を記述することも可能です。
※Terraform Custom Provider for Enterprise Cloud 2.0がサポートするデータソースやデータソース毎に使用可能な検索条件はGitHub上に公開されています。
https://github.com/nttcom/terraform-provider-ecl/tree/master/website/docs/d
具体的な例として、ポータルを利用して作成した“test”という名前のロジカルネットワークのネットワークIDを参照し、そのロジカルネットワークの配下に作成するサブネット“subnet_1”の属性の値として渡す場合の記載例を説明します。
data “ecl_network_network_v2” “network” {
name = “test”
}
resource “ecl_network_subnet_v2” “subnet_1” {
name = “subnet_1”
cidr = “subnet_1”
network_id = “${data.ecl_network_network_v2.network.id}”
}
ネットワークIDのデータソースを参照するには、“${data.リソースタイプ.リソース名.属性}”という形で記述します。
この例では、リソースタイプが“ecl_network_network_v2”、リソース名が“network”、属性が“id”となります。
他のリソースの情報を参照する方法
Terraform管理のリソースの値を参照する方法を紹介します。
dataセクションでは、ポータルから作成したTerraform管理外のリソースを参照していました。今回は、Terraformで作成したロジカルネットワークのIDを参照する例で説明します。
resource "ecl_network_network_v2" "network_1" {
name = "network_1"
plane = "data"
}
resource "ecl_network_subnet_v2" "subnet_1" {
name = "subnet_1"
network_id = "${ecl_network_network_v2.network_1.id}"
no_gateway = "true"
enable_dhcp = "false"
}
最初のresourceセクションの定義で“network_1”という名前のロジカルネットワークを作成し、次のresourceセクションの定義で“subnet_1”という名前のサブネットを作成します。
ここで“network_1”内に“subnet_1”を作成するために、“network_id”の属性の値に“network_1”のロジカルネットワークIDを参照させます。
Terraformで作成したリソースの情報を参照するには、“${リソースタイプ.リソース名.属性名}”と記述します。この例では、リソースタイプを“ecl_network_network_v2”、リソース名を“network_1”、属性を“id”としています。
※リソースの属性を参照する際に“${}”という記法を使いましたが、“${}”を利用するとこれ以外にも、変数を展開したり、組み込みの関数を呼び出したりすることができるようになります。
依存関係の付与
tfファイルで記述できるリソースの属性は、CGHのAPIやポータル画面からリソースを作成する際に指定できる全ての属性に対応していません。
例えば、CGHで仮想サーバーのインスタンスを作成する際には、あらかじめ作成した接続するロジカルネットワークを指定し、リソース間に依存関係を持たせますが、Terraformのこれまで紹介した記述法のみでは、これを実現することができません。
これを解決するため、“depends_on”というパラメータが用意されています。“depends_on”をresourceセクションに追加することでリソース間に依存関係を付与することができるようになります。
“depends_on”を利用し、仮想サーバーインスタンスにロジカルネットワークのサブネットの“id”との依存関係を付与する例が以下です。
resource "ecl_network_network_v2" "network_1" {
name = "network_1"
plane = "data"
}
resource "ecl_network_subnet_v2" "subnet_1" {
name = "subnet_1"
network_id = "${ecl_network_network_v2.network_1.id}"
cidr = "192.168.1.0/24"
no_gateway = "true"
enable_dhcp = "false"
}
}
data "ecl_imagestorages_image_v2" "image_1" {
most_recent = true
name = "Ubuntu-14.04.1_64_virtual-server_02"
}
resource "ecl_compute_instance_v2" "instance_1" {
name = "instance_1"
image_id = "${data.ecl_imagestorages_image_v2.image_1.id}"
flavor_id = "1CPU-2GB"
network {
uuid = "${ecl_network_network_v2.network_1.id}"
}
depends_on = ["ecl_network_subnet_v2.subnet_1"]
}
仮想サーバーインスタンスを定義するresourceセクションに
“depends_on = [“ecl_network_subnet_v2.subnet_1”]”
を記述することでサブネットとの依存関係を付与しています。
設定ファイルのインデント自動調整
コードレビュー時にインデントがずれているという指摘があると思います。
“terraform fmt”によりtfファイルのインデントの自動調整ができます。
上のようにインデントがずれた状態のtfファイルへ“terraform fmt”を実施し、インデントが揃えることができました。
変数の定義(宣言)・代入・利用
tfファイルをGitHubなどで管理する場合、認証情報を直接書き込んだままgit pushしてしまうと、認証情報を公開してしまい情報漏えいの原因となってしまいます。
このようなことを避けるために、変数を利用して認証情報を渡す方法を紹介します。
変数の定義(宣言)
“variable.tf”というファイルに以下を記述し、空の変数を宣言します。
variable "api_key" {}
variable "api_secret_key" {}
variable "tenant_id {}
variable "region" {
default = https://keystone-jp1-ecl.api.ntt.com/v3/
}
“api_key”、“api_secret_key”、“tenant_id”は、“{}”（空のブロック）で定義します。
“region”のようにデフォルトで値を設定することも可能です。今回はjp1リージョンのテナントで作業しているため“jp1”と記述しています。別リージョンの場合は
“https://keystone-<リージョン>-ecl.api.ntt.com/v3/”
と<リージョン>の箇所を置き換えて下さい。
providerセクションでの変数の参照
tfファイルのproviderセクションで、“variable.tf”に定義した変数を参照するために、以下のように“${var.変数名}”という形式で“variable.tf”に定義した変数名を指定します。
provider "ecl" {
auth_url = "${var.region}"
user_name = "${var.api_key}"
password = "${var.api_secret_key}"
tenant_id = "${var.tenant_id}"
user_domain_id = "default"
project_domain_id = "default"
}
変数への値の代入方法
定義した変数に値を代入するには、以下3通りの方法があります。
Terraformコマンドのパラメータで値を代入
Terraform実行時のパラメータで“terraform <plan/apply/..> -var <変数名>=<値>”と指定し、変数に値を代入します。
Terraform plan –var api_key=<api鍵> -var api_secret_key=<api秘密鍵> -var tenant_id=<テナントID>
ファイルで値を代入
以下を記述した“terraform.tfvars”あるいは、“*.auto.tfvars”ファイルを作成します。Terraform実行時にこれらのファイルが読み込まれ、変数に値を代入します。
api_key = “<API鍵>”
api_secret_key = “<API秘密鍵>”
tenant_id = “<テナントID>”
環境変数で値を代入
TF_VAR_<変数名>=<変数の値>で環境変数を設定します。Terraform実行時に環境変数が読み込まれ、変数に値を代入します。
set TF_VAR_api_key =<API鍵>
set TF_VAR_api_secret_key =<API秘密鍵>
set TF_VAR_tenant_id =<テナントID>
インストール
TerraformはWindows、Linux、Macなどに対応していますが、CGHのプラグインは64bitのみに対応しています。今回は、Windows(64bit)でインストールの説明を行います。
Terraformおよびプラグインのインストール
① 公式サイトからTerraform 本体をダウンロードします。
※ダウンロードはこちらから
https://www.terraform.io/downloads.html
② ダウンロードしたzipファイルを展開し、“terraform.exe”を任意のフォルダに配置します。
※今回は、以下フォルダに配置しています。
C:\User\<ユーザー名>\Desktop\terraform
③ フォルダへのパスを通します。
set PATH=%PATH%;C:\Users\<ユーザー名>\Desktop\terraform
④ 続いてGitHubからCGHのプラグイン「Terraform Custom Provider for Enterprise Cloud 2.0」をダウンロードします。
※ダウンロードはこちらから。
https://github.com/nttcom/terraform-provider-ecl/tree/master/website/docs/d
⑤ ダウンロードしたzipファイルを展開し、“terraform-provider-ecl.exe”を“terraform.exe”と同じフォルダに配置します。
⑥ 確認のためにコマンド“terraform”と“terraform version”を実行し、以下のように表示されればインストールは完了です。
C:\Users\~\Desktop\terraform\work>terraform
Usage: terraform [-version] [-help] <command> [args]
The available commands for execution are listed below.
The most common, useful commands are shown first, followed by
less common or more advanced commands. If you're just getting
started with Terraform, stick with the common commands. For the
other commands, please read the help and docs before usage.
Common commands:
apply Builds or changes infrastructure
console Interactive console for Terraform interpolations
destroy Destroy Terraform-managed infrastructure
env Workspace management
fmt Rewrites config files to canonical format
get Download and install modules for the configuration
graph Create a visual graph of Terraform resources
import Import existing infrastructure into Terraform
init Initialize a Terraform working directory
output Read an output from a state file
plan Generate and show an execution plan
providers Prints a tree of the providers used in the configuration
refresh Update local state file against real resources
show Inspect Terraform state or plan
taint Manually mark a resource for recreation
untaint Manually unmark a resource as tainted
validate Validates the Terraform files
version Prints the Terraform version
workspace Workspace management
All other commands:
0.12upgrade Rewrites pre-0.12 module source code for v0.12
debug Debug output management (experimental)
force-unlock Manually unlock the terraform state
push Obsolete command for Terraform Enterprise legacy (v1)
state Advanced state management
C:\Users\~\Desktop\terraform\work>
C:\Users\~\Desktop\terraform\work>terraform version
Terraform v0.12.8
Your version of Terraform is out of date! The latest version
is 0.12.9. You can update by downloading from
www.terraform.io/downloads.html
CGHでの実施例
これまでの紹介した内容を踏まえ、TerraformでCGHのテナント上に仮想サーバーとロジカルネットワークをひとつ作成し、ロジカルネットワークのサブネットに仮想サーバーを接続した例を紹介します。
作業は以下の順で行っています。
- 作業フォルダの作成
- 認証情報の定義
- tfファイルの作成
- Terraformの実行
- リソース一式の削除
作業フォルダの作成
Terraformを配置したフォルダの配下に作業フォルダ“work”を作成します。この作業フォルダにこれから作成するリソースを定義したtfファイルや認証情報を定義したファイルを配置します。Terraformもこのフォルダで実行します。
認証情報の定義
同じフォルダに認証情報を定義したvariable.tfとterraform.tfvarsを作成します。
・variable.tfの設定内容
variable "api_key" {}
variable "api_secret_key" {}
variable "tenant_id” {}
variable "region" {
default = https://keystone-jp1-ecl.api.ntt.com/v3/
}
・terraform.tfvarsの設定内容
api_key = “<API鍵>”
api_secret_key = “<API秘密鍵>”
tenant_id = “<テナントID>”
tfファイルの作成
ロジカルネットワーク、サブネット、仮想サーバーの3つのリソースを作成するtfファイルを作成します。providerセクション内の認証情報を変数化し、dataセクションを使用して仮想サーバーのOSイメージにUbuntuを指定し、“depends_on”を利用してネットワークとの関連付けも行っています。
provider "ecl" {
auth_url = "${var.region}"
user_name = "${var.api_key}"
password = "${var.api_secret_key}"
tenant_id = "${var.tenant_id}"
user_domain_id = "default"
project_domain_id = "default"
}
data "ecl_imagestorages_image_v2" "image_1" {
most_recent = true
name = "Ubuntu-14.04.1_64_virtual-server_02"
}
resource "ecl_network_network_v2" "network_1" {
name = "network_1"
plane = "data"
}
resource "ecl_network_subnet_v2" "subnet_1" {
name = "subnet_1"
network_id = "${ecl_network_network_v2.network_1.id}"
cidr = "192.168.1.0/24"
no_gateway = "true"
enable_dhcp = "false"
}
resource "ecl_compute_instance_v2" "instance_1" {
name = "instance_1"
image_id = "${data.ecl_imagestorages_image_v2.image_1.id}"
flavor_id = "1CPU-2GB"
network {
uuid = "${ecl_network_network_v2.network_1.id}"
}
depends_on = ["ecl_network_subnet_v2.subnet_1"]
}
Terraformの実行
用意ができましたので、Terraformを利用してリソースの作成を行っていきます。
まず、“terraform init”で初期化を行います。
C:\Users\~\Desktop\terraform\work>terraform init
Initializing the backend...
Initializing provider plugins...
Terraform has been successfully initialized!
You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.
If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.
C:\Users\~\Desktop\terraform\work>
次に、“terraform graph”でリソースの依存関係図を作成し、確認してみます。
C:\Users\~\Desktop\terraform\work>terraform graph > input.dot
出力結果をGraphvizを使用してpng形式の画像ファイルに変換します。
C:\Users\~\Desktop\terraform\work>dot -Tpng input.dot > output.png
※事前に公式サイトからGraphvizのzipファイルをダウンロードし、任意のフォルダに展開します。展開したフォルダ名をgraphvizに変更させ、PATHを通します。
set PATH=%PATH%;C:\Users\<ユーザー名>\Desktop\graphviz\bin
図を開くと以下のようなリソース同士の依存関係が確認できます。
実際にリソースの作成を行う前に“terraform plan”を実行し、期待通りにロジカルネットワーク、サブネット、インスタンスが作成されることを確認します。
C:\Users\~\Desktop\terraform\work >terraform plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.
data.ecl_imagestorages_image_v2.image_1: Refreshing state...
------------------------------------------------------------------------
An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
+ create
Terraform will perform the following actions:
# ecl_compute_instance_v2.instance_1 will be created
+ resource "ecl_compute_instance_v2" "instance_1" {
+ access_ip_v4 = (known after apply)
+ all_metadata = (known after apply)
+ availability_zone = (known after apply)
+ flavor_id = "1CPU-2GB"
+ flavor_name = (known after apply)
+ id = (known after apply)
+ image_id = "ad936ae4-2983-4f23-9187-e47e82cb2725"
+ image_name = (known after apply)
+ name = "instance_1"
+ power_state = "active"
+ region = (known after apply)
+ stop_before_destroy = false
+ network {
+ access_network = false
+ fixed_ip_v4 = (known after apply)
+ mac = (known after apply)
+ name = (known after apply)
+ port = (known after apply)
+ uuid = (known after apply)
}
}
# ecl_network_network_v2.network_1 will be created
+ resource "ecl_network_network_v2" "network_1" {
+ admin_state_up = (known after apply)
+ id = (known after apply)
+ name = "network_1"
+ plane = "data"
+ region = (known after apply)
+ shared = (known after apply)
+ status = (known after apply)
+ subnets = (known after apply)
+ tenant_id = (known after apply)
}
# ecl_network_subnet_v2.subnet_1 will be created
+ resource "ecl_network_subnet_v2" "subnet_1" {
+ cidr = "192.168.1.0/24"
+ dns_nameservers = (known after apply)
+ enable_dhcp = false
+ gateway_ip = (known after apply)
+ id = (known after apply)
+ ip_version = 4
+ ipv6_address_mode = (known after apply)
+ ipv6_ra_mode = (known after apply)
+ name = "subnet_1"
+ network_id = (known after apply)
+ no_gateway = true
+ region = (known after apply)
+ status = (known after apply)
+ tenant_id = (known after apply)
+ allocation_pools {
+ end = (known after apply)
+ start = (known after apply)
}
}
Plan: 3 to add, 0 to change, 0 to destroy.
------------------------------------------------------------------------
Note: You didn't specify an "-out" parameter to save this plan, so Terraform
can't guarantee that exactly these actions will be performed if
"terraform apply" is subsequently run.
問題なく３つのリソースが作成されることが確認できたので、“terraform apply”を実行し、実際にリソースを作成します。
“terraform plan”と同じ内容が出力されたあとに、実施を確認する以下のメッセージが出力されますので、”Enter a value: “に“yes”と入力します。
Do you want to perform these actions?
Terraform will perform the actions described above.
Only 'yes' will be accepted to approve.
Enter a value:
C:\Users\~\Desktop\terraform\work >terraform apply
～
（前半はplanと同様の出力が行われますので省略します。）
～
Plan: 3 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: yes
ecl_network_network_v2.network_1: Creating...
ecl_network_network_v2.network_1: Creation complete after 9s [id=2957a8da-e4c5-45ac-ba7c-d5635a7f3094]
ecl_network_subnet_v2.subnet_1: Creating...
ecl_network_subnet_v2.subnet_1: Creation complete after 6s [id=29f79bf0-8789-4154-bf34-9c6ed7deff12]
ecl_compute_instance_v2.instance_1: Creating...
ecl_compute_instance_v2.instance_1: Still creating... [10s elapsed]
ecl_compute_instance_v2.instance_1: Creation complete after 13s [id=a0dd90b0-bb7f-4301-a354-00327e9c5da8]
Apply complete! Resources: 3 added, 0 changed, 0 destroyed.
“Apply complete!”が出力されたので、無事完了です。ポータルでもロジカルネットワークにつながった状態で仮想サーバーが作成できたことが確認できました。
リソースの一式削除
最後に作成したリソースを削除します。実施の前に“terraform plan –destroy”で、作成したロジカルネットワーク、サブネット、インスタンスが削除されることを確認します。
C:\Users\~\Desktop\terraform\work>terraform plan -destroy
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.
data.ecl_imagestorages_image_v2.image_1: Refreshing state...
ecl_network_network_v2.network_1: Refreshing state... [id=8b8a1eec-d583-4790-a2dc-b21278dd836a]
ecl_network_subnet_v2.subnet_1: Refreshing state... [id=bb17604b-8aaa-4430-9a99-4041a060c729]
ecl_compute_instance_v2.instance_1: Refreshing state... [id=d8e6b509-556c-4305-b6fe-b5948aadac40]
------------------------------------------------------------------------
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:
# ecl_compute_instance_v2.instance_1 will be destroyed
- resource "ecl_compute_instance_v2" "instance_1" {
- access_ip_v4 = "192.168.1.2" -> null
- all_metadata = {} -> null
- availability_zone = "zone1-groupa" -> null
- flavor_id = "1CPU-2GB" -> null
- flavor_name = "1CPU-2GB" -> null
- id = "d8e6b509-556c-4305-b6fe-b5948aadac40" -> null
- image_id = "ad936ae4-2983-4f23-9187-e47e82cb2725" -> null
- image_name = "Ubuntu-14.04.1_64_virtual-server_02" -> null
- name = "instance_1" -> null
- power_state = "active" -> null
- stop_before_destroy = false -> null
- network {
- access_network = false -> null
- fixed_ip_v4 = "192.168.1.2" -> null
- mac = "fa:16:3e:10:fc:f7" -> null
- name = "network_1" -> null
- uuid = "8b8a1eec-d583-4790-a2dc-b21278dd836a" -> null
}
}
# ecl_network_network_v2.network_1 will be destroyed
- resource "ecl_network_network_v2" "network_1" {
- admin_state_up = true -> null
- id = "8b8a1eec-d583-4790-a2dc-b21278dd836a" -> null
- name = "network_1" -> null
- plane = "data" -> null
- shared = false -> null
- status = "ACTIVE" -> null
- subnets = [
- "bb17604b-8aaa-4430-9a99-4041a060c729",
] -> null
- tags = {} -> null
- tenant_id = "XXXX" -> null
}
# ecl_network_subnet_v2.subnet_1 will be destroyed
- resource "ecl_network_subnet_v2" "subnet_1" {
- cidr = "192.168.1.0/24" -> null
- dns_nameservers = [] -> null
- enable_dhcp = false -> null
- id = "bb17604b-8aaa-4430-9a99-4041a060c729" -> null
- ip_version = 4 -> null
- name = "subnet_1" -> null
- network_id = "8b8a1eec-d583-4790-a2dc-b21278dd836a" -> null
- no_gateway = true -> null
- ntp_servers = [] -> null
- status = "ACTIVE" -> null
- tags = {} -> null
- tenant_id = "XXXX" -> null
- allocation_pools {
- end = "192.168.1.254" -> null
- start = "192.168.1.2" -> null
}
}
Plan: 0 to add, 0 to change, 3 to destroy.
------------------------------------------------------------------------
Note: You didn't specify an "-out" parameter to save this plan, so Terraform
can't guarantee that exactly these actions will be performed if
"terraform apply" is subsequently run.
------------------------------------------------------------------------
Note: You didn't specify an "-out" parameter to save this plan, so Terraform
can't guarantee that exactly these actions will be performed if
"terraform apply" is subsequently run.
期待通りにリソースが削除されることが確認できましたので、“terraform destroy”でリソースを削除します。
※applyと同じように実施確認のメッセージが出力されますので、“yes”と入力します。
C:\Users\nwse2\Desktop\terraform\work>terraform destroy
～
（前半はplanと同様の出力が行われますので省略します。）
～
Plan: 0 to add, 0 to change, 3 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
ecl_compute_instance_v2.instance_1: Destroying... [id=d8e6b509-556c-4305-b6fe-b5948aadac40]
ecl_compute_instance_v2.instance_1: Still destroying... [id=d8e6b509-556c-4305-b6fe-b5948aadac40, 10s elapsed]
ecl_compute_instance_v2.instance_1: Destruction complete after 12s
ecl_network_subnet_v2.subnet_1: Destroying... [id=bb17604b-8aaa-4430-9a99-4041a060c729]
ecl_network_subnet_v2.subnet_1: Still destroying... [id=bb17604b-8aaa-4430-9a99-4041a060c729, 10s elapsed]
ecl_network_subnet_v2.subnet_1: Still destroying... [id=bb17604b-8aaa-4430-9a99-4041a060c729, 20s elapsed]
ecl_network_subnet_v2.subnet_1: Still destroying... [id=bb17604b-8aaa-4430-9a99-4041a060c729, 30s elapsed]
ecl_network_subnet_v2.subnet_1: Destruction complete after 36s
ecl_network_network_v2.network_1: Destroying... [id=8b8a1eec-d583-4790-a2dc-b21278dd836a]
ecl_network_network_v2.network_1: Destruction complete after 5s
Destroy complete! Resources: 3 destroyed.
“Destroy complete!”で無事完了です。ポータルからもリソースが削除できたことが確認できました。
簡単でしたが以上となります。
関連サービス：
- NTT東日本のクラウドをご利用の場合には、「クラウドゲートウェイ サーバーホスティング」をご検討ください。
RECOMMEND
その他のコラム
無料ダウンロード
自社のクラウド導入に必要な知識、ポイントを
この１冊に総まとめ！
あなたはクラウド化の
何の情報を知りたいですか？
- そもそも自社は本当にクラウド化すべき？オンプレとクラウドの違いは？
- 【AWS・Azure・Google Cloud】
どれが自社に最もマッチするの？ - 情シス担当者の負荷を減らしてコストを軽減するクラウド化のポイントは？
- 自社のクラウド導入を実現するまでの具体的な流れ・検討する順番は？
初めての自社クラウド導入、
わからないことが多く困ってしまいますよね。
NTT東日本では
そんなあなたにクラウド導入に必要な情報を
1冊の冊子にまとめました！
クラウド化のポイントを知らずに導入を進めると、以下のような事になってしまうことも・・・
- システムインフラの維持にかかるトータルコストがあまり変わらない。。
- 情シス担当者の負担が減らない。。
- セキュリティ性・速度など、クラウド期待する効果を十分に享受できない。。
理想的なクラウド環境を実現するためにも、
最低限の4つのポイントを
抑えておきたいところです。
-
そもそも”クラウド化”とは？
その本質的なメリット・デメリット - 自社にとって
最適なクラウド環境構築のポイント - コストを抑えるための
具体的なコツ - 既存環境からスムーズにクラウド化を
実現するためのロードマップ
など、この1冊だけで自社のクラウド化のポイントが簡単に理解できます。
またNTT東日本でクラウド化を実現し
問題を解決した事例や、
導入サポートサービスも掲載しているので、
ぜひダウンロードして読んでみてください。
クラウドのわからない・
面倒でお困りのあなたへクラウドのご相談できます！
面倒でお困りのあなたへ
クラウドのご相談できます！
無料オンライン相談窓口
NTT東日本なら貴社のクラウド導入設計から
ネットワーク環境構築・セキュリティ・運用まで
”ワンストップ支援”が可能です！
NTT東日本が選ばれる5つの理由
- クラウド導入を
0からワンストップでサポート可能！ - 全体最適におけるコスト効率・業務効率の改善を
中立的にご提案 - クラウド環境に問題がないか、
第3者目線でチェック
してもらいたい - 安心の24時間・365日の対応・保守
- NTT東日本が保有する豊富なサービスの組み合わせで
”課題解決”と”コスト軽減”を両立
特に以下に当てはまる方はお気軽に
ご相談ください。
- さまざまな種類やクラウド提供事業者があってどれが自社に適切かわからない
- オンプレミスのままがよいのか、クラウド移行すべきなのか、迷っている
- オンプレミスとクラウド移行した際のコスト比較を行いたい
- AWSとAzure、どちらのクラウドが自社に適切かわからない
- クラウド環境に問題がないか、第3者目線でチェックしてもらいたい
- クラウド利用中、ネットワークの速度が遅くて業務に支障がでている
クラウドを熟知するプロが、クラウド導入におけるお客さまのLAN 環境や接続ネットワーク、
クラウドサービスまでトータルにお客さまのお悩みや課題の解決をサポートします｡
相談無料！プロが中立的にアドバイスいたします
クラウド・AWS・Azureでお困りの方はお気軽にご相談ください。