WooCommerce (AlmaLinux 8) - Приложение - Delta.bg OpenStack Marketplace

Включен софтуер
Първоначално стартиране на услугата
Бързи настройкии и често задавани въпроси
1. Често задавани въпроси, свързани с Wordpress и WooCommerce
Допълнителни настройки при Docker
1. Wordpress + Woocommerce конфигурационни опции
SSL сертификати
Работа с Docker

Включен софтуер

Пакет	Версия
Wordpress + Woocommerce	latest
Docker	3.20.10
Docker compose	2.12.2
containerd.io	1.6.10

Първоначално стартиране на услугата

Това приложение използва Docker, за да осигури по-бързо стартиране на прилежащия софтуер (Wordpress + Woocommerce) и директно започване на употребата му. По този начин се елиминира нуждата от запознаване със спецификите му по отношение на конфигурация и инсталация. За да започнете директна работа с приложението, единственото, което трябва да направите е да посетите IP адреса, който е назначен за виртуалната Ви машина в бразура си, за да видите новата си WooCommerce инсталация.

Забележка: По подразбиране, Wordpress + Woocommerce може да се достъпи директно по IP адрес. За да започнете да използвате Wordpress + Woocommerce с реалния си домейн, първо трябва да насочите въпросния домейн към IP адреса си и да промените настройките за това от къде се отваря Wordpress + Woocommerce през неговия административен панел.

Бързи настройкии и често задавани въпроси

Входът в клауд услугата се извършва посредством SSH ключ или парола, която сте посочили.
Docker е инсталиран според препоръките от официалната docker документация.
Стандартните команди docker и docker compose са вече достъпни в това приложение.
При първо стартиране на виртуалната машина, отнема няколко минути, преди да се стартира Docker контейнер, съдържащ Wordpress + Woocommerce.
Wordpress + Woocommerce data е настроена да бъде persistent и се намира в /opt/wordpress/data/. MariaDB също е persistent и съхранява базите си данни в /opt/mariadb/data/.
Потребителят за достъп до Wordpress + Woocommerce административния панел е admin, а паролата е P@ssw0rd!.

Често задавани въпроси, свързани с Wordpress и WooCommerce

По подразбиране, полетата в административния панел на Wordpress - WordPress Address (URL) и Site Address (URL) са неактивни. Това е така, защото при първоначална инсталация тези опции са заложени в wp-config.php. Ако желаете да ги контролирате, то трябва да премахнете и закоментирате редовете define( 'WP_HOME', 'http://' . $_SERVER['HTTP_HOST'] . '/' ); и define( 'WP_SITEURL', 'http://' . $_SERVER['HTTP_HOST'] . '/' );.
По подразбиране, всяка WooCommerce инсталация идва със следните инсталирани плъгини, които не са активни и могат да се активират допълнително при ваше желание: "Akismet Anti-Spam", "All in One SEO", "All-in-One WP Migration", "AMP", "Google Analytics for WordPress by MonsterInsights", "Hello Dolly", "Jetpack", "TaxoPress", "W3 Total Cache" и "WP Mail SMTP".
Wordpress XML-RPC pingback функцията е забранена чрез филтър по подразбиране. XML-RPC се ползва за връзка на third-party програми към вашия Wordpress сайт. В много редки случай обаче, тази функция е нужна. Проблемът с нея е, че тя отваря Wordpress сайта ви към Brute Force и DoS атаки, което е нежелателно, поради което тя е забранена по подразбиране. Ако желаете да я включите, то отворете wp-config.php файла си с текстов редактор, намерете следните редове и ги премахнете или закоментирайте:

if ( !defined( 'WP_CLI' ) ) {
        // remove x-pingback HTTP header
        add_filter("wp_headers", function($headers) {
                unset($headers["X-Pingback"]);
                return $headers;
        });
        // disable pingbacks
        add_filter( "xmlrpc_methods", function( $methods ) {
                unset( $methods["pingback.ping"] );
                return $methods;
        });
}

Допълнителни настройки при Docker

Допълнителнителните настройки за Wordpress + Woocommerce, които можете да променяте и които се контролират директно от Docker са зададени като променливи стойности в конфигурационния файл /opt/docker-wordpress/docker-compose.yml:

Забележка: След промяна на която и да е от стойностите, трябва да пресъздадете Docker контейнера, върху който работи приложението. За повече информация, моля, прочетете секцията за пресъздаване на Docker контейнери.

Wordpress + Woocommerce конфигурационни опции

Генерални опции

АPACHE_HTTP_PORT_NUMBER: HTTP порт, използван от Apache. Default: 8080
APACHE_HTTPS_PORT_NUMBER: HTTPS порт, използван от Apache. Default: 8443
WORDPRESS_USERNAME: WordPress потребител за достъп. Default: admin
WORDPRESS_PASSWORD: WordPress парола за потребителя. Default: P@ssw0rd!
WORDPRESS_EMAIL: WordPress email. Default: user@example.com
WORDPRESS_FIRST_NAME: WordPress име на потребителя. Default: FirstName
WORDPRESS_LAST_NAME: WordPress фамилия на потребителя. Default: LastName
WORDPRESS_BLOG_NAME: WordPress blog име. Default: User's blog
WORDPRESS_HTACCESS_OVERRIDE_NONE: Оказва Apache директивата AllowOverride да бъде със стойност None. Всички директиви по подразбиране ще се зареждат от /opt/bitnami/wordpress/wordpress-htaccess.conf, който се намира вътре в docker контейнера. Default: yes
WORDPRESS_ENABLE_HTACCESS_PERSISTENCE: Запазване на всички промени, наложени в htaccess (запазване след рестартиране на docker контейнера). Настройката зависи от това дали WORDPRESS_HTACCESS_OVERRIDE_NONE е настроен. Ако е зададено да бъде yes, промените ще се запазват в /opt/bitnami/wordpress/wordpress-htaccess.conf, в противен случай ще се записват в /opt/bitnami/wordpress/.htaccess. Default: no
WORDPRESS_DATA_TO_PERSIST: Списък, разделен с празни места, които да се запазват в отделни директории извън docker контейнерите. Ако не желаете нищо да се намира извън docker контейнера, използвайте празно място - " ". Default: "wp-config.php wp-content"
WORDPRESS_RESET_DATA_PERMISSIONS: Форсиране (reset) на файлови пермисии на данни, които са запазени извън docker контейнера. Тези промени ще влезнат в сила след рестартиране на docker контейнера. Ако тази опция не е включена, се предполага, че текущите пермисии са коректни. Default: no
WORDPRESS_TABLE_PREFIX: Prefix на таблица в базата данни. Default: wp_
WORDPRESS_PLUGINS: Списък на Wordpress плъгини, които да се инсталират и активират автоматично. Списъкът е разделен със запетай. Ако се посочат вече инсталирани плъгини, то те ще бъдат и активирани при следващо рестартиране на docker контейнера. Default: none
WORDPRESS_EXTRA_INSTALL_ARGS: Допълнителни флагове, които се подават на командата wp core install при първо извикване. Без defaults.
WORDPRESS_EXTRA_CLI_ARGS: Допълнителни флагове към всички извиквания на командата WP-CLI. No defaults.
WORDPRESS_EXTRA_WP_CONFIG_CONTENT: Допълнителна конфигурация, който да бъде слепена към wp-config.php по време на инсталация. Без defaults.
WORDPRESS_ENABLE_HTTPS: Дали да се използва HTTPS връзка по подразбиране. Default: no
WORDPRESS_SKIP_BOOTSTRAP: Пропускане на Wordpress инсталационния помощник. Това е нужно, ако се използва вече съществуваща база данни. Default: no
WORDPRESS_AUTO_UPDATE_LEVEL: Ниво на автоматични ъпдейти, които да се включват към основната инсталация на Wordpress. Позволени стойности: major, minor, none. Default: none
WORDPRESS_ENABLE_REVERSE_PROXY: Включване на поддръжката на Wordpress за reverse proxy и добавяне на допълнителни хедъри. Default: no

Salt и keys конфигурационни опции

