WordPress-installatie automatiseren met NGINX Unit en Ubuntu

WordPress-installatie automatiseren met NGINX Unit en Ubuntu

Er zijn veel tutorials over het installeren van WordPress, een Google-zoekopdracht naar "WordPress install" levert ongeveer een half miljoen resultaten op. In feite zijn er maar heel weinig goede handleidingen, volgens welke je WordPress en het onderliggende besturingssysteem zo kunt installeren en configureren dat ze gedurende een lange periode kunnen worden ondersteund. Wellicht zijn de juiste instellingen sterk afhankelijk van specifieke wensen, of komt dit doordat een uitgebreide uitleg het artikel moeilijk leesbaar maakt.

In dit artikel proberen we het beste van twee werelden te combineren door een bash-script te bieden om WordPress automatisch op Ubuntu te installeren, er doorheen te lopen, uit te leggen wat elk stuk doet, evenals de compromissen die we hebben gemaakt bij de ontwikkeling ervan. . Als u een gevorderde gebruiker bent, kunt u de tekst van het artikel overslaan en gewoon neem het script voor aanpassing en gebruik in uw omgevingen. De uitvoer van het script is een aangepaste WordPress-installatie met Lets Encrypt-ondersteuning, draait op NGINX Unit en is geschikt voor productiegebruik.

De ontwikkelde architectuur voor het implementeren van WordPress met behulp van de NGINX Unit wordt beschreven in ouder artikel, nu gaan we ook dingen configureren die daar niet aan bod kwamen (zoals in veel andere tutorials):

  • WordPress CLI
  • Let's Encrypt en TLSSSL-certificaten
  • Automatische verlenging van certificaten
  • NGINX-caching
  • NGINX-compressie
  • HTTPS- en HTTP/2-ondersteuning
  • Proces automatisering

Het artikel beschrijft de installatie op één server, die tegelijkertijd een statische verwerkingsserver, een PHP-verwerkingsserver en een database zal hosten. Een installatie die meerdere virtuele hosts en services ondersteunt, is een potentieel onderwerp voor de toekomst. Als je wilt dat we schrijven over iets dat niet in deze artikelen staat, schrijf dan in de comments.

Eisen

  • Containerserver (LXC of LXD), een virtuele machine of een gewone ijzeren server met minimaal 512 MB RAM en Ubuntu 18.04 of nieuwer geïnstalleerd.
  • Internet toegankelijke poorten 80 en 443
  • Domeinnaam gekoppeld aan het openbare ip-adres van deze server
  • Root-toegang (sudo).

Architectuur overzicht

De architectuur is hetzelfde als beschreven vroeger, een drieledige webapplicatie. Het bestaat uit PHP-scripts die op de PHP-engine draaien en statische bestanden die door de webserver worden verwerkt.

WordPress-installatie automatiseren met NGINX Unit en Ubuntu

Algemene principes

  • Veel configuratiecommando's in een script zijn ingesloten in de volgende voorwaarden voor idempotentie: het script kan meerdere keren worden uitgevoerd zonder het risico bestaande instellingen te wijzigen.
  • Het script probeert software uit repositories te installeren, zodat u systeemupdates met één opdracht kunt toepassen (apt upgrade voor Kubuntu).
  • Opdrachten proberen te detecteren dat ze in een container worden uitgevoerd, zodat ze hun instellingen dienovereenkomstig kunnen wijzigen.
  • Om het aantal threadprocessen in te stellen dat moet worden gestart in de instellingen, probeert het script de automatische instellingen te raden voor het werken in containers, virtuele machines en hardwareservers.
  • Bij het beschrijven van instellingen denken we altijd eerst aan automatisering, die, naar we hopen, de basis zal worden voor het creëren van je eigen infrastructuur als code.
  • Alle opdrachten worden uitgevoerd als gebruiker wortel, omdat ze de basissysteeminstellingen wijzigen, maar WordPress draait direct als een gewone gebruiker.

Omgevingsvariabelen instellen

