DockerでWordPressをインストールする方法

導入

WordPressは、MySQLデータベースとPHP処理をベースに構築された、無料のオープンソースコンテンツ管理システム（CMS）です。プラグインアーキテクチャと拡張可能なテンプレートシステムにより、管理の大部分はWebインターフェースから行えます。そのため、ブログから商品ページ、eコマースサイトまで、あらゆる種類のウェブサイトを作成する際にWordPressが人気の選択肢となっています。.

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

このチュートリアルでは、マルチコンテナWordPressインストールを構築します。コンテナには、MySQLデータベース、Nginxウェブサーバー、そしてWordPress本体が含まれます。また、サイトに関連付けたいドメインのTLS/SSL証明書をLet's Encryptで取得することで、インストール環境のセキュリティを確保します。最後に、ドメインのセキュリティを維持するために、証明書を更新するcronジョブを設定します。.

前提条件

権限を持つ非ルートユーザーでUbuntuを実行しているサーバー 須藤 そしてアクティブファイアウォール。.
Docker がサーバーにインストールされています。.
サーバーに Docker Compose がインストールされている必要があります。.
登録済みのドメイン名。このチュートリアルでは、ドメイン全体をそのまま使用します。.
次の両方の DNS レコードがサーバーに設定されています。.

your_domain がサーバーのパブリック IP アドレスを指すレコード。.

サーバーのパブリック IP アドレスを指す www.your_domain を含むレコード。.

ステップ1 – Webサーバーの構成を定義する

コンテナを実行する前に、まずNginxウェブサーバーの設定を定義します。設定ファイルには、WordPress固有のロケーションブロックと、Let's Encryptの検証リクエストをCertbotクライアントにルーティングして証明書の自動更新を行うためのロケーションブロックが含まれています。.

まず、WordPressセットアップ用のプロジェクトディレクトリを作成します。この例では「WordPress」という名前にしますが、必要に応じて別の名前に変更することもできます。

mkdir wordpress

次に、次のディレクトリに移動します。

cd wordpress

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

mkdir nginx-conf

ファイル ナノ または、お気に入りのエディターを開きます。

nano nginx-conf/nginx.conf

このファイルには、サーバー名とドキュメントルートの指示を含むサーバーブロックと、証明書、PHP 処理、および固定資産要求に対する Certbot クライアント要求を送信するための場所ブロックを追加します。.

以下のコードをファイルに追加してください。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;
        }
}

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

説明書：

聞く: これにより、Nginx はポート 80 で listen するようになります。これにより、証明書リクエストに Webroot Certbot プラグインを使用できるようになります。ポート 443 はまだ入力していないことに注意してください。証明書を正常に受け取ったら、設定を更新して SSL を有効にします。.
サーバー名: サーバー名と、サーバーへのリクエストに使用するサーバーブロックを指定します。この行の your_domain をドメイン名に置き換えてください。.
索引: このディレクティブは、サーバーへのリクエストを処理する際にインデックスとして使用されるファイルを定義します。ここでデフォルトの優先順位を変更し、index.php を index.html の前に移動することで、Nginx は可能な限り index.php という名前のファイルを優先するようになります。.
根: このディレクティブは、サーバーリクエストのルートディレクトリを指定します。このディレクトリ /var/www/html は、WordPress Dockerfile 内のディレクティブによってビルド時にマウントポイントとして作成されます。また、これらの Dockerfile ディレクティブは、WordPress のバージョンファイルがこのボリュームにインストールされることを保証します。.

ロケーションブロック:

