スキップしてメイン コンテンツに移動

Terraformのど基本 - その４

 はじめに

前回の「Terraformのど基本 - その３」ではTerraformでAWSのリソースを扱っていく為の準備として、TerraformのインストールとIAMそしてAWS CLIの設定までを行った。

今回はいよいよになるが、Terraformを使って実際にAWSのリソースを操作する簡単なデモを行ってTerraformのど基本シリーズを締め括りたいと思う。

本来であればEC2やVPCやS3と言ったリソースやAWSといったサービス毎にファイルを分割して管理・構築する方が実践ではオススメではあるがここでは内容理解に重点を置きたいのでmain.tfという一つのファイルにまとめて進めていく。

今回構築する内容としては非常にシンプルなものではあるが、AWS Profileの情報を利用してEC2インスタンスを立ち上げるというのを行っていきたいと思う。

前準備

まずは再度の確認にはなるが前回行ったIAMユーザアクセス権があることを確認したい。

aws sts get-caller-identityのレスポンスが返却されればOKだが、もしここでレスポンスが返却されていない様であれば、前回の「Terraformのど基本 - その３」のAWS CLIの設定の項目で復習して欲しい。

名前は何でも良いのだが、任意のディレクトリを作成しその中にここではmain.tfという名前のファイル名を作成しておこう。

例: test/main.tf

main.tf

では早速main.tfを記述していく。細かい箇所に関しては後ほど解説する予定なので一先ず下記の通り記述をお願いしたい。

それではブロック毎に内容の記述内容の解説を行っていく。

variable

ここで理解して頂きたいことはdefaultとtypeである。これはその名の通り変数のデフォルト値であったり型宣言の部分となる。

variable内の様々な記法に関してはこちらのドキュメントを参照

terraform

次に来るブロックがterraformと書かれたブロックである。ここには必要とするモジュール名であったりバージョン情報などを記述する。

terraform内の様々な記法に関してはこちらのドキュメントを参照

provider

そして次に来るブロックがproviderのブロックとなる。ここでは構築するリソースのプロバイダー情報を記述する。ここではAWSのリソースを作成していくのでawsとし、リージョン情報とプロファイルを指定している。

provider内の様々な記法に関してはこちらのドキュメントを参照

resource

そして最後がresourceのブロックとなる。ここではリソースの種類、リソース名とリソースの設定値を記述してあげる必要がある。ここではAMIの情報とインスタンスタイプの情報を記述している。

resource内の様々な記法に関してはこちらのドキュメントを参照

変数（variable）の参照の仕方

terraformの変数の定義方法は上記で記載した通りとなるが、定義した変数を参照したい場合はvar.変数名で参照が可能。

例えばサンプルで使用されているaws_regionという変数を使用したければ、var.aws_regionの様にすることでデフォルト値のap-northeast-1を取得することが出来る。

mapの参照の仕方

mapの参照の仕方はlookup関数を使用して、引数にkey・valueを渡すことで値が取得出来る様になっている。

例えばサンプルで使用されているlookup(var.amis, var.aws_region)という記述を見てみよう。

まずは引数を確認する。var.amisつまり変数amisを参照するということである。同様にvar.aws_regionは先程確認した内容になるが、変数aws_regionを参照することを意味する。

そしてlookup関数はlookup(map, key)の様に用いられ、引数にmapとkeyを渡してあげることで該当の値を参照出来る様になっている。

つまりサンプルにあるlookup(var.amis, var.aws_region)と記述することで、var.aws_region（ap-northeast-1）のkeyを用いてvar.amis（ap-northeast-1 = "ami-034968955444c1fd9"）のmapより値を取得することを意味する。

結果としてここではami-034968955444c1fd9の値が取得出来る。

terraformによるAWSリソースの作成

それでは準備が整ったので、先程のサンプルを用いて簡単なAWSリソースを作成していく。基本的にな流れはTerraformのど基本 - その２を参照頂ければと思う。

既に任意のディレクトリ内にmain.tfというサンプルファイルを準備頂いていると思うが、下記の手順でリソースを作成していく。

terraform fmt

以前はterraform initから処理を始めたが、今回はインデントなどのフォーマットを整えるterraform fmtから実行したいと思う。

terraform init

現在のディレクトリ内のTerraform関連ファイル(main.tf)を元に必要なモジュールのダウンロードを行い.terraformというディレクトリ内に保存を行う。

成功すると下記の様に初期化される。

terraform plan

実際にterraformにて設定を適用した場合に（terraform applyした場合に）変更点はどこにあるのかの差分の確認を行う。

下記の通り変更差分が表示される。

terraform apply

最後にterraform applyを行い、実際に適用してAWSのリソースを作成していく。途中で実際に変更を適用するかのプロンプトが表示されるが、問題なければyesと入力し処理を進めていく。

AWSコンソールを確認すると下記の通りEC2インスタンスが作成されていることが確認出来る。

terraform destroy

それでは後片付けをして、先程作成したリソースを削除していきたいと思う。ここでもplanやapply時と同様に変更差分が表示されるので問題なければyesと入力して処理を進めていく。

まとめ

以上となる。terraformの基本的な流れと使い方について少しでも理解して頂けただろうか。この記事で少しでもterraformの最初の入りがスムーズに進むと嬉しい限りです。
ラベル:

コメント

コメントを投稿

このブログの人気の投稿

