🥇Mes automatizuojame diegimą WordPress su NGINX bloku ir Ubuntu

Yra daug montavimo medžiagų. WordPress, „Google“ paieška pagal raktinius žodžius "WordPress „install“ pateiks apie pusę milijono rezultatų. Tačiau tarp jų iš tikrųjų yra labai mažai naudingų diegimo ir konfigūravimo vadovų. WordPress ir pagrindinę operacinę sistemą, kad juos būtų galima palaikyti ilgą laiką. Galbūt teisingi nustatymai labai priklauso nuo konkrečių poreikių arba galbūt taip yra todėl, kad išsamus paaiškinimas apsunkina straipsnio skaitymą.

Šiame straipsnyje pabandysime sujungti geriausias abiejų metodų savybes, pateikdami „bash“ scenarijų automatiniam diegimui. WordPress apie UbuntuTaip pat apžvelgsime kiekvieną dalį, paaiškindami, ką daro kiekviena dalis ir kokius kompromisus padarėme ją kurdami. Jei esate patyręs vartotojas, galite praleisti tekstą ir tiesiog paimk scenarijų modifikavimui ir naudojimui jūsų aplinkoje. Scenarijaus išvestis yra pasirinktinis diegimas. WordPress su „Let's Encrypt“ palaikymu, veikia NGINX įrenginyje ir tinka naudoti gamybinėje aplinkoje.

Sukurta diegimo architektūra WordPress NGINX vieneto naudojimas aprašytas senesnis straipsnis, dabar taip pat toliau konfigūruosime dalykus, kurie ten nebuvo aprašyti (kaip ir daugelyje kitų mokymo programų):

WordPress CLI
Užšifruokime ir TLSSSL sertifikatus
Automatinis sertifikato atnaujinimas
NGINX talpyklos kaupimas
NGINX suspaudimas
HTTPS ir HTTP/2 palaikymas
Procesų automatizavimas

Straipsnyje bus aprašytas diegimas viename serveryje, kuriame vienu metu bus statinio apdorojimo serveris, PHP apdorojimo serveris ir duomenų bazė. Diegimas su kelių virtualių kompiuterių ir paslaugų palaikymu yra potenciali ateities tema. Jei norite, kad parašytume apie tai, ko nėra šiuose straipsniuose, parašykite komentaruose.

Reikalavimai

Serverio konteineris (LXC arba LXD), virtuali mašina arba įprastas aparatinės įrangos serveris, turintis bent 512 MB RAM ir įdiegtą Ubuntu 18.04 arba vėliau.
Internetu pasiekiami 80 ir 443 prievadai
Domeno pavadinimas, susietas su šio serverio viešuoju IP adresu
Prieiga su root teisėmis (sudo).

Architektūros apžvalga

Architektūra yra tokia pati, kaip aprašyta anksčiau, trijų pakopų žiniatinklio programa. Jį sudaro PHP scenarijai, vykdomi PHP variklyje, ir statiniai failai, apdorojami žiniatinklio serverio.

Bendrieji principai

Daugelis scenarijaus konfigūravimo komandų yra įtrauktos į idempotencijos sąlygas: scenarijus gali būti paleistas kelis kartus, nerizikuojant pakeisti jau paruoštus parametrus.
Scenarijus bando įdiegti programinę įrangą iš saugyklų, kad galėtumėte pritaikyti sistemos naujinimus viena komanda (apt upgrade už Ubuntu).
Komandos bando aptikti, kad jos veikia konteineryje, kad galėtų atitinkamai pakeisti nustatymus.
Siekdamas nustatymuose nustatyti paleidžiamų gijų procesų skaičių, scenarijus bando atspėti automatinius darbo konteineriuose, virtualiose mašinose ir aparatinės įrangos serveriuose nustatymus.
Apibūdindami nustatymus, visada pirmiausia galvojame apie automatizavimą, kuris, tikimės, taps pagrindu kuriant savo infrastruktūrą kaip kodą.
Visos komandos vykdomos iš vartotojo šaknis, nes jie keičia pagrindinius sistemos nustatymus, bet tiesiogiai WordPress veikia iš įprasto vartotojo.

Aplinkos kintamųjų nustatymas

Prieš paleisdami scenarijų nustatykite šiuos aplinkos kintamuosius:

WORDPRESS_DB_PASSWORD — slaptažodis į duomenų bazę WordPress
WORDPRESS_ADMIN_USER — administratoriaus vardas WordPress
WORDPRESS_ADMIN_PASSWORD — administratoriaus slaptažodis WordPress
WORDPRESS_ADMIN_EMAIL — administratoriaus el. pašto adresas WordPress
WORDPRESS_URL — visas svetainės URL WordPressNuo https://.
LETS_ENCRYPT_STAGING — pagal numatytuosius nustatymus tuščias, tačiau nustačius reikšmę 1, naudosite Let's Encrypt sustojimo serverius, kurie yra būtini norint dažnai prašyti sertifikatų tikrinant nustatymus, kitu atveju Let's Encrypt dėl didelio užklausų skaičiaus gali laikinai užblokuoti jūsų IP adresą.

Scenarijus patikrina, ar šie susiję WordPress kintamieji yra nustatyti ir išeina, jei ne.
Scenarijaus eilutės 572–576 patikrina reikšmę LETS_ENCRYPT_STAGING.

Išvestinių aplinkos kintamųjų nustatymas

55–61 eilutėse esantis scenarijus nustato šiuos aplinkos kintamuosius į tam tikrą užkoduotą reikšmę arba naudodamas vertę, gautą iš ankstesniame skyriuje nustatytų kintamųjų:

DEBIAN_FRONTEND="noninteractive" — nurodo programoms, kad jos veikia pagal scenarijų ir nėra galimybės vartotojui sąveikauti.
WORDPRESS_CLI_VERSION="2.4.0" — programos versija WordPress CLI.
WORDPRESS_CLI_MD5= "dedd5a662b80cda66e9e25d44c23b25c" — vykdomojo failo kontrolinė suma WordPress CLI 2.4.0 (versija nurodyta kintamajame WORDPRESS_CLI_VERSION). 162 eilutėje esantis scenarijus naudoja šią reikšmę, kad patikrintų, ar atsisiųstas teisingas failas. WordPress CLI.
UPLOAD_MAX_FILESIZE="16M" — maksimalus įkeliamo failo dydis WordPressŠis nustatymas naudojamas keliose vietose, todėl jį lengviau nustatyti vienoje vietoje.
TLS_HOSTNAME= "$(echo ${WORDPRESS_URL} | cut -d'/' -f3)" — sistemos pagrindinio kompiuterio pavadinimas, gautas iš WORDPRESS_URL kintamojo. Naudojamas norint gauti atitinkamus TLS/SSL sertifikatus iš „Let's Encrypt“, taip pat vidiniam patikrinimui. WordPress.
NGINX_CONF_DIR="/etc/nginx" — kelias į katalogą su NGINX nustatymais, įskaitant pagrindinį failą nginx.conf.
CERT_DIR="/etc/letsencrypt/live/${TLS_HOSTNAME}" — kelias į svetainės „Let's Encrypt“ sertifikatus WordPress, gautas iš kintamojo TLS_HOSTNAME.

Pagrindinio kompiuterio pavadinimo priskyrimas WordPress serveris

Scenarijus nustato serverio pagrindinio kompiuterio pavadinimą taip, kad reikšmė atitiktų svetainės domeno pavadinimą. Tai nėra būtina, tačiau patogiau siųsti siunčiamus laiškus per SMTP, kai nustatomas vienas serveris, kaip sukonfigūruotas scenarijus.

scenarijaus kodas

# 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

Prieglobos pavadinimo pridėjimas prie /etc/hosts

Papildymas WP-Cron naudojamas periodinėms užduotims vykdyti, reikalauja, kad WordPress galėtų pasiekti save per HTTP. Siekiant užtikrinti, kad WP-Cron veiktų tinkamai visose aplinkose, scenarijus prideda eilutę prie failo / Etc / hosts, taip WordPress gali pasiekti save per kilpinę sąsają:

scenarijaus kodas

# 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

Tolesniems veiksmams reikalingų įrankių įdiegimas

Likusiam scenarijui reikalingos kai kurios programos ir daroma prielaida, kad saugyklos yra atnaujintos. Atnaujiname saugyklų sąrašą ir įdiegiame reikiamus įrankius:

scenarijaus kodas

# 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 įrenginio ir NGINX saugyklų pridėjimas

Scenarijus įdiegia NGINX įrenginį ir atvirojo kodo NGINX iš oficialių NGINX saugyklų, kad būtų naudojamos versijos su naujausiais saugos naujinimais ir klaidų pataisymais.

Scenarijus prideda NGINX vieneto saugyklą, tada NGINX saugyklą, prideda saugyklų raktą ir nustatymų failus apt, apibrėžiantis prieigą prie saugyklų internetu.

