Automatizojmë instalimin e WordPress me NGINX Unit dhe Ubuntu

Automatizojmë instalimin e WordPress me NGINX Unit dhe Ubuntu

Ka shumë materiale për instalimin e WordPress, një kërkim në Google me fjalët kyçe "WordPress install" do të japë rreth gjysmë milioni rezultate. Megjithatë, mes tyre ka shumë pak udhëzues praktikë për të instaluar dhe konfiguruar WordPress dhe sistemin operativ përkatës në mënyrë që ato të jenë të qëndrueshme për një periudhë të gjatë. Mund të jetë se konfigurimet e duhura varen shumë nga nevojat specifike, ose se një shpjegim i detajuar e bën artikullin të vështirë për t'u lexuar.

Në këtë artikull ne do të përpiqemi të mbledhim më të mirën nga të dy qasjet, duke ofruar një skript në bash për instalimin automatik të WordPress në Ubuntu, si dhe do ta kalojmë atë përmes një përshkrimi të çdo pjese, duke shpjeguar çfarë bën secila pjesë dhe cilat kompromise kemi bërë gjatë zhvillimit të tij. Nëse jeni një përdorues i avancuar — mund të injoroni tekstin e artikullit dhe thjesht merrni skriptin për ta modifikuar dhe përdorur në ambientet tuaja. Rezultati i skriptit është një instalim i konfigurueshëm i WordPress me mbështetje për Lets Encrypt, që funksionon në NGINX Unit dhe është i aplikueshëm për përdorim industrial.

Arkitektura e zhvilluar për shpërndarjen e WordPress duke përdorur NGINX Unit është përshkruar në një artikull më të vjetër, tani ne gjithashtu do të konfigurojmë gjëra që atje nuk janë mbuluar (siç është në shumë udhëzues të tjerë):

  • WordPress CLI
  • Let’s Encrypt dhe certifikatat TLSSSL
  • Automatizimi i rinovimeve të certifikatat
  • Keshimi NGINX
  • Shtypja e NGINX
  • Mbështetje për HTTPS dhe HTTP/2
  • Automatizimi i procesit

Artikulli do të përshkruajë instalimin në një server të vetëm, ku do të vendosen ndërlidhësi i skedarëve statikë, serveri i PHP dhe baza e të dhënave. Një instalim që mbështet shumë hoste virtualë dhe shërbime — do të jetë një temë potenciale për të ardhmen. Dëshironi që të shkruajmë për diçka që nuk është në këto artikuj — shkruani në komentet.

Kërkesat

  • Kontejner dhe server (LXC ose LXD), makinë virtuale, apo serveri i zakonshëm fizik, me të paktën 512 MB memorie RAM dhe Ubuntu 18.04 ose më të ri të instaluar.
  • Portat 80 dhe 443 të aksesueshme nga interneti
  • Emri i domenit të lidhur me adresën publike IP të këtij serveri
  • Akses me të drejtat e root (sudo).

Përmbledhje e arkitekturës

Arkitektura është e njëjtë siç është përshkruar më parë, një aplikacion web me tre nivele. Ai përbëhet nga skriptet PHP që ekzekutohen në procesorin PHP, dhe skedarët statikë që trajtohen nga serveri web.

Automatizojmë instalimin e WordPress me NGINX Unit dhe Ubuntu

Parimet e përgjithshme

  • Shumë komanda për konfigurimin në skript janë të mbështjella në kushte (if) për idempotencë: skripti mund të ekzekutohet disa herë pa rrezik për të ndryshuar konfigurimet që janë tashmë në rregull.
  • Skripti përpiqet të instaloje softuer nga depot, në mënyrë që të mund të aplikoni azhurnimet e sistemit me një komandë (apt upgrade për Ubuntu).
  • Komandat përpiqen të përcaktojnë nëse ato ekzekutohen në një kontejner, për të ndërruar përkatësisht konfigurimet e tyre.
  • Për të caktuar numrin e proceseve/rrjedhave që do të ekzekutohen në konfigurim, skripti përpiqet të parashikojë parametrat automatike të konfigurimit për punë në konteinerë, makina virtuale, dhe servera fizikë.
  • Kur përshkruajmë konfigurimet, gjithmonë mendojmë për automatizimin, që shpresojmë se do të bëhet baza për krijimin e infrastrukturës tuaj si kod.
  • Të gjitha komandat ekzekutohen nga përdoruesi root, pasi ato ndryshojnë konfigurimet kryesore të sistemit, por WordPress funksionon nën një përdorues të zakonshëm.

