雑多なメモ帳

Home » All posts

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

in docker, nfv, Openflow, OpenStack, SDN, セミナー - on 20:31

セミナー名：「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編

posted with amazlet at 15.04.23

あきみち宮永直樹岩田淳
オーム社
売り上げランキング: 134,980

Amazon.co.jpで詳細を見る

OpenFlow徹底入門

posted with amazlet at 15.04.23

翔泳社 (2013-10-30)
売り上げランキング: 16,909

Amazon.co.jpで詳細を見る

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

in Openflow, SDN, ネットワークプログラマビリティ - on 21:22

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っぽいことをする

つなげてみる
増やしてみる(VLAN)
リファクタリング&デバッグ（ミラーリング）
騙してみる(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なども
実際の画面は資料参照

資料はこちら

Network Test Automation 2015-04-23 #npstudy from Hiroshi Ota

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編

posted with amazlet at 15.04.23

あきみち宮永直樹岩田淳
オーム社
売り上げランキング: 134,980

Amazon.co.jpで詳細を見る

OpenFlow徹底入門

posted with amazlet at 15.04.23

翔泳社 (2013-10-30)
売り上げランキング: 16,909

Amazon.co.jpで詳細を見る

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

in docker, セミナー - on 19:27

前半はこちら
■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を実現する

posted with amazlet at 15.02.04

技術評論社 (2014-04-25)
売り上げランキング: 2,162

Amazon.co.jpで詳細を見る

Software Design (ソフトウェアデザイン) 2014年 12月号 [雑誌]

posted with amazlet at 15.02.04

技術評論社 (2014-11-18)

Amazon.co.jpで詳細を見る

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

in docker, セミナー - on 18:00

感想

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で使われている技術

etcd
- 分散キーバリューストアクラスタの基盤
- サービスの設定値の保存
- CLI: set / get、APIもある
fleet
- Dockerコンテナのスケジューリングとデプロイ(最適な)
- コンテナ状態の監視・フェイルオーバー
- 各ホストのsystemdを束ねる存在、クラスタ
- systemdのunitファイルの拡張版(X-Fleet)
- 「MAchine Metadata」でmetadataを元にコンテナをデプロイ
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

Clusterを作成
- ARN(Amazon Resource Name)
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を実現する

posted with amazlet at 15.02.04

技術評論社 (2014-04-25)
売り上げランキング: 2,162

Amazon.co.jpで詳細を見る

Software Design (ソフトウェアデザイン) 2014年 12月号 [雑誌]

posted with amazlet at 15.02.04

技術評論社 (2014-11-18)

Amazon.co.jpで詳細を見る

道玄坂LT祭りに参加してきた

in aurora, presto, REHL7, セミナー - on 22:44

前半だけしかも途中参加ですが少しだけ参加してきましたのでメモです。

■ 道玄坂LT祭り(ミドル・インフラ)
https://atnd.org/events/59894

「ミドルやインフラもカジュアルに語りたい」ということでLT祭りでした。

さくっとわかるAurora

クラウド用に再設計したリレーショナルデータベース
MySQL 5.6.1.0ベース
US East Limited Preview
RDBとストレージ部分が明確に分離
キャッシュの層は独自
ログストレージは独自実装
複数AZをまたいで共有型
S3への高速差分バックアップ
AZは3つ全部使う
RDSとの違い。実行容量が課金対象。
キャッシュがMySQLでなく独自で抱えているので、リカバリも高速
最大レプリカは15個まで（RDSは5個）
レプリカラグは約10〜20msec
キャッシュのヒットRatioも見れる。取れるメトリックスが増えた。

Presto＋MySQLで分散SQL

workerがconnector pluginを経由してデータストアをつつく
connector pluginはいろいろ使える（Hive・MySQL・PostgreSQLなど）
connector pluginは複数合わせ技で使える
demo:prest+MySQL+HiveでJoin
prestogres query -> presto -> Hive/MySQL
presto meetup 1/20

RHEL/CentOS 7 に移行しよう！

OSメジャーバージョンアップは宿命
新機能XFS/GRUB2/Network Manager/firewalld/OpenLMIなど
systemdを覚えないとREHL7は使えない？→serviceコマンドも使えるよ
徐々に新機能を使おう（無理して使わなくて良い）
- XFS->ext4
- systemd,journald->OK
- GRUB2->調べながらつかう
- ifconfigなど互換パッケージ使おう
- NW,FW->Disable
- OpenLMI->使わなくても支障なし
- 大量の更新されたパッケージ->コンテナをうまく使おう。違うOSバージョンの混在が可能。
むしろ性能向上に目を向けよう
- スケジューリングよくなった
- bonding強化
- 電力利用効率向上
- 40GbE
- bondingの強化などなど

その他の勉強会参加エントリーです。

日本OpenStackユーザ会(Neutron deep dive)に参加してきた - ぽぽぽぽーんのネットワークとOSS

第20回の日本OpenStackユーザ会(Neutron deep dive)に参加してきた際のメモです。当日取ったメモなので荒いです。日本仮想化技術さんのセミナーにも参加しました。 OpenStack最新情報セミナー＠渋谷に参加してきた | komei.com 12/1 Openstackユーザ会 19:00～ …

Jenkinsユーザ・カンファレンス2015東京に参加してきた | ぽぽぽぽーんのNWとOSS

2014/12/04＠日本仮想化技術のOpenstack最新情報セミナーに参加しました。Ustreamでの参加だったので少し途切れている部分があるかもしれません。

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

サーバ/インフラ徹底攻略 (WEB+DB PRESS plus)

posted with amazlet at 15.02.04

伊藤直也片山暁雄平山毅舟崎健治吉荒祐一今井雄太八木橋徹平安川健太宮下剛輔田中慎司久保達彦道井俊介飯田祐基桑野章弘松浦隼人中村俊之福永亘杉山仁則
技術評論社
売り上げランキング: 10,164

Amazon.co.jpで詳細を見る

サーバ/インフラエンジニア養成読本ログ収集~可視化編 [現場主導のデータ分析環境を構築!] (Software Design plus)

posted with amazlet at 15.02.04

鈴木健太吉田健太郎大谷純道井俊介
技術評論社
売り上げランキング: 12,879

Amazon.co.jpで詳細を見る

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

in docker, jenkins, セミナー - on 17:02

< 概要 >

日時 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 >

はてなのサービス開発とJenkins
ジャンプルーキーの開発フローとJenkins
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万ダウンロード

開発規模と環境

開発・運用：はてな
-　ディレクター１人、デザイナ１人
-　エンジニア数名（開発・運用）
-　最近のはてなでの開発・運用を踏襲／改善
サーバサイド
- 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での自動化
- テストの自動化
- アセットの生成と管理
１日あたり10デプロイくらい
デプロイはhubot経由で

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

アセットの生成と管理
- コンパイルはrrrspecで実施している
静的解析
記録と可視化
- GrowthForecastでsuccess rateなどを管理

質疑応答

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

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

< Agenda >

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

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

女性向け恋愛ソーシャルゲームの開発
- 9コンテンツ／40サイトを自社運用
- イベントなどで急増するアクセス
- chefまわりは以前の発表がある。「slideshare autoscale ゲーム」で検索
構成管理ツールだけに頼ってた時の課題
- コードの複雑化
- Cookbook同士が疎結合になってない / 自動化できないので漏れ発生
- 実行結果を追跡しづらい
Provisioning Toolchainでサーバ構築を概念化
- Bootstrapping
- Configuration
- Orchestration

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

Bootstrapping
- OSインストールとサーバ起動
Configuration
- ミドルウェアの設定
- サーバの役割に基づいた設定
Orchestartion
- GlusterFSのClusterに追加
- zabbix-agentの起動
- jeninsからソースコードデプロイ
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にほとんど仕込んでいるので最新のコードを引っ張ってくるのみで５分くらい。
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から勉強したい人はこちらから。

GitHubでPull Requestを使わないのはもったいないと思ったので簡単な使い方をメモしておく - ぽぽぽぽーんのネットワークとOSS

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

Jenkins実践入門　～ビルド・テスト・デプロイを自動化する技術 (WEB+DB PRESS plus)

posted with amazlet at 15.02.04

佐藤聖規和田貴久河村雅人米沢弘樹山岸啓
技術評論社
売り上げランキング: 32,766

Amazon.co.jpで詳細を見る

チーム開発実践入門 ~共同作業を円滑に行うツール・メソッド (WEB+DB PRESS plus)

posted with amazlet at 15.02.04

池田尚史藤倉和明井上史彰
技術評論社
売り上げランキング: 5,606

Amazon.co.jpで詳細を見る

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

in docker, OpenStack, セミナー, ネットワークプログラマビリティ - on 21:14

ネットワークプログラマビリティ勉強会 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が一番実績がある