Automatisera installationen av WordPress med NGINX Unit och Ubuntu

Det finns många resurser för att installera WordPress, en sökning på Google med nyckelorden "WordPress install" ger över en halv miljon resultat. Men bland dem finns det faktiskt väldigt få användbara guider för hur man installerar och konfigurerar WordPress och den underliggande operativsystemet så att de kan stödjas under en längre tid. Kanske beror de rätta inställningarna starkt på specifika behov, eller så handlar det om att en detaljerad förklaring gör artikeln svår att läsa.

I den här artikeln kommer vi att försöka kombinera det bästa av två tillvägagångssätt genom att tillhandahålla ett bash-skript för automatisk installation av WordPress på Ubuntu och gå igenom det och förklara vad varje del gör, samt vilka kompromisser vi gjorde under dess utveckling. Om du är en erfaren användare kan du hoppa över texten i artikeln och helt enkelt ta skriptet för modifiering och användning i din miljö. Utdata från skriptet ger en anpassningsbar installation av WordPress med Lets Encrypt-stöd, som körs på NGINX Unit och är lämplig för industriellt bruk.

Den utvecklade arkitekturen för att distribuera WordPress med hjälp av NGINX Unit beskrivs i en äldre artikel, nu kommer vi också att ytterligare konfigurera saker som inte täcktes där (som i många andra guider):

• WordPress CLI
• Let’s Encrypt och TLS-certifikat
• Automatiska certifikatuppdateringar
• NGINX-caching
• NGINX-komprimering
• Stöd för HTTPS och HTTP/2
• Automatisering av processen

Artikeln kommer att beskriva installationen på en server där både statisk innehållsserver, PHP-behandlingsserver och databas kommer att placeras samtidigt. Installation med stöd för flera virtuella värdar och tjänster är en potentiell framtida ämne. Om du vill att vi ska skriva om något som inte finns i dessa artiklar, skriv i kommentarerna.

Krav

• Server-container (LXC eller LXD), en virtuell maskin eller en vanlig hårdvaruserver, med minst 512 MB RAM och Ubuntu 18.04 eller nyare installerat.
• Tillgängliga portar 80 och 443 från internet
• Ett domännamn kopplat till den offentliga IP-adressen för denna server
• Åtkomst med root-rättigheter (sudo).

Översikt över arkitekturen

Arkitekturen är densamma som tidigare beskrivet tidigare, en tre-nivå webapplikation. Den består av PHP-skript som körs på PHP-hanteraren och statiska filer som hanteras av webbservern.

Allmänna principer

• Många kommandon för konfiguration i skriptet är omslutna i villkor (if) för idempotens: skriptet kan köras flera gånger utan risk för att ändra inställningar som redan är klara.
• Skriptet försöker installera programvara från repositoryn, så att du kan använda systemuppdateringar med ett enda kommando (apt upgrade för Ubuntu).
• Kommandona försöker avgöra om de körs i en container för att ändra sina inställningar på lämpligt sätt.
• För att ställa in antalet processer/trådar som ska köras i inställningarna försöker skriptet gissa automatiska konfigurationsparametrar för att arbeta i containrar, virtuella maskiner och ”fysiska” servrar.
• När vi beskriver inställningar tänker vi alltid först på automatisering, som vi hoppas kommer att ligga till grund för skapandet av din egen infrastruktur som kod.
• Alla kommandon körs av användare root, eftersom de ändrar grundläggande systeminställningar, men WordPress körs direkt av en vanlig användare.

Inställning av miljövariabler

Ställ in följande miljövariabler innan du kör skriptet:

• WORDPRESS_DB_PASSWORD — lösenordet för WordPress-databasen
• WORDPRESS_ADMIN_USER — användarnamn för WordPress-administratören
• WORDPRESS_ADMIN_PASSWORD — lösenord för WordPress-administratören
• WORDPRESS_ADMIN_EMAIL — e-postadress för WordPress-administratören
• WORDPRESS_URL — fullständig URL för WordPress-webbplatsen, som börjar med https://.
• LETS_ENCRYPT_STAGING — som är tomt som standard, men genom att ställa in värdet till 1 kommer du att använda Let’s Encrypts staging-servrar, vilket är nödvändigt för att ofta begära certifikat när du testar dina inställningar, annars kan Let’s Encrypt tillfälligt blockera din IP-adress på grund av ett stort antal förfrågningar.

