Ansible + Packer + CloudFormationでらくらく構築・運用

Developer Day

Ansible + Packer + CloudFormation でらくらく構築・運用

1

H-3

望月　政夫, AWSコンサルティング部クラスメソッド株式会社

Ⓒ Classmethod, Inc.

2015年03月29日

#cmdevioH

自己紹介• 望月政夫 • Twitter: @Canelmo • @Classmethod 2013.10～ • AWS環境構築・その他諸々担当 • DeNA Baystars 2007.04～

2Ⓒ Classmethod, Inc.

おしながき• 今日話す技術について • 利用してみた感想 • 今後の展望について


本題

4

Developer Day


5

A-1



2015年03月29日

Developer Day


6

A-1



2015年03月29日

「らくらく」とは

7

人によって観点はちがう• 構築が楽 • 自動化 • テスト • ドキュメント

• 運用が楽 • 障害対応 • 監視 • 定常作業


個人的には• 楽したいポイントがある • SSHでログインしたくない • SSH鍵管理めんどう

• 何度もManagement Consoleを開きたくない • アクセスキー管理めんどう • EC2の設定ミスした時にもう一回同じ操作をしたくない


個人的な「楽したい」を満たすための環境を作ればよい

10

個人的には• 楽したいポイントがある • SSHでログインしたくない • SSH鍵管理めんどう

• 何度もManagement Consoleを開きたくない • アクセスキー管理めんどう • EC2の設定ミスした時にもう一回同じ操作をしたくない


Ansible• 構成管理ツール • Chef, Puppetと同等 • YAMLで管理 • Dynamic Inventory機能による動的ホスト一覧生成 • AutoScaling環境に有用


動的ホスト一覧生成• インベントリファイル(ホスト一覧)不要 • タグやセキュリティグループで絞り込み可能 • 数百台単位でも利用できる • https://raw.githubusercontent.com/ansible/ansible/devel/plugins/inventory/ec2.py


https://raw.githubusercontent.com/ansible/ansible/devel/plugins/inventory/ec2.py

Packer• AMI作成補助ツール • Vagrant等のHashicorp製 • 新規にEC2を起動し、Ansibleで設定を流し込んだものをAMI化する • 常に初期状態からAMIを作ることができる


CloudFormation• AWSのサービス管理ツール • 利用するサービスをJSONで定義 • 一度書いたテンプレートファイルは再利用可能 • 他のリージョンでも動く(動くように書いていれば！) • http://dev.classmethod.jp/tag/cloudformation/

• 便利に使うためのツールもある • kumogata(https://github.com/winebarrel/kumogata)


http://dev.classmethod.jp/tag/cloudformation/

https://github.com/winebarrel/kumogata

組み合わせて使う• CloudFormationでAWSの構築 • Packer + AnsibleでAMI作成 • CloudFormationのパラメータ(AMI ID)を変更 • 変更が入ったらAnsibleを再度適用 • PackerでAMIの作成

• それぞれ違ったレイヤでの活用 • CloudFormation: AWS部分 • Ansible: AWSに依存しないOS上設定 • Packer: AWSに依存しない仮想イメージ


活用事例をいくつか

17

とあるイベントのお仕事で• EC2数百台を利用するアプリケーション基盤の構築 • マルチリージョン • アプリケーション(node.js)は数種類 • DynamoDB, SNS, S3, Route53…

• CloudFormationで一発構築・削除 • AMIのコピー(Packerの機能)


Packerの実行時間が長い• node.jsのコンパイルに時間がかかりストレス • PackerのAMI作成のプロセスを分離することにした


Amazon Linux Base AMI Golden AMI

・App配備・App設定変更

・OS基本設定・ミドルインストール






・AMI作成時間の短縮・変更箇所の局所化

AMIが複数作成されると• AMIが大量に作成されてよくわからないことに…


AMIが複数作成されると• AMIが大量に作成されてよくわからないことに… • 方針を変えた • アプリケーションごとにAMIを作成していたがそれを廃止。AMIを１種類にしてCloud DI を活用


Cloud DIパターン• CDPの一つ • EC2タグの値に応じてふるまいを変える • Environmentタグ • production • dev • staging

• Roleタグ • main • batch…


使ってみた感想• 設定が秘伝のタレ化することが少なくなった • だれでもいつでも、どの環境でも再現することができる • 簡単に手を加えることができる

• 他リージョンへのAMIコピーが容易 • Cloud DIはPackerに関わらずオススメ

• AMIの作成はそれなりに時間が掛かる • 時間がかかるプロセス(e.g. ミドルウェアのコンパイル)とアプリケーションのビルドは別段階にしたほうがよい


活用事例その2• 社内で利用するAtlassian環境のリプレース • Confluence : 情報共有(Wiki) • JIRA : チケット管理 • Stash : ソースコード共有(Git) • Crowd : ID管理

• EC2一台で稼働 • 抱えていた問題点 • EC2障害発生時の手動対応 • バージョンアップ時の対応


構成図


DNS管理

特徴• Auto Healingパターンを採用 • 起動時にData Volumeの自動マウント • Jenkinsによる簡易CI環境


Auto Healingパターン• 別名アンデッドパターン • 詳細は


Auto Healing• AutoScalingの特殊な形 • min = n • max = n • desired = n

• 障害が発生したら • 一台Stop • 新しいインスタンスが起動 • もとどおり！


障害発生時• AutoScalingで最新のAMIから起動 • 起動後にイメージの初期化処理 • EBSのマウント • DNSの登録 • 最新アプリケーションのデプロイ • 各サーバ間での連携登録


EBSの自動マウント• Atlassian製品はローカルディスクにファイルを作成する -> AutoScalingには本来不向き

• Root Volumeとは別のEBSに置いておこう • Cloud DIを活用し、マウントするEBS IDをタグに記載

• CloudFormationでEBSも作成する


Jenkinsによる自動化• Packer + AnsibleによるAMI作成 • 作成されたイメージのServerspecによるテスト • AutoScalingのAMI切替 • AMIの世代管理 • etc…

• 定形作業は基本的にお任せします


AMIの世代管理• AMIが増えすぎるのを防ぐ • Jenkinsで、日次で世代数を指定してAMI削除 • AMIにタグ「Persistent」をつけたものは削除されない

• 特定のバージョン・既存LaunchConfigurationのものは残す


運用してみた感想• Auto Healingは本当に楽 • メンテナンスの心配がいらない安心感 • AutoScalingでインスタンスが変わった通知は必要かも

• アプリケーションの制約を知る必要がある • データがどこに書かれるのか • アプリケーションの起動時にどのような処理が走るか


今後は• CloudFormationの実行自動化 • 現状はDry-runができない • CloudFormationに関するテスト • ツールを作る・・・？ • CloudFormationのCI

• AMI管理のベストプラクティス確立 • CloudFormation -> Terraform？


Developer Day

（サンプル）ご静聴ありがとうございました。スライドは後日ブログで公開します。

37

A-1


#cmdevio2015

Ansible + Packer + CloudFormationでらくらく構築・運用

Technology

Transcript of Ansible + Packer + CloudFormationでらくらく構築・運用