Автоматизиране на инсталацията на WordPress с NGINX Unit и Ubuntu

Има множество материали за инсталиране на WordPress, търсенето в Google с ключовите думи "инсталирай WordPress" ще извади около половин милион резултати. Въпреки това, всъщност сред тях има много малко полезни ръководства, по които можете да инсталирате и настроите WordPress и подлежащата операционна система, така че да са в състояние да поддържат дългосрочно. Може би правилните настройки зависят много от конкретните нужди, или пък това е свързано с факта, че подробното обяснение прави статията трудна за четене.

В тази статия ще се опитаме да съберем най-доброто от двата подхода, предоставяйки bash скрипт за автоматична инсталация на WordPress на Ubuntu, както и ще преминем през него, обяснявайки какво прави всеки негов участък и какви компромиси направихме при неговото разработване. Ако сте опитен потребител — можете да пропуснете текста на статията и просто да вземете скрипта за модифициране и използване в вашите среди. Изходът от скрипта е конфигурируема инсталация на WordPress с поддръжка на Lets Encrypt, работеща на NGINX Unit и подходяща за индустриални приложения.

Разработената архитектура за разгръщане на WordPress с използване на NGINX Unit е описана в по-стара статия, сега също ще настроим допълнително неща, които не бяха покрити там (както и в много други ръководства):

• WordPress CLI
• Let’s Encrypt и TLS сертификатиSSL
• Автоматично обновление на сертификатите
• NGINX кеширане
• NGINX компресия
• Поддръжка на HTTPS и HTTP/2
• Автоматизация на процеса

В статията ще бъде описано инсталирането на един сървър, на който ще бъдат разположени едновременно сървър за обработка на статичен контент, сървър за обработка на PHP и база данни. Инсталация с поддръжка на множество виртуални хостове и услуги — потенциална тема за бъдеще. Искате ли да напишем за нещо, което няма в тези статии — пишете в коментарите.

Изисквания

• Сървър-контейнер (LXC или LXD), виртуална машина или обикновен физически сървър, с не по-малко от 512MB оперативна памет и инсталиран Ubuntu 18.04 или по-нов.
• Достъпни от интернет портове 80 и 443
• Домен име, свързано с публичния IP адрес на този сървър
• Достъп с root права (sudo).

Обзор на архитектурата

Архитектурата е същата, както беше описана по-рано, тристепенно web приложение. То се състои от PHP скриптове, изпълнявани на PHP обработвач, и статични файлове, обработвани от уеб сървъра.

Общи принципи

• Много от командите за конфигуриране в скрипта са обвити в условия (if) за идемпотентност: скрипта може да се изпълнява няколко пъти без риск от промяна на настройките, които вече са готови.
• Скрипта се опитва да инсталира софтуер от хранилища, така че можете да прилагате актуализации на системата с една команда (apt upgrade за Ubuntu).
• Командите се опитват да определят, че се изпълняват в контейнер, за да променят съответно своите настройки.
• За да зададете броя на стартираните процеси/нишки в настройките, скрипта опитва да познае автоматичните параметри за конфигуриране за работа в контейнери, виртуални машини и 'железни' сървъри.
• При описване на настройките винаги мислим първо за автоматизацията, която, надяваме се, ще стане основа за изграждането на собствена инфраструктура като код.
• Всички команди се изпълняват от потребителя root, тъй като те променят основните системни настройки, но самият WordPress работи от обикновен потребител.

Настройка на променливи на средата

Настройте следните променливи на средата, преди да стартирате скрипта:

• WORDPRESS_DB_PASSWORD — парола за базата данни на WordPress
• WORDPRESS_ADMIN_USER — име на администратор на WordPress
• WORDPRESS_ADMIN_PASSWORD — парола на администратора на WordPress
• WORDPRESS_ADMIN_EMAIL — email на администратора на WordPress
• WORDPRESS_URL — пълен URL на сайта на WordPress, започващ с https://.
• LETS_ENCRYPT_STAGING — по подразбиране е празно, но задавайки стойност 1, ще използвате staging сървъри на Let’s Encrypt, необходими за честото изискване на сертификати при тестване на вашите настройки, в противен случай Let’s Encrypt може временно да блокира вашия IP адрес поради голям брой заявки.

Скриптът проверява дали тези свързани с WordPress променливи са зададени, и приключва работа, ако не са.
Строките на скрипта от 572 до 576 проверяват стойността LETS_ENCRYPT_STAGING.

Настройка на производни променливи на средата