WORDPRESS_AUTH_KEY: Задай тази стойност на константата AUTH_KEY в wp-config.php
WORDPRESS_SECURE_AUTH_KEY: Задай тази стойност на константата SECURE_AUTH_KEY в wp-config.php
WORDPRESS_LOGGED_IN_KEY: Задай тази стойност на константата LOGGED_IN_KEY в wp-config.php
WORDPRESS_NONCE_KEY: Задай тази стойност на константата NONCE_KEY в wp-config.php
WORDPRESS_AUTH_SALT: Задай тази стойност на константата AUTH_SALT в wp-config.php
WORDPRESS_SECURE_AUTH_SALT: Задай тази стойност на константата SECURE_AUTH_SALT в wp-config.php
WORDPRESS_LOGGED_IN_SALT: Задай тази стойност на константата LOGGED_IN_SALT в wp-config.php
WORDPRESS_NONCE_SALT: Задай тази стойност на константата NONCE_SALT в wp-config.php

Multisite конфигурационни опции

WORDPRESS_ENABLE_MULTISITE: Включване на опцията за Wordpress Multisite. Default: no
WORDPRESS_MULTISITE_HOST: WordPress хостнейм/адрес. Използва се единствено при Multisite конфигурация. No defaults.
WORDPRESS_MULTISITE_EXTERNAL_HTTP_PORT_NUMBER: Порт, използван от Wordpress, за генериране на URL-и и линкове, когато се достъпва по HTTP. Тази настройка ще се игнорира, ако Multisite не е включен. Default 80
WORDPRESS_MULTISITE_EXTERNAL_HTTPS_PORT_NUMBER: Порт, използван от Wordpress, за генериране на URL-и и линкове, когато се достъпва по HTTPS. Тази настройка ще се игнорира, ако Multisite не е включен. Default 443
WORDPRESS_MULTISITE_NETWORK_TYPE: WordPress Multisite мрежови тип, който да бъде включен. Позволени стойности: subfolder, subdirectory, subdomain. Default: subdomain
WORDPRESS_MULTISITE_ENABLE_NIP_IO_REDIRECTION: Дали да се включи пренасочване от IP адрес към nip.io wildcard DNS, когато е включен Multisite. Тази опция е полезна, ако се работи върху IP адрес с поддомейн като мрежови тип. Default: no
WORDPRESS_MULTISITE_FILEUPLOAD_MAXK: Максимален размер на качвани сайтове през Wordpress Multisite инсталацията в килобайти. Default: 81920

Конфигурационни опции за връзка с база данни

WORDPRESS_DATABASE_HOST: Хостнейм за връзка с MariaDB или MySQL сървър. Default: mariadb
WORDPRESS_DATABASE_PORT_NUMBER: Порт за връзка с MariaDB или MySQL сървър. Default: 3306
WORDPRESS_DATABASE_NAME: Име на база данни, които WordPress ще използва за връзка с MariaDB или MySQL сървър. Default: wordpress
WORDPRESS_DATABASE_USER: Потребител, който WordPress ще използва за връзка с MariaDB или MySQL сървър. Default: wordpress
WORDPRESS_DATABASE_PASSWORD: Парола за база данни, които WordPress ще използва за връзка с MariaDB или MySQL сървър. No defaults.
WORDPRESS_ENABLE_DATABASE_SSL: Дали да се използва SSL за връзка с база данни. Default: no
WORDPRESS_VERIFY_DATABASE_SSL: Дали да се врифицира валидността на SSL сертификата Whether при връзка с база данни. Default: yes
WORDPRESS_DATABASE_SSL_CERT_FILE: Път към сертификационния файл. Без defaults
WORDPRESS_DATABASE_SSL_KEY_FILE: Път към ключа за сертификата. Без defaults
WORDPRESS_DATABASE_SSL_CA_FILE: Път към файла, съдържащ CA bundle/Intermediate chain-а. Без defaults
ALLOW_EMPTY_PASSWORD: Използва се за връзка към базата данни с празни пароли. Default: no

SMTP конфигурационни опции

WORDPRESS_SMTP_HOST: SMTP хост.
WORDPRESS_SMTP_PORT: SMTP порт.
WORDPRESS_SMTP_USER: SMTP потребител.
WORDPRESS_SMTP_PASSWORD: SMTP парола.

PHP конфигурационни опции

