Terraformのインストールと使い方(基礎編)

  • このエントリーをはてなブックマークに追加
  • Pocket
  • LINEで送る

この記事では、インフラストラクチャ構成管理ツールであるTerraformのインストール方法と、基本となる使い方をAWSのネットワーク構築を例に紹介します。会社で書いた記事をベースに改めてリライトしてました。

■ Terraformとは

  • コードからインフラリソースを作成する・コードでインフラを管理するためのツール
  • AWS, GCP, Azure, DigitalOcean といったクラウドプロバイダや DNSimple, Mailgun, Rundeckを含む多くのSaaSに幅広く対応

■ Infrastructure as Codeの実践によるメリットとは

ここで、近年のインフラ管理手法として常識となりつつあるInfrastructure as Codeという言葉について考えてみます。文字通りインフラレイヤのコンポーネントをアプリケーションと同じようにコード化、管理する手法を指す言葉です。では具体的になにが嬉しいのでしょうか。
Infrastructure as Codeを実践する中で筆者が感じるメリットは以下の3点です。

  • 1 : セキュリティリスクの軽減
  • 2 : サーバーコスト削減
  • 3 : Githubフロー導入による非属人的なワークフローの確立

セキュリティリスクの軽減

security_1

セキュリティといっても様々なレイヤがありますが、今回は主にインターネット経由で接続されるアプリケーションのネットワークレイヤについての話をします。AWSはGUIベースで様々な変更を加えられる分、なぜこの修正が入ったのか正しく履歴を記録する術がないと、あっという間に構成が汚れていきます。例えば、以下のような状況が発生しかねません。

  • 謎のIPホワイトリストが定義されてるSecurity Group
  • 謎のポートがグローバルに解放されてるNetworkACL
  • VPC Peeringの接続先が、存在しないVPCを指したまま放置されてる

ネットワーク構成をコード化=現在発生中のセキュリティリクスが即解決、というわけではありません。ですが、インフラレイヤの構成がコード管理されていれば、pull-requestをたどって変更履歴と背景も分かるので安心感がありますし、以後の管理/変更のコストは激減します。

サーバコスト削減

cost_1

AWSはサーバ等のリソース起動がカンタンな分、リソース肥大化に伴い、例えば突発的なスパイク等の対応の名残でスケールアウトして急場をしのいだ後ストップされて放置されたサーバー。または、キャパシティプランニングを真面目に行われないまま検証用途で作成、実際には使わず稼働し続けてるリソース(主にEC2、EBS)といった不要なリソースが散在しがちです。例をあげると、以下のような類のものです。

  • 使われてる形跡は無いが3ヶ月以上前から稼働してるEC2
  • 500GBのEBSがマウントされたままStop状態のEC2
  • 理由なく高Provisioned IOPSが付与されたままの検証用RDS

AWSのクラウドリソースは基本的に時間課金のため、対応放置 = コストの垂れ流しです。またコンポーネントによっては、Stop状態 ≠ お金がかからない、ので要注意です。これらの課題に対し、リソースのコード化を進めることで、稼働中のサーバを正確に把握することができます。また、新規リソース作成時も、後述するような第三者によるキャパシティプランニング妥当性をチェックする機会が設けられるので、結果不要なコストを削ることができます。

Githubフロー導入による非属人的なワークフローの確立

アプリケーションコードと同じように、インフラレイヤの変更作業をコードベースによる修正とGithub-Flowによるレビュー、本番反映という流れが行なえます。これにより、以下のようなメリットが得られます。

  • 1:リソース操作の属人化解消
  • 2:キャパシティプランニングの徹底

1に関しては、例えば会社のチームメンバと開発してる場合、チーム内でのナレッジの属人化を防ぐというメリットの他にも、非インフラ担当のエンジニアでもコードの修正のみでリソースの作成/変更が可能になることを意味します。

2に関しては

  • なぜこの修正を行うのか
  • スペックは妥当か

上記観点について第三者の目を通すことで、サーバーコストの高騰化やヒューマンエラーを防ぎつつ、スピード感をもって本番への変更適用が可能になります。

■ Terraformの利点

TerraformはInfrastructure as Codeを実践可能にするツールです。これまで使ってきて筆者が感じる利点は以下3つです。

  • binaryファイルを実行パスに設置すればよいので、インストールが超カンタン。
  • 開発が活発。AWSの場合、新サービス出ても大抵すぐにキャッチアップしてくれる。
  • dry runが可能

では、実際にTerraformのインストールと簡単な使い方を説明します。

■ インストール

  • 公式サイトからダウンロード & 解凍して実行パスに設置すれば即利用可能です。

なお、Terraformは開発が盛んな為、頻繁にアップデートする機会があります。以下のようなインストールスクリプトを作成しておくと
便利です。

■ 使い方

  • AWSでVPC + subnetを作成する以下のようなレシピを試してみます

ProviderブロックでIaaS(例:AWS, GCP, Microsoft Azure, OpenStack), PaaS (例:Heroku)、SaaS services (例:Atlas, DNSimple, CloudFlare)を指定します。今回はAWSを指定します。AWSのリソースを生成する場合、他にaccess_key/secret_key情報を渡す必要があります。これは以下のように環境変数にセットしてやることで、レシピ上での記述を省略
する事が可能です

resourceブロックには1:リソースタイプ、2:リソース名の2つの文字列を指定します。また、resourceブロックのカッコ内にはリソースプロバイダそれぞれの定義を記述します。このresourceブロックの2つの文字列を用いる事で、各resourceブロックで作成されたコンポーネントの作成結果(identifier等)を参照することが可能になります。例えば"${aws_vpc.test-vpc}は、リソースタイプ:aws_vpc / リソース名:test-vpcで定義されたresouceブロックで作成されたVPCの作成結果が参照できます。この例ではVPC作成後にサブネットを作成していますが、サブネット作成時は紐づくVPCを指定してやる必要があるので、VPCを一意に表すid(arn)を生成結果から取得し渡しています。

dry-run実行

terraform planでdry-runを実行します。

このレシピを実行する事で生成されるであろうリソース情報が表示されます。

リソース作成

次に、terraform applyコマンドでリソースの作成を行ってみます。

作成後、terraform showと打つと、以下のような生成結果を確認する事ができます。

terraform showは、apply完了後に作成されているterraform.tfstateという状態ファイルの中身を示すものです。
この中身を実際に見てみます。

terraform.tfstateはterraform経由で作成されたリソースの情報が格納されたファイルなので、今回作成したvpc及びサブネットの情報がjson形式で格納されます。

リソースの削除

次に、リソースの削除を行います。やり方は簡単で、レシピ(vpc.tf)から該当箇所を削除して再度applyするだけです

この状態でdry-runを実行してみます。リソース(VPC + サブネット)が削除対象である事が分かります。

この状態でterraform applyを実施します

terraform showでリソースの状態を見てみます。削除されている事がわかります。

■ 終わりに

今回はTerraformのインストール方法と簡単な使い方を紹介しました。次回はより実践的な使い方を紹介していきます。

■ 参考

  • このエントリーをはてなブックマークに追加
  • Pocket
  • LINEで送る

SNSでもご購読できます。

コメントを残す

*