Diary

@ssig33

03/Dec/2016 (Sat) 16:25

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

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

結論

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


Kubernetes と比較した時に

Docker Swarm mode が優れている点


Kubernetes の基本的な構成

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


Docker Swarm Mode の基本的な構成

img 図作成: 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 にインフラ全部任せる会社で働いている
    • インフラエンジニアではないし インフラエンジニアだったこともないです