Stel de volgende omgevingsvariabelen in voordat u het script uitvoert:

  • WORDPRESS_DB_PASSWORD - WordPress-databasewachtwoord
  • WORDPRESS_ADMIN_USER - WordPress-beheerdersnaam
  • WORDPRESS_ADMIN_PASSWORD - WordPress-beheerderswachtwoord
  • WORDPRESS_ADMIN_EMAIL - WordPress admin e-mail
  • WORDPRESS_URL is de volledige URL van de WordPress-site, beginnend bij https://.
  • LETS_ENCRYPT_STAGING - standaard leeg, maar door de waarde op 1 te zetten, maak je gebruik van de Let's Encrypt staging servers, die nodig zijn voor het regelmatig opvragen van certificaten bij het testen van je instellingen, anders kan Let's Encrypt je ip-adres tijdelijk blokkeren vanwege een groot aantal verzoeken .

Het script controleert of deze WordPress-gerelateerde variabelen zijn ingesteld en sluit af als dat niet het geval is.
Scriptregels 572-576 controleren de waarde LETS_ENCRYPT_STAGING.

Afgeleide omgevingsvariabelen instellen

Het script op regels 55-61 stelt de volgende omgevingsvariabelen in, hetzij op een hardgecodeerde waarde, hetzij op basis van een waarde die is verkregen uit de variabelen die in de vorige sectie zijn ingesteld:

  • DEBIAN_FRONTEND="noninteractive" - Vertelt applicaties dat ze in een script draaien en dat er geen mogelijkheid is voor gebruikersinteractie.
  • WORDPRESS_CLI_VERSION="2.4.0" is de versie van de WordPress CLI-applicatie.
  • WORDPRESS_CLI_MD5= "dedd5a662b80cda66e9e25d44c23b25c" — checksum van het uitvoerbare bestand van WordPress CLI 2.4.0 (de versie wordt gespecificeerd in de variabele WORDPRESS_CLI_VERSION). Het script op regel 162 gebruikt deze waarde om te controleren of het juiste WordPress CLI-bestand is gedownload.
  • UPLOAD_MAX_FILESIZE="16M" - de maximale bestandsgrootte die in WordPress kan worden geüpload. Deze instelling wordt op meerdere plaatsen gebruikt, dus het is gemakkelijker om deze op één plaats in te stellen.
  • TLS_HOSTNAME= "$(echo ${WORDPRESS_URL} | cut -d'/' -f3)" - hostnaam van het systeem, opgehaald uit de variabele WORDPRESS_URL. Wordt gebruikt om de juiste TLS/SSL-certificaten van Let's Encrypt te verkrijgen, evenals interne WordPress-verificatie.
  • NGINX_CONF_DIR="/etc/nginx" - pad naar de map met NGINX-instellingen, inclusief het hoofdbestand nginx.conf.
  • CERT_DIR="/etc/letsencrypt/live/${TLS_HOSTNAME}" — het pad naar de Let's Encrypt-certificaten voor de WordPress-site, verkregen uit de variabele TLS_HOSTNAME.

Een hostnaam toewijzen aan een WordPress-server

Het script stelt de hostnaam van de server zo in dat deze overeenkomt met de domeinnaam van de site. Dit is niet vereist, maar het is handiger om uitgaande e-mail via SMTP te verzenden bij het opzetten van een enkele server, zoals geconfigureerd door het script.

scriptcode

# 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

Hostnaam toevoegen aan /etc/hosts

Toevoeging WP-Cron gebruikt om periodieke taken uit te voeren, vereist dat WordPress zichzelf kan benaderen via HTTP. Om ervoor te zorgen dat WP-Cron correct werkt in alle omgevingen, voegt het script een regel toe aan het bestand / Etc / hostszodat WordPress zichzelf kan benaderen via de loopback-interface:

scriptcode

# 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

De tools installeren die nodig zijn voor de volgende stappen

De rest van het script heeft enkele programma's nodig en gaat ervan uit dat de repositories up-to-date zijn. We werken de lijst met repositories bij, waarna we de nodige tools installeren:

scriptcode

# 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 Unit en NGINX Repositories toevoegen

Het script installeert NGINX Unit en open source NGINX vanuit de officiële NGINX-repository's om ervoor te zorgen dat de versies met de nieuwste beveiligingspatches en bugfixes worden gebruikt.

