Flow CLI

В рамках стандартной консольной утилиты yt существует специальный режим flow с набором команд для работы с Flow Pipeline. В этом разделе перечислены основные команды. Все актуальные опции каждой команды можно посмотреть с помощью команды --help.

Команда	Описание
`start-pipeline`	Запустить Pipeline
`stop-pipeline`	Остановить Pipeline через режим `draining`
`pause-pipeline`	Остановить Pipeline немедленно
`get-pipeline-state`	Получить текущее состояние Pipeline
`get-flow-view`	Посмотреть Flow View — описание всего пайплайна с точки зрения контроллера
`get-pipeline-spec`, `set-pipeline-spec`	Посмотреть/изменить текущую Spec. Требует остановки Pipeline
`get-pipeline-dynamic-spec`, `set-pipeline-dynamic-spec`	Посмотреть/изменить текущую DynamicSpec
`read-states`	Прочитать стейты пайплайна. Возвращает секции `key_states`, `partition_states`, `external_key_states`, `joined_external_key_states`. Фильтрация по `computation_id` / `partition_id` / `key` / `name` / `target`; `limit` применяется к каждой секции независимо. См. `TReadStatesArg` и `TReadStatesResponse` в справочнике
`delete-states`	Удалить стейты пайплайна. По умолчанию dry-run: возвращает счётчики совпавших строк, не удаляя их. Требует Stopped/Completed либо `force=true` на Paused. Удаляются только key/partition/manager-стейты; joiner-стейты не трогаются. См. `TDeleteStatesArg` и `TDeleteStatesResponse` в справочнике

Команды раннера напрямую в контроллер

Выкатывая пайплайн, раннер (flow_server или собранный на его основе бинарник пайплайна) отправляет контроллеру несколько команд: запрашивает состояние пайплайна, останавливает или ставит его на паузу, обновляет flow core target и спецификации, запускает пайплайн и снова ждёт нужного состояния. По умолчанию все они идут через RPC-прокси.

Если прокси не может подключиться к контроллеру, такая выкатка завершается ошибкой Cannot connect to pipeline controller leader, а контроллер пишет в лог, что подтверждение лидерства через прокси пропущено и до него доходит только раннер в прямом режиме. В этом случае включите прямой режим: раннер будет отправлять те же команды самому контроллеру.

Прямой режим включается блоком direct_controller_commands в конфиге раннера:

direct_controller_commands = {
    enabled = %true;
};

Настройки блока:

enabled — включает прямой режим; по умолчанию %false.
rpc_timeout — таймаут одной команды; по умолчанию 30 секунд, как у запросов через RPC-прокси.

Соединение с кластером остаётся прежним: им раннер читает адрес контроллера и по нему же контроллер проверяет учётные данные. Шифрование соединения с контроллером пока не поддерживается.

Ограничения:

Нужны те же права, что и на пути через прокси: read на пайплайн для запроса состояния и write для изменений. Раннер использует те же учётные данные, что и для кластера (YT_TOKEN, ~/.yt/token).
У раннера должен быть сетевой доступ к RPC-порту контроллера.
Прямой режим не заменяет проверку подписи прокси. Пока у контроллера require_proxy_signature = %false, любой хост с доступом к его RPC-порту выполняет команды без аутентификации, минуя проверки прямого режима. Открывайте порт только вместе с require_proxy_signature = %true.
Если bus_server контроллера не настроен на TLS, токен передаётся контроллеру по незащищённому соединению. Процесс пайплайна, работающий от имени владельца пайплайна, видит токены всех, кто пользуется этим режимом. Разрешите доступ к порту контроллера только нужным хостам и пользуйтесь путём через прокси везде, где он работает.
Прямой режим есть только у раннера. Лаунчеры SDK — например, Java-раннер — запускают flow_server с тем же конфигом, поэтому режим работает и через них, отдельной поддержки не требуется. У SDK компаньонов прямого режима не будет: команды пайплайну отправляет раннер. У yt CLI и UI его пока нет.

См. также

Справочник конфигураций

Обзор