Mengautomasikan pemasangan WordPress dengan Unit NGINX dan Ubuntu

Mengautomasikan pemasangan WordPress dengan Unit NGINX dan Ubuntu

Terdapat banyak bahan di luar sana untuk memasang WordPress; carian Google untuk "pemasangan WordPress" akan mengembalikan kira-kira setengah juta hasil. Walau bagaimanapun, sebenarnya terdapat sangat sedikit panduan berguna di luar sana yang boleh membantu anda memasang dan mengkonfigurasi WordPress dan sistem pengendalian asas supaya ia boleh disokong dalam jangka masa yang panjang. Mungkin tetapan yang betul sangat bergantung pada keperluan khusus anda, atau mungkin kerana penjelasan terperinci membuat artikel sukar dibaca.

Dalam artikel ini, kami akan cuba mengumpulkan yang terbaik daripada kedua-dua dunia dengan menyediakan skrip bash untuk memasang WordPress secara automatik pada Ubuntu, dan kami akan meneruskannya, menerangkan perkara yang dilakukan oleh setiap bahagian dan pertukaran yang kami buat dalam mereka bentuk ia. Jika anda seorang pengguna yang berpengalaman, anda boleh melangkau teks artikel dan hanya ambil skrip untuk pengubahsuaian dan penggunaan dalam persekitaran anda. Output skrip ialah pemasangan WordPress tersuai dengan sokongan Lets Encrypt, berjalan pada Unit NGINX dan sesuai untuk kegunaan industri.

Seni bina yang dibangunkan untuk menggunakan WordPress menggunakan Unit NGINX diterangkan dalam artikel lama, kini kami juga akan mengkonfigurasi lebih lanjut perkara yang tidak dibincangkan di sana (seperti dalam banyak tutorial lain):

  • WordPress CLI
  • Sijil Let's Encrypt dan TLSSSL
  • Pembaharuan sijil automatik
  • Caching NGINX
  • pemampatan NGINX
  • Sokongan HTTPS dan HTTP/2
  • Automasi proses

Artikel ini akan menerangkan pemasangan pada satu pelayan, yang pada masa yang sama akan menjadi hos pelayan pemprosesan statik, pelayan pemprosesan PHP dan pangkalan data. Pemasangan dengan sokongan untuk berbilang hos dan perkhidmatan maya merupakan topik yang berpotensi untuk masa hadapan. Jika anda mahu kami menulis tentang sesuatu yang tiada dalam artikel ini, tulis dalam komen.

Keperluan

  • Bekas pelayan (LXC atau LXD), mesin maya, atau pelayan perkakasan biasa, dengan sekurang-kurangnya 512MB RAM dan Ubuntu 18.04 atau lebih baru dipasang.
  • Port boleh diakses Internet 80 dan 443
  • Nama domain yang dikaitkan dengan alamat IP awam pelayan ini
  • Akses dengan hak akar (sudo).

Gambaran keseluruhan seni bina

Seni bina adalah sama seperti yang diterangkan sebelum ini, aplikasi web tiga peringkat. Ia terdiri daripada skrip PHP yang dilaksanakan pada enjin PHP dan fail statik yang diproses oleh pelayan web.

Mengautomasikan pemasangan WordPress dengan Unit NGINX dan Ubuntu

Prinsip umum

  • Banyak arahan konfigurasi dalam skrip dibalut jika syarat untuk mati pucuk: skrip boleh dijalankan beberapa kali tanpa risiko menukar tetapan yang sudah sedia.
  • Skrip cuba memasang perisian dari repositori, jadi anda boleh menggunakan kemas kini sistem dalam satu arahan (apt upgrade untuk Ubuntu).
  • Pasukan cuba mengesan bahawa mereka sedang berjalan dalam bekas supaya mereka boleh menukar tetapan mereka dengan sewajarnya.
  • Untuk menetapkan bilangan proses benang yang akan dilancarkan dalam tetapan, skrip cuba meneka tetapan automatik untuk bekerja dalam bekas, mesin maya dan pelayan perkakasan.
  • Apabila menerangkan tetapan, kami sentiasa memikirkan dahulu tentang automasi, yang kami harap akan menjadi asas untuk mencipta infrastruktur anda sendiri sebagai kod.
  • Semua arahan dijalankan daripada pengguna akar, kerana mereka menukar tetapan sistem asas, tetapi WordPress sendiri berjalan sebagai pengguna biasa.

Menetapkan pembolehubah persekitaran