書評 -「UNIXという考え方」について - その３

    前回に引き続きMike Gancarz著の「UNIXという考え方」について、書評を書いていければと思う。 ４章 ソフトウェアが短命で終わるか否かは移植性を重視して作れるかどうかにかかっている ４章では効率より移植性が重要であり、例え効率を求めたとしてもそれは間もなく新しく来るスペックのものが来た時に残念ながらその努力はあまり意味を成さないものとなってしまうことがAtariの例も挙げられながら書かれている。 これはデータでも同様のことが言える。 取り巻く環境が変化することを前提にソフトウェアを書いていくこと。 その為繰り返し呼ばれている様な箇所以外で最適化にリソースを割き過ぎると環境が変化した時に対応することが困難になる。 その為にもまずは移植性を重視する必要がある。 環境が変化して、新しいハードウェアが登場しそこに移植さえ上手く出来れば前の世代のハードウェアで懸命に最適化して得られた効果よりももっと大きな効果を得られる。 昨今、もはやデファクトになり移植性の為にも無くてはならない存在になっているDocker。 従来以上に開発からサービスのリリースまでのスピーディーさが求められてる世の中になっている様にも感じるし、その為の環境もかつてよりかなり整備されてきている。 こういった環境の中で、効率性を上げるというよりかは、移植性を上げる方が将来的な環境の変化のことを考えると喫緊の課題と言える。 そもそも効率化や最適化を余りにも重視したところで、環境が変わって動かなくなれば元も子もないのだから。 「UNIXという考え方」の書籍の購入は こちら からどうぞ。 以上、５章へつづく。
2 件のコメント
続きを読む

書評 -「UNIXという考え方」について - その５

       前回に引き続きMike Gancarz著の「UNIXという考え方」について、書評を書いていければと思う。 ６章 過度の対話的インタフェースを避ける ６章では主に拘束的なインターフェース、プログラム、コマンドパーサーを避けなければならない理由について書かれている。 ソフトウェア設計者にとってのジレンマ 小さなプログラムやモジュールを数多く持つことで環境への適応能力は最大となるが、取り扱いも煩雑になる。 UNIXはユーザとモジュール間に広がる溝を少しずつ小さな塊または層にして減らしていこうとすることで解決を図る。 拘束的ユーザーインターフェース このアプローチの欠点は多くのアプリケーションが稼働するシステムだったり、あるコマンドを実行していてもそれを終わらせるまでは他のことが出来ない。 何故、避ける必要があるの？ UNIXユーザーにとってコマンド同士を対話させる必要がある。UNIX環境ではどのコマンドも単独では存在できない。様々な時点でコマンド同士が対話する前提だから。 拘束的プログラム ユーザーを人間と想定している為、人間の限界によって動作を制限されるようなシステムは、潜在能力をフルに発揮できない。 何故、避ける必要があるの？ 複雑になった拘束的プログラムは多機能主義と相まってますます大量のシステムリソースを必要とする。 ユーザーが人間であることを想定している為、他のプログラムとのインターフェースは苦手。 拘束的コマンドパーサー あらゆる可能性に対処しようとしてコマンドパーサーが肥大化し複雑になる。UNIXプログラマはユーザーインターフェースへの対処を避けて通る。典型的なUNIXアプリケーションにはコマンドパーサーがない。 その代わり、コマンド起動時にユーザがコマンドラインに動作パラメータも入力することが前提になっている。 何故、避ける必要があるの？ ソフトウェアのテコの効果を利用出来ず、他のプログラムとの対話を妨げるので、その効果をコンピュータ世界に広めることが出来ない。その為やがて取り残されて魅力を失っていく。 すべてのプログラムをフィルタにする 世界は、人間が作り出したデータで溢れている。コンピュータが発明されていなくても、データは存在している。 コンピュータは、データの収集とフィルタリングを効率よく行えるよう...
コメントを投稿
続きを読む

書評 -「UNIXという考え方」について - その４

      前回に引き続きMike Gancarz著の「UNIXという考え方」について、書評を書いていければと思う。 ５章 ソフトウェアのテコを有効に活用する 5章では主にソフトウェアのテコとシェルスクリプトのメリットについて書かれている。 よいプログラマはよいコードを書く。偉大なプログラマはよいコードを借りてくる 自分の仕事に他人の成果を取り込むことで、先人の努力を活かし、コードの有用性を一段と高めることができる。 独自技術症候群を避ける 既存のアプリケーションをゼロから設計し直すことは模倣であっても創造とは言わない。最も成功する会社は、他からソフトウェアを「借用」し、独自拡張を行う会社である。 コードを他社がテコとして使うのを認める ソフトウェアの寿命をコントロールしようとしても、プログラム開発への投資を一時的に保護することができるだけで、ソフトウェアそのものを保護することはできない。 すべてを自動化する コンピュータにできることを人間が手作業で行うのは時間の無駄。 シェルスクリプトのメリット テコの効果と移植性を高めるシェルスクリプトには何十ページ、数百コマンドラインに渡り、そこから呼ばれる各コマンドの背後にあるC言語のコードはものすごい量となる。これこそがテコの効果である。 時間が節約になる コンパイル段階を省略できるので、開発作業に集中できる。 Cより移植性が高い あるUNIXシステムで動作するスクリプトはほとんど修正なしで動作する。コンパイルはもちろん、どのような実行のための変換も不要。 C言語で書き直すという誘惑に負けない シェルスクリプトを次の年のマシンで使えば、もっと速く実行できるようになる。非常に移植性が高いのが普通だから、次の年のマシンに移植するのに特別な作業はほとんど何もない。 「UNIXという考え方」の書籍の購入は こちら からどうぞ。 以上、６章へつづく。
コメントを投稿
続きを読む