ProHoster > blogg > administration > Automatisera WordPress-installation med NGINX Unit och Ubuntu

Automatisera WordPress-installation med NGINX Unit och Ubuntu

Automatisera WordPress-installation med NGINX Unit och Ubuntu

Det finns många tutorials om hur man installerar WordPress, en Google-sökning på "WordPress install" kommer att ge ungefär en halv miljon resultat. Men i själva verket finns det väldigt få bra guider bland dem, enligt vilka du kan installera och konfigurera WordPress och det underliggande operativsystemet så att de är kapabla att stödja under lång tid. Kanske är de korrekta inställningarna mycket beroende av specifika behov, eller så beror det på att en detaljerad förklaring gör artikeln svårläst.

I den här artikeln kommer vi att försöka kombinera det bästa av två världar genom att tillhandahålla ett bash-skript för att automatiskt installera WordPress på Ubuntu, samt gå igenom det, förklara vad varje del gör, samt de kompromisser vi gjorde när vi utvecklade det . Om du är en avancerad användare kan du hoppa över texten i artikeln och bara ta manuset för modifiering och användning i dina miljöer. Utdata från skriptet är en anpassad WordPress-installation med stöd för Lets Encrypt, som körs på NGINX Unit och lämpar sig för produktionsanvändning.

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

  • WordPress CLI
  • Låt oss kryptera och TLSSSL-certifikat
  • Automatisk förnyelse av certifikat
  • NGINX cachning
  • NGINX-komprimering
  • Stöd för HTTPS och HTTP/2
  • Processautomation

Artikeln kommer att beskriva installationen på en server, som samtidigt kommer att vara värd för en statisk bearbetningsserver, en PHP-bearbetningsserver och en databas. Installation med stöd för flera virtuella värdar och tjänster är ett potentiellt ämne för framtiden. Om du vill att vi ska skriva om något som inte finns i dessa artiklar, skriv i kommentarerna.

Krav

  • Behållarserver (LXC eller LXD), en virtuell maskin eller en vanlig järnserver med minst 512 MB RAM och Ubuntu 18.04 eller senare installerat.
  • Internettillgängliga portar 80 och 443
  • Domännamn kopplat till den offentliga IP-adressen för denna server
  • Rotåtkomst (sudo).

Arkitektur översikt

Arkitekturen är densamma som beskrivs tidigare, en webbapplikation i tre nivåer. Den består av PHP-skript som körs på PHP-motorn och statiska filer som bearbetas av webbservern.

Automatisera WordPress-installation med NGINX Unit och Ubuntu

Allmänna principer

  • Många konfigurationskommandon i ett skript är insvept i om villkor för idempotens: skriptet kan köras flera gånger utan risk för att ändra inställningar som redan finns på plats.
  • Skriptet försöker installera programvara från arkiv, så att du kan tillämpa systemuppdateringar i ett kommando (apt upgrade för Ubuntu).
  • Kommandon försöker upptäcka att de körs i en behållare så att de kan ändra sina inställningar därefter.
  • För att ställa in antalet trådprocesser som ska starta i inställningarna, försöker skriptet gissa de automatiska inställningarna för att arbeta i behållare, virtuella maskiner och hårdvaruservrar.
  • När vi beskriver inställningar tänker vi alltid först och främst på automatisering, som vi hoppas ska bli grunden för att skapa din egen infrastruktur som kod.
  • Alla kommandon körs som användare rot, eftersom de ändrar de grundläggande systeminställningarna, men direkt körs WordPress som en vanlig användare.

Ställa in miljövariabler

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

  • WORDPRESS_DB_PASSWORD - WordPress-databaslösenord
  • WORDPRESS_ADMIN_USER - WordPress adminnamn
  • WORDPRESS_ADMIN_PASSWORD - WordPress admin lösenord
  • WORDPRESS_ADMIN_EMAIL - WordPress admin e-post
  • WORDPRESS_URL är den fullständiga webbadressen till WordPress-webbplatsen, med start kl https://.
  • LETS_ENCRYPT_STAGING - tomt som standard, men genom att sätta värdet till 1 kommer du att använda Let's Encrypt staging-servrar, som är nödvändiga 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 WordPress-relaterade variabler är inställda och avslutas om inte.
Skriptraderna 572-576 kontrollerar värdet LETS_ENCRYPT_STAGING.

