Infrastructure as Codeと組織のドキュメンテーション＋ Immutable Infrastructure事例

Infrastructure as Codeと組織のドキュメンテーション＋ Immutable Infrastructure事例 2014/3/15 JAWS DAYS 2014 Immutable Infrastructureトラック 13:00∼

誰ですかどんな立場からもの言うんですか？

トラック仕掛け人(初代)のコネで来ました • 曰く • コアメンツでごりごりやろう • AWS臭がしないレーンを実現する 3

ソーシャルベースの印象からいただいた評価 •Chefの神 (千葉県:Aさん) •Chefおじさん (大阪府:Bさん) •そもそも振る舞いがChef  (神戸市:Cさん) •変態的なChef使い  (神奈川県:Dさん ※人づて) 4

Chefの本を書きました • 来月、4/12(土)発売予定 • 「Chef活用ガイド ∼ コードではじめる構成管理」 • Infrastructure as Codeを実践しよう！ • 日本公式代理店の  クリエーションラインさんと  共著 5 NOW Printing

『Chef活用ガイド』について • 注意：すぐ使える！とかではない模様 • 公式Docsの流れを踏襲し、さらに詳しく記述 • 解説部分の元ネタは大体ソースコード • Chef本体から離れる話は少なめ • 付録 • 今日のセッションみたいなコラム • Enterpriseアドオン • 全リソース和訳 6 NOW Printing

運営組織 7 • 代表社員をつとめる合同会社 • アプリケーションのためのプラットフォーム構築/運用自動化をテーマに活動 • http://opsrock.in 共同開発・運営 • Chef関連を主に取り扱うソリューションを提供 • 導入支援コンサルも

本日の内容 1.Infrastructure as Codeと  組織のドキュメンテーション • ドキュメントにまつわるワークフロー • みなさん既に、なんでもできます 2.Immutable Infrastructure事例 • 外部監視サービス • Zookeeperでステート管理 8

2 Immutable Infrastructure事例

Immutable Infrastructure • きっと今朝、このトラックで説明があった通りです。 10

Immutableなデプロイに向く例など • ステータスやローカルにユーザのファイルを持たないとされるものが中心 • HTTPのロードバランサとか • Railsのアプリケーションプロセスとか • Serfなどのオーケストレーションツールでクラスタにすると良いなど言われるが… ! • 結構限られた感じ (もちろん作りこめばアリ) 11

クローズドサービス：Giraﬃ • 国内IaaSサービスのモニタリング/監視機能を提供、一応SaaS (提供は2011年∼) • 外部監視をユーザごとに個別のNagiosプロセスが担当 • 仮想基板KVM 12

最初の構成 • 各NagiosのセッテイングはAPI経由でDBに • GlusterFSでNagios設定ファイルをシェア • 任意の外部監視サーバでプロセス起動 13 GlusterFS AppServer 外部監視サーバ nagios.cfg 外部監視サーバ外部監視サーバ nagios.cfg nagios.cfg nagios.cfg action_log kick

課題が • GlusterFSに依存  => 物理的に近くないと挙動怪しくなる  => 複数拠点対応が面倒 • 監視サーバの変更は簡単、追加、削除も余裕  => しかし、障害で落ちたらサーバが担当中の Nagiosがつられていなくなる • その他いろいろ • 監視サーバのデプロイ設計が古いとか、なんか飽きたとか 14

Zookeeperを中心にしたステータス管理へ

Apache ZooKeeper • 分散アプリケーションのためのコーディネーションを行なう • 高速、シンプルなデータモデル • HadoopのNameNodeクラスタ(HA)にもつかわれる • ZooKeeper自身もクラスタを組める、データの管理はクォーラム制 16

監視プロセスの持ち方を変更 • Zokeeperにステータス管理を一任 • ロケーション情報 • ユーザの設定 • 監視サーバ担当状況 ! • とにかく監視サーバの数の増減とか死活を気にしないように設計みなおし 17

location A ZooKeeperを通じた協調動作 18 AppServer 外部監視サーバ外部監視サーバ location N 外部監視サーバ外部監視サーバ・S/C間はコネクション維持・新規接続/切断を検出・未担当の設定があれば  誰かが引き継ぐ多分こいつらがイミュータブル Conﬁgure

