第3回ペパボテックカンファレンスに参加してきたメモ #pbtech

10年動き続けているブログサービスのエンドツーエンドを書いた記録

ペパボ技術部
http://www..shu-cream.com

  • 電車で携帯忘れたときの知見と共有
  • プロダクトオーナーシップに関する社内勉強会をはじめました

なぜテストを書くに至ったか

  • NyAh
    • プレイベーとクラウド基盤へ移設する
    • JUGEM移設のPO的なポジション
  • JUGEMU
    • 10周年
    • PHP/MySQL/Ruby/Perl
    • 15個のリポジトリ
    • サーバのロールは18ロール
    • porral
    • JGセット(ユーザ毎のブログでWEBとDBの組み合わせ。39セット)
    • バッチ
    • 外部、内部連携用API
    • 顧客管理、etc
  • JGセットの移設
    • 数が多い
    • ユーザ影響が大きい
    • カスタマーサポートも巻き込む必要が

エンドツーエンドでテストやってしまおう

  • 新規構築のリリース前にしようするチェックリスト
  • 手動、目視の350

  • Trnip(Ruby/自然言語)

  • Capybara(バックエンド)

  • poltergeist(PhantomJS)

  • どうやってテストを書いたのか

  • キューカンバーをイメージすると良い

  • 自然言語でテストで書く事に意味があると感じている

  • 識別可能な名前をユーザ目線でつけれる、共通のワード

  • 複数の処理にまとめて日本語で名前をつけれる

  • 実例とテクニック

    • ステージング、リリース前の本番環境に実行する
    • DBに直接接続しない
    • debug用のステップを作る(よくおちる時の切り分け)
    • ステップを再利用できるようにする
    • 無料ユーザで1日の投稿上限数が決まっている場合
    • DBを直接触れないのでリセットできない
    • 普段は実行せずタグで制御
    • データのリセットは削除操作を繰り替えす
    • evaluate_scriptでjavascript経由でデータを受け取れる

取り組みのまとめ

  • よかった点
    • アプリケーションの動作をよく理解できる
    • stepをうまく作れるとシナリオをどんどん足せるので気持ちいい
  • つらかった点

    • javascriptを多用した記事エディタの難しさ
    • phantomJS or capybara-webkit
  • 全部テストいける?

    • どうしようもない部分は手で実行する必要があるとわかった
    • flashができない
  • 日本語で書けるというので外側がキレイになる

MogileFSをバックエンドとしたPrivate S3の作り方

インフラ編

private Cloud(openstack)に移行中

  • 主に画像、容量が大きい、各サービスが個別にもっている

    • 例えば30days alubum 2008年リリース / 750TB / 22億
    • 横断的なオブジェクトストレージが必要
  • 計画メンテを除いたサービス断はなし

  • 大規模運用で安定運用するのは甘くない。swiftは見送った

  • MogileFSは既存で使っていた

  • S3はコスト面で見送った。従量だけで月数百万

  • Baytと名付けた

ストレージサーバとフロントエンド

  • nginx + ngx_mruby
  • インターネット、インターナルからリクエストを受ける
  • apiにproxy
  • apiだけでは出来ないあれこれ

api

  • rails, unicorn

  • その前に既存システムの安定稼働(負荷が増える/パターンも変わる)を

  • メトリクスの充実化、可視化(munin/kibana/big query)

  • storageサーバの高集積化(47でバイス, 170TB, dev/starまである)

  • DB(MySQL)サーバのリプレース

    • 2台から3台
    • 5.1->5.5
    • MHA #### mogilefsdクラスタの強化
    • スペックアップと台数強化

mogilefsdがスケールしない

  • マスタープロセスとワーカを増やすpreforkモデル
  • 子がすくないうちは大丈夫
  • 増やすと全体的に不全状態に
  • renice -20 -p 親(プロセスの優先度を最大に)
    • 改善!
    • ただし、副作用が
    • 子が-20になる・・・
    • cronで親子のnice値の面倒をみることで解決
  • DBが刺さる問題
    • 5.5以降デッドロックが
    • 負荷がじりじり上がる
    • MHAマネージャからの
    • 元々使われてなかったindexが使われるようになった
    • drop

既存の画像配信の品質向上

  • 30%ほど高速化(資料参照)

gateway

  • 実URLへのreproxy処理
  • x-reproxyヘッダに実態のURLを2つ入れて返す
  • Gatewayが実態のあるURLに取りに行く
  • apiへproxy / ヘッダみて再プロキシ(re-proxy)
  • APIが返したヘッダとクライアントに返すようにしないといけない
  • APIに届かなかった場合のエラードキュメント(bodyだけでなくstatus codeも)

  • ngnx + mruby

    • server: bayt
    • リクエストUUIDの発行
    • HMAC認証をskipさせるヘッダを付与
    • ngx_mrubyのオーバーヘッドはほぼ無い
    • 太らない。活発な開発。劇的改善。

既存データのインポート方法

  • S3互換なのでクライアントの実装はそのまま使える
  • ETag(md5値)保存用のカラム追加
  • path(object key)カラムのサイズを255->512へ
  • 約9億レコードのテーブルへのALTERで最長25時間

今後の予定

  • 全サービス移行
  • マルチロケーション
  • 動的画像リサイズ機能

API編

  • オブジェクト->ストレージのデータ
  • MIMEだったりmysqlのデータ

  • GET/PUT/POST/DELETE

API設計

  • 新しくAPIを設計する?

    • 設計するのいやだな・・・(時間に耐えうる設計の重さ)
    • サーバサイド+クライアントの実装。多種多様な言語
  • S3互換APIにしよう

    • aws-sdk等OSSクライアントを利用可能
    • HMAC認証等、再実装が煩雑なものが揃っている
  • API実装もいろいろ

    • とはいえ、mogilefsをバックエンドとして流用できるものはさすがに
  • S3互換の制約

    • S3 APIができる事だけ提供
    • API自体の拡張は難しそう。SDKをいじるのはきつい
  • S3はREST APIのドキュメントが公開されている

  • さくらのオブジェクトストレージのリファレンスを先に読むとS3互換でよい

MogileFSクライアント、MySQLクライアント

  • HTTPのハンドリング
  • XMLのパース、HMAC認証

  • perl-catalyst APIの稼働実績がある

  • ペパボでperlの継続的開発ができるか

  • MogileFSクライアント

    • perlが本家、rubyはunicornの作者製
    • ラウンドロビン機能、高速に動く工夫の観点でrubyで

S3をリファレンス実装とするとバグレポートのやり取りが楽

  • HMAC認証はrubyに落とす
  • HTTPルーティングも作る。501 Not Imprementでちゃんと返すように。
  • metaテーブルを扱うのは1テーブルのみ
  • オブジェクトのCRUD
    • CRUDを1コントローラ、1トランザクションとして作る
    • S3仕様のレブポンスボディ(XML)