Faktinis NGINX įrenginio ir NGINX įdiegimas vyksta kitame skyriuje. Iš anksto pridedame saugyklas, kad metaduomenys nebūtų atnaujinami kelis kartus, o diegimas būtų greitesnis.

scenarijaus kodas

# 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 vieneto, PHP MariaDB, Certbot (užšifruokime) ir jų priklausomybių diegimas

Pridėjus visas saugyklas, atnaujiname metaduomenis ir įdiegiame programas. Scenarijaus įdiegti paketai taip pat apima PHP plėtinius, rekomenduojamus paleidžiant. WordPress. Org

scenarijaus kodas

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

PHP konfigūravimas naudojimui su NGINX bloku ir WordPress

Scenarijus sukuria nustatymų failą kataloge konf. d. Tai nustato maksimalų PHP failo įkėlimo dydį, leidžia PHP klaidas išvesti į STDERR, kad jos būtų užregistruotos NGINX bloke, ir iš naujo paleidžiamas NGINX įrenginys.

scenarijaus kodas

# 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

„MariaDB“ duomenų bazės nustatymų nustatymas WordPress

Mes pasirinkome MariaDB, o ne MySQL, nes ji turi daugiau bendruomenės veiklos ir gali pagal numatytuosius nustatymus užtikrina geresnį našumą (Ko gero, čia viskas paprasčiau: norint įdiegti MySQL, reikia pridėti dar vieną saugyklą, apytiksl. vertėjas).

Scenarijus sukuria naują duomenų bazę ir sukuria prieigos duomenis. WordPress per kilpinę sąsają:

scenarijaus kodas

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

Programos diegimas WordPress CLI

Šiame etape scenarijus įdiegia programą WP-CLISu jo pagalba galite nustatyti ir valdyti nustatymus WordPress nereikia rankiniu būdu redaguoti failų, atnaujinti duomenų bazės ar prisijungti prie valdymo skydelio. Jį taip pat galima naudoti temoms ir priedams diegti bei atnaujinimams atlikti. WordPress.

scenarijaus kodas

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

Diegimas ir konfigūravimas WordPress

Scenarijus įdiegia naujausią versiją WordPress į katalogą /var/www/wordpress, taip pat keičia nustatymus:

Duomenų bazės ryšys veikia per unix domeno lizdą, o ne TCP atgalinio ciklo metu, kad sumažintų TCP srautą.
WordPress prideda prefiksą https:// į URL, jei klientai prisijungia prie NGINX per HTTPS, taip pat siunčia nuotolinio kompiuterio pavadinimą (kaip pateikia NGINX) į PHP. Norėdami tai nustatyti, naudojame tam tikrą kodo dalį.
WordPress Prisijungimui reikalingas HTTPS
URL struktūra tyliai pagrįsta ištekliais
Katalogui nustatytos teisingos failų sistemos teisės. WordPress.

scenarijaus kodas

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}" --data-gt-translate-attributes='["title"]' 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 įrenginio nustatymas

Scenarijus konfigūruoja NGINX bloką, kad paleistų PHP ir tvarkytų kelius. WordPress, izoliuojant PHP proceso vardų erdvę ir optimizuojant našumo nustatymus. Verta paminėti tris ypatybes:

Vardų erdvės palaikymas nustatomas pagal sąlygą, pagrįstą patikrinimu, ar scenarijus veikia konteineryje. Tai būtina, nes dauguma sudėtinių rodinių sąrankų nepalaiko įdėto sudėtinių rodinių vykdymo.
Jei yra vardų erdvių palaikymas, vardų erdvė išjungta tinklasTai būtina, kad būtų galima WordPress vienu metu prisijungti prie galinių taškų ir būti pasiekiamam internete.
Didžiausias procesų skaičius nustatomas taip: (Pasiekiama atmintis MariaDB ir NGINX Uniy paleidimui)/(RAM limitas PHP + 5)
Ši vertė nustatoma NGINX įrenginio nustatymuose.

Ši reikšmė taip pat reiškia, kad visada veikia bent du PHP procesai, o tai svarbu, nes WordPress pateikia daug asinchroninių užklausų sau, ir be papildomų procesų, pavyzdžiui, „WP-Cron“ paleidimas nepavyks. Galite padidinti arba sumažinti šias ribas pagal vietinius nustatymus, nes čia sukurti nustatymai yra konservatyvūs. Daugumoje gamybinių sistemų nustatymai yra nuo 10 iki 100.

scenarijaus kodas

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 nustatymas

Pagrindinių NGINX nustatymų konfigūravimas

