Create Amazon AMI

by Packer

w/z Ansible provisioner

2018/09/21 @raki

Who?

Twitter: raki

SIer: 10y （そのうち６年は某データ通信）

Freelance: 14y+ （うちCA８年目）

Now: 株式会社グリフォン（うち５年目）

サイバーエージェントのゲーム系子会社の１つ

​

好きなAnsibleモジュールは File かな。一番使うので。

​

汎用機からクラサバを経てWeb系に

サーバサイドから現在はインフラ系

公共,B2B,B2C,C2Cから現在はソシャゲ

Terraform, Ansible, Packer で AWS が主戦場

ただし現職ではGCPがメイン

Contents

• Create Amazon AMI by Packer w/z Ansible
• Hierarchy of Project AMI
• CI / CD
• Pros/Cons
• Help me�

５分じゃ無理でしたｗ

なので図にしてみました

Here

launch configurations

ALL

$ packer build -var-file=vars_base.json packer.json

$ packer build -var-file=vars_jenkins.json packer.json

$ packer build -var-file=vars_php.json packer.json

• packer.json を共通にし、varファイルを切り替えて使用
• 常に最新の元AMIを使うことで全てのインスタンスを共通化
• →　jenkinsとphpはbaseで生成したAMIを使っている
• varファイル毎に Playbook 名を決めてあり、どう設定されるかを決定
• jenkinsから定期実行し、週一で洗い替え
• 作成したAMIをterraformでLC（起動設定）にして、ASG（オートスケーリンググループ）に教えて、スケジュールスケーリングで入れ替える

​

baseはAmazonLinux2

生成したAMIが次のビルドの元AMI

Create Amazon AMI by Packer w/z Ansible

• packer ansible amazon ami で検索
• 今更難しいことも目新しいこともない（汗
• docker への移行までの繋ぎに、捨てやすい環境を作っている
• というか強制的に捨てられる環境にしている
• 必要なタイプ毎にAMIを作成しておき、オートスケーリングでさくっと起動
• 夜になったらオートスケーリングでさくっと削除
• プロダクトのデプロイは AWS CodeDeploy で自動的に同期
• bastion, jenkins, api, web, etc…
• OS を全機共通にしてノウハウを一元化
• packer.jsonを共通にしてvars-fileで切り分け�

コードちら見せ（共通packer.json）

# 最新AMI取得

