Vi automatiserer installationen af WordPress med NGINX Unit og Ubuntu

Vi automatiserer installationen af WordPress med NGINX Unit og Ubuntu

Der findes mange materialer om installation af WordPress; en Google-søgning på nøgleordene "WordPress install" vil give omkring en halv million resultater. Men der er faktisk meget få gode vejledninger blandt dem, som kan hjælpe med at installere og konfigurere WordPress samt det underliggende operativsystem, så de er i stand til at understøtte det i en længere periode. Måske afhænger de rigtige indstillinger meget af specifikke behov, eller også skyldes det, at en detaljeret forklaring gør artiklen sværere at læse.

I denne artikel vil vi prøve at samle det bedste fra to tilgange ved at give et bash-script til automatisk installation af WordPress på Ubuntu, og vi vil gennemgå det, forklare hvad hver del gør, samt hvilke indbyrdes kompromiser vi gik på kompromis med under udviklingen. Hvis du er en erfaren bruger, kan du springe selve teksten over i artiklen og blot tage scriptet til modifikation og brug i dine miljøer. Udgangen af scriptet resulterer i en konfigurerbar WordPress-installation med Lets Encrypt-support, der kører på NGINX Unit og egner sig til industriel anvendelse.

Den udviklede arkitektur for implementering af WordPress ved brug af NGINX Unit er beskrevet i en ældre artikel, nu vil vi også yderligere konfigurere ting, som ikke blev dækket der (som i mange andre vejledninger):

  • WordPress CLI
  • Let’s Encrypt og TLS/SSL-certifikater
  • Automatisk opdatering af certifikater
  • NGINX caching
  • NGINX kompression
  • Support for HTTPS og HTTP/2
  • Automatisering af processen

Artiklen vil beskrive installation på en enkelt server, som samtidig vil hoste en statisk server, en PHP-behandlingsserver og en database. Installation med støtte for flere virtuelle værter og tjenester er et potentielt emne til fremtiden. Hvis du ønsker, at vi skal skrive om noget, som ikke er dækket i disse artikler, så skriv i kommentarerne.

Krav

  • Container-server (LXC eller LXD), en virtuel maskine eller en almindelig dedikeret server med mindst 512 MB RAM og installeret Ubuntu 18.04 eller nyere.
  • Tilgængelige porte fra internettet 80 og 443
  • Et domænenavn knyttet til den offentlige IP-adresse på denne server
  • Adgang med root-rettigheder (sudo).

Oversigt over arkitekturen

Arkitekturen er den samme som beskrevet tidligere, en tre-niveau web-applikation. Den består af PHP-scripts, der køres på PHP-fortolkeren, og statiske filer, der behandles af webserveren.

Vi automatiserer installationen af WordPress med NGINX Unit og Ubuntu

Generelle principper

  • Mange kommandoer til konfiguration i scriptet er indkapslet i betingelser (if) for idempotens: scriptet kan køres flere gange uden risiko for at ændre indstillinger, der allerede er klar.
  • Scriptet forsøger at installere software fra repositories, så du kan anvende systemopdateringer med en enkelt kommando (apt upgrade til Ubuntu).
  • Kommandoerne forsøger at identificere, at de kører i en container, for at ændre deres indstillinger i overensstemmelse hermed.
  • For at angive antallet af kørende processer/ tråde i indstillingerne, prøver scriptet at gætte de automatiske konfigurationsparametre til brug i containere, virtuelle maskiner og 'bare metal'-servere.
  • Når vi beskriver indstillinger, tænker vi altid først på automatisering, som vi håber vil danne grundlaget for opbygningen af din egen infrastruktur som kode.
  • Alle kommandoer køres som bruger root, da de ændrer de grundlæggende systemindstillinger, men WordPress fungerer direkte som en almindelig bruger.

Opsætning af miljøvariabler

Indstil følgende miljøvariabler, før du kører scriptet:

  • WORDPRESS_DB_PASSWORD — adgangskoden til WordPress-databasen
  • WORDPRESS_ADMIN_USER — brugernavnet til WordPress-administratoren
  • WORDPRESS_ADMIN_PASSWORD — adgangskoden til WordPress-administratoren
  • WORDPRESS_ADMIN_EMAIL — e-mail til WordPress-administratoren
  • WORDPRESS_URL — den fulde URL til WordPress-webstedet, der starter med https://.
  • LETS_ENCRYPT_STAGING — tom som standard, men ved at sætte værdien til 1, vil du bruge Let’s Encrypt staging-servere, som er nødvendige for hyppige anmodninger om certifikater, mens du tester dine indstillinger, ellers kan Let’s Encrypt midlertidigt blokere din IP-adresse på grund af et stort antal anmodninger.

