TerraformでAWSのVPC環境の構築自動化

 


 

Terraformとは

Terraformは、HashiCorp社によって提供され、環境構築の一連の手順をスクリプトで記述できる

所謂Infrastructure as codeを実現するためのツール群である。

 
TerraformはAWSに特化したツールというわけではなく、

Azure、Google Cloud、OpenStackやVMware vSphereの環境構築にも活用できる。

 
最初、AWSの環境構築自動化をCloudFormationで実現すべくJSONをしこしこ書いていたわけだが、

クライアントの気まぐれにより、Terraformで書き換えることになった。

まあ、これも1つの勉強か。

 

Terraformのインストール

 
インストールというか、ダウンロードして解凍してパス上に配置するだけである。

1、Amazon Linuxを起動してログイン

2、terraformをダウンロードして解凍


$mkdir terraform
$cd terraform
$wget https://releases.hashicorp.com/terraform/0.6.15/terraform_0.6.15_linux_amd64.zip
$unzip terraform_0.6.15_linux_amd64.zip

3、/usr/binの下に配置


$cd ..
$cp terraform /usr/bin/

4、環境変数の設定。PATHと、AWSのアクセスキー、シークレットキー、デフォルトリージョンを設定


$cd
$vim .bash_profile

.bash_profileの内容

# .bash_profile

# Get the aliases and functions
if [ -f ~/.bashrc ]; then
        . ~/.bashrc
fi

# User specific environment and startup programs

PATH=$PATH:$HOME/.local/bin:$HOME/bin:/usr/bin/terraform

export PATH

export AWS_ACCESS_KEY_ID="AKXXXXXXXXXXXXXXXX"
export AWS_SECRET_ACCESS_KEY="XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
export AWS_DEFAULT_REGION="ap-northeast-1"

5、ホームディレクトリに、Terraformのスクリプトを配置するディレクトリを作成する


$mkdir tf
$cd tf

6、Terraformのスクリプトを作成する(変数編)

Terraformのスクリプト処理で共通的に利用する変数は、

variables.tfファイルに記述する。

#
# Require User input
variable "aws_key_name" {}
variable "aws_region" {}
variable "aws_vpc_cidr" {}
variable "subnet_dmz1_cidr" {}
variable "subnet_dmz2_cidr" {}
variable "subnet_app1_cidr" {}
variable "subnet_app2_cidr" {}

#
# Change values for your AWS environment
variable "azs" {
	default {
		"0" = "ap-northeast-1a"
		"1" = "ap-northeast-1c"
	}
}

variable変数で値を定義しない({})場合、

terraform実行時にユーザー入力を求められるプロンプトが表示される。

Availability Zone(azs)は、自身のAWSアカウントに割り当てられた

AZに応じ、配列として定義すること。

 
7、Terraformのスクリプトを作成する(VPC編)

GitHubに上がっているTerraformのサンプルスクリプト(.tf)ファイルは

main.tfに主な処理を書くようにしているが、

作成するオブジェクト(EC2だったり、VPC定義だったり)によってファイルを

分割して配置してもよい。

 
今回はVPCを作成するので、vpc.tfに処理を記述する。

 
vpc.tfの内容。先ずはVPC本体から。

# VPC
resource "aws_vpc" "main" {
	cidr_block = "${var.aws_vpc_cidr}"
	tags {
		Name = "Sample VPC"
	}
}

Subnetを定義。variables.tfで定義した変数は、

var.subnet_dmz1_cidrのような形で参照することができる。

# Subnets
resource "aws_subnet" "dmz1" {
  vpc_id = "${aws_vpc.main.id}"
  cidr_block = "${var.subnet_dmz1_cidr}"
  availability_zone = "${lookup(var.azs, 0)}"

  tags {
    Name = "DMZ"
  }
}

resource "aws_subnet" "dmz2" {
  vpc_id = "${aws_vpc.main.id}"
  cidr_block = "${var.subnet_dmz2_cidr}"
	availability_zone = "${lookup(var.azs, 1)}"

  tags {
    Name = "DMZ"
  }
}