Skriptet kontrollerar att dessa relaterade WordPress-variabler är inställda och avslutar om de inte är det.
Raderna 572-576 i skriptet kontrollerar värdet LETS_ENCRYPT_STAGING.

Inställning av härledda miljövariabler

Skriptet på raderna 55-61 ställer in följande miljövariabler, antingen till ett visst fast värde eller med hjälp av ett värde som hämtats från variabler som ställts in i föregående avsnitt:

• DEBIAN_FRONTEND="noninteractive" — informerar applikationerna om att de startas i skriptet och att användarkontakt inte är möjlig.
• WORDPRESS_CLI_VERSION="2.4.0" — version av WordPress CLI.
• WORDPRESS_CLI_MD5= "dedd5a662b80cda66e9e25d44c23b25c" — kontrollsumma för körbar fil WordPress CLI 2.4.0 (versionen anges i variabeln WORDPRESS_CLI_VERSION). Skriptet på rad 162 använder detta värde för att kontrollera att rätt fil WordPress CLI har laddats ner.
• UPLOAD_MAX_FILESIZE="16M" — den maximala filstorleken som kan laddas upp till WordPress. Denna inställning används på flera ställen, så det är enklare att definiera den på ett ställe.
• TLS_HOSTNAME= "$(echo ${WORDPRESS_URL} | cut -d'\/ -f3)" — värdnamn för systemet, utvinner från variabeln WORDPRESS_URL. Används för att få motsvarande TLS/SSL-certifikat från Let’s Encrypt, samt för intern kontroll av WordPress.
• NGINX_CONF_DIR="\/etc\/nginx" — sökväg till katalogen med NGINX-inställningar, inklusive huvudfilen nginx.conf.
• CERT_DIR="\/etc\/letsencrypt\/live\/${TLS_HOSTNAME}" — sökvägen till Let’s Encrypt-certifikat för WordPress-webbplatsen, hämtat från variabeln TLS_HOSTNAME.

Tilldelning av värdnamn till WordPress-servern

Skriptet ställer in serverns värdnamn så att värdet motsvarar webbplatsens domännamn. Detta är inte nödvändigt, men det är enklare att skicka utgående e-post via SMTP när man konfigurerar en enda server, som det ställs in av skriptet.

skriptkod

# 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

Lägga till värdnamn i \/etc\/hosts

Tillägg WP‑Cron används för att köra periodiska uppgifter, kräver att WordPress kan nå sig själv via HTTP. För att säkerställa att WP-Cron fungerar korrekt i alla miljöer, lägger skriptet till en rad i filen /etc/hosts, så att WordPress kan nå sig själv via loopback-gränssnittet:

skriptkod

# 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 av verktyg som krävs för efterföljande steg

Den återstående delen av skriptet behöver vissa program och förutsätter att lagren är aktuella. Vi uppdaterar listan över lagren, och installerar sedan de nödvändiga verktygen:

skriptkod

# 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

Lägg till NGINX Unit och NGINX-lager

Skriptet installerar NGINX Unit och NGINX från de officiella NGINX-lagerna för att säkerställa att versioner med de senaste säkerhetsuppdateringarna och bugfixarna används.

Skriptet lägger till NGINX Unit-lagret, följt av NGINX-lagret, genom att lägga till nyckeln för lagren och konfigurationsfilerna apt, som anger tillgång till lagren via internet.

Den faktiska installationen av NGINX Unit och NGINX sker i nästa avsnitt. Vi lägger till repositoryn i förväg för att slippa uppdatera metadata flera gånger, vilket gör installationen snabbare.

skriptkod

# 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 av NGINX, NGINX Unit, PHP MariaDB, Certbot (Let’s Encrypt) och deras beroenden

Så snart alla repositoryn har lagts till, uppdaterar vi metadata och installerar applikationerna. Paketen som installeras av skriptet inkluderar också PHP-tillägg som rekommenderas vid installationen av WordPress.org

skriptkod

echo " Uppdaterar repositorymetadata"
apt-get -qq update