Scriptet kontrollerer, at disse WordPress-relaterede variabler er angivet, og afslutter arbejdet, hvis ikke.
Linjerne i scriptet 572-576 kontrollerer værdien LETS_ENCRYPT_STAGING.

Opsætning af afledte miljøvariabler

Scriptet i linjerne 55-61 sætter følgende miljøvariabler, enten til nogle hårdt kodede værdier eller ved at bruge værdier hentet fra variabler, der er angivet i det foregående afsnit:

  • DEBIAN_FRONTEND="noninteractive" — informerer applikationer om, at de kører i et script, og at der ikke er mulighed for brugerinteraktion.
  • WORDPRESS_CLI_VERSION="2.4.0" — version af WordPress CLI applikationen.
  • WORDPRESS_CLI_MD5="dedd5a662b80cda66e9e25d44c23b25c" — kontrolsum af WordPress CLI 2.4.0 eksekverbar fil (versionen angives i variablen WORDPRESS_CLI_VERSION). Scriptet på linje 162 bruger denne værdi til at kontrollere, at den korrekte WordPress CLI fil er blevet downloadet.
  • UPLOAD_MAX_FILESIZE="16M" — den maksimale filstørrelse, der kan uploads til WordPress. Denne indstilling bruges flere steder, så det er nemmere at definere den ét sted.
  • TLS_HOSTNAME="$(echo ${WORDPRESS_URL} | cut -d'/' -f3)" — systemets hostname, udtrukket fra variablen WORDPRESS_URL. Bruges til at hente de relevante TLS/SSL certifikater fra Let’s Encrypt samt til intern kontrol af WordPress.
  • NGINX_CONF_DIR="/etc/nginx" — stien til NGINX konfigurationskataloget, inklusive hovedfilen nginx.conf.
  • CERT_DIR="/etc/letsencrypt/live/${TLS_HOSTNAME}" — stien til Let’s Encrypt certifikaterne for WordPress hjemmesiden, hentet fra variablen TLS_HOSTNAME.

Tildeling af hostname til WordPress serveren

Scriptet indstiller hostname for serveren, så værdien svarer til hjemmesidens domænenavn. Dette er ikke obligatorisk, men gør det nemmere at sende udgående e-mails via SMTP, når man setter en enkelt server op, som scriptet konfigurerer.

scriptkode

# 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

Tilføjelse af hostname til /etc/hosts

Tilføjelse WP‑Cron bruges til at køre periodiske opgaver, kræver at WordPress kan tilgå sig selv via HTTP. For at sikre, at WP-Cron fungerer korrekt i alle miljøer, tilføjer scriptet en linje i filen /etc/hosts, så WordPress kan tilgå sig selv gennem loopback interfacet:

scriptkode

# 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

Installation af værktøjer, der kræves til de efterfølgende trin

Den resterende del af scriptet har brug for nogle programmer og forudsætter, at repository’er er opdaterede. Vi opdaterer listen over repository’er, hvorefter vi installerer de nødvendige værktøjer:

scriptkode

# 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

Tilføjelse af NGINX Unit og NGINX repositories

Scriptet installerer NGINX Unit og NGINX fra de officielle NGINX repositories for at sikre, at der bruges versioner med de nyeste sikkerhedsopdateringer og fejlrettelser.

Scriptet tilføjer NGINX Unit repository’et, og derefter NGINX repository’et, ved at tilføje repository-nøglen og konfigurationsfilene apt, der definere adgangen til repository’er via internettet.

Den faktiske installation af NGINX Unit og NGINX finder sted i det følgende afsnit. Vi tilføjer først repositories for ikke at opdatere metadata flere gange, hvilket gør installationen hurtigere.

scriptkode

# 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

Installation af NGINX, NGINX Unit, PHP, MariaDB, Certbot (Let’s Encrypt) og deres afhængigheder

Når alle repositories er tilføjet, opdaterer vi metadataene og installerer applikationerne. Pakkerne, der installeres af scriptet, inkluderer også PHP-udvidelser, der anbefales ved opsætning af WordPress.org

scriptkode

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

# Installerer PHP med afhængigheder og NGINX Unit
echo " Installerer PHP, NGINX Unit, NGINX, Certbot, og 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

