Docker Composeを使用してWordPressをインストールする方法を教えてください。

以下の日本語の自然なパラフレーズは一つだけです。

「序論」

WordPressは、MySQLデータベースとPHP処理をベースにした無料でオープンソースのコンテンツ管理システム（CMS）です。拡張可能なプラグインアーキテクチャとテンプレートシステムにより、ほとんどの管理作業はウェブインターフェースを通じて行うことができます。これがWordPressが、ブログから商品ページやeコマースサイトまで、さまざまな種類のウェブサイトを作成する際に人気のある選択肢である理由です。

WordPressを実行するには通常、LAMP（Linux、Apache、MySQL、およびPHP）またはLEMP（Linux、Nginx、MySQL、およびPHP）スタックをインストールする必要がありますが、これには時間がかかることがあります。ただし、DockerやDocker Composeなどのツールを使用することで、好みのスタックを設定しWordPressをインストールするプロセスを効率化できます。個々のコンポーネントを手動でインストールする代わりに、ライブラリ、設定ファイル、および環境変数などを標準化するイメージを使用できます。そして、これらのイメージをコンテナで実行し、共有のオペレーティングシステム上で動作する分離されたプロセスとして実行します。さらに、Composeを使用することで、アプリケーションとデータベースなど、複数のコンテナを連携させ、互いに通信させることができます。

このチュートリアルでは、複数のコンテナからなるWordPressのインストール方法について学びます。コンテナにはMySQLデータベース、Nginxウェブサーバー、そしてWordPress自体が含まれます。また、Let’s Encryptを使用して、サイトに関連付けたいドメイン用のTLS/SSL証明書を取得してインストールをセキュアにします。最後に、ドメインを安全に保つため、証明書の更新を定期的に行うcronジョブを設定します。

前提条件

このチュートリアルに従うためには、以下が必要です：

• A server running Ubuntu 20.04, along with a non-root user with sudo privileges and an active firewall. For guidance on how to set these up, please read our Initial Server Setup guide.
• Docker installed on your server, following Steps 1 and 2 of How To Install and Use Docker on Ubuntu 20.04.
• Docker Compose installed on your server, following Step 1 of How To Install Docker Compose on Ubuntu 20.04.
• A registered domain name. This tutorial will use your_domain throughout. You can get one for free at Freenom, or use the domain registrar of your choice.
• Both of the following DNS records set up for your server. You can follow this introduction to Silicon Cloud DNS for details on how to add them to a Silicon Cloud account:An A record with your_domain pointing to your server’s public IP address.
  An A record with www.your_domain pointing to your server’s public IP address.

すべてが準備できたら、最初のステップを始める準備が整います。 (Subete ga junbi dekitara, saisho no suteppu wo hajimeru junbi ga totonoimasu)

ステップ1 – ウェブサーバーの設定を定義する。

任意のコンテナを実行する前に、最初にNginxウェブサーバーの設定を定義する必要があります。設定ファイルには、WordPress固有のロケーションブロックと、自動的な証明書更新のためにCertbotクライアントにLet’s Encrypt検証リクエストを送信するためのロケーションブロックが含まれています。

最初に、WordPressのセットアップ用のプロジェクトディレクトリを作成します。この例では、wordpressと呼ばれていますが、好きな名前でこのディレクトリを指定することもできます。

1. mkdir wordpress

 

それからディレクトリに移動してください。

1. cd wordpress

 

次に、設定ファイル用のディレクトリを作成してください。

1. mkdir nginx-conf

 

nanoまたはお気に入りのエディターでファイルを開いてください。

1. nano nginx-conf/nginx.conf

 

このファイルに、サーバーブロックを追加してください。サーバー名とドキュメントルートのディレクティブ、さらにCertbotクライアントが証明書、PHP処理、静的アセットのリクエストを向けるためのロケーションブロックも含んでください。