Tetapkan pembolehubah persekitaran berikut sebelum menjalankan skrip:

  • WORDPRESS_DB_PASSWORD β€” Kata laluan pangkalan data WordPress
  • WORDPRESS_ADMIN_USER - Nama pengguna pentadbir WordPress
  • WORDPRESS_ADMIN_PASSWORD - Kata laluan pentadbir WordPress
  • WORDPRESS_ADMIN_EMAIL β€” E-mel pentadbir WordPress
  • WORDPRESS_URL – URL penuh tapak WordPress, bermula dengan https://.
  • LETS_ENCRYPT_STAGING β€” kosong secara lalai, tetapi dengan menetapkan nilai kepada 1, anda akan menggunakan pelayan pementasan Let's Encrypt, yang diperlukan untuk kerap meminta sijil semasa menguji tetapan anda, jika tidak, Let's Encrypt mungkin menyekat alamat IP anda buat sementara waktu kerana bilangan permintaan yang banyak.

Skrip menyemak bahawa pembolehubah berkaitan WordPress ini ditetapkan dan keluar jika tidak.
Baris skrip 572-576 semak nilai LETS_ENCRYPT_STAGING.

Menetapkan pembolehubah persekitaran terbitan

Skrip pada baris 55-61 menetapkan pembolehubah persekitaran berikut, sama ada kepada beberapa nilai berkod keras atau menggunakan nilai yang diperoleh daripada pembolehubah yang ditetapkan dalam bahagian sebelumnya:

  • DEBIAN_FRONTEND="noninteractive" β€” memberitahu aplikasi bahawa mereka berjalan dalam skrip dan tidak ada kemungkinan interaksi pengguna.
  • WORDPRESS_CLI_VERSION="2.4.0" β€” Versi WordPress CLI aplikasi.
  • WORDPRESS_CLI_MD5= "dedd5a662b80cda66e9e25d44c23b25c" β€” checksum fail boleh laku WordPress CLI 2.4.0 (versi ditunjukkan dalam pembolehubah WORDPRESS_CLI_VERSION). Skrip pada baris 162 menggunakan nilai ini untuk mengesahkan bahawa fail CLI WordPress yang betul telah dimuat turun.
  • UPLOAD_MAX_FILESIZE="16M" β€” saiz fail maksimum yang boleh dimuat naik ke WordPress. Tetapan ini digunakan di beberapa tempat, jadi lebih mudah untuk menetapkannya di satu tempat.
  • TLS_HOSTNAME= "$(echo ${WORDPRESS_URL} | cut -d'/' -f3)" β€” nama hos sistem, diekstrak daripada pembolehubah WORDPRESS_URL. Digunakan untuk mendapatkan sijil TLS/SSL yang sesuai daripada Let's Encrypt, serta untuk pengesahan WordPress dalaman.
  • NGINX_CONF_DIR="/etc/nginx" β€” laluan ke direktori dengan tetapan NGINX, termasuk fail utama nginx.conf.
  • CERT_DIR="/etc/letsencrypt/live/${TLS_HOSTNAME}" β€” laluan ke sijil Let's Encrypt untuk tapak WordPress, diperoleh daripada pembolehubah TLS_HOSTNAME.

Menetapkan nama hos kepada pelayan WordPress

Skrip menetapkan nama hos pelayan supaya nilai sepadan dengan nama domain tapak. Ini tidak perlu, tetapi lebih mudah untuk menghantar mel keluar melalui SMTP apabila menyediakan pelayan tunggal, seperti yang dikonfigurasikan oleh skrip.

kod skrip

# 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

Menambah nama hos pada /etc/hosts

Penambahan WP‑Cron digunakan untuk menjalankan tugas berkala, memerlukan WordPress boleh mengakses dirinya sendiri melalui HTTP. Untuk memastikan bahawa WP-Cron berfungsi dengan betul dalam semua persekitaran, skrip menambah baris pada fail / Etc / tuan rumahsupaya WordPress boleh mengakses dirinya melalui antara muka gelung balik:

kod skrip

# 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

Memasang alatan yang diperlukan untuk langkah seterusnya

Selebihnya skrip memerlukan beberapa program dan menganggap bahawa repositori adalah terkini. Kami mengemas kini senarai repositori, dan kemudian memasang alat yang diperlukan:

kod skrip

# 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

Menambah repositori Unit NGINX dan NGINX

Skrip memasang Unit NGINX dan NGINX sumber terbuka daripada repositori NGINX rasmi untuk memastikan bahawa versi dengan kemas kini keselamatan terkini dan pembetulan pepijat digunakan.

