ようへいの日々精進XP

よかろうもん

Immutable Infrastructure Conference #1 に参加(しているので→したので)メモ #immutableinfra

はじめに

  • ダメ元で申し込んでいたら補欠から繰り上がっていて小躍りしながら参加した
  • 会場を提供して頂いた DeNA さん!素敵な夜景でした!ありがとうございました!
  • 登壇された皆さん、ありがとうございました!
  • 以下、箇条書き

参考リンク


19:10 – 19:30 @naoya_ito Immutable Infrastructureが開発プロセスへの与える影響(仮)

資料

Immutable Infrastructure とは

  • 廃棄可能な(disposable components)
  • サーバー状態を管理?
  • 状態管理をしなければいいぢゃん
  • 情熱プログラマー
  • Blue Green Deployment
  • クラスタをもう一個作ってから Load Balancer を切り替える
  • Windows でよくあるアレ
  • Heroku / Travis CI
  • amazon は 1 時間に 1000 回のデプロイ

開発プロセス

  • Immuutable であることでアプリケーションアーキテクチャへも大きな影響
  • アーキテクチャへの影響(アプリ開発者)
  • 制約(REST / ステートレスな HTTP と WWW)
  • The Tweleve-Factor App(Immutable な制約を受け入れる)
  • プロセスはステートレス、 shared nothing.
  • 設定をコードから厳密に分離
  • 依存関係を厳密に
  • 一見不自由だが…
  • 再現可能なアプリケーション、アプリケーションが標準化される
  • テスト容易性(Jenins おじさんのスレーブノード)
  • 上書きデプロイからコンテナベースのデプロイへ
  • Quipper 社の事例(feature branch への push のたびに Heroku でアプリケーションを作る)

Immutable Infrastructure の現在

  • 試行錯誤
  • いろいろな部品(Docker / mesos-docker / serf …)
  • 「Private な PaaS が欲しい」ではなくて「既存のインフラを動的にしたい」
  • コンテナベースのデプロイを体感

これから

  • 従来固定だったコンポーネントが動的、オンザフライになっていく
  • 集大成が Immutable Infrastracture

19:30 – 19:50 @gosukenator Immutable InfrastructureとProvisioning Testing

資料

というよりもコンテナと Provisioning Testing

  • TECHNOLOGY RADER(技術トレンドをまとめている)
  • 2012 年では Trial
  • 概念としては結構前からある

コンテナをテストに利用

  • コンテナと言えば docker
  • puppet から LXC を起動する(直接叩く)
  • Docker は TECHNOLOGY RADER は ASSES
  • Docker を使うことでテストサイクルが早くなる

テストに使うデメリット

  • マシンの仮想化ではない
  • HV 型の VM とは異なる
  • システムコンテナとして起動する
  • iptables の制御が出来ない
  • ntpd が起動しない(Linux の ケイパビリティを使っている為)
  • if in_container が必要になる…
  • ゲストが CentOS でハマる
  • upstart や init 周りの挙動
  • HV 型やベアメタルサーバーのテストはあまりオススメしない

コンテナをプロダクションで使う場合の Provisioning Testing

  • 1 コンテナで 1 サービス
  • 単機能で疎結合
  • ホスト OS とコンテナの機能分離
  • コンテナ内では特定のアプリケーションだけを動かす
  • テスタビリティの向上
  • 状態よりも振る舞いのテストが重要だが決定的なツールはない
  • specinfra と serverspec をベースに作るかも

まとめ

  • プロダクショがコンテナじゃないならオススメしない
  • 状態のテストよりも振る舞いのテストが重要

19:50 – 20:10 @sonots Serf話か、Immutable InfrastructureでFluentd話(仮)(serf の話)

資料

自己紹介

  • Focuslight
  • Yohoushi
  • Fluentd

serf

オーケストレーション

インフラ作業あるある

serf で自動化

Immutable インフラに適した…

  • 中央集権型
  • Agent 型(ホストが立ち上がるとかってに情報をおくる)→ sensu
  • Agent 型が Immutable Infrastracture が適している
  • ganglia…
  • Fluentd ログ収集(Agent 型)
  • 中央型はどうする?
  • そこで serf

気づいたこと

  • どの位の時間で伝播されるのか?(serf のサイトにシュミレータ)→ 30 ノードで 1.25s / 100 ノードで 2s
  • 同じ確率で join のコマンドを投げられるようにする
  • 監視を外すタイミング?

