前書き

WordPressは無料でオープンソースのhttps://www.digitalocean.com/community/tutorials/digitalocean-community-glossary#content-management-system [コンテンツ管理システム(CMS) ] MySQLデータベース上にhttps://www.php.net/[PHP]処理で構築されています。 拡張可能なプラグインアーキテクチャとテンプレートシステム、およびその管理のほとんどがWebインターフェイスを介して実行できるという事実のおかげで、WordPressは、ブログから製品ページ、eコマースサイトまで、さまざまなタイプのWebサイトを作成する際の一般的な選択肢です。

通常、WordPressの実行には、https://www.digitalocean.com/community/tutorials/digitalocean-community-glossary#lamp [LAMP](Linux、Apache、MySQL、およびPHP)またはhttps://www.digitalocean.comのインストールが含まれます。 / community / tutorials / digitalocean-community-glossary#lemp [LEMP](Linux、Nginx、MySQL、およびPHP)スタック。時間がかかる場合があります。 ただし、https://www.docker.com/ [Docker]やhttps://docs.docker.com/compose/[Docker Compose]などのツールを使用すると、優先スタックのセットアップとインストールのプロセスを簡素化できます。 WordPress。 個々のコンポーネントを手動でインストールする代わりに、_images_を使用して、ライブラリ、構成ファイル、環境変数などを標準化し、これらのイメージを共有オペレーティングシステムで実行される分離プロセス_containers_で実行できます。 さらに、Composeを使用することにより、アプリケーションとデータベースなどの複数のコンテナを調整して相互に通信できます。

このチュートリアルでは、複数コンテナのWordPressインストールを構築します。 コンテナには、MySQLデータベース、Nginx Webサーバー、およびWordPress自体が含まれます。 また、サイトに関連付けるドメインのhttps://letsencrypt.org/[Let’s Encrypt]でTLS / SSL証明書を取得することにより、インストールを保護します。 最後に、https://www.digitalocean.com/community/tutorials/how-to-schedule-routine-tasks-with-cron-and-anacron-on-a-vps [+ cron +]を設定しますドメインを安全に保つために証明書を更新する仕事。

前提条件

このチュートリアルを実行するには、次のものが必要です。

ステップ1-Webサーバー構成の定義

コンテナを実行する前に、最初のステップはNginx Webサーバーの構成を定義することです。 構成ファイルには、WordPress固有の場所ブロックと、証明書の自動更新のために認証リクエストをCertbotクライアントに送信する場所ブロックを含める場所ブロックが含まれます。

最初に、WordPressセットアップ用に「++」というプロジェクトディレクトリを作成し、そこに移動します。

mkdir  && cd

次に、構成ファイル用のディレクトリを作成します。

mkdir nginx-conf

`+ nano +`またはお気に入りのエディターでファイルを開きます:

nano nginx-conf/nginx.conf

このファイルでは、サーバー名とドキュメントルートのディレクティブを含むサーバーブロックと、証明書、PHP処理、および静的アセット要求に対するCertbotクライアントの要求を指示する場所ブロックを追加します。

次のコードをファイルに貼り付けます。 必ず `++`を自分のドメイン名に置き換えてください:

〜/ wordpress / nginx-conf / nginx.conf

server {
       listen 80;
       listen [::]:80;

       server_name  www.;

       index  index.html index.htm;

       root /var/www/html;

       location ~ /.well-known/acme-challenge {
               allow all;
               root /var/www/html;
       }

       location / {
               try_files $uri $uri/ /index.php$is_args$args;
       }

       location ~ \.php$ {
               try_files $uri =404;
               fastcgi_split_path_info ^(.+\.php)(/.+)$;
               fastcgi_pass :9000;
               fastcgi_index index.php;
               include fastcgi_params;
               fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
               fastcgi_param PATH_INFO $fastcgi_path_info;
       }

       location ~ /\.ht {
               deny all;
       }

       location = /favicon.ico {
               log_not_found off; access_log off;
       }
       location = /robots.txt {
               log_not_found off; access_log off; allow all;
       }
       location ~* \.(css|gif|ico|jpeg|jpg|js|png)$ {
               expires max;
               log_not_found off;
       }
}

サーバーブロックには次の情報が含まれます。

ディレクティブ:

  • + listen +:これはNginxにポート `+ 80 `でリッスンするように指示します。これにより、証明書リクエストにCertbotのhttps://certbot.eff.org/docs/using.html#webroot[webroot plugin]を使用できるようになります。 。 まだポート ` 443 +`を含んでいないことに注意してください-証明書を正常に取得したら、SSLを含むように設定を更新します。

  • + server_name +:これは、サーバー名とサーバーへのリクエストに使用されるサーバーブロックを定義します。 この行の「++」を自分のドメイン名に置き換えてください。

  • + index +: `+ index `ディレクティブは、サーバーへのリクエストを処理するときにインデックスとして使用されるファイルを定義します。 ここでデフォルトの優先順位を変更し、可能であればNginxが ` index.php `と呼ばれるファイルを優先するように、 ` index.html `の前に ` index.php +`を移動しました。

  • + root +:私たちの `+ root `ディレクティブはサーバーへのリクエストのルートディレクトリを指定します。 このディレクトリ、「 / var / www / html +」はhttps://github.com/docker-library/wordpress/blob/07958d19ed465fb7fe50626be740d88a2c2260a7/php7.2/fpm-alpine/Dockerfile#L53 [マウントポイントとして作成]ビルド時にhttps://github.com/docker-library/wordpress/blob/07958d19ed465fb7fe50626be740d88a2c2260a7/php7.2/fpm-alpine/Dockerfile[WordPress Dockerfile]の指示に従ってください。 これらのDockerfile命令は、WordPressリリースからのファイルがこのボリュームにマウントされることも保証します。

