🥇Ավտոմատացրեք WordPress-ի տեղադրումը NGINX Unit-ով և Ubuntu

WordPress-ը տեղադրելու վերաբերյալ բազմաթիվ ձեռնարկներ կան, Google-ում «WordPress install» որոնումը ցույց կտա մոտ կես միլիոն արդյունք: Այնուամենայնիվ, իրականում նրանց մեջ շատ քիչ լավ ուղեցույցներ կան, որոնց համաձայն դուք կարող եք տեղադրել և կարգավորել WordPress-ը և դրա հիմքում ընկած օպերացիոն համակարգը, որպեսզի նրանք կարողանան երկար ժամանակ աջակցել: Միգուցե ճիշտ կարգավորումները մեծապես կախված են կոնկրետ կարիքներից, կամ դա պայմանավորված է նրանով, որ մանրամասն բացատրությունը դժվարացնում է հոդվածը կարդալը:

Այս հոդվածում մենք կփորձենք համատեղել երկու աշխարհներից լավագույնը՝ տրամադրելով bash script՝ WordPress-ը Ubuntu-ում ավտոմատ տեղադրելու համար, ինչպես նաև քայլել դրա միջով՝ բացատրելով, թե ինչ է անում յուրաքանչյուր կտոր, ինչպես նաև այն փոխզիջումները, որոնք մենք արել ենք այն մշակելիս։ . Եթե դուք առաջադեմ օգտվող եք, կարող եք բաց թողնել հոդվածի տեքստը և պարզապես վերցրեք սցենարը ձեր միջավայրում փոփոխության և օգտագործման համար: Սկրիպտի արդյունքը WordPress-ի անհատական տեղադրում է Lets Encrypt-ի աջակցությամբ, որն աշխատում է NGINX Unit-ով և հարմար է արտադրական օգտագործման համար:

NGINX Unit-ի միջոցով WordPress-ի տեղակայման մշակված ճարտարապետությունը նկարագրված է ավելի հին հոդված, այժմ մենք նաև կկազմաձևենք այն բաները, որոնք այնտեղ չեն լուսաբանվել (ինչպես շատ այլ ձեռնարկներում).

WordPress CLI
Եկեք ծածկագրենք և TLSSSL վկայագրերը
Վկայականների ավտոմատ թարմացում
NGINX քեշավորում
NGINX սեղմում
HTTPS և HTTP/2 աջակցություն
Գործընթացների ավտոմատացում

Հոդվածում նկարագրվելու է տեղադրումը մեկ սերվերի վրա, որը միաժամանակ կհյուրընկալի ստատիկ մշակման սերվեր, PHP պրոցեսոր սերվեր և տվյալների բազա։ Տեղադրումը, որն աջակցում է բազմաթիվ վիրտուալ հյուրընկալողներին և ծառայություններին, ապագայի պոտենցիալ թեմա է: Եթե ցանկանում եք, որ մենք գրենք մի բանի մասին, որը չկա այս հոդվածներում, գրեք մեկնաբանություններում։

Պահանջներ

Կոնտեյներային սերվեր (LXC կամ LXD), վիրտուալ մեքենա կամ սովորական երկաթյա սերվեր, որն ունի առնվազն 512 ՄԲ RAM և տեղադրված է Ubuntu 18.04 կամ ավելի նոր տարբերակը:
Ինտերնետ հասանելի պորտեր 80 և 443
Այս սերվերի հանրային ip հասցեի հետ կապված տիրույթի անուն
Արմատային մուտք (sudo):

Ճարտարապետության ակնարկ

Ճարտարապետությունը նույնն է, ինչ նկարագրված է նախկինում, եռաստիճան վեբ հավելված։ Այն բաղկացած է PHP սկրիպտներից, որոնք աշխատում են PHP շարժիչի վրա և ստատիկ ֆայլերից, որոնք մշակվում են վեբ սերվերի կողմից:

Ընդհանուր սկզբունքներ

Բազմաթիվ կազմաձևման հրամաններ սկրիպտում փաթաթված են, եթե անզորության պայմանները լինեն. սկրիպտը կարող է մի քանի անգամ գործարկվել՝ առանց արդեն տեղադրված պարամետրերը փոխելու ռիսկի:
Սցենարը փորձում է ծրագրակազմ տեղադրել պահեստներից, այնպես որ կարող եք կիրառել համակարգի թարմացումները մեկ հրամանով (apt upgrade Ubuntu-ի համար):
Հրամանները փորձում են հայտնաբերել, որ դրանք աշխատում են կոնտեյներով, որպեսզի կարողանան համապատասխանաբար փոխել իրենց կարգավորումները:
Պարամետրերում սկսելու շղթայի գործընթացների քանակը սահմանելու համար սկրիպտը փորձում է գուշակել կոնտեյներներում, վիրտուալ մեքենաներում և ապարատային սերվերներում աշխատելու ավտոմատ կարգավորումները:
Պարամետրերը նկարագրելիս մենք միշտ առաջին հերթին մտածում ենք ավտոմատացման մասին, որը, հուսով ենք, հիմք կդառնա սեփական ենթակառուցվածքը որպես կոդ ստեղծելու համար։
Բոլոր հրամանները գործարկվում են որպես օգտվող արմատ, քանի որ դրանք փոխում են համակարգի հիմնական կարգավորումները, բայց ուղղակիորեն WordPress-ն աշխատում է որպես սովորական օգտվող։