Ställa in härledda miljövariabler

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

  • DEBIAN_FRONTEND="noninteractive" - Berättar för applikationer att de körs i ett skript och att det inte finns någon möjlighet till användarinteraktion.
  • WORDPRESS_CLI_VERSION="2.4.0" är versionen av WordPress CLI-applikationen.
  • WORDPRESS_CLI_MD5= "dedd5a662b80cda66e9e25d44c23b25c" — kontrollsumma för WordPress CLI 2.4.0 körbara filen (versionen anges i variabeln WORDPRESS_CLI_VERSION). Skriptet på rad 162 använder detta värde för att kontrollera att rätt WordPress CLI-fil har laddats ner.
  • UPLOAD_MAX_FILESIZE="16M" - den maximala filstorleken som kan laddas upp i WordPress. Den här inställningen används på flera ställen, så det är lättare att ställa in den på ett ställe.
  • TLS_HOSTNAME= "$(echo ${WORDPRESS_URL} | cut -d'/' -f3)" - värdnamn för systemet, hämtat från variabeln WORDPRESS_URL. Används för att erhålla lämpliga TLS/SSL-certifikat från Let's Encrypt samt intern WordPress-verifiering.
  • 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-certifikaten för WordPress-webbplatsen, hämtad från variabeln TLS_HOSTNAME.

Tilldela ett värdnamn till en WordPress-server

Skriptet ställer in serverns värdnamn så att det matchar webbplatsens domännamn. Detta krävs inte, men det är bekvämare att skicka utgående e-post via SMTP när du konfigurerar en enda server, som konfigurerats 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ägger till värdnamn till /etc/hosts

Dessutom WP-Cron används för att köra periodiska uppgifter, kräver WordPress för att kunna komma åt 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 / hostsså att WordPress kan komma åt 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

Installera de verktyg som krävs för nästa steg

Resten av skriptet behöver några program och förutsätter att arkiven är uppdaterade. Vi uppdaterar listan över förråd, varefter vi installerar 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ägger till NGINX Unit och NGINX Repositories

Skriptet installerar NGINX Unit och open source NGINX från de officiella NGINX-arkiven för att se till att versionerna med de senaste säkerhetskorrigeringarna och buggfixarna används.

Skriptet lägger till NGINX Unit-förvaret och sedan NGINX-förvaret, lägger till förvarets nyckel och konfigurationsfiler apt, definiera åtkomst till arkiv via Internet.

Själva installationen av NGINX Unit och NGINX sker i nästa avsnitt. Vi lägger till arkiven i förväg så att vi inte behöver 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