ロケーションブロック:

  • + location〜/ .well-known / acme-challenge +:このロケーションブロックは、 `+ .well-known +`ディレクトリへのリクエストを処理します。Certbotは、ドメインのDNSがサーバ。 この構成が適切であれば、Certbotのwebrootプラグインを使用して、ドメインの証明書を取得できます。

  • + location / +:このロケーションブロックでは、 `+ try_files `ディレクティブを使用して、個々のURIリクエストに一致するファイルをチェックします。 ただし、デフォルトで404の「 Not Found 」ステータスを返す代わりに、リクエスト引数とともにWordPressの「 index.php +」ファイルに制御を渡します。

  • + location〜\ .php $ +:このロケーションブロックはPHPの処理を処理し、これらのリクエストを + wordpress +`コンテナにプロキシします。 WordPress Dockerイメージはhttps://github.com/docker-library/php/blob/e63194a0006848edb13b7eff5a7f9d790d679428/7.2/alpine3.9/fpm/Dockerfile [+ php:fpm ` image]に基づいているため、このブロックにhttps://en.wikipedia.org/wiki/FastCGI[FastCGI protocol]に固有の構成オプションを含めます。 Nginxには、PHPリクエスト用に独立したPHPプロセッサが必要です。この場合、これらのリクエストは、 ` php:fpm `イメージに含まれる ` php-fpm `プロセッサによって処理されます。
    さらに、このロケーションブロックには、 ` wordpress +`コンテナーで実行されているWordPressアプリケーションへのリクエストをプロキシし、解析済みリクエストURIの優先インデックスを設定し、URIリクエストを解析するFastCGI固有のディレクティブ、変数、オプションが含まれます。

  • + location〜/ \。ht +:このブロックは、Nginxがファイルを提供しないため、 `+ .htaccess `ファイルを処理します。 ` deny_all `ディレクティブは、 ` .htaccess +`ファイルが決してユーザーに提供されないことを保証します。

  • + location = /favicon.ico++location = / robots.txt +:これらのブロックは、 `+ / favicon.ico `および ` / robots.txt +`へのリクエストがログに記録されないようにします。

  • + location〜* \。(css | gif | ico | jpeg | jpg | js | png)$ +:このブロックは、静的アセット要求のロギングをオフにし、これらのアセットは通常、サーブ。

FastCGIプロキシの詳細については、https://www.digitalocean.com/community/tutorials/understanding-and-implementing-fastcgi-proxying-in-nginx [NginxでのFastCGIプロキシの理解と実装]を参照してください。 サーバーとロケーションブロックの詳細については、https://www.digitalocean.com/community/tutorials/understanding-nginx-server-and-location-block-selection-algorithms [Nginxサーバーとロケーションブロックの選択アルゴリズムについて]を参照してください。

編集が終了したら、ファイルを保存して閉じます。 + nano +`を使用した場合は、 `+ CTRL + X ++ Y +、次に `+ ENTER +`を押して実行します。

Nginxの設定が完了したら、実行時にアプリケーションとデータベースコンテナーに渡す環境変数の作成に進むことができます。

ステップ2-環境変数の定義

データベースとWordPressアプリケーションコンテナーは、アプリケーションデータが保持され、アプリケーションにアクセスできるように、実行時に特定の環境変数にアクセスする必要があります。 これらの変数には、機密情報と非機密情報の両方が含まれます。MySQL* root *パスワードとアプリケーションデータベースユーザーとパスワードの機密値、およびアプリケーションデータベース名とホストの機密情報です。

Docker Composeファイル(コンテナの実行方法に関する情報を含むメインファイル)でこれらの値をすべて設定するのではなく、 `+ .env +`ファイルに機密値を設定し、その循環を制限できます。 これにより、これらの値がプロジェクトリポジトリにコピーされて公開されるのを防ぐことができます。

メインプロジェクトディレクトリの `〜/ +`で、 ` .env +`というファイルを開きます。

nano .env

このファイルに設定する機密値には、MySQL * root *ユーザーのパスワード、およびWordPressがデータベースへのアクセスに使用するユーザー名とパスワードが含まれます。

次の変数名と値をファイルに追加します。 各変数について、ここで*独自の値*を指定することを忘れないでください:

〜/ wordpress / .env

MYSQL_ROOT_PASSWORD=
MYSQL_USER=
MYSQL_PASSWORD=
  • root *管理アカウントのパスワードと、アプリケーションデータベースの優先ユーザー名とパスワードを含めました。

編集が終了したら、ファイルを保存して閉じます。

`+ .env `ファイルには機密情報が含まれているため、プロジェクトの ` .gitignore `および ` .dockerignore +`ファイルに含まれていることを確認する必要があります。これらのファイルはhttps://www.digitalocean.com/communityに通知します/ tutorials / how-to-use-git-a-reference-guide [Git]およびDockerどのファイルをGitリポジトリとDockerイメージにそれぞれコピーしないようにします。

バージョン管理のためにGitを使用する予定がある場合は、https://www.digitalocean.com/community/tutorials/how-to-use-git-a-reference-guide#set-up-and-initialization [現在のリポジトリとしての作業ディレクトリ]と + git init +

git init

次に、 `+ .gitignore +`ファイルを開きます。

nano .gitignore

ファイルに `+ .env +`を追加します。

〜/ wordpress / .gitignore

.env

編集が終了したら、ファイルを保存して閉じます。

同様に、ビルドコンテキストとしてこのディレクトリを使用しているときにコンテナに配置されないように、「。doc + ignore +」ファイルに「 .env +」を追加することをお勧めします。

ファイルを開きます。

nano .dockerignore

ファイルに `+ .env +`を追加します。

〜/ wordpress / .dockerignore

.env

これの下に、アプリケーションの開発に関連するファイルとディレクトリをオプションで追加できます。

〜/ wordpress / .dockerignore

.env
.git
docker-compose.yml
.dockerignore

完了したら、ファイルを保存して閉じます。

機密情報を配置したら、 `+ docker-compose.yml`ファイルでサービスの定義に進むことができます。

ステップ3-Docker Composeでサービスを定義する

`+ docker-compose.yml +`ファイルにはセットアップのサービス定義が含まれます。 Composeの_service_は実行中のコンテナーであり、サービス定義は各コンテナーの実行方法に関する情報を指定します。

