Dockerを評価したシステム管理者としての経験に基づいて、Matt Jaynes氏がDevOps Universityのサイトに「Docker Misconceptions」という記事を書いた。彼は小規模で信頼できるインフラ基盤のないところでDockerを採用することをいさめ、デプロイメントプロセスを改善する代替案について説明している。
ContinoのCTOであるBenjamin Wootton氏も「Microservices - Not a free lunch」という記事で、マイクロサービスベースのアーキテクチャにおける重大なオペレーションオーバーヘッドについて警告していた。 Matt氏はWebアプリケーションをデリバリするサーバのセットアップにおける経験から、同様のことについて、また本番環境でDockerを安全に使うにはシステム管理の専門家が必要であると警告した。
今のところ、Dockerを使いこなすにはシステムに関する専門知識がもっと必要です。少ない知識で済むわけではありません。Dockerについて書いている記事のほとんどすべてが、極めて単純なユースケースを紹介しており、マルチホストの本番システムでDockerを使う複雑さについて無視しています。このことが、Dockerを本番環境で実際に使うために必要なことについて、誤った印象を与えてます。
もしサーバの管理方法を学ぶ必要がないことを望んでいるなら、あなたはHerokuのようなPaaSを使うべきです。 Dockerは解決策にはなりません。
Matt氏はロールベースのコンテナ (アプリ、データベース、キャッシュ、...) から始めることを推奨している。ただし、意味のあるロールについてのみで、プロジェクトに信頼できるインフラ基盤がある場合に限定している。
もしインフラに重大な欠陥があるなら、Dockerを検討している場合ではありません。それは崩れそうな崖っぷちにフェラーリを駐車するようなものです。
Dockerを導入する代わりに、デプロイメントプロセスにおけるパフォーマンスと一貫性を改善するために可能な最適化には、以下のようなものがある。
-
構成管理ツール (Ansible、Puppet、...) を使って、具体的にはクラウドで、簡単にサーバを生成して管理できるようにする。
-
スクラッチからプロビジョニングするのではなく、クラウドイメージを使って、新しいサーバを高速に生成する。ベースイメージと既に開始したサーバは構成管理ツールを使ってプロビジョニングすればよい。
-
バージョンを指定する。パッケージと依存関係のために曖昧さのないバージョンを使用し、環境によって、あるいは時間とともに、ソフトウェアが変わらないようにする。
-
gitやrsyncを使ってアプリケーションをデプロイする。これによって、Dockerのイメージレイヤキャッシングと同じように、サーバはアップデートに必要なダウンロードを最小限にすることができる。
-
アプリケーションのビルドや準備プロセスに時間がかかるなら、パッケージを使ってアプリケーションをデプロイする。zip、rpm、debといったプレビルドパッケージを使うことで、複数のサーバにわたるデプロイメントをスピードアップできるだろう。
マルチホストの本番環境の場合、Matt氏はDockerを使うことで得られるメリットを求める前に、できる限り、先ほど挙げたような最適化手法を使うことを推奨する。今のところ、Dockerのメリットがそれに伴う複雑さを上回るのは、大規模なシステムの場合に限られている。だが、Dockerプロジェクトはどんどん進んでおり、それはすぐに当てはまらなくなるかもしれない。