2015/03/29 Developers.IO 2015 Developer Day CM勢監視運用他トラック #cmdevio2015H
Ansibleで動的にホスト一覧を生成できるので、inventoryファイル(ホスト一覧)を手作りしなくていいらしい。べんり #cmdevio2015H
2015-03-29 15:09:49#cmdevio2015H #cmdevio2015 packe build ナンタラカンタラ -> 寝る -> AMI完成!
2015-03-29 15:10:57Packerがやってくれること: EC2の起動、Ansibleによる設定流し込み、(実行が成功したら)AMI化、EC2削除 #cmdevio2015H
2015-03-29 15:10:59#cmdevio2015H #cmdevio2015 Ansible サービス定義; Packer イメージ定義; AWS インフラ操作
2015-03-29 15:15:05CFnでAWS構築、Packer+AnsibleでAMI作成、CFnのパラメータ(AMI ID)変更、変更が入ったらAnsibleを再度適用してAMI化、という流れで使うとのこと #cmdevio2015H
2015-03-29 15:15:06EC2数百台かつマルチリージョンの基盤構築で、CloudFormationでEC2を作成し、PackerでAMI化、他のリージョンにコピーした経験の話 #cmdevio2015H
2015-03-29 15:17:27#cmdevio2015H #cmdevio2015 更新回数が少ないソフトウェアがミドルウェアであると定義すればいい
2015-03-29 15:18:46node.jsのコンパイル時間がストレスだったので、PackerのAMI作成を別プロセスで実施。変更が少ない部分と多い部分に分けて、2段階でAMIを作成した。おーなるほど #cmdevio2015H
2015-03-29 15:18:57Cloud DIとは: EC2につけたタグに応じて、EC2の起動プロセスでセットアップを実施。EC2自身にステージングか本番か、アプリケーション種別などを示させる。 #cmdevio2015H
2015-03-29 15:21:53#cmdevio2015H #cmdevio2015 起動時にインスタンスのタグに応じてChef-soloが走るようなイメージを作っておくと良いのかな?
2015-03-29 15:22:39CloudFormation、「完全に制御できる、短期間だけ必要な大規模環境」にはすごくマッチするんだな。複数の人が長期にわたって触る環境で使うのはむずかしそうだけど #cmdevio2015H
2015-03-29 15:24:08#cmdevio2015H #cmdevio2015 AMIはミドルの更新時のみ生成するようにするようなワークフローにすると,管理可能な数に収まるし,時間の節約にもなる.
2015-03-29 15:26:29#cmdevio2015H #cmdevio2015 Auto Healingの正体は,いつでも同じ台数を保とうとするAuto Scaling
2015-03-29 15:27:57「Auto Healingはアンデッドパターンとも社内では呼ばれていて」(後者の呼び方は初耳ですが)自動復旧に非常に便利ですね。詳しくは植木さんのスライドをご覧ください。slideshare.net/kazukiueki76/2… #cmdevio2015H
2015-03-29 15:29:50Atlassian製品はローカルにファイルを作成するので本来Auto Scalingに不向き。しかし、EC2のタグにattachすべきEBSのボリュームIDを書き込んでおいて、起動プロセスの中でマウントさせることで解決したとのこと。 #cmdevio2015H
2015-03-29 15:31:40#cmdevio2015H #cmdevio2015 AMIにライフタイムを設定しておくと,AMIの数は結構増えなくなる.
2015-03-29 15:33:51AMIの世代管理はJenkinsで。保存数以上になったら古いものを削除。残しておきたい特定のAMIにはタグをつけておいて、消さない印とする。タグまじべんり #cmdevio2015H
2015-03-29 15:34:58#cmdevio2015H #cmdevio2015 CloudFormationはdryrunができないらしい.もしそうなら,HashiCorpのTerraformは,Plan機能を持っているから,非常に有用なものなのかもしれない.
2015-03-29 15:36:38