序章

WordPress は、PHP処理を備えたMySQLデータベース上に構築された無料のオープンソースコンテンツ管理システム(CMS)です。 Thanks to its extensible plugin architecture and templating system, most of its administration can be done through the web interface. This is a reason why WordPress is a popular choice when creating different types of websites, from blogs to product pages to eCommerce sites.

WordPressの実行には通常、 LAMP (Linux、Apache、MySQL、およびPHP)または LEMP (Linux、Nginx、MySQL、およびPHP)スタックのインストールが含まれます。 However, by using tools like Docker and Docker Compose, you can streamline the process of setting up your preferred stack and installing WordPress. Instead of installing individual components by hand, you can use images, which standardize things like libraries, configuration files, and environment variables. Then, run these images in containers, isolated processes that run on a shared operating system. さらに、Composeを使用すると、アプリケーションやデータベースなどの複数のコンテナーを調整して、相互に通信できます。

このチュートリアルでは、マルチコンテナのWordPressインストールをビルドします。 コンテナには、MySQLデータベース、Nginx Webサーバー、およびWordPress自体が含まれます。 また、サイトに関連付けたいドメインの Let’sEncryptを使用してTLS/SSL証明書を取得することにより、インストールを保護します。 最後に、 cron ジョブを設定して証明書を更新し、ドメインのセキュリティを維持します。

前提条件

このチュートリアルに従うには、次のものが必要です。

  • A server running Ubuntu 20.04, along with a non-root user with sudo 特権とアクティブなファイアウォール。 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.

  • 登録されたドメイン名。 This tutorial will use your_domain throughout. Freenom で無料で入手するか、選択したドメインレジストラを使用できます。

  • 次の両方のDNSレコードがサーバー用に設定されています。 You can follow this introduction to DigitalOcean DNS for details on how to add them to a DigitalOcean account:

    • とのAレコード your_domain サーバーのパブリックIPアドレスを指します。
    • とのAレコード www.your_domain サーバーのパブリックIPアドレスを指します。

Once you have everything set up, you’re ready to begin the first step.

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

Before running any containers, your first step is to define the configuration for your Nginx web server. Your configuration file will include some WordPress-specific location blocks, along with a location block to direct Let’s Encrypt verification requests to the Certbot client for automated certificate renewals.

First, create a project directory for your WordPress setup. In this example, it is called wordpress. You can name this directory differently if you’d like to:

  1. mkdir wordpress

Then navigate to the directory:

  1. cd wordpress

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

  1. mkdir nginx-conf

でファイルを開く nano またはお気に入りの編集者:

  1. nano nginx-conf/nginx.conf

In this file, add a server block with directives for your server name and document root, and location blocks to direct the Certbot client’s request for certificates, PHP processing, and static asset requests.

Add the following code into the file. 必ず交換してください your_domain あなた自身のドメイン名で:

〜/ wordpress / nginx-conf / nginx.conf
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:これはNginxにポートでリッスンするように指示します 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:これは、サーバー名と、サーバーへの要求に使用する必要があるサーバーブロックを定義します。 必ず交換してください your_domain この行に独自のドメイン名を付けます。
  • 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 の前に index.html Nginxが呼び出されたファイルに優先順位を付けるように index.php 可能であれば。
  • root: This directive names the root directory for requests to your server. このディレクトリ、 /var/www/html, is created as a mount point at build time by instructions in your WordPress Dockerfile. これらのDockerfile命令は、WordPressリリースのファイルがこのボリュームにマウントされていることも確認します。

ロケーションブロック:

  • location ~ /.well-known/acme-challenge:このロケーションブロックは、 .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 リクエスト引数を含むファイル。
  • location ~ \.php$: This location block will handle PHP processing and proxy these requests to your wordpress 容器。 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 に含まれているプロセッサ php:fpm 画像。 Additionally, this location block includes FastCGI-specific directives, variables, and options that will proxy requests to the WordPress application running in your wordpress コンテナ、解析されたリクエストURIの優先インデックスを設定し、URIリクエストを解析します。
  • location ~ /\.ht:このブロックは処理します .htaccess Nginxはファイルを提供しないため、ファイル。 The deny_all ディレクティブは .htaccess ファイルがユーザーに提供されることはありません。
  • location = /favicon.ico, location = /robots.txt:これらのブロックは、 /favicon.ico/robots.txt ログに記録されません。
  • location ~* \.(css|gif|ico|jpeg|jpg|js|png)$:このブロックは、静的アセットリクエストのロギングをオフにし、これらのアセットは通常、提供するのに費用がかかるため、高度にキャッシュ可能であることを保証します。

For more information about FastCGI proxying, read Understanding and Implementing FastCGI Proxying in Nginx. For information about server and location blocks, check out Understanding Nginx Server and Location Block Selection Algorithms.

