WordPress в докере

https://youtube.com/watch?v=TVokbdPtoS8%3Ffeature%3Doembed

Overview

Running WordPress sites within a Docker container has grown in popularity since the inception of Docker. Doing so has many obvious benefits, especially for those developing themes and plugins. And while containerizing a WordPress site is not a stren u
ous activity, building and running a container in production requires a number of considerations.

In this tutorial you will be progressively guided through each step for running a container in productions, from building the initial image to running it securely and reliabily in production.

Некоторое время назад я писал статью про быстрое разворачивание окружения под WordPress
, а так же саму установку CMS. В ней был акцент на разработку, поэтому не было простого способа запустить сайт сразу на https. Я решил пойти дальше и полностью автоматизировать установку wordpress в docker с https, чтобы можно было сразу развернуть на vps и показать в рабочем варианте. Пришлось немного доработать предыдущий вариант, добавив туда контейнер с nginx и let’s encrypt.

Онлайн-курс по Kubernetes
– для разработчиков, администраторов, технических лидеров, которые хотят изучить современную платформу для микросервисов Kubernetes. Самый полный русскоязычный курс по очень востребованным и хорошо оплачиваемым навыкам. Курс не для новичков – нужно пройти вступительный тест
.

Вот так современные технологии упрощают и ускоряют разработку и обслуживание. Сравните с тем, что надо сделать, чтобы настроить типовой веб сервер вручную — настройка веб сервера apache
. А тут раз, два и все готово. И потом переносится на любую ОС с докером за минуту. Другое дело, что чтобы во всем этом разбираться, надо сначала научиться вручную все это настраивать, а потом переходить к контейнерам. Иначе они будут как черный ящик. Когда что-то сломается, останется только потыкать в него, но это не приведет к решению проблемы.

Другой вариант решения вопроса — автоматизировать все это с помощью ansible. Я пробовал что-то делать в этом направлении, но реально написать хороший плейбук занимает много времени. Если работаешь не на однотипном потоке, это не оправдывает затраты времени. С докером быстрее и проще получается.

# Что такое Docker Compose

Docker Compose это — удобный и функциональный инструмент, входящий в состав Docker. Его используют, чтобы развернуть целый проект, а не отдельно взятое приложение. Например, если необходимо создать сайт, который будет использовать базу данных для аутентификации пользователей.

Docker Compose позволяет создавать несколько контейнеров, связанных в одну внутреннюю сеть, и управлять ими как единым целым. А все параметры развёртывания уже готовой внутренней сети и контейнеры с необходимыми образами указываются в одном файле.

В этой инструкции мы воспользуемся Docker Compose для запуска сайта на CMS WordPress: запустим Nginx, MySQL и WordPress в отдельных контейнерах, объединим их в единую внутреннюю сеть и проверим работоспособность нашего проекта.

Для начала работы нам потребуется настроенный сервер с Ubuntu, предустановленные Docker и Docker Compose, а также зарегистрированный домен, к которому мы привяжем наш сайт.

WordPress — одна из самых популярных CMS в мире. Порядка 40% всех сайтов в сети используют WordPress.

И это легко объяснить: WordPress лёгок и прост в обращении, для него выпущено множество плагинов и визуальных тем, для работы с ним не нужны глубокие знания о работе в сети. WordPress одинаково успешно справляется как с созданием небольших локальных блогов, так и с большими новостными сайтами.

Единственной проблемой WordPress можно назвать установку. Для полноценной установки WordPress на сервер требуется установка программного стека LAMP или LEMP (Nginx в качестве веб-сервера), а это может занять определённое время. Именно поэтому некоторые хостинговые компании предлагают готовые решения в виде серверов с предустановленными популярными CMS (opens new window)


.

Для того, чтобы ускорить и упростить процесс самостоятельной установки WordPress на сервер, мы предлагаем инструкцию по запуску WordPress с помощью Docker Compose.

Ни один из моих блогов на WordPress не установлен в  Docker контейнерах
, и об этом я жалею с самого момента их создания. Мне хватило всего пары недель, чтобы забыть, как именно настроены сервера, зачем на них включена та или иная фича, и теперь во время каждого апдэйда приходится молиться всем известным богам программирования, потому что если что-то пойдёт не так, я уже без понятия, как это разруливать. Даже просто перенести сайт на новый сервер было бы подвигом.

С Докер контейнерами таких проблем бы не было. Взял Dockerfile или docker-compose.yml, взял volumes с данными, перенёс на другую машину, и всё. Можно было бы даже запустить реплики блогов дома, чтобы на них экспериментировать, проверять апдэйты и надругивать новые фичи.

Но не всё потеряно. Прогрессирующее старпёрство мне уже не позволит просто так вот взять и выкатить Docker в свой «продакшен», но создать локальную докеризированную реплику одного из блогов определённо можно. А там, если всё пойдёт нормально, можно и в большой интернет.

