2018年あけましておめでとうございます。
新年早々ひどい肩こりに悩まされていましたが、最近ようやく回復してきましたインフラの山田です。
去年の振り返り
さて、2017年の振り返りになりますが、おかげさまで昨年は99.996%のシステム稼働率を記録することが出来ました。
今年も飲食店様を支えるインフラとして、この稼働率をキープしていきます。
git push起点でインフラをつくる
トレタではInfrastructure as Codeに積極的に取り組んでいます。
全てのインフラリソースをコード化出来ているわけではありませんが、 git pushでインフラができあがる の考えのもと仕組みを作っています。
さて、今回はサーバの構築に関して紹介します。
使っているツール
以前のブログでも紹介させて頂いていますが、サーバ周りを運用を回すのには以下のツールを使っています。
これらのツールをCircle CIを起点として実行しています。
処理の流れについて順を追って書いてみます。
1. AMIをつくる。
最初にPakcerでサーバの種となるAMIを作ります。
絵の通り、git pushをして、あとは放っておけば単体テストまでが完了したAMIが自動で出来上がってきます。いわゆるゴールデンイメージです。
AMIのImage nameにはtimestampを付与しているので、「あ。MW周りの設定を3日前の状態に戻したいなー」とかあれば戻しは楽です。
当然、AMIを作るだけというのはアレなので、以下の条件を満たすAMIは、削除をする仕組みを入れています。
- 保存日数を超過している。
- 保存世代数を超えている。
さて、実際のtemplateの中身はこんな感じです。
{
"variables": {
"sample1_aws_access_key": "xxxxxxxxxxxxxxxxxxxx",
"sample1_aws_secret_key": "xxxxxxxxxxxxxxxxxxxxxxxxx",
"sample2_aws_access_key": "xxxxxxxxxxxxxxxxxxxx",
"sample2_aws_secret_key": "xxxxxxxxxxxxxxxxxxxxxxxxx"
},
"builders": [{
"name": "sample1",
"access_key": "xxxxxxxxxxxxxxxx",
"secret_key": "xxxxxxxxxxxxxxxx",
"region": "ap-northeast-1",
"source_ami": "xxxxxx",
"vpc_id": "xxxxxx",
"subnet_id": "xxxxxx",
"associate_public_ip_address": xxxxxx,
"type": "amazon-ebs",
"instance_type": "t2.medium",
"ssh_username": "ubuntu",
"ami_name": "toreta-sample1 / sample_service / {timestamp}}"
},{
"name": "sample2",
"access_key": "xxxxxxxxxxxxxxxx",
"secret_key": "xxxxxxxxxxxxxxxx",
"region": "ap-northeast-1",
"source_ami": "xxxxxx",
"vpc_id": "xxxxxx",
"subnet_id": "xxxxxx",
"associate_public_ip_address": xxxxxx,
"type": "amazon-ebs",
"instance_type": "t2.medium",
"ssh_username": "ubuntu",
"ami_name": "toreta-sample2 / sample_service / {{timestamp}}"
},
~~
~~
}],
"provisioners": [
{
"type": "shell",
"scripts": ["base_scripts/base.sh"]
},
{
"type": "ansible",
"playbook_file": "ansible/initialize.yml"
},
{
"type": "file",
"source": "serverspec",
"destination": "/tmp/serverspec"
},
{
"type": "ansible",
"playbook_file": "sample1_inventory.yml",
"extra_arguments": [ "--extra-vars", "/xxxxx/xxxxx/xxxxx/xxxxx" ],
"only": ["sample1"]
},
{
"type": "shell",
"scripts": ["scripts/sample1_spec.sh"],
"execute_command": "{{ .Vars }} sudo -E bash '{{ .Path }}'",
"only": ["sample1"]
},
~~
~~
privisionersでの処理について、全部書くと大変な量になってしまうので1role分のみ書きます。
①パッケージ周りの更新
ここでは主にpackegeのupdate／upgradeの処理を実行します。
全roleのサーバで共通して流します。
sudo sed -i".bak" -e 's/\/\/archive.ubuntu.com/\/\/ftp.jaist.ac.jp/g' /etc/apt/sources.list
sudo apt-get -y update
sudo apt-get -y upgrade
② Ansible
playbookは汎用／専用の2種類を用意しています。
まずは全サーバに同じ処理を施すための汎用playbookを実行します。
packageのインストールや、rbenv, pyenvなどのインストール、ユーザ周りの整備などの処理を行います。
尚、ここで実行する内容は、全roleで共通して流す内容であることと、管理の二重化を避けるためにansible-galaxyで共通化しています。
次にrole毎に処理内容の異なる専用playbookを流して、Ansibleの処理は完了です。
③Serverspec
仕上げに、Serverspecでテストを行います。
事前に/tmpにserverspecをまるごと送り込んであるので、該当するspecファイルをシェルスクリプト経由で実行します。
#!/bin/sh
TARGET="xxxxx"
SPEC_ENV="xxxxxxxxxx"
cd /tmp/serverspec && /usr/local/rbenv/shims/bundle install --path .bundle
cd /tmp/serverspec && export TARGET=${TARGET} && export SPEC_ENV=${SPEC_ENV} && /usr/local/rbenv/shims/bundle exec rake spec
全てのspecを通過したら、AMIが完成します。
尚、ここで出来上がったAMIにはアプリケーションコード(Rails)は含ませていません。（Packerの中に特定時点のコードを含めること事故につながるため。）
2. サーバをつくる。
次にTerraformでサーバをつくります。
絵の通り、ここもgit pushをするだけです。
CircleCI経由でTerraform applyまで完了し、サーバが出来上がります。事前にPackerの中でテストも完了しているので、即サービスインできます。
resource "aws_launch_configuration" "sample-lc-blue" {
name = "sample-lc-blue"
image_id = "${var.sample1_blue}"
instance_type = "t2.medium"
key_name = "${var.samplekey}"
security_groups = [
"${aws_vpc.xxxxxxxxxxxxx}",
"${aws_security_group.xxxxxxxxxxxxxx.id}",
~~
~~
変数周りはtfvarsファイルで別管理しています。
なので、AMI-IDをvar.sample1_blueに埋め込んで、terraform applyしてやるだけです。
(尚、トレタではAuto Scaling を使用してインスタンスを動的にスケールをさせているため、aws_launch_configurationを定義しています。)
EC2が起動してきたら、Packerの中に含むことができなかったRailsアプリケーションを流し込みます。
この流し込みには、userdataを利用しており、リポジトリをローカルにcloneし、local deployします。
deployが正常に完了したことを確認したら、Mackerelの監視が有効化されます。
Railsアプリケーションを流し込んでいない状態で監視を有効化すると、Rackサーバが未起動、workerが未起動状態など不完全な状態となるため、重大障害扱いとなってしまいます。そのためPacker buildの中では、Mackerel起動時の初期監視パラメータを on_start = "standby" としています。
サービスインが完了すると、slackに成功メッセージがpostされ、サーバ構築は完了です。
まとめ
今回はインフラのサーバの構築について紹介させて頂きました。
git pushでインフラができあがる の考えのもと仕組みを作っているので、シンプルなオペレーションができています。
また、今回は運用に関しては紹介をしていないんですが、運用についてもできるだけシンプルな運用なできるような仕組を作り心かげています。また次回ご紹介させて頂ければと思います。
それでは今年も一年、トレタの開発者ブログをよろしくお願いします。
サーバーサイドエンジニアの中村です。
