Docker を使用して PHP アプリケーションをデプロイするための設計計画

1. Docker

Docker の正式な定義は次のとおりです:

Docker を使用すると、アプリケーションをすべての依存関係とともにソフトウェア開発用の標準化されたユニットにパッケージ化できます。

-- https://www.docker.com/whatisdocker

Docker がアプリケーションのデプロイメントにおける大きな問題を解決することに疑いの余地はありません:

顧客: インストールされていますが、使用できません。

投稿者: 私のマシンでは問題ありません。

Docker が登場する前は、各アプリケーションの依存関係を解決する方法は頭の痛い問題でしたが、現在では、1 つの構成と最終的な配信としての Dockerfile またはイメージだけで、どの Linux 上でも完全に実行できるようになりました。簡単そうに聞こえますが、Docker の構成プロセス中には、考慮に値する多くの質問が存在します。アプリケーションのさまざまなコンポーネントをどのように配置するか?コンテナは問題を解決しますか、それともコンテナを改良しますか?コンテナはどのように相互に通信するのでしょうか?等。以下では、最も一般的な WEB アプリケーション構成のデプロイメントの 1 つを使用して、これらの問題を説明します。

注: この記事は、読者が Docker のいくつかの概念を基本的に理解していることを前提としています。Docker についてよく知らない場合は、この記事をお勧めします:

https://linux.cn/article-6074- weibo.html

2 . LNMP

一般的な PHP アプリケーション構成ソリューションは LAMP または LNMP を例に挙げています。

設計計画は以下のとおりです (私が実装して正常に実行したケース):

アプリケーションは 4 つのコンポーネント、つまり Nginx、PHP-FPM (PHP)、MySQL、WWW で構成されます。イメージから作成された独立したコンテナー内でそれぞれによって実行されます。このうち、WWWコンテナは業務コードや静的リソースを格納する単なるコンテナであり、「死んだ」ものと考えてよいでしょう。

実際、上記の設計方法を採用した LNMP アーキテクチャは、各コンポーネントが比較的独立していると考えるのが最も簡単で明確です。 WWW コンテナを除いて、他の 3 つのコンテナは公式イメージを介して直接構築できます。

しかし、インターネット上の多くの学生はこれを行わず、通常、Nginx と WWW を 1 つのコンテナーに入れるか、単にそれらを 1 つのコンテナーにまとめます。 Dockerfile を確認できます:

https://github.com/search?utf8=?&q=docker-lnmp

コンテナ設計の長所と短所を洗練する:

コンテナ間の結合が増加します。 PHP-FPM コンテナと他の 3 つのコンテナの間には結合関係があり、MySQL コンテナが最も独立していることがわかります。

結合は比較的大きいですが、このポート結合とファイルシステム結合関係は、後で紹介するいくつかの実行オプションを追加することで解決できます。

アーキテクチャ全体がコンテナによって分割されているため、コンテナ内のコンテンツは非常に独立しており、安全になります。たとえば、WWW のコードをオンラインで更新する場合、WWW コンテナに入って変更を加えるだけでよく、Nginx、PHP-FPM、MySQL には影響しません。

各コンテナは柔軟に分解して置き換えることができます。たとえば、MySQL を Mongodb に置き換えたり、ビジネス コードを移動するだけで、他のコンテナには影響を与えません (関連する設定ファイルを変更するだけです)

各コンテナが作成されるためです。公式イメージを通じて、いつでも最新の公式イメージを最安値でお試しいただけます。

単純なアプリケーションでこれを実行したい場合、4 つのミラーが多くのストレージ スペースを占有します。

2.1 コンテナ間の通信の問題

Refining Container は、コンテナ間の通信方法という別の問題に直面しています。以下は、上図のデータ フローの簡単な説明です:

クライアントの http リクエストはサーバーのポート 80 に到達します。このポートは Nginx コンテナのポート 80 にマッピングされているため、処理のために Nginx に入ります。 Nginx は、要求されたリソースを分析して、それが静的リソースであるか PHP スクリプトであるかを判断します。静的リソースの場合は WWW から直接取得され、スクリプト プログラムの場合はクライアントに送信されます。 PHP-FPM に、WWW にアクセスして対応するスクリプトを取得し、PHP -cgi 処理を使用するように指示します。

fast-cgi は php を通じてスクリプトを実行し、必要に応じて MySQL にアクセスしてデータにアクセスします。

このように、カップリング関係が出てきます:

Nginx は、PHP-FPM が開いた 9000 ポートに接続し、WWW のファイル システムにアクセスする必要があります。

PHP-FPM は、WWW のファイル システムと MySQL の 3306 ポートにもアクセスする必要があります。

2.2 問題を解決する

カップリング関係には、ポートとファイル システムの 2 種類があることがわかります。

ポート結合の場合、docker は --link オプションを通じて解決します。ファイル システム結合の場合、docker は --volumes-from オプションを通じて解決します。

最初の結合関係を解く:

$ sudo docker run -p 80:80 -p 443:443  # 主机端口映射到容器--volume-from WWW_CONTAINER_NAME  # 把WWW容器VOLUME过的文件夹挂载到将启动的容器上--link PHP_FPM_CONTAINER_NAME:fpmservice  # 冒号前是正在运行的FPM容器名称，后面是别名，别名会作为hostname在将启动的容器内可见-d  # detachNGINX_IMAGE  # 镜像名

2番目の結合関係を解く:

$ sudo docker run --volume-from WWW_CONTAINER_NAME--link MYSQL_CONTAINER_NAME:mysql-dPHP_FPM_IMAGE

参考ドキュメント: https://docs.docker.com/reference/run/

それでコンテナが起動される順番が出てくる：

MySQLコンテナ

WWWコンテナ (サービスが実行されていないため、コンテナは実行後すぐに終了します。tail -fなどのブロックコマンドを使用すると、終了せずにコンテナを実行し続けることができます)

PHP-FPMコンテナ

Nginx Container

1と2は入れ替え可能です。

3. まとめ

Docker を使用して Web アプリケーションをデプロイすると、多くの利便性がもたらされ、マクロ レベルでアプリケーションのコンポーネント化が実現され、分散システム実現の基礎が築かれます。

実際、Docker コンテナ間でデータを共有するのは非常に便利であることがわかります。各コンテナの依存関係を把握するのは難しくありません。

追記 この記事は docker を 2 日間学習した後の私の経験です。間違いがあれば修正してください。