Скриптът в редове 55-61 задава следните променливи на средата, или с определена стойност, или с прилагане на стойност, получена от променливи, зададени в предишната част:

• DEBIAN_FRONTEND="noninteractive" — съобщава на приложенията, че те се изпълняват в скрипта и няма възможност за взаимодействие с потребителя.
• WORDPRESS_CLI_VERSION="2.4.0" — версия на приложението WordPress CLI.
• WORDPRESS_CLI_MD5= "dedd5a662b80cda66e9e25d44c23b25c" — контролна сума на изпълнимия файл WordPress CLI 2.4.0 (версията е зададена в променливата WORDPRESS_CLI_VERSION). Скриптът на 162-ия ред използва това значение, за да провери, че е изтеглен правилният файл WordPress CLI.
• UPLOAD_MAX_FILESIZE="16M" — максималният размер на файла, който може да бъде качен в WordPress. Тази настройка се използва на няколко места, затова е по-лесно да се зададе на едно място.
• TLS_HOSTNAME= "$(echo ${WORDPRESS_URL} | cut -d'\/ -f3)" — hostname на системата, извлечен от променливата WORDPRESS_URL. Използва се за получаване на съответстващи TLS/SSL сертификати от Let's Encrypt, а също така и за вътрешната проверка на WordPress.
• NGINX_CONF_DIR="\/etc\/nginx" — пътят към директорията с настройките на NGINX, включително основния файл nginx.conf.
• CERT_DIR="\/etc\/letsencrypt\/live\/${TLS_HOSTNAME}" — пътят към сертификатите Let's Encrypt за сайта на WordPress, получен от променливата TLS_HOSTNAME.

Назначаване на hostname на WordPress сървъра

Скриптът задава hostname на сървъра, така че стойността да съответства на домейн името на сайта. Това не е задължително, но е по-удобно за изпращане на изходяща поща чрез SMTP при настройка на единствен сървър, както е зададено в скрипта.

код на скрипта

# 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

Добавяне на hostname в \/etc\/hosts

Допълнение WP‑Cron се използва за стартиране на периодични задачи, изисква WordPress да има достъп до самия себе си чрез HTTP. За да се уверим, че WP-Cron работи коректно в всички среди, скриптът добавя ред в файла /etc/hosts, така че WordPress да може да има достъп до самия себе си чрез интерфейса loopback:

код на скрипта

# 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

Инсталиране на инструментите, необходими за следващите стъпки

Останалата част от скрипта изисква някои програми и предполага, че хранилищата са актуални. Ние обновяваме списъка с хранилища, след което инсталираме необходимите инструменти:

код на скрипта

# 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

Добавяне на хранилищата на NGINX Unit и NGINX

Скриптът инсталира NGINX Unit и NGINX с отворен код от официалните хранилища на NGINX, за да се увери, че се използват версии с последните актуализации за сигурност и корекции на грешки.

Скриптът добавя хранилището на NGINX Unit, а след това — хранилището на NGINX, добавяйки ключа на хранилищата и файловете с настройки apt, задаващи достъп до хранилищата през интернет.

Реалната инсталация на NGINX Unit и NGINX става в следващия раздел. Предварително добавяме хранилища, за да не обновяваме метаданните няколко пъти, което ускорява инсталацията.

код на скрипта

# 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

Инсталация на NGINX, NGINX Unit, PHP MariaDB, Certbot (Let’s Encrypt) и техните зависимости

След като всички хранилища са добавени, обновяваме метаданните и инсталираме приложенията. Пакетите, инсталирани със скрипта, включват също PHP разширения, препоръчани при стартиране на WordPress.org

код на скрипта

echo " Обновяване на хранилищните метаданни"
apt-get -qq update

# Инсталиране на PHP с зависимости и NGINX Unit
echo " Инсталиране на PHP, NGINX Unit, NGINX, Certbot и 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

Конфигуриране на PHP за работа с NGINX Unit и WordPress

Скриптът създава файл с настройки в директория conf.d. Тук се задава максималният размер на качваните файлове за PHP, активирането на изхода на PHP грешки в STDERR, така че те да се записват в логовете на NGINX Unit, а също така се рестартира NGINX Unit.

код на скрипта

# 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

Конфигуриране на настройките на MariaDB за WordPress

Избрахме MariaDB вместо MySQL, тъй като има по-голяма активност в общността и освен това, тя вероятно предоставя по-висока производителност по подразбиране (вероятно тук всичко е по-лесно: за да инсталирате MySQL, трябва да добавите още едно хранилище, бел. на преводача).

