AI Platform Docs

Эта инструкция подготавливает новую рабочую станцию для локальной разработки Платформа ИИ. Среда dev-local работает в отдельном Kind-кластере и не использует текущий Kubernetes context рабочей станции.

Требования к рабочей станции

Нужны:

работающий Docker с доступными 4 процессорными ядрами, 12 ГиБ оперативной памяти и примерно 30 ГиБ свободного места;
Kind версии 0.32.x;
Garden версии 0.14.20;
Helm версии 3.x или новее;
kubectl, Python 3 и uv версии 0.11.x;
curl и jq для проверок состояния.

Устанавливайте инструменты по официальным инструкциям:

Общая инструкция Garden может установить более новую версию. После установки переключитесь на версию, закреплённую для композиции:

garden self-update 0.14.20

Проверьте версии:

docker version
kind version
garden version
kubectl version --client
helm version
python3 --version
uv --version
curl --version
jq --version

Расположение репозиториев

По умолчанию вспомогательный скрипт ожидает соседние рабочие каталоги:

ap/
├── ap-deploy/
├── agent-platform/
└── langflow/

Репозитории agent-platform и langflow содержат разные части реализации одного продукта Платформы ИИ. Репозиторий ap-deploy описывает их совместную среду.

Создание Kind-кластера

Сначала убедитесь, что кластер с требуемым именем ещё не существует:

kind get clusters

Создайте каталог kubeconfig и кластер:

mkdir -p "$HOME/.kube"

kind create cluster \
  --name ap-dev-local \
  --kubeconfig "$HOME/.kube/ap-dev-local" \
  --wait 5m

Проверьте соединение:

kubectl \
  --kubeconfig "$HOME/.kube/ap-dev-local" \
  --context kind-ap-dev-local \
  get nodes

Имя кластера, контекст и путь kubeconfig являются частью контракта среды:

Параметр	Значение
Кластер	`ap-dev-local`
Контекст	`kind-ap-dev-local`
Kubeconfig	`~/.kube/ap-dev-local`

Garden использует эти значения явно. Это защищает от случайного развёртывания в кластер, выбранный в обычном ~/.kube/config.

Подключение рабочих каталогов

В общей конфигурации исходные репозитории закреплены полными Git SHA. Для локальной разработки замените их локальными рабочими каталогами:

cd ap-deploy
python3 scripts/link_local_actions.py --check
python3 scripts/link_local_actions.py
garden get linked-repos --env dev-local

Скрипт проверяет адрес удалённого репозитория Git, показывает ветку, SHA и наличие незакоммиченных изменений. Затем он записывает локальные соответствия действий Garden в игнорируемый файл .garden/local-config.json. Изменяемые действия приложений связываются с рабочими каталогами, но immutable carrier platform-lfx-wheel-image получает отдельный локальный detached worktree точно закреплённого коммита из Git-базы соседнего Langflow. Доступ к удалённому репозиторию для этого не нужен, а provenance остаётся согласованным с Runtime lock.

Если рабочая станция использует согласованный промежуточный удалённый репозиторий вместо прямого доступа к Sfera, укажите его явно:

python3 scripts/link_local_actions.py --bridge-remote mac

Этот режим не переносит изменения и не обновляет адрес удалённого репозитория Git. Он только разрешает использование выбранного рабочего каталога. Закреплённый commit LFX входит в историю Langflow develop. Если helper его не находит, обновите локальный develop до актуального composition baseline. Отдельный перенос Git-объектов не является частью рабочего цикла.

Проверка конфигурации

До первого развёртывания выполните статические проверки:

garden validate --env dev-local
garden get linked-repos --env dev-local

Первое развёртывание

Выберите минимальную требуемую точку входа:

# Target langflow: Low-code IDE и его зависимости
garden deploy langflow --env dev-local --yes

# Target agent-platform: другие компоненты и их зависимости
garden deploy agent-platform --env dev-local --yes

# Оба набора компонентов, но без тестовых данных
garden deploy all --env dev-local --yes

Тестовые данные для первого запуска не обязательны. Если для проверки нужны готовые пользователи и агенты Платформы ИИ, выберите явный fixture target; базовый runtime поднимется как его зависимость:

garden deploy agent-platform-fixtures --env dev-local --yes

Холодный запуск может занять продолжительное время из-за загрузки образов и первой сборки.

Доступ с рабочей станции

После успешного развёртывания оставьте в отдельном терминале:

cd ap-deploy
garden run dev-local-edge-forward --env dev-local

Действие поддерживает два точных перенаправления локальных портов и восстанавливает их после замены Pod шлюза. Прямые перенаправления портов приложений не входят в поддерживаемый путь.

Проверьте адреса:

curl -fsS http://ide.localhost:18086/config.js >/dev/null
curl -fsS http://docs.localhost:18086/health/ready
curl -fsS http://api-gw.localhost:18085/agent-registry/health/ready | jq

Остановка терминала сочетанием Ctrl-C завершает только перенаправление портов. Рабочие нагрузки продолжают работать в Kind.

Возврат к закреплённым исходным версиям

Чтобы отключить все локальные соответствия и снова использовать Git SHA из общей конфигурации:

garden unlink action --all
garden get linked-repos --env dev-local

После отключения список локально связанных репозиториев должен быть пустым. Для следующей команды Garden потребуется доступ к закреплённым Git-версиям либо их локальный кеш.

Полный сброс среды

Удаление точного Kind-кластера удаляет все рабочие нагрузки, постоянные тома и локальные данные:

kind delete cluster \
  --name ap-dev-local \
  --kubeconfig "$HOME/.kube/ap-dev-local"

Не используйте эту команду как обычный способ восстановления. Сначала убедитесь, что выбран именно одноразовый кластер ap-dev-local и что его данные больше не нужны.

Первичная настройка dev-local