Tech Sketch Bucket of Technical Chips by TIS Inc.

Terraformを使う!「TerraformからAWSインスタンスを操作する際のハマりどころ」

Pocket

前回はTerraformの導入~AWSインスタンスの操作の仕方までをお知らせしました。
第二回はTerraformを利用していてハマった所について書いて行きたいと思います。
Terraformの基本的な操作や設定ファイルの書き方などは 第一回の記事 をご参照ください。


検証環境

今回Terraformを実行したサーバOSとTerraformのバージョンを明記します。

検証時期 2014/09/11
OS Ubuntu 14.04 LTS 64bit
Terraform Ver0.2.2

ハマりどころ①「設定ファイルの記述ミス時にCrashErrorが発生する場合がある」

Terraformでは計画(Plan)時に自身で記載した設定ファイル(.tfファイル)を読み込みどのような値で実行するかを確認できます。
では記載した設定ファイルにミスがあった場合にはどのような挙動をするのでしょうか。

実際に見て行きましょう。

設定ファイル作成(記述ミスを含む)

この例では15行目のsecurity_groupsの書式に間違いがあります。
ここで指定しているsecurity_groupsは事前に作成しておいたdefaultとは違うグループを使用しています。
正しくは下記の用に記載します。

次に間違いを含んだ設定ファイルを計画していきます。

計画(記述ミスを含む)

上記で作成した記述ミスを含んだ設定ファイルを計画します。

8行目でruntime.panicが発生し、TerraformがCrashしてしまいました。
24行目でCrashした時のログが"crash.log"として実行時のカレントディレクトリに出力された旨が出力されておりますが、今回ケースでは有益なログを取得出来なかったためログの掲載は割愛します。

このように設定ファイルに記述ミスなどがあると実行前の計画段階でミスを検知できます。
しかしながらVer0.2.2では一部エラーハンドリングが出来ていないため原因の特定が難しくもあります。

今回のエラーもTerraformCrashのためログから詳細な原因特定は難しいですが、Terraformを使わずCloudFormationで実行した場合には計画のプロセスが無いためインスタンスが作成され、課金が発生してしまうことを考えると事前に検知出来たほうが良いでしょう。

Terraformの開発自体もものすごいスピードで行われているため、今後はエラーハンドリングも改善され使いやすいものになるでしょう。

設定ファイル修正

今回のエラーは設定ファイルの記述ミスが原因なので修正していきます。

15行目のsecurity_groupsを「"sg-500a8635"」から「["sg-500a8635"]」へ修正を加えています。

計画

設定ファイルに間違いはないので正常に計画と実行ができます。

実行

正常にインスタンスの作成ができました。
設定ファイルにミスが無い場合は意図した挙動を計画立てて実行してくれます。

aws001.JPG

ハマりどころ②「terraformからのインスタンスの変更について」

terraformには作成済みインスタンスの変更(change)を加えることが出来ます。
変更時に注意が必要なのが「変更に際しリソースの再生成が必要になる場合は、既存のリソースを削除して新たにリソースを作成する」という所です。

実際の挙動を見て行きましょう。
既存インスタンスはハマりどころ①で作成した
instanceID"i-d6ea5cd9"インスタンスを使用します。

設定ファイル作成

設定ファイルは以下のものを使用します。
変更箇所については計画で確認しましょう。

次にこの変更を計画します。

計画

作成した設定ファイルを元に計画を立てます。

変更点は

  • "key_name"が"tis_key01" から "tis_key02"へ変更
  • "security_groups"が"sg-500a8635" から "sg-900518f2"へ変更

の二点です。

AWSの仕様によりkey_nameはインスタンスを再生成しなくては変更が出来ません。
TerraformはAWSの仕様に沿って動作するので「(forces new resource)」と表示され既存インスタンスを削除してから新しいインスタンスを作成することで変更を実現します。

security_groupsはインスタンスの再生成を必要としない変更のため「(forces new resource)」が表示されず、値の変更のみを行います。

次に計画を実行していきます。

実行

9行目でkey_nameが"tis_key01"から"tis_key02"へ変更され、
15行目でsecurity_groupsが"sg-500a8635"から"sg-900518f2"へ変更されてます。

19行目でApply complete!と表示されていることから実行は成功です。
ただし、コンプリートメッセージの後ろに表示されている

  • 1 changed
  • 1 destroyed

からもわかるように一つの変更(changed)と一つの破壊(destroyed)が実行されています。

AWSの状態を確認してみましょう。

aws002.JPG

画像の通り既存のインスタンス「i-d6ea5cd9」が削除(terminated)され
新たなインスタンス「i-cce85ec3」が作成されています。

破棄された既存インスタンスはTerraform以外から操作した情報を保持することなく破棄されます。
そして新たに作成されたインスタンスにはTerraformの設定ファイルに記載されている情報のみしか所有していない状態で立ち上がります。
DBや動的コンテンツ等を提供するインスタンスに対してTerraformから変更を加える時には注意が必要です。

クラウドサービスの仕様や制約に影響を受けるため書き方に注意が必要なTerraformですが機能改善や機能追加が今後も行われる予定なので引き続きTerraformの動向を追って皆様に情報を展開していきます。

次回は「TerraformからHerokuサービスを操作する」をお伝えします。

エンジニア採用中!私たちと一緒に働いてみませんか?