はじめに 副業先で一からAWS環境を作成することになり、そろそろ準備を考えてたときに、ふとTerraformCloudのことを思い出しました。 https://www.hashicorp.com/products/terraform/pricing/ 最低の有料プランのチームで使う場合の違いとして権限管理が異なり、個人ユーズなら無料でも十分使えます。 また、tfstateをS3等で管理したくないのもあり、思い切ってTerraformCloudに任せてみることにしました。 ※なお、AWSアカウントがあり、Terraformに触れたことがある方だったら30分もかからずにセットアップができます。 まずはリポジトリ連携 GitHubでTerraformを管理するリポジトリを作成し、TerraformCloudでWorkspaceを作成します。 この時に、特定のディレクトリをTerraform専用ディレクトリとしている場合は、変更を検知するディレクトリを指定できます。 私の場合は、今回は同じリポジトリでインフラを全部管理する予定だったため、シンプルに「terraform」というディレクトリを作成して指定しました。 backend.tfで変数指定 backend.tfファイルを作成して、varでAWSのアクセスキーとシークレットキーを変数で指定します。 provider "aws" { access_key = var.aws_access_key secret_key = var.aws_secret_key region = "ap-northeast-1" } variables.tfで下記のようにします。 variable "aws_access_key" {} variable "aws_secret_key" {} variable "aws_region" { default = "ap-northeast-1" } そして、Pushする前にTerraformCloudでAWSのアクセスキーとシークレットアクセスキーを登録します。 秘匿情報の場合はSENSITIVEを選択すると、中を確認することが出来ないように設定できます。 この辺はCircleCIなんかと使い方は似ていますね。 早速VPC用のtfを作ります。 resource "aws_vpc" "test-vpc" { cidr_block = "192.168.0.0/16" instance_tenancy = "default" enable_dns_support = true enable_dns_hostnames = true tags = { Name = "test-vpc" } } ここまで来たらテストなのでmasterへPush。

概要 夏頃、AWS FargateとEKS祭りに参加してきた。 Fargateが東京リージョンにもやってきたので、そのためだ。 会社のチーム内でもAWS Fargateの機運が高まり、頑張って検証をしたので、まずはTerraformで構築する簡単なものを記録しておく。 なお、基本的には下記Terraformのドキュメントを参考にしている。 https://www.terraform.io/docs/providers/aws/r/ecr_repository.html <a href=“https://www.terraform.io/docs/providers/aws/r/ecs_cluster.html”　rel=“noopener noreferrer” target="_blank">https://www.terraform.io/docs/providers/aws/r/ecs_cluster.html https://www.terraform.io/docs/providers/aws/r/ecs_service.html https://www.terraform.io/docs/providers/aws/r/ecs_task_definition.html 構成 PrivateサブネットにFargateを設置する。 コンテナにグローバルIPを付与することもできるが、EIPをつけずALBにぶら下げる場合はNAT Gateway経由でインターネットに接続するようなサブネット構成にすることになると思う。でないとイメージをpullできない！（ここでまずハマった） 今回はALBにぶら下げるようにする。 ALB 先にコンテナをぶら下げるALBを作成しておく。（グローバルIPを振る場合は不要） SSL証明書の設定（ACM)等は自分の環境にあわせて修正する。 下記ではACMで取得した証明書を指定して、443へリダイレクトするようにしている。 resource "aws_lb" "staging-inamuu" { name = "staging-inamuu" internal = false load_balancer_type = "application" security_groups = ["${aws_security_group.staging-inamuu-alb.id}"] subnets = ["${aws_subnet.staging-public-1a.id}"] enable_deletion_protection = true tags { Env = "staging" } } resource "aws_lb_target_group" "staging-inamuu" { name = "staging-inamuu-lb-tg" port = 80 protocol = "HTTP" vpc_id = "${aws_vpc.staging-inamuu-vpc.id}" target_type = "

概要 SPAのインフラにS3やCloudFrontを使用していると、ページを遷移したあとに、「NoSuchKey」となることがある。 S3で公開している場合、S3+CloudFrontで公開している場合で、それぞれ設定があるのでメモ。 S3の場合 S3の場合は、静的ホスティングの設定をしたら、最初に読み込むファイルとエラーファイルを指定できる。 そこで、いずれもindex.htmlにしてあげることでエラーを回避できるようになる。 下記はTerraformでの定義の仕方。 website { index_document = "index.html" error_document = "index.html" } 上記はエラーに遭遇して調べたところ、下記記事を見つけて参考にしたもの。 Single-Page Apps on AWS, Part 1: Hosting a Website on S3 S3のみの環境であれば上記S3の設定のみでOK. CloudFrontの場合 CloudFrontでもS3と同じような設定できることを最近知った。 下記はTerraformの定義だが、404でもindex.htmlを返すという設定。 custom_error_response { error_code = "404" response_code = "200" response_page_path = "/index.html" error_caching_min_ttl = "300" } 上記はS3の前段にCloudFrontをおいたら、またエラーが出るようになってしまい、調べたところ下記記事を参考に設定したもの。 SPAを S3+CloudFront で表示する方法 SPAは今までのサーバークライアント環境の知識だけだと全く成立しないことが多いので、知っておかないと中々衝撃をうけることが多いが、マネージドサービス側でそれらに対応できるようになっていたりするのでほんと便利。 Amazon Web Services 定番業務システム14パターン 設計ガイド <p style='padding: 5px;'>