Сразу скажу, что мной двигала лень самостоятельной настройки всего этого хозяйства. В связи с этим я искал готовые контейнеры, которым можно было бы доверять и не заботиться об их обновлении и поддержке. На долю секунды у меня возникла мысль собрать контейнеры самостоятельно, но я ее быстро отбросил 🙂 Тогда мне было бы проще и быстрее настраивать все без докера банальным башем или ансиблом.

Для самого web сервера под wordpress нет проблем, так как docker контейнер
предоставляет сама wordpress. А вот с let’s encrypt возникли некоторые затруднения. Чего-то простого и легковесного не попадалось. В итоге остановился вот на этом проекте — https://docs.linuxserver.io/general/swag
. Это многофункциональный web сервер, который больше заточен на проксирование запросов. Я сначала хотел использовать только его в том числе и в качестве веб сервера, но в итоге решил все же остаться на стандартном контейнере от wordpress.

Проект linuxserver достаточно известный. У них много готовых контейнеров на все случаи жизни, так что решил остановиться на нем. Немного поковырялся внутри, посмотрел, как все устроено. Когда разобрался, начал реализацию изначальной идеи — автоматизировать установку wordpress через docker сразу по https с бесплатными сертификатами от let’s encrypt. Запускать все буду через docker-compose. Если у вас еще не установлен докер и композ к нему, используйте мою статью — установка docker на centos
.

  wp-content 

  container  

  ID /usr/bin/mysqldump root mydb backup.sql 