場所 ~ /.well-known/acme-challenge: このブロックは、.well-known ディレクトリへのリクエストを処理します。Certbot は、ドメインの DNS がサーバーに解決されていることを確認するために、このディレクトリに一時ファイルを配置します。この設定により、Webroot Certbot プラグインを使用してドメインの証明書を取得できます。.
位置 /: このロケーションブロックでは、try_filesディレクティブを使用して、リクエストされたURIに一致するファイルの有無を確認します。ただし、デフォルトの404 Not Foundステータスを返す代わりに、リクエスト引数を使用してWordPressのindex.phpファイルに制御を渡します。.
場所 ~ \.php$: このロケーションブロックはPHP処理を行い、これらのリクエストをWordPressコンテナにプロキシします。WordPress Dockerイメージはphp:fpmイメージをベースにするため、このブロックにはFastCGIプロトコル固有の設定オプションも含める必要があります。NginxはPHPリクエスト用に別のPHPプロセッサを必要とします。この場合、これらのリクエストはphp:fpmイメージに付属するphp-fpmプロセッサによって処理されます。さらに、このロケーションブロックには、WordPressコンテナで実行されているWordPressアプリケーションへのプロキシリクエストの設定、解析済みリクエストURIの優先順位リストの設定、リクエストURIの解析を行うFastCGI固有のディレクティブ、変数、オプションが含まれます。.
場所 ~ /\.ht: このブロックは、Nginx が .htaccess ファイルを提供しないため、これらのファイルを処理します。deny_all ディレクティブにより、.htaccess ファイルがユーザーに提供されなくなります。.
場所 = /favicon.ico、場所 = /robots.txt: これらのブロックにより、/favicon.ico および /robots.txt へのリクエストがログに記録されないようになります。.
場所 ~* \.(css|gif|ico|jpeg|jpg|js|png)$: このブロックは、固定資産要求のログ記録を無効にし、これらの資産は通常サービスに費用がかかるため、キャッシュ可能性を高くします。.

編集が終わったら、ファイルを保存して閉じます。nanoを使用している場合は、Ctrl+X、Y、Enterの順に押してください。Nginxの設定が完了したら、実行時にアプリケーションとデータベースコンテナに渡す環境変数の作成に進みます。.

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

WordPressアプリケーションのデータベースとコンテナは、アプリケーションデータを維持し、アプリケーションからアクセスできるようにするために、実行時に特定の環境変数にアクセスする必要があります。これらの変数には、機密情報と非機密情報の両方が含まれています。機密情報には、MySQLのルートパスワード、アプリケーションデータベースのユーザー名とパスワード、そして非機密情報には、アプリケーションデータベース名とホスト名が含まれます。これらの値をすべてDocker Composeファイル（コンテナの実行方法に関する情報を含むメインファイル）に設定するのではなく、機密情報をenv.ファイルに設定し、その循環を制限します。これにより、これらの値がプロジェクトリポジトリ間でコピーされ、公開されることを防ぎます。.

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

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 init の場合:

git init

次に、.gitignore ファイルを作成して開きます。

nano .gitignore

ファイルに env を追加します:

.env

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

同様に、このディレクトリをビルドコンテキストとして使用するときにコンテナーに含まれないように、.dockerignore ファイルに .env を追加しておくと良い予防策になります。.

ファイルを開きます:

nano .dockerignore

ファイルに env を追加します:

.env

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

.env
.git
docker-compose.yml
.dockerignore

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

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

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

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

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

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

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

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

画像: これは、コンテナを作成するためにどのイメージをプルするかをComposeに指示します。mysql:latestイメージが継続的に更新されることで発生する将来の競合を回避するため、ここではmysql:8.0イメージを固定しています。バージョンの固定と依存関係の競合回避の詳細については、DockerドキュメントのDockerfileのベストプラクティスをご覧ください。.
コンテナ名: コンテナの名前を指定します。.
再起動: このポリシーは、コンテナを再起動するかどうかを指定します。デフォルトは「いいえ」ですが、手動で停止しない限りコンテナを再起動するように設定されています。.
環境ファイル: このオプションは、ビルドコンテキストにある .env というファイルから環境変数を追加することを Compose に指示します。この場合、ビルドコンテキストは現在のディレクトリです。.
環境: このオプションを使用すると、.env ファイルで定義されている環境変数に加えて、追加の環境変数を追加できます。MYSQL_DATABASE 変数を wordpress に設定して、アプリケーションのデータベース名を指定します。この情報は機密情報ではないため、docker-compose.yml ファイルに直接記述できます。.
ボリュームここでは、コンテナ内の/var/lib/mysqlフォルダにdbdataというボリュームをマウントしています。これは、ほとんどのディストリビューションにおけるMySQLの標準データディレクトリです。.
指示: このオプションは、イメージのデフォルトの CMD コマンドをオーバーライドするコマンドを指定します。この例では、コンテナ上で MySQL サーバーを起動する標準の mysqld Docker イメージコマンドにオプションを追加します。このオプション (–default-authentication-plugin=mysql_native_password) は、–default-authentication-plugin システム変数を mysql_native_password に設定し、サーバーへの新しい認証リクエストを制御する認証メカニズムを指定します。PHP および WordPress イメージは新しい MySQL 認証のデフォルトをサポートしていないため、アプリケーションのデータベースユーザーを認証するには、これを設定する必要があります。.
networks: これは、アプリケーションサービスが、ファイルの下部で定義した application-network ネットワークに参加することを指定します。.

