Как добавить ранер для выполнения фоновых заданий Action Scheduler с помощью Docker Compose и WP-CLI?

По умолчанию фоновые задачи выполняются при посещении сайта, но в продакшене это не всегда надёжно. При большом объеме задач мы можем создать перегрузку веб сервера, или наоборот — если трафика мало, задания могут долго висеть в очереди. Иногда лучше настроить отдельный runner, который будет запускать Action Scheduler через WP-CLI.

Action Scheduler – это популярная библиотека для планирования и асинхронного выполнения задач в WordPress. Её используют WooCommerce, WP All Import и многие другие плагины.

Также он может быть установлен как Composer Package или в качестве отдельного плагина https://wordpress.org/plugins/action-scheduler/

В этой статье разберём, как организовать дополнительный runner с помощью Docker Compose и контейнера wordpress:cli.

---

Почему стоит выносить runner в отдельный сервис?

• Минимум нагрузки на сайт – запросы пользователей не будут инициировать выполнение тяжёлых фоновых задач. Что позволяет экономить ресурсы основного веб сервера.
• Независимость от трафика – задачи выполняются по расписанию, даже если сайт никто не посещает.
• Гибкость – можно легко менять частоту запуска или проще масштабировать нагрузку.
• Удобство мониторинга – runner работает как отдельный сервис в Docker, его логи доступны через docker compose logs.

---

Зачем мне это понадобилось?

На одном из сайтов было реализовано множество автоматизаций процессов и работа ИИ агентов. Что начало создавать большую нагрузку на веб хостинг.

Чтобы распределить нагрузку я решил запустить 4 отдельных ранера:

• один на самом веб хостинге с редким запуском — скажем 1 раз в час — просто как запасной но без лишней нагрузки
• второй на моем ноутбуке через Docker Desktop — он все равно используется на 10% от своей мощности — пусть какую то еще полезную работу делает
• третий на отдельном VPS с установленным docker compose через Dokploy.
• четвертый — совсем ради забавы — старый ноутбук который забрал от родителей — также на нем поднят Docker и домашний сервер — тоже почти ничего не делает, а электричество кушает — вот пусть кушает не просто так

Процесс настройки

Docker Compose конфигурация

Ниже приведён пример docker-compose.yml, который запускает отдельный сервис wpcli для выполнения заданий Action Scheduler:

services:
  wpcli:
    image: wordpress:cli
    command: sh -c "while true; do wp action-scheduler run --path=/var/www/html; sleep 33; done"
    volumes:
      - wordpress_data:/var/www/html
      - ./public/wp-content:/var/www/html/wp-content
      - ./public/wp-config-cli.php:/var/www/html/wp-config.php
    environment:
      WORDPRESS_DB_HOST: ${DB_HOST}
      WORDPRESS_DB_USER: ${DB_USER}
      WORDPRESS_DB_PASSWORD: ${DB_PASSWORD}
      WORDPRESS_DB_NAME: ${DB_NAME}
    networks:
      - wp-network

volumes:
  wordpress_data:

networks:
  wp-network:
    driver: bridge

---

Настройка wp-config-cli.php

Обычно лучше иметь отдельный конфиг для CLI, чтобы не мешать веб-конфигурации.

Пример wp-config-cli.php:

<?php
define( 'DB_NAME', getenv('WORDPRESS_DB_NAME') );
define( 'DB_USER', getenv('WORDPRESS_DB_USER') );
define( 'DB_PASSWORD', getenv('WORDPRESS_DB_PASSWORD') );
define( 'DB_HOST', getenv('WORDPRESS_DB_HOST') );
define( 'DB_CHARSET', 'utf8' );
define( 'DB_COLLATE', '' );

$table_prefix = 'wp_';

define( 'WP_DEBUG', false );

if ( ! defined( 'ABSPATH' ) ) {
    define( 'ABSPATH', __DIR__ . '/' );
}
require_once ABSPATH . 'wp-settings.php';

---

Проверка работы runner’а

После запуска:

docker compose up -d wpcli

Можно посмотреть логи:

docker compose logs -f wpcli

Там будут появляться сообщения о запуске action-scheduler run.

Если задачи есть — они будут выполняться, если очередь пуста — команда просто завершится без ошибок и перезапустится через 33 секунды.

---

Оптимизация частоты запуска

• 33 секунды — это компромисс: достаточно часто, чтобы задания выполнялись почти в реальном времени, и при этом нагрузка на сервер минимальная. На своем ноутбуке пока оставил 33 секунды
• Для раннера на веб хостинге я поставил вообще 1 час
• Можно увеличить интервал (sleep 60) для менее критичных сайтов или уменьшить (sleep 10) для сайтов с высокой нагрузкой. Но у меня пока нагрузка не так высока.

Заключение

С помощью отдельных ранеров на базе wordpress:cli и Docker Compose можно полностью убрать зависимость выполнения Action Scheduler от трафика и обеспечить стабильную обработку фоновых задач в WordPress. Особенно если нагрузка возросла.

Такой подход особенно полезен для сайтов на WooCommerce, где корректное выполнение заданий (отправка писем, обновление заказов, синхронизация данных) критически важно.

Также это может быть полезно если ваш WordPress используется как система для автоматизации процессов и обработки различных заданий. Как в моем случае.