S3にディレクトリは無い。common prefixesです

  • list objectはLIKE検索とNOT LIKEと ">"で
  • rails-apiでダイエット
  • APIチューニング。XMLの生成がちと遅い
  • builder, nokogiri, oxで比較
  • oxが早い

  • GETはmogilefsのオーバーヘッドが乗るので遅い(100ms)程度

H2OとPHPの話

  • H2O
    • HTTPを早速サポートしている
    • デフォルトで高速 − まだ情報が少ない

高速でメモする余裕がなかった資料参照(?)

歴史あるwebサービスに携わって2年半の間に起きた事やった事

  • カラミーショップのエンジニア − 10年続くサービス − 対部分はPHP、railsでAPI、AngularJS

入社当時(2年半前)

  • Trac使ってた − レビューなし − SVN+git-svn
  • deployはwebistrano

  • 素のSQL

  • テストは特になし

GitHub Enterpriseを使うようになった

− 全社的に導入
− SVN+git-svnからの脱却
− レビューするようになった
− 順番にレビュー当番。共通認識。
− PSRを意識するようになった

  • PHP-CS-Fixer
  • githubで?w=つけるとレビュー便利だよ
    • javascriptの else if -> elseif

テストの導入

− E2Eテストが作られた
− RSpec + capybara
- ユニットテスト
- PHPUnit

composerが導入さられた

− ライブラリを探してバージョン管理
− deploy時にcomposerインストールする

ローカル環境が構築された

  • vagrant + puppet
  • 今まではMaglica上でそれぞれ作ってた

Wheneverでcronの変更を自動化

  • crontabを管理してくれるGem
  • コードにcrontabの設定を落とし込む。もちろんレビューも。

MySQLバージョンアップ

  • 4.0->5.1->5.6
  • Eloquent ORM(Larvelについてくる)
  • もう昔の素のSQLには戻れない

画像サーバをFTPからBaytへ

− BaytとはS3互換のストレージサーバ

尋常じゃない速度でドッグフードを食べる方法

  • sqaleというサービスの話
  • ruby on railsのアプリケーションを利用するためのプラットフォーム − ドッグフーディングとは − 自社の製品を自分たちで使ってより良くしていいくこと

− 良い所・便利なところが見えてくる
− 新機能が出たらすぐに自分の小さなアプリをデプロイ

ネットが切れたので途中・・・

今夜、インターネットの片隅で。 〜ウェブサービス開発ちょっといい話〜

  • カラミーショップ − ショッピングカートを全部作り直す − エンジニアが4人 − いい話一覧を話す

ショッピングカート

− 住所入力が2個あるとかも意味がある
− デジタルコンテンツだったらいらないのに
− その人に最適な情報入力を出せばいいじゃん
− 指針が大事。作る
− 哲学フロー開発

やぷしぃおもしろきかく!網羅パーソン総選挙

− 銅鑼で投票
− conoha(VPS)
- PHP/MySQL/KVSなし
− Nginx -> H2O

  • PHPでできないことは実装をあきらめる(速度重視と実装コスパ) − 1200万投票 − PHP安定してるじゃん − DBが太ってストレージが溢れる − 自動化してAPI叩きまくる人

OS X アプリケーション 開発普及活動

− Cocoa Programing
- 経験は1年、teitenをリリース
− WWDC2014に参加
− NextSTEP

資料参照の方が良さそう

仮想通貨自動トレード記 Part1 〜 国内Bitcoin取引所で裁定取引したら儲かるの? 〜

− JUGEMの開発している人
− もっと世の中に仮想通貨のすばらしさを広めたい
− Hubotとslack
− 2つの国内取引上の板の差を判断し約定させる
- bugで損した
− 改修してみた。またBugが。
− promise/async
- hubotの開発はcloud9
- slackは絵文字でわかりやすくしよう

YAPC::Asia Tokyoでベストトークを取る方法

− 2014のベストスピーカー
− トーク「したら楽しい」「自分の特になる」人は是非やるべし
− タイトル大事。すべてをかけよ。
− 前振り、対象者の想定、実際に話すトピック、予習できる何か、意気込み
− 話題になった勝ち、ではない
− 何人にリーチするか?
- あなたブランド

資料参照


パーフェクトPHP
パーフェクトPHP
posted with amazlet at 15.08.29
技術評論社 (2014-10-31)
売り上げランキング: 10,488


JANOG LT Night#1に参加してきたメモ

インフラエンジニアのスキルパターンを作ってみた話 DMM佐々木さん

  • DMM 1,400万突破!→中の人が大変になる

  • デザインパターンの手法を用いて、現場の要望

  • パターンは形(かた)

  • KJ法で分類

  • パターンに名前をつけてリバイスする

パターンを抽出してわかったこととサンプル

  • 技術的知識はそれほど必要なかった 3/43

    • 知識を自分自身のものとする
    • 基本的技術を正しく理解している
    • 隣接分野の知識を持っている
  • コミュニケーション

    • 大声出さない、怒らない
    • 積極的な声かけ
    • スルー力
  • リーダー

    • 属人化を防ぐ
    • 適切な権限委譲
  • 良し資質、正しい姿勢、仕事をうまくやるためのノウハウ

作ってて面白かったこと

  • 現場の問題がわかった
  • 意外な才能を発掘

ECNのあるネットワーク

使ってない理由

  • TCPだし
  • 帯域使ったもん勝ちな状況
  • ISPもやってない

現状

  • Alexaトップランクの56%がサポート済み
  • iOS9でデフォルトサポート
  • フィールドはECT/CE(DSCPの後。11で輻輳)
  • 設定の仕方はPolicy-mapとrandam-detect

まとめ

  • youtube/Netfixでは効果あり

サーバ屋がガチネットワークやったらこんな感じになった

所属: ssmjp

  • Vyosは使いやすい
  • BGPってなんだ?
  • はじめてのJUNOS
  • 知らない単語がやまもり出てくる
  • BGP Activeの罠

  • フローってなに?

  • BGPとかネットフローとかネット上に情報が少ない
  • あれ?サーバ屋のJANOG的なものないよね

Vagrantで試験ネットワーク構築してハマった話

  • コントロールの試験であれば仮想ルータが利用できる
  • 仮想なら自動化したいよね
  • ネットワークアダプタ作るときにsudo実行してた→対処
  • 共有フォルダも同様→対処
  • Vagrantfileで設定

トラッフィクの可視化

  • インシデントに気付く→内容把握→対策
  • キャプチャを引っ張ってきて統計と中身を可視化
  • ROODEの配合も見えた
  • TOP Nも見えた
  • 水責めも見えた(ランダムクエリ発見)

NetOps Coding#1 開催のお知らせ

ネットワーク運用自動化の勉強会はじめます!
10/30@ビッグローブ 19:00~21:00

