ああdocker swarm,俺はkubernetesに行くよ

今年10月,dockerはkubernetesとの統合を発表した. http://www.publickey1.jp/blog/17/dockerkubernetesdockercon_eu_2017.html

しかもローカルではdocker環境と同時にkubernetes環境が構築されるとか,わけわからんことも発表されている.

kubernetesは更に流れに乗って,先日のAWS re:InventではEKSが発表された. https://aws.amazon.com/jp/eks/

これにより,おそらく将来的にはほとんどのdocker利用者がkubernetesを利用することになるんじゃないだろうか.

docker運用サービス戦国時代

GKEではもともとkubernetesを使っていたため,GCP上でdockerコンテナをデプロイ・管理していた人たちはだいぶ初期からkubernetesを使っていたと思う.

それに対し,我々AWS勢はECSを使うことが多かった. ECSそれ自体ではなかなか全ての問題が解決せず,「ECR早くtokyo来い」とか「動的ポートマッピングしたいけどELBじゃアクセス流せない」「結局ポートの制約あるせいでうまいことコンテナだけで回せない」とかさんざん言われていた. ようやく去年ECRも東京にやってきて,ALBが出たことで動的ポートマッピングもできるようになった.

いろいろ理由はあるにしろ,そうやってECSを使い倒して,デプロイツールも作ったりしてた.

github.com

さらにもうひとつ,docker swarmというのもあった.

docker swarm

当初,swarm modeといわれていた,dockerがネイティブでサポートするクラスタ化のためのツールだ.

今はdocker本体に取り込まれている.

俺は

h3poteto.hatenablog.com

こんな記事を書くくらいにはswarmを使っていたし今でも使っている.

しかし,2016年当時,docker swarmはECSに比べても非常に貧弱で不便だった.

  • 設定ファルがdabという謎形式,せてめcompose-file使えるようにしてくれ
  • クラスタが不安定,ノードが生きてるのに疎通できなくなる
  • ロードバランスが不安定,全然均等にバランスしてくれない
  • デプロイ時のロードバランスに問題が多すぎてホットデプロイ出来ない

今では,かなり安定してきていて,設定ファイルもcompose-fileを食わせることができるようになった.

それでも当時は「あー!!この機能欲しい!まだ入らんのか!」としょっちゅう唸っていた. そしてだいたいそういうとき「kubernetesならあるのにな」という囁きも同時に聞こえていた.

しかしなんといってもswarmはdockerのネイティブサポート,「いつかkubernetesの機能のいいとこ取りをしまくったswarmの安定版が出て,世界を制覇するに違いない」と信じたかった(いや,当時の出来から言うと全然信じられなが).

少なくとも多少なりとそう思ってswarmを使い続けてきたし(もちろんECSも使うんだけど),これからもswarmを使うつもりでいた.

裏切ったな!docker!!!

そこでkubernetesですよ. まさかついにkubernetesをネイティブサポートするなんて.

もう時代はswarmじゃないのかもしれない(そもそもswarmの時代なかった).

もうswarmがkubernetesの機能を取り込む必要がない,だってkubernetesがあるんだもの.

もう「kubernetesにあるこの機能,swarmに入らないかなー」「お,次のリリースでswarm結構良くなるぞ」みたいなことをしなくなる,だってkubernetesがあるんだもの.

俺は思いっきりdockerに裏切られた気分だった.

kubernetesにいきます

swarmはdeprecateになるわけではないし,引き続き利用できるって言ってるけど,これだけ似た機能をいつまで保守するのか正直わからない.

それに,となりのkubernetesがずっと青く見えていたわけだし,もう俺はkubernetesに行くよ.

ごめんなswarm.

kubernetesでクラスタ作ってコンテナデプロイすることを,最近「kubeる」って言うようにした. kubeろう.