resource "aws_subnet" "app1" {
  vpc_id = "${aws_vpc.main.id}"
  cidr_block = "${var.subnet_app1_cidr}"
  availability_zone = "${lookup(var.azs, 0)}"

  tags {
    Name = "APP"
  }
}

resource "aws_subnet" "app2" {
  vpc_id = "${aws_vpc.main.id}"
  cidr_block = "${var.subnet_app2_cidr}"
  availability_zone = "${lookup(var.azs, 1)}"

  tags {
    Name = "APP"
  }
}

 
Internet Gatewayと、S3 Endpointを定義。

# Internet Gateway
resource "aws_internet_gateway" "igw" {
	vpc_id = "${aws_vpc.main.id}"
	tags {
		Name = "IGW"
	}
}

# S3 Endpoint
resource "aws_vpc_endpoint" "s3endpoint" {
	vpc_id = "${aws_vpc.main.id}"
	service_name = "com.amazonaws.ap-northeast-1.s3"
	route_table_ids = [
		"${aws_route_table.route_dmz.id}",
                "${aws_route_table.route_app.id}"
	]
	policy = <<POLICY
{
	"Statement": [
		{
			"Action": "*",
			"Effect": "Allow",
			"Resource": "*",
			"Principal": "*"
		}
	]
}
POLICY
}

 
Route Tablesの定義とサブネットとの関連付け

# Route Tables
resource "aws_route_table" "route_dmz" {
	vpc_id = "${aws_vpc.main.id}"
	route {
		cidr_block = "0.0.0.0/0"
		gateway_id = "${aws_internet_gateway.igw.id}"
	}
	tags {
		Name = "route_dmz"
	}
}

resource "aws_route_table_association" "route_dmz1_assoc" {
	subnet_id = "${aws_subnet.dmz1.id}"
	route_table_id = "${aws_route_table.route_dmz.id}"
}

resource "aws_route_table_association" "route_dmz2_assoc" {
	subnet_id = "${aws_subnet.dmz2.id}"
	route_table_id = "${aws_route_table.route_dmz.id}"
}

resource "aws_route_table" "route_app" {
	vpc_id = "${aws_vpc.main.id}"
	route {
		cidr_block = "0.0.0.0/0"
		gateway_id = "${aws_internet_gateway.igw.id}"
	}
	tags {
		Name = "route_app"
	}
}

resource "aws_route_table_association" "route_app1_assoc" {
	subnet_id = "${aws_subnet.app1.id}"
	route_table_id = "${aws_route_table.route_app.id}"
}

resource "aws_route_table_association" "route_app2_assoc" {
	subnet_id = "${aws_subnet.app2.id}"
	route_table_id = "${aws_route_table.route_app.id}"
}

 

Terraformの実行

 

先ずはplanし、エラーがないことを確認。

※いちいちプロンプトに入力するのは面倒だと思うので、

シェル化するとよいでしょう。


/usr/bin/terraform plan \
-var 'aws_key_name=hogehoge-key' \
-var 'aws_region=ap-northeast-1' \
-var 'aws_vpc_cidr=192.168.0.0/16' \
-var 'subnet_dmz1_cidr=192.168.11.0/24' \
-var 'subnet_dmz2_cidr=192.168.12.0/24' \
-var 'subnet_app1_cidr=192.168.21.0/24' \
-var 'subnet_app2_cidr=192.168.22.0/24'

planでエラーが表示されないことを確認したら、

applyしてAWS環境を自動構築しましょう。


/usr/bin/terraform apply \
-var 'aws_key_name=hogehoge-key' \
-var 'aws_region=ap-northeast-1' \
-var 'aws_vpc_cidr=192.168.0.0/16' \
-var 'subnet_dmz1_cidr=192.168.11.0/24' \
-var 'subnet_dmz2_cidr=192.168.12.0/24' \
-var 'subnet_app1_cidr=192.168.21.0/24' \
-var 'subnet_app2_cidr=192.168.22.0/24'

 
環境を削除する時はterraform destroyで。

