Привет! Меня зовут Игорь Росляков, я технический писатель. По приглашению руководителя направления «Маркет и интеграции» Сергея Вострикова я готовлю цикл статей на тему ИИ-ассистированной разработки решений для Битрикс24.
Статьи из цикла можно использовать как туториалы при создании локальных приложений в свой бизнес-портал. Их можно показать своим разработчикам или использовать самому, если работаете один и хотите кастомизировать работу дополнительными удобными функциями.
Сегодня — 3-я статья из цикла. Рассказываем про преимущества разработки, которую можно воспроизвести на любой машине и сервере с сохранением всех зависимостей. Это подход, когда у всех всё работает одинаково: запуск, настройка, обновления, ошибки.
После этого зарегистрируем домен для готового приложения, арендуем сервер и задеплоим, чтобы всё работало 24 часа в сутки без запущенной программы на нашем локальном компьютере.
Основную работу будем делать не сами, а через AI-агентов — Claude Sonnet 4.6 и Codex GPT-5.4.
Ссылка на репозиторий, который сейчас задеплоен:
github.com/igorrosliakov-bitrix24/Bitrix24-Article2-Adding-4-Robots
Игорь Росляков
Технический писатель
Что будет в статье:
Как работать без воспроизводимой среды разработки
Если разработчик работает соло и запускает приложение только на своей машине, можно просто установить все зависимости и запускать проект локально.
Но для командной работы или запуска проекта в интернете это неудобно: другим разработчикам тоже нужно устанавливать все те же самые программы с теми же версиями, которые использовали вы. Если вы хотите развернуть приложение в интернете на сервере, чтобы оно было доступно другим пользователям в любое время, те же самые зависимости нужно будет установить на сервер.
Это выглядит примерно так. Одному разработчику для разработки приложения нужны Python 3.11, PostgreSQL 17 и RabbitMQ 3.13.
Что нужно сделать на Windows:
Открываем python.org → скачиваем installer → проходим путь установки и не забываем галочку "Add to PATH".
Заходим на postgresql.org → скачиваем installer → запоминаем порт → устанавливаем pgAdmin.
Для установки RabbitMQ сначала скачиваем и устанавливаем Erlang → потом RabbitMQ
Настраиваем переменные окружения.
Для сборки psycopg2 нужен Visual C++ Build Tools.
Если передать этот проект коллеге с MacOS, то просто запустить его не получится. Почему:
У коллеги Homebrew, но Python 3.9 из системы.
brew install python@3.11 выдаст конфликт с pyenv.
PostgreSQL стоит не той версии, которую ожидает проект.
Нужный порт уже занят другим проектом.
RabbitMQ через Homebrew устанавливается, но как сервис.
Примерно так же, но с другими конфликтами будет выглядеть установка на Linux. В итоге проект запускается, но только одним конкретным способом.
Что даёт воспроизводимая среда разработки
Чтобы было проще запускать приложение на разных системах, чаще всего его упаковывают в Docker-контейнер. На всех системах этот процесс можно уложить в 3 шага:
Установить Docker (Docker Desktop для локальной разработки или Docker Engine для сервера).
Клонировать репозиторий.
Запустить командой make dev-python.
После этого получаем одинаковую среду на всех машинах. Другие коллеги из команды клонируют репозиторий и благодаря Docker получают точно такой же образ.
Все нюансы командной работы повторяются при деплое на сервере. Без Docker нужно устанавливать и настраивать все зависимости по одной. А если проект уже упакован в контейнер, для сервера нужно будет только скачать сам Docker, клонировать репозиторий, заполнить значения в .env-файле и запустить ./scripts/deploy.sh.
По крайней мере, так выглядел мой план в теории. Дальше рассказываю, что получилось на практике.
Деплоим готовое приложение по шагам
Всю работу можно разделить на 2 большие задачи:
Инфраструктурная: сервер, Docker, nginx, SSL, backend, frontend.
Интеграционная: правильная установка приложения в Битрикс24, регистрация роботов, корректная работа самих роботов.
Мы пройдём все этапы развёртывания готового приложения из предыдущей статьи.
Наш готовый проект основан на AI-cтартере, готовом шаблоне, который можно подключить к Битрикс-порталу. В стартер уже вшит контейнер, и после первоначальной почти полностью автоматической настройки сервис поднимается одной командой. Скачивать язык программирования, базы данных и брокер очередей не нужно устанавливать вручную — всё уже есть в контейнере.
Функция приложения — создание роботов для автоматизации работы в CRM. Роботы добавляются в процесс ведения сделки. У сделки есть несколько стадий, и на каждую можно добавить несколько роботов:
Это состояние проекта на начальном этапе. Сейчас всё работает, только если запустить приложение на моём локальном компьютере.
Вот как выглядел мой деплой по шагам.
Аренда домена и сервера
Для деплоя нам понадобится домен и арендованный сервер. После небольшого исследования я купил домен и арендовал VPS на месяц у Timeweb Cloud.
Сначала я завёл домен под приложение с роботами:
После этого выбрал сервер с Ubuntu и в Москве.
Почему Ubuntu:
Официальный скрипт установки Docker
curl -fsSL https://get.docker.com | shтестируется в первую очередь на Ubuntu.Для этой ОС самая большая база документации и Stack Overflow-ответов.
Обновления безопасности LTS (Long Term Support) до 2029 года.
После этого я взял второй снизу по стоимости сервер:
Если брать 1 Гб RAM, есть риск, что при сборке Docker-образов не хватит памяти. А всё что выше и дороже 2 ГБ, избыточно для тестового проекта.
Публичный IP — это дополнительная опция поверх базовой, то есть один публичный IP вы получаете по умолчанию. Эту возможность и бэкапы я не добавлял, потому что у нас учебный проект. Но доступ по SSH-ключу нужен, чтобы можно было подключиться из терминала командной строки на своём компьютере:
Cloud-init — это скрипт, который запускается один раз при первом старте сервера для автоматической настройки. Может быть удобно, если знаете что делать заранее. Но мы будем настраивать всё с ИИ-агентами поэтапно, поэтому здесь ничего не пишем.
После покупки в настройках домена нужно найти DNS-записи и добавить запись типа А, в которой вместо хоста должен быть ваш домен, а в качестве значения — IP-адрес сервера. Тогда домен тоже будет указывать на сервер, например, если пользователь открывает домен в браузере.
Оплата домена на 1 год и сервера на 1 месяц суммарно обошлись в ~1000 рублей.
Подключаемся к серверу
Мы подключаемся к серверу по SSH с использованием root-пароля командой такого вида:
ssh root@62.54.11.208
После этого терминал запросит root-пароль, который можно найти в панели управления сервером:
Первоначальная настройка
Сначала я попросил у агента план настройки сервера и просто повторял команды в терминале командной строки.
Шаг 1: установить Docker для запуска наших контейнеров. Выполняем такие команды:
apt update && apt upgrade -y curl -fsSL https://get.docker.com | sh docker --version && docker compose version
Шаг 2: потом клонируем репозиторий и переходим в корневую директорию проекта:
git clone https://github.com/igorrosliakov-bitrix24/Bitrix24-Article2-Adding-4-Robots.git /opt/b24-robots cd /opt/b24-robots
Шаг 3: создаём и настраиваем переменные окружения:
cp .env.example .env nano .env
Что нужно заполнить для приложения на портале Битрикс:
VIRTUAL_HOST=https://bremenrobots24.site # ваш домен SERVER_HOST=http://api-python:8000 JWT_SECRET=сгенерируйте-длинную-случайную-строку CLIENT_ID=local.xxxxxxxx.xxxxxxxx # из настроек приложения в Битрикс24 CLIENT_SECRET=xxxxxxxxxxxxxxxxxxxxxxxx # из настроек приложения в Битрикс24 DB_NAME=appdb DB_USER=appuser DB_PASSWORD=пароль DB_ROOT_PASSWORD=root_пароль DATABASE_URL=postgresql://appuser:сильный_пароль@database:5432/appdb BUILD_TARGET=production NODE_ENV=production DJANGO_SUPERUSER_USERNAME=admin DJANGO_SUPERUSER_EMAIL=admin@bremenrobots24.site DJANGO_SUPERUSER_PASSWORD=сильный_пароль_admin ENABLE_RABBITMQ=0
В настройках есть параметры CLIENT_ID и CLIENT_SECRET. Взять их можно на портале Битрикс при регистрации нового приложения. Подробно об этом шаге можно прочесть в 1-й статье в разделе «Регистрируем приложение на портале Битрикс24».
Шаг 4: после этого нужно настроить NGINX. В нашем проекте это внешний вход в систему. Он нужен не просто как веб-сервер для хранения файлов, а как reverse proxy и SSL termination layer. То есть когда пользователь или Битрикс24 приходит на https://bremenrobots24.site, этот запрос принимает nginx. Дальше он решает, куда его отправить:
/→ во frontend./api/→ в Django backend./admin/→ в Django admin./static/→ отдаёт Django файлы статики напрямую.
Какие команды понадобятся:
mkdir -p infrastructure/nginx/certs mkdir -p infrastructure/nginx/certbot-webroot sed -i 's/YOUR_DOMAIN/bremenrobots24.site/g' infrastructure/nginx/nginx.conf
Это создаёт директории для сертификатов и ACME webroot и подставляет реальный домен вместо шаблона YOUR_DOMAIN. Зачем это нужно: в nginx домен и путь к сертификату завязаны на YOUR_DOMAIN, и пока мы его не заменим, nginx не знает, какой домен обслуживать.
Шаг 5: после этого стандартная настройка сервера закончена, и остаётся одна команда для деплоя:
./scripts/deploy.sh
Какие проблемы могут быть при деплое на разных этапах
На этом месте начались проблемы, потому что деплой никак не хотел сходиться. С этого места я дал агентам доступ к серверу и репозиторию, чтобы они сами смогли найти все проблемные места и решить их.
В какой-то момент я израсходовал все токены для Claude и перешёл на Codex. В итоге Codex довольно быстро нашёл ошибки, которые допустил Claude, исправил их и довёл приложение до рабочего состояния.
Вот основные этапы, на которые можно разделить тот процесс деплоя, который получился у меня. На всякий случай к каждому разделу я приложу краткое описание основных составных элементов — возможно, кому-то это окажется полезным.
Этап 1 — подготовка
Базовая вещь: приложение вообще должно запускаться на VPS по домену bremenrobots24.site. Это инфраструктурная работа: нужно поднять контейнеры, настроить nginx, получить SSL-сертификат и запустить Django + Nuxt.
Эту работу я описал по шагам выше в разделе «Первоначальная настройка».
Технические компоненты этапа:
Docker Compose поднимает несколько контейнеров как одно приложение.
nginx — веб-сервер, принимает запросы снаружи и проксирует их во frontend/backend.
certbot — программа, которая получает SSL-сертификаты от Let's Encrypt.
frontend — Nuxt-приложение, пользовательский интерфейс.
backend — Django API, которое общается с Битрикс24 и запускает роботов.
Этап 2 — запуск nginx
Довольно частая проблема, когда nginx-серверу нужен сертификат для старта, а для получения сертификата нужен уже работающий nginx.
Nginx читает конфиг при старте. В конфиге написано: «слушай порт 443 с SSL, используй сертификат из файла /etc/letsencrypt/live/domain/fullchain.pem». В нашей конфигурации nginx не запускался, если сертификат отсутствовал: в конфиге сразу был указан HTTPS и путь к файлам сертификата, которых ещё не было.
Сертификаты выдаёт сервис Let's Encrypt. Он делает это так: делает HTTP-запрос на порт 80 к нашему серверу для проверки. Если порт 80 не отвечает — отказывает в выдаче сертификата. Получается: сертификат нужен чтобы запустить nginx, а nginx нужен чтобы получить сертификат.
Как эту проблему решил Claude: перед запуском nginx создавался временный самоподписанный сертификат через встроенную утилиту шифрования openssl:
openssl req -x509 -nodes -newkey rsa:2048 \ -keyout privkey.pem \ -out fullchain.pem \ -days 1 -subj "/CN=domain.com"
Этот сертификат ненастоящий, то есть браузеры его не признают. Но nginx с ним стартует, и порт 80 становится доступен. В итоге certbot получает реальный сертификат, и nginx перезагружается с ним.
Технические компоненты этапа:
SSL-сертификат, который нужен для работы домена по защищённому протоколу https://.
self-signed cert — временный сертификат, чтобы сервер мог запуститься до получения настоящего.
Let's Encrypt — сервис, выдающий бесплатные SSL-сертификаты.
ACME challenge — способ, которым certbot доказывает, что домен действительно принадлежит серверу. Let's Encrypt выдаёт токен, и certbot должен разместить этот токен определённым образом, чтобы Let's Encrypt мог сделать запрос и найти его. Логика в том, что если ты можешь положить файл на сайт — значит, ты владелец домена.
Этап 3 — Битрикс-интеграция на бэкенде (неправильный вариант)
К этому шагу сервер, контейнеры и HTTPS уже работали. Но роботы в портале Битрикс24 не появились. В конце я попросил Codex проанализировать ошибки, допущенные в предыдущих этапах, и он починил приложение, но допустил архитектурную ошибку: перевёл установку на бэкенд.
Как рассуждал Codex:
Claude не сделал решающую проверку интеграции. Он не подтвердил по логам и живым API-вызовам:
вызывался ли /api/install
вызывался ли /api/robots/register
сработал ли bizproc.robot.add
сохранился ли токен Битрикс24 в базе
То есть система была технически запущена, но не было доказано, что достигнута бизнес-цель: работающее приложение в портале. Codex проанализировал состояние проекта и обнаружил, что регистрация роботов в проекте была архитектурно хрупкой. В чём это выражалось:
/api/install в views.py сначала только сохранял установку.
Сами роботы регистрировались отдельно через frontend install-page.
Обычное открытие приложения вело на главную страницу, а не на install-page, где происходит регистрация.
Для агента это выглядело так, что логика размазана между backend и frontend. Часть логики процесса установки жила на бэкенде, а часть на фронтенде. Чтобы убрать хрупкость установки, агент сделал несколько вещей:
Перенёс регистрацию роботов в backend
/api/install.То есть «Путь обработчика» при регистрации приложения в портале выглядел какhttps://bremenrobots24.site/api/install.Добавил fallback на главную страницу приложения.
Добавил кнопку повторной регистрации. Если автоматическая регистрация не проходила, на главном экране приложения можно вызвать её вручную:
После этого логика стала действительно намного надёжнее. Для регистрации роботов появились 3 варианта:
Либо install-hook сам зарегистрирует роботов.
Либо обычное открытие приложения сделает это позже.
Как запасной парашют, пользователь нажмёт кнопку вручную. В реальном проекте такое решение выглядит криво, но мы добавили его как демонстрацию возможностей и для отладки.
Технические компоненты этапа:
install hook — backend endpoint, который Битрикс24 вызывает при установке приложения.
OAuth token — токен доступа, с которым backend потом вызывает API Битрикс24.
bizproc.robot.add — метод Битрикс24 для регистрации робота.
health endpoint — техническая проверка, что сервер работает. Отвечает только на вопрос «жив ли backend», но не отвечает на вопрос «видит ли Битрикс24 роботов».
Этап 4 — Битрикс-интеграция на фронтенде (правильный вариант)
Проблема была в том, что установка Битрикс-приложений задумана иначе, как frontend wizard:
Битрикс24 открывает страницу
/install.frontend показывает шаги установки и progress bar.
Один из шагов вызывает backend
/api/install.Другой шаг вызывает
/api/robots/register.В конце frontend вызывает
installFinish().
После объяснения этой схемы агент вернул каноническую установку:
Во views.py
/api/installснова стал узким backend-шагом: он только сохраняет установку и auth-данные.В index.client.vue исчез автозапуск регистрации роботов и кнопка повторной регистрации.
Основным install-flow снова стал install.client.vue.
Этап 5 — финальные правки
В начале я не обратил внимания на то, что инструкции агента по установке приложения в бизнес-портал расходятся с тем, что написано в официальной документации.
Как должны выглядеть параметры установки:
При таких параметрах:
если Битрикс открывает
/install, запускаетсяwizardесли Битрикс открывает
/, открывается обычный indexесли Битрикс после завершения установки открывает backend endpoint, пользователь видит JSON
Что предлагал агент:
Из-за этого после возвращения установки на фронтенде появлялись разные симптомы:
В одном варианте после переустановки открывалась обычная главная страница, и в панели DevTools на вкладке Network были только
health/getToken, безinstallиregister.в другом варианте после завершения установки Битрикс открывал JSON
{"message":"Installation successful"}вместо UI приложения:
Для точной проверки я полностью удалил приложение из портала и создал заново с новыми токенами. На этот раз роботы зарегистрировались, и их можно было добавлять на этапы сделки:
Проверяем работу приложения в портале
После успешного деплоя и регистрации роботов я ещё раз прошёл путь проверки роботов. Я создал тестовый контакт, имя и номер телефона которого нужно было нормализовать:
После этого создал тестовую сделку, в которую добавил все нужные данные:
После запуска стадии, на которой стоят роботы, видно, что всё работает правильно. Это можно увидеть в логах:
И в карточках клиента или компании, у которых отформатированы ФИО, название и номер телефона:
Результат
Сейчас у нас есть стабильно работающее приложение 24 часа в сутки без необходимости локального запуска.
На локальной машине мы не устанавливали ничего, кроме Docker Desktop — все остальные зависимости уже были упакованы в контейнеры. Поэтому во время отладки появились только те баги, которые вызывал код и настройки самого проекта. Любой разработчик на любой машине получил бы те же самые проблемы, и решал бы их примерно так же.
Что будем делать дальше
В следующий раз будем испытывать AI-агентов как инструмент архитектурного анализа. Разберём существующий проект и попробуем добавить в него новые функции.
Содержание цикла статей про создание приложений с AI-агентами
Пишем первое приложение с AI-стартером, чтобы видеть прибыли и убытки
Добавляем в бизнес-портал Битрикс24 роботов для автоматизации
Что даёт воспроизводимая среда разработки и как развернуть контейнеры на VPS.