私の勤めている会社では、サーバは全部で4台、そのうち3台はパッケージシステムやADが動作しているWindowsサーバでそのまま運用するだけ(過去に開発されて引き継いだAccessアプリはこの3台のWindows上で動作) 内製アプリは残りの1台でやりくりしています。とは言え利用者は限られているのでリソース的には余裕です。
Dockerで複数コンテナを立てて運用していましたが、Kubernetesが流行っていることも知っていたので是非導入したいと思い、チャレンジしていました。 結論としては、うちの規模では割りに合わない、Docker運用に戻すことにしました。
Dockerのメリットは
- コンテナ化することで複数のサーバを独立に動作させることができる
- PublicなDockerイメージからDockerfileでイメージを構築する形にすれば、Dockerfileさえあればどの環境でも同じように動作させることができる
- docker-composeを利用すれば、コンテナ起動時の連携設定等も行える
Kubernetesのメリットは、上記に加えて
- 同一イメージのコンテナを複数立てて負荷分散する設定を簡単に行える
- Blue-Greenデプロイのように既存の環境を維持したままのDeployが設定で簡単にできる あたりが一例としてあると思います。
一方でDockerに対するKubernetesのデメリットとして
- DBの運用が難しい
- PVCを使えばできるようだが、壁は低くない
- 非Publicなコンテナを利用するのであれば、別途Registryサーバが必要
- ネットワーク構成が複雑、外部に公開するためにまぁまぁの設定が必要
- 複数ノードで負荷分散を可能にするための抽象化だが、そこまでいらない場合にはつらい
現状では、内製アプリが死んでも即困る状況ではなく、気付いたらDockerコンテナを起動すれば良い程度の状況なので、Kubernetesで複数コンテナを分散運用する必要もなく… ただDBだけは守る必要があるので、しっかりバックアップしてすぐに復旧できるようにしたい。となるとDockerでホストVolumeを使ってやるくらいがメンテしやすい。
このような理由でDockerに戻します。 その上で、DBのバックアップやリストアなどの手順をAnsibleでコード化しておく、あたりが今のインフラ規模ではベストだと判断しました。
Kuberetesのソリューションには、シングルで運用できるminikubeやmicrok8s,k3sなどのソリューションがあり簡単に始められますが、運用にあたっては同一コンテナの負荷分散が必要、のような必要性がないと難しいと思いました。お金をかけられるのであれば、EKSなどのマネージドサービスがベストだと思います。