困ったらドキュメントを読みましょう。

https://www.terraform.io/docs/index.html

 
CloudFormationと比較すると、ネット上の情報も少ない。

ググってもGitHubのコメントとかしか出ないので、

がんばってドキュメントを読むしかない感じ。

ただ、コメントがつけられるのはいいね。JSONより人間にやさしいし。

 

 

WordPressのブログタイトル(title)の一文字目が大文字になる件

 


ちょい前から気になってたんですけど、

ブラウザのタブに表示されるブログタイトルの一文字目が、

いつのまにか大文字になってたんですよ。

つまり、

昔は「cyberarchitect」だったのが、

「Cyberarchitect」になっとる、と。

 
いやまあ、英語的にはCapital letterで一文字目が大文字になるのは正しいのかもしれませんが、

わたし的には全部小文字に直したいんです!!!!!!!

 

原因はなんじゃ

 
最初はスタイルシート(CSS)だと思ったんですよね。

で、style.cssやらdefault.cssやらで

titleタグにtext-transformが設定されていると思ったら、

そんな記述は存在しない。

なぜだ・・

 

犯人は貴様だ!!!

 
で、途方に暮れながらWordPressの設定やプラグインの設定を色々確認していたところ、

みつけました。

All in One SEO Pack~

やってくれるぜ。

Title Settingsに、”Capitalize Titles:”なるチェックボックスがある。

allinoneseo_20160507

チェックボックスをオフにしたところ、

ブラウザタグのブログタイトル(つまりHTMLのtitle)が先頭含めて小文字になった!

 
これですっきりである。

プラグインを更新した際は、見た目等、リグレッション確認した方がいいな。

 

WordPress 仕事の現場でサッと使える!デザイン教科書
技術評論社 (2015-06-23)
売り上げランキング: 18,461

 

カテゴリー: WordPress | コメントは受け付けていません。

「クラウド写経」でアプリとインフラの境界を越えよう『Amazon Web Services クラウドネイティブ・アプリケーション開発技法 』

 


JR品川駅の改札を出て、港南口のマイクロソフトの方に向かうと、

駅構内の柱に広告用のディスプレイが掲げられていて、

様々な広告映像が流れているわけですよ。

ID-100340848

ある日、品川駅構内を歩いておりますと、某ハードウェアベンダの広告映像を目にしましてね、

こう言うわけです。

 
〇〇のクラウドシステムは、導入から稼働まで3時間
 

ぶっちゃけ、「遅っ!!!」って思いました。

 
3時間っていってもあれですよ、

導入しようと思うと先ず営業呼んで話を聞いて、大体の要件を伝えると

「じゃあ次は技術の者も連れてきますんで」となる気がしますね。

で、次、技術の者が来たら前回よりも突っ込んだ内容をヒアリングしてきて、

営業が「じゃあこれで一旦お見積り出しますんで」ってなる気がしますね。

ここまでで2週間ぐらいです。

そこから稟議通して発注してベンダの準備のリードタイムを確保して、

そこからやっと「3時間で稼働」、な気がするんですよ(妄想です)。

 
disりたいわけじゃないんですが(実質disってますが)、

これからのクラウドの皮を被ったベンダは大変だろうなあと思うと共に、

そこで働くインフラエンジニアの方々というのも、

職を維持できるかどうかという点で、非常に大変だろうなあと感じたわけです。

中の人でないにも関わらず、今後も「ITインフラエンジニア」の肩書だけで食っていくためには、

相当の経験と技術力がないと、正直キツいだろうなあという感覚を、

びりびりと感じてしまってちょっと身震いする気分でした。

 

Amazon Web Services クラウドネイティブ・アプリケーション開発技法

 
前著、『Amazon Web Services パターン別構築・運用ガイド』に引き続き、

待望の類書が発売されました。即買いしました。

 
今回は「アプリケーション開発技法」ということで、