編集が終了したら、ファイルを保存して閉じます。 使用した場合 nano、を押してそうします CTRL+X, Y、 それから ENTER.

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

ステップ2—環境変数を定義する

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

Rather than setting all of these values in your Docker Compose file — the main file that contains information about how your containers will run — set the sensitive values in an .env ファイルし、その循環を制限します。 This will prevent these values from copying over to your project repositories and being exposed publicly.

メインプロジェクトディレクトリで、 ~/wordpress、というファイルを開きます .env:

  1. nano .env

The confidential values that you set in this file include a password for the MySQL root user, and a username and password that WordPress will use to access the database.

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

〜/ wordpress / .env
MYSQL_ROOT_PASSWORD=your_root_password
MYSQL_USER=your_wordpress_database_user
MYSQL_PASSWORD=your_wordpress_database_password

Included is a password for the root administrative account, as well as your preferred username and password for your application database.

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

あなたの .env file contains sensitive information, you want to ensure that it is included in your project’s .gitignore.dockerignore files. This tells Git and Docker what files not to copy to your Git repositories and Docker images, respectively.

バージョン管理のためにGitを使用する場合は、現在の作業ディレクトリをリポジトリとして初期化します git init:

  1. git init

Then create and open a .gitignore ファイル:

  1. nano .gitignore

追加 .env ファイルへ:

〜/ wordpress / .gitignore
.env

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

同様に、追加するのは良い予防策です .env.dockerignore このディレクトリをビルドコンテキストとして使用しているときに、コンテナに保存されないようにします。

ファイルを開きます。

  1. nano .dockerignore

追加 .env ファイルへ:

〜/ wordpress / .dockerignore
.env

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

〜/ wordpress / .dockerignore
.env
.git
docker-compose.yml
.dockerignore

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

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

ステップ3—DockerComposeを使用したサービスの定義

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

Using Compose, you can define different services to run multi-container applications since Compose allows you to link these services together with shared networks and volumes. This will be helpful for your current setup since you will create different containers for your database, WordPress application, and web server. You will also create a container to run the Certbot client to obtain certificates for your webserver.

To begin, create and open the docker-compose.yml ファイル:

  1. nano docker-compose.yml

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

〜/ wordpress / 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

The db サービス定義には、次のオプションが含まれています。

  • image:これは、コンテナを作成するためにプルするイメージを作成するように指示します。 You are pinning the mysql:8.0 image here to avoid future conflicts as the mysql:latest 画像は更新され続けます。 For more information about version pinning and avoiding dependency conflicts, read the Docker documentation on Dockerfile best practices.
  • container_name:コンテナの名前を指定します。
  • restart:これは、コンテナの再起動ポリシーを定義します。 デフォルトは 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:このオプションを使用すると、で定義されているもの以外に、環境変数を追加できます。 .env ファイル。 You will set the MYSQL_DATABASE に等しい変数 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 ファイル。
  • volumes: Here, you’re mounting a named volume called dbdata/var/lib/mysql コンテナのディレクトリ。 これは、ほとんどのディストリビューションでのMySQLの標準データディレクトリです。
  • command:このオプションは、イメージのデフォルトのCMD命令をオーバーライドするコマンドを指定します。 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. このオプション、 --default-authentication-plugin=mysql_native_password、を設定します --default-authentication-plugin システム変数から mysql_native_password、サーバーへの新しい認証要求を管理する認証メカニズムを指定します。 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 / docker-compose.yml
...
  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

In this service definition, you’re naming your container and defining a restart policy, as you did with the db サービス。 You’re also adding some options specific to this container:

  • depends_on: This option ensures that your containers will start in order of dependency, with the wordpress 後に開始するコンテナ db 容器。 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 NginxがPHP処理を処理するために必要なプロセッサ。 これも alpine image, derived from the Alpine Linux project, which will help keep your overall image size down. 使用のメリットとデメリットの詳細については 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_USERWORDPRESS_DB_PASSWORD. You’re also defining a WORDPRESS_DB_HOST、で実行されているMySQLサーバーになります db MySQLのデフォルトポートでアクセス可能なコンテナ、 3306. 君の 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/var/www/html WordPressイメージによって作成されたマウントポイント。 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 コンテナへ app-network 通信網。

次に、以下 wordpress アプリケーションサービスの定義については、次の定義を追加してください webserver Nginxサービス:

〜/ wordpress / docker-compose.yml
...
  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

Here, you’re naming your container and making it dependent on the wordpress container in starting order. You’re also using an alpine image — 1.15.12-alpineNginxイメージ

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

  • ports:これはポートを公開します 80 to enable the configuration options you defined in your nginx.conf ステップ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.

