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

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は台数増えると遅い