Շրջակա միջավայրի փոփոխականների կարգավորում

Նախքան սկրիպտը գործարկելը սահմանեք հետևյալ միջավայրի փոփոխականները.

WORDPRESS_DB_PASSWORD - WordPress տվյալների բազայի գաղտնաբառը
WORDPRESS_ADMIN_USER - WordPress-ի ադմինիստրատորի անունը
WORDPRESS_ADMIN_PASSWORD - WordPress-ի ադմինիստրատորի գաղտնաբառը
WORDPRESS_ADMIN_EMAIL - WordPress-ի ադմինիստրատորի էլ
WORDPRESS_URL WordPress կայքի ամբողջական URL-ն է՝ սկսած https://.
LETS_ENCRYPT_STAGING - լռելյայն դատարկ է, բայց արժեքը 1-ին դնելով, դուք կօգտագործեք 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)" - համակարգի հոսթի անունը՝ վերցված WORDPRESS_URL փոփոխականից: Օգտագործվում է Let's Encrypt-ից համապատասխան TLS/SSL վկայագրեր ստանալու համար, ինչպես նաև WordPress-ի ներքին հաստատում:
NGINX_CONF_DIR="/etc/nginx" - ուղին դեպի գրացուցակ NGINX կարգավորումներով, ներառյալ հիմնական ֆայլը nginx.conf.
CERT_DIR="/etc/letsencrypt/live/${TLS_HOSTNAME}" — ուղին դեպի Let's Encrypt վկայականներ WordPress կայքի համար, որը ստացվել է փոփոխականից TLS_HOSTNAME.

WordPress սերվերին հյուրընկալող անուն նշանակելը

Սցենարը սահմանում է սերվերի հոսթի անունը, որպեսզի համապատասխանի կայքի տիրույթի անվանմանը: Սա պարտադիր չէ, բայց ավելի հարմար է ելքային փոստ ուղարկել 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

Հոսթի անունը ավելացնելով /etc/hosts-ին

Լրացում WP-Cron օգտագործվում է պարբերական առաջադրանքներ կատարելու համար, պահանջում է, որ WordPress-ը կարողանա մուտք գործել ինքն իրեն HTTP-ի միջոցով: Համոզվելու համար, որ WP-Cron-ը ճիշտ է աշխատում բոլոր միջավայրերում, սկրիպտը տող է ավելացնում ֆայլին Միասին etc / գլխավոր հանգույցինորպեսզի 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 միավորի և 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 " 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-ի կարգավորում NGINX Unit-ի և WordPress-ի հետ օգտագործելու համար

Սցենարը գրացուցակում ստեղծում է կարգավորումների ֆայլ conf.d. Սա սահմանում է PHP-ի վերբեռնումների առավելագույն չափը, միացնում է PHP-ի սխալի ելքը STDERR-ին, որպեսզի դրանք գրվեն NGINX միավորի մատյանում և վերագործարկվի NGINX միավորը:

սցենարի կոդը

# 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

WordPress-ի համար MariaDB տվյալների բազայի կարգավորումների կարգավորում

Մենք ընտրել ենք 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
  # 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-ի տեղադրում և կարգավորում

Սցենարը տեղադրում է WordPress-ի վերջին տարբերակը գրացուցակում /var/www/wordpressև նաև փոխում է կարգավորումները.

Տվյալների բազայի միացումն աշխատում է unix տիրույթի վարդակից, այլ ոչ թե TCP-ի հանգույցի վրա, որպեսզի կրճատի TCP տրաֆիկը:
WordPress-ն ավելացնում է նախածանց https:// URL-ին, եթե հաճախորդները միանում են NGINX-ին HTTPS-ի միջոցով, ինչպես նաև ուղարկում է հեռավոր հոսթի անունը (ինչպես տրամադրվում է NGINX-ի կողմից) PHP-ին: Սա կարգավորելու համար մենք օգտագործում ենք կոդի մի կտոր:
Մուտք գործելու համար WordPress-ին անհրաժեշտ է HTTPS
URL-ի կանխադրված կառուցվածքը հիմնված է ռեսուրսների վրա
Սահմանում է ճիշտ թույլտվությունները ֆայլային համակարգի վրա WordPress գրացուցակի համար:

սցենարի կոդը

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 միավորի կարգավորում

Սցենարը կարգավորում է NGINX Unit-ը, որպեսզի գործարկի PHP-ն և մշակի WordPress-ի ուղիները՝ մեկուսացնելով PHP գործընթացի անվանատարածքը և օպտիմալացնելով կատարողականի կարգավորումները: Այստեղ պետք է ուշադրություն դարձնել երեք առանձնահատկություններին.

Անվանատարածքների աջակցությունը որոշվում է պայմանով՝ ստուգելով, որ սկրիպտը աշխատում է կոնտեյներով: Սա անհրաժեշտ է, քանի որ բեռնարկղերի կարգավորումների մեծ մասը չի աջակցում բեռնարկղերի տեղադրման մեջ:
Եթե անունների տարածքների աջակցություն կա, ապա անջատեք անվանատարածքը ցանց. Սա թույլ է տալիս WordPress-ին միանալ երկու վերջնակետերին և միաժամանակ հասանելի լինել համացանցում:
Գործընթացների առավելագույն քանակը սահմանվում է հետևյալ կերպ. (Հասանելի հիշողություն MariaDB-ի և NGINX Uniy-ի գործարկման համար)/(RAM-ի սահմանաչափը 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 " 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-ի կարգավորում

Հիմնական 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'
# 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

WordPress-ի համար NGINX-ի կարգավորում

Հաջորդը, սցենարը ստեղծում է WordPress-ի համար կազմաձևման ֆայլ default.conf կատալոգում conf.d. Այն կազմաձևված է այստեղ՝

Let's Encrypt-ից ստացված TLS վկայականների ակտիվացում 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 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-ի կարգավորում 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 " 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

Ձեր կայքի լրացուցիչ հարմարեցում

Մենք վերևում խոսեցինք այն մասին, թե ինչպես է մեր սկրիպտը կարգավորում NGINX-ը և NGINX Unit-ը, որպեսզի սպասարկեն արտադրության համար պատրաստ կայք՝ միացված TLSSSL-ով: Կարող եք նաև, կախված ձեր կարիքներից, ապագայում ավելացնել.

աջակցություն Բրոտլի, բարելավվել է արագ սեղմումը HTTPS-ի միջոցով
Mod Security с wordpress-ի կանոններըձեր կայքի վրա ավտոմատ հարձակումները կանխելու համար
պահուստ WordPress-ի համար, որը համապատասխանում է ձեզ
Պաշտպանություն միջոցով AppArmor (Ubuntu-ում)
Postfix կամ msmtp, որպեսզի WordPress-ը կարողանա նամակ ուղարկել
Ստուգում է ձեր կայքը, որպեսզի հասկանաք, թե որքան տրաֆիկ կարող է այն կարգավորել

Կայքի էլ ավելի լավ աշխատանքի համար խորհուրդ ենք տալիս թարմացնել NGINX Plus, մեր առևտրային, ձեռնարկության մակարդակի արտադրանքը, որը հիմնված է բաց կոդով NGINX-ի վրա: Նրա բաժանորդները կստանան դինամիկ բեռնված Brotli մոդուլ, ինչպես նաև (լրացուցիչ վճարով) NGINX ModSecurity WAF. Մենք նաև առաջարկում ենք NGINX հավելվածի պաշտպանություն, WAF մոդուլ NGINX Plus-ի համար՝ հիմնված F5-ից արդյունաբերության առաջատար անվտանգության տեխնոլոգիայի վրա:

NB Բարձր բեռնված կայքի աջակցության համար կարող եք կապվել փորձագետների հետ Սաութբրիջ. Մենք կապահովենք ձեր կայքի կամ ծառայության արագ և հուսալի շահագործումը ցանկացած ծանրաբեռնվածության պայմաններում:

Source: www.habr.com

WordPress-ի տեղադրման ավտոմատացում NGINX Unit-ի և Ubuntu-ի հետ

Պահանջներ

Ճարտարապետության ակնարկ

Ընդհանուր սկզբունքներ

Շրջակա միջավայրի փոփոխականների կարգավորում

Ստացված միջավայրի փոփոխականների կարգավորում

WordPress սերվերին հյուրընկալող անուն նշանակելը

Հոսթի անունը ավելացնելով /etc/hosts-ին

Հաջորդ քայլերի համար անհրաժեշտ գործիքների տեղադրում

NGINX միավորի և NGINX պահեստների ավելացում

NGINX, NGINX Unit, PHP MariaDB, Certbot (Let's Encrypt) և դրանց կախվածությունների տեղադրում

PHP-ի կարգավորում NGINX Unit-ի և WordPress-ի հետ օգտագործելու համար

WordPress-ի համար MariaDB տվյալների բազայի կարգավորումների կարգավորում

WordPress CLI ծրագրի տեղադրում

WordPress-ի տեղադրում և կարգավորում

NGINX միավորի կարգավորում

NGINX-ի կարգավորում

Հիմնական NGINX կարգավորումների կարգավորում

NGINX սեղմման կարգավորում

WordPress-ի համար NGINX-ի կարգավորում

Certbot-ի կարգավորում Let's Encrypt-ի վկայագրերի համար և դրանց ավտոմատ թարմացում

Ձեր կայքի լրացուցիչ հարմարեցում