# Installera PHP med beroenden och NGINX Unit
echo " Installerar PHP, NGINX Unit, NGINX, Certbot och 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

Konfigurera PHP för användning med NGINX Unit och WordPress

Skriptet skapar en konfigurationsfil i katalogen conf.d. Här anges den maximala filstorleken för uppladdningar till PHP, PHP-felmeddelanden aktiveras i STDERR så att de registreras i NGINX Unit-loggen, och NGINX Unit startas om.

skriptkod

# 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

Inställning av databasinställningar för MariaDB för WordPress

Vi valde MariaDB istället för MySQL eftersom den har ett större samhällsengagemang, dessutom kan den eventuellt ge högre prestanda som standard (troligtvis är det enklare: för att installera MySQL måste vi lägga till ytterligare ett repository, anm. översättare).

Skriptet skapar en ny databas och skapar inloggningsuppgifter för åtkomst till WordPress via loopback-gränssnittet:

skriptkod

# 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 av WordPress CLI

I det här steget installerar skriptet programmet WP-CLI. Med detta kan du installera och hantera WordPress-inställningar utan att behöva redigera filer manuellt, uppdatera databasen eller logga in på kontrollpanelen. Du kan också installera teman och tillägg samt utföra WordPress-uppdateringar.

skriptkod

if [ ! -f /usr/local/bin/wp ]; then
  # Installera WordPress CLI
  echo " Installerar WordPress CLI-verktyget"
  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 och konfiguration av WordPress

Skriptet installerar den senaste versionen av WordPress i katalogen /var/www/wordpress, och ändrar även inställningarna:

• Anslutningen till databasen fungerar via unix-domänsocket istället för TCP på loopback för att minska TCP-trafiken.
• WordPress lägger till prefix https:// till URL: om kunder ansluter till NGINX via HTTPS-protokollet, samt skickar den fjärrhostname (som tillhandahålls av NGINX) till PHP. Vi använder en kodsnutt för att konfigurera detta.
• WordPress kräver HTTPS för inloggning
• Standard URL-struktur baseras på resurser
• Rätt behörigheter sätts på filsystemet för WordPress-katalogen.

skriptkod

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

  # Ladda ner WordPress med WordPress CLI
  echo "Installerar 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}'"

  # Denna kodsnutt injiceras i wp-config.php-filen när den skapas;
  # den informerar WordPress att vi är bakom en omvänd proxy och på så sätt
  # gör det möjligt för den att generera länkar med HTTPS
  cat > /tmp/wp_forwarded_for.php << 'EOM'
