NGINX Unit と Ubuntu を使用した WordPress インストールの自動化

WordPress のインストール方法に関するチュートリアルは数多くあり、Google で「WordPress インストール」を検索すると、約 XNUMX 万件の結果が表示されます。 しかし、実際には、WordPress とその基礎となるオペレーティング システムをインストールして構成し、長期間サポートできるようにするための優れたガイドはほとんどありません。 おそらく、正しい設定は特定のニーズに大きく依存しているか、詳細な説明が記事を読みにくくしているためです。

この記事では、Ubuntu に WordPress を自動的にインストールする bash スクリプトを提供することで、両方の長所を組み合わせることを試みます。また、それを実際に実行し、各部分の機能と開発時に行った妥協点について説明します。 。 上級ユーザーの場合は、記事のテキストをスキップして、 スクリプトを受け取ります お客様の環境で変更して使用するためのものです。 スクリプトの出力は、Lets Encrypt サポートを備えたカスタム WordPress インストールであり、NGINX ユニット上で実行され、運用環境での使用に適しています。

NGINX ユニットを使用して WordPress をデプロイするために開発されたアーキテクチャについては、次のセクションで説明されています。 古い記事, ここで、(他の多くのチュートリアルと同様に) そこで説明されていないこともさらに設定します。

• WordPress CLI
• Let's Encrypt と TLSSSL 証明書
• 証明書の自動更新
• NGINX キャッシュ
• NGINX 圧縮
• HTTPS および HTTP/2 のサポート
• プロセスの自動化

この記事では、静的処理サーバー、PHP 処理サーバー、およびデータベースを同時にホストする XNUMX 台のサーバーへのインストールについて説明します。 複数の仮想ホストとサービスをサポートするインストールは、将来の潜在的なトピックです。 これらの記事にないことについて書いてほしい場合は、コメントに書いてください。

必要条件