運用を突き詰めた結果、 Immutableぽく • 変更はしてもしなくてもよい • サーバ追加時にバージョンの変更もOK • 任意のサーバを廃棄するのも気分次第 • クライアントをグループ定義して、適当に切り替えればBlue Green風 • Devと一緒に問題点を洗いだし、対策を協議したら勝手にこうなりした感 19

しかし新構成の本番運用なし • パブリックサービス化も視野に • 2012年秋頃には既にひと通り動作 ! • 諸事情によって刷新リリース未定 • 諸事情とは 20

ZooKeeper補足 • 信頼性はServer/Client間の疎通で保つ • メンバが離れすぎると全体がもっさり 21 ※Google Maps ap-northeast sa-east AWSって便利ね

1.Infrastructure as Codeと  組織のドキュメンテーション

Immutable Infrastructure • 大体さっきの事例っぽいかんじ 23

円滑に実践するには • Infrastructure as Codeを活用するのがよいと思います • サーバほか論理リソースの調達、および構成管理 • 先の事例でもChefを使用 • shell, puppet, chef, ansible.. syllabus.. ! • 導入したい企業も多いようです 24

• でも本当にこんなもの要るのだろうか？ • 導入するとして、どうするのかもわからない

ドキュメント礼賛 https://gist.github.com/azukiwasher/8571505 手順書こそが最善の方策である。

ドキュメント(手順書)の特徴 • 理解できるのは人間だけ • コンピュータにとっては高級すぎる言語 • 行間など、コンテキストがもたらす神秘性 • 作れるのも人間だけ • 制作物としてシェアできる • 親密なコミュニティを形成、人間同士の強い結束 27

機械に読解不能であること • インフラの構築とは、人間の企みだ 28

• ワープロで編集する  手順書比較1 • 機械で実行??  Chefのレシピ 29 構築手順書.txt ! 1. 共通パッケージの導入 2. Webサーバ用の設定 3. DBサーバ用の設定

ワークフローその１

手順を作成し、シェアしよう 31

シェアされた手順をレビューしよう 32

検証機でためしてみよう 33 Env: Staging

検証の結果を元に、承認をもらおう 34

手順を本番用に書き換えよう 35

本番へ 36 Env: Production

鉄板のワークフロー！

• 人にしかわからない  文字の羅列比較1 • 機械が理解できる内容 38

ワークフローその2

手順を作成し、シェアしよう 40

シェアされた手順をレビューしよう 41

検証機でためしてみよう 42 Env: Staging

検証の結果を元に、承認をもらおう 43

手順を本番用に書き換えよう 44

本番へ 45 Env: Production

鉄板のワークフロー(再)！

Infrastructure as Codeの抱える問題人で置き換えやすい ※手でImmutableやっても全然こまらない 47

そもそもCodeって • 自然言語だってコード • 整形されたテキストで表現されたやたら高級なファイルももちろんコードです • ドキュメント(コード)を中心にしたワークフローの形式は確立している • なら記述しやすいうえに実行可能な手順書になっていくのは自然の流れ • ワープロの手順書と、ChefのレシピはOﬃce97を使うか、Oﬃce2013を使ううかくらいの違いと思いましょう 48

既存のワークフローにのっとって人のやることを置き換えるだけでも十分 49

例：serverspecに対して持つ個人的な感想 • 作った後にチェック、なんか美しくない．．． • でも受け入れられる世界なのも理解できるし勧めやすい • ただ、 • どーせお前らログインして… • このコマンド叩いて • この出力確認すんだろ？ • そんくらいなら素早く正確にやったるわー  • という、人をおちょくった機能美がとても好きです 50

イマイチ納得いかない方のため、 ! もう一つワークフロー比較

障害対応のフロー 1. アラートを受け取って 2. 内容を確認して 3. 既知なら手順に沿って対応する 4. 分からなかったら報告・連絡・相談 52

障害対応のフロー++ 1. アラートを受け取って  [受け取り口を用意(Listen)] 2. 内容を確認して  [パース＆チェック] 3. 既知なら手順に沿って対応する  [ディスパッチ・レスポンス] 4. 分からなかったら報告・連絡・相談  [ログなど] 53

