Docker Swarm Mode の話(タイトル変えた)

おもしろい話をしようと思ったのですが、 15 分しかないので素早くやっていきます

結論

今すぐ Docker ベースで HA 環境を作らないといけない
- use Kubernetes
ベンチャー企業でインフラのコストを低減させたい
- AWS や GCP が配ってるクーポンは無視して Heroku 使うべき
デプロイが趣味の人
- この場で Docker Swarm Mode を使いはじめるべき
それ以外の人
- Docker Swarm Mode にのんびり注目してみるといいです、全てが変わる可能性を持っている

Kubernetes と比較した時に

Docker Swarm mode が優れている点

Kubernetes の基本的な構成

引用元: kubernetesによるDockerコンテナ管理入門 - さくらのナレッジ

Docker Swarm Mode の基本的な構成

図作成: ssig33

優れていない点については後で話す

いろいろある

Apache Mesos + Chronos + Marathon の基本的な構成とか図を作りたくない

Docker Swarm Mode は名前に Apache という文字列が含まれていないというメリットがあります

Docker Swarm Mode とはなにか?

コマンド例を見ると一発でどういうものか分かります

クラスタのマスターノードの構築

$ docker swarm init
Swarm initialized: current node (ID) is now a manager.

To add a worker to this swarm, 
run the following command:

docker swarm join \
--token #{TOKEN} \
#{IP アドレス}:2377

クラスタにノードを追加

$ docker swarm join --token #{TOKEN} #{IP アドレス}

めっちゃ簡単！！

サービスを開始

Docker Swarm Mode ではアプリケーションの実行単位をサービスと呼びます

$ docker service create \
  --publish 80 \ 
  --name #{SERVICE_NAME} \
  #{IMAGE_NAME}

サービスのアップデート

$ docker servce update \
--image #{IMAGE_NAME}:#{TAG} \
#{SERVICE_NAME}

スケーリング

$ docker service scale #{SERVICE_NAME}=5

サービス作成時にこのサービスは全ノードに展開みたいな指定も可能

$ docker service create --mode global #{IMAGE_NAME}

典型的なありかたとしては、

Web アプリを global でデプロイ
各種タスクランナーを必要数だけデプロイ

みたいな

ノードのラベリングとデプロイ先制約

# ラベル作成
$ docker node update --label-add #{KEY}=#{VALUE}

# サービスに制約を追加
$ docker service update --constraints-add \
  node.#{KEY}==#{VALUE} #{SERVICE_NAME}

# 否定とかももちろん可能
$ docker service update --constraints-add \
  node.#{KEY}!=#{VALUE} #{SERVICE_NAME}

これにより、複数リージョンのサーバー群を単一のクラスタとして扱いながらサービスを適切に配置みたいなことが簡単に実現できる

サービスディスカバリ/負荷分散とかどうなってるの?

サービスがポートを公開すると、クラスタ内全部のノードにおいて、そのポートが公開されます

複数のノードに分散されてデプロイされている場合でも適切に負荷分散されます

Application Load Balancer やオートスケールと非常に相性がよい

ただし現状この挙動に致命的な問題が、、、(後述します)

結果何が出来るか

オレオレ Heroku/GAE が数分で構築できる、すごい！！！

そんなに何でも都合よく行くか

現状の問題点

サービスディスカバリ/負荷分散が全く正しく動いていない
たまにノードが行方不明になる
単発実行のタスクのデプロイが困難
- 当然ジョブスケジューラーもない
MySQL 置き場が難しい
- 例として MySQL を挙げましたが、ファイルの永続化が困難だという話
複数のサービスをひとまとめにして管理する機能がない
ログ管理がない
いろいろ undocumented

対策

サービスディスカバリが壊れてる件については前段にロードバランサを置けば対応可能
ノード消滅は死活監視入れてなんとかしましょう
ファイルの永続化困難な点は、今のところどうにもならない
- ボリュームがマウントできないわけではないので、特定ノード固定とかいう置き方でいいなら大丈夫
- パフォーマンスあんまり必要ではないものなら glusterfs なども選択肢に入る
ドキュメントに無い困り事については Github の issue を眺めればだいたい解決する
- 貢献チャンスかもしれない(僕はやりたくない)
ログは docker service log というのが実装中
- 僕は今は logspout + papertrail で運用中

現状どれくらい使い物になるか？

僕の個人サイトとデーモンは全部 Docker Swarm Mode にのっている
企業内のテスト用インフラぐらいなら、、、

面倒だったので説明を省いたこと

メモリや CPU の予約機能はあります
ネットワークを作成してやっていくことはできます
グレースフルリスタートその他かしこくアップデートができます
認証つき Docker Registry を適切に扱えます
ログドライバを指定可能です
- これ logspout に比べて全然便利じゃないと思う
*****という問題があるのでそこが心配の方は使わないほうがいい
- 会場の皆さんにだけ話します

まとめ

Docker Swarm Mode は Heroku もどきを一瞬で作れるすごいやつ
- とにかく簡単ですごい
大抵の人がほしいものはこれだったのでは？
Kubernets の Pod とかいらんやろ
安定性は酷く、まだ全然 Production Ready とは言えない

自己紹介

Name: @ssig33, 小池陸
普段は Heroku にインフラ全部任せる会社で働いている
- インフラエンジニアではないしインフラエンジニアだったこともないです

Diary

@ssig33