次に、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サービスの場合と同様に、コンテナに名前を付け、再起動ポリシーを定義します。また、このコンテナにいくつかの特定のオプションを追加します。

依存する: このオプションを指定すると、コンテナが依存関係の順序に従って起動され、WordPressコンテナはdbコンテナの後に起動されます。WordPressアプリケーションはデータベースとアプリケーションユーザーの存在を前提としているため、この依存関係の順序を指定することで、アプリケーションが適切に起動することが保証されます。.
画像このセットアップでは、WordPress 5.1.1-fpm-alpine イメージを使用します。ステップ 1 で説明したように、このイメージを使用することで、Nginx が PHP 処理に必要な php-fpm プロセッサがアプリケーションに搭載されます。これは Alpine Linux プロジェクトから派生した Alpine イメージでもあり、イメージ全体のサイズを縮小するのに役立ちます。Alpine イメージの使用のメリットとデメリット、そしてアプリケーションにとって Alpine イメージが適切かどうかについて詳しくは、WordPress Docker Hub イメージページの「イメージのバリエーション」セクションをご覧ください。.
環境ファイル: ここでも、アプリケーションデータベースのユーザーとパスワードを定義した .env ファイルから値を抽出することを指定します。.
環境ここでは、.env ファイルで定義した値を使用しますが、WordPress イメージが想定する変数名（WORDPRESS_DB_USER と WORDPRESS_DB_PASSWORD）に割り当てています。また、WORDPRESS_DB_HOST も定義しています。これは、デフォルトの MySQL ポート 3306 でアクセス可能な db コンテナ上で実行される MySQL サーバーです。WORDPRESS_DB_NAME は、MySQL サービス定義（wordpress）の MYSQL_DATABASE に指定した値と同じになります。.
ボリューム: WordPressイメージによって作成された/var/www/htmlマウントポイントに、wordpressという名前のボリュームをマウントしています。このように名前付きボリュームを使用することで、アプリケーションコードを他のコンテナと共有できます。.
ネットワーク: また、WordPress コンテナをアプリケーションネットワークに追加します。.

次に、WordPress アプリケーションサービス定義の下に、Nginx Web サーバーサービスの次の定義を追加します。

...
  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コンテナへの依存関係を設定します。また、Alpineイメージ（1.15.12-alpine Nginxイメージ）を使用します。.

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

ポート: これにより、ポート 80 が公開され、手順 1 で nginx.conf ファイルで定義した構成オプションが有効になります。.
ボリューム: ここでは、名前付きボリュームとマウントポイントの組み合わせを定義します。
wordpress:/var/www/html: このコードは、WordPress アプリケーションを、Nginx サーバーブロックでルートとして設定したディレクトリである /var/www/html フォルダーに配置します。.
./nginx-conf:/etc/nginx/conf.d: これにより、ホスト上の Nginx 構成フォルダーがコンテナー内の対応するディレクトリに接続され、ホスト上のファイルに加えた変更がホストに反映されるようになります。.
certbot-etc:/etc/letsencrypt: これにより、ドメインの Let's Encrypt 証明書とキーがコンテナ上の適切なディレクトリにインストールされます。.

このコンテナをアプリケーションネットワークにも追加しました。.

最後に、Webサーバーの定義の下に、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

