Infrastructure as Codeと 組織のドキュメンテーション ＋ Immutable Infrastructure事例
•
34 recomendaciones•14,762 vistas
2014/3/15 JAWS DAYS 2014 Immutable Infrastructureトラック 13:00〜
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Similar a Infrastructure as Codeと 組織のドキュメンテーション ＋ Immutable Infrastructure事例
Similar a Infrastructure as Codeと 組織のドキュメンテーション ＋ Immutable Infrastructure事例 (20)
Más de Yukihiko SAWANOBORI
Más de Yukihiko SAWANOBORI (20)
Último
Último (10)
Infrastructure as Codeと 組織のドキュメンテーション ＋ Immutable Infrastructure事例
- 1. Infrastructure as Codeと 組織のドキュメンテーション ＋ Immutable Infrastructure事例 2014/3/15 JAWS DAYS 2014 Immutable Infrastructureトラック 13:00∼
- 3. トラック仕掛け人(初代)の コネで来ました • 曰く • コアメンツでごりごりやろう • AWS臭がしないレーンを実現する 3
- 5. Chefの本を書きました • 来月、4/12(土)発売予定 • 「Chef活用ガイド ∼ コードではじめる構成 管理」 • Infrastructure as Codeを実践しよう！ • 日本公式代理店の クリエーションラインさんと 共著 5 NOW Printing
- 6. 『Chef活用ガイド』について • 注意：すぐ使える！とかではない模様 • 公式Docsの流れを踏襲し、さらに詳しく記述 • 解説部分の元ネタは大体ソースコード • Chef本体から離れる話は少なめ • 付録 • 今日のセッションみたいなコラム • Enterpriseアドオン • 全リソース和訳 6 NOW Printing
- 7. 運営組織 7 • 代表社員をつとめる合同会社 • アプリケーションのためのプラットフォーム構築/運 用自動化をテーマに活動 • http://opsrock.in 共同開発・運営 • Chef関連を主に取り扱うソリューションを 提供 • 導入支援コンサルも
- 8. 本日の内容 1.Infrastructure as Codeと 組織のドキュメンテーション • ドキュメントにまつわるワークフロー • みなさん既に、なんでもできます 2.Immutable Infrastructure事例 • 外部監視サービス • Zookeeperでステート管理 8
- 11. Immutableなデプロイに向く例など • ステータスやローカルにユーザのファイルを 持たないとされるものが中心 • HTTPのロードバランサとか • Railsのアプリケーションプロセスとか • Serfなどのオーケストレーションツールでク ラスタにすると良いなど言われるが… ! • 結構限られた感じ (もちろん作りこめばアリ) 11
- 12. クローズドサービス：Giraffi • 国内IaaSサービスのモニタリング/監視機能 を提供、一応SaaS (提供は2011年∼) • 外部監視をユーザごとに個別のNagiosプロ セスが担当 • 仮想基板KVM 12
- 13. 最初の構成 • 各NagiosのセッテイングはAPI経由でDBに • GlusterFSでNagios設定ファイルをシェア • 任意の外部監視サーバでプロセス起動 13 GlusterFS AppServer 外部監視サーバ nagios.cfg 外部監視サーバ 外部監視サーバ nagios.cfg nagios.cfg nagios.cfg action_log kick
- 14. 課題が • GlusterFSに依存 => 物理的に近くないと挙動怪しくなる => 複数拠点対応が面倒 • 監視サーバの変更は簡単、追加、削除も余裕 => しかし、障害で落ちたらサーバが担当中の Nagiosがつられていなくなる • その他いろいろ • 監視サーバのデプロイ設計が古いとか、な んか飽きたとか 14
- 16. Apache ZooKeeper • 分散アプリケーションのためのコーディネーション を行なう • 高速、シンプルなデータモデル • HadoopのNameNodeクラスタ(HA)にもつかわれる • ZooKeeper自身もクラスタを組める、データの管理 はクォーラム制 16
- 17. 監視プロセスの持ち方を変更 • Zokeeperにステータス管理を一任 • ロケーション情報 • ユーザの設定 • 監視サーバ担当状況 ! • とにかく監視サーバの数の増減とか死活を気 にしないように設計みなおし 17
- 19. 運用を突き詰めた結果、 Immutableぽく • 変更はしてもしなくてもよい • サーバ追加時にバージョンの変更もOK • 任意のサーバを廃棄するのも気分次第 • クライアントをグループ定義して、適当に切 り替えればBlue Green風 • Devと一緒に問題点を洗いだし、対策を協議 したら勝手にこうなりました感 19
- 20. しかし新構成の本番運用なし • パブリックサービス化も視野に • 2012年秋頃には既にひと通り動作 ! • 諸事情によって刷新リリース未定 • 諸事情とは 20
- 21. ZooKeeper補足 • 信頼性はServer/Client間の疎通で保つ • メンバが離れすぎると全体がもっさり 21 ※Google Maps ap-northeast sa-east AWSって便利ね
- 24. 円滑に実践するには • Infrastructure as Codeを活用するのがよい と思います • サーバほか論理リソースの調達、および構 成管理 • 先の事例でもChefを使用 • shell, puppet, chef, ansible.. syllabus.. ! • 導入したい企業も多いようです 24
- 27. ドキュメント(手順書)の特徴 • 理解できるのは人間だけ • コンピュータにとっては高級すぎる言語 • 行間など、コンテキストがもたらす神秘性 • 作れるのも人間だけ • 制作物としてシェアできる • 親密なコミュニティを形成、人間同士の強 い結束 27
- 29. • ワープロで編集する 手順書 比較1 • 機械で実行?? Chefのレシピ 29 構築手順書.txt ! 1. 共通パッケージの導入 2. Webサーバ用の設定 3. DBサーバ用の設定
- 30. ワークフロー その１
- 31. 手順を作成し、シェアしよう 31
- 35. 手順を本番用に書き換えよう 35
- 37. 鉄板の ワークフロー！
- 39. ワークフロー その2
- 40. 手順を作成し、シェアしよう 40
- 44. 手順を本番用に書き換えよう 44
- 46. 鉄板の ワークフロー(再)！
- 48. そもそもCodeって • 自然言語だってコード • 整形されたテキストで表現されたやたら高級なファ イルももちろんコードです • ドキュメント(コード)を中心にしたワークフローの 形式は確立している • なら記述しやすいうえに実行可能な手順書になって いくのは自然の流れ • ワープロの手順書と、ChefのレシピはOffice97を使 うか、Office2013を使うかくらいの違い、と思いま しょう 48
- 50. 例：serverspecに対して持つ 個人的 な感想 • 作った後にチェック、なんか美しくない．．． • でも受け入れられる世界なのも理解できるし勧めやすい • ただ、 • どーせお前らログインして… • このコマンド叩いて • この出力確認すんだろ？ • そんくらいなら素早く正確にやったるわー • という、人をおちょくった機能美がとても好きです 50
- 52. 障害対応のフロー 1. アラートを受け取って 2. 内容を確認して 3. 既知なら手順に沿って対応する 4. 分からなかったら報告・連絡・相談 52
- 53. 障害対応のフロー++ 1. アラートを受け取って [受け取り口を用意(Listen)] 2. 内容を確認して [パース＆チェック] 3. 既知なら手順に沿って対応する [ディスパッチ・レスポンス] 4. 分からなかったら報告・連絡・相談 [ログなど] 53
- 55. Webサーバ? • Apache httpd • nginx • lighttpd • etc… ! • で、Webサーバ運用担当者が使うのは 55
- 56. ところで、インフラの方ならば • telnetでこのくらいのリクエストは日常的に やりますよね？ • SMTP • FTP • HTTP • munin-plugin • sslなら openssl s_client とか・・ 56
- 59. $ sudo nc -l 80
- 60. Webサーバ手順書一覧 • アクセス許可IPリスト.xlsx • レスポンス手順書.docx • index.html表示手順書.docx 60
- 65. index.html手順書 • まず `HTTP/1.0 200 OK` で表示の許可を お伝えします。 • 一行開けます • 続いてコンテンツを送信します、次の文書を コピペして、Ctrl+Dで閉じましょう。 65 <html><body> <h1>Hello World</h1> </body></html>
- 66. 捌きました！ 66 Web担当者
- 70. Web運用担当とhttpdを 比較して検討 • 正確とかコストとか色々ありますが • 単位あたりの所用時間が短く • 繰り返し処理に強い • 同じワークフローでも、内容が洗練されてい けば結局こうなる • インフラもそうかもしれない 70
- 72. Chefでこんな相談受けます • 開発環境とかは手でやってます • でもその先とか、本番とかはChefにして、 なんかカッコよく自動でやりたいんです！ 72 …Infra as Codeとかって、 多分そういうことちゃうんよ
- 73. 短いスパンで 何度も繰り返そう
- 74. Infrastructure as Codeのいいとこ • いろんな段階・レイヤから適用でき、つかい まわせる、というかつかいまわそう • すぐ試せる、何度も失敗できる • そういうツールも沢山 • AWS使うのもいいよね • 便利なツールになれると、さらに応用も利く • アジャイル開発の手法に近づけるのかも 74
- 76. 新しめに見える概念の導入に 意外と課題は少ない • 考え方、ワークフローは(多分)完成してい る。 • 捉え方の問題 • 何の置き換えかを把握して、置き換えられた 事は停止する 76
- 77. 最後：テーマについて諸々 1/2 • ただのディスポーザブルちゃうの? • そこらへん、個人的にはあまり違いを意識 していません • 単位がサーバだったりアプリだったりでも通 用する • 例えばCapistranoのデプロイとか、似た ような構造のフローです 77
- 78. 最後：テーマについて諸々 2/2 • 適用できそうなところ・レイヤには優先して 適用していけば良いんじゃないか • ZooKeeperの例とかは、多分一般的な構 成ですが、イミュータブルぽかったので紹 介しました 78