参加登録は9月中旬以降

  • インフラ運用自動化の発表増えてきた
  • ネットワークは除く
  • 技術的な壁、そして組織的な壁
  • プログラミングのハードルの高さ、機種とOSの公開のしづらさ、リスク、開発担当アサインのむずかしさ
  • 知見の共有・モジュールの共同開発・事例

1000BASE-Tの次の一手

  • 10G BASE-T はまだまだ高い
  • Cat6からだし、100mだとCat6e
  • NBASE-Tアライアンス 2.5G/5G
  • Interopラスベガスで今年ブースでデモ
  • Interop東京でCat5eで5Gbps出る事をデモ。Award取った。
  • Cisco/Intel/Marvel/FreeScale/Aruba/Rucksなど

Routign Resilience Manifestoって知ってる?

  • 直訳:「ルーティングの正しさの維持に向けた声明」
  • .orgに情報あり
  • ルーティングセキュリティの話
  • A4で2ページくらいのお願い文章
  • 経路フィルタなどを適用して、IRRの連絡先を保つなど基本動作
  • Anti-spoofing/WHOIS・IRRの最新保持など
  • 日本語版を掲示します

うちもフルルートやめました

  • 自社内Filter方式「bgp community no-advertise」
  • ASBRではフルルート

なんで自社内Filter??
- origin asがトランジットASになる
- 思わぬASのトラフィック量変化に気づかない
- このprefixほしい!と思ったときの依頼が手間
- 網内の経路削っていたけど、増やすのが怖い

  • default + fll routeをもらう。主要な経路とdefaultは自社内に流す。
  • それならNetflowでもAS見えるよね
  • Flowspecとかの実装予定はルータの方がよさそう
  • FIBの更新待ちでBGP Update遅くならない?
  • Defaultが救ってくれるはず
  • ピアしているルータのトランジットが切れたら流用0です

  • BGP RIBには載せるけどFIBには載せない機能も。IOS SR/Juniper/Arista

  • 2ホップ先で全力キャプチャ→Flow案

OpenSSHの認証処理の流れから見るCVE-20150-5600

  • 好きなポート番号は22/tcp

  • CVE-20150-5600ってなに?

    • パスワード入力回数がサーバの制限を迂回
  • キーボード対話認証ってなに?

    • チャレンジ・レスポンス認証の1種類
    • Linuxの場合はPAM一択
  • MAXAuthTriesはデフォルト6回

  • LoginGraceTimeは2分
  • 認証処理はクライアントが主導権を握っている
  • ChallengeResponseAuthが有効だとPAM経由で有効に

CONBUの道具箱

  • ツールではなくリアル道具箱の話
    -余談:面白いプレゼン/つまらないプレゼンでトラフィックが変わる
  • カーペット用のケーブルガイド
    • マジックテープです。若干高い。なかなか売ってない。
  • しめしめ45(インシュロック・タイアップ・結束バンド)
    • APをくくりつける(楽譜置きのようなもの?)
  • ホワイトボードシート
    • 静電気なのでどこでも張り付く
  • ポストイットの印刷シール
    • すぐはがれる
  • タグ付きのケーブルバンド
    • マーカーバンド、マーカータイ、カラーエフ
  • ウォーキングメジャー

カンファレンスネットワークの物品借用心得

  • 当たり前のことをあたり前にできてますか?
  • 借りた時よりきれいに返そう
  • 資料参照

あるtsudaリストの憂鬱

  • なぜtsudaり?
  • クライアント:ツイタマ(ハッシュタグを自動でつけられる)、KuroTwi
  • ゆかりんのーとにまとめていた。togetter
  • 知り合いが増えた。助かりますという言葉も。
  • 疲れる。その分野の専門の方には議論に参加して!私も頑張る。

sensuでネットワーク監視をやってみた

  • 香川からきた
  • サーバだけでなくネットワーク監視
  • Nagiosの問題点を解決。Ruby製
  • 監視クライアントの自動登録、JOSN形式の設定ファイル、スケールアウトが簡単

  • Go言語でプラグインを実装(高速、簡単デプロイ)

  • 監視ツールはKibana
  • ダッシュボードは自動生成。Ansibleを使用(hico-horiuchi)

  • Sensu Deep talks #2 9/30 or 10/2

  • sensu-talks,connpass.com

JANOG37のお知らせ

  • 1/20~1/22 日本特殊陶業市民会館@名古屋
  • テーマ「みんなでつくるインターネット」
  • ベテランだけでなく初心者も積極的に
  • スタッフ募集は9月半ばから、会場運営・プログラム委員・企画編成委員

マスタリングTCP/IP OpenFlow編
あきみち 宮永 直樹 岩田 淳
オーム社
売り上げランキング: 134,980


OpenFlow徹底入門
OpenFlow徹底入門
posted with amazlet at 15.04.23
翔泳社 (2013-10-30)
売り上げランキング: 16,909

Trema Day #7 に参加してきた


http://trema.connpass.com/event/16844/

OpenFlow「で」おぼえるネットワーク

はじめに

  • 対象
    • ネットワークって何?って人にネットワークって何かを伝える
    • ネットワークに詳しい人は自分が説明する時のために

ネットワークのキホンのキ

  • 誰から誰宛に情報を伝えるもの(Src/Dst)
  • 伝える方法と伝える媒体
  • 音声もメディアを使うよね

  • 共有メディアで考えよう

    • ある人が喋るとみんなに聞こえる(flooding)
    • ある人が喋っていると他の人が喋れない(半二重)
    • 一緒にみんなが喋る(コリジョン)
    • 遠くの人に喋る(増幅)
    • 別の部屋にも伝達(L3)

デモ

今後ネタ

  • もっと同時に喋れる人を増やそう。共有メディアを狭めて同時に喋れる人を増やそう。

    -> ブリッジ

  • 誰がどこにいるか把握して直接くっつけてP2Pに
    -> スイッチ

  • ARP TableはknownとしてARP Request + Unicastコントロールルールを考えてみる

  • learning switch

  • 会話モデルで考えるNetwork Layer

ついにリリース! ニューTremaの紹介

ニューTremaの5つのポイント

  1. Openflow 1.3.4対応
    • trema run my_controller_rb --openflow13 -c my.conf
    • パケットライブラリ trema/pio参照
  2. Ruby化
    • 旧TremaはCをRubyでラップ
    • Ruby化で50,000行が5,000行くらいになった
    • インストールが簡単に。gccとかいらなくなった。openvswitchだけ準備でOK。
    • debugが楽に。Rubyのデバッガーだけでいい!
    • Pryでデバックしてみよう(demo)
  3. コントローラー連携
    • 既存コントローラーを組み合わせ高機能なコントローラーをつくる
    • 機能を拡張する
    • trema/routing_switch , Path Manager + trema/topology
    • def_delegators
    • VLAN的な動きはSliceable SwitchはPath Managerに機能を継承してあがればできる
  4. テスト
    • outputとして標準出力にログを吐く(Cucumber)
  5. ドキュメント
    • Project:Pio
    • APIドキュメントは整っている。
    • 本も出るよ。原稿は近日中に公開。
  • (嬉しい)バグ報告・パッチPR・本のレビュー