Advanced

  • serf event
  • serf monitor(serf agent のログを見れる)
  • serf tag
  • serf query(serf event は投げっぱなし、query はレスポンスを受け取ることが出来る)

まとめ

  • serf
  • Immutable インフラには Agent 型が適している
  • serf で中央集権型を Agent 型にすると捗る

20:20 – 20:40 @tatsuru Mesos + Dockerでデプロイできるものを試作してみた系(仮)

Immutable Infrastacture はどこまで出来るんだろう

  • 作ってみた

Cluster Management

mesos

  • ZooKeeper で管理されている
  • Master / Slave
  • Framework : Marathon
  • Executer : Mesos-Docker

Log 収集

  • Fluentd
  • supervisor 経由
  • ログ収集のプロセスをどのように立てるかが議論されていた(Inside / Outside / In Separater)

Metrics

  • サーバー(Docker)メトリクス(cgroup / netstat
  • Graphite と Fluentd
  • スケールさせ辛い
  • Munin と Zabbix は難しい
  • Agent 型は NewReric は課金がきつい

監視

  • sensu
  • Docker API から監視
  • sensu のエージェントがどこにいるか?

Helper コンテナ

  • 監視、ログ収集
  • Ambassador Container よりもう少し高機能

オーケストレーション

まとめ

  • Immutable 環境を作ってみた
  • 課題いろいろ(クラスタ管理、ログ管理、監視)

20:40 – 21:00 @mirakui Docker + HAProxy + Synapse

Synapse とは?

  • サービスディスカバリを haproxy に反映させるツール
  • haproxy は動的にノード追加出来ない

なぜ Synapse か?

  • haproxy を自動更新する実装に興味があった
  • Pure Ruby

cookpad のオートスケール

  • EC2 のタグ(Status:working)

インストールと設定

  • gem install syanpse
  • 設定は JSON
  • discovery(DNS / Docker / ec2tag…)
  • ec2tag は非対応

docker + synapse

  • docker の HTTP API で監視、コンテナの起動等を行う

雑感

  • 動く
  • Docker Host 側 IP アドレス + ポートマップにしか対応していない
  • ディスカバリと連携して haproxy の設定を書き換える(JSON を生成している)
  • Watcher は Zookeeper しか対応してない
  • Cookpad では erb で生成している

21:00 – 21:10 @stanaka Immutable Infrastructure時代のサーバー管理

サーバー管理と言えば…

  • Zabbix
  • Nagios + Munin
  • sensu…

従来

  • ホストを 1 台ずつ認識

Immutable Infrastracture 時代

Role-based Management

  • 役割でホスト集合を管理する
  • ホスト名に意味を持たせない
  • サーバーに名前を付けるのは古い!クラウドネイティブな試行を妨げになる
  • EC2 のタグ
  • デプロイ時のホスト一覧取得
  • ホストへの一括 ssh ログイン
  • 役割単位でのメトリクス情報可視化

デプロイプロセスとサーバー管理の融合

  • mackernel サービスとして提供

21:10 – 21:15 @xga LT: chefからdockerへの鞍替え

  • 資料
  • cookbook の管理が面倒!
  • 安定した環境を docker 化
  • ansible-playbook 内で docker を実行する
  • docker-registry
  • 不安が幾つかある

21:15 – 21:20 @y_uuk1 LT: Docker使ってたらロードアベレージが80超えた話(サーバーがゴミ捨て場)

load average が 80 を超えた

  • 300 process
  • lxc のプロセスがうようよメモリを食いつぶしてswap

ファイルディスクリプタが 1000 を超えてる

  • docker => fork => lxc-start
  • Device mapper
  • 仮想的なブロックデバイスを作れる
  • umount

ゾンビプロセス 300 を超えてた

  • 綺麗好きな人を募集

21:20 – 21:25 @katzchang LT: AWSを使った事例紹介 (いろいろ辛い)

  • logrotate 辛い
  • インスタンス入れ替え時の負荷が辛い
  • puppet が辛い(shellscript /Makfile)
  • 監視系が辛い
  • 裏方系のサービスが密結合で辛い
  • オートスケールとデプロイの競合が辛い

ヌーラボの試み

  • @ikikko
  • NUUCON
  • AWS を使っている
  • 既存環境に影響を与えないところから Immutable
  • Jenkins => Ansible + Packer 最初の AMI
  • Jenkins => Vagrant + Ansible + serverspec で次の AMI
  • 過渡期
  • 一週間に一回程度

感想とか

  • 後で書きまする