Скриптът създава нова база данни и създава идентификационни данни за достъп до WordPress чрез loopback интерфейса:

код на скрипта

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

Инсталация на WordPress CLI

На този етап скриптът инсталира програмата WP-CLI. С него можете да инсталирате и управлявате настройките на WordPress без необходимост от ръчно редактиране на файлове, обновяване на базата или влизане в административния панел. Също така можете да инсталирате теми и добавки и да извършвате обновление на WordPress.

код на скрипта

if [ ! -f /usr/local/bin/wp ]; then
  # Инсталиране на WordPress CLI
  echo " Инсталиране на инструмента WordPress CLI"
  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

Инсталация и настройка на WordPress

Скриптът инсталира последната версия на WordPress в директория /var/www/wordpress, а също така променя настройките:

• Съединението с базата данни работи чрез Unix домейн сокет вместо TCP на loopback, за да се намали TCP трафикът.
• WordPress добавя префикс https:// к URL, ако клиентите се свързват с NGINX по протокол HTTPS, и също така изпраща отдалечен hostname (както го предоставя NGINX) в PHP. Ние прилагаме фрагмент от код за да го настроим.
• WordPress изисква HTTPS за вход
• Структурата на URL по подразбиране се основава на ресурсите
• Настройват се правилните права на файловата система за каталога на WordPress.

код на скрипта

if [ ! -d /var/www/wordpress ]; then
  # Създаване на директории за WordPress
  mkdir -p /var/www/wordpress
  chown -R www-data:www-data /var/www

  # Изтегляне на WordPress с помощта на WordPress CLI
  echo " Инсталиране на 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}""

  # Този фрагмент се инжектира във файла wp-config.php, когато се създава;
  # той уведомява WordPress, че сме зад обратен прокси и така
  # позволява генериране на връзки с HTTPS
  cat > /tmp/wp_forwarded_for.php << 'EOM'