/* Aktivera HTTPS om HTTP_X_FORWARDED_PROTO matchar '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

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

  # Installera 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ätt permalink-struktur till en vettig standard som inte finns i UI
  su -s /bin/sh -p -c "wp --path=/var/www/wordpress option update permalink_structure '/%year%/%monthnum%/%postname%/'" www-data

  # Ta bort exempelarkivet eftersom det är skräp och kan vara ett säkerhetsproblem
  rm /var/www/wordpress/wp-config-sample.php

  # Se till att WordPress-behörigheterna är korrekta
  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 av NGINX Unit

Skriptet konfigurerar NGINX Unit för att köra PHP och hantera vägar i WordPress, isolera namnrymden för PHP-processerna och optimera prestanda. Det finns tre funktioner att notera:

• Stöd för namnrymder definieras av ett villkor, baserat på att skrapet körs i en container. Detta är nödvändigt eftersom de flesta containerinställningar inte stödjer inbäddade containeranrop.
• Om namnrymdsstöd finns, inaktiveras namnrymden nätverk. Detta är nödvändigt för att möjliggöra att WordPress ansluter både till endpoints och är tillgängligt på internet.
• Det maximala antalet processer bestäms enligt följande: (Tillgängligt minne för körda MariaDB och NGINX Uniy)/(gräns för RAM i PHP + 5)
  Detta värde anges i NGINX Unit-inställningarna.

Detta värde innebär också att det alltid finns minst två körda PHP-processer, vilket är viktigt eftersom WordPress gör många asynkrona anrop till sig själv, och utan ytterligare processer kommer det till exempel, WP-Cron, att sluta fungera. Du kanske vill öka eller minska dessa gränser baserat på dina lokala inställningar, eftersom de inställningar som skapats här är konservativa. I de flesta produktionssystem ligger inställningarna mellan 10 och 100.

skriptkod

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 " Beräknade det maximala antalet PHP-processer som ${MAX_PHP_PROCESSES}. Du kanske vill justera detta värde på grund av variationer i din konfiguration. Det är inte ovanligt att se värden mellan 10-100 i produktionskonfigurationer."

echo " Konfigurerar NGINX Unit för att använda PHP och 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 av NGINX

Inställning av NGINX:s grundläggande parametrar

Skriptet skapar en katalog för NGINX-cache och därefter skapar det huvudkonfigurationsfilen nginx.confObservera antalet processhanterare och ange den maximala storleken för uppladdningar. Det finns också en rad som ansluter en fil för komprimeringsinställningar, som definieras i nästa avsnitt, följt av cache-inställningar.

skriptkod

# 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

Konfigurering av NGINX-komprimering

Att komprimera innehåll i realtid innan det skickas till kunderna är ett utmärkt sätt att förbättra webbplatsens prestanda, men endast om komprimeringen är korrekt inställd. Det här avsnittet av skriptet är baserat på inställningarna. härifrån.

skriptkod

cat > ${NGINX_CONF_DIR}/gzip_compression.conf << 'EOM'
# Kredit: https://github.com/h5bp/server-configs-nginx/
# ----------------------------------------------------------------------
# | Komprimering                                                       |
# ----------------------------------------------------------------------
# https://nginx.org/en/docs/http/ngx_http_gzip_module.html
# Aktivera gzip-komprimering.
# Standard: av
gzip on;
# Komprimeringsnivå (1-9).
# 5 är en perfekt kompromiss mellan storlek och CPU-användning, vilket ger cirka 75%
# minskning för de flesta ASCII-filer (nästan identisk med nivå 9).
# Standard: 1
gzip_comp_level 6;
# Komprimera inte något som redan är litet och osannolikt att krympa mycket om
# överhuvudtaget (standard är 20 byte, vilket är dåligt då det vanligtvis leder till större
# filer efter gzipping).
# Standard: 20
gzip_min_length 256;
# Komprimera data även för klienter som ansluter till oss via proxys,
# identifierade av "Via"-huvudet (obligatoriskt för CloudFront).
# Standard: av
gzip_proxied any;
# Berätta för proxys att cacha både den gzippade och vanliga versionen av en resurs
# när som helst klientens Accept-Encoding kapabiliteter huvud varierar;
# Undviker problemet där en icke-gzip-förmögen klient (vilket är extremt sällsynt
# idag) skulle visa nonsens om deras proxy gav dem den gzippade versionen.
# Standard: av
gzip_vary on;
# Komprimera all utdata märkt med en av följande MIME-typer.
# `text/html` komprimeras alltid av gzip-modulen.
# 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

Konfigurering av NGINX för WordPress

Därefter skapar skriptet en konfigurationsfil för WordPress default.conf i katalogen conf.dHär konfigureras:

• Aktivering av TLS-certifikat erhållna från Let’s Encrypt via Certbot (dess konfiguration kommer att finnas i nästa avsnitt)
• Inställning av säkerhetsparametrar för TLS, baserat på rekommendationer från Let’s Encrypt
• Aktivering av caching för förbigångna förfrågningar i 1 timme som standard
• Inaktivering av åtkomstloggning samt fel-loggning, om filen inte hittas, för två vanliga begärda filer: favicon.ico och robots.txt
• Förbjud tillgång till dolda filer och vissa filer .php, för att förhindra obehörig åtkomst eller oavsiktlig körning
• Inaktivera åtkomstloggning för statiska resurser och typarchiv
• Ange rubrik Access-Control-Allow-Origin för typarchiv
• Lägg till routing för index.php och andra statiska resurser.

skriptkod

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-utmaning som används av Certbot för 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-cache
    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;
    }

    # Förbjuda alla försök att komma åt dolda filer som .htaccess, .htpasswd,
    # .DS_Store (Mac)
    # Behåll loggning av begärningar för senare (eller för att vidarebefordra till brandväggsverktyg
    # som fail2ban)
    location ~ \/. {
        deny all;
    }
    # Förbjuda åtkomst till alla filer med en .php-tillägg i uppladdningskatalogen;
    # fungerar i underkataloginstallations och även i fleranvändarnätverk.
    # Behåll loggning av begärningar för senare (eller för att vidarebefordra till brandväggsverktyg
    # som fail2ban).
    location ~* \/(?:uploads|files)\/.*.php$ {
        deny all;
    }
    # WordPress: förbjuda åtkomst till wp-content, wp-includes PHP-filer
    location ~* ^\/(?:wp-content|wp-includes)\/.*.php$ {
        deny all;
    }
    # Förbjuda offentlig åtkomst till wp-config.php
    location ~* wp-config.php {
        deny all;
    }
    # Logga inte åtkomst för statiska tillgångar, 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

Inställning av Certbot för certifikat från Let’s Encrypt och automatisk förnyelse

Certbot är ett gratis verktyg från Electronic Frontier Foundation (EFF) som gör det möjligt att få och automatiskt uppdatera TLS-certifikat från Let’s Encrypt. Skriptet utför följande åtgärder för att konfigurera Certbot för hantering av certifikat från Let’s Encrypt i NGINX:

• Stoppar NGINX
• Laddar ner rekommenderade TLS-inställningar
• Startar Certbot för att få certifikat för webbplatsen
• Startar om NGINX för att använda certifikaten
• Konfigurerar daglig körning av Certbot klockan 03:24 för att kontrollera behovet av att förnya certifikat, samt om nödvändigt, hämta nya certifikat och starta om NGINX.

skriptkod

echo " Stoppar NGINX för att ställa in 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 " Laddar ner rekommenderade TLS-inställningar"
  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 "Kunde inte ladda ner senaste options-ssl-nginx.conf"
fi

if [ ! -f ${NGINX_CONF_DIR}/ssl-dhparams.pem ]; then
  echo " Laddar ner rekommenderade TLS DH-inställningar"
  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 "Kunde inte ladda ner senaste ssl-dhparams.pem"
fi

# Om tls_certs_init.sh inte har körts tidigare, ta bort de självsignerade certifikaten
if [ ! -d "/etc/letsencrypt/accounts" ]; then
  echo " Tar bort självsignerade certifikat"
  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 " Genererar certifikat 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 " Startar NGINX för att använda ny konfiguration"
service nginx start

# Skriver crontab för periodisk förnyelse av Let's Encrypt certifikat
if [ "$(crontab -l | grep -m1 'certbot renew')" == "" ]; then
  echo " Lägger till certbot i crontab för automatisk förnyelse av Let's Encrypt"
  (crontab -l 2>/dev/null; echo "24 3 * * * certbot renew --nginx --post-hook 'service nginx reload'") | crontab -
fi

Ytterligare inställning av din webbplats

Vi har ovan beskrivit hur vårt skript konfigurerar NGINX och NGINX Unit för att driva en webbplats som är redo för industriell användning med aktiverad TLS/SSL. Du kan också, beroende på dina behov, lägga till i framtiden:

• Stöd för Brotli, förbättrad komprimering i realtid över HTTPS
• ModSecurity med med regler för WordPress, för att förhindra automatiska attacker mot din webbplats
• Säkerhetskopiering för WordPress, som passar dig
• Skydd med hjälp av AppArmor (på Ubuntu)
• Postfix eller msmtp så att WordPress kan skicka e-post
• Kontroller av din webbplats så att du förstår hur mycket trafik den kan hantera

För ännu bättre webbprestanda rekommenderar vi att du uppgraderar till NGINX Plus, vår kommersiella företagsprodukt baserad på den öppna källkoden NGINX. Prenumeranter får en dynamiskt laddad Brotli-modul samt (mot extra kostnad) NGINX ModSecurity WAF. Vi erbjuder även NGINX App Protect, WAF-modul för NGINX Plus, baserad på branschledande säkerhetsteknik från F5.

N.B. För support av högtrafikerade webbplatser kan du kontakta specialister Southbridge. Vi säkerställer snabb och pålitlig drift av din webbplats eller tjänst under alla belastningar.

Källa: habr.com