OVS拡張を援用して簡単なOpenFlow Programming(とPioの話)

trema/pio紹介

Pioとは?

  • Rubyのパケットパーサ実装
  • 使い易い、分かり易い
  • 1.0だけでなく1.3.2も実装されている

こんな感じ

  • openflow

    • Pio::FlowMod.new
    • Pio::ICMP::Request.new
    • Pio::Udp.new
    • Pio::SendOutPort.new
  • features_reply.ports

    - stateが人の目でみて扱い易い

Nicira拡張

Nicira拡張とは?

  • vender拡張
  • NXAST_LEARNが有名

openflowのキツいところ

  • controllerに転送処理を書く

  • controllerって

    • 宣言的な転送ルールを事前定義できればいいのに
    • BUMを例外として扱うべきか
  • packet_inはさせるな的な風潮

  • 例外になる転送処理(一部)

    • MAC Learning
    • ARP Respond
    • Routing & Egress interface lookup
    • BUM
  • NXM_NX_REG(idx)

    • Packet register fields
    • pipelineフィールドでpacket_inのmatchフィールドにも入る
  • LOAD_REG / MOVE_REG / OUTPUT_RGE

  • NXAST_LEARN フロー追加するアクション

作ってみる

  • learning-switch -> mac_learning(table=0)
  • isolated learning-switch -> ingress port(table=0), ingress vid(table=1), mac-filter(table=2), unicat-l2(table=3), bum-handling(table=4)

  • 中身は小さすぎて見えなった・・・。

  • 基本的にエッジで使うものと考えた方が良い。ARP__RESPONDERはBUM対策で便利。

いろいろなデバイスでOpenVNetを動かしてみようとした

  • tremaが使われているネットワークかそうかプロダクトOpenVNetとオーバーレイの話

  • Raspberry PiでTremaに挑戦した話

Edge Overlayのおさらい

  • 図で説明

  • openstack neutornと親和性が高い/同じ方向性のものが覇権争い

Open VNetとは

  • あくしゅさんが作ってる
  • trema-edgeを使って作られています
  • hypervisorの横にtremaベースのagent

作ってみた

  • 最先端(?)の某端末で試験
  • OVS / trema / open vnet
  • デモ(見ないとわからない)

Dive into wireless openflow!

  • なんか繋がらない
  • なんか不安定
  • なんか遅い
  • 無線のパケットを観測できるツールが必要
  • APに入ってれば・・・

  • openflow 1.3 + experimenter

  • IEEE802.11 / 6LoWPAN

  • デモ

    • 電波強度
    • AP
    • AP切り替え
  • openflow対応方法

    • netdev = openflow port
    • cfg80211系ドライバ
    • 物理インタフェースにnetdevを複数作れる
    • ARPHRD_RADIOTAP

Lagopusで遊ぶ(仮)

はじめに

  • Tremaで試すFirewallいいよね

    • ACLしんどい
    • シュミレーション、ACL自動テスト
  • openflow1.0ではL4ポートのrangeが使えない

Lagopasで試すFirewall

  • rangeどうする?

    • range -> bitmask変換のアルゴリズム
    • 0111 ~ 1111を再起的にマップを処理して{011*,1***}へ
  • TCP/UDPのポートどうする

    • 1.3.2ならmetadataコピーすればいいじゃん
    • maskでlookupできるし
    • 26万ルール・・・
    • Lagopasは100万を超えるフローを処理
  • 実装どうする

    • table0 : L4 srcをmetadataにコピー
    • table1 : L4 dstをmetadataにコピー
    • table2 : range変換。マッチしたら落とす。
  • ルールの追加/削除が動的にできる(priorityを考える必要あり)

  • iptablesより早いかも

  • Lagopusならなんとかしてくれるはず

近頃のDockerネットワーク

Dockerとは(略)

Software Infrastructure Plumbing

libnetwork

  • コンテナネットワークモデル
  • endpoint(veth)をsandbox(コンテナ)につけたり外したり
  • 起動 -> libnetwork driverがdocker0作成・NAT設定 -> Linux kernel
  • libnetwork driver(bridge / host / null / overlay / windows)
  • 中身があるのはbridgeとoverlayくらい

  • overlay driver

    • 1.8-experimental buildからdocker networkコマンドが追加
    • libkv(consul/zookeeper/etcd等と連携)がnetwork名やIPを共有
    • linux bridgeでbroadcast落としてる
    • デモ
  • VLANドライバ作ってみた

    • vlanidごとにbrを作成。bridgeドライバ流用できそう
    • デモ

コンテナをネットワーク

  • docker on cumulus linux
  • 制約を考えると、、RunC!
  • open container projextに準拠されたコンテナ管理ツール。Goでコンパイル。
  • デモ

質問

  • VNIは直書きできない?例えば箱物とかと組める?出口はgatewayの`コンテナ`を作るべし。
  • VXLANはmulticast / unicastのどちら?
  • ホワイトボックスにコンテナ入れるのは嬉しい?

クラウド時代のネットワーク技術 OpenFlow実践入門 (Software Design plus)
高宮 安仁 鈴木 一哉
技術評論社 (2013-01-09)
売り上げランキング: 93,728
次世代ネットワーク制御技術 OpenFlow入門
石井秀治 大山裕泰 河合栄治
アスキー・メディアワークス
売り上げランキング: 600,388
マスタリングTCP/IP OpenFlow編
あきみち 宮永 直樹 岩田 淳
オーム社
売り上げランキング: 305,938

OpenStack最新情報セミナー(2015年4月)のメモ

セミナー名:「OpenStack最新情報セミナー『OpenStack再入門』&『NFV/OPNFVとは何か?』」
日時:2015年4月28日(火) 昼の部 14時00分〜18時00分(受付13時30分より)
日時:2015年4月28日(火) 夜の部 18時30分〜20時30分(受付18時00分より)

http://virtualtech.jp/release/150427/

今さら聞けない人のためのDocker超入門

省略

OpenStackネットワーク入門

History of Neutron

  • 2010 Nova -> L2/DHCP
  • 2011 Quantum -> L3/L2/DHCP/FloatingIP/Security Group
  • 2013 Neutron -> + LBasS/FWaaS/VPNaaS/DVR/L3HA

Nova Network(Flat DHCP Manager)

  • Linux Bridgeを複数VLAN分用意する

  • Routing NAT

Quantum

  • Network Node(DHCP/外部接続/Metadata) / Compute(L2 Agent) / Controller

  • DHCP / Metadata Agent

Neutron

  • ML2 Plugin

    • Type Driver(GRE/VXLAN/FLAT)
    • Mechanism Driver(OpenvSwitch/LinuxBridge/Cisco)
  • XaaS Agent

Neutronでユーザができること

  • 仮想ネットワーク(L2)の作成
  • 仮想L3ルータの作成
  • ネットワークとルータの接続
  • ルータと外部ネットワークの接続
  • FloatingIP
  • VMのポートに対してSecurityGroupを作成し適用する

Neutron環境のパケットフロー

  • 図を見た方がよい

Network Namespace

command

  • ip netns
  • ip netns exec qrouter-*** ip link
  • ip netns exec qrouter-*** netstat -nr

パケットフロー

  • 図を見た方がよい

DVR(Distribute Virtual Router)

  • NeutronのL3 AgentをCompute上で動作させて分散する

  • パケットフローは図を見た方がよい

  • Floating IP は Floating IP用のNamespaceを通る

  • 現行ではSNATはNetwork NodeにあるSNAT namespaceを通る

OVS Network Node HA deployment

  • VRRP (Active/Standby)のみ対応

その他

  • Metadata Proxy/Agent <-> Nova Network

  • DHCPのNamespaceで取ってくることも可能

SDN

  • Brocade(Vyatta / VDX ..etc)

  • Cisco Nexus

  • Juniper Opencontrail

  • IBMSDN-VE

  • Midonet + Cumulus

Midonet

  • Midonet Agentは全体のtopologyを見てinbound時にすぐdropする
  • first packetの転送後はactionを記憶する
  • first packetの遅延はそういうこと

  • Provider Router / Tenant Routerなどの説明(割愛)

  • BGPでの冗長の説明(割愛)

  • midonetはBPDU透過

Recap

  • Overlay vs Underlay
  • Intelligence at Edgeの話
  • Network Stackの表がわかりやすい

OpenStack+Lagopusのご紹介

  • キャリアグレードの性能が必要
  • 10Gbpsワイヤーレート
  • Openflow 1.3.4対応(MPLS, PBB)
  • 1M フロールール
  • DPDK対応
  • dataplaneとI/O処理 Flow処理はスレッドを分離

  • lagopusのVM接続はこれからユースケースが出てくる

  • VM対応においてはLagopus以外のVMのI/Oをどうするかが課題

  • KVMベースのVMとして使用できるように

  • Intel DPDK <-> virtoio ユーザ空間で閉じるようにした

  • Unix domain socketを使って接続相手の状態検出

NFV/OPNFV概要

アーキテクチャ

  • VIマネージャにOpenstack/OpenDaylight/Controllerがあたる
  • 別途、VNFマネージャ、オーケストレーター

OPNFV

  • NFVIとVIマネージャを構築

エンジニアとしての注目ポイント

  • 資料に記載ありのため割愛

HPのOpenNFV戦略とMWCのレポート

  • 資料参照

IETFの標準化動向とNFVのユースケース

  • サービスプロバイダはAggredateルータで付加価値をつけたい
  • お客様ごとに設定や機器が必要
  • LB/FWなど

NFVで実現できそうなもの

  • ファンクションの割り当てをルール化
  • サービスのスケールアウト ...etc

OPNFV詳細編

活動方針

  • Phase1が終わっている
  • OPNFVの中にコードは持たない
  • 各コンポーネント内に実装する

プロジェクトの説明

  • 資料参照
  • テクニカルな話はなかった

マスタリングTCP/IP OpenFlow編
あきみち 宮永 直樹 岩田 淳
オーム社
売り上げランキング: 134,980


OpenFlow徹底入門
OpenFlow徹底入門
posted with amazlet at 15.04.23
翔泳社 (2013-10-30)
売り上げランキング: 16,909

ネットワークプログラマビリティ勉強会#4に参加してきた

Agenda

  • ソフトウェアSDN/OpenFlowスイッチ Lagopusとそのプログラミング
  • SDNを導入してみて思ったこと
  • LOOM OpenFlow Controller

  • ネットワークのテスト自動化

  • Openflow 超解釈

http://network-programmability.connpass.com/event/13103/

ソフトウェアSDN/OpenFlowスイッチ Lagopusとそのプログラミング

Agenda

  • Lagopusの概要
  • Lagopus(openflow)で遊んでみる

Lagopusの概要

snd?openflow?lagopus?

  • openflowの話とlagopusの位置づけ(省略)

やってみた

  • 会場内のトラフィック制御

    • meter
  • ブラジル〜日本間の映像伝送実験

    • IPごとのルート制御(宛先IPを書き換える)
  • iPoP2015での実証実験

    • packetの複製+MACとIP書き換え

Lagopusターゲット

  • NFVに対応する仮想スイッチ
  • 異種NWを接続するゲートウェイ

中身の話

概要

  • ネットに転がっているので省略
機能評価
  • Lagopusは評価高い
性能評価
  • 資料にグラフあり
  • Throughput vs flow
    • OVSとほぼ同じ性能(最近追いつかれた?)
  • 2015/2/1リリースでDPDK 2.0.0rc1にマージされた

  • ソースコードはlagopus.github.io

Lagopus(openflow)で遊んでみる

  • Flowを設計して動かしてみる
  • Openflowっぽいことをする

Flowを設計して動かしてみる

  • Lagpus
  • Ryu(app/ofctl_rest.py)
  • ofctl_script(flow addなど)

Openflowっぽいことをする

  1. つなげてみる
  2. 増やしてみる(VLAN)
  3. リファクタリング&デバッグ(ミラーリング)
  4. 騙してみる(DHCPサーバの共有)
1.つなげてみる
  • ns間をflowでつなげてみる
  • match inport, action outport
2.増やしてみる(VLAN)
3.リファクタリング
  • マルチテーブル、メタデータ
  • メタデータは次のテーブルで使える
  • ポートミラーリング、VLANミラーリング
  • debugテーブルでメタデータを用いて識別。複製。
4.DHCPサーバの共有
  • MACアドレスが既知前提だった。。

Flow設計の注意

  • パケットイン遅い
  • パケットコピーの処理は多い
  • ARP学習はパケットイン
  • フロー数増え過ぎ問題

Lagopusってすごい

  • 10Gbps, 1MFlow
  • OSS / x86

質問

  • マルチテーブルの名前ってどうなる?

    • ryuは名前でdefineできる
    • スイッチ側はidで認識
  • NFVってキーワード出たけど、Lagopus的にレイヤーあがってく?

    • 基本方針はopenflowに追従していく
    • セッション情報はコントローラにもたすことになるかな(個人的意見とのこと)
    • LagopusはFWやLBへのねじ曲げかな(個人的意見とのこと)

SDNを導入してみて思ったこと

導入の背景

  • 社内の某事業部がスポンサー(機材供給)になる関係でSDNのソリューションを国際展開

国際通信の問題

  • お隣との通信品質、改善には高いコスト
  • 2014年に地区全体で23回発生したネットワークダウンを削減したい

具体的な品質問題

  • 2014/2 海底ケーブルが一度に2カ所断
    • こういったトラブルに大してBCPを考慮したネットワークを作りたい
    • 日常的なインターネットVPNのパケットロスを抑えたい

施策

  • 落ちないネットワークを作る

    • 2種類の経路(トンネリング)を設置
    • 経路の状態を毎秒監視する
    • 10秒ごとの経路の品質評価と切り替え処理を自動実行
  • ポータル可視化

使用機材

  • Centech V330
  • Openflow1.3対応
  • GigabitEthernet 48ポート

コントローラー

  • RyuコントローラのREST APIをモニタサーバから叩く
  • 制御プログラム、コンソール画面はモニタへ

既存技術との比較

  • ルータが自律的に動くのに比べると問題発生時の見通しが良い
  • 経路上で問題が起きた場合の代替経路もあらかじめ決めておく必要あり
  • 可視化しやすい
  • 切り替えが高速
  • 即財に元の状態に戻せる

工夫したところ

  • コントローラーからの経路は2重化
  • 複数経路のステートフルFWのTCPホールパンチングの考慮(複製してエンドの手前で止めるようなことをした)

実装時のポイント

  • 内部実装のモジュールの影響範囲は最小に(コード重複よりも重視)
  • コンソールはシンプルに

導入後の感想

  • 実装、テスト、運用を一人で行うので、毎回避難訓練を行っている感じになる(強いオペレータになる)
  • SDNは入れてみないと便利さがわからない
  • 実際に入れてみると続々とアイディアが出てくる
  • 仕組みを理解しないと手が出せない

質問

  • テストって本番使った?

    • 実際に海外に機材持っていた
    • 試験用と商用は経路を分けて試験している
  • 例のFW通過はどうした?

    • バイパス経路と通常経路を用意している
    • 比較的問題は起きていない
  • 何を通信品質の監視につかった?

    • loss rate
    • latency

LOOM OpenFlow Controller

LOOM OpenFlow Controllerとは

  • infobloxとerlang solutionsのエンジニアが主に開発

Erlangって?

  • 平行プログラミングがやりやすい
  • 分散プログラミングがやりやすい

LOOM OpenFlow Controllerについて

  • ofs_handler:sync_send/2

  • Demo

ネットワークのテスト自動化

Network Programmabilityって?

  • SDN

    • OpenFlow
    • OpenStack
  • Configuration

    • NETCONF
    • REST API
    • SSH
  • Test automation

    • RSpec

Test Automationは今からでもできる

  • Ruby & RSpec

  • LBspec, infrastaster-plugin-firewall(自作)

  • 他にもRspec-ssltlsなども

  • 実際の画面は資料参照

資料はこちら

Openflow 超解釈

  • OpenFlow 1.5 Relesed

  • Packet Type Aware

  • OXM_OF_PACKET_TYPE(Matchの要素, Set-fieldフィールド)

  • Default = Ehetnet

  • packet_type(3, 80)とやるとHTTP


マスタリングTCP/IP OpenFlow編
あきみち 宮永 直樹 岩田 淳
オーム社
売り上げランキング: 134,980


OpenFlow徹底入門
OpenFlow徹底入門
posted with amazlet at 15.04.23
翔泳社 (2013-10-30)
売り上げランキング: 16,909

Docker Meetup Tokyo #4に参加(視聴)したメモ(後半)

前半はこちら
Docker Meetup Tokyo #4に参加(視聴)したメモ(前半)

感想

途切れ途切れなことが多く少し抜けがあります。資料がアップされたら復習したいです。監視については話をあまり聞かなかったので、もっと賑わってくれればいいと思ったところです。

Docker Meetup Tokyo#4 概要

■ Docker Meetup Tokyo #4
http://connpass.com/event/10318/

  • 17:25-18:05 LT (5min) x 8
    • Development and Deployment with Docker at Dwango
    • Google Container Engineについて
    • DatadogさんのLT
    • 共用スパコンシステム上でデータ解析 with Docker
    • TBD
    • Docker/ECSでIAMロールを利用する
    • GitのコミットごとにQA環境を作成するプロキシを作ってみた
    • tutumで雑に包んで雑にデプロイ

LT大会

Development and Deployment with Docker at Dwango

  • ニコニコのRecommendation API
  • コードレビュー/UnitTestは参照づらい。
  • 実際のテスト環境を簡単に作りたい
  • pull req出したらdockerでテスト環境をデプロイしてほしい
  • Jenkins Pull Request Builder
  • 「pull request/時刻」でコンテナ生成
  • git pullした時にbuildするrake taskを裏で実行
  • Deploy Manager WebUI

  • ログ収集はfluentd + 専用コンテナ

  • Deploy Manager WebUI(capistranoでStatic)

Google Container Engineについて

  • GKE (kubernetesの商用版)

    • サポート
    • microservice間の接続
  • fluentd + kubernetes

  • UI新しくなった

  • sample: wordpress構築

Datadog

  • Dockerがトラブった時にコンテナの状況が把握できているか?

  • Docker User Cases

    • 依存関係を排除したい
    • github workflow
    • statelessな部品を使う
  • コンテナを載せるインスタンスサイズ

    • m3.midiumが多い(?)
    • ちっちゃなワーカープロセスをがんがん回している
    • 1つのdockerホストに5つ平均
    • 調査した環境内では最高で12個くらいだった

    まだ導入は初期段階、いづれ増えていって平均10くらいになるのでは?

  • 監視を考えてdocker使おう

  • Dockerメトリクス cgroup or cAdviser

  • リソース:Memory / CPU / Network / IO

  • イベント:run & stopped

  • 自作派:cAdvisor / InfluxDB / Grafana

  • 企業:sFlow / DataDog

共用スパコンシステム上でデータ解析 with Docker

  • データの性質が変わるのに追随
  • ソフトウェアとワークフローを柔軟に変更したい
  • 既存のリソースを有効化(User管理・占有し続けたものの削除がしたい)
  • 0から作るのは嫌なので今日の聞いた話で作るつもり

DockerAPIをGoから使う

  • docker remote api
  • kurbernetesが使っているGoのクライアントライブラリ
  • デモ
  • コンテナの起動/停止/リストなど色々いじれるので自作派には嬉しい

Docker/ECSでIAMロールを利用する

  • Dockerコンテナのクレデンシャル設計(ブログ)
  • APIのtoken keyをどこにおくか

    • Dockerイメージに埋め込む
    • 環境変数(docker run -env)
    • クラウドサービスならクレデンシャルが外出しできる

課題

  • dockerコンテナとインスタンスで区別できない
  • docker単位の制御ができない

対策

  • MetaServerの自前実装(Qiita)
  • できた。MetaServer側でログを確認

今後の課題

  • 自前MetaServer自体をコンテナ化
  • コンテナごとにロールを管理したい