Het script voegt de NGINX Unit-repository toe en vervolgens de NGINX-repository, waarbij de repositories-sleutel en configuratiebestanden worden toegevoegd apt, het definiëren van toegang tot repositories via internet.

De eigenlijke installatie van NGINX Unit en NGINX gebeurt in de volgende sectie. We voegen de repositories vooraf toe, zodat we de metadata niet meerdere keren hoeven bij te werken, wat de installatie sneller maakt.

scriptcode

# 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

Installatie van NGINX, NGINX Unit, PHP MariaDB, Certbot (Let's Encrypt) en hun afhankelijkheden

Zodra alle repositories zijn toegevoegd, werkt u de metadata bij en installeert u de applicaties. De pakketten die door het script worden geïnstalleerd, bevatten ook de PHP-extensies die worden aanbevolen bij het uitvoeren van WordPress.org

scriptcode

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 instellen voor gebruik met NGINX Unit en WordPress

Het script maakt een instellingenbestand in de directory conf.d. Dit stelt de maximale grootte in voor PHP-uploads, schakelt PHP-foutuitvoer naar STDERR in zodat ze naar het logboek van de NGINX Unit worden geschreven en start de NGINX Unit opnieuw op.

scriptcode

# 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-database-instellingen specificeren voor WordPress

We hebben MariaDB verkozen boven MySQL omdat het meer gemeenschapsactiviteit heeft en waarschijnlijk ook zal doen biedt standaard betere prestaties (waarschijnlijk is alles hier eenvoudiger: om MySQL te installeren, moet je nog een repository toevoegen, ca. vertaler).

Het script maakt een nieuwe database aan en maakt inloggegevens aan om toegang te krijgen tot WordPress via de loopback-interface:

scriptcode

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

Het WordPress CLI-programma installeren

Bij deze stap installeert het script het programma WP-CLI. Hiermee kunt u WordPress-instellingen installeren en beheren zonder handmatig bestanden te hoeven bewerken, de database bij te werken of het configuratiescherm te openen. Het kan ook worden gebruikt om thema's en add-ons te installeren en WordPress bij te werken.

scriptcode

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

Installeren en configureren van WordPress

Het script installeert de nieuwste versie van WordPress in een map /var/www/wordpressen verandert ook de instellingen:

  • De databaseverbinding werkt via een unix-domeinsocket in plaats van TCP bij loopback om het TCP-verkeer te verminderen.
  • WordPress voegt een voorvoegsel toe https:// naar de URL als clients verbinding maken met NGINX via HTTPS, en stuurt ook de externe hostnaam (zoals geleverd door NGINX) naar PHP. We gebruiken een stukje code om dit in te stellen.
  • WordPress heeft HTTPS nodig om in te loggen
  • De standaard URL-structuur is gebaseerd op bronnen
  • Stelt de juiste machtigingen in op het bestandssysteem voor de WordPress-directory.

scriptcode

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-eenheid opzetten

Het script configureert de NGINX-eenheid om PHP uit te voeren en WordPress-paden te verwerken, de naamruimte van het PHP-proces te isoleren en prestatie-instellingen te optimaliseren. Er zijn drie functies waar u op moet letten:

  • Ondersteuning voor naamruimten wordt bepaald door de voorwaarde, gebaseerd op het controleren of het script in een container wordt uitgevoerd. Dit is nodig omdat de meeste containerconfiguraties genest starten van containers niet ondersteunen.
  • Als er ondersteuning is voor naamruimten, schakelt u de naamruimte uit netwerk. Dit is om WordPress in staat te stellen verbinding te maken met beide eindpunten en tegelijkertijd beschikbaar te zijn op internet.
  • Het maximale aantal processen wordt als volgt gedefinieerd: (Beschikbaar geheugen voor het uitvoeren van MariaDB en NGINX Uniy)/(RAM-limiet in PHP + 5)
    Deze waarde wordt ingesteld in de instellingen van de NGINX-eenheid.

Deze waarde houdt ook in dat er altijd ten minste twee PHP-processen actief zijn, wat belangrijk is omdat WordPress veel asynchrone verzoeken aan zichzelf doet en zonder aanvullende processen, bijvoorbeeld WP-Cron zal breken. Mogelijk wilt u deze limieten verhogen of verlagen op basis van uw lokale instellingen, omdat de hier gemaakte instellingen conservatief zijn. Op de meeste productiesystemen liggen de instellingen tussen 10 en 100.

scriptcode

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 opzetten

Basisinstellingen voor NGINX configureren

Het script maakt een map aan voor de NGINX-cache en maakt vervolgens het hoofdconfiguratiebestand aan nginx.conf. Let op het aantal afhandelingsprocessen en het instellen van de maximale bestandsgrootte voor uploaden. Er is ook een regel met het bestand met compressie-instellingen dat in de volgende sectie is gedefinieerd, gevolgd door de caching-instellingen.

scriptcode

# 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-compressie instellen

Het direct comprimeren van inhoud voordat deze naar klanten wordt verzonden, is een geweldige manier om de prestaties van de site te verbeteren, maar alleen als de compressie correct is geconfigureerd. Dit gedeelte van het script is gebaseerd op instellingen vandaar.

scriptcode

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 opzetten voor WordPress

Vervolgens maakt het script een configuratiebestand voor WordPress standaard.conf in de catalogus conf.d. Het is hier geconfigureerd:

  • Activeren van TLS-certificaten ontvangen van Let's Encrypt via Certbot (instellen komt in het volgende gedeelte)
  • TLS-beveiligingsinstellingen configureren op basis van aanbevelingen van Let's Encrypt
  • Schakel verzoeken voor het overslaan van caching gedurende 1 uur standaard in
  • Schakel toegangsregistratie uit, evenals foutregistratie als het bestand niet wordt gevonden, voor twee veelgebruikte bestanden: favicon.ico en robots.txt
  • Voorkom toegang tot verborgen bestanden en sommige bestanden . Phpom illegale toegang of onbedoelde start te voorkomen
  • Schakel toegangsregistratie uit voor statische bestanden en lettertypebestanden
  • Kopinstelling Toegangscontrole-Toestaan-Oorsprong voor lettertypebestanden
  • Routering toevoegen voor index.php en andere statica.

scriptcode

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 instellen voor certificaten van Let's Encrypt en deze automatisch vernieuwen

Certbot is een gratis tool van de Electronic Frontier Foundation (EFF) waarmee u TLS-certificaten van Let's Encrypt kunt verkrijgen en automatisch kunt verlengen. Het script doet het volgende om Certbot te configureren om certificaten van Let's Encrypt in NGINX te verwerken:

  • Stopt NGINX
  • Download aanbevolen TLS-instellingen
  • Voert Certbot uit om certificaten voor de site te krijgen
  • Herstart NGINX om certificaten te gebruiken
  • Configureert Certbot om dagelijks om 3:24 uur te draaien om te controleren of certificaten vernieuwd moeten worden, en indien nodig nieuwe certificaten te downloaden en NGINX opnieuw op te starten.

scriptcode

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

Extra maatwerk van uw site

We hebben hierboven gesproken over hoe ons script NGINX en NGINX Unit configureert om een ​​productieklare site te bedienen met TLSSSL ingeschakeld. U kunt ook, afhankelijk van uw behoeften, in de toekomst toevoegen:

  • steun Brotli, verbeterde on-the-fly compressie via HTTPS
  • ModSecurity с regels voor wordpressom geautomatiseerde aanvallen op uw site te voorkomen
  • backup voor WordPress die bij je past
  • Bescherming via AppArmor (op Kubuntu)
  • Postfix of msmtp zodat WordPress mail kan versturen
  • Uw site controleren zodat u begrijpt hoeveel verkeer deze aankan

Voor nog betere siteprestaties raden we aan te upgraden naar NGINX Plus, ons commerciële, enterprise-grade product op basis van open source NGINX. De abonnees ontvangen een dynamisch geladen Brotli-module, evenals (tegen een extra vergoeding) NGINX ModSecurity WAF. Wij bieden ook NGINX-app beschermen, een WAF-module voor NGINX Plus gebaseerd op toonaangevende beveiligingstechnologie van F5.

NB Voor ondersteuning van een zwaarbelaste site kunt u terecht bij de experts Southbridge. Wij zorgen voor een snelle en betrouwbare werking van uw website of dienst onder elke belasting.

Bron: www.habr.com