„WordPress“ diegimo automatizavimas naudojant „NGINX Unit“ ir „Ubuntu“.
Yra daug medžiagos apie „WordPress“ diegimą; „Google“ paieška pagal „WordPress install“ duos apie pusę milijono rezultatų. Tačiau iš tikrųjų yra labai mažai naudingų vadovų, kurie gali padėti įdiegti ir sukonfigūruoti „WordPress“ ir pagrindinę operacinę sistemą, kad jos būtų palaikomos ilgą laiką. Galbūt teisingi nustatymai labai priklauso nuo jūsų konkrečių poreikių arba gali būti, kad dėl išsamaus paaiškinimo straipsnį sunku perskaityti.
Šiame straipsnyje mes pabandysime sujungti geriausius iš abiejų pasaulių, pateikdami bash scenarijų, kad automatiškai įdiegtų „WordPress“ Ubuntu, ir apžvelgsime jį, paaiškindami, ką daro kiekviena dalis ir kokius kompromisus padarėme jį kurdami. Jei esate patyręs vartotojas, galite praleisti straipsnio tekstą ir tiesiog paimk scenarijų modifikavimui ir naudojimui jūsų aplinkoje. Scenarijaus išvestis yra pasirinktinis „WordPress“ diegimas su „Lets Encrypt“ palaikymu, veikia NGINX įrenginiu ir tinkamas pramoniniam naudojimui.
Sukurta „WordPress“ diegimo naudojant NGINX įrenginį architektūra aprašyta senesnis straipsnis, dabar taip pat toliau konfigūruosime dalykus, kurie ten nebuvo aprašyti (kaip ir daugelyje kitų mokymo programų):
WordPress CLI
Užšifruokime ir TLSSSL sertifikatus
Automatinis sertifikato atnaujinimas
NGINX talpyklos kaupimas
NGINX suspaudimas
HTTPS ir HTTP/2 palaikymas
Procesų automatizavimas
Straipsnyje bus aprašytas diegimas viename serveryje, kuriame vienu metu bus statinio apdorojimo serveris, PHP apdorojimo serveris ir duomenų bazė. Diegimas su kelių virtualių kompiuterių ir paslaugų palaikymu yra potenciali ateities tema. Jei norite, kad parašytume apie tai, ko nėra šiuose straipsniuose, parašykite komentaruose.
Reikalavimai
Serverio konteineris (LXC arba LXD), virtualioji mašina arba įprastas aparatinės įrangos serveris, kuriame yra bent 512 MB RAM ir įdiegta Ubuntu 18.04 ar naujesnė versija.
Internetu pasiekiami 80 ir 443 prievadai
Domeno pavadinimas, susietas su šio serverio viešuoju IP adresu
Prieiga su root teisėmis (sudo).
Architektūros apžvalga
Architektūra yra tokia pati, kaip aprašyta anksčiau, trijų pakopų žiniatinklio programa. Jį sudaro PHP scenarijai, vykdomi PHP variklyje, ir statiniai failai, apdorojami žiniatinklio serverio.
Bendrieji principai
Daugelis scenarijaus konfigūravimo komandų yra įtrauktos į idempotencijos sąlygas: scenarijus gali būti paleistas kelis kartus, nerizikuojant pakeisti jau paruoštus parametrus.
Scenarijus bando įdiegti programinę įrangą iš saugyklų, kad galėtumėte pritaikyti sistemos naujinimus viena komanda (apt upgrade Ubuntu).
Komandos bando aptikti, kad jos veikia konteineryje, kad galėtų atitinkamai pakeisti nustatymus.
Siekdamas nustatymuose nustatyti paleidžiamų gijų procesų skaičių, scenarijus bando atspėti automatinius darbo konteineriuose, virtualiose mašinose ir aparatinės įrangos serveriuose nustatymus.
Apibūdindami nustatymus, visada pirmiausia galvojame apie automatizavimą, kuris, tikimės, taps pagrindu kuriant savo infrastruktūrą kaip kodą.
Visos komandos vykdomos iš vartotojo šaknis, nes jie keičia pagrindinius sistemos nustatymus, tačiau pati „WordPress“ veikia kaip įprastas vartotojas.
Aplinkos kintamųjų nustatymas
Prieš paleisdami scenarijų nustatykite šiuos aplinkos kintamuosius:
WORDPRESS_DB_PASSWORD - „WordPress“ duomenų bazės slaptažodis
WORDPRESS_ADMIN_USER - „WordPress“ administratoriaus vartotojo vardas
WORDPRESS_ADMIN_EMAIL – „WordPress“ administratoriaus el
WORDPRESS_URL – visas „WordPress“ svetainės URL, pradedant nuo https://.
LETS_ENCRYPT_STAGING — pagal numatytuosius nustatymus tuščias, tačiau nustačius reikšmę 1, naudosite Let's Encrypt sustojimo serverius, kurie yra būtini norint dažnai prašyti sertifikatų tikrinant nustatymus, kitu atveju Let's Encrypt dėl didelio užklausų skaičiaus gali laikinai užblokuoti jūsų IP adresą.
Scenarijus patikrina, ar šie su „WordPress“ susiję kintamieji nustatyti, ir išeina, jei ne.
Scenarijaus eilutės 572–576 patikrina reikšmę LETS_ENCRYPT_STAGING.
Išvestinių aplinkos kintamųjų nustatymas
55–61 eilutėse esantis scenarijus nustato šiuos aplinkos kintamuosius į tam tikrą užkoduotą reikšmę arba naudodamas vertę, gautą iš ankstesniame skyriuje nustatytų kintamųjų:
DEBIAN_FRONTEND="noninteractive" — nurodo programoms, kad jos veikia pagal scenarijų ir nėra galimybės vartotojui sąveikauti.
WORDPRESS_CLI_VERSION="2.4.0" — WordPress CLI programos versija.
WORDPRESS_CLI_MD5= "dedd5a662b80cda66e9e25d44c23b25c" — WordPress CLI 2.4.0 vykdomojo failo kontrolinė suma (versija nurodyta kintamajame WORDPRESS_CLI_VERSION). 162 eilutėje esantis scenarijus naudoja šią reikšmę, kad patikrintų, ar buvo atsisiųstas tinkamas WordPress CLI failas.
UPLOAD_MAX_FILESIZE="16M" – maksimalus failo dydis, kurį galima įkelti į „WordPress“. Šis nustatymas naudojamas keliose vietose, todėl lengviau jį nustatyti vienoje vietoje.
TLS_HOSTNAME= "$(echo ${WORDPRESS_URL} | cut -d'/' -f3)" – sistemos prieglobos pavadinimas, išgautas iš WORDPRESS_URL kintamojo. Naudojamas norint gauti atitinkamus TLS/SSL sertifikatus iš Let's Encrypt, taip pat vidiniam WordPress patikrinimui.
NGINX_CONF_DIR="/etc/nginx" — kelias į katalogą su NGINX nustatymais, įskaitant pagrindinį failą nginx.conf.
CERT_DIR="/etc/letsencrypt/live/${TLS_HOSTNAME}" — kelias į Let's Encrypt sertifikatus, skirtus „WordPress“ svetainei, gautus iš kintamojo TLS_HOSTNAME.
Prieglobos serverio pavadinimo priskyrimas „WordPress“ serveriui
Scenarijus nustato serverio pagrindinio kompiuterio pavadinimą taip, kad reikšmė atitiktų svetainės domeno pavadinimą. Tai nėra būtina, tačiau patogiau siųsti siunčiamus laiškus per SMTP, kai nustatomas vienas serveris, kaip sukonfigūruotas scenarijus.
scenarijaus kodas
# 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
Prieglobos pavadinimo pridėjimas prie /etc/hosts
Papildymas WP-Cron naudojamas periodinėms užduotims vykdyti, reikalauja, kad „WordPress“ galėtų pasiekti save per HTTP. Kad įsitikintumėte, jog WP-Cron tinkamai veikia visose aplinkose, scenarijus prie failo prideda eilutę / Etc / hostskad „WordPress“ galėtų pasiekti save per atgalinio ryšio sąsają:
scenarijaus kodas
# 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
Tolesniems veiksmams reikalingų įrankių įdiegimas
Likusiam scenarijui reikalingos kai kurios programos ir daroma prielaida, kad saugyklos yra atnaujintos. Atnaujiname saugyklų sąrašą ir įdiegiame reikiamus įrankius:
scenarijaus kodas
# 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 įrenginio ir NGINX saugyklų pridėjimas
Scenarijus įdiegia NGINX įrenginį ir atvirojo kodo NGINX iš oficialių NGINX saugyklų, kad būtų naudojamos versijos su naujausiais saugos naujinimais ir klaidų pataisymais.
Scenarijus prideda NGINX vieneto saugyklą, tada NGINX saugyklą, prideda saugyklų raktą ir nustatymų failus apt, apibrėžiantis prieigą prie saugyklų internetu.
Faktinis NGINX įrenginio ir NGINX įdiegimas vyksta kitame skyriuje. Iš anksto pridedame saugyklas, kad metaduomenys nebūtų atnaujinami kelis kartus, o diegimas būtų greitesnis.
scenarijaus kodas
# 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 vieneto, PHP MariaDB, Certbot (užšifruokime) ir jų priklausomybių diegimas
Pridėjus visas saugyklas, atnaujiname metaduomenis ir įdiegiame programas. Scenarijaus įdiegtuose paketuose taip pat yra PHP plėtinių, rekomenduojamų vykdant WordPress.org
scenarijaus kodas
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
PHP nustatymas naudoti su NGINX įrenginiu ir WordPress
Scenarijus sukuria nustatymų failą kataloge konf. d. Tai nustato maksimalų PHP failo įkėlimo dydį, leidžia PHP klaidas išvesti į STDERR, kad jos būtų užregistruotos NGINX bloke, ir iš naujo paleidžiamas NGINX įrenginys.
scenarijaus kodas
# 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“ duomenų bazės nustatymų nustatymas „WordPress“.
Mes pasirinkome MariaDB, o ne MySQL, nes ji turi daugiau bendruomenės veiklos ir gali pagal numatytuosius nustatymus užtikrina geresnį našumą (Ko gero, čia viskas paprasčiau: norint įdiegti MySQL, reikia pridėti dar vieną saugyklą, apytiksl. vertėjas).
Scenarijus sukuria naują duomenų bazę ir sukuria „WordPress“ prieigos kredencialus per kilpos sąsają:
scenarijaus kodas
# 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 programos diegimas
Šiame etape scenarijus įdiegia programą WP-CLI. Su juo galite įdiegti ir tvarkyti „WordPress“ nustatymus, nereikės rankiniu būdu redaguoti failų, atnaujinti duomenų bazę ar prisijungti prie valdymo skydelio. Jis taip pat gali būti naudojamas temoms ir priedams įdiegti bei „WordPress“ naujinimui.
scenarijaus kodas
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
„WordPress“ diegimas ir konfigūravimas
Scenarijus įdiegia naujausią „WordPress“ versiją į katalogą /var/www/wordpress, taip pat keičia nustatymus:
Duomenų bazės ryšys veikia per unix domeno lizdą, o ne TCP atgalinio ciklo metu, kad sumažintų TCP srautą.
„WordPress“ prideda priešdėlį https:// į URL, jei klientai prisijungia prie NGINX per HTTPS, taip pat siunčia nuotolinio kompiuterio pavadinimą (kaip pateikia NGINX) į PHP. Norėdami tai nustatyti, naudojame tam tikrą kodo dalį.
Norint prisijungti, „WordPress“ reikia HTTPS
URL struktūra tyliai pagrįsta ištekliais
„WordPress“ katalogui nustatyti teisingi failų sistemos leidimai.
scenarijaus kodas
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
NGINX įrenginio nustatymas
Scenarijus sukonfigūruoja NGINX įrenginį, kad jis paleistų PHP ir tvarkytų „WordPress“ kelius, išskirdamas PHP procesų vardų sritį ir optimizuodamas našumo nustatymus. Yra trys savybės, į kurias verta atkreipti dėmesį:
Vardų erdvės palaikymas nustatomas pagal sąlygą, pagrįstą patikrinimu, ar scenarijus veikia konteineryje. Tai būtina, nes dauguma sudėtinių rodinių sąrankų nepalaiko įdėto sudėtinių rodinių vykdymo.
Jei yra vardų erdvių palaikymas, vardų erdvė išjungta tinklas. Tai būtina, kad „WordPress“ vienu metu galėtų prisijungti prie galinių taškų ir būtų pasiekiama internete.
Didžiausias procesų skaičius nustatomas taip: (Pasiekiama atmintis MariaDB ir NGINX Uniy paleidimui)/(RAM limitas PHP + 5)
Ši vertė nustatoma NGINX įrenginio nustatymuose.
Ši reikšmė taip pat reiškia, kad visada veikia bent du PHP procesai, o tai svarbu, nes „WordPress“ pateikia daug asinchroninių užklausų sau, o be papildomų procesų, pavyzdžiui, WP-Cron suges. Galite padidinti arba sumažinti šias ribas atsižvelgdami į vietinius nustatymus, nes čia sukurti nustatymai yra konservatyvūs. Daugumoje gamybos sistemų nustatymai yra nuo 10 iki 100.
scenarijaus kodas
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
NGINX nustatymas
Pagrindinių NGINX nustatymų konfigūravimas
Scenarijus sukuria NGINX talpyklos katalogą ir sukuria pagrindinį konfigūracijos failą nginx.conf. Atkreipkite dėmesį į tvarkyklės procesų skaičių ir didžiausio atsisiuntimo failo dydžio nustatymą. Taip pat yra eilutė, prie kurios prijungiamas glaudinimo nustatymų failas, apibrėžtas kitame skyriuje, o po to - talpyklos nustatymai.
Turinio suspaudimas prieš siunčiant jį klientams yra puikus būdas pagerinti svetainės našumą, tačiau tik tada, jei glaudinimas sukonfigūruotas teisingai. Ši scenarijaus dalis yra pagrįsta nustatymais taigi.
scenarijaus kodas
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
NGINX nustatymas „WordPress“.
Tada scenarijus sukuria „WordPress“ konfigūracijos failą default.conf kataloge konf. d. Čia jis sukonfigūruotas:
TLS sertifikatų, gautų iš Let's Encrypt per Certbot, aktyvinimas (konfigūravimas bus pateiktas kitame skyriuje)
Konfigūruokite TLS saugos parametrus pagal Let's Encrypt rekomendacijas
Pagal numatytuosius nustatymus įgalinkite praleistų užklausų saugojimą talpykloje 1 valandą
Išjungti prieigos registravimą ir klaidų registravimą, jei failas nerastas, dviem dažniausiai prašomiems failams: favicon.ico ir robots.txt
Uždrausti prieigą prie paslėptų failų ir kai kurių failų . PHPkad būtų išvengta neteisėtos prieigos ar netyčinio paleidimo
Išjungti statinių ir šriftų failų prieigos registravimą
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
Certbot konfigūravimas Let's Encrypt sertifikatams ir automatinis jų atnaujinimas
Certbotas yra nemokamas „Electronic Frontier Foundation“ (EFF) įrankis, leidžiantis gauti ir automatiškai atnaujinti TLS sertifikatus iš „Let's Encrypt“. Scenarijus atlieka šiuos veiksmus, kad sukonfigūruotų Certbot apdoroti sertifikatus iš Let's Encrypt in NGINX:
Sustabdo NGINX
Atsisiunčia rekomenduojamus TLS nustatymus
Paleidžia Certbot, kad gautų svetainės sertifikatus
Iš naujo paleidžia NGINX, kad būtų naudojami sertifikatai
Konfigūruojamas „Certbot“, kad jis veiktų kasdien 3:24 val., kad patikrintų, ar nėra atnaujintų sertifikatų, ir, jei reikia, atsisiųstų naujų sertifikatų ir iš naujo paleistų NGINX.
scenarijaus kodas
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
Papildomas svetainės pritaikymas
Aukščiau kalbėjome apie tai, kaip mūsų scenarijus sukonfigūruoja NGINX ir NGINX įrenginį, kad būtų galima teikti gamybai paruoštą svetainę su įjungta TLSSSL. Taip pat, atsižvelgdami į savo poreikius, ateityje galėsite pridėti:
parama Brotli, patobulintas glaudinimas naudojant HTTPS
Postfix arba msmtp, kad „WordPress“ galėtų siųsti laiškus
Tikrinate savo svetainę, kad suprastumėte, kiek srauto ji gali apdoroti
Kad svetainė veiktų dar geriau, rekomenduojame naujovinti į NGINX Plus, mūsų verslo klasės komercinis produktas, pagrįstas atvirojo kodo NGINX. Jo abonentai gaus dinamiškai įkeliamą Brotli modulį, taip pat (už papildomą mokestį) NGINX ModSecurity WAF. Taip pat siūlome NGINX App Protect, WAF modulis, skirtas NGINX Plus, pagrįstas pramonėje pirmaujančia saugos technologija iš F5.
NB Jei norite palaikyti didelės apkrovos svetainę, galite susisiekti su specialistais Southbridge. Užtikrinsime greitą ir patikimą Jūsų svetainės ar paslaugos veikimą esant bet kokiai apkrovai.