Terraform: Tableau用のプロキシサーバを立てたい
やりたきこと
TableauでDBに繋ぎたいけど、DBがprivate subnetにあるからproxyサーバ経由でアクセスしたい
っていうのをTerraformで書きたい。
資源
| service | OS | subnet | note |
|---|---|---|---|
| RDS | MySQL(Auroraじゃない) | private | |
| EC2 | centos | public | 作業用サーバなのでなんでも |
やること
Terraformで
- EC2立てる(ubuntu t2.micro)
- haproxyインストールする
- 自分用設定ファイルを転送して配置する
- haproxyを再起動する
- Tableau DesktopでRDSにアクセスしてみる
スタート
$ cat main.tf
provider "aws" {
access_key = "${var.access_key}"
secret_key = "${var.secret_key}"
region = "${var.region}"
}
# SGつくるやつ
resource "aws_security_group" "util-server" {
name = "example_sg_util_server"
description = "terraform example"
vpc_id = "${data.aws_vpc.main.id}"
ingress {
from_port = 3306
to_port = 3306
protocol = "tcp"
cidr_blocks = ["許せるIP"]
}
ingress {
from_port = 22
to_port = 22
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"]
}
egress {
from_port = 0
to_port = 0
protocol = "-1"
cidr_blocks = ["0.0.0.0/0"]
}
}
#EC2つくるやつ
resource "aws_instance" "example" {
ami = "ami-07ad4b1c3af1ea214"
instance_type = "t2.micro"
key_name = "${var.key_name}"
vpc_security_group_ids = [
"${aws_security_group.util-server.id}",
]
provisioner "remote-exec" {
connection {
type = "ssh"
user = "ubuntu"
private_key = "${file("${var.key_name_full}")}"
}
inline = [
"sudo apt-get update -y && sudo apt-get upgrade -y",
"sudo apt-get install -y haproxy"
]
}
provisioner "file" {
source = "haproxy.cfg"
destination = "/etc/haproxy"
}
tags = {
Name = "${var.ec2_nametag}"
}
}
#EIPつくるやつ（PublicIPでもいいなら、別にEIPは不要かも）
resource "aws_eip" "ip" {
instance = "${aws_instance.example.id}"
}
戦った跡
EC2構築時、apt-get内のgrub更新で3択迫られてるうちにtime outする。
terraformでapt-get update -y したけど、grubの更新でバグったファミコンみたいになる
apt-get-upgrade内のgrub更新の際、対応をn択で迫られるのだけど、GUIライクなCUIで聞かれるため標準出力がひどくなる。
そして、Terraformで答えられないので、time out待ちになってしまう。（9分待ってtime outしなかったけど）
provisioner "remote-exec" {
connection {
type = "ssh"
user = "ubuntu"
private_key = "${file("${var.key_name_full}")}"
}
inline = [
★ "echo grub-pc hold | sudo dpkg --set-selections && sudo apt-get update -y && sudo apt-get upgrade -y",
"sudo apt-get install -y haproxy"
]
}
参考：Vagnrat Ubuntu16.04 apt upgrade のGRUBで更新が止まる時の対策 - Qiita
上手くいったっぽい
aws_instance.example: Still creating... (3m10s elapsed) aws_instance.example: Creation complete after 3m11s (ID: i-0ac91b7d5c7141c5d) aws_eip.ip: Creating... allocation_id: "" => "<computed>" association_id: "" => "<computed>" domain: "" => "<computed>" instance: "" => "i-0ac91b7d5c7141c5d" network_interface: "" => "<computed>" private_ip: "" => "<computed>" public_ip: "" => "<computed>" public_ipv4_pool: "" => "<computed>" vpc: "" => "<computed>"
作成したEC2にログインして確認してみる
$ systemctl list-unit-files|grep haproxy haproxy.service enabled $ ps -ef|grep haproxy root 16460 1 0 04:29 ? 00:00:00 /usr/sbin/haproxy -Ws -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid haproxy 16461 16460 0 04:29 ? 00:00:00 /usr/sbin/haproxy -Ws -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid ubuntu 16742 16685 0 04:44 pts/0 00:00:00 grep --color=auto haproxy
haproxyがインストールされてて、起動もされている。
次は自分用のhaproxy設定ファイル置きたい。
file句？とりあえず突っ込んでみる。
provisioner "file" {
source = "haproxy.cfg"
destination = "/etc/haproxy/"
}
ssh: handshake failed: ssh: unable to authenticate
Error: Error applying plan: 1 error(s) occurred: * aws_instance.example: timeout - last error: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none], no supported methods remain
haproxyのインストールは上手くいってる。
ubuntu@ip-172-31-41-172:~$ dpkg -l|grep hapro ii haproxy 1.8.8-1ubuntu0.3 amd64 fast and reliable load balancing reverse proxy ubuntu@ip-172-31-41-172:~$ ps -ef|grep hap root 1993 1 0 07:31 ? 00:00:00 /usr/sbin/haproxy -Ws -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid haproxy 1994 1993 0 07:31 ? 00:00:00 /usr/sbin/haproxy -Ws -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid ubuntu 2256 2241 0 07:40 pts/0 00:00:00 grep --color=auto hap
たぶん二つ目のprovisioner句にConnectionを指定してないからかも。
provisioner "remote-exec" {
connection {
type = "ssh"
user = "ubuntu"
private_key = "${file("${var.key_name_full}")}"
}
inline = [
"echo grub-pc hold | sudo dpkg --set-selections",
"sudo apt-get update -y && sudo apt-get upgrade -y",
"sudo apt-get install -y haproxy"
]
}
provisioner "file" {
source = "haproxy.cfg"
destination = "/etc/haproxy/"
}
とりあえず、connectionを入れてみる。
provisioner "remote-exec" {
connection {
type = "ssh"
user = "ubuntu"
private_key = "${file("${var.key_name_full}")}"
}
inline = [
"echo grub-pc hold | sudo dpkg --set-selections",
"sudo apt-get update -y && sudo apt-get upgrade -y",
"sudo apt-get install -y haproxy"
]
}
provisioner "file" {
connection {
type = "ssh"
user = "ubuntu"
private_key = "${file("${var.key_name_full}")}"
}
source = "haproxy.cfg"
destination = "/etc/haproxy/"
}
二重になってダサいけど、直った。
provisioner "file"のpermission denied
上のsshのエラーは直ったけど、今度はpermission denied。
aws_instance.example: Provisioning with 'file'... Error: Error applying plan: 1 error(s) occurred: * aws_instance.example: Upload failed: scp: /etc/haproxy/haproxy: Permission denied
ファイルは置ける場所に置いて、remote-execでsudo権限を使って置きたい場所に置きましょう、らしい。
If your SSH user doesn't have access, what we recommend is using the file provisioner to upload to a place you can, then the remote shell provisioner to
sudo(or similar) to move it.
↓のように修正
- haproxyの設定ファイルを転送しておく
- 脳死でapt-get update && upgrade
- haproxyインストール
- 転送しておいたhaproxy設定ファイルを/etc/haproxy/配下に移動
- systemctlで再起動
provisioner "file" {
connection {
type = "ssh"
user = "ubuntu"
private_key = "${file("${var.key_name_full}")}"
}
source = "haproxy.cfg"
destination = "/tmp/haproxy.cfg"
}
provisioner "remote-exec" {
connection {
type = "ssh"
user = "ubuntu"
private_key = "${file("${var.key_name_full}")}"
}
inline = [
"echo grub-pc hold | sudo dpkg --set-selections",
"sudo apt-get update -y && sudo apt-get upgrade -y",
"sudo apt-get install -y haproxy && sudo mv /tmp/haproxy.cfg /etc/haproxy/. && sudo systemctl restart haproxy.service"
]
}
再起動されてそう。
Feb 5 09:13:59 ip-172-31-47-197 systemd[1]: Stopping HAProxy Load Balancer... Feb 5 09:13:59 ip-172-31-47-197 systemd[1]: haproxy.service: Main process exited, code=exited, status=143/n/a Feb 5 09:13:59 ip-172-31-47-197 systemd[1]: haproxy.service: Failed with result 'exit-code'. Feb 5 09:13:59 ip-172-31-47-197 systemd[1]: Stopped HAProxy Load Balancer. Feb 5 09:13:59 ip-172-31-47-197 systemd[1]: Starting HAProxy Load Balancer... Feb 5 09:13:59 ip-172-31-47-197 systemd[1]: Started HAProxy Load Balancer.
RDSのSGを開ける
RDSのSGにTerraformで作ったEC2のSGを登録してあげる。
Tableauにアクセスしてみる
行けてそう。（繋ぎたい案件対応で入れただけなので使い方は分からない）
DBがWordpressなのは、RDSが別件で検証用に立てたこやつしかいなかったから。。。
出来上がったtf
$ cat main.tf
provider "aws" {
access_key = "${var.access_key}"
secret_key = "${var.secret_key}"
region = "${var.region}"
}
resource "aws_security_group" "util-server" {
name = "example_sg_util_server"
description = "terraform example"
vpc_id = "${data.aws_vpc.main.id}"
ingress {
from_port = 3306
to_port = 3306
protocol = "tcp"
cidr_blocks = ["許せるIP"]
}
ingress {
from_port = 22
to_port = 22
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"]
}
egress {
from_port = 0
to_port = 0
protocol = "-1"
cidr_blocks = ["0.0.0.0/0"]
}
}
resource "aws_instance" "example" {
ami = "ami-07ad4b1c3af1ea214"
instance_type = "t2.micro"
key_name = "${var.key_name}"
vpc_security_group_ids = [
"${aws_security_group.util-server.id}",
]
provisioner "file" {
connection {
type = "ssh"
user = "ubuntu"
private_key = "${file("${var.key_name_full}")}"
}
source = "haproxy.cfg"
destination = "/tmp/haproxy.cfg"
}
provisioner "remote-exec" {
connection {
type = "ssh"
user = "ubuntu"
private_key = "${file("${var.key_name_full}")}"
}
inline = [
"echo grub-pc hold | sudo dpkg --set-selections",
"sudo apt-get update -y && sudo apt-get upgrade -y",
"sudo apt-get install -y haproxy && sudo mv /tmp/haproxy.cfg /etc/haproxy/. && sudo systemctl restart haproxy.service"
]
}
tags = {
Name = "${var.ec2_nametag}"
}
}
resource "aws_eip" "ip" {
instance = "${aws_instance.example.id}"
}
$ cat variables.tf
variable "access_key" {
type = "string"
default = "hogehoge"
}
variable "secret_key" {
type = "string"
default = "hogehoge"
}
variable "region" {
default = "ap-northeast-1"
}
variable "key_name" {
type = "string"
default = "mng"
}
variable "key_name_full" {
type = "string"
default = "mng.pem"
}
variable "vpc_id" {
type = "string"
default = "vpc-hoge"
}
variable "ec2_nametag" {
type = "string"
default = "util-server"
}
残ってる課題
RDSに登録したSGを消さないとterraform destroyがスタックする
aws_security_group.util-server: Still destroying... (ID: sg-0deaaa83a62085e75, 7m0s elapsed) aws_security_group.util-server: Still destroying... (ID: sg-0deaaa83a62085e75, 7m10s elapsed) aws_security_group.util-server: Still destroying... (ID: sg-0deaaa83a62085e75, 7m20s elapsed) aws_security_group.util-server: Still destroying... (ID: sg-0deaaa83a62085e75, 7m30s elapsed) aws_security_group.util-server: Still destroying... (ID: sg-0deaaa83a62085e75, 7m40s elapsed) aws_security_group.util-server: Still destroying... (ID: sg-0deaaa83a62085e75, 7m50s elapsed) aws_security_group.util-server: Still destroying... (ID: sg-0deaaa83a62085e75, 8m0s elapsed) aws_security_group.util-server: Still destroying... (ID: sg-0deaaa83a62085e75, 8m10s elapsed)
terraform destroy時にEC2用に作ったSGの削除を行っているが、RDS側のSGで参照しているとEC2用が削除できない。
エラー時にcontinueするみたいな構文あった気がするけど、この場合はずっと待ちなわけで、スキップするようなやつないかな。
Terraform: サンプルが難しい〜aws_autoscaling_groupが上手くいかない話〜
Placement groups may not be used with instances of typeの話
↓のサンプルやれば、オートスケールできるようになるんじゃね、って軽いノリで検証し始めたけど、見事にはまった。
ソースは上記リンク先のページをそのまま。
* aws_autoscaling_group.bar: 1 error(s) occurred:
* aws_autoscaling_group.bar: "foobar3-terraform-test": Waiting up to 10m0s: Need at least 4 healthy instances in ASG, have 0. Most recent activity: {
ActivityId: "94f5a09e-6491-f883-31fc-9a67b6e36d34",
AutoScalingGroupName: "foobar3-terraform-test",
Cause: "At 2019-01-07T09:16:12Z an instance was started in response to a difference between desired and actual capacity, increasing the capacity from 0 to 4.",
Description: "Launching a new EC2 instance. Status Reason: Placement groups may not be used with instances of type 't2.micro'. Launching EC2 instance failed.",
Details: "{\"Subnet ID\":\"subnet-0f8f0e78e2f93e59e\",\"Availability Zone\":\"ap-northeast-1c\"}",
EndTime: 2019-01-07 09:16:14 +0000 UTC,
Progress: 100,
StartTime: 2019-01-07 09:16:14.334 +0000 UTC,
StatusCode: "Failed",
StatusMessage: "Placement groups may not be used with instances of type 't2.micro'. Launching EC2 instance failed."
}
多分、こんな感じのことを言われてる気がする。
10分待った、最低4台のインスタンスがいるはずなんだけど、1台もいないよ。 t2.microでPlacement groupsが使われてないかもよ。上がらんし
知らんし。
1台だけEC2インスタンス上がってる。
10分待ったけど、って待ちすぎ。と思って画面見てたら、↓こんなんあった。
wait_for_capacity_timeout "" =>"10m"
何も指定してないとデフォ10分になるっぽい。これはとりあえず5mに変えておこう。
あと、health_check_typeがELBになっていたけど、ELB作る設定は書いてないのでEC2に変更してみる。
変更後 wait_for_capacity_timeout = "5m" health_check_type = "EC2
再度実行
$ terraform apply
〜略〜
health_check_type: "" => "EC2"
〜略〜
wait_for_capacity_timeout: "" => "5m"
〜略〜
* aws_autoscaling_group.bar: 1 error(s) occurred:
* aws_autoscaling_group.bar: "foobar3-terraform-test": Waiting up to 5m0s: Need at least 4 healthy instances in ASG, have 0. Most recent activity: {
ActivityId: "da95a09e-e5cd-0267-43c3-ff43250264a2",
AutoScalingGroupName: "foobar3-terraform-test",
Cause: "At 2019-01-07T09:51:30Z an instance was started in response to a difference between desired and actual capacity, increasing the capacity from 0 to 4.",
Description: "Launching a new EC2 instance. Status Reason: Placement groups may not be used with instances of type 't2.micro'. Launching EC2 instance failed.",
Details: "{\"Subnet ID\":\"subnet-05082e304ca64329e\",\"Availability Zone\":\"ap-northeast-1c\"}",
EndTime: 2019-01-07 09:51:31 +0000 UTC,
Progress: 100,
StartTime: 2019-01-07 09:51:31.648 +0000 UTC,
StatusCode: "Failed",
StatusMessage: "Placement groups may not be used with instances of type 't2.micro'. Launching EC2 instance failed."
}
変更はちゃんと適用されたけど、問題はここじゃないくさい。
1台目が起動したあとのヘルスチェックかな？？？
Placement Groupに対応しているEC2インスタンスタイプの話
調べてたら、たまたま引っかかった。クラスタープレイスメントグループの制約だった。
懐を気にしてinstance_type = t2.microにしてたけど、サポートされていなかった。
そして、オレオレ和訳も間違っていた。
× t2.microでPlacement groupsが使われてないかもよ。上がらんし ○ t2.microでPlacement groupsが使われないかもよ。上がらんし
↓のようにaws_launch_configurationを修正したら無事上がった。
$ cat launch_config.tf
resource "aws_launch_configuration" "foobar" {
name = "test-launch-config"
image_id = "ami-092834f1e5079fb84"
# AWS Placement_Groupがt2とか対応してないっぽい
instance_type = "m5.large"
#instance_type = "t2.micro"
key_name = "${var.key_name}"
}
m5を4台とか要らん。。。
現状、まだヘルスチェックが上手く引っかからず、意図せずdesired_capacityまでスケールアウトしてしまう。
Error: Error applying plan:
1 error(s) occurred:
* aws_autoscaling_group.bar: 1 error(s) occurred:
* aws_autoscaling_group.bar: "foobar3-terraform-test": Waiting up to 5m0s: Need at least 1 healthy instances in ASG, have 0. Most recent activity: {
ActivityId: "ea15a0b3-2f8a-d85e-a6e4-d86b1f95e8fa",
AutoScalingGroupName: "foobar3-terraform-test",
Cause: "At 2019-01-08T09:29:43Z a user request update of AutoScalingGroup constraints to min: 0, max: 5, desired: 1 changing the desired capacity from 0 to 1. At 2019-01-08T09:29:44Z an instance was started in response to a difference between desired and actual capacity, increasing the capacity from 0 to 1.",
Description: "Launching a new EC2 instance: i-039eb1472280c5749",
Details: "{\"Subnet ID\":\"subnet-0720c7a4238f0fd26\",\"Availability Zone\":\"ap-northeast-1c\"}",
Progress: 40,
StartTime: 2019-01-08 09:29:45.911 +0000 UTC,
StatusCode: "MidLifecycleAction"
}
引き続き、検証しよう・・・。
その他：terraform destroyしたときにEBSが消えない話
消されなかったEBSが大量に残ってるんだけど・・・。
delete_on_terminationオプションだろうな、あとで入れとこう。
忘れたままにしといたら、課金が捗りそう。
terraformでaws access_key, secret_keyの指定方法
個人的備忘録。本家のドキュメントが英語なので。
IAMの指定の仕方はいくつかある
- tfファイルに直書きする
- コマンド実行時にオプションで渡す
- ファイルに書いておく
1. tfファイルに直書きする
本家のexampleに一番最初に出てくる書き方。
どやーってgithubとかに上げたら後悔するやつ。
$ cat example.tf
provider "aws" {
access_key = "hogeo"
secret_key = "hogeo_secret"
region = "ap-northeast-1"
}
2. コマンド実行時にオプションで渡す
variables.tfをつくる
$ cat variables.tf
variable "access_key" {}
variable "secret_key" {}
variable "region" {
default = "ap-northeast-1"
}
example.tfは変数に置き換える。
$ cat example.tf
provider "aws" {
access_key = "${var.access_key}"
secret_key = "${var.secret_key}"
region = "${var.region}"
}
apply実行時に-varオプションで渡す。
$ terraform apply -var 'access_key=hogeo' -var 'secret_key=hogeo_secret'
オプション忘れても、入力待ちになる
$ terraform apply var.access_key Enter a value:
3. ファイルに書いておく
variables.tf書くのと、example.tfの変数化までは一緒だけど、コマンドラインのオプションで渡すんじゃなくて、ファイルに書くパターン。
terraform.tfvarsというファイル名をカレントにおいて、中にaccess_key, secret_keyを書くことで、IAMをレシピ？に書かずに済む。
$ cat terraform.tfvars access_key = "hogeo" secret_key = "hogeo_secret"
terraform.tfvarsというファイル名じゃないと、勝手に読んでくれないので、別のファイル名にしたいときは-var-fileオプションで指定してあげる。
↓はファイル名に「_org」とかつけちゃったのｄ、-var-fileオプションで指定したとき。
$ terraform destroy -var-file="terraform.tfvars_org"
今日はここまで。全然進まない。。。
本日の一言
勉強してると、部屋の片づけ始めて、カメラのSDカードとか見つかっちゃって、いつの間にか昔の写真見返して時間が過ぎてるよね。
雑記：terraformちょっと触ってる
- EC2 FullAccessだけつけたIAMユーザつくる
- ↓本家を見ながらつくってく
- depends_onでS3出たあたりで、IAMユーザにS3 FullAccessつける
↓の途中で止まってるなう。
https://learn.hashicorp.com/terraform/getting-started/dependencies
beanstalk触ってる話
概要
さわってみた系の話
検証
.ebextensitonを使ってみる
プロジェクトのソースコードの最上位に.ebextensionsを掘れ？
掘って、ファイル置いてデプロイしたら変わるのだろうか。
healthcheckurl.configを置いてみる
hello/.ebextensions配下に上記ファイルを置いてzip化する
マネコンからアップロードして、beanstalkにデプロイさせる
エラーが出る
/healthというパスはないからね
つらい
とりあえず1台に適当な静的ファイルを置いてみる
$ sudo sh -c "echo ok >> /var/www/html/hello/public/health"
直った。（実は直ってなかった）
とにかく、この使い方でいいということが分かった。
2台目にも手動でhealthファイルを配置した、がエラーが解けない。
アプリケーションのバージョンが合わないと。これはもしかしてデプロイ諦めた結果？
もたついてる間にローリングデプロイがAbortされたらしい。
During an aborted deployment, some instances may have deployed the new application version. To ensure all instances are running the same version, re-deploy the appropriate application version.
ちなみに、.ebextensions/healthcheckurl.configの内容も切り戻されていたので、現象としては
- .ebextensions/healthcheckurl.configに/healthがヘルスチェックパスだと指定してアプリをデプロイ
- 1台目に最新アプリをデプロイしたが、/healthのパスがなかったため、ヘルスチェックに失敗
- もたもたとhealthファイルを作ったが、操作はAbortされた →.ebextensions等の変更内容も切り戻された。(ヘルスチェックパスが/healthから/に戻っていた)
- 最新のアプリが1台目にデプロイ済みのため、その1台目の状態が「低下」になった
- 少し↑で直ったと思ったのは、デプロイをAbortされて古いままになっていた2台目の状態が「Ok」になっているだけだった
healthの静的ファイルもアプリ内に配置して、再デプロイしてみる。
バージョン情報が分かりにくかったので文字列にしてみる。
なんとかなった。実行バージョンも更新された。
td-agentを入れてみる
インストール
$ cat hello/.ebextensions/requirement.config
commands:
command block:
command: |
curl -L "https://toolbelt.treasuredata.com/sh/install-amazon1-td-agent3.sh" > td-agent_install.sh
sh td-agent_install.sh
td-agent-gem install fluent-plugin-forest
デプロイされたEC2で確認
$ rpm -qa|grep td-a td-agent-3.2.0-0.el2018.x86_64 $ td-agent-gem list|grep forest fluent-plugin-forest (0.3.3)
td-agent.confを配布する
$ cat hello/.ebextensions/td-agent_conf.config
files:
"/etc/td-agent/td-agent.conf" :
mode: "000644"
owner: root
group: root
content: |
<source>
@type tail
format ltsv
path /var/www/html/hello/storage/logs/monolog-%Y-%m-%d
tag local.laravel.log
pos_file /var/log/td-agent/laravel.log.pos
</source>
<filter local.**>
@type record_transformer
<record>
host ${hostname}
</record>
</filter>
<match local.**>
@type forest
subtype s3
<template>
aws_key_id アイディー
aws_sec_key キー
s3_bucket at.test.bucket
s3_region ap-northeast-1
path laravel/dt=%Y-%m-%d-%H/
buffer_path /var/log/td-agent/buffer/laravel.buf
time_slice_format %Y-%m-%d
time_slice_wait 10s
flush_interval 10s
format ltsv
</template>
</match>
ebコマンドを用いたデプロイ
ざっくりイメージ
- jenkinsでビルド
- S3アップロード
- ebコマンドでローリングデプロイ
ebコマンド使ってみる
ebコマンドインストール
本家にあるので省略
使ってみる
eb init
[centos@ip-172-31-10-238 ~]$ eb init Select a default region 1) us-east-1 : US East (N. Virginia) 2) us-west-1 : US West (N. California) 3) us-west-2 : US West (Oregon) 4) eu-west-1 : EU (Ireland) 5) eu-central-1 : EU (Frankfurt) 6) ap-south-1 : Asia Pacific (Mumbai) 7) ap-southeast-1 : Asia Pacific (Singapore) 8) ap-southeast-2 : Asia Pacific (Sydney) 9) ap-northeast-1 : Asia Pacific (Tokyo) 10) ap-northeast-2 : Asia Pacific (Seoul) 11) sa-east-1 : South America (Sao Paulo) 12) cn-north-1 : China (Beijing) 13) cn-northwest-1 : China (Ningxia) 14) us-east-2 : US East (Ohio) 15) ca-central-1 : Canada (Central) 16) eu-west-2 : EU (London) 17) eu-west-3 : EU (Paris) (default is 3): 9 Select an application to use 1) BGDeploy 2) sample-laravel 3) [ Create new Application ] (default is 3): 2 Select a platform. 1) Node.js 2) PHP 3) Python 4) Ruby 5) Tomcat 6) IIS 7) Docker 8) Multi-container Docker 9) GlassFish 10) Go 11) Java 12) Packer (default is 1): 2 Select a platform version. 1) PHP 7.1 2) PHP 7.0 3) PHP 5.6 4) PHP 5.5 5) PHP 5.4 6) PHP 5.3 (default is 1): 1 Cannot setup CodeCommit because there is no Source Control setup, continuing wit h initialization Do you want to set up SSH for your instances? (Y/n): Y Select a keypair. 1) hoge-hogeo 2) [ Create new KeyPair ] (default is 1): 1
eb health
→マネコンでみているようなリストが出力された
memo
aws elasticbeanstalk describe-application-versions
マネコンの「アプリケーションバージョン」で見れるやつ
$ aws --profile eb-cli --region ap-northeast-1 elasticbeanstalk describe-application-versions
{
"ApplicationVersions": [
{
"ApplicationName": "sample-laravel",
"Status": "UNPROCESSED",
"VersionLabel": "modify_healthcheck_path",
"Description": "",
"ApplicationVersionArn": "arn:aws:elasticbeanstalk:ap-northeast-1:57142996XXXX:applicationversion/sample-laravel/modify_healthcheck_path",
"DateCreated": "2018-07-19T03:16:14.455Z",
"DateUpdated": "2018-07-19T03:16:14.455Z",
"SourceBundle": {
"S3Bucket": "elasticbeanstalk-ap-northeast-1-57142996XXXX",
"S3Key": "2018200EjT-hello.zip"
}
},
コマンドラインでデプロイしたい
アプリケーションのバージョンを作成
$ aws --profile eb-cli --region ap-northeast-1 elasticbeanstalk create-application-version \
--application-name sample-laravel --version-label 201807201700 \
--source-bundle S3Bucket="__bucket_name__",S3Key="hello.zip" --auto-create-application
{
"ApplicationVersion": {
"ApplicationName": "sample-laravel",
"Status": "UNPROCESSED",
"VersionLabel": "201807201700",
"ApplicationVersionArn": "arn:aws:elasticbeanstalk:ap-northeast-1:571429965935:applicationversion/sample-laravel/201807201700",
"DateCreated": "2018-07-20T08:19:43.496Z",
"DateUpdated": "2018-07-20T08:19:43.496Z",
"SourceBundle": {
"S3Bucket": "__bucket_name__",
"S3Key": "hello.zip"
}
}
}
無事登録された。
環境へのデプロイ
201807251600をデプロイする
$ aws --profile eb-cli --region ap-northeast-1 elasticbeanstalk update-environment --environment-name Laravel-env --version-label 201807251600
{
"ApplicationName": "laravel",
"EnvironmentName": "Laravel-env",
"VersionLabel": "201807251600",
"Status": "Updating",
"EnvironmentArn": "arn:aws:elasticbeanstalk:ap-northeast-1:571429965935:environment/laravel/Laravel-env",
"PlatformArn": "arn:aws:elasticbeanstalk:ap-northeast-1::platform/PHP 7.1 running on 64bit Amazon Linux/2.7.1",
"EndpointURL": "awseb-AWSEB-6T78TTLA31X-XXXXXXXXX.ap-northeast-1.elb.amazonaws.com",
"SolutionStackName": "64bit Amazon Linux 2018.03 v2.7.1 running PHP 7.1",
"EnvironmentId": "e-axab792pcj",
"CNAME": "Laravel-env.XXXXXXXXXX.ap-northeast-1.elasticbeanstalk.com",
"AbortableOperationInProgress": true,
"Tier": {
"Version": "1.0",
"Type": "Standard",
"Name": "WebServer"
},
"Health": "Grey",
"DateUpdated": "2018-07-25T06:53:38.215Z",
"DateCreated": "2018-07-25T02:01:56.666Z"
}
アプリケーションバージョンについて
いくらバージョンラベルを切っても、ソースの「アプリ.zip」のパスが一緒だと最新のものが参照されるらしい。（当然といえば当然か）
下記の画像だと、20180725hhmmのバージョンラベルが3つあるが、ソースのパスはS3上で同じパスなので、
最古のバージョンラベルに紐づくソースは最新のバージョンラベルのものと同じになる。
requirement.txtってどこで実行されてるの？
command:にtouch hogeとか入れてみる
$cat /var/www/html/hello/requirement.txt
commands:
command block:
command: |
touch hoge
"curl -L \"https://toolbelt.treasuredata.com/sh/install-amazon1-td-agent3.sh\" > td-agent_install.sh"
sh td-agent_install.sh
ここがrequirement.txtが読み込まれ、実行されるpwdらしい
$ sudo find / -type f -name hoge /opt/elasticbeanstalk/eb_infra/hoge
jenkins ジョブの排他実行したい話
概要
アプリケーションのデプロイに3つのジョブを使っている。
- PHPアプリをビルドする@ビルドサーバ
- ビルドしたアプリを対象サーバのDocumentRootへscpする
- 対象サーバのDocumentRootを切り替えてリリースする
資源
| 資源 | モノ | 備考 |
|---|---|---|
| EC2 | amzn2-ami-hvm-2.0.20180810-x86_64-gp2 (ami-08847abae18baa040) | |
| MW | Jenkins ver. 2.140 |
検証
ノードを1つにしてみる
とりあえず、1ジョブだけ実行させられるのか確認してみよう。
これを採用すると、常に1ジョブしか実行できないとても使いづらいjenkinsになるけど。
jenkinsの管理→ノードの管理→ノードの歯車
これを1にしてみる。
実行してみるジョブはこんな感じ
PipelineのBulk-Deploy-API-for-WhiteがJob3つを実行するだけ
| Job種 | |||
|---|---|---|---|
| Pipeline | Bulk-Deploy-API-for-White | ||
| Job | Deploy-API-for-White | ||
| Job | Release-API-to-Server-from-HUB-for-White | ||
| Job | Change_SymbolicLink_API_for_White |
待てど暮らせど始まらない、pipeline中の下流ジョブ
利用可能なエグゼキューターとは。。。
とりあえず思い当たるのは、ノード実行数を1つだけにしたやつ、戻してみる。
動いた。pipelineと下流ジョブで、それぞれエグゼキューターが必要になるらしい。
ということは、下流ジョブを複数起動したい場合は、pipline分 + 下流ジョブ並列実行分必要になるのか。。。
Pluginに頼ってみる
Jenkins上からプラグインを探してみたけどなかった、ので変わりに下記のプラグインを入れてみた。
パターンマッチで実行中のジョブがあったら、自分をブロックするようなので、雑に「.*」で試してみよう。
Bulk-Deploy-Account-for-WhiteとBulk-Deploy-API-for-Whiteを同時実行してみる。
キューに片方が入って、もう片方はビルドが実行中になった。
オンマウスで待ってるぜコメントが見れた。
詰まることなく、2つのパイプラインジョブが完了した。
一旦、これで排他的な動きは実現できた。。。
