Послуги з DevOps та серверного налаштування для 1С-Бітрікс

DevOps для 1С-Бітрікс

rsync -avz на продакшен у п'ятницю ввечері, рестарт php-fpm, і сайт відповідає 502 — бо в .settings.php залишились локальні налаштування підключення до БД. Класика Бітрікс-деплою «по-старому». Ми вибудовуємо повний DevOps-цикл для проєктів на 1С-Бітрікс: від Docker-оточення до алертів у Telegram, щоб деплой був рутиною, а не лотереєю.

Проблеми, які вирішує DevOps на Бітрікс-проєктах

Бітрікс історично жив у парадигмі «правимо файли по FTP на бойовому сервері». У 2026 році так працюють десятки команд, і ось до чого це призводить:

• Двоє розробників правлять init.php одночасно — один затирає зміни іншого. Файл init.php у Бітрікс — точка входу для обробників подій, кастомних функцій і підключень модулів. Втратити правки тут — втратити бізнес-логіку
• Оновлення модуля через адмінку ламає кастомний шаблон компонента, бо ніхто не зафіксував, які файли змінювались у /local/templates/
• Про падіння сайту дізнаються від клієнта, а не з моніторингу
• Staging-середовища немає — «швидко перевіримо на проді», і bitrix:catalog.section зник

CI/CD: від коміту до продакшену без рук

Git — переводимо проєкт з FTP на Git (GitLab, GitHub, Bitbucket). Структура гілок: main (production), staging, develop, feature-гілки. .gitignore під Бітрікс — річ нетривіальна:

/bitrix/cache/
/bitrix/managed_cache/
/bitrix/stack_cache/
/upload/
/bitrix/php_interface/dbconn.php
/bitrix/.settings.php
/bitrix/license_key.php

Пропустиш managed_cache/ — репозиторій розпухне на гігабайти. Забудеш виключити license_key.php — ключ витече.

CI-пайплайн перевіряє код автоматично:

• PHPStan level 5+ для статичного аналізу — ловить звернення до неіснуючих методів CIBlockElement до того, як вони потраплять на сервер
• PHP_CodeSniffer зі стандартом Bitrix
• PHPUnit для бізнес-логіки, Jest для фронтенду
• composer audit — перевірка залежностей на вразливості
• Збірка фронтенду (webpack/Vite)

CD-пайплайн розгортає автоматично:

• Мерж у staging — деплой на staging
• Мерж у main — деплой на production (з ручним підтвердженням або автоматично)
• Zero-downtime через symlink-стратегію: нова версія в окремій директорії, current → symlink-перемикання за мілісекунди. upload/ живе поза релізними директоріями
• Автоматичний rollback при помилках — якщо healthcheck після деплою повернув не 200, symlink відкочується

Інструменти: GitLab CI/CD, GitHub Actions, Deployer (PHP). Deployer особливо зручний для Бітрікс — є рецепти для symlink-деплою та shared-директорій.

Docker для Бітрікс

Docker вирішує «у мене працює» раз і назавжди.

Локальна розробка — docker-compose.yml:

• nginx + php-fpm 8.1/8.2 + MySQL 8.0 (або MariaDB 10.6) + Redis + Memcached
• Конфігурація максимально близька до продакшену — ті самі версії, ті самі модулі PHP
• Новий розробник: git clone + docker-compose up -d — через 5 хвилин пише код
• Паралельна робота над проєктами з різними версіями PHP — через різні compose-файли

Особливості Бітрікс у Docker — тут граблі:

• /upload/ монтується як named volume. Не bind mount — інакше на Windows/Mac будуть проблеми з правами та швидкістю
• Cron-задачі Бітрікс (/bitrix/modules/main/tools/cron_events.php) — через окремий контейнер з тим самим образом або supervisord всередині контейнера
• Модуль «Проактивний захист» (security) блокує запити, якщо бачить reverse proxy. Потрібен правильний REMOTE_ADDR через set_real_ip_from у nginx та realip_module
• bitrix/php_interface/dbconn.php та .settings.php — через environment variables або окремий .env-файл, не через volume з продакшен-конфігами

Production:

• Мультистейдж-збірка: build-стадія для ассетів, production-стадія з мінімальним образом
• Docker Registry для версіонованих образів
• Оркестрація через Docker Swarm або Kubernetes для великих проєктів

