Docker для WordPress: почему изолированные контейнеры меняют всё

Традиционный хостинг WordPress размещает несколько сайтов на одном сервере. Они используют общий PHP, общий доступ к файловой системе и часто общий сервер баз данных. Это нормально, пока не возникает проблема — а когда она возникает, это серьёзная проблема.

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

Проблема общего хостинга

На обычном общем хостинге или даже на базовом VPS с несколькими установками WordPress:

Конкуренция за ресурсы: всплеск трафика на одном сайте замедляет работу всех остальных сайтов на сервере. Плохо оптимизированный плагин на сайте А ухудшает производительность сайта Б.

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

Конфликты версий PHP: сайту А нужен PHP 7.4 для старого плагина. Сайту Б нужен PHP 8.2 для нового. На общем хостинге вы выбираете один.

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

Docker-контейнеры решают все эти проблемы на уровне инфраструктуры.

Что такое контейнер на самом деле

Docker-контейнер — это лёгкий, изолированный процесс, который имеет свою собственную:

• Файловую систему (контейнер не видит файлы за своими пределами)
• Сетевой стек (свой IP-адрес, свои порты)
• Пространство процессов (не видит процессы других контейнеров)
• Ограничения ресурсов (лимиты ЦП и памяти)

Он разделяет ядро хоста с другими контейнерами, но всё, что выше ядра, изолировано. Это не полноценная виртуальная машина — она запускается за секунды, а не минуты, и использует лишь малую часть ресурсов.

Для WordPress в одном контейнере работают: Nginx, PHP-FPM и файлы WordPress. База данных работает в отдельном контейнере, подключённом только к этому конкретному контейнеру WordPress.

Как PAGEnza разворачивает сайт

Когда вы создаёте новый клиентский сайт в PAGEnza, вот что происходит менее чем за 45 секунд:

1. Создаётся новый Docker-контейнер из базового образа WordPress
2. WordPress настраивается со свежей базой данных на общем экземпляре MariaDB (изолированной учётными данными этого контейнера)
3. Плагин PAGEnza автоматически устанавливается и активируется
4. Настраивается виртуальный хост Nginx с поддоменом клиента
5. SSL выдаётся через Let's Encrypt
6. Контейнер регистрируется в обратном прокси с правилами маршрутизации

Клиент получает URL вида clientname.pagenza.com, который становится доступен в течение 45 секунд после нажатия «Создать сайт». Никакой ручной настройки сервера, SSH или ожидания DNS (для поддомена — распространение DNS для пользовательских доменов происходит отдельно).

Изоляция контейнеров на практике

Лимиты памяти: каждый контейнер имеет настраиваемый лимит памяти. Если вышедший из-под контроля плагин вызывает всплеск потребления памяти на сайте одного клиента, он не может использовать память, выделенную другим контейнерам. Сайт может замедлиться или вернуть ошибку 503 — но это не повлияет на других клиентов.

Изоляция файловой системы: файлы WordPress клиента А полностью невидимы для контейнера клиента Б. Скомпрометированный плагин на сайте клиента А не имеет доступа к файлам клиента Б.

Сетевая изоляция: контейнеры взаимодействуют только через определённые сетевые мосты. Контейнер базы данных клиента А принимает соединения только от контейнера WordPress клиента А — не от какого-либо другого контейнера в системе.

PHP на контейнер: поскольку каждый контейнер запускает свой собственный экземпляр PHP-FPM, вы можете запускать разные версии PHP для разных клиентов. Устаревший плагин клиента А, которому нужен PHP 7.4, прекрасно работает рядом с современным стеком клиента Б на PHP 8.2.

Пользовательские домены

Настройка по умолчанию предоставляет каждому клиенту поддомен *.pagenza.com. Для клиентов, желающих использовать собственный домен, процесс выглядит так:

1. Клиент направляет запись A своего домена на IP-адрес сервера PAGEnza
2. В панели управления PAGEnza вы вводите пользовательский домен
3. Конфигурация обратного прокси автоматически обновляется
4. SSL выдаётся для пользовательского домена через Let's Encrypt

Параметры siteurl и home WordPress обновляются соответствующим образом. С точки зрения клиента, его сайт просто работает по его домену — без перенаправления, без видимого посетителям поддомена.

Что это значит для агентств

Практическая выгода для агентств, управляющих несколькими клиентскими сайтами:

Скорость онбординга: развёртывание нового клиентского сайта занимает менее минуты. Никакой настройки сервера, cPanel или ручной установки WordPress.

Разделение клиентов: каждый клиентский сайт по-настоящему изолирован. Клиент, устанавливающий проблемный плагин, влияет только на свой собственный сайт.

Масштабируемость: добавление нового клиента не требует развёртывания нового сервера. Контейнерная инфраструктура масштабируется до мощности хоста, а добавление большей мощности — это вопрос добавления новых узлов хоста.

Аварийное восстановление: поскольку каждый сайт находится в контейнере, резервное копирование и восстановление происходит на уровне контейнера. Восстановление сайта одного клиента не затрагивает других клиентов.

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