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

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

Jenkinsユーザ・カンファレンス2015東京に参加してきた

日本Jenkinsユーザ会主催のJenkinsユーザ・カンファレンス2015東京に参加してきましたので、そのメモです。登録人数は723人でした。400人くらい来てた(運営談)

< 概要 >

  • 日時 2015/01/11 (日)
  • 場所 法政大学 市ヶ谷キャンパス 外濠校舎
  • セッション/LT

http://build-shokunin.org/juc2015/

< タイムテーブル >

  • 12:10~13:00 基調講演
    • Jenkinsプロジェクトの現状とワークフロー
  • 13:30~14:20
    • 組み込み環境でのJenkinsによる多段階CIシステムask the speaker(川口耕介)
    • はてなにおける継続的デプロイメントの現状とDockerの導入
    • JenkinsとSeleniumの活用事例:試験自動化のプロジェクトへの導入
  • 14:30~15:20
    • JenkinsとPuppet+ServerspecでインフラCI
    • クックパッドにおけるJenkinsの活用
    • Jenkinsを使ったコンシューマゲームでのデプロイとテスト
  • 15:40~16:30
    • 「Infrastructure as a CodeにおけるJenkinsの役割」 〜環境構築も継続的インテグレーションを行う時代です〜
    • Jenkins導入する本当の理由を考えてみた
    • おばかXFDコンテスト
  • 16:30~17:20 LT大会

基調講演 Jenkinsプロジェクトの現状とワークフロー

参加できず・・・

情報募集中

13:30~14:20 はてなにおける継続的デプロイメントの現状とDockerの導入

< Agenda >

  1. はてなのサービス開発とJenkins
  2. ジャンプルーキーの開発フローとJenkins
  3. Dockerコンテナによる環境開発とJenkins

1. はてなのサービス開発とJenkins

利用しているサービスについて

  • ブックマーク・ブログなど

    • Perlで書かれている。そのためコンパイルは不要。
    • テストの実行や静的ファイル生成、デプロイなどでJenkinsを活用
  • Mackerel

    • サーバ管理サービス
    • Scaraで書かれている
    • 過去のプレゼン資料がsperkerdockに上がっている

Jenkinsの活用方法について

  • 各サービスとjenkins

    • サービスごとにJenkinsを準備
    • あるサービス用の変更による別のサービスのテストが動かなくなる
    • 関係者が少ない方がメンテしやすい
  • なんのためのJenkins??

    • ソフトウェア進化を継続するため
    • 意識しなくてもテストが実行される環境
    • 面倒な手順の自動化
  • 特にテスト

    • 開発は各自のマシンで
    • 本番に近い環境でのテストの実行と自動化のためにJenkins
  • Jenkins自体の管理

    • Chefで環境構築
    • プロダクトの本番サーバも同じ
  • Jenkins使用の方針

    • Jenkinsの設定を複雑にしない(秘伝のタレ問題)
    • シェルスクリプトをリポジトリに入れてJenkinsから誰でも実行できるように
  • スマホアプリとJenkins

    • AndroidはGradleが標準になり、ビルドとテストがしやすくなった
    • Android emulater pluginを使用

2. ジャンプルーキーの開発フローとJenkins

少年ジャンプルーキーって?

  • 2014年リリース
  • 漫画投稿サービス
  • 250万ダウンロード

開発規模と環境

  • 開発・運用:はてな
    - ディレクター1人、デザイナ1人
    - エンジニア数名(開発・運用)
    - 最近のはてなでの開発・運用を踏襲/改善

  • サーバサイド

    • perl
    • mysql
    • redis
  • フロント

    • htmlは生
    • TypeScript -> JS -> minified JS(ビルドプロセスが必要(開発者の手元+Jenkins))
    • LESS -> CSS(ビルドプロセスが必要(開発者の手元+Jenkins))
  • ビルドツールやデプロイツール
    ビルドツール

    • gulp(Node.jp)
    • TS -> JSやLESS -> CSS
    • JSテスト実行
    • 静的ファイルにダイジェストハッシュ付与 デプロイツール
    • デプロイ:Capistrano3(Ruby)
    • Github Enterprise

開発プロセス

  • 開発に用いるツール

    • 日記+Wiki
    • Slack
    • Trello
    • Github Enterprise
    • Jenkins
  • 開発プロセス

    • スクラム、2週間①スクリプト
    • リリースは毎週。とはいえ常に最新をリリースできるようにはしておく。
  • ブランチモデル

    • GitFlowに近い
    • master / staging /devel / features
    • 基本はdevelブランチから切る。緊急リリースはmaterからブランチを切る
    • Pull Requestはとりあえず開発中でも上げておく(議論のため)

開発時のJenkins

  • Jenkinsでやっていること

    • pushされるごとにライブラリ更新、JS minify
    • pushされるごとにテストとを実行
    • 動作確認のために開発用ホスト(doceker)にデプロイ
    • Github Plugin + script/jenkins.sh
    • GH;Eの通知はシェルスクリプト内
  • 課題

    • slackとGH;Eだけなので弱い?->XFD?
    • GH;Eへの通知がビルド処理の中にある

その他

  • 開発が完了したらコードレビュー(develブランチ)

    • Pull Requestに残す
    • レビュアにとってテスト結果がGH;Eで通ったかが確認できるのは楽
  • デプロイ

    • 本番リリース用のpull requestを作成(devel -> staging -> prod)
    • リリースチェックリストをpull request
  • 今後

    • Jenkins Workflow Plugin(scripted control flow、ユーザのインタラクション機能もある)を検討

3. Dockerコンテナによる環境開発とJenkins

背景と利用環境

  • 開発した機能の確認が遅れると困る

    • 無駄な手戻り
    • 開発スピードの低下
    • 特にUI/UX
  • 目的

    • 開発中の機能(develブランチにマージする前)の動作やUIを手軽に確認したい
  • Devhostは誰のため?

    • 開発者以外のチームメンバー
    • 社外のメンバー(ドメインを用意する必要性)
  • 既存の方法

    • 1ホストに複数環境をデプロイ
    • Nginxでドメイン別にポート番号ごとに振り分け
    • ポート管理が手間、ライブラリが共有・・・
  • DockerによるDevhost

    • Proxy用Plackアプリケーション+DockerAPIでポート番号を解決
    • ゲストは80番で待ち受け
    • ブランチからイメージをビルドする際にタグを付けておき、ドメイン名からブランチ名を取得->APIを叩いて対応するタグのポート番号を取得

やっていること

  • 課題と対策

    • dockerイメージのビルドに時間がかかる
    • Dockerイメージのビルドにキャッシュが効く(プロジェクト全体をコピーする前に初期化スクリプトを実行しておく)
  • Jenkins上でのビルドとデプロイ

    • Jenkins上でdocker build、docker rm -f(同じブランチのコンテナを止める)、docker run
    • 実際のコマンドはrakeタスクにしてある
    • タグを認識して変換する必要がある
    • ビルド開始方法は現在手動(ブランチ名はビルドパラメータで受け渡し)
  • なぜJenkinsでビルドするのか

    • 同じ環境でビルド処理を行わせたい
  • 今後

    • develブランチの手動でプロ胃
    • pull requestとの関連付けの強めたい(コメントから作成、マージ後に自動破棄)
  • その他

    • faviconで確認環境と他の環境を視覚的に変える

質疑応答

  • dockerでコンテナを作った時のテストデータはどうしているのか?

    • ->データベースは一つを共有。スキーマ変更もやっている。
  • Pull Request時に何をテストしているのか?

    • ->マージ後のものをJenkinsで実行はしていない

14:30~15:20 クックパッドにおけるJenkinsの活用

はじめに

宣伝:クックパッドのプレミアム会員になろう。レシピ意外にもサービス色々あるよ。

  • Ruby 2.0 + Ruby on Rails 4.1
  • Amazon Web Service

難しい事はしていないので、シンプルに説明をしていく

クックパッドでのJenkinsの使用環境

※ jenkinsではなく「おむきんす」を使用している

  • マスタースレーブ構成

    • Puppet / Itamae(独自:Lightweightなchefを目指す)
    • クラウドとオンプレミス(MAC OS/IOS環境のビルドなど)管理
    • ラベルでノードを管理
  • ci-slave-ruby

    • AWS上で6ノード、夜間は2ノードに縮退
    • rbenvを使用
    • テストはrspec
  • ci-slave-docker

    • microserviceを進めている背景
    • Go + Docker Engine用のCI環境
    • ビルド・テスト・レジストリ登録
    • GitHub Enterpriseを使用
  • ci-slave-android/ios

    • オフィスのサーバルーム
    • Androidは実機、Xcodeのバージョン管理で苦慮

なぜCIをしているのか?

< ユーザの要求を手元に届けるまでのサイクルを圧倒的なスピードで回したい >

  • CIで守れる価値
    1. 意図しない変更を予防
    2. 再現可能で自動化されている
    3. リソースや情報を集約できる

意図しない変更を予防

意図しない変更が起きた時に開発者がすぐ取り組む文化が必要。

  • CIツールの速度改善への取り組み

    • マルチプロセス化 -> 分散化 -> rrrspec(開発者ブログ参照)
  • 通知について

    • Failしたらhipchatへ通知する
    • その通知時にmentionも使っている
    • 誰がどこを失敗させたのか
    • HipChat Pluginではなくjenkins-hipchat-publisher(独自)を使用している。失敗時のメンションと成功ビルドを通知しない機能
  • 偽陽性を避ける

    • 時間に依存するもの
    • 組み合わせに依存するもの
    • 性能に依存するもの
  • 偽陽性があると・・・

    • エラーを気にしなくなってしまう
    • 本物のエラーを見逃してしまう
  • 偽陽性への対処

    • 最後に成功したビルドを夜間に繰り返し実行してみる
    • 翌月初にシステム時間を変更して実行してみる
    • 失敗したテストを再実行してみる

再現可能で自動化されている

  • CIでの自動化

    • テストの自動化
    • アセットの生成と管理
  • 1日あたり10デプロイくらい

  • デプロイはhubot経由で

リソースや情報を集約できる

  • アセットの生成と管理

    • コンパイルはrrrspecで実施している
  • 静的解析

  • 記録と可視化

    • GrowthForecastでsuccess rateなどを管理

質疑応答

  • デプロイが1日10回というのはどの範囲?
    • -> 全社でフロントだけでなくバッチなども含む

15:40~16:30「Infrastructure as a CodeにおけるJenkinsの役割」 〜環境構築も継続的インテグレーションを行う時代です〜

< Agenda >

  • サーバ構築フローとJenkinsの役割
  • サーバ構築の実践例とCI環境

サーバ構築フローとJenkinsの役割

  • 女性向け恋愛ソーシャルゲームの開発

    • 9コンテンツ/40サイトを自社運用
    • イベントなどで急増するアクセス
    • chefまわりは以前の発表がある。「slideshare autoscale ゲーム」で検索
  • 構成管理ツールだけに頼ってた時の課題

    • コードの複雑化
    • Cookbook同士が疎結合になってない / 自動化できないので漏れ発生
    • 実行結果を追跡しづらい
  • Provisioning Toolchainでサーバ構築を概念化

    • Bootstrapping
    • Configuration
    • Orchestration

各レイヤーでやっていること

  1. Bootstrapping

    • OSインストールとサーバ起動
  2. Configuration

    • ミドルウェアの設定
    • サーバの役割に基づいた設定
  3. Orchestartion

    • GlusterFSのClusterに追加
    • zabbix-agentの起動
    • jeninsからソースコードデプロイ
  4. Releasalization (独自)

    • 外部サービスとの連携
    • LBへの追加など
    • 変なサーバを本番環境に入れないようにする

Jenkinsの役割

  • ソースコードのデプロイ管理
  • ユニットテスト
  • サーバ構築の全体管理(new)

構築管理の変化

  • chefのRoleをJenkinsにパラメータとして渡しJOBの条件分岐
  • Build Flow Pluginを使用して可視化

サーバ構築の実践例とCI環境

各レイヤーについて

  • configration
    • chef-soloを使っている。jenkinsからknife soloを打つ。
    • jenkinsでGUI化できて楽になった
    • chef実行結果のログを集約
    • jenkins + serf(Go言語製オーケストレーションツール)
    • serf はnodeでやりたい処理を実行
    • jenkinsはイベント検知(serf join)とビルド
  • orachestation
    • configuration -> orchestrationの橋渡しもserf(+tag)
    • serfのtagはRoleをjson形式で要約
    • serf queryで成功/失敗の判断と処理中断
    • SSHが必要ない
  • Releasalization
    • orchestationの内容をテスト
    • 問題なければLBに追加して本番に入るようにしている
    • serverspec

課題と改善策

  • chefのテストが簡単に行えない問題
    • まっさらな状態がすぐ作りたい
    • serverspecですぐテストしたい
  • 改善策
    • dcoker + chef zero
    • jenkins pullrequest builder plugin
    • feature = role名
    • chef repoをmount

冗長化
- serfで通知
- jenkins起動
- EIP変更
- heartbeatなどは使用していない。100台のclusterで2秒(?)

Jenkinsでやってみた結果

  • JenkinsでChefの役割をシンプルにできた
  • ビルドの使い方次第でレイヤーが明確化される
  • JOBのログが残る/可視化
  • Build Flowを途中で止められる/不完全なものを本番に入れない

質疑応答

  • Auto Scaleは全体でどのくらい時間かかる?

    • 前は20分くらいかかってた。AWSはAMIにほとんど仕込んでいるので最新のコードを引っ張ってくるのみで5分くらい。
  • Jenkinsの冗長構成のデータ同期は?

    • GlusterFSはうまくいかなかった。Lsyncdを検討。今は同じ設定にしている。
  • 今後やりたいことは?

    • Autoscaleをもっと早くしたい

16:30~17:20 LT大会

1. Jenkinsを使った継続的Webセキュリティテスト

  • セキュリティテスト(脆弱性)

  • 継続的なセキュリティテストを実施すべき

  • vaddy

    • 無料プランのみ、何度でも
    • SQLインジェクション、XSS
    • Jenkinsプラグイン提供中
  • MeetUp 2/19(木) 新宿(doorkeeper)

2. Jenkinsおじさん、お堅いメガバンクに就職

  • 配布ソフト(有償)が参照するレポジトリにプッシュしている

  • 知識がない人でも簡単に作業が出来るようになった

3. Jenkinsおじさんと楽しい連携ツールたち

  • slackでビルド結果の通知を行う

    • Emojiで少し工夫
  • Gitlab

    • MergeRequestでmasterにマージする前にビルド、静的解析、テスト
    • GitLab MergeRequest Builder Plugin
  • deploygate

    • iOS/Androidアプリのテスト版アプリの配信
    • gradle-deploygate-plugin(proxy使えるようになった)

4. ゲーム業界の人がJenkinsさん3Dモデルで遊んでみた

  • 3Dロゴが出た
  • 3D空間に出してみたのデモ
  • 実際の画面でみないとわからないでのメモ断念。高級感溢れるおじさん。増えるおじさん。爆発するおじさん。REST API経由で赤く光るJenkinsおじさん。

5. CI”じゃない方”のJenkins

  • パッチ処理
    • 結果の履歴残る
    • cronより柔軟
    • ssh/scpも不要
  • 多システムの連携
    • APIあればコントロールできる
  • 負荷テストツール
    • インスタンス + jmeter

秘蔵のシェルスクリプトをJenkins登録して表に出そう。

プルリクとかGitHub Flowから勉強したい人はこちらから。
12436288584_94d6bc46d2_b.jpg
GitHubでチーム開発なんて考えだすと、commitやpushだけではレビューをする時にもどかしさを感じることがあるかと思います。 GitHubやGitコマンドは使ったことあるけど、Pull Requestは使ったことない。という人向けに簡単に使い方をメモしておきます。 GitHubの基本的な使い方から学びたい場合は…

Jenkins実践入門 ~ビルド・テスト・デプロイを自動化する技術 (WEB+DB PRESS plus)
佐藤 聖規 和田 貴久 河村 雅人 米沢 弘樹 山岸 啓
技術評論社
売り上げランキング: 32,766
チーム開発実践入門 ~共同作業を円滑に行うツール・メソッド (WEB+DB PRESS plus)
池田 尚史 藤倉 和明 井上 史彰
技術評論社
売り上げランキング: 5,606

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

ネットワークプログラマビリティ勉強会 2回目


ネットワークプログラマビリティ勉強会 2回目に参加した際のメモです。

  • 12/16
  • 19:00-19:05 はじめに
  • 19:05-20:00 結局、OpenStackとは何なのか?
  • 20:15-21:00 Docker入門: コンテナ型仮想化技術の仕組みと使い方

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

結局、OpenStackとは何なのか? ユーザ会 中嶋氏

今回は、OpenStackって何?という入門の話です。

■自己紹介

  • 日本OpenStackユーザ会長
  • @IT OpenStack超入門

■日本OpenStacckユーザ会とは

日本は世界で最も活発なコミュニティの一つ

  • 22団体
  • 約1800名
  • メーリングリスト
  • ローカライズ、翻訳

■OpenStackの概要

概要

  • OSSで開発されるCloudOS
  • IaaSからPaaS
  • Juno→Kilo
  • コンポーネント紹介(図)
  • 機能で分割したマイクロコード構造
  • Pythonで実装

ネットワーク例

  • Linux Bridge/OVSを使った場合のネットワーク例の紹介(Virtual/Physical)
  • 操作イメージ(Neutron API/SDK)

■エコシステム

どんな人が何のために使っているの?

当初、RackspaceがAWSに対抗するために始めたもの

  • Phase1 IaaS基盤
    • PublicをターゲットにしたIaaS基盤を作りたい
    • 研究開発に大規模なリソースを使いたい
  • Phase2 サービス基盤
    • 標準化による効率化を目的として、自社サービス基盤として採用
    • 現在、最も活発に活用されている領域
  • Phase3 クラウドネイティブ
    • フルプログラマビリティな世界

事例に関して

  • 公式サイトのユーザストーリーに事例が多数あり
  • Marketplaceでも登録したユーザを多数確認可能
  • BMW
  • BestBuyなど

ディズニーの話。

Good/Cheap/Fast→Fast/Fast/Fastへの転換。

■よくある質問

  • 一般的なk草加ソフトウェアとどう違うの?
  • どんなメリットがあるの?
  • 非IT企業で使うメリットは?
  • ミッションクリティカルなところは・・・

→回答略

■OpenStackって何なのか?

横に見るのではなく

  • 個別の技術要素(コンポーネント)をそれぞれ見ても・・・

縦に見る

  • 人での作業から解放する

抽象化と標準化を進めてくれる

抽象化と標準化を良しとする

  • 当然、HyperVでもVMWareでもKVMでも
  • 細かい機能を細かく使うのではない
  • 結果、完全な自動化を実現していこう

■まとめ

  • とりあえず触ってみる(BMWがそうだった)
  • OpenStack Days 2015 2/3-4
  • OpenStack Summit 2015/OctはTokyo

■質問

  • 規模が大きく開発チームが必要なイメージがあるがどうか?
    → 規模が大きいと大変。ただし小規模からスタートして行くことが大事である。

  • OpenStackを意識して開発しておくべきか
    → PublicからPrivateに持っていくのもAPIに準拠していれば簡単です。逆も簡単です。

  • IaaSからPaaSまでのPaaSってどのあたりまで?HerokuだとGitとの連携などあるけど。
    → プロジェクトが増えてきている。今回紹介したのはコアコンポーネントでPaaSでいうとHeat/Sahara/Troveあたり。

  • エッジオーバーレイの話はNeutronのAPIを持っているものが多いが、ネットワーク系のデファクトはNeutornになってきている?
    → NFVはOpenStackに近づいてきている。そんな印象を受けます。

  • NovaとNeutronが連携してサーバ/NWのプロビジョニングはKVMだけという話を聞いたが、他の事例は?
    → HyperVは7から盛り上がっている。VMは楽天が使っている。
    → VMだとNSX使わない場合、裏で作り込みが必要と聞いたが?
    → KVMが一番実績がある

Openstackはリソースを調達するとこまで、アプリケーションの管理はDockerという流れもある。

Docker入門: コンテナ型仮想化技術の仕組みと使い方 Cisco TAC伊藤氏


Dockerの基礎です。

  • Dockerって何?
  • なぜNEがDocker?
  • 基本的な使い方と応用例
  • 次回あれば:Dockerとその足回りと実運用

■自己紹介

  • Cisco TAC
  • Docker仕事ではなく個人利用
  • 最近作ったサービスとして「ゆくも」を紹介
  • 「ゆくも」の裏ではDockerが動いている

■Dockerの概要

Dockerって何?

  • Linuxで利用される仮想化技術です
  • コンテナと呼ばれる仮想化技術を使う

コンテナ型って何?

  • OSの一部のみを仮想化
  • LinuxのKernelの機能でリソースを分離
  • JVMとJarに近い
  • 実際はnamespacesやcgroupsをまとめている

Infrastructure as a Code

  • サーバのイメージがCodeとして扱われる
  • Codeをコンテナとしてイメージ化
  • コンテナ切り替えが容易

Dockerの強み

  • OS on OSではないのでオーバーヘッドが少ない
    • Linpackを使った演算性能測定でNativeとパフォーマンスが近い結果が
  • 「コード」でインフラの構成を管理

なぜNetwork EngineerがなぜDockerをやるか

  • ネットワーク機器への接続を意識する
  • Ambassadorパターン
  • コンテナがネットワーク機器の内部で使われる可能性があるよね
  • トラフィックジェネレータとしてのDocker

■Dockerの使い方のデモ

Dockerのコンポーネント

  • Docker Client:Daemonに対して命令を与える
  • Docker Daemon:コンテナを実際に動かす
  • Docker Repository:イメージを保存

Dockerの状態遷移

  • running
  • paused
  • stopped
  • image
  • removed

Dockerのイメージ取扱い

  • docker run
  • docker build
  • docker commit
  • docker push
  • docker pull
  • docker rmi
  • import

Docker Demo

  1. まずはdocker searchコマンドでイメージを探す

  2. docker pullでイメージを取ってくる

  3. docker imageで確認

  4. docker run ubuntu:14.04 echo “hello docker”で応答を確認

  5. docker run ubuntu:14.04 cat /etc/issue でOSも確認

  6. docker run ubuntu:14.04 cat uname -a とするとカーネルは同じに見える

  7. docker run -t -i ubuntu:14.04 /bin/bash でシェルに入る(tty/interactive)

  8. 新しいコンテナを立ち上げると別のコンテナでの操作は見えない

  9. docker run -d -p 80:5000 コンテナ名 で外と中をマッピングして導通確認

  10. docker ps で状態確認 -aで停止中のコンテナも表示

  11. docker stop / start の紹介

  12. docker commitでイメージ化(IDを指定)

  13. docker pushでレポジトリへ追加する

  14. docker fileからイメージを作成。Scriptファイルのようなもの。docker buildで実行。

■Dockerのネットワーク

Dockerのネットワーク構成

  • docker0 Bridgeにvethが接続されている。
  • vethの先にコンテナのeth0が接続
  • eth0は不定のIPが割り当てられる
  • 物理NICでNAPT

DockerのPort Forwarding

  • 外部からのNAT越えはポートフォワードする
  • docker run -p Port_X:PORT_Y

DockerでのIP不定対策

  • IPではなく「Link」
  • –linkを使用
  • envで参照可能

3階層の例

  • Nginx Python MySQL
  • 階層間の接続には必ずLinkを使う
  • イメージ化しましょう
  • 各コンテナにサービスをすべて入れて、Nginxでドメイン振り分け

■まとめ

  • 従来の仮想化と違いリソースを効率的に利用
  • 環境を適度に分離する
  • 不変なイメージをコンテナ化する
  • 大規模環境ではKubernetesのようなオーケストレーションツールで管理する必要性が高まる
  • Dockerを挟むとベンダ依存が減る
  • コンテナ間の連携は苦労する。DNSによる連携の補足スライドあり(パフォーマンス面で難あり)

質問は大分聞き逃したので省略します・・・

次回はOpenDayLightの話を予定しています

その他のセミナー参加メモ


紹介がありましたがOpenStackは日本語の参考書も出ています。勉強しておいた方が良いと思います

オープンソース・クラウド基盤 OpenStack入門 構築・利用方法から内部構造の理解まで
中井悦司 中島倫明
KADOKAWA/アスキー・メディアワークス
売り上げランキング: 33,738