以下のコードをファイルに追加してください。必ずyour_domainを自分のドメイン名に置き換えてください。

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

        server_name your_domain www.your_domain;

        index index.php 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 wordpress: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: This tells Nginx to listen on port 80, which will allow you to use Certbot’s webroot plugin for your certificate requests. Note that you are not including port 443 yet — you will update your configuration to include SSL once you have successfully obtained your certificates.
• server_name: This defines your server name and the server block that should be used for requests to your server. Be sure to replace your_domain in this line with your own domain name.
• index: This directive defines the files that will be used as indexes when processing requests to your server. You modified the default order of priority here, moving index.php in front of index.html so that Nginx prioritizes files called index.php when possible.
• root: This directive names the root directory for requests to your server. This directory, /var/www/html, is created as a mount point at build time by instructions in your WordPress Dockerfile. These Dockerfile instructions also ensure that the files from the WordPress release are mounted to this volume.

場所ブロック

• location ~ /.well-known/acme-challenge: This location block will handle requests to the .well-known directory, where Certbot will place a temporary file to validate that the DNS for your domain resolves to your server. With this configuration in place, you will be able to use Certbot’s webroot plugin to obtain certificates for your domain.
• location /: In this location block, a try_files directive is used to check for files that match individual URI requests. Instead of returning a 404 Not Found status as a default, however, you’ll pass control to WordPress’s index.php file with the request arguments.
• location ~ \.php$: This location block will handle PHP processing and proxy these requests to your wordpress container. Because your WordPress Docker image will be based on the php:fpm image, you will also include configuration options that are specific to the FastCGI protocol in this block. Nginx requires an independent PHP processor for PHP requests. In this case, these requests will be handled by the php-fpm processor that’s included with the php:fpm image.
  Additionally, this location block includes FastCGI-specific directives, variables, and options that will proxy requests to the WordPress application running in your wordpress container, set the preferred index for the parsed request URI, and parse URI requests.
• location ~ /\.ht: This block will handle .htaccess files since Nginx won’t serve them. The deny_all directive ensures that .htaccess files will never be served to users.
• location = /favicon.ico, location = /robots.txt: These blocks ensure that requests to /favicon.ico and /robots.txt will not be logged.
• location ~* \.(css|gif|ico|jpeg|jpg|js|png)$: This block turns off logging for static asset requests and ensures that these assets are highly cacheable, as they are typically expensive to serve.

FastCGIプロキシに関する詳細は、NginxでのFastCGIプロキシの理解と実装を読んでください。サーバーおよびロケーションブロックに関する情報については、Nginxのサーバーおよびロケーションブロックの選択アルゴリズムの理解を参照してください。

編集が終わったら、ファイルを保存して閉じてください。もしnanoを使用している場合は、CTRL+X、Y、そしてENTERを押してください。

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

ステップ２：環境変数の定義

ランタイムでアクセスが必要な環境変数があります。これには、データベースとWordPressアプリケーションコンテナにより、アプリケーションデータが永続化され、アプリケーションにアクセス可能になるための、センシティブな値（MySQLのルートパスワード、アプリケーションデータベースのユーザーとパスワード）と、アプリケーションのデータベース名とホストの非センシティブな情報が含まれます。

Docker Composeファイルにこれらの値をすべて設定するよりも、機密情報を.envファイルに設定し、その流通を制限しましょう。これにより、これらの値がプロジェクトリポジトリにコピーされて公開されることを防ぐことができます。

メインのプロジェクトディレクトリである~/wordpress内の.envという名前のファイルを開いてください。

1. nano .env

 

このファイルに設定する機密情報には、MySQLのルートユーザーのパスワード、およびWordPressがデータベースにアクセスするために使用するユーザー名とパスワードが含まれています。

以下の変数名と値をファイルに追加してください。各変数については、独自の値を指定してください。

MYSQL_ROOT_PASSWORD=your_root_password
MYSQL_USER=your_wordpress_database_user
MYSQL_PASSWORD=your_wordpress_database_password

以下のものが含まれています：管理者アカウントのルートパスワード、そしてアプリケーションデータベースのユーザー名とパスワードです。

