docker-compose.ymlの使い道に関して

Question

【質問1】docker-composeを勉強し始めたのですが、よく、下記のようなページ配信用サーバ(wordpress)とDBサーバ(Mysql)を作るdocker-compose.ymlを見かけますが、開発中は簡単に構築出来て便利ですが、本番環境で1つのサーバ内にページ配信用サーバ(wordpress)とDBサーバ(Mysql)を作るような場面ってあるんですか？自分の経験上、ページ配信用サーバとDBサーバは物理的に別サーバに立てるのが原則だと思ってました。

version: '2'

services:
   db:
     image: mysql:5.7
     volumes:
       - "./.data/db:/var/lib/mysql"
     restart: always
     environment:
       MYSQL_ROOT_PASSWORD: wordpress
       MYSQL_DATABASE: wordpress
       MYSQL_USER: wordpress
       MYSQL_PASSWORD: wordpress

   wordpress:
     depends_on:
       - db
     image: wordpress:latest
     links:
       - db
     ports:
       - "8880:80"
     restart: always
     environment:
       WORDPRESS_DB_HOST: db:3306
       WORDPRESS_DB_PASSWORD: wordpress

【質問2】
下記の認識であっていますでしょうか？
『dockerコマンドで一々環境構築するのは面倒だから、Dockerfileを使い、もっと複雑になればDockerfileすら管理が煩雑になるので、docker-composeを用いる。』

【質問3】
ある開発が一段落ついた際の、docker-composeの使用方法は、基本的に、docker-compose.ymlを実行すれば、全ての環境が整うように作成されるべきでしょうか？
例えば、nginx.confを編集していたのなら、そのnginx.confをdocker-compose.ymlと同じディレクトリに配置して、docker-compose.yml実行時に、仮想環境内のnginx.confを置換したり、既にWEBサイトが完成しているなら、そのHTMLファイルをdocker-compose.ymlと同じディレクトリに配置して、docker-compose.yml実行時に、var/www/html配下に配置するなど。

Answer 1

質問1: 本番環境で1つのサーバ内にページ配信用サーバ(wordpress)とDBサーバ(Mysql)を作るような場面ってあるんですか？

あります。例えば、まったく何も冗長化されておらず、WebかDBのどちらかがコケたら結局サービスが止まることがサービスレベルとして許容されているような本番環境です。

質問2: もっと複雑になればDockerfileすら管理が煩雑になるので、docker-composeを用いる。

開発環境上での話であれば、そのような認識で大丈夫です。

質問3:基本的に、docker-compose.ymlを実行すれば、全ての環境が整うように作成されるべきでしょうか？

はい、原則としては、その認識で間違いないです。
docker-compose up を実行すれば、dockerがインストールされていてインターネットに接続されているマシンからなら誰でも環境を立ち上げられるようにしておくのが、docker-composeで開発環境を作るときの最低限のマナーみたいなところです。

Answer 2

ページ配信用サーバとDBサーバは物理的に別サーバに立てるのが原則

これはコストなどを踏まえたバランスで決定されるものではないでしょうか。
きちんとやろうとすると、監視サーバやバックアップ、ロードバランスなども必要となりますが、
全てやるかやらないかだけでなく、色々と検討した結果、今回はこんな構成でいいよねってなると思います。
で、一緒にするならdocker-composeで良いし、複数サーバが必要ならKubernetesとか（既出）でしょう。

dockerコマンドで一々環境構築するのは面倒だから、Dockerfileを使い、もっと複雑になればDockerfileすら管理が煩雑になるので、docker-composeを用いる。

dockerでの環境って、本当に基本的なものだったり、一回ごとに作るよりはhubにまとめ、そこから使うようになっていて、ほぼcompose利用が前提に思います。
何かやっていれば、すぐにcomposeが必要になるでしょうし。ただ、以下も参考に選択していただければと思います。

ある開発が一段落ついた際の、docker-composeの使用方法は、基本的に、docker-compose.ymlを実行すれば、全ての環境が整うように作成されるべきでしょうか？

開発現場ごとに色々とやり方はあるかと思います。それほど多くのプロダクトを抱えていないような場合は、composeやKubernetesを利用しているところもあるでしょうし、すでに様々なプロダクトを抱えていて、基本となる環境を使い回し、固有の環境だけを必要に応じて取捨選択みたいな場合もあります。そういった場合に、よくあるのが、プロビジョニングツールを活用するのではないでしょうか。試験環境と本番環境で分けていて、試験が通過したら自動的にリリースまで自動化みたいなことをansible/ansible-container等を利用して実現するとか。まぁ、これも最初にいった通りバランスを考えてどのような運用が良いのかを見極めることが良いかとは思います。

以下10、11ページが参考になるかと。
https://www.slideshare.net/HidetoshiHirokawa/devopsansible

Answer 3

どういう前提の話かわかんないから一般的な話として…

質問1
コンテナホストの分散とか冗長化の話をしているのであれば、docker-composeは直接的には無関係な気がする。そこはコンテナオーケストレーションツール（Kubernetesとか）の守備範囲では。

質問2
根本的なところで間違ってると思う。Dockerfileはコンテナイメージを作るための設計図（ソースコード）であり、docker-composeはコンテナを動かす際の手順をまとめたものなので、そもそも別物。
dockerコマンド(run -vとか-pとか-eとかnetworkとか）を個別に使えばdocker-composeでできることは基本的に個別に実行可能だけど、利用するたびに毎回いちいち大量のコマンドなりオプションなりを間違えずに個別に実行するのが面倒なのでまとめるための仕組みってだけ。

質問3
当然そうするべき。むしろそうなってないなら何のために作るのかわかんない。