DockerとFig クラスタ対応の話

figをぽちぽち触っていると、こいつDBなんかのサービスを含むアプリケーション全体を自動構築できるのに、なぜデプロイターゲットはDOCKER_HOST一台だけなのん？と疑問に思う。

少し調べてみたら、当然、外人さん達も同じことを思うらしく、githubでぼちぼち議論されていた。

• Enable services to use different Docker Hosts
• Proposal: Enable services to use different Docker Hosts
• Different Docker host configuration for each service

中身を覗いてみると単純にhostを複数管理できるようにしているだけらしい。そんでfig.ymlにどのホストにデプロイするかの情報を付与する。

web1:
  build: .
  command: python app.py
  docker_host: tcp://192.168.0.101
  docker_cert_path: /path/to/your/cert1/directory
  docker_tls_verify: 1
  ports:
   - "8000:8000"

web2:
  build: .
  command: python app.py
  docker_host: tcp://192.168.0.102
  docker_cert_path: /path/to/your/cert2/directory
  docker_tls_verify: 1
  ports:
   - "8000:8000"

これ、ホスト決め打ちだから、そのホスト落ちたら(^o^)/なんじゃないかな…。

Dockerクラスタ内のどこかにデプロイされるが、それがどこかはリクエスト側は知る必要が無い/仮にクラスタを構成するインスタンスがクラッシュした場合、そのインスタンスが実行していたDockerプロセスは別の健全なインスタンスに引き継がれる。無理言ってる気もするけど、このくらいの機能がないとマルチホスト構成をサポートする意味がないように思える。

上に挙げた特性はkubernetesがそこそこ対応しているように思えるけど、googleにべったりなのもなぁ…docker本体でなんとかしないのかなーと期待している。

この話、figがdockerに取り込まれたこともあり、内部ではdockerとfigどっちに持たせる？って話になっているように見える。

docker本体側の議論。

• Docker Clustering: Design proposal

• Proposal: Host management

• 8859 dockerのクラスタ対応、master x 1 slave x Nのモデル？

  • 詳しく読んでないけど「masterが死んだときにslaveのどれかがmasterになる/masterが定期的に交代する」くらいの特性が欲しいな！それなんてcoreosって話だけども。
• 8681 dockerホスト立てるのメンドイ。dockerクライアントにdockerホスト立てる機能も持たせようぜ！みたいな話

という感じで、上の機能が盛り込まれたら今までのdockerとは位置づけが異なった
ものになりそう。figをアプリケーションの構成を管理する環境構築ツールと位置付けて、クラスタ管理はdockerが担うっていうのが住み分けとしてはいいのかな。

クラスタ機能がサポートされるのを待つのもあれだし、PR中のブランチ引っ張ってきて自分で試せないか調べてみようかな…。

Written with StackEdit.