Mookさん GitのコミットごとにQA環境を作成するプロキシを作ってみた(仮

  • Dockerを使った爆速プレビュープロキシ
  • サブドメインにコミットハッシュやブランチ名を入れる
  • Qiitaにvagrantでの使い方がある
  • レビュー時にURLを貼るbot付き
  • 仕組み
    • コミットに対応したコンテナがあるか
    • なければリポジトリからソースを取得してdockerfileを元にデプロイ
    • ビルド中はクライアントにログを残す
  • ホスティング版のβを2月に予定している

tutumで雑に包んで雑にデプロイ

  • tutumuとは?

    • docker as a serviceのプロバイダ
    • Open Betaで無料
    • IasSのノードに対して、投下的にコンテナをデプロイできる
    • AWS,GKE,DigitalOcean,さくらVPS,ConoHa,オンプレなノードにも対応
    • 簡易的な監視、プライベートレジストリを無料で使える
  • なんでtutumu?

    • ダッシュボードがシンプルで使い易い
    • 特定のIaaSに縛られたくない
  • Dashbord -> Create Service -> image選択



Docker入門 Immutable Infrastructureを実現する
技術評論社 (2014-04-25)
売り上げランキング: 2,162

Docker Meetup Tokyo #4に参加(視聴)したメモ(前半)

感想

Dockerをサービスで使う際にオーケストレーションとかDockerだけで足りない部分はどうするの?というところについて皆さん検討しているようです。CoreOSなのかKubernetesなのかECSなのか、これからどうなるか気になります。

Docker Meetup Tokyo#4 概要

■ Docker Meetup Tokyo #4
http://connpass.com/event/10318/

  • 13:55-15:10 Talk (25min) x 3

    • @deeeetさん CoreOSの基礎/CoreOSに期待すること
    • @y_uuk1さん WebアプリケーションにおけるDockerパフォーマンスチューニング
    • @shot6さん Amazon EC2 Container Service(ECS)
  • 15:30-17:10 Talk (25min) x 4

  • @yuguiさん Kubernetesの機能とデモ、開発体制について

  • @ten_forwardさん cgroupによるリソース隔離入門

  • @yuryuさん RedHat atomic hostの話

  • @spesnovaさん Docker at Wantedly

(続く)

後半のLT×8は以下からどうぞ
Docker Meetup Tokyo #4に参加(視聴)したメモ(後半)

CoreOSの基礎/CoreOSに期待すること

  • PaaSサービスで使用

docker/CoreOS

Dockerが与えてくれないもの

  • オーケストレーション
  • サービスデリバリー
  • スケジューリング
  • 死活監視
  • ホスト環境/ツールの統一

CoreOSについて

  • datacenter as a computer

CoreOSで使われている技術

  1. etcd

    • 分散キーバリューストアクラスタの基盤
    • サービスの設定値の保存
    • CLI: set / get、APIもある
  2. fleet

    • Dockerコンテナのスケジューリングとデプロイ(最適な)
    • コンテナ状態の監視・フェイルオーバー
    • 各ホストのsystemdを束ねる存在、クラスタ
    • systemdのunitファイルの拡張版(X-Fleet)
    • 「MAchine Metadata」でmetadataを元にコンテナをデプロイ
  3. cloud-config

    • coreOSを初期化したりカスタマイズするためのファイル
    • 起動サービス、ユーザ、アップデート、metadataなどをymlで書く

CoreOSが解決すること

  • オーケストレーション

    • etcdにコンテナの情報を保存してサブスクライブする別のコンテナを準備
  • サービスデリバリー

    • fleet list init
  • スケジューリング

    • fleetでできそう
  • 死活監視

    • fleetが最低限みてる
  • ホスト環境/ツールの統一

    • cloud-configをprod/devと同じものを使う
    • (参考)Playstationの動画がいい

CoreOSの運用

  • CoreOSはOpenstackでもEC2でもdigital-oceanでも動くよ
  • 複数プラットフォームまたぐのを推奨

  • Auto Scale(webサーバ増やしてLBに追加)のデモ

    • etcdのディスカバリーサービス
    • IP/Portをetcdへ登録
    • LBはconfdを使ってetcdの情報+テンプレートを元に設定を動的に生成
  • TeraHome + CoreOS

  • Minimal RAMの使用量は114MB

  • CoreOSはどこまでMinimalにできるか

  • パッケージマネジャーもない

  • OS Update

    • OSアップデートは書き込み不可なRootFSを丸ごと入れ替える
    • ロールバック簡単
    • アプリケーションはdockerの入れ替え
    • 設定値 etcd

WebアプリケーションにおけるDockerパフォーマンスチューニング

  • Docker Egine上でアプリケーションを動かして性能劣化しないの?

  • Docker Demon / クラウドのマネージサービス

1. Dockerのパフォーマンスにおいて重要なのはなに?

  • Linuxカーネルの名前空間機能
  • LXC Linux Containersのフロントエンド

  • Linux Containers Overhead

    • 単体のLinuxカーネルで完結するので効率いい
    • パケット受信してkernel割り込みからユーザランドまでの2重処理がない
  • Docker Filesystem

UNION Filesystem

  • 差分管理とかいいよね
  • Writeは最上層へ書き込み、Read IOは探して層をもぐる
  • Copy On Write
  • Linuxカーネル標準のdevice mapperでも

Device Mapper

  • ブロックデバイスへのIOに暗号化、ストライプ、ミラーなどが可能
  • 特定のファイルシステムに依存しない

Volume

  • コンテナ間でディレクトリーを共有
  • Dockerグローバルな領域
  • Union FS部分を通らないのでオーバーヘッドが少ない
  • docker run -v /var/lib/mysql mysql

    • Docker Network

Portmapper(Goのパッケージ名から拝借)

  • ホスト側のiptablesでNAT
  • iptablesがない環境はdocker-proxyがユーザランドで動く

Host Networking

  • コンテナ用のNetwork Namespaceを使う
  • iptablesは不要/Portはホスト側のものを使用
  • docker run -net=host mysql
  • LXC1.0 or exec-driver=native

2.Docker化したISUCONでベンチマーク

  • ISUCON(Iikanjini Speed Contest)
  • ベンチマーカー -> Nginx -> App(+memcached) -> DB
  • m3.xlarge / Ubuntu 14.04 LTS Kernel 3.18.0 / Docker 1.4.1
  • 初期で38446で予選突破レベル

ベンチマーク環境
- NginxとMySQLをそれぞれDocker化
- Nginxだけ(-net=host/-net=bridge)
- MySQL(devicemapper/overlayfs/volume ON/OFF)

  • Nginxはbridgeを使った方がパフォーマンス落ちる(NATのため)
  • Nginxにパケットが集約するのでNAPTするオーバーヘッドが高い

  • MySQLはvolume切っても以外と早い。ReadI/Oはメモリ、Writeは最上層。

  • defaultと変わらない

NAPTの高速化

  • デフォルトのipatablesに「!-d 127.0.0.0/8」があった。つまりdocker-proxy使っている。
  • ベンチマークのソースをいじったらdefaultに合った

Amazon EC2 Container Service(ECS)

  • コンテナのマネージメント(今はpreview)
  • オーケストレーションやクラスタ
  • pure docker / vpcとかautoscaleとかも
  • limited previewでUSのみ

ECSの仕組み

Container Instance

  • EC2(VPC) / Docker / ECS agent
  • Amazon Linux / 他ECS agentが動けば
  • ECS Agentとは
    • Apacheオープンソース
    • go
    • Docker Hubにも登録されている

Cluster

  • リソースプール
  • リージョンに閉じている

Task

  • 関係するコンテナの集合
  • Container Instance上で稼働
  • Jsonで記述

    • 今までのAWSライクに使える(Security Group/VPC/MultiAZ)
    • パブリック・プライベートレポジトリ使える
    • ECS Command Line Tool
  1. Clusterを作成

    • ARN(Amazon Resource Name)
  2. EC2をContainer Instance として起動

    • CoreOSも使える
    • ブートストラップでECSの設定を書き込む
    • IAM profileでecsをつけておく

1と2をコマンドで用意しておけばOK

  • taskの走らせ方
    • ECSのスケジューラー
    • 手動

Kubernetesの機能とデモ、開発体制について

  • コンテナ渡すだけで動いてくれるDockerってすばらしい
  • だけど他の発表者と同様にオーケストレーションなど足りてないとろこはまだある
  • LB / デプロイ時のポート競合 / リソース / レプリなど自動がやってほしい

  • kubernetes(ギリシャ語)がやってくれる

    • Google主導
    • オープンソース*
  • Service / ReplicationController / Pod

  • Pod ≠ Container

  • Podは同じインスタンスで走らせるようにしたいコンテナの集まり

  • Podの定義はymlかjsonで書く

  • Client -> API -> etcd <- Controller Manager -> scheduler -> etcd -> Instance

  • etcdが中央にありそれを各コンポーネントがwatchして自分のtaskに関連するものを拾って制御をするイメージ(図があったので後日資料参照がオススメ)

  • Minion(インスタンス)でkubrenetdが動いている

  • Networking

    • 基本はiptables
    • kube proxyというアンバサダーがいる(etcdも見ている)
    • 一つのインスタンス内でポート衝突する可能性があるものも動く

まとめ

  • 開発は結構Active
  • 技術的にはオープンなものを選択(ex:Fluentd/kibana)
  • Well designed by Google

その他

  • Namespaces -> multitenat
  • internal DNS
  • Master as a Service(まだシングルなので)

cgroupによるリソース隔離入門

Cgroupについて

  • Namespaceとは?
    • OS/カーネルリソースを隔離
  • Cgroupとは?

    • コンピュータが持つ物理リソースを隔離
  • Cgroupとは

    • プロセスをグループ化
    • Cgroup内のプロセスに対してまとめてリソース隔離
    • tasksというファイルにpidを記入 / 稼働中に動的に変更

dockerでの使い方

  • dockerでの使い方

    • docker runのオプションかjsonファイル
  • cgroupから直接でも

    • dockerコンテナのcgroupの場所を見つけて直接書く
  • systemd配下で動いている場合

    • ユニットファイルにcgroupの設定を書いて起動
    • パラメータがまだまだ少ない

Docker on RedHat & Project Atomic入門

RHELとCentOSってどう違うの?

  • communityの主体の違い
  • リリースもメンテナンスの期間も違う
  • Fedora -> RHEL -> CentOS

RHELとDocker

  • RHELへの移植
  • systemd統合
  • SELinux対応
  • kubeの開発も参加
  • RHEL7で正式サポート(Extras)
  • 頻繁にrebase/リリースされるのでミッションクリティカル非推奨&サポート限定的(RHEL7.1から制限なくなる予定)
  • コンテナの互換性(サポートの観点)
    • x86_64のみ
    • RHEL6/7のコンテナのみ
  • コンテナの互換性(その他)
    • /procや/sysに依存するアプリケーションに注意
    • A kernel chenge breaks GlusterFS
    • firewalldをdisableにすること

Project Atomic

  • コンテナのためのホスト
  • CentOS Atomic HostとRHEL Atomic Hostはベースが違う
    • CentOSをベースにRHEL Atomic Hostの変更をマージ
  • 似てるもの
    • Ubuntu CoreはホストOSじゃない
    • CoreOSは良く似ている(CoreOSは一から/Atomicはベースがある)
  • RHELとAtomicの違い
    • yumがない
    • docker/etcd/kubernetesが標準で入る
    • cloud-init / cockpitも標準
  • リソース消費量の比較
    • CoreOS 46MB / Atomic Host 144MB
  • http://buildlogs.centos.org/rolling/7/iso/x86_64/
    • qcow2
    • metadata / cloud-init
  • vagrantで作ったよ(非公式)
    • vagrant init yuryu/centos-atomic
    • id:centosm password:vagrant
    • 20141129版を元に作っている

Docker at Wantedly

  • 最初はherokuを使っていた
  • 東京リージョンがないからパフォーマンスが・・・
  • AWS + Docker

色々試した

  • Elastic beanstalk
  • Centurion
  • Chef with Docker

これにした

  • Capistrano3
  • Chef
  • Packer

    Ubuntu / Private Registry(S3)
    dockerレジストリは認証回避と可用性のため全ホストに配備

  • Capistrano3でスタティックオーケストレーション

    • デプロイ
    • コンテナの操作
    • ホストの操作(scale)
  • デプロイ

    • Dockerfileでビルド
    • WebはNginxで新旧コンテナ切り替え
  • ChefとPacker

    • dockerのホストのAMI
    • 過去のレシピを再利用
  • Datadogでモニタリング

    • 何時何分にどのインスタンスでコンテナが立ち上がったか
  • Logentries gemでログ収集

  • Chef+PackerでなくDockerfileでビルド使用

    • ツールの観点
    • キャッシュがほしい
  • でもDockerfileで書くのはツライ

    • そういうアプリは、おそらくコンテナに向かない
    • そもそもDockerは小さいアプリをのっける向けと感じた

    「シンプルさを保つための制約を受け入れる」

  • Dockerホストは軽量にしよう

    • AMI焼いてdocker pullで結構大変
    • ホストに色々入れると単純に管理台数倍増する
  • herokuから学んだ事

    • on-offコンテナという使い方
    • 設定を環境変数で渡す
    • コンテナを載せる基盤に必要なもの
  • その他

    • 1コンテナ1プロセス
    • ログはstdout/stderrへ
    • モニタリング・ログ収集は専用コンテナでホストに入れると・・・
    • Private Registryはオススメしない(早いが不安定な経験)
    • capistranoは台数増えると遅い
後半のLT×8は以下からどうぞ
Docker Meetup Tokyo #4に参加(視聴)したメモ(後半)



Docker入門 Immutable Infrastructureを実現する
技術評論社 (2014-04-25)
売り上げランキング: 2,162