概要 特定のサイトにおいて、CloudFrontを経由している際に、国内のみ接続を許可したい場合がある。 CloudFrontの場合は、Geo Restricitonsを使えばアクセス元を国内のみに制限することができる。 Terraform CloudFrontのリソースで下記を追加すればOK. restrictions { geo_restriction { restriction_type = "whitelist" locations = ["JP"] } } Webコンソール 確認 OperaのVPNを使用してアメリカ経由の接続にすると、403になることが確認できる。 Amazon Web Services 定番業務システム14パターン 設計ガイド <p style='padding: 5px;'>

AWSの静的ウェブサイトのウェブホスティングとは 静的ウェブサイトを Amazon Simple Storage Service (Amazon S3) でホスティングできます。 つまり、静的コンテンツであれば、S3に配置することでEC2などのサーバーを管理することなく、ウェブサイトが公開可能。 Amazon S3 での静的ウェブサイトのホスティング ということで、TerraformでS3のウェブホスティングを構築したのでまとめる。 TerraformでAWSにアクセスして、S3のバケットを作成したり、更新したりできる権限がある前提。 今回は外部へ公開しない前提で作る。 bucketの作成 resource "aws_s3_bucket" "website_hosting_inamuu_com" { bucket = "website-hosting.inamuu.com" acl = "public-read" policy = "${file("files/s3/policy/website_hosting_inamuu.com.json")}" website { index_document = "index.html" error_document = "error.html" } } これだけでwebホスティングとして公開するバケットを作成できる なお、ポリシーの箇所は人によってはヒアドキュメントを使って書くことも可能。※ファイルが長くなってしまうので私は今のところはポリシー用のファイルはリソースと分けるようにしている。 また、SPAとかで公開していると、別のURLになったときにindex.htmlを見に行かないので、エラーになったりする。 その場合は error_documentもindex.htmlにすることで回避できる。 ポリシーは下記の通り。 { "Version": "2012-10-17", "Statement": [ { "Sid": "AddPerm", "Effect": "Allow", "Principal": "*", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::web-hosting.inamuu.com/*", "Condition": { "IpAddress": { "aws:SourceIp": [ "

概要 Terraformを使っていてインデントがずれてしまうのを修正するのにterraform fmtというコマンドがある。 これを手元で都度やるのをよく忘れる。 忘れてそのままマージするのは宜しくないので、せめてCIでチェックできればと思い調べたところ、hashicorpの公式のterraformイメージがあった。 これを活用することで、CircleCIと連携して簡単にterraform fmtで差分が出てしまった箇所が検知できる。 version: 2 jobs: terraform: working_directory: ~/repo/terraform/ docker: - image: hashicorp/terraform:0.11.8 steps: - checkout - run: name: "terraform fmt" command: | terraform fmt -diff=true -check=true workflows: version: 2 terraform: jobs: - terraform 上記のように、terraform fmtにいくつかオプションを付けている。 -diffをtrueにすると差分が表示されるので、どこが修正されるかがわかる。 -checkをtrueにするとチェックだけを行い、差分が発生するとコマンドの返り値に3を返す。 CircleCIでコマンドの返り値が0と異なるとエラーになり、CIがこけるようになる。 ちなみに実行した際の結果はこちら。 #!/bin/sh -eo pipefail terraform fmt -diff=true -check=true diff a/terraform/variables.tf b/terraform/variables.tf --- /tmp/875634021 +++ /tmp/774976384 @@ -1,6 +1,8 @@ variable "aws_access_key" {} variable "aws_secret_key" {} + variable "

概要 仕事で複数のプロジェクトでTerraformを使うことになった。 過去、0.10.* から 0.11.* にバージョンアップした後、不具合が発生して 0.10.* にバージョンダウンしようとしたらsyntaxが変わりバージョンを下げられなくなってしまったということがあった。 そこで、Terraformのバージョンを統一的にしていくかどうかは置いたとしても、バージョンの差異による問題が発生することは今後ありえるだろうと考え、tfenvを利用してみることにした。 tfenvを使うとterraformのバージョンを簡単に切り替えられるらしい。 tfenvのインストール brew installするだけ。 $ brew install tfenv Error: Cannot install tfenv because conflicting formulae are installed. terraform: because tfenv symlinks terraform binaries Please `brew unlink terraform` before continuing. Unlinking removes a formula's symlinks from /usr/local. You can link the formula again after the install finishes. You can --force this install, but the build may fail or cause obscure side-effects in the resulting software.