Scenarijus sukuria NGINX talpyklos katalogą ir sukuria pagrindinį konfigūracijos failą nginx.conf. Atkreipkite dėmesį į tvarkyklės procesų skaičių ir didžiausio atsisiuntimo failo dydžio nustatymą. Taip pat yra eilutė, prie kurios prijungiamas glaudinimo nustatymų failas, apibrėžtas kitame skyriuje, o po to - talpyklos nustatymai.

scenarijaus kodas

# 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 glaudinimo nustatymas

Turinio suspaudimas prieš siunčiant jį klientams yra puikus būdas pagerinti svetainės našumą, tačiau tik tada, jei glaudinimas sukonfigūruotas teisingai. Ši scenarijaus dalis yra pagrįsta nustatymais taigi.

scenarijaus kodas

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

NGINX nustatymas WordPress

Toliau scenarijus sukuria konfigūracijos failą WordPress default.conf kataloge konf. d. Čia jis sukonfigūruotas:

TLS sertifikatų, gautų iš Let's Encrypt per Certbot, aktyvinimas (konfigūravimas bus pateiktas kitame skyriuje)
Konfigūruokite TLS saugos parametrus pagal Let's Encrypt rekomendacijas
Pagal numatytuosius nustatymus įgalinkite praleistų užklausų saugojimą talpykloje 1 valandą
Išjungti prieigos registravimą ir klaidų registravimą, jei failas nerastas, dviem dažniausiai prašomiems failams: favicon.ico ir robots.txt
Uždrausti prieigą prie paslėptų failų ir kai kurių failų . PHPkad būtų išvengta neteisėtos prieigos ar netyčinio paleidimo
Išjungti statinių ir šriftų failų prieigos registravimą
Pavadinimo nustatymas Prieiga-Control-Allow-Origin šriftų failams
Index.php ir kitos statikos maršruto pridėjimas.

scenarijaus kodas

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

Certbot konfigūravimas Let's Encrypt sertifikatams ir automatinis jų atnaujinimas

Certbotas yra nemokamas „Electronic Frontier Foundation“ (EFF) įrankis, leidžiantis gauti ir automatiškai atnaujinti TLS sertifikatus iš „Let's Encrypt“. Scenarijus atlieka šiuos veiksmus, kad sukonfigūruotų Certbot apdoroti sertifikatus iš Let's Encrypt in NGINX:

Sustabdo NGINX
Atsisiunčia rekomenduojamus TLS nustatymus
Paleidžia Certbot, kad gautų svetainės sertifikatus
Iš naujo paleidžia NGINX, kad būtų naudojami sertifikatai
Konfigūruojamas „Certbot“, kad jis veiktų kasdien 3:24 val., kad patikrintų, ar nėra atnaujintų sertifikatų, ir, jei reikia, atsisiųstų naujų sertifikatų ir iš naujo paleistų NGINX.

scenarijaus kodas

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

Papildomas svetainės pritaikymas

Aukščiau kalbėjome apie tai, kaip mūsų scenarijus sukonfigūruoja NGINX ir NGINX įrenginį, kad būtų galima teikti gamybai paruoštą svetainę su įjungta TLSSSL. Taip pat, atsižvelgdami į savo poreikius, ateityje galėsite pridėti:

parama Brotli, patobulintas glaudinimas naudojant HTTPS
ModSecurity с taisyklės WordPresskad išvengtumėte automatinių atakų jūsų svetainėje
Atsarginė kopija už WordPress, tinka tau
Apsauga per „AppArmor“ (įjungta Ubuntu)
Postfix arba msmtp į WordPress galėtų išsiųsti laišką
Tikrinate savo svetainę, kad suprastumėte, kiek srauto ji gali apdoroti

Kad svetainė veiktų dar geriau, rekomenduojame naujovinti į NGINX Plus, mūsų verslo klasės komercinis produktas, pagrįstas atvirojo kodo NGINX. Jo abonentai gaus dinamiškai įkeliamą Brotli modulį, taip pat (už papildomą mokestį) NGINX ModSecurity WAF. Taip pat siūlome NGINX App Protect, WAF modulis, skirtas NGINX Plus, pagrįstas pramonėje pirmaujančia saugos technologija iš F5.

NB Jei norite palaikyti didelės apkrovos svetainę, galite susisiekti su specialistais Southbridge. Užtikrinsime greitą ir patikimą Jūsų svetainės ar paslaugos veikimą esant bet kokiai apkrovai.

Šaltinis: www.habr.com