You’ve also added this container to the 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 [email protected]_domain --agree-tos --no-eff-email --staging -d your_domain -d www.your_domain

この定義は、DockerHubからcertbot / certbotimageをプルするようにComposeに指示します。 また、名前付きボリュームを使用して、ドメイン証明書やキー入力などのリソースをNginxコンテナと共有します certbot-etc およびアプリケーションコード wordpress.

Again, you’ve used depends_on そのことを指定するには certbot コンテナは一度開始する必要があります webserver サービスが実行されています。

You’ve also included a command コンテナのデフォルトで実行するサブコマンドを指定するオプション certbot 指図。 certonlyサブコマンドは、次のオプションを使用して証明書を取得します。

  • --webroot:これは、認証のためにwebrootプラグインを使用してファイルをwebrootフォルダーに配置するようにCertbotに指示します。 このプラグインは、 HTTP-01検証メソッドに依存しています。このメソッドは、HTTPリクエストを使用して、Certbotが特定のドメイン名に応答するサーバーからリソースにアクセスできることを証明します。
  • --webroot-path:これは、webrootディレクトリのパスを指定します。
  • --email:登録と復旧のためのご希望のメールアドレス。
  • --agree-tos:これは、ACMEのサブスクライバー契約に同意することを指定します。
  • --no-eff-email:これは、電子メールを Electronic Frontier Foundation (EFF)と共有したくないことをCertbotに通知します。 必要に応じて、これを省略してください。
  • --staging:これは、Let’sEncryptのステージング環境を使用してテスト証明書を取得することをCertbotに通知します。 このオプションを使用すると、構成オプションをテストして、ドメイン要求の制限を回避できます。 For more information about these limits, please read Let’s Encrypt’s rate limits documentation.
  • -d:これにより、リクエストに適用するドメイン名を指定できます。 In this case, you’ve included your_domainwww.your_domain. これらは必ず独自のドメインに置き換えてください。

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

〜/ wordpress / docker-compose.yml
...
volumes:
  certbot-etc:
  wordpress:
  dbdata:

networks:
  app-network:
    driver: bridge  

Your top-level volumes キーはボリュームを定義します certbot-etc, wordpress、 と dbdata. Dockerがボリュームを作成すると、ボリュームのコンテンツはホストファイルシステム上のディレクトリに保存されます。 /var/lib/docker/volumes/、それはDockerによって管理されています。 次に、各ボリュームのコンテンツは、このディレクトリからボリュームを使用する任意のコンテナにマウントされます。 このようにして、コンテナ間でコードとデータを共有することが可能です。

ユーザー定義のブリッジネットワーク app-network enables communication between your containers since they are on the same Docker daemon host. これにより、ポートを外部に公開することなく、同じブリッジネットワーク上のコンテナ間のすべてのポートが開かれるため、アプリケーション内のトラフィックと通信が合理化されます。 Thus, your db, wordpress、 と webserver containers can communicate with each other, and you only need to expose port 80 アプリケーションへのフロントエンドアクセス用。

The following is docker-compose.yml file in its entirety:

〜/ wordpress / 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 [email protected]_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証明書とクレデンシャルを取得する

Start your containers with the docker-compose up command, which will create and run your containers in the order you have specified. By adding the -d flag, the command will run the db, wordpress、 と webserver バックグラウンドのコンテナ:

  1. docker-compose up -d

The following output confirms that your services have been created:

Output
Creating db ... done Creating wordpress ... done Creating webserver ... done Creating certbot ... done

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

  1. docker-compose ps

Once complete, your db, wordpress、 と webserver サービスは 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

Anything other than Up の中に State の列 db, wordpress、 また webserver サービス、または以外の終了ステータス 0 のために certbot container means that you may need to check the service logs with the docker-compose logs command:

  1. docker-compose logs service_name

これで、証明書がにマウントされていることを確認できます。 webserver docker-compose exec を含むコンテナー:

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

Once your certificate requests succeed, the following is the output:

Output
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 のフラグ command オプションと --force-renewal フラグ。これは、既存の証明書と同じドメインを持つ新しい証明書を要求することをCertbotに通知します。 The following is the certbot service definition with the updated flag:

〜/ 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 [email protected]_domain --agree-tos --no-eff-email --force-renewal -d your_domain -d www.your_domain
...

これで実行できます docker-compose up を再現するには certbot 容器。 You will also include the --no-deps Composeに開始をスキップできることを通知するオプション webserver サービス、すでに実行されているため:

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

The following output indicates that your certificate request was successful:

Output
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—Webサーバーの構成とサービス定義を変更する

Enabling SSL in your Nginx configuration will involve adding an HTTP redirect to HTTPS, specifying your SSL certificate and key locations, and adding security parameters and headers.

