Локальный запуск

Workflow-движок распространяется как open source, и его можно полностью запустить локально — это самый быстрый способ его попробовать. Понадобятся установленные Docker и kind (Kubernetes in Docker): каждый запущенный сценарий выполняется в собственном поде локального k8s-кластера — тем же механизмом, что и в боевом окружении.

Быстрый старт

1. Создайте локальный kind-кластер:

   ./scripts/kind-dev-setup.sh

   Скрипт идемпотентен — его можно перезапускать повторно, например после изменений в коде раннера, чтобы пересобрать и перезагрузить его образ в кластер.

2. Скопируйте .env.example в .env в корне репозитория. Для чистого локального запуска можно ничего не менять — у каждого секрета (JWT_SECRET, CREDENTIALS_ENCRYPTION_KEY и т.д.) есть значение по умолчанию для разработки.

3. Поднимите стек:

   docker compose -f docker-compose.workflow.yml up –build

4. Откройте http://localhost:5175 и войдите как admin/admin (учётная запись создаётся автоматически при первом запуске backend’а) либо зарегистрируйте новый аккаунт со страницы входа.

5. Создайте проект, затем в нём — папку и документ типа «Функция»: задайте имя и тело функции.

6. Нажмите «Build & Run» на панели инструментов. Это скомпилирует все функции проекта и создаст под в kind-кластере для их выполнения — под очередью задач вида workflow-dev-<projectId> (её имя отображается на панели инструментов рядом с индикатором статуса, а также командой kubectl -n workflow get pods).

7. Запустите выполнение через CLI администратора Temporal:

   docker compose -f docker-compose.workflow.yml exec temporal-admin-tools \
   temporal workflow start --task-queue workflow-dev-<projectId> --type <functionName> \
   --workflow-id demo-1 --input '{}'

   Ход выполнения можно наблюдать в Temporal Web UI: http://localhost:8080.

8. Кнопка «Publish» переводит текущий код в стабильную версию (общую очередь задач workflow-<projectId>) — в модальном окне «Версии» доступны откат («Активировать») и остановка более старых версий («Остановить раннер»).

Из чего состоит стек

docker-compose.workflow.yml поднимает:

• самостоятельно размещённый сервер Temporal (с собственной базой Postgres) и его веб-интерфейс;
• отдельную базу Postgres для backend’а (проекты, папки, документы, пользователи);

• backend — сервис, который хранит проекты, компилирует функции и управляет запуском/остановкой подов выполнения через Kubernetes API;

• client — веб-редактор схем;

• activepieces — вспомогательный сервис для части интеграций (см. Интеграции).

Каждый опубликованный сценарий выполняется не отдельным процессом внутри контейнера backend’а, а собственным подом в Kubernetes — именно поэтому нужен локальный kind-кластер.

Известная особенность

При самом первом запуске docker compose up после (пере)создания сети falang-workflow-network контейнер backend’а иногда не успевает подключиться ко второй сети (kind) — в его логах будут постоянные ошибки вида getaddrinfo EAI_AGAIN app-postgres. Лечится одной командой:

docker compose -f docker-compose.workflow.yml restart backend

Повторно эта проблема не возникает, пока обе сети не пересоздаются заново.