Downloaded 67 times
![障害対応のフロー++
1. アラートを受け取って
[受け取り口を用意(Listen)]
2. 内容を確認して
[パース＆チェック]
3. 既知なら手順に沿って対応する
[ディスパッチ・レスポンス]
4. 分からなかったら報告・連絡・相談
[ログなど]
53](https://image.slidesharecdn.com/jawsdaysinfra-140315000936-phpapp01/85/Infrastructure-as-Code-Immutable-Infrastructure-53-320.jpg)
![[小話]
Webサーバ
運用担当のお仕事](https://image.slidesharecdn.com/jawsdaysinfra-140315000936-phpapp01/85/Infrastructure-as-Code-Immutable-Infrastructure-54-320.jpg)
Uploaded byYukihiko SAWANOBORI
Infrastructure as Codeと 組織のドキュメンテーション ＋ Immutable Infrastructure事例
2014/3/15 JAWS DAYS 2014 Immutable Infrastructureトラック 13:00〜
More Related Content
![Aws OpsWorks [JAWSDAYS 2014 ACEに聞けトラック]](https://cdn.slidesharecdn.com/ss_thumbnails/awsopsworksoverview-140316224852-phpapp02-thumbnail.jpg?width=640&height=640&fit=bounds)
![さくらのクラウドフォーメーション with Chef [XEgg session]](https://cdn.slidesharecdn.com/ss_thumbnails/xegg01-chef-140214221012-phpapp02-thumbnail.jpg?width=640&height=640&fit=bounds)
![[jjug] Java と Benchmark](https://cdn.slidesharecdn.com/ss_thumbnails/nanobench-140822053056-phpapp01-thumbnail.jpg?width=640&height=640&fit=bounds)
![[Microsoft Tech Summit 2017] マイクロサービスだけじゃない! コンテナー オーケストレーターとしての「Azure Servic...](https://cdn.slidesharecdn.com/ss_thumbnails/20171108techsummitservicefabric-171109075108-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar to Infrastructure as Codeと 組織のドキュメンテーション ＋ Immutable Infrastructure事例
![[LT] インフラの人がChefやServerspec(ほか)が Rubyだったおかげですこし プログラムをするようになった話](https://cdn.slidesharecdn.com/ss_thumbnails/kansai-ruby6local-150711080405-lva1-app6892-thumbnail.jpg?width=640&height=640&fit=bounds)
Infrastructure as Codeと 組織のドキュメンテーション ＋ Immutable Infrastructure事例
- 1. Infrastructure as Codeと 組織のドキュメンテーション ＋Immutable Infrastructure事例 2014/3/15 JAWS DAYS 2014 Immutable Infrastructureトラック 13:00∼
- 2.
- 3. トラック仕掛け人(初代)の コネで来ました • 曰く • コアメンツでごりごりやろう •AWS臭がしないレーンを実現する 3
- 4.
- 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
- 9.
- 10.
- 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
- 15.
- 16. Apache ZooKeeper • 分散アプリケーションのためのコーディネーション を行なう •高速、シンプルなデータモデル • HadoopのNameNodeクラスタ(HA)にもつかわれる • ZooKeeper自身もクラスタを組める、データの管理 はクォーラム制 16
- 17. 監視プロセスの持ち方を変更 • Zokeeperにステータス管理を一任 • ロケーション情報 •ユーザの設定 • 監視サーバ担当状況 ! • とにかく監視サーバの数の増減とか死活を気 にしないように設計みなおし 17
- 18.
- 19. 運用を突き詰めた結果、 Immutableぽく • 変更はしてもしなくてもよい • サーバ追加時にバージョンの変更もOK •任意のサーバを廃棄するのも気分次第 • クライアントをグループ定義して、適当に切 り替えればBlue Green風 • Devと一緒に問題点を洗いだし、対策を協議 したら勝手にこうなりました感 19
- 20. しかし新構成の本番運用なし • パブリックサービス化も視野に • 2012年秋頃には既にひと通り動作 ! •諸事情によって刷新リリース未定 • 諸事情とは 20
- 21. ZooKeeper補足 • 信頼性はServer/Client間の疎通で保つ • メンバが離れすぎると全体がもっさり 21 ※GoogleMaps ap-northeast sa-east AWSって便利ね
- 22.
- 23.
- 24. 円滑に実践するには • Infrastructure asCodeを活用するのがよい と思います • サーバほか論理リソースの調達、および構 成管理 • 先の事例でもChefを使用 • shell, puppet, chef, ansible.. syllabus.. ! • 導入したい企業も多いようです 24
- 25.
- 26.
- 27. ドキュメント(手順書)の特徴 • 理解できるのは人間だけ • コンピュータにとっては高級すぎる言語 •行間など、コンテキストがもたらす神秘性 • 作れるのも人間だけ • 制作物としてシェアできる • 親密なコミュニティを形成、人間同士の強 い結束 27
- 28.
- 29. • ワープロで編集する 手順書 比較1 • 機械で実行?? Chefのレシピ 29 構築手順書.txt ! 1.共通パッケージの導入 2. Webサーバ用の設定 3. DBサーバ用の設定
- 30.
- 31.
- 32.
- 33.
- 34.
- 35.
- 36.
- 37.
- 38.
- 39.
- 40.
- 41.
- 42.
- 43.
- 44.
- 45.
- 46.
- 47.
- 48. そもそもCodeって • 自然言語だってコード • 整形されたテキストで表現されたやたら高級なファ イルももちろんコードです •ドキュメント(コード)を中心にしたワークフローの 形式は確立している • なら記述しやすいうえに実行可能な手順書になって いくのは自然の流れ • ワープロの手順書と、ChefのレシピはOffice97を使 うか、Office2013を使うかくらいの違い、と思いま しょう 48
- 49.
- 50. 例：serverspecに対して持つ 個人的 な感想 • 作った後にチェック、なんか美しくない．．． •でも受け入れられる世界なのも理解できるし勧めやすい • ただ、 • どーせお前らログインして… • このコマンド叩いて • この出力確認すんだろ？ • そんくらいなら素早く正確にやったるわー • という、人をおちょくった機能美がとても好きです 50
- 51.
- 52. 障害対応のフロー 1. アラートを受け取って 2. 内容を確認して 3.既知なら手順に沿って対応する 4. 分からなかったら報告・連絡・相談 52
- 53. 障害対応のフロー++ 1. アラートを受け取って [受け取り口を用意(Listen)] 2. 内容を確認して [パース＆チェック] 3.既知なら手順に沿って対応する [ディスパッチ・レスポンス] 4. 分からなかったら報告・連絡・相談 [ログなど] 53
- 54.
- 55. Webサーバ? • Apache httpd •nginx • lighttpd • etc… ! • で、Webサーバ運用担当者が使うのは 55
- 56. ところで、インフラの方ならば • telnetでこのくらいのリクエストは日常的に やりますよね？ • SMTP •FTP • HTTP • munin-plugin • sslなら openssl s_client とか・・ 56
- 57.
- 58.
- 59. $ sudo nc-l 80
- 60. Webサーバ手順書一覧 • アクセス許可IPリスト.xlsx • レスポンス手順書.docx •index.html表示手順書.docx 60
- 61.
- 62.
- 63.
- 64.
- 65. index.html手順書 • まず `HTTP/1.0200 OK` で表示の許可を お伝えします。 • 一行開けます • 続いてコンテンツを送信します、次の文書を コピペして、Ctrl+Dで閉じましょう。 65 <html><body> <h1>Hello World</h1> </body></html>
- 66.
- 67.
- 68.
- 69.
- 70. Web運用担当とhttpdを 比較して検討 • 正確とかコストとか色々ありますが • 単位あたりの所用時間が短く •繰り返し処理に強い • 同じワークフローでも、内容が洗練されてい けば結局こうなる • インフラもそうかもしれない 70
- 71.
- 72. Chefでこんな相談受けます • 開発環境とかは手でやってます • でもその先とか、本番とかはChefにして、 なんかカッコよく自動でやりたいんです！ 72 …Infraas Codeとかって、 多分そういうことちゃうんよ
- 73.
- 74. Infrastructure as Codeのいいとこ •いろんな段階・レイヤから適用でき、つかい まわせる、というかつかいまわそう • すぐ試せる、何度も失敗できる • そういうツールも沢山 • AWS使うのもいいよね • 便利なツールになれると、さらに応用も利く • アジャイル開発の手法に近づけるのかも 74
- 75.
- 76. 新しめに見える概念の導入に 意外と課題は少ない • 考え方、ワークフローは(多分)完成してい る。 • 捉え方の問題 •何の置き換えかを把握して、置き換えられた 事は停止する 76
- 77. 最後：テーマについて諸々 1/2 • ただのディスポーザブルちゃうの? •そこらへん、個人的にはあまり違いを意識 していません • 単位がサーバだったりアプリだったりでも通 用する • 例えばCapistranoのデプロイとか、似た ような構造のフローです 77
- 78. 最後：テーマについて諸々 2/2 • 適用できそうなところ・レイヤには優先して 適用していけば良いんじゃないか •ZooKeeperの例とかは、多分一般的な構 成ですが、イミュータブルぽかったので紹 介しました 78
- 79.