Composeでは、複数のコンテナアプリケーションを実行するためにさまざまなサービスを定義できます。Composeでは、これらのサービスを共有ネットワークおよびボリュームとリンクできるためです。 これは、データベース、WordPressアプリケーション、およびWebサーバー用に異なるコンテナを作成するため、現在のセットアップに役立ちます。 また、Webサーバーの証明書を取得するために、https://certbot.eff.org/ [Certbot client]を実行するコンテナーを作成します。

まず、 `+ docker-compose.yml +`ファイルを開きます:

nano docker-compose.yml

次のコードを追加して、作成ファイルのバージョンと「+ db +」データベースサービスを定義します。

〜/ wordpress / docker-compose.yml

version: '3'

services:
 db:
   image: mysql:
   container_name: db
   restart: unless-stopped
   env_file: .env
   environment:
     - MYSQL_DATABASE=
   volumes:
     - dbdata:/var/lib/mysql
   command: '--default-authentication-plugin=mysql_native_password'
   networks:
     - app-network

`+ db +`サービス定義には次のオプションが含まれます。

  • + image +:コンテナを作成するためにプルするイメージをComposeに伝えます。 + mysql:latest +`イメージが継続するので、将来の競合を避けるためにhttps://github.com/docker-library/mysql/blob/130bd8e46a3da1adfc1732a08c70673e20aa5977/8.0/Dockerfile [+ mysql:+` image]をここに固定しています更新します。 バージョンの固定と依存関係の競合の回避の詳細については、https://docs.docker.com/develop/develop-images/dockerfile_best-practices/ [Dockerfileベストプラクティス]のDockerドキュメントを参照してください。

  • + container_name +:これはコンテナの名前を指定します。

  • + restart +:コンテナの再起動ポリシーを定義します。 デフォルトは「+ no +」ですが、手動で停止しない限り、コンテナは再起動するように設定されています。

  • + env_file +:このオプションは、ビルドコンテキストにある `+ .env +`というファイルから環境変数を追加することをComposeに伝えます。 この場合、ビルドコンテキストは現在のディレクトリです。

  • + environment +:このオプションを使用すると、 `+ .env `ファイルで定義されている環境変数以外に、追加の環境変数を追加できます。 アプリケーションデータベースの名前を指定するために、変数「 MYSQL_DATABASE 」を「+」に設定します。 これは機密情報ではないため、 `+ docker-compose.yml +`ファイルに直接含めることができます。

  • + volumes +:ここでは、名前付きhttps://docs.docker.com/storage/volumes/[volume]を `+ dbdata `と呼び、コンテナの ` / var / lib / mysql +`ディレクトリにマウントします。 これは、ほとんどのディストリビューションのMySQLの標準データディレクトリです。

  • + command +:このオプションは、イメージのデフォルトのhttps://docs.docker.com/engine/reference/builder/#cmd[CMD instruction]を上書きするコマンドを指定します。 この場合、Dockerイメージの標準https://dev.mysql.com/doc/refman/8.0/en/mysqld.html [+ mysqld + command]にオプションを追加し、MySQLサーバーを起動します容器。 このオプション `-default-authentication-plugin = mysql_native_password +`は、 `-default-authentication-plugin `システム変数を ` mysql_native_password +`に設定し、サーバーへの新しい認証要求を管理する認証メカニズムを指定します。 PHP以降のWordPressイメージhttps://github.com/docker-library/wordpress/issues/313 [サポートされません] https://mysqlserverteam.com/upgrading-to-mysql-8-0-default- authentication-plugin-considerations / [MySQLの新しい認証デフォルト]では、アプリケーションデータベースユーザーを認証するためにこの調整を行う必要があります。

  • + network +:これは、アプリケーションサービスがファイルの下部で定義する `+ app-network +`ネットワークに参加することを指定します。

次に、 `+ db `サービス定義の下に、 ` wordpress +`アプリケーションサービスの定義を追加します。

〜/ wordpress / docker-compose.yml

...
 wordpress:
   depends_on:
     - db
   image: wordpress:-fpm-alpine
   container_name: wordpress
   restart: unless-stopped
   env_file: .env
   environment:
     - WORDPRESS_DB_HOST=db:3306
     - WORDPRESS_DB_USER=$MYSQL_USER
     - WORDPRESS_DB_PASSWORD=$MYSQL_PASSWORD
     - WORDPRESS_DB_NAME=
   volumes:
     - wordpress:/var/www/html
   networks:
     - app-network

このサービス定義では、 `+ db +`サービスで行ったように、コンテナに名前を付け、再起動ポリシーを定義しています。 このコンテナに固有のオプションもいくつか追加しています。

  • + depends_on +:このオプションは、コンテナが依存関係の順に起動することを保証し、 `+ wordpress `コンテナは ` db +`コンテナの後に起動します。 WordPressアプリケーションは、アプリケーションデータベースとユーザーの存在に依存しているため、この依存関係の順序を表現すると、アプリケーションを適切に起動できます。

  • + image +:このセットアップでは、https://github.com/docker-library/wordpress/blob/07958d19ed465fb7fe50626be740d88a2c2260a7/php7.2/fpm-alpine/Dockerfile [+ -fpm-alpine + WordPressイメージを使用しています。 ]。 https://www.digitalocean.com/community/tutorials/how-to-install-wordpress-with-docker-compose#step-1-%E2%80%94-defining-the-web-server-で説明されているようにconfiguration [Step 1]、このイメージを使用することで、NginxがPHP処理を処理するために必要な `+ php-fpm `プロセッサがアプリケーションにあることが保証されます。 これはhttps://alpinelinux.org/[Alpine Linux project]から派生した ` alpine `イメージでもあり、全体のイメージサイズを小さくするのに役立ちます。 ` alpine +`画像を使用することの利点と欠点、およびこれがアプリケーションにとって意味があるかどうかの詳細については、https://hub.docker.com/_の* Image Variants *セクションにある完全な説明を参照してください。 / wordpress [Docker Hub WordPress画像ページ]。

  • + env_file +:繰り返しますが、 `+ .env +`ファイルから値を取得することを指定します。これはアプリケーションデータベースのユーザーとパスワードを定義した場所だからです。

  • + environment +:ここでは、 + .env +`ファイルで定義した値を使用していますが、WordPressイメージが期待する変数名に割り当てています: `+ WORDPRESS_DB_USER +`と `+ WORDPRESS_DB_PASSWORD +。 また、 + WORDPRESS_DB_HOST +`を定義しています。これは、MySQLのデフォルトポートである `+ 3306 +`でアクセス可能な `+ db +`コンテナで実行されるMySQLサーバーになります。 `+ WORDPRESS_DB_NAME +`は、 `+ MYSQL_DATABASE +`のMySQLサービス定義で指定した値と同じ値になります: `++

  • + volumes +: `+ wordpress `という名前のボリュームを ` / var / www / html +`マウントポイントにマウントしていますhttps://github.com/docker-library/wordpress/blob/07958d19ed465fb7fe50626be740d88a2c2260a7/php7.2/ fpm-alpine / Dockerfile#L53 [WordPressイメージによって作成]。 このように名前付きボリュームを使用すると、アプリケーションコードを他のコンテナと共有できます。

  • + network +: `+ apppress-network `ネットワークに ` wordpress`コンテナも追加しました。