• コンテナサーバー (LXC または Lxd）、仮想マシン、または少なくとも 512MB の RAM と Ubuntu 18.04 以降がインストールされている通常の Iron サーバー。
• インターネットにアクセス可能なポート 80 および 443
• このサーバーのパブリック IP アドレスに関連付けられたドメイン名
• ルートアクセス (sudo)。

アーキテクチャの概要

アーキテクチャは説明したものと同じです 前、XNUMX層Webアプリケーション。 これは、PHP エンジン上で実行される PHP スクリプトと、Web サーバーによって処理される静的ファイルで構成されます。

一般原則

• スクリプト内の多くの構成コマンドは、冪等性の if 条件でラップされています。スクリプトは、すでに設定されている設定を変更するリスクなしに複数回実行できます。
• スクリプトはリポジトリからソフトウェアをインストールしようとするため、XNUMX つのコマンドでシステム アップデートを適用できます (apt upgrade Ubuntuの場合）。
• コマンドはコンテナ内で実行されていることを検出して、それに応じて設定を変更できるようにします。
• 設定で開始するスレッド プロセスの数を設定するために、スクリプトはコンテナー、仮想マシン、およびハードウェア サーバーで動作するための自動設定を推測しようとします。
• 設定を説明するとき、私たちは常に自動化について最初に考えます。これがコードとして独自のインフラストラクチャを作成するための基礎となることを願っています。
• すべてのコマンドはユーザーとして実行されます ルート、基本的なシステム設定を変更しますが、WordPress は直接通常のユーザーとして実行されるためです。

環境変数の設定

スクリプトを実行する前に、次の環境変数を設定します。

• WORDPRESS_DB_PASSWORD - WordPress データベースのパスワード
• WORDPRESS_ADMIN_USER - WordPress 管理者名
• WORDPRESS_ADMIN_PASSWORD - WordPress 管理者パスワード
• WORDPRESS_ADMIN_EMAIL - WordPress 管理者のメールアドレス
• WORDPRESS_URL は、WordPress サイトの完全な URL です。 https://.
• LETS_ENCRYPT_STAGING - デフォルトでは空ですが、値を 1 に設定すると、Let's Encrypt ステージング サーバーが使用されます。これは、設定をテストするときに頻繁に証明書を要求するために必要です。そうしないと、大量の要求により Let's Encrypt が一時的に IP アドレスをブロックする可能性があります。 。

スクリプトは、これらの WordPress 関連の変数が設定されているかどうかを確認し、設定されていない場合は終了します。
スクリプト行 572 ～ 576 で値を確認します LETS_ENCRYPT_STAGING.

派生環境変数の設定

55 ～ 61 行目のスクリプトは、ハードコーディングされた値、または前のセクションで設定した変数から取得した値を使用して、次の環境変数を設定します。

• DEBIAN_FRONTEND="noninteractive" - アプリケーションがスクリプトで実行されていること、およびユーザー対話の可能性がないことをアプリケーションに伝えます。
• WORDPRESS_CLI_VERSION="2.4.0" WordPress CLI アプリケーションのバージョンです。
• WORDPRESS_CLI_MD5= "dedd5a662b80cda66e9e25d44c23b25c" — WordPress CLI 2.4.0 実行可能ファイルのチェックサム (バージョンは変数で指定されます) WORDPRESS_CLI_VERSION）。 162 行目のスクリプトは、この値を使用して、正しい WordPress CLI ファイルがダウンロードされたことを確認します。
• UPLOAD_MAX_FILESIZE="16M" - WordPress にアップロードできる最大ファイル サイズ。 この設定は複数の場所で使用されるため、XNUMX か所に設定する方が簡単です。
• TLS_HOSTNAME= "$(echo ${WORDPRESS_URL} | cut -d'/' -f3)" - システムのホスト名。WORDPRESS_URL 変数から取得されます。 Let's Encrypt から適切な TLS/SSL 証明書を取得したり、WordPress の内部検証を取得したりするために使用されます。
• NGINX_CONF_DIR="/etc/nginx" - メインファイルを含むNGINX設定が含まれるディレクトリへのパス nginx.conf.
• CERT_DIR="/etc/letsencrypt/live/${TLS_HOSTNAME}" — 変数から取得される、WordPress サイトの Let's Encrypt 証明書へのパス TLS_HOSTNAME.

WordPress サーバーにホスト名を割り当てる

スクリプトは、サイトのドメイン名と一致するようにサーバーのホスト名を設定します。 これは必須ではありませんが、単一サーバーをセットアップする場合は、スクリプトの構成に従って SMTP 経由で送信メールを送信すると便利です。

スクリプトコード

# Change the hostname to be the same as the WordPress hostname
if [ ! "$(hostname)" == "${TLS_HOSTNAME}" ]; then
  echo " Changing hostname to ${TLS_HOSTNAME}"
  hostnamectl set-hostname "${TLS_HOSTNAME}"
fi

/etc/hosts にホスト名を追加する

補足 WP-クロン 定期的なタスクの実行に使用されるため、WordPress が HTTP 経由で自身にアクセスできる必要があります。 WP-Cron がすべての環境で正しく動作することを確認するために、スクリプトはファイルに行を追加します。 /etc/hostsWordPress がループバック インターフェイス経由で自身にアクセスできるようにします。

スクリプトコード

# Add the hostname to /etc/hosts
if [ "$(grep -m1 "${TLS_HOSTNAME}" /etc/hosts)" = "" ]; then
  echo " Adding hostname ${TLS_HOSTNAME} to /etc/hosts so that WordPress can ping itself"
  printf "::1 %sn127.0.0.1 %sn" "${TLS_HOSTNAME}" "${TLS_HOSTNAME}" >> /etc/hosts
fi

次のステップに必要なツールをインストールする

スクリプトの残りの部分にはいくつかのプログラムが必要であり、リポジトリが最新であることを前提としています。 リポジトリのリストを更新した後、必要なツールをインストールします。

スクリプトコード

# Make sure tools needed for install are present
echo " Installing prerequisite tools"
apt-get -qq update
apt-get -qq install -y 
  bc 
  ca-certificates 
  coreutils 
  curl 
  gnupg2 
  lsb-release

NGINX ユニットと NGINX リポジトリの追加

このスクリプトは、公式 NGINX リポジトリから NGINX ユニットとオープン ソース NGINX をインストールし、最新のセキュリティ アップデートとバグ修正が適用されたバージョンが使用されていることを確認します。

スクリプトは、NGINX Unit リポジトリを追加し、次に NGINX リポジトリを追加して、リポジトリ キーと構成ファイルを追加します。 apt、インターネット経由のリポジトリへのアクセスを定義します。

NGINX ユニットと NGINX の実際のインストールは次のセクションで行われます。 リポジトリが事前に追加されているため、メタデータを複数回更新する必要がなく、インストールが高速化されます。

スクリプトコード

# Install the NGINX Unit repository
if [ ! -f /etc/apt/sources.list.d/unit.list ]; then
  echo " Installing NGINX Unit repository"
  curl -fsSL https://nginx.org/keys/nginx_signing.key | apt-key add -
  echo "deb https://packages.nginx.org/unit/ubuntu/ $(lsb_release -cs) unit" > /etc/apt/sources.list.d/unit.list
fi

# Install the NGINX repository
if [ ! -f /etc/apt/sources.list.d/nginx.list ]; then
  echo " Installing NGINX repository"
  curl -fsSL https://nginx.org/keys/nginx_signing.key | apt-key add -
  echo "deb https://nginx.org/packages/mainline/ubuntu $(lsb_release -cs) nginx" > /etc/apt/sources.list.d/nginx.list
fi

NGINX、NGINX Unit、PHP MariaDB、Certbot (Let's Encrypt) とその依存関係のインストール

すべてのリポジトリを追加したら、メタデータを更新し、アプリケーションをインストールします。 スクリプトによってインストールされるパッケージには、WordPress.org の実行時に推奨される PHP 拡張機能も含まれています

スクリプトコード

echo " Updating repository metadata"
apt-get -qq update

# Install PHP with dependencies and NGINX Unit
echo " Installing PHP, NGINX Unit, NGINX, Certbot, and MariaDB"
apt-get -qq install -y --no-install-recommends 
  certbot 
  python3-certbot-nginx 
  php-cli 
  php-common 
  php-bcmath 
  php-curl 
  php-gd 
  php-imagick 
  php-mbstring 
  php-mysql 
  php-opcache 
  php-xml 
  php-zip 
  ghostscript 
  nginx 
  unit 
  unit-php 
  mariadb-server

NGINX ユニットおよび WordPress で使用するための PHP のセットアップ

スクリプトはディレクトリに設定ファイルを作成します conf.d。 これにより、PHP アップロードの最大ファイル サイズが設定され、STDERR への PHP エラー出力がオンになり、NGINX ユニットのログに書き込まれるようになり、NGINX ユニットが再起動されます。

スクリプトコード

# Find the major and minor PHP version so that we can write to its conf.d directory
PHP_MAJOR_MINOR_VERSION="$(php -v | head -n1 | cut -d' ' -f2 | cut -d'.' -f1,2)"

if [ ! -f "/etc/php/${PHP_MAJOR_MINOR_VERSION}/embed/conf.d/30-wordpress-overrides.ini" ]; then
  echo " Configuring PHP for use with NGINX Unit and WordPress"
  # Add PHP configuration overrides
  cat > "/etc/php/${PHP_MAJOR_MINOR_VERSION}/embed/conf.d/30-wordpress-overrides.ini" << EOM
; Set a larger maximum upload size so that WordPress can handle
; bigger media files.
upload_max_filesize=${UPLOAD_MAX_FILESIZE}
post_max_size=${UPLOAD_MAX_FILESIZE}
; Write error log to STDERR so that error messages show up in the NGINX Unit log
error_log=/dev/stderr
EOM
fi

# Restart NGINX Unit because we have reconfigured PHP
echo " Restarting NGINX Unit"
service unit restart

WordPress の MariaDB データベース設定の指定

MySQL ではなく MariaDB を選択したのは、コミュニティ活動がより多く、また、 デフォルトでより優れたパフォーマンスを提供します (おそらく、ここではすべてが簡単です。MySQL をインストールするには、別のリポジトリを追加する必要があります。、約。 翻訳者）。

スクリプトは新しいデータベースを作成し、ループバック インターフェイス経由で WordPress にアクセスするための認証情報を作成します。

スクリプトコード

# Set up the WordPress database
echo " Configuring MariaDB for WordPress"
mysqladmin create wordpress || echo "Ignoring above error because database may already exist"
mysql -e "GRANT ALL PRIVILEGES ON wordpress.* TO "wordpress"@"localhost" IDENTIFIED BY "$WORDPRESS_DB_PASSWORD"; FLUSH PRIVILEGES;"

WordPress CLI プログラムのインストール

このステップでは、スクリプトによってプログラムがインストールされます。 WP-CLI。 これを使用すると、ファイルを手動で編集したり、データベースを更新したり、コントロール パネルにアクセスしたりすることなく、WordPress 設定をインストールして管理できます。 テーマやアドオンのインストール、WordPress の更新にも使用できます。

スクリプトコード

if [ ! -f /usr/local/bin/wp ]; then
  # Install the WordPress CLI
  echo " Installing the WordPress CLI tool"
  curl --retry 6 -Ls "https://github.com/wp-cli/wp-cli/releases/download/v${WORDPRESS_CLI_VERSION}/wp-cli-${WORDPRESS_CLI_VERSION}.phar" > /usr/local/bin/wp
  echo "$WORDPRESS_CLI_MD5 /usr/local/bin/wp" | md5sum -c -
  chmod +x /usr/local/bin/wp
fi

WordPress のインストールと設定

スクリプトは、WordPress の最新バージョンをディレクトリにインストールします。 /var/www/wordpressまた、設定も変更します。

• データベース接続は、TCP トラフィックを削減するために、ループバック上の TCP ではなく Unix ドメイン ソケット上で動作します。
• WordPress はプレフィックスを追加します https:// クライアントが HTTPS 経由で NGINX に接続する場合は URL に送信し、リモート ホスト名 (NGINX によって提供される) も PHP に送信します。 これを設定するにはコードを使用します。
• WordPress のログインには HTTPS が必要です
• デフォルトの URL 構造はリソースに基づいています
• WordPress ディレクトリのファイル システムに正しいアクセス許可を設定します。

スクリプトコード

if [ ! -d /var/www/wordpress ]; then
  # Create WordPress directories
  mkdir -p /var/www/wordpress
  chown -R www-data:www-data /var/www

  # Download WordPress using the WordPress CLI
  echo " Installing WordPress"
  su -s /bin/sh -c 'wp --path=/var/www/wordpress core download' www-data

  WP_CONFIG_CREATE_CMD="wp --path=/var/www/wordpress config create --extra-php --dbname=wordpress --dbuser=wordpress --dbhost="localhost:/var/run/mysqld/mysqld.sock" --dbpass="${WORDPRESS_DB_PASSWORD}""

  # This snippet is injected into the wp-config.php file when it is created;
  # it informs WordPress that we are behind a reverse proxy and as such
  # allows it to generate links using HTTPS
  cat > /tmp/wp_forwarded_for.php << 'EOM'
/* Turn HTTPS 'on' if HTTP_X_FORWARDED_PROTO matches 'https' */
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && strpos($_SERVER['HTTP_X_FORWARDED_PROTO'], 'https') !== false) {
    $_SERVER['HTTPS'] = 'on';
}
if (isset($_SERVER['HTTP_X_FORWARDED_HOST'])) {
    $_SERVER['HTTP_HOST'] = $_SERVER['HTTP_X_FORWARDED_HOST'];
}
EOM

  # Create WordPress configuration
  su -s /bin/sh -p -c "cat /tmp/wp_forwarded_for.php | ${WP_CONFIG_CREATE_CMD}" www-data
  rm /tmp/wp_forwarded_for.php
  su -s /bin/sh -p -c "wp --path=/var/www/wordpress config set 'FORCE_SSL_ADMIN' 'true'" www-data

  # Install WordPress
  WP_SITE_INSTALL_CMD="wp --path=/var/www/wordpress core install --url="${WORDPRESS_URL}" --title="${WORDPRESS_SITE_TITLE}" --admin_user="${WORDPRESS_ADMIN_USER}" --admin_password="${WORDPRESS_ADMIN_PASSWORD}" --admin_email="${WORDPRESS_ADMIN_EMAIL}" --skip-email"
  su -s /bin/sh -p -c "${WP_SITE_INSTALL_CMD}" www-data

  # Set permalink structure to a sensible default that isn't in the UI
  su -s /bin/sh -p -c "wp --path=/var/www/wordpress option update permalink_structure '/%year%/%monthnum%/%postname%/'" www-data

  # Remove sample file because it is cruft and could be a security problem
  rm /var/www/wordpress/wp-config-sample.php

  # Ensure that WordPress permissions are correct
  find /var/www/wordpress -type d -exec chmod g+s {} ;
  chmod g+w /var/www/wordpress/wp-content
  chmod -R g+w /var/www/wordpress/wp-content/themes
  chmod -R g+w /var/www/wordpress/wp-content/plugins
fi

NGINX ユニットのセットアップ

このスクリプトは、PHP を実行して WordPress パスを処理するように NGINX ユニットを構成し、PHP プロセスの名前空間を分離し、パフォーマンス設定を最適化します。 ここで注目すべき XNUMX つの機能があります。

• 名前空間のサポートは、スクリプトがコンテナ内で実行されているかどうかのチェックに基づいて、条件によって決定されます。 ほとんどのコンテナー設定ではコンテナーのネストされた起動がサポートされていないため、これが必要になります。
• ネームスペースがサポートされている場合は、ネームスペースを無効にします。 ネットワーク。 これは、WordPress が両方のエンドポイントに接続し、同時に Web 上で利用できるようにするためです。
• プロセスの最大数は次のように定義されます。 (MariaDB および NGINX Uniy の実行に使用可能なメモリ)/(PHP の RAM 制限 + 5)
  この値は NGINX ユニット設定で設定されます。

この値は、常に少なくとも 10 つの PHP プロセスが実行されていることも意味します。これは重要です。なぜなら、WordPress はそれ自体に対して多くの非同期リクエストを作成し、追加のプロセスがないと、WP-Cron などの実行が中断してしまうからです。 ここで作成された設定は保守的であるため、ローカル設定に基づいてこれらの制限を増減することができます。 ほとんどの実稼働システムでは、設定は 100 ～ XNUMX です。

スクリプトコード

if [ "${container:-unknown}" != "lxc" ] && [ "$(grep -m1 -a container=lxc /proc/1/environ | tr -d '')" == "" ]; then
  NAMESPACES='"namespaces": {
        "cgroup": true,
        "credential": true,
        "mount": true,
        "network": false,
        "pid": true,
        "uname": true
    }'
else
  NAMESPACES='"namespaces": {}'
fi

PHP_MEM_LIMIT="$(grep 'memory_limit' /etc/php/7.4/embed/php.ini | tr -d ' ' | cut -f2 -d= | numfmt --from=iec)"
AVAIL_MEM="$(grep MemAvailable /proc/meminfo | tr -d ' kB' | cut -f2 -d: | numfmt --from-unit=K)"
MAX_PHP_PROCESSES="$(echo "${AVAIL_MEM}/${PHP_MEM_LIMIT}+5" | bc)"
echo " Calculated the maximum number of PHP processes as ${MAX_PHP_PROCESSES}. You may want to tune this value due to variations in your configuration. It is not unusual to see values between 10-100 in production configurations."

echo " Configuring NGINX Unit to use PHP and WordPress"
cat > /tmp/wordpress.json << EOM
{
  "settings": {
    "http": {
      "header_read_timeout": 30,
      "body_read_timeout": 30,
      "send_timeout": 30,
      "idle_timeout": 180,
      "max_body_size": $(numfmt --from=iec ${UPLOAD_MAX_FILESIZE})
    }
  },
  "listeners": {
    "127.0.0.1:8080": {
      "pass": "routes/wordpress"
    }
  },
  "routes": {
    "wordpress": [
      {
        "match": {
          "uri": [
            "*.php",
            "*.php/*",
            "/wp-admin/"
          ]
        },
        "action": {
          "pass": "applications/wordpress/direct"
        }
      },
      {
        "action": {
          "share": "/var/www/wordpress",
          "fallback": {
            "pass": "applications/wordpress/index"
          }
        }
      }
    ]
  },
  "applications": {
    "wordpress": {
      "type": "php",
      "user": "www-data",
      "group": "www-data",
      "processes": {
        "max": ${MAX_PHP_PROCESSES},
        "spare": 1
      },
      "isolation": {
        ${NAMESPACES}
      },
      "targets": {
        "direct": {
          "root": "/var/www/wordpress/"
        },
        "index": {
          "root": "/var/www/wordpress/",
          "script": "index.php"
        }
      }
    }
  }
}
EOM

curl -X PUT --data-binary @/tmp/wordpress.json --unix-socket /run/control.unit.sock http://localhost/config

NGINXのセットアップ

基本的な NGINX 設定の構成

スクリプトは NGINX キャッシュ用のディレクトリを作成し、メインの構成ファイルを作成します。 nginx.conf。 ハンドラプロセス数とアップロード時の最大ファイルサイズの設定に注意してください。 次のセクションで定義する圧縮設定ファイルを含む行と、その後にキャッシュ設定が続く行もあります。

スクリプトコード

# Make directory for NGINX cache
mkdir -p /var/cache/nginx/proxy

echo " Configuring NGINX"
cat > ${NGINX_CONF_DIR}/nginx.conf << EOM
user nginx;
worker_processes auto;
error_log  /var/log/nginx/error.log warn;
pid        /var/run/nginx.pid;
events {
    worker_connections  1024;
}
http {
    include       ${NGINX_CONF_DIR}/mime.types;
    default_type  application/octet-stream;
    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';
    access_log  /var/log/nginx/access.log  main;
    sendfile        on;
    client_max_body_size ${UPLOAD_MAX_FILESIZE};
    keepalive_timeout  65;
    # gzip settings
    include ${NGINX_CONF_DIR}/gzip_compression.conf;
    # Cache settings
    proxy_cache_path /var/cache/nginx/proxy
        levels=1:2
        keys_zone=wp_cache:10m
        max_size=10g
        inactive=60m
        use_temp_path=off;
    include ${NGINX_CONF_DIR}/conf.d/*.conf;
}
EOM

NGINX 圧縮のセットアップ

クライアントに送信する前にコンテンツをその場で圧縮することは、サイトのパフォーマンスを向上させる優れた方法ですが、これは圧縮が正しく構成されている場合に限ります。 スクリプトのこのセクションは設定に基づいています 故に.

スクリプトコード

cat > ${NGINX_CONF_DIR}/gzip_compression.conf << 'EOM'
# Credit: https://github.com/h5bp/server-configs-nginx/
# ----------------------------------------------------------------------
# | Compression                                                        |
# ----------------------------------------------------------------------
# https://nginx.org/en/docs/http/ngx_http_gzip_module.html
# Enable gzip compression.
# Default: off
gzip on;
# Compression level (1-9).
# 5 is a perfect compromise between size and CPU usage, offering about 75%
# reduction for most ASCII files (almost identical to level 9).
# Default: 1
gzip_comp_level 6;
# Don't compress anything that's already small and unlikely to shrink much if at
# all (the default is 20 bytes, which is bad as that usually leads to larger
# files after gzipping).
# Default: 20
gzip_min_length 256;
# Compress data even for clients that are connecting to us via proxies,
# identified by the "Via" header (required for CloudFront).
# Default: off
gzip_proxied any;
# Tell proxies to cache both the gzipped and regular version of a resource
# whenever the client's Accept-Encoding capabilities header varies;
# Avoids the issue where a non-gzip capable client (which is extremely rare
# today) would display gibberish if their proxy gave them the gzipped version.
# Default: off
gzip_vary on;
# Compress all output labeled with one of the following MIME-types.
# `text/html` is always compressed by gzip module.
# Default: text/html
gzip_types
  application/atom+xml
  application/geo+json
  application/javascript
  application/x-javascript
  application/json
  application/ld+json
  application/manifest+json
  application/rdf+xml
  application/rss+xml
  application/vnd.ms-fontobject
  application/wasm
  application/x-web-app-manifest+json
  application/xhtml+xml
  application/xml
  font/eot
  font/otf
  font/ttf
  image/bmp
  image/svg+xml
  text/cache-manifest
  text/calendar
  text/css
  text/javascript
  text/markdown
  text/plain
  text/xml
  text/vcard
  text/vnd.rim.location.xloc
  text/vtt
  text/x-component
  text/x-cross-domain-policy;
EOM

WordPress 用の NGINX のセットアップ

次に、スクリプトは WordPress の構成ファイルを作成します。 デフォルト.conf カタログにある conf.d。 ここで設定されます:

• Certbot 経由で Let's Encrypt から受信した TLS 証明書をアクティブ化します (セットアップについては次のセクションで説明します)。
• Let's Encrypt の推奨事項に基づいて TLS セキュリティ設定を構成する
• デフォルトで 1 時間のキャッシュ スキップ リクエストを有効にする
• XNUMX つの一般的な要求ファイル (favicon.ico および robots.txt) について、アクセス ログを無効にし、ファイルが見つからない場合のエラー ログも無効にします。
• 隠しファイルおよび一部のファイルへのアクセスを禁止する 。PHPの不正アクセスや意図しない起動を防ぐため
• 静的ファイルとフォント ファイルのアクセス ログを無効にする
• ヘッダー設定 アクセス制御許可オリジン フォントファイル用
• Index.php およびその他の静的ファイルのルーティングを追加します。

スクリプトコード

cat > ${NGINX_CONF_DIR}/conf.d/default.conf << EOM
upstream unit_php_upstream {
    server 127.0.0.1:8080;
    keepalive 32;
}
server {
    listen 80;
    listen [::]:80;
    # ACME-challenge used by Certbot for Let's Encrypt
    location ^~ /.well-known/acme-challenge/ {
      root /var/www/certbot;
    }
    location / {
      return 301 https://${TLS_HOSTNAME}$request_uri;
    }
}
server {
    listen      443 ssl http2;
    listen [::]:443 ssl http2;
    server_name ${TLS_HOSTNAME};
    root        /var/www/wordpress/;
    # Let's Encrypt configuration
    ssl_certificate         ${CERT_DIR}/fullchain.pem;
    ssl_certificate_key     ${CERT_DIR}/privkey.pem;
    ssl_trusted_certificate ${CERT_DIR}/chain.pem;
    include ${NGINX_CONF_DIR}/options-ssl-nginx.conf;
    ssl_dhparam ${NGINX_CONF_DIR}/ssl-dhparams.pem;
    # OCSP stapling
    ssl_stapling on;
    ssl_stapling_verify on;
    # Proxy caching
    proxy_cache wp_cache;
    proxy_cache_valid 200 302 1h;
    proxy_cache_valid 404 1m;
    proxy_cache_revalidate on;
    proxy_cache_background_update on;
    proxy_cache_lock on;
    proxy_cache_use_stale error timeout http_500 http_502 http_503 http_504;
    location = /favicon.ico {
        log_not_found off;
        access_log off;
    }
    location = /robots.txt {
        allow all;
        log_not_found off;
        access_log off;
    }

    # Deny all attempts to access hidden files such as .htaccess, .htpasswd,
    # .DS_Store (Mac)
    # Keep logging the requests to parse later (or to pass to firewall utilities
    # such as fail2ban)
    location ~ /. {
        deny all;
    }
    # Deny access to any files with a .php extension in the uploads directory;
    # works in subdirectory installs and also in multi-site network.
    # Keep logging the requests to parse later (or to pass to firewall utilities
    # such as fail2ban).
    location ~* /(?:uploads|files)/.*.php$ {
        deny all;
    }
    # WordPress: deny access to wp-content, wp-includes PHP files
    location ~* ^/(?:wp-content|wp-includes)/.*.php$ {
        deny all;
    }
    # Deny public access to wp-config.php
    location ~* wp-config.php {
        deny all;
    }
    # Do not log access for static assets, media
    location ~* .(?:css(.map)?|js(.map)?|jpe?g|png|gif|ico|cur|heic|webp|tiff?|mp3|m4a|aac|ogg|midi?|wav|mp4|mov|webm|mpe?g|avi|ogv|flv|wmv)$ {
        access_log off;
    }
    location ~* .(?:svgz?|ttf|ttc|otf|eot|woff2?)$ {
        add_header Access-Control-Allow-Origin "*";
        access_log off;
    }
    location / {
        try_files $uri @index_php;
    }
    location @index_php {
        proxy_socket_keepalive on;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Host $host;
        proxy_pass       http://unit_php_upstream;
    }
    location ~* .php$ {
        proxy_socket_keepalive on;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Host $host;
        try_files        $uri =404;
        proxy_pass       http://unit_php_upstream;
    }
}
EOM

Let's Encrypt からの証明書用の Certbot のセットアップと自動更新

Certbot は、Electronic Frontier Foundation (EFF) が提供する無料ツールで、Let's Encrypt から TLS 証明書を取得して自動的に更新できるようにします。 このスクリプトは次の処理を実行して、NGINX で Let's Encrypt からの証明書を処理するように Certbot を構成します。

• NGINXを停止します
• 推奨される TLS 設定をダウンロードします
• Certbot を実行してサイトの証明書を取得します
• 証明書を使用するために NGINX を再起動します
• Certbot を毎日午前 3 時 24 分に実行して証明書を更新する必要があるかどうかを確認し、必要に応じて新しい証明書をダウンロードして NGINX を再起動するように構成します。

スクリプトコード

echo " Stopping NGINX in order to set up Let's Encrypt"
service nginx stop

mkdir -p /var/www/certbot
chown www-data:www-data /var/www/certbot
chmod g+s /var/www/certbot

if [ ! -f ${NGINX_CONF_DIR}/options-ssl-nginx.conf ]; then
  echo " Downloading recommended TLS parameters"
  curl --retry 6 -Ls -z "Tue, 14 Apr 2020 16:36:07 GMT" 
    -o "${NGINX_CONF_DIR}/options-ssl-nginx.conf" 
    "https://raw.githubusercontent.com/certbot/certbot/master/certbot-nginx/certbot_nginx/_internal/tls_configs/options-ssl-nginx.conf" 
    || echo "Couldn't download latest options-ssl-nginx.conf"
fi

if [ ! -f ${NGINX_CONF_DIR}/ssl-dhparams.pem ]; then
  echo " Downloading recommended TLS DH parameters"
  curl --retry 6 -Ls -z "Tue, 14 Apr 2020 16:49:18 GMT" 
    -o "${NGINX_CONF_DIR}/ssl-dhparams.pem" 
    "https://raw.githubusercontent.com/certbot/certbot/master/certbot/certbot/ssl-dhparams.pem" 
    || echo "Couldn't download latest ssl-dhparams.pem"
fi

# If tls_certs_init.sh hasn't been run before, remove the self-signed certs
if [ ! -d "/etc/letsencrypt/accounts" ]; then
  echo " Removing self-signed certificates"
  rm -rf "${CERT_DIR}"
fi

if [ "" = "${LETS_ENCRYPT_STAGING:-}" ] || [ "0" = "${LETS_ENCRYPT_STAGING}" ]; then
  CERTBOT_STAGING_FLAG=""
else
  CERTBOT_STAGING_FLAG="--staging"
fi

if [ ! -f "${CERT_DIR}/fullchain.pem" ]; then
  echo " Generating certificates with Let's Encrypt"
  certbot certonly --standalone 
         -m "${WORDPRESS_ADMIN_EMAIL}" 
         ${CERTBOT_STAGING_FLAG} 
         --agree-tos --force-renewal --non-interactive 
         -d "${TLS_HOSTNAME}"
fi

echo " Starting NGINX in order to use new configuration"
service nginx start

# Write crontab for periodic Let's Encrypt cert renewal
if [ "$(crontab -l | grep -m1 'certbot renew')" == "" ]; then
  echo " Adding certbot to crontab for automatic Let's Encrypt renewal"
  (crontab -l 2>/dev/null; echo "24 3 * * * certbot renew --nginx --post-hook 'service nginx reload'") | crontab -
fi

サイトの追加のカスタマイズ

上では、TLSSSL が有効になっている本番環境に対応したサイトを提供するために、スクリプトが NGINX と NGINX Unit を構成する方法について説明しました。 必要に応じて、将来的に以下を追加することもできます。

• サポート ブロトリ、HTTPS を介したオンザフライ圧縮の改善
• ModSecurityは с ワードプレスのルールサイトへの自動攻撃を防ぐため
• バックアップする あなたに合ったWordPressを
• 保護 経由 AppArmor (Ubuntu 上)
• Postfix または msmtp (WordPress がメールを送信できるようにする)
• サイトをチェックして、処理できるトラフィック量を把握する

サイトのパフォーマンスをさらに向上させるには、次のようにアップグレードすることをお勧めします。 NGINX プラス、オープンソース NGINX をベースにした商用エンタープライズ グレードの製品です。 その加入者は、動的にロードされる Brotli モジュールを受け取るだけでなく、(追加料金で) NGINX ModSecurity WAF。 もご用意しております NGINX アプリプロテクト、F5 の業界をリードするセキュリティ テクノロジーに基づく NGINX Plus 用の WAF モジュール。

N.B. 高負荷のサイトのサポートについては、専門家にお問い合わせください。 サウスブリッジ。 あらゆる負荷の下でも、お客様の Web サイトやサービスの高速かつ信頼性の高い動作を保証します。

出所： habr.com