/* Включи HTTPS, ако HTTP_X_FORWARDED_PROTO съвпада с '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

  # Създаване на конфигурацията на WordPress
  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

  # Инсталиране на 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

  # Настройване на структура на постоянни линкове на разумен по подразбиране вариант, който не е в интерфейса
  su -s /bin/sh -p -c "wp --path=/var/www/wordpress option update permalink_structure '/%year%/%monthnum%/%postname%/'" www-data

  # Премахване на примерния файл, тъй като е ненужен и може да бъде проблем за сигурността
  rm /var/www/wordpress/wp-config-sample.php

  # Осигуряване, че правата на WordPress са правилни
  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

Настройка на NGINX Unit

Скриптът настройва NGINX Unit за работа с PHP и обработка на пътища на WordPress, изолирайки имената на процесите на PHP и оптимизирайки настройките за производителност. Тук има три функции, на които трябва да се обърне внимание:

• Подкрепата на пространствата на имената се определя по условие, основано на проверката дали скриптът работи в контейнер. Това е необходимо, тъй като повечето настройки на контейнерите не поддържат вложено стартиране на контейнери.
• Ако има поддръжка на пространства на имената, пространството на имената се деактивира мрежа. Това е необходимо, за да позволи на WordPress да се свързва едновременно и с крайни точки и да бъде достъпен в интернет.
• Максималният брой процеси се определя по следния начин: (Достъпна памет за стартирани MariaDB и NGINX Uniy) / (лимит на оперативната памет в PHP + 5)
  Тази стойност се задава в настройките на NGINX Unit.

Също така, тази стойност предполага, че винаги има поне два стартирани PHP процеса, което е важно, тъй като WordPress прави много асинхронни заявки към себе си, а без допълнителни процеси стартирането, например, на WP-Cron, ще се провали. Може би ще искате да увеличите или намалите тези ограничения в зависимост от вашите локални настройки, тъй като зададените настройки тук са консервативни. На повечето производствени системи настройките са между 10 и 100.

код на скрипта

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 " Изчислен максимален брой PHP процеси: ${MAX_PHP_PROCESSES}. Може да искате да настроите тази стойност поради вариации в конфигурацията си. Не е необичайно да видите стойности между 10-100 в производствени конфигурации."

echo " Конфигуриране на NGINX Unit за използване на PHP и 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

Настройка на NGINX

Настройка на основните параметри на NGINX

Скриптът създава директория за кеша на NGINX и след това създава основния файл за конфигурация nginx.conf. Обърнете внимание на броя на обработващите процеси и задаването на максималния размер на файла за качване. Има и ред, в който се свързва файл с настройките за компресия, определен в следващия раздел, следвани от настройките за кеширане.

код на скрипта

# Make directory for NGINX cache
mkdir -p /var/cache/nginx/proxy

echo " Configuring NGINX"
cat > ${NGINX_CONF_DIR}/nginx.conf << EOM
user nginx;
worker_processes auto;
error_log  /var/log/nginx/error.log warn;
pid        /var/run/nginx.pid;
events {
    worker_connections  1024;
}
http {
    include       ${NGINX_CONF_DIR}/mime.types;
    default_type  application/octet-stream;
    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';
    access_log  /var/log/nginx/access.log  main;
    sendfile        on;
    client_max_body_size ${UPLOAD_MAX_FILESIZE};
    keepalive_timeout  65;
    # gzip settings
    include ${NGINX_CONF_DIR}/gzip_compression.conf;
    # Cache settings
    proxy_cache_path /var/cache/nginx/proxy
        levels=1:2
        keys_zone=wp_cache:10m
        max_size=10g
        inactive=60m
        use_temp_path=off;
    include ${NGINX_CONF_DIR}/conf.d/*.conf;
}
EOM

Настройка за компресия на NGINX

Компресирането на съдържанието в движение преди изпращането му на клиентите е отличен начин за подобряване на производителността на сайта, но само ако компресията е правилно настроена. Тази част от скрипта е базирана на настройките оттук.

код на скрипта

cat > ${NGINX_CONF_DIR}\/gzip_compression.conf << 'EOM'
# Кредит: https://github.com/h5bp/server-configs-nginx/
# ----------------------------------------------------------------------
# | Компресия                                                       |
# ----------------------------------------------------------------------
# https://nginx.org/en/docs/http/ngx_http_gzip_module.html
# Включете gzip компресия.
# По подразбиране: изключена
gzip on;
# Ниво на компресия (1-9).
# 5 е перфектен компромис между размер и използване на CPU, предлагащ около 75%
# намаление за повечето ASCII файлове (почти идентично на ниво 9).
# По подразбиране: 1
gzip_comp_level 6;
# Не компресирайте нищо, което вече е малко и малко вероятно да се свие много,
# ако изобщо (по подразбиране е 20 байта, което е лошо, тъй като обикновено води до по-големи
# файлове след gzip).
# По подразбиране: 20
gzip_min_length 256;
# Компресирайте данни дори за клиенти, които се свързват с нас чрез прокси,
# идентифицирани по заглавието "Via" (изисква се за CloudFront).
# По подразбиране: изключена
gzip_proxied any;
# Кажете на прокситата да кешират както gzip версията, така и редовната версия на ресурса
# всеки път, когато заглавието на възможностите Accept-Encoding на клиента варира;
# Избягва проблема, при който некопираща gzip клиент (което е изключително рядко
# днес) би показала неразбираемо, ако техният прокси им даде gzip версията.
# По подразбиране: изключена
gzip_vary on;
# Компресирайте всички изходи, обявени с един от следните MIME-типове.
# `text/html` винаги се компресира от gzip модула.
# По подразбиране: 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

Настройка на NGINX за WordPress

Следващият скрипт създава конфигурационен файл за WordPress default.conf в директорията conf.d. Тук се настройва:

• Активиране на TLS сертификати, получени от Let’s Encrypt чрез Certbot (настройката му ще бъде в следващия раздел)
• Настройка на параметрите за сигурност на TLS, основана на препоръките от Let’s Encrypt
• Включване на кеширането на пропусканите заявки за 1 час по подразбиране
• Деактивиране на журнализацията на достъпа и журнализацията на грешки, когато файлът не е намерен, за два общи поисквани файла: favicon.ico и robots.txt
• Забрана на достъпа до скрити файлове и някои файлове .php, за да предотвратите неразрешен достъп или неволно стартиране
• Деактивиране на достъпа до логовете за статични ресурси и файлове с шрифтове
• Задаване на заглавие Access-Control-Allow-Origin за файлове с шрифтове
• Добавяне на маршрутизиране за index.php и друга статика.

код на скрипта

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, използван от Certbot за 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
    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 стаплинг
    ssl_stapling on;
    ssl_stapling_verify on;
    # Проксито кеширане
    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;
    }

    # Забраняване на всички опити за достъп до скрити файлове като .htaccess, .htpasswd,
    # .DS_Store (Mac)
    # Запазване на записите на заявките за по-късно анализиране (или предаване на защитни средства
    # като fail2ban)
    location ~ /\. {
        deny all;
    }
    # Забраняване на достъпа до файлове с разширение .php в директорията uploads;
    # работи и в инсталации под директори и в мрежи с много сайтове.
    # Запазване на записите на заявките за по-късно анализиране (или предаване на защитни средства
    # като fail2ban).
    location ~* /(?:uploads|files)/.*.php$ {
        deny all;
    }
    # WordPress: забрана за достъп до файлове с PHP в wp-content, wp-includes
    location ~* ^/(?:wp-content|wp-includes)/.*.php$ {
        deny all;
    }
    # Забрана за публичен достъп до wp-config.php
    location ~* wp-config.php {
        deny all;
    }
    # Не записвайте достъп до статични активи, медии
    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

Конфигуриране на Certbot за сертификати от Let's Encrypt и автоматично обновяване на тези сертификати

Certbot е безплатен инструмент от Electronic Frontier Foundation (EFF), с който можете да получавате и автоматично обновявате TLS сертификати от Let's Encrypt. Скриптът извършва следните действия, които водят до конфигуриране на Certbot за обработка на сертификати от Let's Encrypt в NGINX:

• Спира NGINX
• Изтегля препоръчителните TLS параметри
• Стартира Certbot, за да получи сертификати за сайта
• Рестартира NGINX, за да използва сертификатите
• Настройва ежедневен стартиращ скрипт на Certbot в 3:24 през нощта за проверка на необходимо обновление на сертификатите, както и за изтегляне на нови сертификати и перезареждане на NGINX, ако е необходимо.

код на скрипта

echo " Спирам NGINX, за да настроя 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 " Изтегляне на препоръчителните TLS параметри"
  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 "Неуспешно изтегляне на последния options-ssl-nginx.conf"
fi

if [ ! -f ${NGINX_CONF_DIR}/ssl-dhparams.pem ]; then
  echo " Изтегляне на препоръчителните TLS DH параметри"
  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 "Неуспешно изтегляне на последния ssl-dhparams.pem"
fi

# Ако tls_certs_init.sh не е стартиран преди, премахнете самоподписаните сертификати
if [ ! -d "/etc/letsencrypt/accounts" ]; then
  echo " Премахване на самоподписаните сертификати"
  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 " Генериране на сертификати с Let's Encrypt"
  certbot certonly --standalone 
         -m "${WORDPRESS_ADMIN_EMAIL}" 
         ${CERTBOT_STAGING_FLAG} 
         --agree-tos --force-renewal --non-interactive 
         -d "${TLS_HOSTNAME}"
fi

echo " Стартиране на NGINX, за да използва новата конфигурация"
service nginx start

# Записване на crontab за периодично обновление на сертификатите на Let's Encrypt
if [ "$(crontab -l | grep -m1 'certbot renew')" == "" ]; then
  echo " Добавяне на certbot в crontab за автоматично обновление на Let's Encrypt"
  (crontab -l 2>/dev/null; echo "24 3 * * * certbot renew --nginx --post-hook 'service nginx reload'") | crontab -
fi

Допълнителна конфигурация на вашия сайт

По-горе разгледахме как нашият скрипт конфигурира NGINX и NGINX Unit за обслужване на сайт, който е готов за производствени условия с включен TLS. В зависимост от вашите нужди, в бъдеще можете да добавите:

• Поддръжка на Brotli, подобрено компресиране в реално време по HTTPS
• ModSecurity с с правила за WordPress, за да предотвратите автоматични атаки на вашия сайт
• Резервно копие за WordPress, подходящо за вас
• Защита чрез AppArmor (в Ubuntu)
• Postfix или msmtp, за да може WordPress да изпраща имейли
• Проверки на сайта ви, за да разберете колко трафик може да издържи

За още по-добра производителност на сайта, препоръчваме да се ъпгрейднете до NGINX Plus, нашият търговски продукт на корпоративно ниво, основан на NGINX с открит код. Подписчиците му ще получат динамично зареждащия модул Brotli, както и (с допълнителна такса) NGINX ModSecurity WAF. Ние предлагаме също NGINX App Protect, модул WAF за NGINX Plus, основан на водеща в индустрията технология за сигурност от F5.

Забележка. За поддръжка на сайт с висока натовареност, можете да се свържете с експерти Southbridge. Осигуряваме бърза и надеждна работа на сайта или услугата ви под всякакво натоварване.

Източник: habr.com