Konfigurering af PHP til brug med NGINX Unit og WordPress

Scriptet opretter en konfigurationsfil i mappen conf.d. Her angives den maksimale størrelse på uploadede filer til PHP, PHP-fejlrapportering aktiveres til STDERR, så de bliver logget i NGINX Unit, og NGINX Unit genstartes.

scriptkode

# 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

Angivelse af databaseindstillinger for MariaDB til WordPress

Vi valgte MariaDB frem for MySQL, da den har større samfundsaktivitet, og den tilbyder muligvis bedre ydeevne som standard (sandsynligvis er det alt sammen enklere: for at installere MySQL skal man tilføje endnu et repository, bemærk fra oversætteren).

Scriptet opretter en ny database og skaber legitimationsoplysninger til adgang for WordPress via loopback-grænsefladen:

scriptkode

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

Installation af WordPress CLI

I dette trin installerer scriptet WP-CLI. Med det kan du installere og administrere WordPress-indstillinger uden at skulle redigere filer manuelt, opdatere databasen eller logge ind på kontrolpanelet. Det kan også bruges til at installere temaer og plugins samt udføre WordPress-opdateringer.

scriptkode

if [ ! -f /usr/local/bin/wp ]; then
  # Installerer WordPress CLI
  echo " Installerer WordPress CLI-værktøjet"
  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

Installation og konfigurering af WordPress

Scriptet installerer den nyeste version af WordPress i mappen /var/www/wordpress, og ændrer også indstillingerne:

  • Forbindelsen til databasen fungerer via unix domain socket i stedet for TCP på loopback for at reducere TCP-trafikken.
  • WordPress tilføjer et præfiks https:// til URL, når kunderne opretter forbindelse til NGINX via HTTPS-protokollen, og sender det eksterne hostname (som NGINX leverer) til PHP. Vi anvender et stykke kode for at konfigurere dette.
  • WordPress kræver HTTPS for login
  • Standard URL-struktur er baseret på ressourcer
  • De korrekte rettigheder er indstillet på filsystemet for WordPress-mappen.

scriptkode

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

  # Download WordPress med WordPress CLI
  echo "Installerer 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}'"

  # Dette snippet bliver indsat i wp-config.php-filen, når den oprettes;
  # det informerer WordPress om, at vi er bag en omvendt proxy og derved
  # muliggør, at den genererer links ved hjælp af HTTPS
  cat > /tmp/wp_forwarded_for.php << 'EOM'