編集が終わったら、ファイルを保存して閉じてください。

あなたの. envファイルには機密情報が含まれているため、プロジェクトの.gitignoreファイルと.dockerignoreファイルに含まれていることを確認したいと思います。これにより、GitとDockerはそれぞれGitリポジトリとDockerイメージにコピーしないファイルを指定します。

もしバージョン管理としてGitを使用する予定なら、git initで現在の作業ディレクトリをリポジトリとして初期化してください。

1. git init

 

それから、.gitignoreファイルを作成して開いてください。

1. nano .gitignore

 

ファイルに .env を追加してください。

.env

編集が終わったら、ファイルを保存して閉じてください。

同様に、ビルドコンテキストとしてこのディレクトリを使用している場合、.envファイルを.dockerignoreファイルに追加することは重要な予防措置です。これにより、コンテナに含まれないようになります。

ファイルを開く。

1. nano .dockerignore

 

ファイルに.envを追加してください。

.env

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

.env
.git
docker-compose.yml
.dockerignore

作業が終わったら、ファイルを保存して閉じてください。

あなたの個人情報を指定したら、次はdocker-compose.ymlファイルでサービスを定義することができます。

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

あなたのdocker-compose.ymlファイルには、セットアップのためのサービスの定義が含まれています。Composeのサービスは実行中のコンテナであり、サービスの定義は各コンテナがどのように実行されるかに関する情報を指定します。

Composeを使用すると、複数のコンテナを実行するために異なるサービスを定義できます。Composeにより、これらのサービスを共有ネットワークとボリュームでリンクすることができます。現在のセットアップには便利であり、データベース、WordPressアプリケーション、Webサーバーのための異なるコンテナを作成します。また、Certbotクライアントを実行するコンテナを作成して、Webサーバーの証明書を取得します。

最初に、docker-compose.ymlファイルを作成して開きます。

1. nano docker-compose.yml

 

Composeファイルのバージョンとdbデータベースサービスを定義するために、以下のコードを追加してください。

version: '3'

services:
  db:
    image: mysql:8.0
    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

データベースサービスの定義には、以下のオプションが含まれています。

• image: This tells Compose what image to pull to create the container. You are pinning the mysql:8.0 image here to avoid future conflicts as the mysql:latest image continues to be updated. For more information about version pinning and avoiding dependency conflicts, read the Docker documentation on Dockerfile best practices.
• container_name: This specifies a name for the container.
• restart: This defines the container restart policy. The default is no, but you have set the container to restart unless it is stopped manually.
• env_file: This option tells Compose that you would like to add environment variables from a file called .env, located in your build context. In this case, the build context is your current directory.
• environment: This option allows you to add additional environment variables, beyond those defined in your .env file. You will set the MYSQL_DATABASE variable equal to wordpress to provide a name for your application database. Because this is non-sensitive information, you can include it directly in the docker-compose.yml file.
• volumes: Here, you’re mounting a named volume called dbdata to the /var/lib/mysql directory on the container. This is the standard data directory for MySQL on most distributions.
• command: This option specifies a command to override the default CMD instruction for the image. In this particular case, you will add an option to the Docker image’s standard mysqld command, which starts the MySQL server on the container. This option, –default-authentication-plugin=mysql_native_password, sets the –default-authentication-plugin system variable to mysql_native_password, specifying which authentication mechanism should govern new authentication requests to the server. Since PHP and therefore your WordPress image won’t support MySQL’s newer authentication default, you must make this adjustment in order to authenticate your application database user.
• networks: This specifies that your application service will join the app-network network, which you will define at the bottom of the file.

次に、dbサービスの定義の下に、wordpressアプリケーションのサービス定義を追加してください。

...
  wordpress:
    depends_on: 
      - db
    image: wordpress:5.1.1-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

このサービス定義では、コンテナの名前を定義し、再起動ポリシーを設定しています。また、dbサービスと同様に、このコンテナに固有のいくつかのオプションを追加しています。