次に、 + wordpress +`アプリケーションサービス定義の下に、 `+ webserver + Nginxサービスの次の定義を追加します。

〜/ wordpress / docker-compose.yml

...
 webserver:
   depends_on:
     - wordpress
   image: nginx:-alpine
   container_name: webserver
   restart: unless-stopped
   ports:
     - "80:80"
   volumes:
     - wordpress:/var/www/html
     - ./nginx-conf:/etc/nginx/conf.d
     - certbot-etc:/etc/letsencrypt
   networks:
     - app-network

繰り返しますが、コンテナに名前を付け、開始する順番に「+ wordpress 」コンテナに依存させます。 また、「 alpine 」画像(https://github.com/nginxinc/docker-nginx/blob/e5123eea0d29c8d13df17d782f15679458ff899e/mainline/stretch/Dockerfile [` -alpine +` Nginx image]も使用しています。

このサービス定義には、次のオプションも含まれます。

  • + ports +:これはポート `+ 80 `を公開して、リンクの[ nginx.conf + `ファイルで定義した設定オプションを有効にします:[ステップ1]。

  • + volumes +:ここでは、名前付きボリュームとhttps://docs.docker.com/storage/bind-mounts/[bind mounts]の組み合わせを定義しています。

  • + wordpress:/ var / www / html +:これにより、WordPressアプリケーションコードが `+ / var / www / html `ディレクトリ(Nginxサーバーブロックで ` root +`として設定されたディレクトリ)にマウントされます。

  • +。/ nginx-conf:/ etc / nginx / conf.d +:これにより、ホスト上のNginx設定ディレクトリがコンテナ上の関連ディレクトリにバインドマウントされ、ホスト上のファイルに加えた変更が確実に行われます。コンテナに反映されます。

  • + certbot-etc:/ etc / letsencrypt +:これにより、ドメインの関連するLet’s Encrypt証明書とキーがコンテナの適切なディレクトリにマウントされます。

そして再び、このコンテナを「+ app-network +」ネットワークに追加しました。

最後に、 `+ webserver `定義の下に、 ` certbot +`サービスの最後のサービス定義を追加します。 ここにリストされている電子メールアドレスとドメイン名を独自の情報に置き換えてください。

〜/ wordpress / docker-compose.yml

 certbot:
   depends_on:
     - webserver
   image: certbot/certbot
   container_name: certbot
   volumes:
     - certbot-etc:/etc/letsencrypt
     - wordpress:/var/www/html
   command: certonly --webroot --webroot-path=/var/www/html --email  --agree-tos --no-eff-email --staging -d  -d www.

この定義により、Composeはhttps://hub.docker.com/r/certbot/certbot/ [+ certbot / certbot + image]をDocker Hubからプルするように指示されます。 また、名前付きボリュームを使用して、 `+ certbot-etc `のドメイン証明書とキー、および ` wordpress +`のアプリケーションコードなどのリソースをNginxコンテナーと共有します。

繰り返しますが、「+ depends_on 」を使用して、「 webserver 」サービスの実行後に「 certbot +」コンテナを開始するように指定しました。

コンテナのデフォルトの + certbot +`コマンドで実行するサブコマンドを指定する `+ command +`オプションも含まれています。 https://certbot.eff.org/docs/using.html#certbot-command-line-options [+ certonly +`サブコマンド]は、次のオプションで証明書を取得します。

  • +-webroot +:これは、認証のためにwebrootプラグインを使用してwebrootフォルダーにファイルを配置するようCertbotに指示します。 このプラグインはhttps://tools.ietf.org/html/draft-ietf-acme-acme-03#section-7.2[HTTP-01検証方法]に依存します。これはHTTP要求を使用して、Certbotがリソースにアクセスできることを証明します特定のドメイン名に応答するサーバーから。

  • +-webroot-path +:これはwebrootディレクトリのパスを指定します。

  • +-email +:登録と回復に使用するメール。

  • +-agree-tos +:これは、https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf [ACME’s Subscriber Agreement]に同意することを指定します。

  • +-no-eff-email +:これは、Certbotに、https://www.eff.org/ [Electronic Frontier Foundation](EFF)とメールを共有したくないことを伝えます。 必要に応じて、これを省略しても構いません。

  • +-staging +:これにより、CertbotにLet’s Encryptのステージング環境を使用してテスト証明書を取得することを伝えます。 このオプションを使用すると、構成オプションをテストして、ドメイン要求の制限を回避できます。 これらの制限の詳細については、Let’s Encryptのhttps://letsencrypt.org/docs/rate-limits/[rate limits documentation]をご覧ください。

  • + -d +:これにより、リクエストに適用したいドメイン名を指定できます。 この場合、「+」と「 www。+」を含めました。 これらは必ず独自のドメインに置き換えてください。

`+ certbot +`サービス定義の下に、ネットワークとボリュームの定義を追加します。

〜/ wordpress / docker-compose.yml

...
volumes:
 certbot-etc:
 wordpress:
 dbdata:

networks:
 app-network:
   driver: bridge

トップレベルの「+ volumes 」キーは、ボリューム「 certbot-etc 」、「 wordpress 」、および「 dbdata 」を定義します。 Dockerがボリュームを作成するとき、ボリュームのコンテンツは、Dockerによって管理されるホストファイルシステムのディレクトリ「 / var / lib / docker / volumes / +」に保存されます。 各ボリュームの内容は、このディレクトリからボリュームを使用するコンテナにマウントされます。 このようにして、コンテナ間でコードとデータを共有できます。

ユーザー定義のブリッジネットワーク「+ app-network 」は、コンテナが同じDockerデーモンホスト上にあるため、コンテナ間の通信を可能にします。 これにより、ポートを外部に公開することなく、同じブリッジネットワーク上のコンテナ間のすべてのポートが開かれるため、アプリケーション内のトラフィックと通信が合理化されます。 したがって、 ` db `、 ` wordpress `、および ` webserver `コンテナは相互に通信でき、アプリケーションへのフロントエンドアクセス用にポート ` 80 +`を公開するだけで済みます。

完成した `+ docker-compose.yml +`ファイルは次のようになります。

〜/ wordpress / docker-compose.yml

version: '3'

services:
 db:
   image: mysql:
   container_name: db
   restart: unless-stopped
   env_file: .env
   environment:
     - MYSQL_DATABASE=
   volumes:
     - dbdata:/var/lib/mysql
   command: '--default-authentication-plugin=mysql_native_password'
   networks:
     - app-network

 wordpress:
   depends_on:
     - db
   image: wordpress:-fpm-alpine
   container_name: wordpress
   restart: unless-stopped
   env_file: .env
   environment:
     - WORDPRESS_DB_HOST=db:3306
     - WORDPRESS_DB_USER=$MYSQL_USER
     - WORDPRESS_DB_PASSWORD=$MYSQL_PASSWORD
     - WORDPRESS_DB_NAME=
   volumes:
     - wordpress:/var/www/html
   networks:
     - app-network

 webserver:
   depends_on:
     - wordpress
   image: nginx:-alpine
   container_name: webserver
   restart: unless-stopped
   ports:
     - "80:80"
   volumes:
     - wordpress:/var/www/html
     - ./nginx-conf:/etc/nginx/conf.d
     - certbot-etc:/etc/letsencrypt
   networks:
     - app-network

 certbot:
   depends_on:
     - webserver
   image: certbot/certbot
   container_name: certbot
   volumes:
     - certbot-etc:/etc/letsencrypt
     - wordpress:/var/www/html
   command: certonly --webroot --webroot-path=/var/www/html --email  --agree-tos --no-eff-email --staging -d  -d www.

volumes:
 certbot-etc:
 wordpress:
 dbdata:

networks:
 app-network:
   driver: bridge

編集が終了したら、ファイルを保存して閉じます。

サービス定義を適切に配置したら、コンテナを起動して証明書リクエストをテストする準備が整います。

手順4-SSL証明書と資格情報の取得

https://docs.docker.com/compose/reference/up/[`docker-compose up + `]コマンドを使用してコンテナを起動できます。このコマンドは、指定した順序でコンテナを作成して実行します。 ドメインリクエストが成功すると、出力に正しい終了ステータスが表示され、正しい証明書が ` webserver `コンテナーの ` / etc / letsencrypt / live +`フォルダーにマウントされます。

+docker-compose up + ` + -d + フラグを使用してコンテナを作成します。これにより、 + db + + wordpress +バックグラウンドでの 、および + webserver + `コンテナ:

docker-compose up -d

サービスが作成されたことを確認する出力が表示されます。

OutputCreating db ... done
Creating wordpress ... done
Creating webserver ... done
Creating certbot   ... done

`+docker-compose ps + `を使用して、サービスのステータスを確認します。

docker-compose ps

すべてが成功した場合、 + db ++ wordpress +、および + web server`サービスは + Up`になり、 + certbot`コンテナは + 0 + `ステータスメッセージで終了します。

Output  Name                 Command               State           Ports
-------------------------------------------------------------------------
certbot     certbot certonly --webroot ...   Exit 0
db          docker-entrypoint.sh --def ...   Up       3306/tcp, 33060/tcp
webserver   nginx -g daemon off;             Up       0.0.0.0:80->80/tcp
wordpress   docker-entrypoint.sh php-fpm     Up       9000/tcp

+ db ++ wordpress +、または + webserver +`サービスの `+ State +`列に `+ Up +`以外のものが表示された場合、または `+ 0 +`以外の終了ステータスが `+ + certbot + `コンテナ、https://docs.docker.com/compose/reference/logs/ [ + docker-compose logs + `]コマンドでサービスログを確認してください:

docker-compose logs

+docker-compose exec + `を使用して、証明書が + webserver + `コンテナにマウントされていることを確認できます。

docker-compose exec webserver ls -la /etc/letsencrypt/live

証明書リクエストが成功した場合、次のような出力が表示されます。

Outputtotal 16
drwx------    3 root     root          4096 May 10 15:45 .
drwxr-xr-x    9 root     root          4096 May 10 15:45 ..
-rw-r--r--    1 root     root           740 May 10 15:45 README
drwxr-xr-x    2 root     root          4096 May 10 15:45

リクエストが成功することがわかったので、 `+ certbot `サービス定義を編集して `-staging +`フラグを削除できます。

`+ docker-compose.yml`を開きます:

nano docker-compose.yml

`+ certbot `サービス定義を持つファイルのセクションを見つけ、 ` command `オプションの `-staging `フラグを `-force-renewal `フラグに置き換えます。既存の証明書と同じドメインを持つ新しい証明書を要求したい。 ` certbot +`サービス定義は次のようになります。

〜/ wordpress / docker-compose.yml

...
 certbot:
   depends_on:
     - webserver
   image: certbot/certbot
   container_name: certbot
   volumes:
     - certbot-etc:/etc/letsencrypt
     - certbot-var:/var/lib/letsencrypt
     - wordpress:/var/www/html
   command: certonly --webroot --webroot-path=/var/www/html --email  --agree-tos --no-eff-email  -d  -d www.
...

これで、「+ docker-compose up 」を実行して「 certbot 」コンテナを再作成できます。 また、 `-no-deps `オプションを追加して、Composeに ` webserver +`サービスが既に実行されているため、開始をスキップできることを伝えます。

docker-compose up --force-recreate --no-deps certbot

証明書要求が成功したことを示す出力が表示されます。

OutputRecreating certbot ... done
Attaching to certbot
certbot      | Saving debug log to /var/log/letsencrypt/letsencrypt.log
certbot      | Plugins selected: Authenticator webroot, Installer None
certbot      | Renewing an existing certificate
certbot      | Performing the following challenges:
certbot      | http-01 challenge for
certbot      | http-01 challenge for www.
certbot      | Using the webroot path /var/www/html for all unmatched domains.
certbot      | Waiting for verification...
certbot      | Cleaning up challenges
certbot      | IMPORTANT NOTES:
certbot      |  - Congratulations! Your certificate and chain have been saved at:
certbot      |    /etc/letsencrypt/live//fullchain.pem
certbot      |    Your key file has been saved at:
certbot      |    /etc/letsencrypt/live//privkey.pem
certbot      |    Your cert will expire on 2019-08-08. To obtain a new or tweaked
certbot      |    version of this certificate in the future, simply run certbot
certbot      |    again. To non-interactively renew *all* of your certificates, run
certbot      |    "certbot renew"
certbot      |  - Your account credentials have been saved in your Certbot
certbot      |    configuration directory at /etc/letsencrypt. You should make a
certbot      |    secure backup of this folder now. This configuration directory will
certbot      |    also contain certificates and private keys obtained by Certbot so
certbot      |    making regular backups of this folder is ideal.
certbot      |  - If you like Certbot, please consider supporting our work by:
certbot      |
certbot      |    Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
certbot      |    Donating to EFF:                    https://eff.org/donate-le
certbot      |
certbot exited with code 0

証明書を配置したら、Nginx構成の変更に進んでSSLを含めることができます。

ステップ5-Webサーバーの構成とサービス定義の変更

Nginx構成でSSLを有効にするには、HTTPリダイレクトをHTTPSに追加し、SSL証明書とキーの場所を指定し、セキュリティパラメーターとヘッダーを追加する必要があります。

これらの追加を含めるために `+ webserver +`サービスを再作成するので、今すぐ停止できます:

docker-compose stop webserver

構成ファイル自体を変更する前に、まずhttps://github.com/certbot/certbot/blob/master/certbot-nginx/certbot_nginx/tls_configs/options-ssl-nginx.conf [推奨されるNginxセキュリティパラメーター]を取得します`+ curl +`を使用したCertbot:

curl -sSLo nginx-conf/options-ssl-nginx.conf https://raw.githubusercontent.com/certbot/certbot/master/certbot-nginx/certbot_nginx/tls_configs/options-ssl-nginx.conf

このコマンドは、これらのパラメーターを `+ nginx-conf `ディレクトリにある ` options-ssl-nginx.conf +`というファイルに保存します。

次に、前に作成したNginx構成ファイルを削除します。

rm nginx-conf/nginx.conf

ファイルの別のバージョンを開きます。

nano nginx-conf/nginx.conf

次のコードをファイルに追加して、HTTPをHTTPSにリダイレクトし、SSL資格情報、プロトコル、およびセキュリティヘッダーを追加します。 `++`を独自のドメインに置き換えることを忘れないでください:

〜/ wordpress / nginx-conf / nginx.conf

server {
       listen 80;
       listen [::]:80;

       server_name  www.;

       location ~ /.well-known/acme-challenge {
               allow all;
               root /var/www/html;
       }

       location / {
               rewrite ^ https://$host$request_uri? permanent;
       }
}

server {
       listen 443 ssl http2;
       listen [::]:443 ssl http2;
       server_name  www.;

       index index.php index.html index.htm;

       root /var/www/html;

       server_tokens off;

       ssl_certificate /etc/letsencrypt/live//fullchain.pem;
       ssl_certificate_key /etc/letsencrypt/live//privkey.pem;

       include /etc/nginx/conf.d/options-ssl-nginx.conf;

       add_header X-Frame-Options "SAMEORIGIN" always;
       add_header X-XSS-Protection "1; mode=block" always;
       add_header X-Content-Type-Options "nosniff" always;
       add_header Referrer-Policy "no-referrer-when-downgrade" always;
       add_header Content-Security-Policy "default-src * data: 'unsafe-eval' 'unsafe-inline'" always;
       # add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
       # enable strict transport security only if you understand the implications

       location / {
               try_files $uri $uri/ /index.php$is_args$args;
       }

       location ~ \.php$ {
               try_files $uri =404;
               fastcgi_split_path_info ^(.+\.php)(/.+)$;
               fastcgi_pass :9000;
               fastcgi_index index.php;
               include fastcgi_params;
               fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
               fastcgi_param PATH_INFO $fastcgi_path_info;
       }

       location ~ /\.ht {
               deny all;
       }

       location = /favicon.ico {
               log_not_found off; access_log off;
       }
       location = /robots.txt {
               log_not_found off; access_log off; allow all;
       }
       location ~* \.(css|gif|ico|jpeg|jpg|js|png)$ {
               expires max;
               log_not_found off;
       }
}

HTTPサーバーブロックは、 `+ .well-known / acme-challenge +`ディレクトリへのCertbot更新リクエストのwebrootを指定します。 また、HTTP要求をルートディレクトリにHTTPSに転送するhttp://nginx.org/en/docs/http/ngx_http_rewrite_module.html#rewrite[rewrite directive]も含まれています。

HTTPSサーバーブロックは、「+ ssl 」と「 http2 +」を有効にします。 HTTP / 2がHTTPプロトコルを反復処理する方法とWebサイトのパフォーマンスに与える利点について詳しくは、https://www.digitalocean.com/community/tutorials/how-to-set-up-nginxの概要をご覧ください。 -with-http-2-support-on-ubuntu-18-04 [Ubuntu 18.04でHTTP / 2サポートを使用してNginxをセットアップする方法]。

このブロックには、SSL証明書とキーの場所、および `+ nginx-conf / options-ssl-nginx.conf +`に保存した推奨Certbotセキュリティパラメーターも含まれます。

さらに、https://www.ssllabs.com/ssltest/ [SSL Labs]やhttps://securityheaders.com/[Securityヘッダー]サーバーテストサイト。 これらのヘッダーには、https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options [+ X-Frame-Options +]、https://developer.mozilla.orgが含まれます。 /en-US/docs/Web/HTTP/Headers/X-Content-Type-Options[X-Content-Type-Options]、https://scotthelme.co.uk/a-new-security-header -referrer-policy / [+ Referrer Policy +]、https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy [+ Content-Security-Policy +] 、およびhttps://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-XSS-Protection [+ X-XSS-Protection +]。 HTTP + Strict Transport Security +(HSTS)ヘッダーはコメント化されています-意味を理解し、https://hstspreload.orgを評価した場合にのみ、これを有効にします/ [「プリロード」機能]。

https://www.digitalocean.com/community/tutorials/how-to-installで説明されているWordPress固有の残りのブロックと同様に、「+ root 」および「 index +」ディレクティブもこのブロックに配置されています-wordpress-with-docker-compose#step-1-%E2%80%94-defining-the-web-server-configuration [ステップ1]。

編集が完了したら、ファイルを保存して閉じます。

`+ webserver `サービスを再作成する前に、 ` webserver `サービス定義に ` 443 +`ポートマッピングを追加する必要があります。

`+ docker-compose.yml +`ファイルを開きます:

nano docker-compose.yml

`+ webserver +`サービス定義で、次のポートマッピングを追加します。

〜/ wordpress / docker-compose.yml

...
 webserver:
   depends_on:
     - wordpress
   image: nginx:-alpine
   container_name: webserver
   restart: unless-stopped
   ports:
     - "80:80"
     -
   volumes:
     - wordpress:/var/www/html
     - ./nginx-conf:/etc/nginx/conf.d
     - certbot-etc:/etc/letsencrypt
   networks:
     - app-network

終了すると、 `+ docker-compose.yml +`ファイルは次のようになります。

〜/ wordpress / docker-compose.yml

version: '3'

services:
 db:
   image: mysql:
   container_name: db
   restart: unless-stopped
   env_file: .env
   environment:
     - MYSQL_DATABASE=wordpress
   volumes:
     - dbdata:/var/lib/mysql
   command: '--default-authentication-plugin=mysql_native_password'
   networks:
     - app-network

 wordpress:
   depends_on:
     - db
   image: wordpress:-fpm-alpine
   container_name: wordpress
   restart: unless-stopped
   env_file: .env
   environment:
     - WORDPRESS_DB_HOST=db:3306
     - WORDPRESS_DB_USER=$MYSQL_USER
     - WORDPRESS_DB_PASSWORD=$MYSQL_PASSWORD
     - WORDPRESS_DB_NAME=wordpress
   volumes:
     - wordpress:/var/www/html
   networks:
     - app-network

 webserver:
   depends_on:
     - wordpress
   image: nginx:-alpine
   container_name: webserver
   restart: unless-stopped
   ports:
     - "80:80"
     - "443:443"
   volumes:
     - wordpress:/var/www/html
     - ./nginx-conf:/etc/nginx/conf.d
     - certbot-etc:/etc/letsencrypt
   networks:
     - app-network

 certbot:
   depends_on:
     - webserver
   image: certbot/certbot
   container_name: certbot
   volumes:
     - certbot-etc:/etc/letsencrypt
     - wordpress:/var/www/html
   command: certonly --webroot --webroot-path=/var/www/html --email  --agree-tos --no-eff-email --force-renewal -d  -d www.

volumes:
 certbot-etc:
 wordpress:
 dbdata:

networks:
 app-network:
   driver: bridge

編集が終了したら、ファイルを保存して閉じます。

`+ webserver +`サービスを再作成します:

docker-compose up -d --force-recreate --no-deps webserver

`+ docker-compose ps +`でサービスを確認してください:

docker-compose ps

+ db、` + wordpress`、および `+ web server`サービスが実行されていることを示す出力が表示されるはずです。

Output  Name                 Command               State                     Ports
----------------------------------------------------------------------------------------------
certbot     certbot certonly --webroot ...   Exit 0
db          docker-entrypoint.sh --def ...   Up       3306/tcp, 33060/tcp
webserver   nginx -g daemon off;             Up       0.0.0.0:443->443/tcp, 0.0.0.0:80->80/tcp
wordpress   docker-entrypoint.sh php-fpm     Up       9000/tcp

コンテナを実行すると、WebインターフェースからWordPressのインストールを完了することができます。

ステップ6-Webインターフェースを介したインストールの完了

コンテナを実行すると、WordPress Webインターフェースからインストールを完了できます。

ウェブブラウザで、サーバーのドメインに移動します。 ここで「++」を自分のドメイン名に置き換えることを忘れないでください:

https://

使用する言語を選択します。

image:https://assets.digitalocean.com/articles/docker-wordpress/wp_language_select.png [WordPress言語セレクター]

[続行]をクリックすると、メインのセットアップページが表示されます。ここで、サイトの名前とユーザー名を選択する必要があります。 ここでは、「admin」ではなく、覚えやすいユーザー名と強力なパスワードを選択することをお勧めします。 WordPressが自動的に生成するパスワードを使用するか、独自のパスワードを作成できます。

最後に、電子メールアドレスを入力し、検索エンジンがサイトのインデックスを作成しないようにするかどうかを決定する必要があります。

image:https://assets.digitalocean.com/articles/docker-wordpress/wp_main_setup.png [WordPressメインセットアップページ]

ページの下部にある* Install WordPress *をクリックすると、ログインプロンプトが表示されます。

image:https://assets.digitalocean.com/articles/docker-wordpress/wp_login.png [WordPressログイン画面]

ログインすると、WordPress管理ダッシュボードにアクセスできるようになります。

image:https://assets.digitalocean.com/articles/docker-wordpress/wp_main_dash.png [WordPressメイン管理ダッシュボード]

WordPressのインストールが完了したら、SSL証明書が自動的に更新されるように対策を講じることができます。

ステップ7-証明書の更新

Let’s Encrypt証明書は90日間有効です。そのため、自動更新プロセスを設定して、失効しないようにしてください。 これを行う1つの方法は、 `+ cron `スケジューリングユーティリティでジョブを作成することです。 この場合、 ` cron +`ジョブを作成して、証明書を更新し、Nginx設定を再ロードするスクリプトを定期的に実行します。

まず、 `+ ssl_renew.sh +`というスクリプトを開きます:

nano ssl_renew.sh

次のコードをスクリプトに追加して、証明書を更新し、Webサーバー構成を再読み込みします。 ここのサンプルのユーザー名を、独自の非ルートユーザー名に置き換えることを忘れないでください。

〜/ wordpress / ssl_renew.sh

#!/bin/bash

COMPOSE="/usr/local/bin/docker-compose --no-ansi"

cd /home//wordpress/
$COMPOSE run certbot renew --dry-run && $COMPOSE kill -s SIGHUP webserver

このスクリプトは、最初に `+ docker-compose `バイナリを ` COMPOSE `という変数に割り当て、 `-no-ansi `オプションを指定します。これにより、https:// vt100なしで ` docker-compose `コマンドが実行されます。 .net / docs / vt510-rm / chapter4.html [ANSI制御文字]。 次に、 `〜/ wordpress `プロジェクトディレクトリに移動し、次の ` docker-compose +`コマンドを実行します。

  • + docker-compose run +:これは、 `+ certbot `コンテナを起動し、 ` certbot `サービス定義で提供される ` command `をオーバーライドします。 ` certonly `サブコマンドを使用する代わりに、ここでは ` renew `サブコマンドを使用します。これにより、期限切れに近い証明書が更新されます。 スクリプトをテストするために、ここに「-dry-run +」オプションを含めました。

  • +docker-compose kill + `:これはhttps://en.wikipedia.org/wiki/SIGHUP [ + SIGHUP + シグナル]を送信します+ webserver +`コンテナに追加して、Nginx設定をリロードします。 このプロセスを使用してNginx設定をリロードする方法の詳細については、https://blog.docker.com/2015/04/tips-for-deploying-nginx-official-image-with-docker/ [このDockerブログ投稿]を参照してください。 Dockerで公式のNginxイメージを展開する]。

編集が終了したら、ファイルを閉じます。 実行可能にします。

chmod +x ssl_renew.sh

次に、* root * `+ crontab +`ファイルを開いて、指定された間隔で更新スクリプトを実行します。

sudo crontab -e

このファイルを初めて編集する場合は、エディターを選択するよう求められます。

Outputno crontab for root - using an empty one

Select an editor.  To change later, run 'select-editor'.
 1. /bin/nano        <---- easiest
 2. /usr/bin/vim.basic
 3. /usr/bin/vim.tiny
 4. /bin/ed

Choose 1-4 [1]:
...

ファイルの最後に、次の行を追加します。

crontab

...
*/5 * * * * /home//wordpress/ssl_renew.sh >> /var/log/cron.log 2>&1

これにより、ジョブ間隔が5分ごとに設定されるため、更新リクエストが意図したとおりに機能したかどうかをテストできます。 また、ジョブからの関連する出力を記録するために、ログファイル `+ cron.log +`を作成しました。

5分後、 `+ cron.log +`をチェックして、更新リクエストが成功したかどうかを確認します。

tail -f /var/log/cron.log

更新が成功したことを確認する出力が表示されます。

Output- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
** DRY RUN: simulating 'certbot renew' close to cert expiry
**          (The test certificates below have not been saved.)

Congratulations, all renewals succeeded. The following certs have been renewed:
 /etc/letsencrypt/live//fullchain.pem (success)
** DRY RUN: simulating 'certbot renew' close to cert expiry
**          (The test certificates above have not been saved.)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

これで、 `+ crontab +`ファイルを変更して、毎日の間隔を設定できます。 たとえば、毎日正午にスクリプトを実行するには、ファイルの最終行を次のように変更します。

crontab

...
0 12 * * * /home//wordpress/ssl_renew.sh >> /var/log/cron.log 2>&1

また、 `+ ssl_renew.sh `スクリプトから `-dry-run +`オプションを削除することもできます。

〜/ wordpress / ssl_renew.sh

#!/bin/bash

COMPOSE="/usr/local/bin/docker-compose --no-ansi"

cd /home//wordpress/
$COMPOSE run certbot renew && $COMPOSE kill -s SIGHUP webserver

`+ cron +`ジョブは、Let’s Encrypt証明書が適格になったときに更新することにより、証明書が失効しないようにします。 また、https://www.digitalocean.com/community/tutorials/how-to-manage-logfiles-with-logrotate-on-ubuntu-16-04 [Logrotateユーティリティを使用してログのローテーションを設定]して、ローテーションおよび圧縮することもできます。ログファイル。

結論

このチュートリアルでは、Docker Composeを使用して、Nginx WebサーバーでWordPressインストールを作成しました。 このワークフローの一環として、WordPressサイトに関連付けるドメインのTLS / SSL証明書を取得しました。 さらに、必要に応じてこれらの証明書を更新するための `+ cron +`ジョブを作成しました。

サイトのパフォーマンスと冗長性を改善するための追加手順として、WordPressアセットの配信とバックアップに関する次の記事を参照できます。

Kubernetesを使用したコンテナ化されたワークフローの調査に興味がある場合は、以下も確認できます。