- Docker Cluster Management周りについて調査
- Google Container Engine的なマルチテナントで中,大規模なものを構築することを想定
- Docker Management系のOSSがいっぱいのっている
- http://stackoverflow.com/questions/18285212/how-to-scale-docker-containers-in-production
- Cloud Foundry | |
- Cloud Foundry BOSH | |
- Diego | |
## Cloud Foundry | |
- OSSのPaaS基盤 | |
- Dockerコンテナのデプロイができるというわけではない | |
- herokuのようにソースコードをあげるとデプロイできる | |
- デプロイをWardenという独自コンテナ形式で行う | |
- コンポーネント | |
- Router | |
- Controller | |
- HealthMonitor | |
- NATS | |
- 参考資料 | |
- http://www.slideshare.net/jacopen/cloud-foundry-33851040 | |
### Router | |
- https://github.com/cloudfoundry/gorouter | |
- 4025行(Godepsと_test.go以外の*.go) 2015/01/17 | |
- 全てのリクエストがここを通る(API, サービス) | |
### Controller | |
- https://github.com/cloudfoundry/cloud_controller_ng | |
- 10970(app/*.rb) 2015/01/17 | |
- 10918(lib/*.rb) 2015/01/17 | |
### DEA | |
- https://github.com/cloudfoundry/dea_ng | |
- 6377(lib/*.rb) 2015/01/17 | |
- 11596(*.go) 2015/01/17 | |
- Wardenコンテナの作成など | |
### HealthMonitor | |
- https://github.com/cloudfoundry/hm9000 | |
- 5588行(*.go) 2015/01/17 | |
- 役割 | |
- あるべき状態の管理 | |
- 現在の状態の管理 | |
- 状態の差異の検出と解決 | |
- インスタンスの管理 | |
- etcdに依存 | |
- stateの管理 | |
- 分散 | |
### NATS | |
- https://github.com/apcera/gnatsd | |
- 6257行(*.go) | |
- 各コンポーネント間の通信はNATS経由で行う | |
- NATSが死ぬと全て止まる(?) | |
- pub/subモデル | |
- クラスター化できて、1台落ちても大丈夫 | |
- 500万msg/secで処理できる(らしい) | |
## 参考資料 | |
- http://www.atmarkit.co.jp/ait/articles/1206/22/news141_2.html | |
- Cloud Foundryのソフトウェアスタック(日本語) |
Docker社のDocker Cluster Management系のOSS | |
- Docker Machine | |
- Docker Swarm | |
- Docker Compose | |
### Docker Machine | |
- https://github.com/docker/machine | |
- 155546行(*.go) 2015/01/17 | |
- 8186行(/drivers/*.go) | |
- Dockerのホストをprovider(OpenStackとか)を指定して新規構築できる | |
### Docker Swarm | |
- https://github.com/docker/swarm/ | |
- 3945行(*.go) 2015/01/17 | |
- dockerが起動しているpoolの中からスケジューリングしてコンテナを起動してくれる | |
- swarm createでクラスターを作成 | |
- swarm joinでクラスターに対してホストを追加する | |
- 起動するときはdocker run(swarm APIを通して?) | |
- 起動するノードを制限するFilter機能がある(Constraint, Port, Helthy) | |
- Constraint Filter | |
- ノードでdocker daemonを起動するときに--labelで名前をつけておく(storage=ssd, storage=hddとか) | |
- docker runのときに環境変数(-e)でconstraint:storage=ssd をつけるとlabelがstorage=ssdのノードだけで起動する( | |
- Port Filter | |
- docker run -P でexposeするポートが被らないように分散してくれる | |
- `-P 80:80`で複数回実行すると既にそのポートを使っているノード以外で起動する。ノードが足りないとエラー | |
### Docker compose | |
- YAMLに同時に起動するコンテナの定義をかいてdocker upすると全部立ち上がる | |
- 単一ホストでの話だけでscaleoutや分散的なものはなさそう | |
- alpha(2015/01/17) | |
## 所感 | |
- docker単体では運用にのせるときに辛いところをパーツ単位で提供している | |
- パーツ単位で提供しているので組み合わせる必要がある | |
- それぞれがまだ実験的な雰囲気 | |
- (swarmに?)FailOver機能がないので規模が大きくなるとまだ辛い | |
- 小規模にやるならパーツにわかれていることが逆に良さそう | |
## 参考資料 | |
- http://blog.docker.com/2014/12/announcing-docker-machine-swarm-and-compose-for-orchestrating-distributed-apps/ | |
- Docker社のアナウンス記事(英語) | |
- http://jaco.udcp.info/docker-machine-and-swarm/ | |
- 使ってみた解説記事(日本語) |
# Fleet | |
Docker Incが開発している分散initシステム。 | |
etcdとsystemdを組み合わせてクラスタレベルでプロセス管理ができるようにしたもの。 | |
systemdに依存しているのでdockerコンテナを起動させるだけでなく通常のプロセスも管理できる。 | |
## 構成 | |
構成要素はかなりシンプル。必要なものは3つだけ。 | |
- fleetd | |
- etcd | |
- systemd | |
### fleetd | |
- golangで実装されているのでバイナリはfleet本体だけ | |
- 各サーバにデーモンとして起動しておく必要がある | |
- マスターノードはなく自律分散型 | |
- 外から操作する場合はどのノードに対して操作しても良い(HTTP) | |
- 全てのデータや各ノードの状態などはetcdに保存 | |
### systemd | |
特にいうことは無い。systemdの機能をそのまま使っている。 | |
## 機能 | |
- Unitをクラスタ内のノードのどこかで起動させる | |
- Unitをクラスタ内のノードの全てで起動させる | |
- Unit(systemdのジョブ)を外から追加できる | |
- systemdのコマンドでできることは外からもできそう | |
- statusでサービスの状態確認 | |
- journalでログ見る | |
- ノード毎落ちた場合のリスケジューリング | |
- Unitの依存に応じたスケジューリング | |
- 起動するノードの指定 | |
- 起動する順番 | |
- 同一ノードで動作させる/させない | |
- fleetd起動時にそのノードのmetadataを指定できる | |
- `metadata="region=us-west,az=us-west-1"` | |
## Systemd Unit | |
- 基本的には通常のSystemdのUnitと同じ | |
- X-Fleetという項目に依存をかける | |
- MachineID: 起動するノード | |
- MachineOf: 同一ノードで起動するUnit | |
- MachineMetadata: metadataの条件にあうノードで起動する | |
- Conflicts: 同一ノードで起動しないUnit | |
- Global: 全てのノードで起動する | |
## 所感 | |
- 構成がシンプルで特に複雑な要素もないので導入しやすそう | |
- Systemdをクラスタ化というコンセプト通り、Systemdの知識だけしか必要なさそう | |
- Dockerベースで考えるにはもう一つ上のレイヤで管理する仕組みがあってもよさそう | |
- クラスタ内でN台起動という条件はないのかな?落ちたら指定台数に合わせるように調整してくれるようなもの | |
- fleetctl startでN回実行すると似たような挙動になるのかもしれない | |
## 参考資料 | |
- https://github.com/coreos/fleet | |
# Google Container Engine | |
Googleが提供しているDockerコンテナを実行・管理するサービス。 | |
基盤としてKubernetesを利用している。 | |
現在はアルファリリース。 | |
## Overview | |
- Cluster | |
- 1つのmasterと複数のworkerノードで構成される | |
- クラスタ構築時にmasterとworkerが作成 | |
- privateネットワーク内に構築 | |
- Node | |
- ノードは単一のクラスタに紐づく | |
- ノードの数は必要なリソースに応じて変わる | |
- (alphaでは)ノードの数はクラスタで固定。最大は50 | |
- (alphaでは)クラスタ内のVMインスタンスの種類は固定 | |
### リソースの単位 | |
- Project | |
- Projectが一番大きな単位 | |
- GCP全てのリソースがProjectに紐づく | |
- https://cloud.google.com/compute/docs/projects | |
- Zone | |
- us-central1-aとかのデータセンター指定 | |
- https://cloud.google.com/compute/docs/zones | |
- Cluster | |
- Zoneをに紐づく | |
## Container VM | |
- Dockerコンテナはコンテナ用に最適化されたVM上で実行される | |
- Debian7イメージに以下の変更を追加したもの | |
- Dockerがプリインストール | |
- OSS metadata framework(謎, gcpのツールかな) | |
- Kubenetes, Kubelet | |
## 所感 | |
- クラスタ毎にmaster/workerのセットを作っているのはまだスケールに問題あるからだろうか | |
- まだalphaだからクラスタ構築時にノード数が固定としても、今後もkubenetesのバージョンも固定になるのかな | |
- 実機ではなくVMベースなのはSSHでログインさせるためだろうか | |
- instances listでIPまでわかるからログインできるのかも | |
## 参考資料 | |
- https://cloud.google.com/container-engine/ | |
- https://cloud.google.com/container-engine/docs/?hl=ja |
** Kubernetes | |
- 外部ソフトウェア | |
SkyDNS | |
etcd | |
cadvisor | |
heapster | |
- Resources | |
- Pod | |
- ReplicationController | |
- Service | |
すべてのリソースはlabelとannotationをもつ | |
リソースはnamespaceと関連付けられる | |
- Pod | |
コンテナをデプロイする単位でまとめたもの | |
- ReplicationController | |
Podが何個同時に動くかを制御するもの | |
- Service | |
複数のpodをまとめるもの。proxyによるアクセスポイントを提供する | |
Docker内に環境変数としてアクセス先を設定する | |
- Namespace | |
開発中 | |
Actors | |
k8s admin - administers a kubernetes cluster | |
k8s service - k8s daemon operates on behalf of another user (i.e. controller-manager) | |
k8s policy manager - enforces policies imposed on k8s cluster | |
k8s user - uses a kubernetes cluster to schedule pods | |
- Label | |
Object(Resource)のsetを構成するためのメタデータ. | |
selectorによって検索可能 | |
- Annotation | |
検索できない単なる付加情報のためのメタデータ.APIからは取れる | |
ツールなどから利用する | |
- DNS | |
SkyDNSのkubernetesオプションを使う | |
SkyDNSに問い合わせるとserviceのIPが引ける. | |
ドメインの設定もできる | |
- 疑問 | |
update | |
Volume - ホスト単位でホスト間はなさそう。GCEのPersistentDiskもホスト間で共有はできるけどMaster/Slaveぽい | |
ホストの指定 - たぶんできない. DC-awareと同じ | |
DataCenter-aware - たぶんできない. Schedulingがその担当. pluggableなので自分で拡張もできる | |
minionの動的な追加 | |
masterの冗長性 - roadmapにはいっているからまだかも |
(結構前に調べた結果を適当にまとめる) | |
- Mesos | |
- Marathon | |
### Mesos | |
- クラスタ内のリソース管理とジョブの実行管理 | |
- すごいcron, heroku run的なものを大規模にやる | |
- Java, C++ | |
- ZooKeeper | |
### Marathon | |
- Mesos上で長時間起動しつづけるようなアプリケーションを実行するための仕組み | |
- Dockerも起動できるらしい | |
- Scala | |
## 所感 | |
- 既にMesos使っていてその上にのせるなら良さそう | |
- Java, C++, Scalaと複数の言語がまざっていてそれぞれが重量級の実装なので今から入るのは辛い | |
- 実績はありそうなのでzookeeperを使うかetcdを使うか的な選択 | |
## 参考資料 | |
- https://mesosphere.com/docs/tutorials/launch-docker-container-on-mesosphere/ | |
- Mesosでdockerを使う方法(英語) | |
- http://blog.livedoor.jp/sonots/archives/35421955.html | |
- Mesos, Marathonの解説(日本語) |