Terraformのど基本

Terraformのど基本 - その２

はじめに

前回の「Terraformのど基本 - その１」ではTerraformのど基本としてその概要に迫ってみた。Terraformあると良さそうだなぁ。というのを少しでも感じて頂ければ取り敢えずはOK。

今回は「Terraformのど基本 - その２」になるのだが、では実際にどういう流れでコーディングしていけば良いかについて、まずはその流れから見てきたいと思う。

まずは基本的な流れから

Terraformを使用していくにあたって、まずはよく使う基本のコマンドから紹介。これらのコマンドは特に重要なので使い方をここでしっかり理解しておいて欲しい。

terraform init

terraform plan

terraform apply
では早速それぞれのコマンドについて解説していく。

terraform init

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

ちなみにこちらのコマンドを誤って複数回実行しても特に問題はない。

詳しくはドキュメントのCommand: initを参照。

terraform plan

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

このコマンドをapply前に叩くことで、適用前に事前に変更差分を確認出来るので、同じ開発チーム内でも変更差分を共有できる等のメリットがある。

詳しくはドキュメントのCommand: planを参照。

terraform apply

このコマンドはもうお分かりの通りterraform planした結果を実際に反映させる。

実はこのコマンドを実際に実行させると分かるのだが、実際に実行する前にきちんと変更差分を教えてくれるようになっている。

プロンプトにより実際に適用してOKか否かでOKして初めて適用される仕様となっている。

ちなみに-auto-approveを付与することでプロンプトによる承認無く適用させることも可能だが、特段の理由が無い限りはこのオプションは付けない方が無難であろう。

詳しくはドキュメントのCommand: applyを参照。

まとめ

いかがだっただろうか？コマンドに関しては至ってシンプルであまり迷うところも特に無いハズ。

要は初期化して、ドライランして適用するというよくある一般的な流れと同等と考えてもらえれば良いかと思う。

続いてはこれらのコマンドを使って実際に簡単なサンプルを作りながら、AWSの場合を例に「EC2インスタンスを立ち上げ、そして破棄」までの一連の流れを見ていく。

P. S.

この記事に関する内容の誤りや改善提案などございましたら随時お待ちしております。

このブログの人気の投稿

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

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

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

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

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

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

1024

このブログを検索