🥇Automatizamos a instalación de WordPress con NGINX Unit e Ubuntu

Hai moito material por aí sobre a instalación de WordPress; unha busca en Google de "instalación de WordPress" devolverá preto de medio millón de resultados. Non obstante, en realidade hai moi poucas guías útiles que che poden axudar a instalar e configurar WordPress e o sistema operativo subxacente para que poidan ser compatibles durante un longo período de tempo. Quizais a configuración correcta dependa en gran medida das túas necesidades específicas, ou pode ser porque a explicación detallada dificulta a lectura do artigo.

Neste artigo, tentaremos xuntar o mellor de ambos mundos proporcionando un script bash para instalar automaticamente WordPress en Ubuntu, e imos percorrelo, explicando o que fai cada peza e as compensacións que fixemos ao deseñar iso. Se es un usuario experimentado, pode saltar o texto do artigo e só toma o guión para a súa modificación e uso nos seus ambientes. A saída do script é unha instalación personalizada de WordPress con soporte para Lets Encrypt, que se executa na Unidade NGINX e é apta para uso industrial.

A arquitectura desenvolvida para a implantación de WordPress usando NGINX Unit descríbese en artigo máis antigo, agora tamén configuraremos máis cousas que non foron tratadas alí (como en moitos outros tutoriais):

CLI de WordPress
Imos cifrar e certificados TLSSSL
Renovación automática do certificado
Almacenamento en caché NGINX
Compresión NGINX
Compatibilidade con HTTPS e HTTP/2
Automatización de procesos

O artigo describirá a instalación nun servidor, que aloxará simultaneamente un servidor de procesamento estático, un servidor de procesamento PHP e unha base de datos. A instalación con soporte para varios hosts virtuais e servizos é un tema potencial para o futuro. Se queres que escribamos sobre algo que non está nestes artigos, escribe nos comentarios.

Requisitos

Contedor do servidor (LXC ou LXD), unha máquina virtual ou un servidor de hardware normal, con polo menos 512 MB de RAM e Ubuntu 18.04 ou máis recente instalado.
Portos accesibles por Internet 80 e 443
O nome de dominio asociado ao enderezo IP público deste servidor
Acceso con dereitos de root (sudo).

Visión xeral da arquitectura

A arquitectura é a mesma que se describe antes, unha aplicación web de tres niveis. Consta de scripts PHP executados no motor PHP e ficheiros estáticos procesados polo servidor web.

Principios xerais

Moitos comandos de configuración nun script están envoltos en condicións para a idempotencia: o script pódese executar varias veces sen o risco de cambiar a configuración que xa está lista.
O script tenta instalar software desde repositorios, polo que pode aplicar actualizacións do sistema nun comando (apt upgrade para Ubuntu).
Os equipos tentan detectar que se están a executar nun contedor para que poidan cambiar a súa configuración en consecuencia.
Para establecer o número de procesos de fío que se van iniciar na configuración, o script tenta adiviñar a configuración automática para traballar en contedores, máquinas virtuais e servidores de hardware.
Ao describir a configuración, sempre pensamos primeiro na automatización, que esperamos que se converta na base para crear a túa propia infraestrutura como código.
Todos os comandos son executados dende o usuario raíz, porque cambian a configuración básica do sistema, pero o propio WordPress funciona como un usuario habitual.

Establecemento de variables de ambiente

Estableza as seguintes variables de ambiente antes de executar o script:

WORDPRESS_DB_PASSWORD - Contrasinal da base de datos de WordPress
WORDPRESS_ADMIN_USER - Nome de usuario administrador de WordPress
WORDPRESS_ADMIN_PASSWORD - Contrasinal de administrador de WordPress
WORDPRESS_ADMIN_EMAIL - Correo electrónico do administrador de WordPress
WORDPRESS_URL – URL completo do sitio de WordPress, comezando por https://.
LETS_ENCRYPT_STAGING — baleiro por defecto, pero ao establecer o valor en 1, utilizará os servidores de preparación de Let's Encrypt, que son necesarios para solicitar certificados con frecuencia ao probar a súa configuración; se non, Let's Encrypt pode bloquear temporalmente o seu enderezo IP debido ao gran número de solicitudes.