[小話]  Webサーバ運用担当のお仕事

Webサーバ? • Apache httpd • nginx • lighttpd • etc… ! • で、Webサーバ運用担当者が使うのは 55

ところで、インフラの方ならば • telnetでこのくらいのリクエストは日常的にやりますよね？ • SMTP • FTP • HTTP • munin-plugin • sslなら openssl s_client とか・・ 56

Netcat +補助的にTCPdump

http://ja.wikipedia.org/wiki/Netcat

$ sudo nc -l 80

Webサーバ手順書一覧 • アクセス許可IPリスト.xlsx • レスポンス手順書.docx • index.html表示手順書.docx 60

例示：アクセス許可IPリスト.xlsx 61

担当者はnetcatでサーバ業務開始 • ついでにTCPdumpでアクセス元を監視 • アクセスが来ました！？ 62 ※撮影の都合上、8080でやっています

表で認証チェック! OKです 63

続いてリクエストチェック! GET /index.html です！ 64

index.html手順書 • まず `HTTP/1.0 200 OK` で表示の許可をお伝えします。 • 一行開けます • 続いてコンテンツを送信します、次の文書をコピペして、Ctrl+Dで閉じましょう。 65 <html><body> <h1>Hello World</h1> </body></html>

捌きました！ 66 Web担当者

アクセス増加、 10,000req/分の人気サイトに！ ! どうしましょう・・？

もちろん、増員すりゃいいです 68 Web担当者Web担当者Web担当者Web担当者Web担当者Web担当者Web担当者Web担当者Web担当者Web担当者Web担当者Web担当者Web担当者 Web担当者Web担当者Web担当者Web担当者Web担当者Web担当者Web担当者Web担当者Web担当者Web担当者Web担当者Web担当者Web担当者 Web担当者Web担当者Web担当者Web担当者Web担当者Web担当者Web担当者Web担当者Web担当者Web担当者Web担当者Web担当者Web担当者 Netcat! Netcat! Netcat! Netcat! 伝説の部長

Web担当部の抱える問題 httpdで置き換えやすい 69

Web運用担当とhttpdを比較して検討 • 正確とかコストとか色々ありますが • 単位あたりの所用時間が短く • 繰り返し処理に強い • 同じワークフローでも、内容が洗練されていけば結局こうなる • インフラもそうかもしれない 70

Infrastructure as Code導入のヒント

Chefでこんな相談受けます • 開発環境とかは手でやってます • でもその先とか、本番とかはChefにして、なんかカッコよく自動でやりたいんです！ 72 …Infra as Codeとかって、  多分そういうことちゃうんよ

短いスパンで何度も繰り返そう

Infrastructure as Codeのいいとこ • いろんな段階・レイヤから適用でき、つかいまわせる、というかつかいまわそう • すぐ試せる、何度も失敗できる • そういうツールも沢山 • AWS使うのもいいよね • 便利なツールになれると、さらに応用も利く • アジャイル開発の手法に近づけるのかも 74

ワークフロー、ツールを書籍執筆にだって応用 75 執筆中(6ヶ月間)は1回も顔を合わせなかった ※Chef活用ガイドは4月発売予定です

新しめに見える概念の導入に意外と課題は少ない • 考え方、ワークフローは(多分)完成している。 • 捉え方の問題 • 何の置き換えかを把握して、置き換えられた事は停止する 76

最後：テーマについて諸々 1/2 • ただのディスポーザブルちゃうの? • そこらへん、個人的にはあまり違いを意識していません • 単位がサーバだったりアプリだったりでも通用する • 例えばCapistranoのデプロイとか、似たような構造のフローです 77

最後：テーマについて諸々 2/2 • 適用できそうなところ・レイヤには優先して適用していけば良いんじゃないか • ZooKeeperの例とかは、多分一般的な構成ですが、イミュータブルぽかったので紹介しました 78

おわり。 ! 17:00∼のパネルディスカッションもどうぞよろしく

Infrastructure as Codeと組織のドキュメンテーション＋ Immutable Infrastructure事例

by Yukihiko SAWANOBORI, CEO at HiganWorks LLC on Mar 15, 2014

Statistics

Views

Actions

0 Embeds 0

Accessibility

Categories

Upload Details

Usage Rights

Report content