アプリケーション開発者を読者層として意識した構成になっています。

紹介されているAWSのサービスとしては、

S3、API Gateway、SNS、DynamoDB、Lambda、Cognito、Machine Learning、

Kinesis、SQS、IoT、Mobile Hubと、

コードの匂いのするサービスが中心となっています。

所謂、「クラウドネイティブなアプリケーション」を開発するために

活用できる(すべき)サービス群ですね。

本書は、上記の各種AWSサービスの紹介と、これらサービスを組み合わせた

アプリの実装方法の解説が大部分を占めています。

 
正直申しますと、本書で紹介されているAWSサービスの中で、

まだ触ったこともないサービスがたくさんあります。

「ヤバイ」

と思いました。

 
AWSの荒木さんが以前、JAWSの勉強会(確かテーマは「アンチパターン」)で

全部のAWSサービスを無理やり使おうとするのはアンチパターン。
やりたいことを見極め、最適なサービスを取捨選択しましょう

的なことを仰っていました。

取捨選択・・そう、、一人で全部を使いこなす必要はない、、と思いつつ、

AWSで飯を食うものとして、このままではマズイという思いがふつふつと湧いてきます。

 
そこで、「クラウド写経」ですよ。

 

クラウド写経とは

 
ブログ記事のタイトルに書いた「クラウド写経」はわたしが勝手につけたのですが、

本書はサービスの概要を解説だけで済ませるのではなく、

Java、OjbC、Swift、Node.js、PythonのコードがAWSサービスの設定方法と一緒に

ふんだんに盛り込まれています。

 
わたしは頭が良い方ではないので、実際に自分の手で動かしてみないと、

新しい技術を理解することができないのですが、

本書は、実際に手を動かして、

「どうすればクラウドネイティブなアプリケーションを開発できるのか?」

を体感することができると感じました。

写経です。

写経することで、キャッチアップを目指すのです。

 

Appendixの「クラウドとエンジニア」

 
Appendixとして、著者の方々のクラウドとエンジニアのこれからの関わり方に関する思いが綴られています。

Twitterでしたか、著者の佐々木さんが「ポエム」と自嘲されていましたが、

わたしには実現しようもないポエムなどとは、到底思えませんでした。

 
2016年現在、まだ企業のAWS導入においては、

アプリはEC2のLinuxやWindowsで、

DBはRDSでMySQLやOracleを使って、というケースが多いため、

従来のインフラエンジニアも、インフラの仕事だけで食っていける余地が残っています。

ERPパッケージのインフラとして、EC2が使われるケースも多いですしね。

 
しかし、それだけで済む時代はそう長くは続かないという危機感があります。

なぜなら、EC2やRDSは、決してコスト的に安いサービスではないからです。(便利ですが。特にRDSは)

 
API GatewayやLambdaをフル活用するアプリが一般的になってきた時、

その驚異的なコスト効率や運用の簡便さが浸透し、

最早「わたしはインフラ担当です」「わたしはアプリ担当です」という境界は、消えてなくなってしまうでしょう。

その時仕事を失わないためには、勉強を続ける必要があると思います。

楽しみながらね。

 

最後に

 
私はKindleで購入したので最初は気づきませんでしたが、

書店で本書を見たときは、鈍器感が拭えませんでした。

 
それだけ読み応えのある本ですが、ご自身の興味のあるサービスの部分に絞って読み、

「写経する」だけでも十分勉強になると思います。
 
猛スピードで変化するAWSのサービスについていくのは簡単ではありませんが、

Have funの心を持って、楽しみながら学び続けていきましょう!!!

 

Amazon Web Services クラウドネイティブ・アプリケーション開発技法 一番大切な知識と技術が身につく (Informatics&IDEA)
NRIネットコム株式会社 佐々木 拓郎 佐藤 瞬 石川 修 高柳 怜士 佐藤 雄也 岸本 勇貴
SBクリエイティブ
売り上げランキング: 698