Instalimi i variablave të ambientit

Vendosni variablat e mëposhtëm të mjedisit, para se të ekzekutoni skriptin:

  • WORDPRESS_DB_PASSWORD — fjalëkalimi për bazën e të dhënave WordPress
  • WORDPRESS_ADMIN_USER — emri i administratorit të WordPress
  • WORDPRESS_ADMIN_PASSWORD — fjalëkalimi i administratorit të WordPress
  • WORDPRESS_ADMIN_EMAIL — emaili i administratorit të WordPress
  • WORDPRESS_URL — URL e plotë e faqes WordPress, duke filluar nga https://.
  • LETS_ENCRYPT_STAGING — e lënë bosh si parazgjedhje, por duke vendosur vlerën në 1, do të përdorni serverët staging të Let’s Encrypt, të nevojshëm për kërkesa të shpeshta për certifikata gjatë testimit të konfigurimeve tuaja, përndryshe Let’s Encrypt mund t'ju bllokojë përkohësisht adresën IP për shkak të numrit të madh të kërkesave.

Skripti kontrollon nëse variablat e lidhur me WordPress janë vendosur, dhe përfundon punën nëse jo.
Linjat e skriptit 572-576 kontrollojnë vlerën LETS_ENCRYPT_STAGING.

Vendosja e variablave të mjedisit të nxjerrë

Skripti në linjat 55-61 vendos variablat e mjedisit të mëposhtëm, ose në një vlerë të caktuar, ose duke përdorur vlerat e marra nga variablat e vendosur në seksionin e mëparshëm:

  • DEBIAN_FRONTEND="noninteractive" — informon aplikacionet se ato po ekzekutohen në skript dhe nuk ka mundësi për ndërveprim me përdoruesin.
  • WORDPRESS_CLI_VERSION="2.4.0" — versioni i aplikacionit WordPress CLI.
  • WORDPRESS_CLI_MD5= "dedd5a662b80cda66e9e25d44c23b25c" — kontrola e shumës së skedarit ekzekutiv WordPress CLI 2.4.0 (versioni jepet në variablën WORDPRESS_CLI_VERSION). Skripti në rreshtin 162 përdor këtë vlerë për të kontrolluar që skedari WordPress CLI është shkarkuar siç duhet.
  • UPLOAD_MAX_FILESIZE="16M" — madhësia maksimale e skedarit që mund të ngarkohet në WordPress. Ky parametër përdoret në disa vende, kështu që është më e lehtë ta përcaktojmë në një vend.
  • TLS_HOSTNAME= "$(echo ${WORDPRESS_URL} | cut -d'/' -f3)" — emri i hostit të sistemit, i nxjerrë nga variabli WORDPRESS_URL. Përdoret për të marrë certifikatat përkatëse TLS/SSL nga Let’s Encrypt, si dhe për verifikimin e brendshëm të WordPress.
  • NGINX_CONF_DIR="/etc/nginx" — rruga për katalogun me konfigurimet NGINX, duke përfshirë skedarin kryesor nginx.conf.
  • CERT_DIR="/etc/letsencrypt/live/${TLS_HOSTNAME}" — rruga për certifikatat Let’s Encrypt për faqen WordPress, e nxjerrë nga variabli TLS_HOSTNAME.

Caktohet emri i hostit për serverin WordPress

Skripti cakton emrin e hostit për serverin, në mënyrë që vlera të përputhet me emrin e domain-it të faqes. Kjo nuk është e detyrueshme, por është më e lehtë për të dërguar email-e dalëse përmes SMTP kur konfigurohet një server i vetëm, siç është konfiguruar nga skripti.

kodi i skriptit

# 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

Shtimi i emrit të hostit në /etc/hosts

Shtesë WP‑Cron përdoret për të ekzekutuar detyra të periodike, kërkon që WordPress të ketë qasje në veten e tij përmes HTTP. Për t'u siguruar që WP-Cron punon siç duhet në të gjitha mjediset, skripti shton një rresht në skedarin /etc/hosts, në mënyrë që WordPress të ketë qasje në veten e tij përmes ndërlidhësit loopback:

kodi i skriptit

# 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

Instalimi i mjeteve të nevojshme për hapat e ardhshëm

Pjesa e mbetur e skriptit kërkon disa programe dhe supozon që depozitat janë të azhurnuara. Ne azhurnojmë listën e depozitave dhe pastaj instalojmë mjetet e nevojshme:

kodi i skriptit

# 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

Shtimi i depozitave NGINX Unit dhe NGINX

Skripti instalon NGINX Unit dhe NGINX me burim të hapur nga depozitat zyrtare të NGINX, për t'u siguruar që përdoren versionet me përditësimet më të fundit të sigurisë dhe përmirësimeve të gabimeve.

Skripti shton depozitën NGINX Unit dhe më pas depozitën NGINX, duke shtuar çelësin e depozitave dhe skedarët e konfigurimeve apt, të cilat caktuan qasje në depozitat përmes internetit.

Instalimi aktual i NGINX Unit dhe NGINX ndodh në seksionin e ardhshëm. Ne i kemi shtuar paraprakisht depozitat për të mos azhurnuar metadata disa herë, gjë që e bën instalimin më të shpejtë.

kodi i skriptit

# 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

Instalimi i NGINX, NGINX Unit, PHP MariaDB, Certbot (Let’s Encrypt) dhe varësive të tyre

Sapo të gjitha depozat të jenë shtuar, ne azhurnojmë metadatat dhe instalojmë aplikacionet. Paketat që instalohen nga skripti gjithashtu përfshijnë zgjerimet PHP, të rekomanduara gjatë ekzekutimit në WordPress.org

kodi i skriptit

echo " Azhurnimi i metadata e depozitave"
apt-get -qq update

# Instaloni PHP me varësitë dhe NGINX Unit
echo " Instalimi i PHP, NGINX Unit, NGINX, Certbot, dhe 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

Konfigurimi i PHP për t'u përdorur me NGINX Unit dhe WordPress

Skripti krijon një skedar konfigurimi në katalogun conf.d. Këtu caktohet madhësia maksimale e skedarëve të ngarkuar për PHP, aktivizohet nxjerrja e gabimeve PHP në STDERR, në mënyrë që ato të shkruhen në regjistrin e NGINX Unit, si dhe ri-nis NGINX Unit.

kodi i skriptit

# 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

Caktimi i konfigurimeve të bazës së të dhënave MariaDB për WordPress

Ne kemi zgjedhur MariaDB në vend të MySQL, sepse ka më shumë aktivitet të komunitetit, për më tepër, ajo ndoshta ofron performancë më të lartë si standard (ndoshta këtu është më e thjeshtë: për të instaluar MySQL, duhet të shtohet një depo tjetër, shënim i përkthyesit).

Skripti krijon një bazë të re të të dhënave dhe krijon kredencialet për qasje në WordPress përmes ndërlidhësit loopback:

kodi i skriptit

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

Instalimi i programit WordPress CLI

Në këtë hap skripti instalon programin WP-CLI. Me të mund të instaloni dhe menaxhoni konfigurimet e WordPress pa pasur nevojë për redaktimin manual të skedareve, azhurnimin e bazës së të dhënave ose hyrjen në panelin e administratës. Po ashtu, me të mund të instaloni temat dhe shtesat dhe të kryeni azhurnimin e WordPress.

kodi i skriptit

if [ ! -f /usr/local/bin/wp ]; then
  # Instaloni mjetin WordPress CLI
  echo " Instalimi i mjetit 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

Instalimi dhe konfigurimi i WordPress

Skripti instalon versionin më të fundit të WordPress në katalogun /var/www/wordpress, si dhe ndryshon konfigurimet:

  • Lidhja me bazën e të dhënave funksionon përmes socket-eve dhezaksion unix në vend të TCP në loopback, për të reduktuar trafikun TCP.
  • WordPress shton një prefix https:// në URL, nëse klientët lidhen me NGINX përmes protokollit HTTPS, dhe gjithashtu dërgon emrin e hostit të largët (siç e ofron NGINX) në PHP. Ne aplikojmë një pjesë kodi për ta konfiguruar këtë.
  • WordPress ka nevojë për HTTPS për të hyrë
  • Struktura e URL sipas parazgjedhjes bazohet në burimet
  • Caktohen të drejtat e duhura në sistemin e skedarëve për katalogun WordPress.

kodi i skriptit

nëse [ ! -d /var/www/wordpress ]; atëherë
  # Krijoni katalogët WordPress
  mkdir -p /var/www/wordpress
  chown -R www-data:www-data /var/www

  # Shkarkoni WordPress duke përdorur WordPress CLI
  echo " Duke instaluar 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}""

  # Ky fragment futet në skedarin wp-config.php kur krijohet;
  # informon WordPress që ne jemi pas një proxy të kthyer dhe si i tillë
  # lejon që të gjenerojë lidhje duke përdorur HTTPS
  cat > /tmp/wp_forwarded_for.php << 'EOM'