あなたが再作成しようとしているので webserver これらの追加を含めるサービスは、今すぐ停止できます。

  1. docker-compose stop webserver

Before modifying the configuration file, get the recommended Nginx security parameter from Certbot using curl:

  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

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

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

  1. rm nginx-conf/nginx.conf

Create and open another version of the file:

  1. nano nginx-conf/nginx.conf

次のコードをファイルに追加して、HTTPをHTTPSにリダイレクトし、SSLクレデンシャル、プロトコル、およびセキュリティヘッダーを追加します。 交換することを忘れないでください your_domain あなた自身のドメインで:

〜/ wordpress / nginx-conf / nginx.conf
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更新要求のWebルートを指定します。 .well-known/acme-challenge ディレクトリ。 また、ルートディレクトリへのHTTPリクエストをHTTPSに転送するrewriteディレクティブも含まれています。

HTTPSサーバーブロックは sslhttp2. To read more about how HTTP/2 iterates on HTTP protocols and the benefits it can have for website performance, please read the introduction to How To Set Up Nginx with HTTP/2 Support on Ubuntu 18.04.

This block also includes your SSL certificate and key locations, along with the recommended Certbot security parameters that you saved to nginx-conf/options-ssl-nginx.conf.

Additionally, included are some security headers that will enable you to get A ratings on things like the SSL Labs and Security Headers server test sites. これらのヘッダーには、 X-Frame-Options X-Content-Type-Options Referrer Policy Content-Security-Policy 、およびX-XSS-Protection HTTP Strict Transport Security (HSTS)ヘッダーはコメント化されています。これは、影響を理解し、「プリロード」機能を評価した場合にのみ有効にしてください。

君の rootindex ステップ1で説明されているWordPress固有のロケーションブロックの残りの部分と同様に、ディレクティブもこのブロックに配置されます。

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

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

あなたの docker-compose.yml ファイル:

  1. nano docker-compose.yml

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

〜/ wordpress / 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

Here is the complete docker-compose.yml file after the edits:

〜/ wordpress / 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 [email protected]_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  

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

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

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

であなたのサービスをチェックしてください docker-compose ps:

  1. docker-compose ps

The output should indicate that your db, wordpress、 と webserver サービスが実行されています:

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

With your containers running, you can complete your WordPress installation through the web interface.

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

With your containers running, finish the installation through the WordPress web interface.

Webブラウザーで、サーバーのドメインに移動します。 代用することを忘れないでください your_domain あなた自身のドメイン名で:

https://your_domain

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

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

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

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

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

With your WordPress installation complete, you can take steps to ensure that your SSL certificates will renew automatically.

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

Let’s Encrypt certificates are valid for 90 days. You can set up an automated renewal process to ensure that they do not lapse. これを行う1つの方法は、 cron スケジューリングユーティリティ。 In the following example, you will create a cron job to periodically run a script that will renew your certificates and reload your Nginx configuration.

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

  1. nano ssl_renew.sh

次のコードをスクリプトに追加して、証明書を更新し、Webサーバー構成を再ロードします。 Remember to replace the example username here with your own non-root username:

〜/ wordpress / 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:これは開始します certbot コンテナとオーバーライド command provided in your certbot サービス定義。 を使用する代わりに 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 :これによりSIGHUPシグナルwebserver container to reload the Nginx configuration.

次に、 docker system prune を実行して、未使用のコンテナーとイメージをすべて削除します。

編集が終了したら、ファイルを閉じます。 Make it executable with the following command:

  1. chmod +x ssl_renew.sh

次に、ルートを開きます crontab 指定された間隔で更新スクリプトを実行するファイル:

sudo crontab -e 

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

Output
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]: ...

At the very bottom of this file, add the following line:

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

これにより、ジョブ間隔が5分ごとに設定されるため、更新要求が意図したとおりに機能したかどうかをテストできます。 A log file, cron.log, is created to record relevant output from the job.

5分後、確認してください cron.log to confirm whether or not the renewal request has succeeded:

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

The following output confirms a successful renewal:

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

Exit out by entering CTRL+C in your terminal.

You can modify the crontab 毎日の間隔を設定するファイル。 To run the script every day at noon, for example, you would modify the last line of the file like the following:

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

また、削除する必要があります --dry-run あなたからのオプション ssl_renew.sh 脚本:

〜/ wordpress / 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 && $COMPOSE kill -s SIGHUP webserver
$DOCKER system prune -af

君の cron ジョブは、Let’s Encrypt証明書が適格なときに更新することで、証明書が失効しないようにします。 Logrotateユーティリティを使用してログローテーションを設定し、ログファイルをローテーションおよび圧縮することもできます。

結論

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

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

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

  • Helmを使用してKubernetesでMySQLを使用してWordPressを設定する方法。