O script comproba que estas variables relacionadas con WordPress estean configuradas e sae se non o están.
As liñas de guión 572-576 verifican o valor LETS_ENCRYPT_STAGING.

Establecemento de variables de ambiente derivadas

O script das liñas 55-61 establece as seguintes variables de ambiente, xa sexa a algún valor codificado ou utilizando un valor derivado das variables definidas na sección anterior:

DEBIAN_FRONTEND="noninteractive" — indica ás aplicacións que se están executando nun script e que non hai posibilidade de interacción do usuario.
WORDPRESS_CLI_VERSION="2.4.0" — Versión CLI de WordPress da aplicación.
WORDPRESS_CLI_MD5= "dedd5a662b80cda66e9e25d44c23b25c" — suma de verificación do ficheiro executable de WordPress CLI 2.4.0 (a versión indícase na variable WORDPRESS_CLI_VERSION). O script da liña 162 usa este valor para verificar que se descargou o ficheiro CLI de WordPress correcto.
UPLOAD_MAX_FILESIZE="16M" — o tamaño máximo de ficheiro que se pode cargar en WordPress. Esta configuración utilízase en varios lugares, polo que é máis fácil configurala nun só lugar.
TLS_HOSTNAME= "$(echo ${WORDPRESS_URL} | cut -d'/' -f3)" — nome de host do sistema, extraído da variable WORDPRESS_URL. Úsase para obter certificados TLS/SSL axeitados de Let's Encrypt, así como para a verificación interna de WordPress.
NGINX_CONF_DIR="/etc/nginx" — ruta ao directorio coa configuración de NGINX, incluído o ficheiro principal nginx.conf.
CERT_DIR="/etc/letsencrypt/live/${TLS_HOSTNAME}" — camiño aos certificados Let's Encrypt para o sitio de WordPress, obtidos a partir da variable TLS_HOSTNAME.

Asignando nome de host ao servidor de WordPress

O script establece o nome de host do servidor para que o valor coincida co nome de dominio do sitio. Isto non é necesario, pero é máis conveniente enviar correo saínte a través de SMTP ao configurar un único servidor, tal e como o configura o script.

código de script

# 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

Engadindo o nome de host a /etc/hosts

Adición WP-Cron usado para executar tarefas periódicas, require que WordPress poida acceder a si mesmo a través de HTTP. Para asegurarse de que WP-Cron funciona correctamente en todos os ambientes, o script engade unha liña ao ficheiro / Etc / hostspara que WordPress poida acceder a si mesmo a través da interface de loopback:

código de script

# 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

Instalación das ferramentas necesarias para os pasos posteriores

O resto do script require algúns programas e asume que os repositorios están actualizados. Actualizamos a lista de repositorios e despois instalamos as ferramentas necesarias:

código de script

# 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

Engadindo a Unidade NGINX e os repositorios NGINX

O script instala NGINX Unit e NGINX de código aberto desde os repositorios oficiais de NGINX para garantir que se utilicen as versións coas últimas actualizacións de seguranza e corrección de erros.

O script engade o repositorio da unidade NGINX e despois o repositorio NGINX, engadindo a chave dos repositorios e os ficheiros de configuración apt, definindo o acceso aos repositorios a través de Internet.

A instalación real da Unidade NGINX e NGINX ocorre na seguinte sección. Engadimos previamente repositorios para evitar actualizar metadatos varias veces, facendo a instalación máis rápida.

código de script

# 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