PHP_ENABLE_OPCACHE: Включване на OPcache за PHP. Default: yes
PHP_EXPOSE_PHP: Показване на HTTP header в PHP. Без default.
PHP_MAX_EXECUTION_TIME: Максимално време за изпълнение на PHP скриптовете. Без default.
PHP_MAX_INPUT_TIME: Maximum input време за PHP скриптовете. Без default.
PHP_MAX_INPUT_VARS: Максимален брой променливи PHP скриптовете. Без default.
PHP_MEMORY_LIMIT: Лимит на паметта за PHP скриптовете. Default: 512M
PHP_POST_MAX_SIZE: Максимален размер на PHP POST заявки. Без default.
PHP_UPLOAD_MAX_FILESIZE: Максимален обем за качване на файлове за PHP PHP скриптовете. Без default.

SSL сертификати

Използване на собствени (платени) SSL сертификати

Ако вече разполагате с готови, валидни сертификати, трябва да направите няколко модификации върху конфигурацията, преди да можете да ги използвате. За да постигнете това, моля следвайте следните стъпки:

Стъпка 1 - поставяне на сертификатите

Създайте директория, където сертификатите ще се съхраняват:

mkdir /opt/certs/

Копирайте сертификатите в директорията, която създадохте току-що и модифицирайте техните права:

chown 1001:1001 /opt/certs/ -R

Стъпка 2 - модифицирайте Docker конфигурацията

Отворете docker конфигурационния файл /opt/docker-wordpress/docker-compose.yml с текстов редактор и намерете следния фрагмент:

  wordpress:
    image: docker.io/bitnami/wordpress:6
    ports:
      - '80:8080'
      - '443:8443'
    volumes:
      - '/opt/wordpress/data:/bitnami/wordpress'

Редактирайте го, така че да изглежда по следния начин:

  wordpress:
    image: docker.io/bitnami/wordpress:6
    ports:
      - '80:8080'
      - '443:8443'
    volumes:
      - '/opt/wordpress/data:/bitnami/wordpress'
      - '/opt/certs/cert.pem:/opt/bitnami/apache/conf/bitnami/certs/server.crt'
      - '/opt/certs/privkey.pem:/opt/bitnami/apache/conf/bitnami/certs/server.key'

Обърнете внимание, че /opt/certs/cert.pem е пътя до сертификата, а /opt/certs/privkey.pem е пътя до частния ключ. Можете да именувате файловете и директоряита както пожелаете, но трябва да са посочени правилно в конфигурацията

Стъпа 3 - рестартирайте Docker контейнерите

cd /opt/docker-wordpress/
docker compose up -d

Издаване на сертификати с Letsencrypt

Ако желаете, винаги можете да издадете и безплатни сертификати от Letsencrypt. За целта, моля следвайте следните стъпки:

Стъпка 1 - инсталиране на нужните пакети

Влезте в сървъра си, като добиете root права и изпълнете следните команди:

dnf install -y epel-release
dnf install -y certbot

Стъпка 2 - издаване на сертификата

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

За целта, спрете временно контейнера с командата docker stop docker-wordpress-wordpress-1. Важно: Изпълнявайки тази стъпка, сайтът ви ще спре да работи временно. Уверете се, че искате да изпълните това действие във време, когато най-малко ще афектира потребителите ви.

Издайте сертификата с командата certbot certonly --standalone --preferred-challenges http -d example.com, като замените "example.com" с домейна, който сте насочили към IP адреса на Cloud сървъра си.

Стъпка 3 - поставете новите сертификати в конфигурацията

Отворете docker конфигурационния файл /opt/docker-wordpress/docker-compose.yml с текстов редактор и намерете следния фрагмент:

  wordpress:
    image: docker.io/bitnami/wordpress:6
    ports:
      - '80:8080'
      - '443:8443'
    volumes:
      - '/opt/wordpress/data/:/bitnami/wordpress'

Редактирайте го, така че да изглежда по следния начин:

  wordpress:
    image: docker.io/bitnami/wordpress:6
    ports:
      - '80:8080'
      - '443:8443'
    volumes:
      - '/opt/wordpress/data/:/bitnami/wordpress'
      - '/etc/letsencrypt/live/example.com/cert.pem:/opt/bitnami/apache/conf/bitnami/certs/server.crt'
      - '/etc/letsencrypt/live/example.com/privkey.pem:/opt/bitnami/apache/conf/bitnami/certs/server.key'

С тази модификация оказвате, че "свързвате" външните сертификати, издадени от Letsencrypt с конфигурацията, която се намира вътре в docker контейнера. Заменете "example.com" с името на домейна си. След като подмените конфигурацията, е нужно да поправите правата на сертификатите с командата chown 1001:1001 /etc/letsencrypt/archive/example.com/ -R, като отново замените "example.com" с името на домейна си.

Стъпка 4 - стартиране на услугите

Тъй като временно е спрян docker контейнера, то трябва да се приложи новата конфигурация и да го стартираме. Моля изпълнете следните команди:

cd /opt/docker-wordpress/
docker compose up -d

Стъпка 5 (опционално) - автоматично подновяване на сертификата

Автоматичното подновяване може да бъде организирано чрез cron. Можете да зададете следната cron конфигурация, за да се случи автматичното подновяване:

# Automated Letsencrypt renewal
0 0 * * * /usr/bin/certbot renew --pre-hook 'docker stop docker-wordpress-wordpress-1' --post-hook 'chown 1001:1001 /etc/letsencrypt/archive/example.com/ -R; docker start docker-wordpress-wordpress-1'

Разбира се, можете да промените времето на изпълнение, когато пожелаете. В горният пример, тази задача ще се изпълнява всеки ден в 00:00 часа.

Работа с Docker

Организацията на това приложение е осъществена изцяло посредством Docker. По този начин можем да Ви предоставим готови приложения по-бързо. Освен това, конфигурацията им е по-гъвкава и е доста контролируема. За да можете да го контролирате това приложение обаче, е нужно да знаете някой базови Docker функционалности и особености.

Рестартиране на всички услуги

Рестартирането на базата данни и Docker контейнера, който съдържа самия Wordpress, заедно с останалия софтуер, може да бъде извършено по два начина:

Чрез рестартиране на цялата виртуална машина
Рестартиране на Docker контейнерите, което е по-бързия вариант. За целта, достъпете машината си чрез SSH, и изпълнете следните команди:

sudo su -
cd /opt/docker-wordpress
docker compose restart

Пресъздаване на Docker контейнери

Пресъздаването може да се наложи, в случай че сме променяли конфигурацията в docker-compose.yml. При тази ситуация, трябва да следвате следните стъпки:

cd /opt/docker-wordpress
docker compose stop
docker compose up -d

Проверка на статуса на Docker приложението

За да направите проверка, трябва да изпълните следните команди:

sudo su -
docker ps -a

Моля, обърнете внимание на колоната STATUS. Тя трябва да показва от колко време работи услугата, например Up X minutes. Ако статуса е Restarting, то трябва да се провери какво не е наред с приложението. В такъв случай, можете да направите проверка, като проследите логовете на приложението по следния начин:

Вземете името на приложението, което можете да видите в колоната NAMES от изходния код на командата docker ps -a. Вижте логовете с командата docker logs <NAME>, Където е името на контейнера.

Промяна на настройки

Описаните настройки в секцията Допълнителни настройки при Docker могат да бъдат нагласяни в docker-compose.yml файла. Пътят до него е описан отново в тази секция. За да промените настройка, отворете конфигурационния файл и обърнете внимание на секцията environment, намираща се под wordpress. Всяка една конфигурационна опция трябва да бъде описана на нов ред с тире отпред по следния примерен начин:

    environment:
      - ALLOW_EMPTY_PASSWORD=yes
      - WORDPRESS_DATABASE_HOST=mariadb
      - WORDPRESS_DATABASE_PORT_NUMBER=3306
      - WORDPRESS_DATABASE_USER=wordpress
      - WORDPRESS_DATABASE_NAME=wordpress
      - WORDPRESS_USERNAME=admin
      - WORDPRESS_PASSWORD=P@ssw0rd!
      - WORDPRESS_EMAIL=admin@example.com
      - WORDPRESS_PLUGINS=woocommerce

Моля, обърнете внимание, че трябва да се спазва и правилната индентация (брой празно място), тъй като това е важно за конфигурационни файлове от тип yaml.