Automatización de la instalación de WordPress con NGINX Unit y Ubuntu

Hay muchos tutoriales sobre cómo instalar WordPress; una búsqueda en Google de "instalación de WordPress" arrojará alrededor de medio millón de resultados. Sin embargo, de hecho, hay muy pocas guías buenas entre ellas, según las cuales puede instalar y configurar WordPress y el sistema operativo subyacente para que sean capaces de soportar un largo período de tiempo. Quizás la configuración correcta dependa en gran medida de necesidades específicas, o esto se deba al hecho de que una explicación detallada dificulta la lectura del artículo.

En este artículo, intentaremos combinar lo mejor de ambos mundos proporcionando un script bash para instalar automáticamente WordPress en Ubuntu, además de recorrerlo, explicando qué hace cada pieza, así como los compromisos que hicimos al desarrollarlo. . Si eres un usuario avanzado, puedes saltarte el texto del artículo y simplemente toma el guión para modificación y uso en sus entornos. El resultado del script es una instalación personalizada de WordPress con soporte Lets Encrypt, que se ejecuta en la unidad NGINX y es adecuada para uso en producción.

La arquitectura desarrollada para implementar WordPress usando la Unidad NGINX se describe en artículo anterior, ahora también configuraremos más cosas que no se trataron allí (como en muchos otros tutoriales):

• CLI de WordPress
• Certificados Let's Encrypt y TLSSSSL
• Renovación automática de certificados
• Almacenamiento en caché NGINX
• Compresión NGINX
• Soporte HTTPS y HTTP/2
• Automatización de procesos

El artículo describirá la instalación en un servidor, que albergará simultáneamente un servidor de procesamiento estático, un servidor de procesamiento PHP y una base de datos. Una instalación que admita múltiples servicios y hosts virtuales es un tema potencial para el futuro. Si quieres que escribamos sobre algo que no está en estos artículos, escribe en los comentarios.

Requisitos

• Servidor de contenedores (LXC o LXD), una máquina virtual o un servidor Iron normal con al menos 512 MB de RAM y Ubuntu 18.04 o posterior instalado.
• Puertos accesibles a Internet 80 y 443
• Nombre de dominio asociado con la dirección IP pública de este servidor
• Acceso raíz (sudo).

Descripción general de la arquitectura

La arquitectura es la misma que se describe. más temprano, una aplicación web de tres niveles. Consiste en scripts PHP que se ejecutan en el motor PHP y archivos estáticos que procesa el servidor web.

Principios Generales

• Muchos comandos de configuración en un script están incluidos en condiciones if para idempotencia: el script se puede ejecutar varias veces sin el riesgo de cambiar la configuración que ya está implementada.
• El script intenta instalar software desde los repositorios, por lo que puede aplicar actualizaciones del sistema con un solo comando (apt upgrade para Ubuntu).
• Los comandos intentan detectar que se están ejecutando en un contenedor para poder cambiar su configuración en consecuencia.
• Para establecer la cantidad de procesos de subprocesos que se iniciarán en la configuración, el script intenta adivinar la configuración automática para trabajar en contenedores, máquinas virtuales y servidores de hardware.
• Al describir la configuración, siempre pensamos en primer lugar en la automatización, que esperamos se convierta en la base para crear su propia infraestructura en forma de código.
• Todos los comandos se ejecutan como usuario. raíz, porque cambian la configuración básica del sistema, pero directamente WordPress se ejecuta como un usuario normal.

Configuración de variables de entorno

Configure las siguientes variables de entorno antes de ejecutar el script:

• WORDPRESS_DB_PASSWORD - Contraseña de la base de datos de WordPress
• WORDPRESS_ADMIN_USER - Nombre del administrador de WordPress
• WORDPRESS_ADMIN_PASSWORD - Contraseña de administrador de WordPress
• WORDPRESS_ADMIN_EMAIL - Correo electrónico del administrador de WordPress
• WORDPRESS_URL es la URL completa del sitio de WordPress, comenzando en https://.
• LETS_ENCRYPT_STAGING - vacío de forma predeterminada, pero al establecer el valor en 1, utilizará los servidores provisionales de Let's Encrypt, que son necesarios para solicitar certificados con frecuencia al probar su configuración; de lo contrario, Let's Encrypt puede bloquear temporalmente su dirección IP debido a una gran cantidad de solicitudes. .

El script verifica que estas variables relacionadas con WordPress estén configuradas y, en caso contrario, sale.
Líneas de script 572-576 comprueban el valor LETS_ENCRYPT_STAGING.

Establecer variables de entorno derivadas

El script en las líneas 55-61 establece las siguientes variables de entorno, ya sea con algún valor codificado o utilizando un valor obtenido de las variables establecidas en la sección anterior:

• DEBIAN_FRONTEND="noninteractive" - Indica a las aplicaciones que se están ejecutando en un script y que no hay posibilidad de interacción del usuario.
• WORDPRESS_CLI_VERSION="2.4.0" es la versión de la aplicación CLI de WordPress.
• WORDPRESS_CLI_MD5= "dedd5a662b80cda66e9e25d44c23b25c" — suma de comprobación del archivo ejecutable de WordPress CLI 2.4.0 (la versión se especifica en la variable WORDPRESS_CLI_VERSION). El script en la línea 162 usa este valor para verificar que se haya descargado el archivo CLI de WordPress correcto.
• UPLOAD_MAX_FILESIZE="16M" - el tamaño máximo de archivo que se puede cargar en WordPress. Esta configuración se utiliza en varios lugares, por lo que es más fácil configurarla en un solo lugar.
• TLS_HOSTNAME= "$(echo ${WORDPRESS_URL} | cut -d'/' -f3)" - nombre de host del sistema, recuperado de la variable WORDPRESS_URL. Se utiliza para obtener los certificados TLS/SSL adecuados de Let's Encrypt, así como la verificación interna de WordPress.
• NGINX_CONF_DIR="/etc/nginx" - ruta al directorio con la configuración de NGINX, incluido el archivo principal nginx.conf.
• CERT_DIR="/etc/letsencrypt/live/${TLS_HOSTNAME}" — la ruta a los certificados Let's Encrypt para el sitio de WordPress, obtenida de la variable TLS_HOSTNAME.

Asignar un nombre de host a un servidor de WordPress

El script establece el nombre de host del servidor para que coincida con el nombre de dominio del sitio. Esto no es necesario, pero es más conveniente enviar correo saliente a través de SMTP cuando se configura un único servidor, según lo configurado en el script.

código de secuencia de comandos

# 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

Agregar nombre de host a /etc/hosts

Adición WP-Cron utilizado para ejecutar tareas periódicas, requiere que WordPress pueda acceder a sí mismo a través de HTTP. Para asegurarse de que WP-Cron funcione correctamente en todos los entornos, el script agrega una línea al archivo / etc / hostspara que WordPress pueda acceder a sí mismo a través de la interfaz loopback:

código de secuencia de comandos

# 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 de las herramientas necesarias para los siguientes pasos.

El resto del script necesita algunos programas y supone que los repositorios están actualizados. Actualizamos la lista de repositorios, luego de lo cual instalamos las herramientas necesarias:

código de secuencia de comandos

# 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

Agregar unidad NGINX y repositorios NGINX

El script instala NGINX Unit y NGINX de código abierto desde los repositorios oficiales de NGINX para garantizar que se utilicen las versiones con los últimos parches de seguridad y correcciones de errores.

El script agrega el repositorio de la Unidad NGINX y luego el repositorio NGINX, agregando la clave de los repositorios y los archivos de configuración. apt, definiendo el acceso a los repositorios a través de Internet.

La instalación real de NGINX Unit y NGINX se realiza en la siguiente sección. Agregamos previamente los repositorios para no tener que actualizar los metadatos varias veces, lo que agiliza la instalación.

código de secuencia de comandos

# 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) y sus dependencias

Una vez agregados todos los repositorios, actualice los metadatos e instale las aplicaciones. Los paquetes instalados por el script también incluyen las extensiones PHP recomendadas al ejecutar WordPress.org

código de secuencia de comandos

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

Configuración de PHP para usar con NGINX Unit y WordPress

El script crea un archivo de configuración en el directorio. conf.d. Esto establece el tamaño máximo de archivo para cargas de PHP, activa la salida de errores de PHP a STDERR para que se escriban en el registro de la Unidad NGINX y reinicia la Unidad NGINX.

código de secuencia de comandos

# 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

Especificación de la configuración de la base de datos MariaDB para WordPress

Hemos elegido MariaDB en lugar de MySQL porque tiene más actividad comunitaria y también es probable que proporciona un mejor rendimiento por defecto (Probablemente, aquí todo es más simple: para instalar MySQL, necesita agregar otro repositorio, aprox. traductor).

El script crea una nueva base de datos y crea credenciales para acceder a WordPress a través de la interfaz loopback:

código de secuencia de comandos

# 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 del programa CLI de WordPress

En este paso, el script instala el programa. WP-CLI. Con él, puedes instalar y administrar la configuración de WordPress sin tener que editar archivos manualmente, actualizar la base de datos o ingresar al panel de control. También se puede utilizar para instalar temas y complementos y actualizar WordPress.

código de secuencia de comandos

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 y configuración de WordPress

El script instala la última versión de WordPress en un directorio. /var/www/wordpressy también cambia la configuración:

• La conexión de la base de datos funciona a través de un socket de dominio Unix en lugar de TCP en bucle invertido para reducir el tráfico TCP.
• WordPress agrega un prefijo https:// a la URL si los clientes se conectan a NGINX a través de HTTPS, y también envía el nombre de host remoto (según lo proporcionado por NGINX) a PHP. Usamos un fragmento de código para configurar esto.
• WordPress necesita HTTPS para iniciar sesión
• La estructura de URL predeterminada se basa en recursos.
• Establece los permisos correctos en el sistema de archivos para el directorio de WordPress.

código de secuencia de comandos

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

Configuración de la unidad NGINX