/* Tænd for HTTPS, hvis HTTP_X_FORWARDED_PROTO matcher '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

  # Opret WordPress-konfiguration
  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

  # Installer 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

  # Sæt permalink-struktur til en fornuftig standard, som ikke er i UI'en
  su -s /bin/sh -p -c "wp --path=/var/www/wordpress option update permalink_structure '/%year%/%monthnum%/%postname%/'" www-data

  # Fjern eksempel-filen, da den er unødvendig og kan være et sikkerhedsproblem
  rm /var/www/wordpress/wp-config-sample.php

  # Sørg for, at WordPress-rettighederne er korrekte
  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

Konfiguration af NGINX Unit

Scriptet konfigurerer NGINX Unit til at køre PHP og håndtere WordPress-stier, isolerende PHP-processernes namespaces og optimerende ydeevneindstillingerne. Der er tre funktioner, som det er værd at bemærke:

  • Namespace-support bestemmes ud fra en betingelse, baseret på at kontrollere, om scriptet kører i en container. Dette er nødvendigt, fordi de fleste containerindstillinger ikke understøtter indlejrede containerkørsler.
  • Hvis der er support for namespaces, deaktiveres namespaces netværk. Dette er nødvendigt for at tillade WordPress at oprette forbindelse til både endpoints og være tilgængelig på internettet.
  • Det maksimale antal processer bestemmes som følger: (Tilgængelig hukommelse til kørende MariaDB og NGINX Uniy) / (grænsen for RAM i PHP + 5)
    Denne værdi indstilles i NGINX Units indstillinger.

Denne værdi antager også, at der altid er mindst to kørende PHP-processer, hvilket er vigtigt, da WordPress laver mange asynkrone forespørgsler til sig selv, og uden ekstra processer ville eksempelvis kørsel af WP-Cron fejle. Du ønsker måske at øge eller mindske disse grænser baseret på dine lokale indstillinger, da de indstillede værdier her er konservative. På de fleste produktionssystemer ligger indstillingerne mellem 10 og 100.

scriptkode

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 "Beregnet det maksimale antal PHP-processer som ${MAX_PHP_PROCESSES}. Du ønsker måske at justere denne værdi på grund af variationer i din konfiguration. Det er ikke usædvanligt at se værdier mellem 10-100 i produktionskonfigurationer."

echo "Konfigurerer NGINX Unit til at bruge PHP og 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

Konfiguration af NGINX

Konfiguration af grundlæggende NGINX-parametre

Scriptet opretter et bibliotek til NGINX cache og derefter opretter hovedkonfigurationsfilen nginx.confBemærk antallet af processer-behandlere og angiv den maksimale filstørrelse for uploads. Der er også en linje, hvor konfigurationsfilen for komprimering tilsluttes, som defineres i det følgende afsnit, efterfulgt af cache-indstillinger.

scriptkode

# 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 komprimeringsindstillinger

On-the-fly komprimering af indhold før det sendes til kunderne er en fremragende måde at forbedre websitets ydeevne på, men det kræver korrekt konfiguration. Dette afsnit af scriptet er baseret på indstillingerne. from here.

scriptkode

cat > ${NGINX_CONF_DIR}\/gzip_compression.conf << 'EOM'
# Credit: https://github.com/h5bp/server-configs-nginx/
# ----------------------------------------------------------------------
# | Komprimering                                                      |
# ----------------------------------------------------------------------
# https://nginx.org/en/docs/http/ngx_http_gzip_module.html
# Aktiver gzip kompression.
# Standard: off
gzip on;
# Komprimeringsniveau (1-9).
# 5 er et perfekt kompromis mellem størrelse og CPU-forbrug, der tilbyder cirka 75%
# reduktion for de fleste ASCII-filer (næsten identisk med niveau 9).
# Standard: 1
gzip_comp_level 6;
# Komprimer ikke noget, der allerede er småt, og som næppe vil kunne reduceres meget, hvis overhovedet
# (standarden er 20 bytes, hvilket er dårligt, da det normalt fører til større
# filer efter gzipping).
# Standard: 20
gzip_min_length 256;
# Komprimer data, selv for kunder, der forbinder til os via proxy,
# identificeret af "Via" headeren (påkrævet for CloudFront).
# Standard: off
gzip_proxied any;
# Fortæl proxyer at cache både den gzippede og regulære version af en ressource
# hver gang klientens Accept-Encoding kapaciteter header varierer;
# Undgår problemet, hvor en ikke-gzip komprimeret klient (som er ekstremt sjælden
# i dag) ville vise gibberish, hvis deres proxy gav dem den gzippede version.
# Standard: off
gzip_vary on;
# Komprimer al output mærket med en af de følgende MIME-typer.
# `text/html` komprimeres altid af gzip-modulet.
# Standard: 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

Konfiguration af NGINX til WordPress

Derefter opretter scriptet en konfigurationsfil til WordPress default.conf i katalogen conf.d. Her konfigureres:

  • Aktivering af TLS-certifikater fra Let’s Encrypt via Certbot (dens konfiguration vil være i det næste afsnit)
  • Konfiguration af TLS-sikkerhedsindstillinger baseret på anbefalinger fra Let’s Encrypt
  • Aktivering af caching for forbipasserende forespørgsler i 1 time som standard
  • Deaktivering af adgangslogning samt logning af fejl, hvis filen ikke findes, for to ofte anmodede filer: favicon.ico og robots.txt
  • Forbud mod adgang til skjulte filer og visse filer .php, for at forhindre uautoriseret adgang eller utilsigtet start
  • Deaktivering af adgangslogning for statiske filer og skrifttyper
  • Angivelse af header Access-Control-Allow-Origin for skrifttyper
  • Tilføjelse af routing for index.php og andre statiske filer.

scriptkode

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 brugt af Certbot til 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 konfiguration
    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;
    }

    # Forbyde alle forsøg på at tilgå skjulte filer som .htaccess, .htpasswd,
    # .DS_Store (Mac)
    # Fortsæt med at logge anmodningerne for at analysere senere (eller overføre til firewall værktøjer
    # som fail2ban)
    location ~ \/. {
        deny all;
    }
    # Forbyd adgang til alle filer med en .php-udvidelse i upload-mappen;
    # fungerer også i installationsmænd i undermappen og i multisite-netværk.
    # Fortsæt med at logge anmodningerne for at analysere senere (eller overføre til firewall værktøjer
    # som fail2ban).
    location ~* \/(?:uploads|files)\/.*.php$ {
        deny all;
    }
    # WordPress: forbyd adgang til wp-content, wp-includes PHP-filer
    location ~* ^\/(?:wp-content|wp-includes)\/.*.php$ {
        deny all;
    }
    # Forbyd offentlig adgang til wp-config.php
    location ~* wp-config.php {
        deny all;
    }
    # Log ikke adgang for statiske aktiver, medier
    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

Konfiguration af Certbot til certificater fra Let’s Encrypt og deres automatiske fornyelse

Certbot er et gratis værktøj fra Electronic Frontier Foundation (EFF), der gør det muligt at modtage og automatisk opdatere TLS-certifikater fra Let’s Encrypt. Scriptet udfører følgende handlinger, der fører til konfiguration af Certbot til håndtering af certificater fra Let’s Encrypt i NGINX:

  • Stopper NGINX
  • Downloader anbefalede TLS-parametre
  • Starter Certbot for at få certifikater til websitet
  • Genstarter NGINX for at anvende certifikaterne
  • Konfigurerer daglig kørsel af Certbot kl. 3:24 om natten for at kontrollere behovet for opdatering af certifikaterne samt, om nødvendigt, download af nye certifikater og genstart af NGINX.

scriptkode

echo " Stopper NGINX for at konfigurere 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 " Downloader anbefalede TLS-parametre"
  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 "Kunne ikke downloade seneste options-ssl-nginx.conf"
fi

if [ ! -f ${NGINX_CONF_DIR}/ssl-dhparams.pem ]; then
  echo " Downloader anbefalede TLS DH-parametre"
  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 "Kunne ikke downloade seneste ssl-dhparams.pem"
fi

# Hvis tls_certs_init.sh ikke er blevet kørt før, fjern de selvsignerede certifikater
if [ ! -d "/etc/letsencrypt/accounts" ]; then
  echo " Fjerner selvsignerede certifikater"
  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 " Genererer certifikater med Let's Encrypt"
  certbot certonly --standalone 
         -m "${WORDPRESS_ADMIN_EMAIL}" 
         ${CERTBOT_STAGING_FLAG} 
         --agree-tos --force-renewal --non-interactive 
         -d "${TLS_HOSTNAME}"
fi

echo " Starter NGINX for at bruge ny konfiguration"
service nginx start

# Skriv crontab for periodisk fornyelse af Let's Encrypt certifikat
if [ "$(crontab -l | grep -m1 'certbot renew')" == "" ]; then
  echo " Føjer certbot til crontab for automatisk fornyelse af Let's Encrypt"
  (crontab -l 2>/dev/null; echo "24 3 * * * certbot renew --nginx --post-hook 'service nginx reload'") | crontab -
fi

Yderligere konfiguration af dit website

Vi har tidligere forklaret, hvordan vores script konfigurerer NGINX og NGINX Unit til at betjene et produktionsklart website med aktiveret TLS/SSL. Du kan også, afhængigt af dine behov, fremover tilføje:

  • Support Brotli, forbedret komprimering on-the-fly via HTTPS
  • ModSecurity med regler for WordPress, for at forhindre automatiserede angreb på dit website
  • Sikkerhedskopiering for WordPress, der passer til dig
  • Beskyttelse ved hjælp af AppArmor (på Ubuntu)
  • Postfix eller msmtp, så WordPress kan sende e-mails
  • Gennemgange af din hjemmeside, så du forstår, hvor meget trafik den kan klare

For endnu bedre ydeevne på dit website anbefaler vi at opgradere til NGINX Plus, vores enterprise-grade kommercielle produkt baseret på NGINX med åben kildekode. Dets abonnenter vil modtage en dynamisk indlæst Brotli-modul, samt (mod ekstra betaling) NGINX ModSecurity WAF. Vi tilbyder også NGINX App Protect, et WAF modul til NGINX Plus, baseret på branchens førende sikkerhedsteknologi fra F5.

N.B. For support af en højbelastet hjemmeside kan du kontakte specialisterne Southbridge. Vi sikrer hurtig og pålidelig drift af din hjemmeside eller tjeneste under enhver belastning.

Kilde: habr.com

Køb pålidelig webhosting med DDoS-beskyttelse, VPS VDS-servere 🔥 Køb pålidelig webhosting med DDoS-beskyttelse, VPS VDS-servere | ProHoster