"builders": [� {� "source_ami_filter": {� "filters": {� "name": "{{user `filter_name`}}",� "root-device-type": "ebs",� "virtualization-type": "hvm"� },� "owners": [� "self",� "amazon"� ],� "most_recent": true� },� ],�

# Ansible 呼び出し�� "provisioners": [� {� "type": "shell",� "inline": [� "sudo yum -y update",� "sudo amazon-linux-extras install ansible2",� "ansible --version"� ]� },� {� "type": "ansible",� "playbook_file": "{{user `playbook_file`}}",� "inventory_directory": "{{user `inventory_directory`}}",� "host_alias": "{{user `host_alias`}}-{{user `aws_ami_name`}}",� "extra_arguments": [� "-l {{user `host_alias`}}-{{user `aws_ami_name`}}",� "--vault-password-file={{user `vault-password-file`}}"� ]� }� ]�

後でスライドを共有します

Hierarchy of Project AMI

• Amazon Linux 2（週一で最新取得）
• 　base （yum update, ansible, OS Tuning, DataDog Agent、その他プロジェクト共通）
• 　bastion （NWなど。ssh で nc するので）
• 　jenkins （nginx, jenkins, EFS）
• 　php （nginx, php7）
• 　api
• 　web
• 　pra （phpRedisAdmin）
• 　pma （phpMyAdmin）
• 　etc...�

それぞれ AMI 化して、

jenkins から terraform を叩いて

AutoScaling::LaunchConfiguration にして

AWS::AutoScaling::AutoScalingGroup 更新

​

コードちら見せ（terraform）

# base AMI の最新を取得��data "aws_ami" "bastion" {� most_recent = true�� owners = [� "self",� ]�� filter {� name = "name"�� values = [� "base *",� ]� }�}�

# 差し込むとこ��module "bastion_asg" {� source = "terraform-aws-modules/autoscaling/aws"�� lc_name = "bastion-lc"�� image_id = "${data.aws_ami.bastion.id}"��

CI / CD

• Ansible は問題があれば終了して通知がでるので CI には注力していない
• AMI を使用して起動されるインフラ環境そのものをチェックする
• 各サービスに接続して正しい結果を返すか（外形監視）
• 各サービスのパフォーマンスはどうか（DataDogで試行錯誤中）
• 稼働中のメトリクス（DataDogに丸投げ）
• とはいえ docker の amazonlinux:2 でシステム周り以外はテストを実施
• 最近問題が出てるのでspecを追加しようと検討中
• CD としては jenkins で定期的に作り直し、洗い替えしている
• 定期実行で毎週 packer build
• terraform apply --auto-approve
• aws cli で最新の AMI ID で（terraform範囲外のASGを）更新
• jenkins で packer も terraform もなるべく人の手が入らないように実行
• したいけどタイミングもあるので実行ボタンは人の手で

コードちら見せ（Playbook）

# base.yml��- name: build server for base(ssh) AMI� hosts: all� # connection: local� become: true� gather_facts: yes�� vars:� remove_package:� - ntp*� install_package:� - chrony� - nmap� - git�

• 各インスタンスの状態をPlaybookが知っているので、role化はしていない
• 以前はしてたけど結局時間の流れと共に修正が必要になるので、PBとインベントリだけでどう構成するかが決まるのがわかるほうが理解しやすいと判断
• ≒ role 化は（OSの違いを吸収するroleは特に）コストに見合わないと判断
• 逆に十分にこなれたgalaxyなら価値がある（かもしれない）

Pros / Cons

Pros

• 捨てる前提のインスタンスで12appに寄せる
• 常に新陳代謝。切り戻しも容易
• セキュリティリスクを減らす
• 全ダウンからでも復旧が容易
• 台数調整でコスト低
• インフラの全機能が packer+Ansible と terraform でコード化されているので引き継ぎが容易
• package.json の共通化で共通部分とそうでない部分の切り分けがわかりやすい

​

Cons

• 最新化への運用間隔は要調整
• AMI 保持コスト（誤差の範囲）
• 作成時間コスト（夜間自動実行で解消）
• システムフローの理解
• 意図しない最新版への更新で問題が出る
• Amazon Linux 2 なのに cli がエラーとか
• 正確には CloudWatch Logs のプラグインが最新化しないとか
• python と pip と パッケージのバージョンコントロールに外れると悲惨

Help me

• 東京リージョンでだけ ansible 実行中にネットワークで落ちる事象
• オハイオ、バージニア、東京リージョンでそれぞれ packer 実行している
• が、東京だけ(Ansibleの実行中に)タイムアウトで落ちることがよくある
• 手動で再実行するとうまくいく？！
• ネットワークエラーを回避するための工夫？
• S3に先に降ろしておいてそれを使う？
• パッケージは？
• 権限系課題

​

この辺りについて情報交換したいです。AnsibleってよりはAWSだけど。

提供

ご清聴ありがとうございました

不良遊戯

​

​

​

• Gree （4周年）
• dゲーム（3周年）
• Mobage（2周年）

​

　　スマホ向けソーシャルゲーム

　　ジャンルはGvG（リアルタイムギルドバトル）

　　100万ユーザを超えるヒット作

　　各プラットフォーム内でR18閲覧注意

　　（PFゾーニングなのでお察し）

​

　　GMOアプリクラウドからGCP移行済み

アイドルうぉーず

​

​

​

• DMM（3周年）

​

　　150万人突破

　　ブラウザ向けソーシャルゲーム

　　ジャンルは同じくGvG

　　ＺタイトルはDMM内R18（Fanza）閲覧注意

　　（成人向けレーティングです）

​

　　ＣＤ（１、２）LINEスタンプ、コミケ出展など

​

​

　　GMOアプリクラウドからGCP移行済み

Next Our Products

2019

COMING SOON

やっとAWSの出番！