• depends_on: This option ensures that your containers will start in order of dependency, with the wordpress container starting after the db container. Your WordPress application relies on the existence of your application database and user, so expressing this order of dependency will enable your application to start properly.
• image: For this setup, you are using the 5.1.1-fpm-alpine WordPress image. As discussed in Step 1, using this image ensures that your application will have the php-fpm processor that Nginx requires to handle PHP processing. This is also an alpine image, derived from the Alpine Linux project, which will help keep your overall image size down. For more information about the benefits and drawbacks of using alpine images and whether or not this makes sense for your application, review the full discussion under the Image Variants section of the Docker Hub WordPress image page.
• env_file: Again, you specify that you want to pull values from your .env file, since this is where you defined your application database user and password.
• environment: Here, you’re using the values you defined in your .env file, but are assigning them to the variable names that the WordPress image expects: WORDPRESS_DB_USER and WORDPRESS_DB_PASSWORD. You’re also defining a WORDPRESS_DB_HOST, which will be the MySQL server running on the db container that’s accessible on MySQL’s default port, 3306. Your WORDPRESS_DB_NAME will be the same value you specified in the MySQL service definition for your MYSQL_DATABASE: wordpress.
• volumes: You are mounting a named volume called wordpress to the /var/www/html mountpoint created by the WordPress image. Using a named volume in this way will allow you to share your application code with other containers.
• networks: You’re also adding the wordpress container to the app-network network.

次に、WordPressアプリケーションサービスの定義の下に、WebサーバーNginxサービスの次の定義を追加してください。

...
  webserver:
    depends_on:
      - wordpress
    image: nginx:1.15.12-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コンテナに依存させています。また、アルパインイメージ（1.15.12-alpine Nginxイメージ）を使用しています。

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

• ports: This exposes port 80 to enable the configuration options you defined in your nginx.conf file in Step 1.
• volumes: Here, you are defining a combination of named volumes and bind mounts:wordpress:/var/www/html: This will mount your WordPress application code to the /var/www/html directory, the directory you set as the root in your Nginx server block.
  ./nginx-conf:/etc/nginx/conf.d: This will bind mount the Nginx configuration directory on the host to the relevant directory on the container, ensuring that any changes you make to files on the host will be reflected in the container.
  certbot-etc:/etc/letsencrypt: This will mount the relevant Let’s Encrypt certificates and keys for your domain to the appropriate directory on the container.

あなたはこのコンテナもapp-networkネットワークに追加しました。

最後に、ウェブサーバーの定義の下に、certbotサービスの定義を追加してください。ここに表示されているメールアドレスとドメイン名は、自分の情報に置き換えてください。

  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 sammy@your_domain --agree-tos --no-eff-email --staging -d your_domain -d www.your_domain

この定義は、Docker Hubからcertbot/certbotイメージを取得するようComposeに指示します。また、certbot-etcのドメイン証明書と鍵、およびwordpressのアプリケーションコードなどのリソースをNginxコンテナと共有するために、名前付きボリュームを使用します。

再び、webサーバーサービスが実行されてからcertbotコンテナが開始されるようにdepends_onを使用しました。

コンテナのデフォルトのcertbotコマンドで実行するサブコマンドを指定するオプションも含まれています。certonlyサブコマンドでは、以下のオプションを使用して証明書を取得します。

• –webroot: This tells Certbot to use the webroot plugin to place files in the webroot folder for authentication. This plugin depends on the HTTP-01 validation method, which uses an HTTP request to prove that Certbot can access resources from a server that responds to a given domain name.
• –webroot-path: This specifies the path of the webroot directory.
• –email: Your preferred email for registration and recovery.
• –agree-tos: This specifies that you agree to ACME’s Subscriber Agreement.
• –no-eff-email: This tells Certbot that you do not wish to share your email with the Electronic Frontier Foundation (EFF). Feel free to omit this if you would prefer.
• –staging: This tells Certbot that you would like to use Let’s Encrypt’s staging environment to obtain test certificates. Using this option allows you to test your configuration options and avoid possible domain request limits. For more information about these limits, please read Let’s Encrypt’s rate limits documentation.
• -d: This allows you to specify domain names you would like to apply to your request. In this case, you’ve included your_domain and www.your_domain. Be sure to replace these with your own domain.

certbotサービスの定義の下に、ネットワークとボリュームの定義を追加してください。

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

networks:
  app-network:
    driver: bridge  

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

ユーザー定義のブリッジネットワーク「app-network」は、Dockerデーモンホスト上にあるコンテナ同士の通信を可能にします。これにより、アプリケーション内のトラフィックと通信が効率化され、同じブリッジネットワーク上のコンテナ間で全ポートが開かれますが、外部には一切のポートが公開されません。そのため、db、wordpress、webserverのコンテナは互いに通信することができ、アプリケーションへのフロントエンドアクセスにはポート80の公開のみが必要です。

以下は、完全なdocker-compose.ymlファイルです。

version: '3'

services:
  db:
    image: mysql:8.0
    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:5.1.1-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:1.15.12-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 sammy@your_domain --agree-tos --no-eff-email --staging -d your_domain -d www.your_domain

volumes:
  certbot-etc:
  wordpress:
  dbdata:

networks:
  app-network:
    driver: bridge  

編集が終わったら、ファイルを保存して閉じてください。

あなたのサービスの定義が整ったら、コンテナを起動して証明書のリクエストをテストする準備が整いました。

ステップ4 – SSL証明書とクレデンシャルの取得

docker-compose upコマンドでコンテナを起動してください。このコマンドは指定した順序でコンテナを作成し、実行します。-dフラグを追加することで、db、wordpress、webserverコンテナをバックグラウンドで実行します。

1. docker-compose up -d

 

以下の出力により、お客様のサービスが作成されたことが確認されました。

Creating db … done Creating wordpress … done Creating webserver … done Creating certbot … done

docker-compose psを使用して、サービスの状態を確認してください。

1. docker-compose ps

 

完了したら、DB、WordPress、およびWebサーバーサービスがアップし、certbotコンテナは0のステータスメッセージで終了します。

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

データベース、WordPress、またはWebサーバーサービスの「State」列以外で「Up」以外の値、またはcertbotコンテナの終了ステータスが0以外の場合、docker-compose logsコマンドでサービスログを確認する必要がある可能性があります。

1. docker-compose logs service_name

 

docker-compose execで、証明書がウェブサーバーコンテナにマウントされているかを確認することができます。

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

 

証明書のリクエストが成功したら、以下が出力されます。

total 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 your_domain

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

docker-compose.ymlを開く

1. nano docker-compose.yml

 

ファイルの中からcertbotのサービス定義部分を見つけ、コマンドオプションの–stagingフラグを–force-renewalフラグに置き換えてください。–force-renewalフラグは、既存の証明書と同じドメインで新しい証明書をリクエストすることをCertbotに伝えます。以下は更新されたフラグを含んだcertbotのサービス定義です。

...
  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 sammy@your_domain --agree-tos --no-eff-email --force-renewal -d your_domain -d www.your_domain
...

certbotコンテナを再作成するために、現在docker-compose upを実行できます。また、–no-depsオプションを含めることで、Composeにウェブサーバーサービスの起動をスキップするように指示します。なぜなら、既に実行中だからです。

1. docker-compose up –force-recreate –no-deps certbot

 

以下の出力は、証明書のリクエストが成功したことを示しています。

Recreating 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 your_domain certbot | http-01 challenge for www.your_domain 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/your_domain/fullchain.pem certbot | Your key file has been saved at: certbot | /etc/letsencrypt/live/your_domain/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 – ウェブサーバーの設定とサービス定義の変更

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

これらの追加機能を含めてウェブサーバーのサービスを再作成する予定ですので、今すぐ停止していただいて構いません。

1. docker-compose stop webserver

 

設定ファイルを変更する前に、curlを使用してCertbotから推奨されるNginxセキュリティパラメータを取得してください。

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

 

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

次に、前に作成したNginxの設定ファイルを削除してください。

1. rm nginx-conf/nginx.conf

 

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

1. nano nginx-conf/nginx.conf

 

以下のコードをファイルに追加して、HTTPからHTTPSへのリダイレクトやSSLの資格情報、プロトコル、およびセキュリティヘッダーを追加してください。your_domainを自分のドメインに置き換えることを忘れないでください。

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

        server_name your_domain www.your_domain;

        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 your_domain www.your_domain;

        index index.php index.html index.htm;

        root /var/www/html;

        server_tokens off;

        ssl_certificate /etc/letsencrypt/live/your_domain/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/your_domain/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 wordpress: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サーバーブロックは、Certbotの更新リクエストを.well-known/acme-challengeディレクトリに指定します。また、HTTPリクエストをルートディレクトリからHTTPSにリダイレクトするリライトディレクティブも含まれています。

HTTPSサーバーブロックは、SSLとHTTP/2を有効にします。HTTP/2がHTTPプロトコルにどのように進化しているか、およびウェブサイトのパフォーマンスにおける利点について詳しく知りたい場合は、「Ubuntu 18.04でのNginxのHTTP/2サポートの設定方法」のイントロダクションをお読みください。

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

さらに、SSL LabsやSecurity HeadersのテストサイトなどでAの評価を得るために、いくつかのセキュリティヘッダが含まれています。これらのヘッダにはX-Frame-Options、X-Content-Type-Options、Referrer Policy、Content-Security-Policy、およびX-XSS-Protectionが含まれます。HTTP Strict Transport Security（HSTS）ヘッダはコメントアウトされています。”preload”の機能を理解し、評価した場合にのみ有効にしてください。

ルートディレクティブとインデックスディレクティブは、このブロックにも配置されています。また、ステップ1で説明したWordPressに特化した他のロケーションブロックもこのブロックにあります。

編集が終わったら、ファイルを保存して閉じてください。

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

docker-compose.ymlファイルを開いてください。

1. nano docker-compose.yml

 

ウェブサーバーのサービス定義に、次のポートマッピングを追加してください。

...
  webserver:
    depends_on:
      - wordpress
    image: nginx:1.15.12-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

編集後の完全な docker-compose.yml ファイルは以下の通りです。

version: '3'

services:
  db:
    image: mysql:8.0
    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:5.1.1-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:1.15.12-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 sammy@your_domain --agree-tos --no-eff-email --force-renewal -d your_domain -d www.your_domain

volumes:
  certbot-etc:
  wordpress:
  dbdata:

networks:
  app-network:
    driver: bridge  

編集が終わったら、ファイルを保存して閉じてください。

ウェブサーバーサービスを再作成してください。

1. docker-compose up -d –force-recreate –no-deps webserver

 

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

1. docker-compose ps

 

以下のように日本語で言い換えます（1つのオプションのみ）：
出力には、あなたのデータベース、WordPress、およびWebサーバーのサービスが実行されていることが示される必要があります。

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 — ウェブインターフェースを介してインストールを完了する

あなたのコンテナが実行中の場合、WordPressのウェブインターフェースを通じてインストールを完了してください。

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

https://your_domain

ご利用になりたい言語を選択してください。

「続行」をクリックすると、メインの設定ページに移動します。ここで、サイトの名前とユーザー名を選ぶ必要があります。”admin”というよりも覚えやすいユーザー名と強力なパスワードを選ぶことをおすすめします。WordPressが自動的に生成するパスワードを使用するか、独自のパスワードを作成することができます。

最後に、メールアドレスを入力し、検索エンジンがサイトをインデックス化するのを望むかどうかを決める必要があります。

ページの一番下にある「WordPressをインストールする」をクリックすると、ログインプロンプトが表示されます。

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

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

第7ステップ – 証明書の更新

Let’s Encrypt の証明書は90日間有効です。期限切れにならないように、自動更新プロセスを設定することができます。その方法の一つは、cron スケジュールユーティリティを使用してジョブを作成することです。以下の例では、定期的に実行されるスクリプトを実行して証明書を更新し、Nginx の設定を再読み込みする cron ジョブを作成します。

最初に、ssl_renew.shという名前のスクリプトを開きます。

1. nano ssl_renew.sh

 

以下のコードをスクリプトに追加して、証明書を更新し、ウェブサーバーの設定を再読み込みしてください。例のユーザー名は自分の非ルートユーザー名で置き換えることを忘れないようにしてください。

#!/bin/bash

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

cd /home/sammy/wordpress/
$COMPOSE run certbot renew --dry-run && $COMPOSE kill -s SIGHUP webserver
$DOCKER system prune -af

このスクリプトは、最初にdocker-composeバイナリをCOMPOSEという変数に割り当て、–no-ansiオプションを指定します。これにより、docker-composeコマンドがANSI制御文字なしで実行されます。次に、dockerバイナリも同様の処理を行います。最後に、~/wordpressプロジェクトディレクトリに移動し、以下のdocker-composeコマンドを実行します。

• docker-compose run: This will start a certbot container and override the command provided in your certbot service definition. Instead of using the certonly subcommand, the renew subcommand is used, which will renew certificates that are close to expiring. Also included is the –dry-run option to test your script.
• docker-compose kill: This will send a SIGHUP signal to the webserver container to reload the Nginx configuration.

それから、使用されていないコンテナとイメージをすべて削除するために「docker system prune」を実行します。

編集が終了したら、ファイルを閉じてください。次のコマンドで実行可能にしてください。

1. chmod +x ssl_renew.sh

 

次に、指定された間隔で更新スクリプトを実行するために、ルートクロンタブファイルを開いてください。

sudo crontab -e 

もしこのファイルを編集するのが初めてなら、エディターを選択するように求められます。

no 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]: …

このファイルの一番最後に、次の行を追加してください。

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

以下の日本語でパラフレーズします（１つのオプションのみ）：
「これにより、ジョブ間隔が5分ごとに設定されますので、更新リクエストが意図したように機能しているかどうかをテストすることができます。ジョブからの関連する出力を記録するために、cron.logというログファイルが作成されます。」

５分後にcron.logを確認して、更新リクエストが成功したかどうかを確認してください。

1. tail -f /var/log/cron.log

 

以下の出力は、更新が成功したことを確認します。

– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – ** 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/your_domain/fullchain.pem (success) ** DRY RUN: simulating ‘certbot renew’ close to cert expiry ** (The test certificates above have not been saved.) – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –

ターミナルで「CTRL+C」を入力して終了してください。

cronタブファイルを編集して、毎日の間隔を設定することができます。例えば、スクリプトを毎日正午に実行するためには、ファイルの最後の行を以下のように変更します。

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

あなたはまた、ssl_renew.shスクリプトから–dry-runオプションを削除したいと思うでしょう。

#!/bin/bash

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

cd /home/sammy/wordpress/
$COMPOSE run certbot renew && $COMPOSE kill -s SIGHUP webserver
$DOCKER system prune -af

あなたのクロンジョブは、Let’s Encrypt証明書が期限切れにならないよう、有効期限が近づいたときに自動的に更新します。また、Logrotateユーティリティを使ってログファイルのローテーションと圧縮を設定することもできます。

結論

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

サイトのパフォーマンスと冗長性を向上させるために、WordPress のアセットの配信とバックアップに関する以下の記事を参照することができます。

• How to Speed Up WordPress Asset Delivery Using Silicon Cloud Spaces CDN.
• How To Back Up a WordPress Site to Spaces.
• How To Store WordPress Assets on Silicon Cloud Spaces.

Kubernetesを使用したコンテナ化ワークフローに興味がある場合は、次のリンクもチェックしてみてください。

• How To Set Up WordPress with MySQL on Kubernetes Using Helm.