El script configura la unidad NGINX para ejecutar PHP y procesar rutas de WordPress, aislando el espacio de nombres del proceso PHP y optimizando la configuración de rendimiento. Hay tres características a tener en cuenta aquí:

• La compatibilidad con espacios de nombres está determinada por la condición, basada en la verificación de que el script se esté ejecutando en un contenedor. Esto es necesario porque la mayoría de las configuraciones de contenedores no admiten el lanzamiento anidado de contenedores.
• Si hay soporte para espacios de nombres, deshabilite el espacio de nombres. del sistema,. Esto es para permitir que WordPress se conecte a ambos puntos finales y esté disponible en la web al mismo tiempo.
• El número máximo de procesos se define de la siguiente manera: (Memoria disponible para ejecutar MariaDB y NGINX Uniy)/(Límite de RAM en PHP + 5)
  Este valor se establece en la configuración de la unidad NGINX.

Este valor también implica que siempre hay al menos dos procesos PHP en ejecución, lo cual es importante porque WordPress realiza muchas solicitudes asincrónicas a sí mismo y, sin procesos adicionales, la ejecución, por ejemplo, WP-Cron se interrumpirá. Es posible que desee aumentar o disminuir estos límites según su configuración local, porque las configuraciones creadas aquí son conservadoras. En la mayoría de los sistemas de producción, las configuraciones están entre 10 y 100.

código de secuencia de comandos

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

Configurar los ajustes básicos de NGINX

El script crea un directorio para el caché NGINX y luego crea el archivo de configuración principal. nginx.conf. Preste atención a la cantidad de procesos del controlador y a la configuración del tamaño máximo de archivo para cargar. También hay una línea que incluye el archivo de configuración de compresión definido en la siguiente sección, seguido de la configuración de almacenamiento en caché.

código de secuencia de comandos

# 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

Configurar la compresión NGINX

Comprimir contenido sobre la marcha antes de enviarlo a los clientes es una excelente manera de mejorar el rendimiento del sitio, pero solo si la compresión está configurada correctamente. Esta sección del script se basa en la configuración. por lo tanto.

código de secuencia de comandos

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, el script crea un archivo de configuración para WordPress. predeterminado.conf en el catalogo conf.d. Está configurado aquí:

• Activar los certificados TLS recibidos de Let's Encrypt a través de Certbot (la configuración se encontrará en la siguiente sección)
• Configuración de los ajustes de seguridad TLS según las recomendaciones de Let's Encrypt
• Habilite el almacenamiento en caché de solicitudes de omisión durante 1 hora de forma predeterminada
• Deshabilite el registro de acceso, así como el registro de errores si no se encuentra el archivo, para dos archivos solicitados comúnmente: favicon.ico y robots.txt
• Evitar el acceso a archivos ocultos y algunos archivos. . Phppara evitar el acceso ilegal o el inicio involuntario
• Deshabilitar el registro de acceso para archivos estáticos y de fuentes
• Configuración del encabezado Acceso-Control-Permitir-Origen para archivos de fuentes
• Agregar enrutamiento para index.php y otras estáticas.

código de secuencia de comandos

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

Configurar Certbot para certificados de Let's Encrypt y renovarlos automáticamente

Certbot es una herramienta gratuita de Electronic Frontier Foundation (EFF) que le permite obtener y renovar automáticamente certificados TLS de Let's Encrypt. El script hace lo siguiente para configurar Certbot para procesar certificados de Let's Encrypt en NGINX:

• Detiene NGINX
• Descargas la configuración TLS recomendada
• Ejecuta Certbot para obtener certificados para el sitio.
• Reinicia NGINX para usar certificados
• Configura Certbot para que se ejecute diariamente a las 3:24 a. m. para verificar si es necesario renovar los certificados y, si es necesario, descargar nuevos certificados y reiniciar NGINX.

código de secuencia de comandos

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 de su sitio

Hablamos anteriormente sobre cómo nuestro script configura NGINX y NGINX Unit para brindar servicio a un sitio listo para producción con TLSSSL habilitado. También podrás, dependiendo de tus necesidades, añadir en el futuro:

• Apoyar Brotli, compresión sobre la marcha mejorada sobre HTTPS
• ModSecurity с reglas para wordpresspara prevenir ataques automatizados en su sitio
• Резервное копирование para WordPress que más te convenga
• Protección a través de AppArmor (en Ubuntu)
• Postfix o msmtp para que WordPress pueda enviar correo
• Revisar su sitio para comprender cuánto tráfico puede manejar

Para un rendimiento aún mejor del sitio, recomendamos actualizar a NGINX más, nuestro producto comercial de nivel empresarial basado en NGINX de código abierto. Sus suscriptores recibirán un módulo Brotli cargado dinámicamente, así como (por una tarifa adicional) NGINX ModSecurity WAF. También ofrecemos Protección de aplicaciones NGINX, un módulo WAF para NGINX Plus basado en la tecnología de seguridad líder en la industria de F5.

NB Para obtener soporte para un sitio altamente cargado, puede contactar a los expertos. Southbridge. Garantizaremos un funcionamiento rápido y confiable de su sitio web o servicio bajo cualquier carga.

Fuente: habr.com