Instalación de NGINX, NGINX Unit, PHP MariaDB, Certbot (Let's Encrypt) e as súas dependencias

Unha vez engadidos todos os repositorios, actualizamos os metadatos e instalamos as aplicacións. Os paquetes instalados polo script tamén inclúen extensións PHP recomendadas ao executar WordPress.org

código de script

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

Configurando PHP para usar con NGINX Unit e WordPress

O script crea un ficheiro de configuración no directorio conf. d. Isto establece o tamaño máximo de carga de ficheiros para PHP, permite que os erros de PHP sexan enviados a STDERR para que se rexistren na Unidade NGINX e reinicie a Unidade NGINX.

código de script

# 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

Configuración da base de datos MariaDB para WordPress

Escollemos MariaDB sobre MySQL porque ten máis actividade comunitaria e tamén pode proporciona un mellor rendemento por defecto (Probablemente, aquí todo sexa máis sinxelo: para instalar MySQL, cómpre engadir outro repositorio, aprox. tradutor).

O script crea unha nova base de datos e crea credenciais de acceso de WordPress a través da interface de loopback:

código de script

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

Instalación do programa CLI de WordPress

Neste paso, o script instala o programa WP-CLI. Con el, pode instalar e xestionar a configuración de WordPress sen ter que editar manualmente ficheiros, actualizar a base de datos ou iniciar sesión no panel de control. Tamén se pode usar para instalar temas e complementos e actualizar WordPress.

código de script

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

Instalación e configuración de WordPress

O script instala a última versión de WordPress no directorio /var/www/wordpress, e tamén cambia a configuración:

A conexión de base de datos funciona a través dun socket de dominio Unix en lugar de TCP en loopback para reducir o tráfico TCP.
WordPress engade un prefixo https:// ao URL se os clientes se conectan a NGINX a través de HTTPS e tamén envía o nome de host remoto (tal como proporciona NGINX) a PHP. Usamos un anaco de código para configuralo.
WordPress necesita HTTPS para iniciar sesión
A estrutura do URL baséase silenciosamente en recursos
Establécense os permisos correctos do sistema de ficheiros para o directorio de WordPress.

código de script

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

Configurando a unidade NGINX

O script configura a Unidade NGINX para executar PHP e xestionar rutas de WordPress, illando o espazo de nomes dos procesos PHP e optimizando a configuración de rendemento. Hai tres características ás que vale a pena prestar atención:

A compatibilidade do espazo de nomes determínase pola condición, en función da comprobación de que o script se está a executar no contedor. Isto é necesario porque a maioría das configuracións de contedores non admiten a execución aniñada de contedores.
Se hai soporte para espazos de nomes, o espazo de nomes está desactivado rede. Isto é necesario para que WordPress se conecte simultaneamente aos puntos finais e sexa accesible en Internet.
O número máximo de procesos determínase do seguinte xeito: (Memoria dispoñible para executar MariaDB e NGINX Uniy)/(Límite de RAM en PHP + 5)
Este valor establécese na configuración da unidade NGINX.

Este valor tamén implica que sempre hai polo menos dous procesos PHP en execución, o que é importante porque WordPress fai moitas solicitudes asíncronas a si mesmo e sen que se executen procesos adicionais, por exemplo, WP-Cron romperá. Pode querer aumentar ou diminuír estes límites en función da súa configuración local, porque a configuración creada aquí é conservadora. Na maioría dos sistemas de produción, os axustes están entre 10 e 100.

código de script

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

Configurando NGINX

Configuración básica de NGINX

O script crea un directorio para a caché de NGINX e despois crea o ficheiro de configuración principal nginx.conf. Preste atención ao número de procesos controladores e á configuración de tamaño máximo de ficheiro para descargar. Tamén hai unha liña na que se conecta o ficheiro de configuración de compresión, definido na seguinte sección, seguido da configuración de caché.

código de script

# 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

Configurando a compresión NGINX

Comprimir contido sobre a marcha antes de envialo aos clientes é unha boa forma de mellorar o rendemento do sitio, pero só se a compresión está configurada correctamente. Esta sección do script baséase na configuración por iso.

código de script

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

Configurando NGINX para WordPress

A continuación, o script crea un ficheiro de configuración para WordPress por defecto.conf no catálogo conf. d. Aquí está configurado:

Activando os certificados TLS recibidos de Let's Encrypt a través de Certbot (a súa configuración será na seguinte sección)
Configura a configuración de seguranza de TLS en función das recomendacións de Let's Encrypt
Activa o almacenamento en caché de solicitudes omitidas durante 1 hora de forma predeterminada
Desactive o rexistro de acceso, así como o rexistro de erros se non se atopa o ficheiro, para dous ficheiros solicitados comúnmente: favicon.ico e robots.txt
Denegar o acceso a ficheiros ocultos e a algúns ficheiros .PHPpara evitar o acceso ilegal ou o lanzamento non intencionado
Desactiva o rexistro de acceso para ficheiros estáticos e de fontes
Establecendo o título Acceso-Control-Permitir-Orixe para ficheiros de fontes
Engadindo enrutamento para index.php e outras estáticas.

código de script

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

Configurando Certbot para os certificados Let's Encrypt e renovalos automaticamente

certbot é unha ferramenta gratuíta da Electronic Frontier Foundation (EFF) que che permite obter e renovar automaticamente certificados TLS de Let's Encrypt. O script realiza os seguintes pasos para configurar Certbot para procesar certificados de Let's Encrypt en NGINX:

Detén NGINX
Descarga a configuración de TLS recomendada
Executa Certbot para obter certificados para o sitio
Reinicia NGINX para usar certificados
Configura Certbot para que se execute diariamente ás 3:24 a.m. para comprobar se hai renovacións de certificados e, se é necesario, descargar novos certificados e reiniciar NGINX.

código de script

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

Personalización adicional do teu sitio

Falamos anteriormente sobre como o noso script configura NGINX e NGINX Unit para servir un sitio web listo para a produción con TLSSSL activado. Tamén podes, dependendo das túas necesidades, engadir no futuro:

Apoiar Brotli, mellorou a compresión ao voo sobre HTTPS
Seguridade mod с regras para WordPresspara evitar ataques automatizados no seu sitio
Copia de seguridade para WordPress, adecuado para ti
Protección coa axuda AppArmor (en Ubuntu)
Postfix ou msmtp para que WordPress poida enviar correo
Comprobando o seu sitio para comprender canto tráfico pode xestionar

Para un rendemento aínda mellor do sitio, recomendamos actualizar a NGINX Plus, o noso produto comercial de calidade empresarial baseado no código aberto NGINX. Os seus subscritores recibirán un módulo Brotli cargado dinámicamente, así como (por unha tarifa adicional) NGINX ModSecurity WAF. Tamén ofrecemos NGINX App Protect, un módulo WAF para NGINX Plus baseado na tecnoloxía de seguridade líder do sector de F5.

NB Para obter soporte para un sitio web de alta carga, podes contactar con especialistas Southbridge. Garantiremos un funcionamento rápido e fiable do seu sitio web ou servizo baixo calquera carga.

Fonte: www.habr.com

Automatización da instalación de WordPress con NGINX Unit e Ubuntu

Requisitos

Visión xeral da arquitectura

Principios xerais

Establecemento de variables de ambiente

Establecemento de variables de ambiente derivadas

Asignando nome de host ao servidor de WordPress

Engadindo o nome de host a /etc/hosts

Instalación das ferramentas necesarias para os pasos posteriores

Engadindo a Unidade NGINX e os repositorios NGINX

Instalación de NGINX, NGINX Unit, PHP MariaDB, Certbot (Let's Encrypt) e as súas dependencias

Configurando PHP para usar con NGINX Unit e WordPress

Configuración da base de datos MariaDB para WordPress

Instalación do programa CLI de WordPress

Instalación e configuración de WordPress

Configurando a unidade NGINX

Configurando NGINX

Configuración básica de NGINX

Configurando a compresión NGINX

Configurando NGINX para WordPress

Configurando Certbot para os certificados Let's Encrypt e renovalos automaticamente

Personalización adicional do teu sitio