現在Dockerについて学習しています。
DockerはLinux上で動作するコンテナ型の仮想化技術で、アプリケーションをDockerイメージとしてネットワーク上にアーカイブすることにより、どんなところにいても簡単にコンテナを作成して走らせることができる。また、Docker for macやWindowsなどもリリースされていてLinuxの枠を飛び越えて様々な環境(OS)上でコンテナを走らせることができるようになっているため、アプリケーションをコンテナ化することでOSに依存しない可搬性を手に入れることができる。また、デプロイの際にもコンテナを差し替えることでアプリケーションのアップデートができるため管理が楽になり、スケールさせる際にもサーバを増やしてコンテナを走らせるだけで同じサーバを複製できるほか、ローカル環境でもコンテナを動作させることができるため、開発環境の構築も楽になる。Dockerfileを利用すればイメージを抽象化でき、ビルドすることで様々な独自環境のイメージを作成することができるようになるため、容量の大きなイメージ自体を管理する必要もなくなり、Gitを併用すればアプリケーションソースの管理だけでなく、そのソースが動く環境をもバージョン管理することができるようになる。
と解釈しています。
Dockerと言うと、印象に残るクジラのキャラクターを思い浮かべますが、このアイコンを見てみると「海」がDockerが動作しているコンピュータの環境(OS)であり「クジラ」が仮想化技術、そしてクジラの上に乗っかってる「箱」がコンテナと解釈することができると思います。とてもわかりやすい良いシンボルだと思います。
しかし、実際にDockerに触れてみると、いろいろと疑問が生まれてきました。
[疑問1]
このクジラのシンボルのように複数のコンテナを1つの環境で走らせることってあるのか?
例えば、もともとApacheを利用して複数のサイトをVirtualHostで運用していた場合、それぞれサイトをコンテナ化した場合にはこのような状態になるということでしょうか?その際にポートが衝突する問題が発生すると思うのですが「nginx-proxy」のようなプロキシを利用することで回避するのがベストプラクティスということなのでしょうか?
[疑問2]
MySQLのコンテナを作成し、PHPのウェブサービスのコンテナと同時に1つのサーバでコンテナを走らせたというようなパターンを考えた場合、スケールアウトできなくなりませんか?
サーバをスケールアウトさせると、DBの単一性が崩れるため、データがとっちらかってDBとして機能しなくなりませんか?このような場合、MySQLのコンテナをもう一匹のクジラの上に乗せる(つまりもう一台サーバを増やしてMySQL専用サーバの上でMySQLのコンテナを走らせる)ことで、1匹1コンテナのような形で2匹のクジラに管理させるようになるのでしょうか?そうすると、疑問1にもつながるのですが、複数のコンテナを一つの環境で走らせることがなくなると思ってしまうんですが...
[疑問3]
docker-composeなるものが存在し、より抽象度の高いコンテナを跨いだ環境の構築の自動化ができるようですが、結局、物理的なサーバが分かれることを考えると(例えばスケールアウトしてロードバランサによって負荷分散することを考えると)環境構築ができなくなりませんか?
Dockerはもともと複数のサーバで走らせることを想定していないのでしょうか?まさかそんなはずはないと思うのですが、混乱してしまっています。おそらく何か僕に足りない知識があると思うので是非アドバイスよろしくお願いします。
回答1件
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2016/07/27 18:01