Step by stepで学ぶTerraformによる監視付きAWS構築
Download as pptx, pdf16 likes3,608 views
コードによるインフラ構築(Infrastructure as Code)を実現するOSS Terraformのハンズオンを含むスライド資料です
![SecurityGroupを作る 58
aws_security_group リソース
https://www.terraform.io/docs/providers/aws/r/security_group.html
resource "aws_security_group" "allow_ssh_httpd" {
name = "allow_ssh_httpd"
description = "Allow ssh and HTTP inbound traffic"
vpc_id = "${aws_vpc.main.id}"
ingress {
from_port = ??????
to_port = ??????
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"]
}
ingress {
from_port = ??????
to_port = ??????
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"]
}
～次ページへ続く
?HTTP(80番)とSSH(22番)のポートを解放](https://image.slidesharecdn.com/terraform-160129162835/85/Step-by-step-Terraform-AWS-58-320.jpg)
![SecurityGroupを作る 59
aws_security_group リソース
https://www.terraform.io/docs/providers/aws/r/security_group.html
egress {
from_port = 0
to_port = 0
protocol = "-1"
cidr_blocks = ["0.0.0.0/0"]
}
}
?確認は左メニューのSecurity Groups
→ allow_ssh_httpd → Inbound rules](https://image.slidesharecdn.com/terraform-160129162835/85/Step-by-step-Terraform-AWS-59-320.jpg)
![Instance(サーバ)を作る 61
aws_instance リソース
https://www.terraform.io/docs/providers/aws/r/instance.html
resource "aws_instance" "web" {
depends_on = ["aws_internet_gateway.igw"]
ami = "ami-60b6c60a"
key_name = "techcircle12"
subnet_id = "${aws_subnet.main.id}"
vpc_security_group_ids = ["${??????}"]
instance_type = "t2.micro"
tags {
Name = "Terraform"
}
}](https://image.slidesharecdn.com/terraform-160129162835/85/Step-by-step-Terraform-AWS-61-320.jpg)
![固定IPを振る 64
aws_eip リソース
?確認は左メニューのElastic IPs
?試しにSSHでつないでみるのもアリ
https://www.terraform.io/docs/providers/aws/r/eip.html
resource "aws_eip" "web" {
depends_on = ["aws_internet_gateway.igw"]
instance = "${??????}"
vpc = true
}
# aws_eip.public_ipの確認
terraform show
# ssh接続(windowsの人はターミナルソフトをもう一つ起動するなど)
ssh –i techcircle12.pemのパス ec2-user@IPアドレス](https://image.slidesharecdn.com/terraform-160129162835/85/Step-by-step-Terraform-AWS-64-320.jpg)
![Webサーバのインストール 69
remote-exec provisioner
resource "aws_eip" "web" {
～省略～
provisioner "remote-exec" {
inline = [
"sudo yum install -y httpd",
"sudo service httpd start",
"sleep 10"
]
connection {
host = "${self.public_ip}"
user = "ec2-user"
private_key = "${var.private_key_path}"
}
}
}](https://image.slidesharecdn.com/terraform-160129162835/85/Step-by-step-Terraform-AWS-69-320.jpg)
Step by stepで学ぶTerraformによる監視付きAWS構築
- 2. 自己紹介 2 仕事関連 名前：竹澤 陽 所属：株式会社アーベルソフト 言語：Ruby, JavaScript, Go, C++, C#, 他色々 仕事：Webシステムのフロントからバックエンドまで全部 仕事以外 Twitter：@Sheile サークル：RebRank (http://www.rebrank.org)
- 3. 自己紹介 3 RefRain ～prism 尘别尘辞谤颈别蝉～
- 4. 今日の流れ 4 コードによるインフラ構築 (Infrastructure as code) Terraformとは メリットとデメリット ハンズオン 質疑応答
- 5. 今日の流れ 5 コードによるインフラ構築 (Infrastructure as code) Terraformとは メリットとデメリット ハンズオン 質疑応答
- 7. 代表的なツール 7 ネットワーク、サーバ構築 ?CloudFormation(AWS) ?OpenStack Heat(OpenStack) ?Google Deployment Manager(GCP) サーバ?ミドルウェアのセットアップ ?Puppet ?Chef ?Ansible ?Itamae ?(Docker)
- 8. 各ツールの対応範囲 8 Puppet, Chef, Ansible ネットワーク サーバ構築 ミドルウェア AWS Cloud Formation Heat Google Deployment Manager OpenStack GCP
- 9. Terraformの対応範囲 9 ネットワーク サーバ構築 ミドルウェア AWS OpenStack GCP 他サービス Terraform
- 10. 今日の流れ 10 コードによるインフラ構築 (Infrastructure as code) Terraformとは メリットとデメリット ハンズオン 質疑応答
- 15. Terraformの使用方法 15 基本的な流れ 1. Terraform configrationを記述 2. planでどんな変更が加わるか確認 3. applyで実際に構築 4. showやaws consoleで結果確認 5. Terraform configrationを修正 6. planでどんな変更が加わるか確認 7. applyで実際に構築 8. 要らなくなったらdestroy
- 16. 今日の流れ 16 コードによるインフラ構築 (Infrastructure as code) Terraformとは メリットとデメリット ハンズオン 質疑応答
- 20. メリット 20 3. SVN, Gitなどによるバージョン管理が可能 ?履歴の管理 ?変更者の確認 ?差分の確認 ?変更の取り消し アプリ開発と同様の 利点が得られる
- 21. メリット 21 4. 設計書よりも厳密な記述?チェックが可能 構築内容を記述した ファイル ツール ネットワーク構築 サーバ構築 セットアップ 設計書 作業者 ネットワーク構築 サーバ構築 セットアップ
- 23. メリット 23 6. コードとシステムの同一性が保障される 構築内容を記述した ファイル ツール ネットワーク構築 サーバ構築 セットアップ ※構築されたシステムに手動で変更を加えなければ
- 24. メリット 24 7. システム構築の自動テストができる 2. 構築 3. テスト 1. clone コード変更時や特定曜日に自動実行しますぞ
- 26. デメリット 26 構築内容を記述した ファイル 1. 初期コストが高い ツール ネットワーク構築 サーバ構築 セットアップ 構築の試行錯誤
- 27. デメリット 27 2. アドホックな修正がいれづらい 構築内容を記述した ファイル ツール ネットワーク構築 サーバ構築 セットアップ
- 29. Immutable Infrastructure 29 もしくはDisposable Infrastructure ?Amazon RDSやAuroraといった外部DB ?Fluentdを用いたログの退避
- 30. 今日の流れ 30 コードによるインフラ構築 (Infrastructure as code) Terraformとは メリットとデメリット ハンズオン 質疑応答
- 32. 宿題の確認 32 事前準備 1. Terraformのインストール 2. PATHの追加 3. AWSアカウント 4. AWS IAMユーザの作成（API Key / Secret） 5. StatusCakeユーザの作成（User / API Key） 手元に用意 1. AWS Access Key & Secret Key(credentials.csv) 2. StatusCake Username(メールアドレスは不可) 3. StatusCake API Key 4. AWSに登録した秘密鍵(techcircle12.pem)
- 33. ハンズオン 33 おさらい
- 34. Terraformの使用方法 34 基本的な流れ 1. Terraform configrationを記述 2. planでどんな変更が加わるか確認 3. applyで実際に構築 4. showやaws consoleで結果確認 5. Terraform configrationを修正 6. planでどんな変更が加わるか確認 7. applyで実際に構築 8. 要らなくなったらdestroy
- 35. ハンズオンの全体像 35 ネットワーク図 AWS VPC 10.0.0.0/16 10.0.1.0/24 Gateway 54.xxx.xxx.xx(global/固定) 10.0.1.xxx(private/自動) Destination Target 10.0.0.0/16 local 0.0.0.0/0 Internet gateway
- 36. ハンズオン 36 まずは写経
- 37. 準備 37 作業ディレクトリの作成 $ mkdir ~/terraform # お好みのディレクトリで $ cd ~/terraform Terraform configurationの作成 $ touch main.tf # 空のmain.tfを作成 ※Windowsの場合はフォルダを作成してコマンドプロンプトを起動 ?Terraformはディレクトリ内の全ての*.tfファイルを構築 ※今回はmain.tfのみを使用し、随時追記していきます
- 38. AWS provider 38 AWS Provider provider "aws" { access_key = "${var.aws_access_key}" secret_key = "${var.aws_secret_key}" region = "us-east-1" } https://www.terraform.io/docs/providers/aws/ ?providerは接続情報を記述 ?これ自体では何も作成されない ?Regionは変更可能ですが、今回はus-east-1で
- 39. variables 39 動的な値 variable "aws_access_key" {} variable "aws_secret_key" {} ?variableはplan, apply, destroy時に指定する変数 ?対話型インターフェイスで指定 ?コマンドオプション(-var) で指定 ?環境変数で指定 ?terraform.tfvarsファイルで指定 https://www.terraform.io/docs/providers/aws/
- 40. 実行してみよう 40 terraform plan $ terraform plan https://www.terraform.io/docs/commands/plan.html ?variableで定義したAWS KeyとAWS Secretを入力 ?まだ接続情報(provider)だけなので、こうなる No changes. Infrastructure is up-to-date.
- 41. terraform.tfvarsファイル 41 variableの値をファイルで指定 aws_access_key="AKIA***" aws_secret_key="***" https://www.terraform.io/docs/commands/plan.html ?variableで定義したパラメータを指定 ?terraform.tfvarsは自動的に読み込まれる ?VCSに入れる場合は.gitignore / svn:ignore推奨 $ terraform plan
- 42. 次はこれ 42 ネットワーク図 AWS VPC 10.0.0.0/16 10.0.1.0/24 Gateway 54.xxx.xxx.xx(global/固定) 10.0.1.xxx(private/自動) Destination Target 10.0.0.0/16 local 0.0.0.0/0 Internet gateway
- 43. VPCで他の人と環境を分ける 43 aws_vpc リソース resource "aws_vpc" "main" { cidr_block = "10.0.0.0/16" } ?Argument Referenceは指定可能な値 ?Attributes Referenceは取得可能な値 ?resourceは実際に作成される「何か」 ?AWS上のサーバ ?StatusCake上の監視設定 https://www.terraform.io/docs/providers/aws/r/vpc.html
- 44. 実行してみよう 44 terraform plan $ terraform plan https://www.terraform.io/docs/commands/plan.html ?variableで定義したAWS KeyとAWS Secretを入力 ?サーバ側には対応するVPCが無いのでこうなる Plan: 1 to add, 0 to change, 0 to destroy.
- 45. やりがちなポカミス 45 ダブルクォート漏れ（数字やtrue/falseは省略可能） access_key = ${var.aws_access_key} $漏れ access_key = "{var.aws_access_key}" JSONの癖でカンマを付けるとエラー provider "aws" { access_key = "${var.aws_access_key}", secret_key = "${var.aws_secret_key}" } =漏れ access_key "${var.aws_access_key}"
- 46. 実行してみよう 46 terraform apply $ terraform apply https://www.terraform.io/docs/commands/apply.html ?AWS上にVPCが作られる ?ブラウザでAWS Consoleにログインして確認 Apply complete! Resources: 1 added, 0 changed, 0 destroyed.
- 48. ハンズオン 48 それでは本番
- 49. 次はこれ 49 ネットワーク図 AWS VPC 10.0.0.0/16 10.0.1.0/24 Gateway 54.xxx.xxx.xx(global/固定) 10.0.1.xxx(private/自動) Destination Target 10.0.0.0/16 local 0.0.0.0/0 Internet gateway
- 50. Subnetを作る 50 aws_subnet リソース https://www.terraform.io/docs/providers/aws/r/subnet.html resource "aws_subnet" "main" { vpc_id = "${aws_vpc.main.id}" cidr_block = "10.0.1.0/24" } ?vpc_idは他リソースのAttributeを動的に参照 "${リソース種別.リソース名.Attribute名}" ?結果の確認は左メニューのSubnets
- 51. 次はこれ 51 ネットワーク図 AWS VPC 10.0.0.0/16 10.0.1.0/24 Gateway 54.xxx.xxx.xx(global/固定) 10.0.1.xxx(private/自動) Destination Target 10.0.0.0/16 local 0.0.0.0/0 Internet gateway
- 52. Internet gatewayを作る 52 aws_internet_gateway リソース https://www.terraform.io/docs/providers/aws/r/internet_gateway.html resource "aws_internet_gateway" "igw" { vpc_id = "${??????}" } ?vpc_idは他リソースのAttributeを動的に参照 ?結果の確認は左メニューのInternet gateways "${リソース種別.リソース名.Attribute名}"
- 53. 次はこれ 53 ネットワーク図 AWS VPC 10.0.0.0/16 10.0.1.0/24 Gateway 54.xxx.xxx.xx(global/固定) 10.0.1.xxx(private/自動) Destination Target 10.0.0.0/16 local 0.0.0.0/0 Internet gateway
- 54. GatewayへのRouteを作る 54 aws_route リソース https://www.terraform.io/docs/providers/aws/r/route.html resource "aws_route" "route_to_igw" { route_table_id = "${aws_vpc.main.main_route_table_id}" destination_cidr_block = "0.0.0.0/0" gateway_id = "${??????}" } ?gateway_idはさっき作った Internet gatewayのidを使用 ?結果の確認はRoute Tables → Routeタブ
- 55. 次はこれ 55 ネットワーク図 AWS VPC 10.0.0.0/16 10.0.1.0/24 Gateway 54.xxx.xxx.xx(global/固定) 10.0.1.xxx(private/自動) Destination Target 10.0.0.0/16 local 0.0.0.0/0 Internet gateway
- 56. RouteTableをSubnetに紐づける 56 aws_route_table_association リソース ?確認はRoute Tables → Subnet Associations https://www.terraform.io/docs/providers/aws/r/route_table_association.html resource "aws_route_table_association" "a" { subnet_id = "${??????}" route_table_id = "${aws_vpc.main.main_route_table_id}" }
- 57. 次はこれ 57 ネットワーク図 AWS VPC 10.0.0.0/16 10.0.1.0/24 Gateway 54.xxx.xxx.xx(global/固定) 10.0.1.xxx(private/自動) Destination Target 10.0.0.0/16 local 0.0.0.0/0 Internet gateway
- 58. SecurityGroupを作る 58 aws_security_group リソース https://www.terraform.io/docs/providers/aws/r/security_group.html resource "aws_security_group" "allow_ssh_httpd" { name = "allow_ssh_httpd" description = "Allow ssh and HTTP inbound traffic" vpc_id = "${aws_vpc.main.id}" ingress { from_port = ?????? to_port = ?????? protocol = "tcp" cidr_blocks = ["0.0.0.0/0"] } ingress { from_port = ?????? to_port = ?????? protocol = "tcp" cidr_blocks = ["0.0.0.0/0"] } ～次ページへ続く ?HTTP(80番)とSSH(22番)のポートを解放
- 59. SecurityGroupを作る 59 aws_security_group リソース https://www.terraform.io/docs/providers/aws/r/security_group.html egress { from_port = 0 to_port = 0 protocol = "-1" cidr_blocks = ["0.0.0.0/0"] } } ?確認は左メニューのSecurity Groups → allow_ssh_httpd → Inbound rules
- 60. 次はこれ 60 ネットワーク図 AWS VPC 10.0.0.0/16 10.0.1.0/24 Gateway 54.xxx.xxx.xx(global/固定) 10.0.1.xxx(private/自動) Destination Target 10.0.0.0/16 local 0.0.0.0/0 Internet gateway
- 61. Instance(サーバ)を作る 61 aws_instance リソース https://www.terraform.io/docs/providers/aws/r/instance.html resource "aws_instance" "web" { depends_on = ["aws_internet_gateway.igw"] ami = "ami-60b6c60a" key_name = "techcircle12" subnet_id = "${aws_subnet.main.id}" vpc_security_group_ids = ["${??????}"] instance_type = "t2.micro" tags { Name = "Terraform" } }
- 63. 次はこれ 63 ネットワーク図 AWS VPC 10.0.0.0/16 10.0.1.0/24 Gateway 54.xxx.xxx.xx(global/固定) 10.0.1.xxx(private/自動) Destination Target 10.0.0.0/16 local 0.0.0.0/0 Internet gateway
- 64. 固定IPを振る 64 aws_eip リソース ?確認は左メニューのElastic IPs ?試しにSSHでつないでみるのもアリ https://www.terraform.io/docs/providers/aws/r/eip.html resource "aws_eip" "web" { depends_on = ["aws_internet_gateway.igw"] instance = "${??????}" vpc = true } # aws_eip.public_ipの確認 terraform show # ssh接続(windowsの人はターミナルソフトをもう一つ起動するなど) ssh –i techcircle12.pemのパス ec2-user@IPアドレス
- 67. 次はこれ 67 ネットワーク図 AWS VPC 10.0.0.0/16 10.0.1.0/24 Gateway 54.xxx.xxx.xx(global/固定) 10.0.1.xxx(private/自動) Destination Target 10.0.0.0/16 local 0.0.0.0/0 Internet gateway
- 68. Webサーバのインストール 68 remote-exec provisioner ?Elastic IP(public IP)を付ける前はSSH不可 ※（今回はやらないが）subnetの設定を変えれば可能 ?実行するコマンドはyumで手軽に https://www.terraform.io/docs/provisioners/remote-exec.html https://www.terraform.io/docs/provisioners/connection.html
- 69. Webサーバのインストール 69 remote-exec provisioner resource "aws_eip" "web" { ～省略～ provisioner "remote-exec" { inline = [ "sudo yum install -y httpd", "sudo service httpd start", "sleep 10" ] connection { host = "${self.public_ip}" user = "ec2-user" private_key = "${var.private_key_path}" } } }
- 70. Webサーバのインストール 70 variableの追加 variable "private_key_path" {} ?SSHで接続するための秘密鍵として techcircle12.pemへの絶対パスを指定 ?terraform.tfvarsに追記しておくと楽
- 71. Resourceの再構築 71 再構築 $ terraform plan No changes. Infrastructure is up-to-date. $ terraform apply Apply complete! Resources: 0 added, 0 changed, 0 destroyed. $ terraform destroy --target aws_eip.web Apply complete! Resources: 0 added, 0 changed, 1 destroyed. $ terraform plan Plan: 1 to add, 0 to change, 0 to destroy. $ terraform apply Apply complete! Resources: 1 added, 0 changed, 0 destroyed. ?provisionerの追加はResourceの再構築が必要
- 72. 次はこれ 72 ネットワーク図 AWS VPC 10.0.0.0/16 10.0.1.0/24 Gateway 54.xxx.xxx.xx(global/固定) 10.0.1.xxx(private/自動) Destination Target 10.0.0.0/16 local 0.0.0.0/0 Internet gateway
- 73. 監視設定の作成 73 StatusCake provider https://www.terraform.io/docs/providers/statuscake/ variable "statuscake_user" {} variable "statuscake_apikey" {} provider "statuscake" { username = "${var.statuscake_user}" apikey = "${var.statuscake_apikey}" }
- 74. 監視設定の作成 74 statuscake_test リソース ?無料プランの場合check_rateは300秒が最低 ?確認は http://www.statuscake.com/ https://www.terraform.io/docs/providers/statuscake/r/test.html resource "statuscake_test" "web" { website_name = "terraform test" website_url = "http://${??????}/" test_type = "HTTP" check_rate = 300 }
- 77. 次はこれ 77 ネットワーク図 AWS VPC 10.0.0.0/16 10.0.1.0/24 Gateway 54.xxx.xxx.xx(global/固定) 10.0.1.xxx(private/自動) Destination Target 10.0.0.0/16 local 0.0.0.0/0 Internet gateway
- 78. 同一リソースを複数作成 78 count Attribute ?全てのResourceにcountが指定可能 ?同一のResourceが複数作成される ?Resourceの参照時は添え字を追加する ?Listで受け取ることも可能 https://www.terraform.io/docs/configuration/resources.html resource "aws_instance" "web" { count = 2 ～省略～ } aws_instance.web.1.public_ip aws_instance.web.*.public_ip
- 79. 時間が余った人用 79 remote-exec (provisioner) https://www.terraform.io/docs/provisioners/remote-exec.html output https://www.terraform.io/intro/getting-started/outputs.html 対象サーバにssh/winrmで自動ログインしてコマンドを実行 バックエンドサーバの場合、踏み台サーバ(basition_host)の設定も可能 aws_intanceの中に書くのが基本 →全instanceの構築終了後に実行したい場合などはnull_resourceの 中に書くと自分以外のサーバにssh/winrm可能 terraform outputコマンドで一覧が取得可能 必要な情報をまとめて出力したり、他アプリとの連携などに利用可能
- 80. 今日の流れ 80 コードによるインフラ構築 (Infrastructure as code) Terraformとは メリットとデメリット ハンズオン 質疑応答
Editor's Notes
- #8: 笔耻辫辫别迟の初出は2005年
- #12: *.tfファイルはTerraform configurations
- #16: 辫濒补苍の时点では既存システムに何も影响を与えないのでガシガシ実行して翱碍
- #19: ?同一構成ならいくらでも複製できる ?Stagingでは動いたのに本番環境では何故かエラーが出る、という問題を減らせる
- #20: ?既に动いている実绩のあるファイルを使用できる
- #22: ?設計書が正しくても構築時に失敗 ?手順書のレビューと比べて機械的なValidationが掛けやすくポカミスを抑制できるというのも上げられる
- #23: ブランチを切った開発が可能 Masterにある定義ファイルとDevelopにある定義ファイルは互いに影響しないので、本番に影響を与えずに動作検証ができる
- #24: ?例えば、長年使った既存システムがここにあります。 お客さんから「新サーバへの移行」を依頼された場合、 あなたの手元にある設計書は果たして現在のシステムと同一でしょうか？信用できますか？
- #25: 自動テスト自体は手作業で作ったインフラに対してもできる JenkinsなどのCIツールから叩ける レベル感も色々：chefspec, test-kitchen, serverspec
- #27: 記述方法の問題と、ファイルを作る前に実物が出来るのでは問題 JSON、YAMLといった汎用的なデータフォーマットを使っているツールもある RubyによるDSL、Terraform自身もHCLというJSONに似ているがちょっと違う
- #28: 直接手を入れるとコード＝システムの関連が崩れる 両方に入れる コードに入れてすぐ自動構築する
- #29: これはContainerでも問題になるパターン Terraformは差分を適用することで、既存のインスタンスをそのまま使える →変更の種類によっては無理。 Chefの場合は冪等性によって、既存環境を残しつつ修正を適用できるようになっていますが、変更内容によっては再構築が必要になることがあります
- #33: 辫濒补苍の时点では既存システムに何も影响を与えないのでガシガシ実行して翱碍
- #35: 辫濒补苍の时点では既存システムに何も影响を与えないのでガシガシ実行して翱碍
- #38: 迟别谤谤补蹿辞谤尘はディレクトリ単位で処理します
- #39: 痴笔颁を作る所までは写経です
- #46: 痴笔颁を作る所までは写経です
- #69: 時間が余るようならAnsibleとかremote-execとか。ChefはChef serverが必要なのでちょっとつらいか。
- #70: 時間が余るようならAnsibleとかremote-execとか。ChefはChef serverが必要なのでちょっとつらいか。
- #71: 時間が余るようならAnsibleとかremote-execとか。ChefはChef serverが必要なのでちょっとつらいか。
- #72: 時間が余るようならAnsibleとかremote-execとか。ChefはChef serverが必要なのでちょっとつらいか。