Installera NGINX, NGINX Unit, PHP MariaDB, Certbot (Let's Encrypt) och deras beroenden

När alla förråd har lagts till uppdaterar du metadata och installerar applikationerna. Paketen som installeras av skriptet inkluderar även de PHP-tillägg som rekommenderas när du kör WordPress.org

skriptkod

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

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

Skriptet skapar en inställningsfil i katalogen conf.d. Detta ställer in den maximala storleken för PHP-uppladdningar, aktiverar PHP-felutgången till STDERR så att de skrivs till NGINX-enhetsloggen och startar om NGINX-enheten.

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

Ange MariaDB-databasinställningar för WordPress

Vi har valt MariaDB framför MySQL eftersom det har mer gemenskapsaktivitet och sannolikt också kommer att göra det ger bättre prestanda som standard (förmodligen är allt enklare här: för att installera MySQL måste du lägga till ett annat arkiv, cirka. översättare).

Skriptet skapar en ny databas och skapar autentiseringsuppgifter för att komma åt 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;"

Installera WordPress CLI-programmet

I det här steget installerar skriptet programmet WP-CLI. Med den kan du installera och hantera WordPress-inställningar utan att behöva redigera filer manuellt, uppdatera databasen eller gå in i kontrollpanelen. Den kan också användas för att installera teman och tillägg och uppdatera WordPress.

skriptkod

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

Installera och konfigurera WordPress

Skriptet installerar den senaste versionen av WordPress i en katalog /var/www/wordpressoch ändrar även inställningarna:

  • Databasanslutningen fungerar över unix-domänsocket istället för TCP på loopback för att minska TCP-trafiken.
  • WordPress lägger till ett prefix https:// till URL:en om klienter ansluter till NGINX över HTTPS, och skickar även fjärrvärdnamnet (som tillhandahålls av NGINX) till PHP. Vi använder en bit kod för att ställa in detta.
  • WordPress behöver HTTPS för inloggning
  • Standard-URL-strukturen är baserad på resurser
  • Ställer in rätt behörigheter på filsystemet för WordPress-katalogen.

skriptkod

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

Konfigurera NGINX-enheten

Skriptet konfigurerar NGINX-enheten för att köra PHP och bearbeta WordPress-sökvägar, isolerar PHP-processens namnutrymme och optimerar prestandainställningar. Det finns tre funktioner att hålla utkik efter här:

  • Stöd för namnutrymmen bestäms av villkor, baserat på att kontrollera att skriptet körs i en behållare. Detta är nödvändigt eftersom de flesta behållarinställningar inte stöder kapslad lansering av behållare.
  • Om det finns stöd för namnutrymmen, inaktivera namnområdet nät. Detta för att WordPress ska kunna ansluta till båda slutpunkterna och vara tillgängligt på webben samtidigt.
  • Det maximala antalet processer definieras enligt följande: (Tillgängligt minne för att köra MariaDB och NGINX Uniy)/(RAM-gräns i PHP + 5)
    Detta värde ställs in i NGINX-enhetens inställningar.

Detta värde innebär också att det alltid finns minst två PHP-processer igång, vilket är viktigt eftersom WordPress gör många asynkrona förfrågningar till sig själv, och utan ytterligare processer kommer körning av t.ex. WP-Cron att gå sönder. Du kanske vill öka eller minska dessa gränser baserat på dina lokala inställningar, eftersom inställningarna som skapas här är konservativa. På de flesta produktionssystem är 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 " 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

Konfigurera NGINX

Konfigurera grundläggande NGINX-inställningar

Skriptet skapar en katalog för NGINX-cachen och skapar sedan huvudkonfigurationsfilen nginx.conf. Var uppmärksam på antalet hanterarprocesser och inställningen av den maximala filstorleken för uppladdning. Det finns också en rad som inkluderar komprimeringsinställningsfilen som definieras i nästa avsnitt, följt av cachningsinställningarna.

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

Ställa in NGINX-komprimering

Att komprimera innehåll i farten innan det skickas till kunder är ett utmärkt sätt att förbättra webbplatsens prestanda, men bara om komprimeringen är korrekt konfigurerad. Det här avsnittet av skriptet är baserat på inställningar hence.

skriptkod

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

Konfigurera NGINX för WordPress

Därefter skapar skriptet en konfigurationsfil för WordPress default.conf i katalogen conf.d. Den är konfigurerad här:

  • Aktivera TLS-certifikat som tagits emot från Let's Encrypt via Certbot (inställning av det kommer att göras i nästa avsnitt)
  • Konfigurera TLS-säkerhetsinställningar baserat på rekommendationer från Let's Encrypt
  • Aktivera överhoppningsförfrågningar i cache i 1 timme som standard
  • Inaktivera åtkomstloggning, samt felloggning om filen inte hittas, för två vanliga begärda filer: favicon.ico och robots.txt
  • Förhindra åtkomst till dolda filer och vissa filer . Phpför att förhindra olaglig åtkomst eller oavsiktlig start
  • Inaktivera åtkomstloggning för statiska filer och teckensnittsfiler
  • Rubrikinställning Åtkomstkontroll-Tillåt-ursprung för teckensnittsfiler
  • Lägger till routing för index.php och annan statik.

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

Konfigurera Certbot för certifikat från Let's Encrypt och automatiskt förnya dem

Certbot är ett gratis verktyg från Electronic Frontier Foundation (EFF) som låter dig erhålla och automatiskt förnya TLS-certifikat från Let's Encrypt. Skriptet gör följande för att konfigurera Certbot för att bearbeta certifikat från Let's Encrypt in NGINX:

  • Stoppar NGINX
  • Laddar ned rekommenderade TLS-inställningar
  • Kör Certbot för att få certifikat för webbplatsen
  • Startar om NGINX för att använda certifikat
  • Konfigurerar Certbot att köras dagligen kl. 3:24 för att kontrollera om certifikaten behöver förnyas, och vid behov ladda ner nya certifikat och starta om NGINX.

skriptkod

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

Ytterligare anpassning av din webbplats

Vi pratade ovan om hur vårt skript konfigurerar NGINX och NGINX Unit för att tjäna en produktionsklar webbplats med TLSSSL aktiverat. Du kan också, beroende på dina behov, lägga till i framtiden:

  • Stöd Brotli, förbättrad on-the-fly-komprimering över HTTPS
  • ModSecurity с regler för wordpressför att förhindra automatiska attacker på din webbplats
  • säkerhetskopiering för WordPress som passar dig
  • Skydd via AppArmor (på Ubuntu)
  • Postfix eller msmtp så att WordPress kan skicka mail
  • Kontrollera din webbplats så att du förstår hur mycket trafik den kan hantera

För ännu bättre webbplatsprestanda rekommenderar vi att du uppgraderar till NGINX Plus, vår kommersiella, företagsklassade produkt baserad på öppen källkod NGINX. Dess prenumeranter kommer att få en dynamiskt laddad Brotli-modul, samt (mot en extra avgift) NGINX ModSecurity WAF. Vi erbjuder också NGINX App Protect, en WAF-modul för NGINX Plus baserad på branschledande säkerhetsteknik från F5.

NB För support för en högt laddad webbplats kan du kontakta specialisterna Southbridge. Vi kommer att säkerställa snabb och pålitlig drift av din webbplats eller tjänst under alla belastningar.

Källa: will.com