web-dev-qa-db-ja.com

Docker：LAMPアプリケーションの複数のインスタンスをドッキングして展開する方法

同じLAMP（またはLEMP）アプリケーションの多くのインスタンスをデプロイする必要があります：

  • フロントロードバランサー/プロキシを使用して、各インスタンスにサブドメインからアクセスできます
  • 各インスタンスには、独自のdbデータとファイルデータが必要です。
  • 各インスタンスが監視される場合があります
  • メモリ制限/ CPUはアプリインスタンスごとに設定される場合があります
  • 新しいwebappインスタンスの展開を自動化するのは簡単
  • 環境はテストと開発のために簡単に再現可能かもしれません。

アプリケーションに必要なもの：

  • dameonプロセス（Nginx、MariaDB、PHPFPM）
  • バイナリ（composer、bower、...）
  • 他のシステム固有のライブラリと構成

Dockerのドキュメントと多くのハウツーを読んだ後、このWebアプリケーションをドッキングするためのさまざまなソリューションを見つけました：

解決策1：オールインワンコンテナーを使用する

すべてのスタックは1つのコンテナにあります：

  • webappソースファイル、EMPデーモンプロセス、バイナリ、…
  • mysqlおよびwebappデータファイル用のマウントされたボリューム

例：

長所（私見）：

  • 展開の自動化、監視、破壊が簡単に思えます…。
  • 製品、テスト、開発環境で使いやすい。

短所（私見）：

  • モノリシック
  • スケーリングが難しい
  • Dockerのすべての長所を使用しない

解決策2：webappインスタンスごとにコンテナスタックを使用する

デプロイするWebアプリケーションごとに、コンテナスタックがデプロイされます：

  • プロセスごとに1つのコンテナ：Nginx、Mysql、PHP-FPM、
  • バイナリコンテナ（composer、bower、...）は、ドッキングするか、phpfpmコンテナにマージすることもできます。
  • mysqlおよびwebappデータファイル用のボリュームのマウント

例：

Pro（私見）：

  • 分離
  • インスタンスごとに分離されたプロセス
  • コンテナーごとに1つのプロセス、RUnitまたはSupervisordとしてデーモンマネージャーは不要

短所（私見）：

  • 仕事をするのがより複雑に見える
  • 維持するのが難しく、すべてのコンテナの状態、リンク、バージョンの「全体像」を確認する...

解決策3：以前の2つの解決策を混ぜる

  • 1つの「アプリ」コンテナ：app srcファイル、nginx、phpfmp、composer、git ..
  • Db mysqlの1つのコンテナー。アプリコンテナーと共有することも共有しないこともできます

私はOpsよりもDevであり、また混乱しています。

だから、質問：

  1. これらのソリューションを選択する際の基準、考慮すべき賛否両論は何ですか
  2. すべてのコンテナスタックを管理する方法ソリューション2を選択すると、すべてのコンテナの状態、リンク、バージョンの「全体像」が得られます...？
  3. アプリのsrcファイル（PHP）は、コンテナ内に構築されるか、ボリュームとしてマウントされます。/var/www？
web-applicationsweb-deploymentlampdocker
50
Koryonik

最近、このタイプのセットアップについてDockerで分析を行いました。 Dockerを一種のMicroVMと見なす人がいることは知っていますが、私の考えは、Dockerの哲学はコンテナごとの単一プロセスに傾いているということです。これは、プログラミングにおける単一責任の原則によく追従します。 Dockerコンテナが多ければ多いほど、再利用性が低くなり、管理が難しくなります。ここに私の考えをすべて掲載しました。

http://software.danielwatrous.com/a-review-of-docker/

その後、Dockerを使用してLEMPスタックを構築しました。 PHPとNginxプロセスを別個のDockerコンテナーに分割することにはあまり価値がありませんでしたが、Webとデータベースの機能は別個のコンテナーにあります。リンクとボリュームの管理方法も示しますコンテナでSSHデーモンが実行されないようにするために共有します。ここで行ったことを参考にしてください。

http://software.danielwatrous.com/use-docker-to-build-a-lemp-stack-buildfile/

コンテナごとの単一機能の複雑さの複雑さについては、あなたは正しいです。個別の分散層があるように見えます。非常に大規模なアプリケーションがこれを長年行ってきましたが、通信、セキュリティ、および管理に関しては複雑さが増しています。もちろん、多くの利点ももたらします。

18
Daniel Watrous

両方のソリューションが可能です。ただし、Dockerの「哲学」との互換性が高いため、ソリューション2（プロセスごとに1つのコンテナー）を使用します。

Dockerの良いところは、独立したビルディングブロック（単一のアプリケーションのイメージ）でアプリケーションスタック（あなたのものと同じ）を作成できることです。これらの構成要素を組み合わせて再利用できます。 公式Dockerレジストリ を見ると、ほとんどのコンポーネントがビルド前のイメージとして見つかります。例えば。 Nginxは https://registry.hub.docker.com/u/dockerfile/nginx に、MySQLデータベースは https://registry.hub.docker.comにあります。/_/mysql 。したがって、プロセス/アプリごとに1つのコンテナーを使用することを選択した場合、スタックのセットアップは非常に簡単になります。

（注意、これは単なる例であり、PHP and stuff ...）には慣れていません。）

画像を取得：

docker pull mysql
docker pull dockerfile/nginx
docker pull tutum/Apache-php

docker run --name some-mysql -e MYSQL_ROOT_PASSWORD=mysecretpassword -d mysql
docker run -d -p 80:80 -v <sites-enabled-dir>:/etc/nginx/sites-enabled -v <log-dir>:/var/log/nginx dockerfile/nginx
docker run -d -p 80:80 tutum/Apache-php

このように非常に簡単にスタックをセットアップできます。また、必要に応じて、いくつかの単一のコンポーネントを変更できます。例えば。別のコンポーネントに触れることなく、MariaDBでMySQLデータベースを変更できます。

このソリューションの最も複雑なことは、スタックの構成方法です。コンテナをリンクするには、 https://docs.docker.com/userguide/dockerlinks をご覧ください。このアプローチを使用して、たとえばMySQLコンテナーとアプリケーションコンテナー。

9
Thomas Uhrig