Skrip menambah repositori Unit NGINX dan kemudian repositori NGINX, menambah kunci repositori dan fail tetapan apt, mentakrifkan akses kepada repositori melalui Internet.

Pemasangan sebenar Unit NGINX dan NGINX berlaku di bahagian seterusnya. Kami pra-menambah repositori untuk mengelakkan mengemas kini metadata berbilang kali, menjadikan pemasangan lebih pantas.

kod skrip

# 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

Memasang NGINX, Unit NGINX, PHP MariaDB, Certbot (Let's Encrypt) dan kebergantungannya

Setelah semua repositori ditambahkan, kami mengemas kini metadata dan memasang aplikasi. Pakej yang dipasang oleh skrip juga termasuk sambungan PHP yang disyorkan semasa menjalankan WordPress.org

kod skrip

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

Menyediakan PHP untuk digunakan dengan Unit NGINX dan WordPress

Skrip mencipta fail tetapan dalam direktori conf.d. Ini menetapkan saiz muat naik fail maksimum untuk PHP, membolehkan ralat PHP dikeluarkan kepada STDERR supaya ia akan dilog masuk ke Unit NGINX dan memulakan semula Unit NGINX.

kod skrip

# 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

Menetapkan Tetapan Pangkalan Data MariaDB untuk WordPress

Kami memilih MariaDB berbanding MySQL kerana ia mempunyai lebih banyak aktiviti komuniti dan boleh juga memberikan prestasi yang lebih baik secara lalai (Mungkin, semuanya lebih mudah di sini: untuk memasang MySQL, anda perlu menambah repositori lain, lebih kurang. penterjemah).

Skrip mencipta pangkalan data baharu dan mencipta kelayakan akses WordPress melalui antara muka gelung balik:

kod skrip

# 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;"

Memasang program CLI WordPress

Pada langkah ini skrip memasang program WP-CLI. Dengan itu, anda boleh memasang dan mengurus tetapan WordPress tanpa perlu mengedit fail secara manual, mengemas kini pangkalan data atau log masuk ke panel kawalan. Ia juga boleh digunakan untuk memasang tema dan alat tambah serta mengemas kini WordPress.

kod skrip

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

Memasang dan Mengkonfigurasi WordPress

Skrip memasang versi terkini WordPress ke dalam direktori /var/www/wordpress, dan juga menukar tetapan:

  • Sambungan pangkalan data berfungsi melalui soket domain unix dan bukannya TCP pada gelung balik untuk mengurangkan trafik TCP.
  • WordPress menambah awalan https:// ke URL jika pelanggan menyambung ke NGINX melalui HTTPS, dan juga menghantar nama hos jauh (seperti yang disediakan oleh NGINX) ke PHP. Kami menggunakan sekeping kod untuk menyediakannya.
  • WordPress memerlukan HTTPS untuk log masuk
  • Struktur URL secara senyap berasaskan sumber
  • Kebenaran sistem fail yang betul ditetapkan untuk direktori WordPress.

kod skrip

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

Menyediakan Unit NGINX

Skrip mengkonfigurasi Unit NGINX untuk menjalankan PHP dan mengendalikan laluan WordPress, mengasingkan ruang nama proses PHP dan mengoptimumkan tetapan prestasi. Terdapat tiga ciri yang patut diberi perhatian:

  • Sokongan ruang nama ditentukan oleh syarat, berdasarkan pemeriksaan bahawa skrip berjalan dalam bekas. Ini adalah perlu kerana kebanyakan persediaan bekas tidak menyokong penggunaan bersarang bekas.
  • Jika terdapat sokongan untuk ruang nama, ruang nama dilumpuhkan rangkaian. Ini adalah perlu untuk membolehkan WordPress menyambung secara serentak ke titik akhir dan boleh diakses di Internet.
  • Bilangan maksimum proses ditentukan seperti berikut: (Memori yang tersedia untuk menjalankan MariaDB dan NGINX Uniy)/(had RAM dalam PHP + 5)
    Nilai ini ditetapkan dalam tetapan Unit NGINX.

Nilai ini juga membayangkan bahawa sentiasa terdapat sekurang-kurangnya dua proses PHP yang sedang berjalan, yang penting kerana WordPress membuat banyak permintaan tak segerak kepada dirinya sendiri, dan tanpa proses tambahan berjalan, sebagai contoh, WP-Cron akan rosak. Anda mungkin mahu menambah atau mengurangkan had ini berdasarkan tetapan setempat anda, kerana tetapan yang dibuat di sini adalah konservatif. Pada kebanyakan sistem pengeluaran tetapan adalah antara 10 dan 100.

kod skrip

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

Menyediakan NGINX

Mengkonfigurasi Tetapan NGINX Asas

Skrip mencipta direktori untuk cache NGINX dan kemudian mencipta fail konfigurasi utama nginx.conf. Beri perhatian kepada bilangan proses pengendali dan tetapan saiz fail maksimum untuk dimuat turun. Terdapat juga baris di mana fail tetapan mampatan, yang ditakrifkan dalam bahagian seterusnya, disambungkan, diikuti dengan tetapan caching.

kod skrip

# 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

Menyediakan pemampatan NGINX

Memampatkan kandungan dengan segera sebelum menghantarnya kepada pelanggan ialah cara terbaik untuk meningkatkan prestasi tapak, tetapi hanya jika pemampatan dikonfigurasikan dengan betul. Bahagian skrip ini adalah berdasarkan tetapan oleh itu.

kod skrip

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

Menyediakan NGINX untuk WordPress

Seterusnya, skrip mencipta fail konfigurasi untuk WordPress default.conf dalam katalog conf.d. Di sini ia dikonfigurasikan:

  • Mengaktifkan sijil TLS yang diterima daripada Let's Encrypt melalui Certbot (mengkonfigurasinya akan berada di bahagian seterusnya)
  • Konfigurasikan tetapan keselamatan TLS berdasarkan pengesyoran daripada Let's Encrypt
  • Dayakan caching permintaan yang dilangkau selama 1 jam secara lalai
  • Lumpuhkan pengelogan akses, serta pengelogan ralat jika fail tidak ditemui, untuk dua fail yang biasa diminta: favicon.ico dan robots.txt
  • Tolak akses kepada fail tersembunyi dan beberapa fail .phpuntuk menghalang akses haram atau pelancaran yang tidak disengajakan
  • Lumpuhkan pengelogan akses untuk fail statik dan fon
  • Menetapkan tajuk Akses-Kawalan-Benarkan-Asal untuk fail fon
  • Menambah penghalaan untuk index.php dan statik lain.

kod skrip

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

Mengkonfigurasi Certbot untuk sijil Let's Encrypt dan memperbaharuinya secara automatik

Certbot ialah alat percuma daripada Electronic Frontier Foundation (EFF) yang membolehkan anda mendapatkan dan memperbaharui sijil TLS secara automatik daripada Let's Encrypt. Skrip melakukan langkah berikut untuk mengkonfigurasi Certbot untuk memproses sijil daripada Let's Encrypt dalam NGINX:

  • Hentikan NGINX
  • Muat turun tetapan TLS yang disyorkan
  • Menjalankan Certbot untuk mendapatkan sijil untuk tapak
  • Mulakan semula NGINX untuk menggunakan sijil
  • Mengkonfigurasikan Certbot untuk dijalankan setiap hari pada 3:24 a.m. untuk menyemak pembaharuan sijil dan, jika perlu, muat turun sijil baharu dan mulakan semula NGINX.

kod skrip

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

Penyesuaian tambahan tapak anda

Kami bercakap di atas tentang cara skrip kami mengkonfigurasi Unit NGINX dan NGINX untuk menyediakan tapak web sedia pengeluaran dengan TLSSSL didayakan. Anda juga boleh, bergantung pada keperluan anda, menambah pada masa hadapan:

  • Sokongan Brotli, dipertingkatkan pemampatan on-the-fly melalui HTTPS
  • ModSecurity с peraturan untuk WordPressuntuk mengelakkan serangan automatik pada tapak anda
  • Sandaran untuk WordPress, sesuai untuk anda
  • Perlindungan melalui AppArmor (pada Ubuntu)
  • Postfix atau msmtp supaya WordPress boleh menghantar mel
  • Menyemak tapak anda supaya anda memahami jumlah trafik yang boleh dikendalikannya

Untuk prestasi tapak yang lebih baik, kami mengesyorkan anda menaik taraf kepada NGINX Plus, produk komersial gred perusahaan kami berdasarkan NGINX sumber terbuka. Pelanggannya akan menerima modul Brotli yang dimuatkan secara dinamik, serta (dengan bayaran tambahan) NGINX ModSecurity WAF. Kami juga menawarkan NGINX App Protect, modul WAF untuk NGINX Plus berdasarkan teknologi keselamatan terkemuka industri daripada F5.

NB Untuk sokongan tapak web dengan muatan tinggi, anda boleh menghubungi pakar Southbridge. Kami akan memastikan operasi tapak web atau perkhidmatan anda yang pantas dan boleh dipercayai di bawah sebarang beban.

Sumber: www.habr.com