/* Rrotulloni HTTPS 'on' nëse HTTP_X_FORWARDED_PROTO përputhet me '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

  # Krijoni konfigurimin e 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

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

  # Caktoni strukturën e permalink që është një standard të arsyeshëm që nuk është në UI
  su -s /bin/sh -p -c "wp --path=/var/www/wordpress option update permalink_structure '/%year%/%monthnum%/%postname%/'" www-data

  # Hiqni skedarin e shembullit sepse është mbeturinë dhe mund të jetë një problem në sigurinë
  rm /var/www/wordpress/wp-config-sample.php

  # Sigurohuni që lejet e WordPress të jenë të sakta
  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

Konfigurimi i NGINX Unit

Skema konfigurimit përcakton NGINX Unit për të ekzekutuar PHP dhe për të trajtuar rrugët e WordPress, duke izoluar hapësirën emërore të proceseve PHP dhe optimizuar cilësimet e performancës. Këtu ka tre funksione që meritojnë vëmendje:

  • Mbështetjes së hapësirave emërore i jepet përparësi në bazë të kushtit mbi verifikimin e ekzekutimit të skriptit në konteiner. Kjo është e nevojshme pasi shumica e cilësimeve të konteinerëve nuk mbështesin ekzekutimin e konteinerëve të brendshëm.
  • Nëse ka mbështetje për hapësira emërore, atëherë ndalon hapësirën emërore network. Kjo është e nevojshme që të lejojë WordPress të lidhet njëkohësisht me endpoints dhe të jetë e disponueshme në internet.
  • Numri maksimal i proceseve përcaktohet si më poshtë: (Memoria e disponueshme për MariaDB dhe NGINX Unit të ekzekutuar)/(kufiri i memories në PHP + 5)
    Ky vlerë vendoset në cilësimet e NGINX Unit.

Kjo vlerë gjithashtu nënkupton se gjithmonë ka të paktën dy procese PHP në ekzekutim, që është e rëndësishme, pasi WordPress bën shumë kërkesa asinkrone ndaj vetes, dhe pa procese të tjera, ekzekutimi, për shembull, i WP-Cron, do të jetë i thyer. Mund të dëshironi të rritni ose ulni këto kufij bazuar në cilësimet tuaja lokale, sepse cilësimet e krijuara këtu janë konservatore. Në shumicën e sistemeve prodhuese, cilësimet janë midis 10 dhe 100.

kodi i skriptit

nëse [ "${container:-unknown}" != "lxc" ] && [ "$(grep -m1 -a container=lxc /proc/1/environ | tr -d ' ')" == "" ]; atëherë
  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 " Llogaritur numri maksimal i proceseve PHP si ${MAX_PHP_PROCESSES}. Mund të dëshironi ta rregulloni këtë vlerë për shkak të variacioneve në konfigurimin tuaj. Nuk është e pazakontë të shihni vlera midis 10-100 në konfigurimet prodhuese."

echo " Konfigurimi i NGINX Unit për të përdorur PHP dhe 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

Konfigurimi i NGINX

Konfigurimi i parametrave kryesorë të NGINX

Skema krijon një katalog për caching-in e NGINX, dhe pastaj krijon skedarin kryesor të konfigurimit nginx.conf. Vëreni numrin e proceseve përpunuese dhe caktimin e madhësisë maksimale të skedarit për ngarkesë. Gjithashtu ka një rresht që lidhet me skedarin e konfigurimit të kompresimit që përcaktohet në seksionin në vazhdim, duke përfunduar me cilësimet e caching.

kodi i skriptit

# 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

Konfigurimi i kompresionit NGINX

Kompresimi i përmbajtjes në flukso përpara se ta dërgoni atë klientëve është një mënyrë e shkëlqyer për të përmirësuar performancën e faqes, por vetëm nëse kompresimi është i konfiguruar siç duhet. Ky seksion i skemës është i bazuar në cilësime. këtu.

kodi i skriptit

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
# Aktivoni kompresimin gzip.
# Default: off
gzip on;
# Niveli i kompresimit (1-9).
# 5 është një kompromis i përsosur ndërmjet madhësisë dhe përdorimit të CPU, duke ofruar rreth 75%
# reduktim për shumicën e skedarëve ASCII (gati identike me nivelin 9).
# Default: 1
gzip_comp_level 6;
# Mos kompresoni asgjë që është tashmë e vogël dhe e pamundur të zvogëlohet shumë nëse
# ndonjëherë (default është 20 bytes, që është e keqe pasi zakonisht çon në skedarë më të mëdhenj pas gzipping).
# Default: 20
gzip_min_length 256;
# Kompresoni të dhënat edhe për klientët që lidhen me ne përmes proxy-eve,
# identifikuar nga header-i "Via" (kërkohet për CloudFront).
# Default: off
gzip_proxied any;
# Informoni proxy-t të ruajnë si versionin gzipped ashtu edhe versionin e zakonshëm të një burimi
# sa herë që header-i i mundësive Accept-Encoding të klientit ndryshon;
# Shmangni çështjen ku një klient që nuk ka kapacitet gzip (i cili është jashtëzakonisht i rrallë
# sot) do të shfaqë gjëra të paqarta nëse proxy-i i jep atij versionin gzipped.
# Default: off
gzip_vary on;
# Kompresoni të gjitha daljet etiketuar me një nga MIME-të e mëposhtme.
# `text/html` gjithmonë kompresohet nga moduli gzip.
# 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

Konfigurimi i NGINX për WordPress

Më pas skripti krijon një skedar konfigurimi për WordPress default.conf në katalog conf.d. Këtu konfiguroni:

  • Aktivizimi i certifikatave TLS, të marra nga Let’s Encrypt përmes Certbot (konfigurimi i tij do të jetë në seksionin tjetër)
  • Konfigurimi i parametrave të sigurisë TLS, i bazuar në rekomandimet nga Let’s Encrypt
  • Aktivizimi i caching për kërkesat e kaluara për 1 orë si parazgjedhje
  • Çaktivizimi i regjistrimit të qasjes, si dhe regjistrimit të gabimeve, nëse skedari nuk gjendet, për dy skedarë të zakonshëm të kërkuar: favicon.ico dhe robots.txt
  • Ndalo qasjen në skedarë të fshehur dhe disa skedarë .php, për të parandaluar qasjen e paligjshme ose aktivizimin e paqëllimshëm
  • Çaktivizimi i regjistrimit të qasjes për statikën dhe skedarët e fontit
  • Caktoni header-in Access-Control-Allow-Origin për skedarët e fontit
  • Shtimi i routing për index.php dhe statikën tjetër.

kodi i skriptit

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 përdorur nga Certbot për Let’s Encrypt
    location ^~ /.well-known/acme-challenge/ {
      root /var/www/certbot;
    }
    location / {
      return 301 https://${TLS_HOSTNAME}$request_uri;
    }
}
server {
    listen      443 ssl http2;
    listen [::]:443 ssl http2;
    server_name ${TLS_HOSTNAME};
    root        /var/www/wordpress/;
    # Konfigurimi i 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 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;
    }

    # Ndaloni të gjitha përpjekjet për të aksesuar skedarë të fshehur si .htaccess, .htpasswd,
    # .DS_Store (Mac)
    # Ruani regjistrimin e kërkesave për t'i analizuar më vonë (ose për t'i kaluar në utilitetet e firewall-it
    # si fail2ban)
    location ~ /.{
        deny all;
    }
    # Ndaloni qasjen në çdo skedar me një zgjedhje .php në direktorinë e ngarkimeve;
    # punon në instalimet në nën-direktori dhe gjithashtu në rrjetin me shumë vende.
    # Ruani regjistrimin e kërkesave për t'i analizuar më vonë (ose për t'i kaluar në utilitetet e firewall-it
    # si fail2ban).
    location ~* /(?:uploads|files)/.*.php$ {
        deny all;
    }
    # WordPress: ndaloni qasjen në skedarët PHP të wp-content, wp-includes
    location ~* ^/(?:wp-content|wp-includes)/.*.php$ {
        deny all;
    }
    # Ndaloni qasjen publike në wp-config.php
    location ~* wp-config.php {
        deny all;
    }
    # Mos regjistroni qasjen për asetet statike, 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

Konfigurimi i Certbot për certifikat nga Let’s Encrypt dhe automatizimi i rinovimit të tyre

Certbot — një mjet falas nga Electronic Frontier Foundation (EFF), me ndihmën e të cilit mund të merrni dhe automatizoni rinovimin e certifikatave TLS nga Let’s Encrypt. Skripti kryen veprimet e mëposhtme, që çojnë në konfigurimin e Certbot për të trajtuar certifikatat nga Let’s Encrypt në NGINX:

  • Ndalon NGINX
  • Shkarkon parametrat e rekomanduar TLS
  • Ruan Certbot për të marrë certifikatat për sitin
  • Rinis NGINX për të përdorur certifikatat
  • Konfiguroni fillimin e përditshëm të Certbot në 3:24 të mëngjesit për të kontrolluar nevojën për rinovimin e certifikatave, si dhe, në rast nevoje, shkarkimin e certifikatave të reja dhe ridëshkimin e NGINX.

kodi i skriptit

echo " Ndaluar NGINX për të vendosur 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 " Shkarkimi i parametrave të rekomanduar 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 "Nuk mund të shkarkoni opsionet e fundit-ssl-nginx.conf"
fi

if [ ! -f ${NGINX_CONF_DIR}/ssl-dhparams.pem ]; then
  echo " Shkarkimi i parametrave të rekomanduar 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 "Nuk mund të shkarkoni ssl-dhparams.pem të fundit"
fi

# Nëse tls_certs_init.sh nuk është ekzekutuar më parë, hiqni certifikatat e vetë-shkruara
if [ ! -d "/etc/letsencrypt/accounts" ]; then
  echo " Heqja e certifikatave të vetë-shkruara"
  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 " Gjenerimi i certifikatave me Let's Encrypt"
  certbot certonly --standalone 
         -m "${WORDPRESS_ADMIN_EMAIL}" 
         ${CERTBOT_STAGING_FLAG} 
         --agree-tos --force-renewal --non-interactive 
         -d "${TLS_HOSTNAME}"
fi

echo " Duke nisur NGINX për të përdorur konfigurimin e ri"
service nginx start

# Shkruani crontab për rinovimin periodik të certifikatave Let's Encrypt
if [ "$(crontab -l | grep -m1 'certbot renew')" == "" ]; then
  echo " Shtimi i certbot në crontab për rinovimin automatik të Let's Encrypt"
  (crontab -l 2>/dev/null; echo "24 3 * * * certbot renew --nginx --post-hook 'service nginx reload'") | crontab -
fi

Konfigurimi shtesë i faqes suaj

Më lart, ne diskutuam se si skripti ynë konfiguron NGINX dhe NGINX Unit për të shërbyer një faqe që është gati për përdorim industrial me TLS SSL të aktivizuar. Ju gjithashtu mund të shtoni në të ardhmen, varësisht nga nevojat tuaja:

  • Përkrahje Brotli, kompresim më të avancuar në real-time për HTTPS
  • ModSecurity me rregulla për WordPress, për të parandaluar sulmet automatike në faqen tuaj
  • Kopjimi për WordPress, që ju përshtatet
  • Mbrojtje me anë të AppArmor Postfix ose msmtp, në mënyrë që WordPress të mund të dërgojë email
  • Kontrollime të faqes tuaj, në mënyrë që të kuptoni sa trafik mund të përballojë
  • Për një performancë edhe më të mirë të faqes, ne rekomandojmë të kaloni në

, produktin tonë komercial të nivelit të korporatave, të bazuar në NGINX me kod të hapur. Abonentët e tij do të marrin një modull të ngarkuar dinamikisht Brotli, si dhe (për një pagesë shtesë) NGINX PlusNGINX ModSecurity WAF . Ne gjithashtu ofrojmëNGINX App Protect , një modull WAF për NGINX Plus, i cili bazohet në teknologjinë kryesore të sigurisë nga F5.Për mbështetje të një faqeje me ngarkesë të lartë, ju mund të kontaktoni specialistët

Shën. . Do të sigurojmë funksionimin e shpejtë dhe të besueshëm të faqes ose shërbimit tuaj nën çdo ngarkesë. SouthbridgeKa shumë materiale për instalimin e WordPress, një kërkim në Google me fjalë kyçe "WordPress install" do të japë rreth gjysmë milioni rezultate. Megjithatë, mes tyre ka shumë pak udhëzime të vlefshme, sipas të cilave mund të instaloni dhe konfiguroni WordPress dhe sistemin operativ në nëntokë në mënyrë që të jenë të aftë për mbështetje të gjatë. Ndoshta, konfigurimet e duhura

Burimi: habr.com

Bleni hostim të besueshëm për faqe me mbrojtje nga DDoS, serverë VPS VDS 🔥 Bleni hostim të besueshëm për faqe me mbrojtje nga DDoS, serverë VPS VDS | ProHoster