この定義は、Compose に Docker Hub から certbot/certbot イメージをプルするように指示します。また、名前付きボリュームを使用して、certbot-etc 内のドメイン証明書と鍵、WordPress 内のアプリケーションコードなどのリソースを Nginx コンテナと共有します。ここでも、dependent_on を使用して、certbot コンテナが Web サーバーサービスの起動後に起動するように指定しています。また、コンテナのデフォルトの certbot コマンドで実行するサブコマンドを指定するコマンドオプションも追加しました。certonly サブコマンドは、以下のオプションを使用して証明書を取得します。

--ウェブルート: これは、Certbot に webroot プラグインを使用して認証用のファイルを webroot フォルダに配置するように指示します。このプラグインは HTTP-01 認証方式を使用します。この認証方式は、HTTP リクエストを使用して、Certbot が指定されたドメイン名に応答するサーバーのリソースにアクセスできることを証明します。.
--webroot-path: これは、Web ルートディレクトリへのパスを指定します。.
--メール: 登録および回復に使用する希望のメールアドレス。.
--同意する: これは、ACME 共通契約に同意することを示します。.
--no-eff-email: これは、Certbot にあなたのメールアドレスを電子フロンティア財団（EFF）と共有したくないことを伝えます。必要に応じて削除してください。.
--ステージング: これは、Certbot にテスト証明書を取得するために Let's Encrypt のステージング環境を使用するように指示します。このオプションを使用すると、設定オプションをテストし、ドメインリクエストの制限を回避できます。これらの制限の詳細については、Let's Encrypt のレート制限に関するドキュメントをご覧ください。.
-d: リクエストに適用するドメイン名を指定できます。この例では、your_domain と www.your_domain を入力しました。これらを必ずご自身のドメインに置き換えてください。.

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

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

networks:
  app-network:
    driver: bridge

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

ユーザー定義のブリッジネットワークアプリケーションネットワークは、Dockerデーモンと同じホスト上にあるコンテナ間の通信を可能にします。これにより、同じブリッジネットワーク上のコンテナ間のすべてのポートが開放され、外部にポートを公開することなく、アプリケーション内のトラフィックと通信が簡素化されます。つまり、データベース、WordPress、Webサーバーのコンテナは相互に通信でき、アプリケーションへのフロントエンドアクセス用にポート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 の各コンテナをバックグラウンドで実行します。

docker-compose up -d

次の出力は、サービスが作成されたことを確認します。

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

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

docker-compose ps

完了すると、db、wordpress、および webserver サービスが起動し、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 サービスの状態列が上記以外である場合、または certbot コンテナの終了ステータスが 0 以外の場合は、docker-compose logs コマンドを使用してサービスログを確認する必要がある可能性があります。

docker-compose logs service_name

docker-compose exec を使用して、証明書が Web サーバーコンテナーにインストールされたことを確認できます。

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

証明書の要求が成功すると、コードの出力は次のようになります。

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 を開きます:

nano docker-compose.yml

certbotサービス定義を含むファイル部分を見つけ、コマンドオプションの–stagingを–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
...

これで、docker-compose を実行して certbot コンテナを再作成できます。また、Web サーバーサービスが既に実行されているため、Compose に --no-deps オプションを追加して、Web サーバーサービスの起動をスキップするように指示します。

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

次の出力は、証明書要求が成功したことを示しています。

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

Nginx の設定で SSL を有効にするには、HTTP から HTTPS へのリダイレクトの追加、SSL 証明書とキーの場所の指定、セキュリティパラメータとヘッダーの追加が必要です。これらの追加内容を反映させるため、Web サーバーサービスを再構築する必要があるため、ここで停止します。

docker-compose stop webserver

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

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 構成ファイルを削除します。

rm nginx-conf/nginx.conf

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

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更新リクエストのWebルートを.well-known/acme-challengeディレクトリに指定します。また、HTTPリクエストをHTTPS経由でルートディレクトリにリダイレクトするrewriteディレクティブも含まれています。.

HTTPSサーバーブロックはSSLとHTTP2を有効にします。HTTPプロトコルにおけるHTTP/2の複製方法と、それがウェブサイトのパフォーマンスにどのようなメリットをもたらすかについて詳しくは、「Ubuntu 18.04でHTTP/2サポート付きのNginxを設定する方法」の概要をご覧ください。.

このブロックには、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) ヘッダーについては説明されています。概念を理解し、「プリロード」機能を評価した場合にのみ、有効にしてください。.

ルートおよびディレクトリのディレクティブもこのブロックに配置されます。手順 1 で説明した WordPress 固有の場所ブロックの残りも同様です。編集が完了したら、ファイルを保存して閉じます。.

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

docker-compose.yml ファイルを開きます。

nano docker-compose.yml

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

...
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

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

Web サーバーサービスを再作成します。

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

docker-compose ps でサービスを確認します。

docker-compose ps

出力には、db、wordpress、および Web サーバーサービスが実行されていることが表示されます。

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 インターフェース経由でインストールを完了します。.

ウェブブラウザでサーバーのドメインにアクセスします。your_domain をドメイン名に置き換えることを忘れないでください。

https://your_domain

使用する言語を選択してください:

「続行」をクリックすると、メインの設定ページに移動し、サイト名とユーザー名を選択する必要があります。ここでは覚えやすいユーザー名（「admin」ではなく）と強力なパスワードを設定することをお勧めします。WordPressが自動生成するパスワードを使用することも、独自のパスワードを作成することもできます。最後に、メールアドレスを入力し、検索エンジンによるサイトのインデックス登録をブロックするかどうかを選択します。

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

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

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

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

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

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

nano ssl_renew.sh

証明書を更新し、Webサーバーの設定を再読み込みするには、以下のコードをスクリプトに追加してください。ここでの例のユーザー名は、非rootユーザー名に置き換えてください。

#!/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: certbotコンテナを起動し、certbotサービス定義で指定されたコマンドを上書きします。certonlyサブコマンドの代わりに、有効期限が迫っている証明書を更新するrenewサブコマンドが使用されます。また、スクリプトをテストするための--dry-runオプションも含まれています。.
docker-compose の強制終了: これにより、Web サーバーコンテナーに SIGHUP 信号が送信され、Nginx 構成が再読み込みされます。.

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

ファイルの編集が終わったら、ファイルを閉じます。以下のコマンドで実行可能にします。

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

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

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

ターミナルで CTRL+C を入力して終了します。.

crontabファイルを編集して、毎日実行間隔を設定できます。例えば、スクリプトを毎日正午に実行するには、ファイルの最後の行を次のように変更します。

...
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

cronジョブは、Let's Encrypt証明書が期限切れにならないように、期限が切れたら更新します。また、Ubuntu 22.04 / 20.04のLogrotateツールを使用してログローテーションを設定し、ログファイルをローテーションして圧縮することもできます。.

結果

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

DockerでWordPressをインストールする方法

導入

前提条件

ステップ1 – Webサーバーの構成を定義する

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

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

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

ステップ4 – SSL証明書と認証情報を取得する

ステップ5 – Webサーバーの構成とサービス定義を変更する

ステップ6 – Webインターフェース経由でインストールを完了する

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

結果

この記事の内容:

投稿者: ハディ・バハドリ

コメントを残す

教育MySQLで新しいユーザーを作成し、権限を付与する方法

教育Linux Rescue System を使って古い専用サーバーに FreeBSD をインストールする

専用のCS2（カウンターストライク2）サーバーを作成する方法

ホストとローカルホストでのWordPressのトレーニングとインストール

ダークソウルシリーズ全体のストーリー

Wbuntu: Windows 11に似たUbuntu OS

Olama と Open WebUI を使用して AI チャットボットをホストする

Netcat を使用して TCP および UDP 接続を作成し、テストする方法

Virtual Boxのインストールチュートリアル

Ubuntu 20.04でリポジトリを設定する方法

DockerでWordPressをインストールする方法

導入

前提条件

ステップ1 – Webサーバーの構成を定義する

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

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

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

ステップ4 – SSL証明書と認証情報を取得する

ステップ5 – Webサーバーの構成とサービス定義を変更する

ステップ6 – Webインターフェース経由でインストールを完了する

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

結果

この記事の内容:

投稿者: ハディ・バハドリ

フォローする

コメントを残す

あなたも気に入るかもしれない

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