Налаштування nginx та php-fpm

Різниця між «сайт гальмує» та «200ms TTFB» — у конфігурації.

nginx:

• Location-блоки під Бітрікс: urlrewrite.php обробляє ЧПУ, /bitrix/admin/ закритий по IP через allow/deny
• expires 30d для статики — CSS, JS, зображення віддаються з кешу браузера
• Brotli (краще за gzip на 15-20% для тексту): brotli on; brotli_comp_level 6;
• Rate limiting на /bitrix/tools/ — захист від брутфорсу та простого DDoS
• HTTP/2 push для критичних ресурсів

php-fpm:

• pm = dynamic, розрахунок pm.max_children за формулою: (RAM - RAM_інших_сервісів) / avg_memory_per_process. Для Бітрікс avg зазвичай 40-80 МБ
• OPcache: opcache.memory_consumption=256 (стандартних 128 МБ не вистачає — Бітрікс тягне тисячі файлів), opcache.max_accelerated_files=20000, opcache.validate_timestamps=0 на продакшені (скидання через cachetool opcache:reset при деплої)
• php.ini: memory_limit=256M (для важких операцій імпорту — до 512M), max_execution_time=60, upload_max_filesize=100M
• slowlog з request_slowlog_timeout=5s — знаходимо вузькі місця раніше за користувачів

Моніторинг та логування

Інфраструктура:

• Prometheus + Grafana: CPU, RAM, диск, мережа, стан сервісів
• Алерти: CPU > 80% за 5 хвилин, вільна RAM < 500 МБ, диск > 85%, php-fpm queue > 0 (черга означає, що воркерів не вистачає)
• Node Exporter, MySQL Exporter, PHP-FPM Exporter — метрики збираються з кожного компонента

Застосунок:

• Uptime check кожні 60 секунд — якщо сайт ліг, алерт у Telegram за хвилину
• Час відгуку ключових URL: /, /catalog/, /personal/order/make/
• Sentry для PHP-помилок — не tail /var/log/php-errors.log, а структуровані помилки з контекстом
• Моніторинг агентів Бітрікс (b_agent у БД) — завислий агент може тихо ламати обмін з 1С годинами. Перевіряємо NEXT_EXEC < NOW() - INTERVAL 1 HOUR

Логування:

• ELK Stack або Loki + Grafana — nginx access/error, php-fpm slow log, MySQL slow query log, Бітрікс-помилки — все в одному місці
• Ротація через logrotate — без неї через півроку access.log з'їсть 50 ГБ

Staging-середовище

• Ідентичне production: ті самі версії nginx, PHP, MySQL, ті самі модулі, ті самі налаштування php.ini
• Автоматичне оновлення при мержі в staging-гілку
• Періодичний клон БД з production. Знеособлення персональних даних — UPDATE b_user SET EMAIL = CONCAT('user', ID, '@test.local'), PHONE = '' — захист персональних даних
• HTTP Basic Auth або IP-фільтрація. Robots.txt з Disallow: /
• Sandbox-режим платіжних шлюзів для тестування оплати

Ansible: інфраструктура як код

Потрібен новий сервер? ansible-playbook site.yml -l production — через 15 хвилин налаштований ідентично поточному:

• Плейбуки: nginx, php-fpm, MySQL, Redis, certbot, firewall
• Перевикористовувані ролі: common (users, SSH, NTP), web (nginx + php-fpm), db (MySQL + backup), monitoring (Prometheus + exporters)
• Ідемпотентність — повторний запуск нічого не ламає
• Inventory: [production], [staging], [development] — керування групами серверів

Резервне копіювання

• Географічна розподіленість — S3-сумісне сховище + окремий сервер в іншому ЦОД
• Тестове відновлення щомісяця. Бекап, з якого жодного разу не відновлювались — це не бекап, а ілюзія безпеки
• Cron зі сповіщеннями: якщо бекап не пройшов — алерт одразу

Типові терміни впровадження

DevOps — не проєкт з датою завершення, а перехід від «закинув по FTP і молюся» до передбачуваних процесів. Кожен деплой — рутина, кожен інцидент — алерт з контекстом, кожен новий розробник — docker-compose up замість триденного налаштування оточення.