В начале подготовим конфиг nginx для проксирования запросов
из контейнера с swag в wordpress. Назовем его , так как он будет заменять дефолтный конфиг nginx.

 server {	listen 80;	listen [::]:80;	server_name  253197.simplecloud.ru 
;	return 301 https://$host$request_uri;
}
server {	listen 443 ssl http2 default_server;	listen [::]:443 ssl http2 default_server;	root /var/www/html/example;	index index.html index.htm index.php;	server_name  253197.simplecloud.ru 
;	include /config/nginx/proxy-confs/*.subfolder.conf;	include /config/nginx/ssl.conf;	client_max_body_size 64M;	location / {	try_files $uri $uri/ /index.php?$args @app;	}	location @app {	proxy_pass http://wordpress;	proxy_set_header Host $host;	proxy_redirect off;	proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;	proxy_set_header X-Forwarded-Proto https;	proxy_set_header X-Real-IP $remote_addr;	}
} 

Вам нужно будет в нем заменить только имя сервера — 253197.simplecloud.ru
. Это dns запись vds на simplecloud
, которые я обычно использую для теста. Мало того, что есть возможность почасовой аренды, так сразу же с виртуалкой идет прописанное dns имя. В итоге такие vds очень удобно использовать для тестов и временного размещения чего-либо. Рекомендую.

Далее я подготовил конфиг для установки и первоначальной настройки wordpress с помощью инструмента wp-cli
, который запускается в отдельном контейнере. После того, как он все выполнит, завершает свою работу.

 retries=0
while :
do if wp core install --url="  253197.simplecloud.ru 
" --title="test blog" --admin_user="admin" --admin_password="pass" --admin_email="admin@sample.com" then break else retries=$((retries+1)) echo "Couldn't connect to DB. Try - ${retries}. Sleeping 5 seconds and will retry ." sleep 5 fi if [ "${retries}" -eq "30" ] then echo "Couldn't connect to DB 30 times. Exiting." exit 1 fi
done
wp theme install donovan --activate
wp theme uninstall twentynineteen
wp theme uninstall twentyseventeen
wp theme uninstall twentytwenty
wp plugin install wordpress-importer --activate
#wp plugin install classic-editor --activate
#wp plugin install wp-mail-smtp --activate
#wp plugin install cyr3lat --activate
#wp plugin install wordpress-seo --activate
wp plugin uninstall akismet
wp plugin uninstall hello
wp language core install ru_RU --activate 

Здесь надо не забыть поменять имя сайта, а так же указать учетную запись для администратора, его email.

Так же я отдельно подготовил файл с конфигурацией веб сервера apache, который используется в контейнере wordpress.

 # BEGIN WordPress
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress
php_value memory_limit 256M
php_value upload_max_filesize 64M
php_value post_max_size 64M
php_value max_execution_time 300
php_value max_input_time 1000 

Подготовка окончена, можно переходить к непосредственно установке wordpress через docker.

Getting Started

Running WordPress Containers

WordPress publishes an official Docker image to Dockerhub. It is a bare bones, light weight container running on Alpine Linux. Перетащите образ в локальный репозиторий.

“`
docker pull wordpress
«`

Обратите внимание, что в нашей команде pull не указана версия выпуска. Действие по умолчанию, выполняемое docker pull, когда тег выпуска не указан, — это вытащить последний образ (или :latest>). Чтобы вытащить определенную версию WordPress, добавьте тег версии к команде docker pull.

“`
докер тянуть вордпресс: 5.2
«`

Давайте запустим базовое изображение, чтобы показать контейнер в действии. Мы будем использовать флаг -p, чтобы открыть контейнер на порту 80, и использовать флаг -d, чтобы демонизировать контейнер для работы в фоновом режиме.

“`
docker run -d -p 80:80 wordpress
«`

Для типичной установки WordPress одним из первых действий, которое вы предпримете, будет настройка вашей базы данных. Базовый образ принимает ряд переменных среды, используемых для настройки WordPress. Основные переменные, которые необходимо знать, предназначены для настройки конечной точки базы данных.

 docker run -d -p 80:80 -e WORDPRESS_DB_HOST=localhost,WORDPRESS_DB_USER=user1,WORDPRESS_DB_PASSWORD=пароль,WORDPRESS_DB_NAME=wpsite1 wordpress 

 WORDPRESS_DB_HOST=
WORDPRESS_DB_USER=.
WORDPRESS_DB_PASSWORD=
WORDPRESS_DB_NAME=
WORDPRESS_TABLE_PREF=wp_ 

Чтобы использовать файл переменных среды при запуске контейнера WordPress, мы используем флаг –env-file. Запустите базовый образ и укажите в файле –env файл wp_vars.

 docker run -d -p 80:80 --env-file wp_vars wordpress 

Вы успешно использовали базовый образ для запуска WordPress в качестве контейнера Docker. Обязательные сайты не используют стандартную установку WordPress, поэтому в следующем разделе мы рассмотрим настройку изображения для сайта.

Настройка образа WordPress

Dockerfile — это файл, используемый Docker для шаблона сборки нового образа Docker. Большинство образов строятся поверх существующих образов для расширения их конфигураций. Мы сделаем то же самое, создав новый образ для блога WordPress поверх официального образа докера WordPress.

Создайте рабочую область в своей файловой системе для хранения вашего проекта докера WordPress.

 mkdir -p ~/workspace/wordpress 

 ИЗ WordPress
ENV WORDPRESS_DB_HOST=192.168.1.2:3307 \ WORDPRESS_DB_USER=демонстрационный_блог \ WORDPRESS_DB_NAME=демонстрационный_блог \ WORDPRESS_TABLE_PREFIX=wp_ 

Наш Dockerfile состоит из двух шагов: FROM и ENV. Шаг FROM указывает Docker создать новый образ на основе образа wordpress. Шаг ENV позволяет нам установить переменные среды для WordPress. Обратите внимание, что переменная WORDPRESS_DB_PASSWORD отсутствует в нашем Dockerfile. Хранение конфиденциальной информации, также известной как секреты, в наших файлах конфигурации очень небезопасно. Вместо этого мы установим переменную при запуске контейнера.

Давайте создадим наш новый пользовательский образ. Мы пометим наш образ именем и версией, чтобы сохранить историю изменений. Поскольку это наша первая сборка, мы пометим изображение с помощью myblog:1.0.0.

 docker build -t myblog:1.0.0 . 

После успешной сборки наш образ будет доступен в нашем локальном репозитории Docker. Мы можем убедиться в этом, выполнив команду docker images.

 docker images 

Давайте запустим наше первое изображение. Мы установим пароль базы данных WordPress, используя флаг -e. В качестве альтернативы мы могли бы использовать и файл переменных среды, как мы делали ранее.

 docker run -d -p 80:80 -e WORDPRESS_DB_PASSWORD=super-secret-password myblog:1.0.0 

Добавление плагинов и тем

Есть два решения. Решение будет рассмотрено в этом разделе, и оно заключается в добавлении плагинов в процесс сборки. Второй вариант, присоединение постоянного хранилища к контейнеру, будет рассмотрен в следующем разделе.

Docker предоставляет команды для добавления содержимого в сборку образа — ADD и COPY. В то время как оба могут добавлять загружаемые плагины и темы в образ WordPress, команда ADD автоматически извлекает архивы в цель.

В рабочей области создайте каталоги для хранения тем и плагинов, а затем загрузите некоторые темы и плагины в соответствующие каталоги.

 mkdir -p ~/workspace/wordpress/{themes,plugins,uploads} 

Измените Dockerfile, чтобы добавить темы и плагины в установку WordPress в вашем образе. Для каждого элемента мы указываем источник на локальном компьютере, а затем цель в самом образе.

 ИЗ Вордпресс
ENV WORDPRESS_DB_HOST=192.168.1.2:3307 \ WORDPRESS_DB_USER=демонстрационный_блог \ WORDPRESS_DB_PASSWORD=d7FfHZsBASsqN5Y \ WORDPRESS_DB_NAME=демонстрационный_блог \ WORDPRESS_TABLE_PREFIX=wp_ 

ДОБАВИТЬ plugins/plugins-a-1.0.0.tar.gz /var/www/html/wp-content/plugins \
plugins/plugin-b-1.1.1.tar.gz /var/www/html/wp-content/plugins
«`

Сохраните изменения и запустите новую сборку. При желании увеличьте версию образа на единицу.

 docker build -t myblog:1.0.1 . 

Запустите обновленный образ Docker и убедитесь, что установленные темы и подключаемые модули доступны.

 docker run -d -p 80:80 -e WORDPRESS_DB_PASSWORD=суперсекретный пароль myblog:1.0.1 

Добавление плагинов и тем в вашу сборку удобно, но создает несколько проблем. Плагины, например, обычно имеют большое количество выпусков для устранения ошибок и проблем с безопасностью. Вы можете обновить плагин из работающего контейнера, однако, поскольку контейнер является эфемерным, обновления не будут сохраняться при перезапуске контейнера. Поскольку обновления могут внести изменения в схему базы данных, ваш сайт не сможет правильно загрузиться с устаревшим контейнером.

Постоянное хранилище контента

Docker может монтировать каталоги в файловой системе хоста в контейнер во время выполнения. Эта функция позволяет данным сохраняться после жизненного цикла контейнера, который является эфемерным (временным). С помощью функции томов мы можем устанавливать наши плагины и темы в файловую систему локального хоста, и все обновления будут сохранены.

В этом разделе будет использоваться созданная ранее структура каталогов для размещения наших плагинов и тем. Затем мы смонтируем каталог в наш контейнер.

Чтобы смонтировать тома, мы должны использовать флаг Docker run -v. В приведенном ниже примере мы предоставляем список целевых точек монтирования внутри контейнера. Исходный каталог будет автоматически создан Docker в каталоге /var/lib, если мы не включим исходный код.

 docker run -d -p 80:80 -v /var/www/html/wp-content/themes,/var/www/html/wp-content/plugins,/var/www/html/wp- контент/загрузки мой блог/wordpress: 5.2 

Давайте снова смонтируем наши тома, но на этот раз мы будем использовать каталоги, которые мы создали ранее, в качестве наших источников.

 docker run -d -p 80:80 \
-v темы/:/var/www/html/wp-content/темы \
-v плагины:/var/www/html/wp-content/plugins \
-v загрузки/:/var/www/html/wp-content/uploads \
мой блог/wordpress: 5.2 

 докер пс 

 ИДЕНТИФИКАТОР КОНТЕЙНЕРА ИЗОБРАЖЕНИЕ КОМАНДА СОЗДАНА СОСТОЯНИЕ НАЗВАНИЯ ПОРТОВ
c68d32e31fd2 docker_blog "docker-entrypoint.s…" 10 часов назад Up 10 часов 0.0.0.0:80->80/tcp docker_blog_1 

докер стоп c68d32

 docker run -d -p 80:80 \
-v темы/:/var/www/html/wp-content/темы \
-v плагины:/var/www/html/wp-content/plugins \
-v загрузки/:/var/www/html/wp-content/uploads \
мой блог/wordpress: 5.2 

Запуск контейнера с непривилегированным пользователем

Большое количество образов, доступных на Dockerhub, включая официальный образ WordPress, запускаются от имени пользователя root. Неудивительно, что это небезопасный способ запуска контейнера. Контейнеры должны работать только с минимальным уровнем привилегий для работы. Возвращаясь к нашей проблеме записи на смонтированные тома в последнем разделе, наши тома смонтированы как root и, следовательно, принадлежат одной и той же учетной записи.

В базовом контейнере WordPress работает веб-сервер Apache, а это означает, что WordPress работает как www-data. Давайте изменим наши Dockerfiles, чтобы наш контейнер также работал как www-data.

Создайте новую версию образа WordPress и перезапустите контейнер.

Перезапустите контейнер и убедитесь, что он работает успешно. Теперь вы сможете устанавливать и обновлять плагины, хранящиеся на смонтированном томе.

Как справиться с неудачами

Посмотрим правде в глаза, ничто не застраховано от неудач. Есть большая вероятность того, что ваш контейнер по той или иной причине выйдет из строя, что приведет к отключению вашего сайта. Очевидно, что это нежелательно, поскольку наши пользователи ожидают не что иное, как 100% безотказной работы. В Docker есть несколько политик перезапуска, которые можно применить к контейнеру во время выполнения. Эти политики попытаются перезапустить контейнер после его остановки или сбоя.

Мораль

Существующий WordPress в Docker можно и не особенно болезненно. Процесс относительно простой, и только настройка сервера меня немного поставила в тупик, но, возможно, это только моя проблема.

Я потрачу ещё какое-то время, тестируя эти контейнера. Измерю потерю в производительности, если такая есть, поищу косяки. Эта штука неизбежно едет в продажу.

Онлайн курс по Kubernetes

Онлайн-курс по Kubernetes – для объединения, администраторов, руководителей, которые хотят изучить современную комбинацию для микросервисов Kubernetes. Самый полный русскоязычный курс по очень востребованным и хорошо оплачиваемым навыкам. Курс не для новичков – нужно пройти вступительный тест.

Если вы ответите «да» хотя бы на один вопрос, то это ваш курс:

• устали тратить время на автоматизацию?
• хотите единообразные окружения?;
• хотите развиваться и использовать современные инструменты?
• небезразлична надежность инфраструктуры?
• приходится масштабировать инфраструктуру под растущие потребности бизнеса?
• хотите освободить продуктовые команды от части задач администрирования и автоматизации и сфокусировать их на развитии продукта?

Сдавайте вступительный тест по ссылке
и присоединяйтесь к новому набору!

Помогла статья? Подписывайся на telegram канал
автора

Анонсы всех статей, плюс много другой полезной и интересной информации, которая не попадает на сайт.

Задумка

Теоретически, задача не сложная, так как у Вордпресса уже есть свой собственный
Докер образ. Даже больше, у них есть и пример docker-compose.yml
 файла, который и WordPress запустит, и MySQL к нему добавит, так что сразу есть с чего начать:

Если к полученной паре контейнеров прикрутить backup сайта, то, по идее, это должно сгодиться в качестве полноценной реплики. Конечно, могут начаться какие-нибудь проблемы, связанные с отсутствием доменного имени на локальной машине, но, думаю, что-нибудь можно придумать. Итак, начнём.

Running the Container in Production

Docker Compose

 ---
version: '3'
services: blog: build: . ports: - "80:80" volumes: - "./wp-content/:/var/www/html/wp-content:Z" 

 docker-compose up -d 

 docker-compose ps 

 Name Command State Ports
---------------------------------------------------------------------------
docker_blog_1 docker-entrypoint.sh apach . Up 0.0.0.0:80->80/tcp 

 docker-compose stop 

 docker-compose build 

Least Privilege

 docker-compose exec blog id 

 uid=0(root) gid=0(root) groups=0(root) 

 useradd -r -u 33 -g 33 www-data 

 FROM wordpress
USER www-data
ENV WORDPRESS_DB_HOST=192.168.1.2:3307 \ WORDPRESS_DB_USER=demo_blog \ WORDPRESS_DB_PASSWORD=d7FfHZsBASsqN5Y \ WORDPRESS_DB_NAME=demo_blog \ WORDPRESS_TABLE_PREFIX=wp_
``` 

If you attempted to restart your container with the latest changes, you will note that it will fail to launch successfully. The reason for this is that we are now running unprivileged, preventing Apache from binding to a system port

. We can update our docker-compose.yml file to instruct the container to allow unprivileged port binding.

 sysctls: - net.ipv4.ip_unprivileged_port_start=0 

Your docker-compose.yml file should now look like the example below.

 ---
version: '3'
services: blog: build: . sysctls: - net.ipv4.ip_unprivileged_port_start=0 ports: - "80:80" volumes: - "./wp-content/:/var/www/html/wp-content:Z"
``` 

Rebuild your Docker image via docker-compose and then restart it.

 docker-compose build && docker-compose up -d 

Делаем бэкап блога

Вот что мне нравится в Вордпрессе, так это как легко с ним сделать полный бэкап. Архивируем  www
 папку, архивируем дамп базы данных, и всё, гештальт завершён. В качестве подопытной морской свинки я возьму свой более свежий блог — codeblog.dotsandbrackets.com, и без лишних церемоний сделаю ему бэкап веб-контента с  tar
 и дамп базы данных с  mysqldump
 и gzip:

При помощи scp
копирую получившиеся два архива на локальную машину, и понеслась, родная.

Шаг 4. Исправляем доменное имя

Ещё один сеанс гугла, и решение найдено
. Заменить имя может вот такой скрипт:

mysql’овская папка  docker-entrypoint-initdb.d
 может принимать больше чем один файл (запускает в алфавитном порядке), так что создам-ка я какой-нибудь migrate.sql
, пропишу в нём новые имена, да подключу к контейнеру:

Но теперь нарисовалась более крупная проблема. Непонятно, как я не заметил её раньше. Все ссылки на посты возвращают 404:

Я смутно помню, что в конфигах nginx на сервере что-то действительно было про пермалинки и ссылки на посты, так что нужно снова идти туда и выяснять, что за оно.

# Настройка параметров веб-сервера

Сначала создадим директорию, в которой будет находиться наш проект, и перейдём в неё:

Внутри этой директории создадим папку для конфигурационного файла веб-сервера:

Создадим сам конфигурационный файл, в котором укажем основные параметры работы: имя нашего сервера, порт, на котором будет работать веб-сервер, блок обработки PHP и запросов статичных активов.

Мы будем создавать текстовые файлы с помощью редактора vim
, но вы можете использовать другой редактор, например, nano
.

Для серверов на Джино можно также воспользоваться файловым менеджером, чтобы создавать вложенные папки и файлы:

Содержимое конфигурационного файла должно быть следующим:

• listen
  — указывает Nginx слушать порт 80.

• server_name
  — имя нашего сервера. В этой строке нужно указать доменное имя, к которому вы хотите привязать свои сайты.

• index
  — порядок обработки индексных файлов. Здесь мы указываем на первом месте php-файл, чтобы он первым обрабатывал запросы.

• root
  — имя корневой директории для запросов к нашему серверу. Эта директория используется как точка монтирования в момент сборки.

• location ~ /.well-known/acme-challenge
  — это блок расположения, который будет обрабатывать запросы в директории .well-known
  .

• location /
  — здесь мы используем директиву try_files
  для проверки файлов, соответствующих отдельным запросам URI. Вместо страницы с ошибкой 404 мы будем передавать контроль файлу index.php
  .

• location ~.php$
  — этот блок будет обрабатывать PHP-запросы и проксировать их в наш контейнер для WordPress. Также здесь мы добавим параметры конфигурации, принадлежащие протоколу FastCGI.

• location ~ /.ht
  — обрабатывает файлы .htaccess
  , поскольку Nginx не будет их обслуживать. В данном случае deny_all
  гарантирует, что файлы .htaccess
  никогда не будут отображаться для пользователей.

• location = /favicon.ico, location = /robots.txt
  — эти блоки гарантируют, что запросы для /favicon.ico и /robots.txt не будут регистрироваться.

Сохраняем наш файл и переходим к созданию переменных среды, которые будут передаваться в контейнеры приложений и базы данных.

# Запуск Docker-Compose

Находясь в директории нашего проекта (~/wordpress), запустим Docker Compose:

Docker Compose создаст необходимые контейнеры и внутреннюю сеть между ними, скачает указанные образы программного обеспечения и запустит WordPress.

Теперь, чтобы проверить правильность работы нашего проекта, откроем браузер и зайдём по адресу, который мы указывали в качестве доменного имени. Если всё было сделано правильно, откроется окно мастера установки WordPress.

Шаг 5. Исправляем ссылки

ОК, проблема на самом деле большая. Вот как я заставлял ссылки работать на nginx в «продакшене»:

Но в контейнером WordPress используется Apache! У него наверняка есть что-нибудь похожее, но я не настолько фанат или спец в Апаче, чтобы с ним ковыряться. Я хочу свой nginx назад!

Очередной сеанс гугла, и снова есть решение. Образ WordPress существует в нескольких вариантах, в том числе и fpm
, к которому можно прикручивать собственные сервера. А один хороший человек даже подготовил образ с nginx для этого —  rault/nginx-wordpress
. Буду пробовать.

Опять же, сначала убиваем старые контейнеры:

Теперь, меняем wordpress
образ на wordpress:fpm
 и добавляем новый сервис — nginx:

Наконец, запускаем контейнера и скрещиваем все доступные пальцы на удачу, потому что разродиться альтернативным решением среди ночи я не смогу. Это просто должно сработать.

JetPack снова поругался и снова отправился в страну вечной охоты. Но в остальном всё вроде работает.

Я прокликал все очевидные ссылки, и всё ОК. Всё в докере, и всё ОК!

# Создание переменных среды

В процессе работы нашей базе данных и WordPress понадобится доступ к некоторым переменным среды. Эти переменные содержат как чувствительную информацию (root-пароль к базе данных, имя и пароль администратора базы данных), так и нечувствительную (имя базы данных и её хост).

Вместо того чтобы прописывать эти переменные в нашем docker-compose-файле, мы создадим отдельный .env-файл
и запретим его копирование. Это позволит нам указывать все чувствительные переменные в одном месте и быть уверенными, что они не копируются и не перемещаются без нашего контроля.

Находясь в директории нашего проекта (~/wordpress), создадим файл, в котором будут храниться чувствительные переменные среды:

В новом файле укажем значения наших переменных:

Чтобы избежать копирования нашего файла, укажем его в .gitignore
и .dockerignore
— файлах, указывающих на то, какие файлы нельзя копировать при создании git-репозиториев (если вы собираетесь использовать git в качестве системы контроля версий) и docker-образов.

Если вы планируете работать с Git, инициируйте текущую директорию в качестве репозитория:

Теперь откройте .gitignore-файл:

Укажите здесь файл, содержащий чувствительные переменные среды:

То же самое нужно сделать для docker
:

В этом файле укажем не только наш файл с чувствительными переменными, но и все файлы, которые с ним связаны:

Сохраним и закроем наш файл.

Наша чувствительная информация защищена, и можно перейти непосредственно к созданию docker-compose-файла.

# Создание файла docker-compose

Файл docker-compose.yml
определяет, какие службы будут запущены в вашем проекте. Службы — это отдельные контейнеры с приложениями, образы которых скачиваются непосредственно после запуска compose-файла.

В Docker Compose можно запустить несколько контейнеров с разными приложениями, объединить их в единую внутреннюю сеть и указать на использование одних и тех же томов.

В нашем случае мы создадим отдельные контейнеры для WordPress, Nginx и MySQL.

Начнём с общей информации о файле и определим первую службу — MySQL:

Чтобы было понятнее, что мы делаем и зачем, приведём пояснения, описывающие содержимое каждого отдельного блока:

• version
  — версия compose-файла, соответствующая текущей версии Docker.

• image
  — образ приложения, которое будем использовать. В данном случае мы указываем конкретное значение (8.0), чтобы избежать возможных проблем при появлении более новой версии (параметр latest
  ).

• container_name
  — имя контейнера, в котором будет запускаться наше приложение.

• restart
  — устанавливает политику перезапуска контейнера. Обычно указывают «no», но мы укажем «unless-stopped», т.е контейнер будет перезапускаться, пока не будет остановлен вручную.

• env_file
  — указание файла, в котором содержатся переменные среды.

• environment
  — добавляем дополнительные переменные среды, в нашем случае это имя нашей базы данных. Поскольку это нечувствительная переменная, её можно указать прямо в compose-файле.

• volumes
  — создаём том dbdata
  в директории /var/lib/mysql
  . Это стандартная директория для баз данных.

• command
  — определение метода аутентификации для PHP и WordPress. Поскольку эти приложения не будут поддерживать стандартный метод аутентификации, то здесь мы вручную определяем значение для default-authentication-plugin
  , равное значению переменной среды mysql_native_password
  .

• networks
  — указание на то, что наш контейнер db
  будет подключён к app-network
  — внутренней сети, которую мы определим в самом конце нашего файла.

После определения службы баз данных определяем службу WordPress. В том же файле docker-compose.yml
после строки network
в блоке для баз данных вставляем пустую строку и пишем следующий блок текста:

• depends_on
  — параметр, который определяет зависимость контейнера «wordpress» от контейнера «db» — «wordpress» не будет запущен, пока не запустится «db».

• image
  — образ скачиваемого приложения. В нашем примере мы используем WordPress 5.1.1-fpm-alpine.

• env_file
  — здесь мы также указываем наш .env-файл, поскольку именно WordPress будет пользователем базы данных, и для него нужны имя и пароль.

• environment
  — в этом блоке переменных среды мы указываем переменные, необходимые для работы WordPress, при этом присваиваем значения из env-файла. Также здесь мы определяем имя хоста (mysql-сервер, запущенный в разделе db и по умолчанию работающий на порте 3306). Имя базы данных для WordPress мы указываем то же, которое указали на предыдущем шаге в разделе db (wordpress).

• volumes
  — создаём том «wordpress» в /var/www/html
  , который является точкой сборки. Используя том таким образом, мы сможем организовать обмен данными между всеми контейнерами в нашем проекте.

• networks
  — добавляем наш контейнер в сеть «app-network».

Следующий на очереди — блок веб-сервера. Также вставляем пустую строку после networks
в блоке wordpress
в уже открытом файле и продолжаем ввод текста:

Помимо уже описанных параметров обратим здесь внимание на:

• ports
  — здесь указан 80, который отмечен в конфигурационном файле веб-сервера в самом начале нашей инструкции.

• volumes
  — здесь мы определяем сразу несколько томов и связей:
  — wordpress:/var/www/html — это указание поместит код WordPress в /var/www/html
  , директорию, которую в конфигурации нашего веб-сервера мы указали как root
  ;
  — ./nginx-conf:/etc/nginx/conf.d — это указание связывает конфигурационный файл веб-сервера на хосте и в контейнере. Таким образом, все изменения в конфигурационном файле на хосте переносятся в файл в контейнере.

Также добавляем наш контейнер в сеть app-network
.

Теперь можно переходить к определению томов и внутренней сети нашего проекта. Это будут заключительные блоки нашего docker-compose.yml
:

• volumes
  определяет тома,которые будут созданы при работе Docker Compose. Тома расположены по адресу /var/lib/docker/volumes/
  . Данные из томов могут быть доступны для любого контейнера, расположенного в сети, что позволяет организовать обмен данными между контейнерами.

• networks:
  — создаёт внутреннюю сеть, которая обеспечивает связь между контейнерами, при этом для связи с внешней сетью контейнеры используют только порт 80 веб-сервера.

Теперь можно сохранить и закрыть наш compose-файл.

Запуск wordpress в docker с https

Теперь самое главное — готовим конфиг docker-compose для нашей магии, с помощью которой wordpress будет автоматически установлен одной командой. И не придется заморачиваться с сертификатами и всем остальным. Это все отлично подойдет для разработчиков. Самые отважные так запускают сайты в прод заказчикам. В целом, криминала в этом нет, но мне кажется на мелких проектах и одиночных vps лучше все это без докера в прод выпускать.

Вот мой финальный .

 version: '3'
services: swag: image: linuxserver/swag container_name: swag cap_add: - NET_ADMIN environment: - TZ=Europe/Moscow - URL=  253197.simplecloud.ru 
# - SUBDOMAINS=www, - VALIDATION=http volumes: - "./nginx-default:/config/nginx/site-confs/default" ports: - 443:443 - 80:80 restart: unless-stopped mysql: image: mysql:8 container_name: mysql command: --default-authentication-plugin=mysql_native_password restart: always environment: MYSQL_ROOT_PASSWORD:  root  MYSQL_DATABASE:  wordpress  volumes: - "./mysql:/var/lib/mysql" wordpress: image: wordpress:php7.4-apache container_name: wordpress depends_on: - mysql environment: WORDPRESS_DB_HOST: mysql WORDPRESS_DB_USER: root WORDPRESS_DB_PASSWORD:  root  WORDPRESS_DB_NAME:  wordpress  volumes: - "./html:/var/www/html/" - "./.htaccess:/var/www/html/.htaccess" wp-cli: image: wordpress:cli container_name: wp-cli user: "33:33" environment: WORDPRESS_DB_HOST: mysql WORDPRESS_DB_USER: root WORDPRESS_DB_PASSWORD: root WORDPRESS_DB_NAME: wordpress volumes: - "./html:/var/www/html/" - "./configure-wp.sh:/opt/configure-wp.sh" command: "bash /opt/configure-wp.sh" 

Жирным я выделил то, что вам нужно заменить на свои значения. Сохраняем конфиг и запускаем docker-compose:

 # docker-compose up 

Наблюдаем в консоли запуск нашего проекта на wordpress с помощью docker контейнеров. Если все в порядке, то последним вы должны у видеть примерно следующее.

Успешный выпуск tls сертификата lert’s encrypt будет выглядеть в логах вот так.

Можно сходить по адресу сайта и убедиться, что все работает.

Ваша рабочая директория со скриптами и исходниками будет выглядеть следующим образом.

• html — исходники сайта
• mysql — бинарные файлы базы данных

Можете все это забэкапить или положить в git
, настроив исключение для директории с базой. Ее можно дампить отдельно и как-то сохранять. При желании можно в тот же git класть, если она не очень большая.

Safely Handling Secrets

We’ve address running a Docker container reliably on a production server by utilizing docker-compose. We haven’t, however, addressed the elephant in the room, which is securely handling secrets. Unfortunately, with WordPress there isn’t an easy solution for handling database credentials securely. Whether we are storing this information in our docker-compose.yml file, storing it within our Dockerfile, or entering it as an env variable when executing docker run, the credentials are easily discoverable.

While docker provides a built-in secrets service for handling sensitive information, it is only available in swarm mode. We have not covered docker orchestration solutions in this tutorial, but to address this area of concern you will want to investigate running the container

Импортируем данные

Краткий сеанс гугла меня очень порадовал. Оказывается, если примонтировать к mysql контейнеру дамп базы вот к этой папке —  /docker-entrypoint-initdb.d/
, то при первом запуске mysql его автоматически импортирует. Он даже архивы понимает, так что можно сдать ему мой дамп как он есть:

Снова запускаем контейнеры:

Бэкап wordpress в docker

Отдельно расскажу, как такой сайт бэкапить или куда-то переносить. Первым делом надо сделать дамп базы данных, которая живет в docker. У меня была отдельная заметка на этот счет — Backup mysql базы в docker контейнере
. В нашем случае получается такая команда:

 # docker exec mysql /usr/bin/mysqldump -u root --password=  root  wordpress | gzip -c > ~/`date +%Y-%m-%d`_wordpress.sql.gz 

Исходники сайта будут лежать в директории html
. Таким образом, для бэкапа всего сайта вам достаточно куда-то скопировать исходники и дамп с базой. Я рекомендую для этого использовать rsync
. У меня есть отдельная статья по этой теме — настройка бэкапа с помощью rsync
.

Подключаем веб-контент к контейнеру

В том же Dockerfile я заметил, что вордпрессовский контент будет лежать в папке  /var/www/html
 (это ещё и volume). По идее, можно просто подключить туда мой бэкап, и вебовская часть контента будет восстановлена.

Наконец, моя прогрессирующая интернет паранойя
больше не позволяет мне ложить имена и пароли открытым текстом в Docker-файлы, так что я лучше их положу в локальные переменные окружения и буду импортировать уже оттуда:

Теперь распаковываем бэкап с вэб-контентом, подкручиваем его к docker-compose.yml, задаём там же пустую базу данных, и пробуем запустить (кстати, всё это происходит на маке, но на никсе будет то же самое):

Ну, Вордпресс определённо запустился. Но как определить, это он «мой» контент использует сейчас, или «свой»? Можно, конечно, влезть в контейнер и посмотреть внутри, но лучше я подключу настоящую базу, и всё сразу станет яснее. Так что останавливаем запущенные контейнеры и вперёд к импорту данных: