Команды используют RudderStack, агентную платформу клиентских данных, ориентированную на хранилища, для сбора, управления, унификации и активации своих данных о клиентах. Основное приложение RudderStack предоставляет командам по работе с данными все инструменты и конвейеры, необходимые для создания надежной основы данных вокруг их хранилища данных. Rudder Lookout делает все данные из этой основы доступными для маркетологов через приложение на базе ИИ для анализа, построения и активации аудиторий. Сегодня я сосредоточусь на этой основе, объяснив наш подход к инфраструктуре как коду (IaC) и причины, по которым мы поддерживаем как Terraform, так и наш собственный CLI.

Два пути для IaC с RudderStack

Конвейеры клиентских данных часто начинаются с простого подключения веб- или мобильного приложения к хранилищу, такому как BigQuery или Snowflake, но редко остаются в таком состоянии. Добавляются преобразования для обогащения, фильтрации или применения пользовательской обработки событий перед доставкой. Планы отслеживания, основанные на обширных каталогах данных, используются для проверки и отклонения событий на источнике. Настройки на уровне подключений настраиваются для управления тем, как каждый конвейер взаимодействует со своими подчиненными системами.

Конфигурация такого масштаба становится производственной инфраструктурой. Изменения требуют проверки и утверждения перед их применением. Конвейеры должны быть протестированы в промежуточной среде. Когда в производственной среде обнаруживается ошибка конфигурации, конвейеры должны быть возвращены к известной рабочей версии. Решение этой проблемы хорошо известно в отрасли и включает подход «инфраструктура как код» (IaC): определение конфигураций в файлах, фиксация этих файлов в системе контроля версий, такой как Git, и использование инструмента для применения изменений к каждой среде.

Terraform — это широко используемый инструмент для такого рабочего процесса, и у RudderStack уже много лет есть официальный провайдер Terraform. Мы по-прежнему привержены его поддержке и расширению его покрытия.

В то же время мы решили создать Rudder CLI, наш собственный инструмент IaC, наряду с нашим провайдером Terraform. Мы считаем, что специализированный инструмент может обеспечить лучший пользовательский опыт по сравнению с универсальным инструментом, таким как Terraform. Он может кодировать информацию, правила и рабочие процессы, которые было бы сложно смоделировать в Terraform.

В этой статье мы приводим три примера того, как мы используем это для улучшения опыта: отсутствие зависимости от файлов состояния и атомарные ассоциации ресурсов, проверка всей конфигурации конвейера и поддержка рабочего процесса разработки, который выходит за рамки простого применения конфигурации.

Преимущество CLI №1: Бэкенд — это состояние

Terraform требует файл состояния для отслеживания примененных изменений. Самая важная часть этого состояния — это связь между ресурсами, определенными в файлах конфигурации Terraform, и ресурсами, созданными в удаленных системах. Хотя состояние включает в себя больше информации, например, их последнюю известную конфигурацию, именно эта связь позволяет Terraform знать, какой ресурс обновить при изменении конфигурации и какой удалить при удалении соответствующего блока конфигурации.

Команды несут ответственность за это хранилище, обычно это корзина S3. И поскольку этот файл состояния критически важен для операций Terraform, он нуждается в резервном копировании, защите от повреждения и шифровании. Доступ к нему должен быть ограничен. Это добавляет командам накладных расходов на обслуживание, но есть еще одна опасность: изменения ресурсов никогда не могут происходить атомарно с изменениями их состояния. Если Terraform создает ресурс, но дает сбой до того, как запишет его в файл состояния, этот ресурс становится «сиротой».

Файл состояния имеет смысл для инструмента общего назначения. Terraform поддерживает широкий спектр систем и не может предполагать, что каждая система способна хранить связь между удаленным источником и его декларацией конфигурации.

Rudder CLI, будучи инструментом, специализированным для управления ресурсами RudderStack, избегает этой проблемы. RudderStack контролирует как CLI, так и API бэкенда, и может хранить эту связь нативно.

Каждый ресурс в нашем бэкенде получает свойство внешнего идентификатора (external id), которое Rudder CLI заполняет идентификатором, выбранным пользователем в файлах конфигурации. API, создающие ресурсы, получают этот внешний идентификатор в том же теле запроса, что и остальные свойства ресурса. Наш бэкенд сохраняет как ресурс, так и его связь с идентификатором Rudder CLI атомарно.

Rudder CLI получает инвентаризацию всех управляемых ресурсов, просто запрашивая у API те, у которых заполнен внешний идентификатор, и использует эти ответы для синхронизации. Нет необходимости во внешнем файле состояния, потому что API предоставляет все, что связано с состоянием, что нужно Rudder CLI. Без файла состояния нет опасности его удаления или повреждения.

Преимущество CLI №2: Проверки по всему графу ресурсов

Terraform поддерживает граф ресурсов, когда один ресурс использует свойство другого ресурса, обычно его удаленный идентификатор, и использует его для упорядочивания плана. Этот граф ресурсов не проверяется целиком. Провайдеры проверяют каждый ресурс независимо, поэтому они не проверяют, связан ли ресурс с несовместимым. Они не могут проверить такие ограничения, как уникальность свойства имени для одного и того же типа ресурса. Пользователи несут ответственность за написание конфигураций, которые удовлетворяют этим более широким ограничениям, и невыполнение этого требования проявляется как ошибка во время применения. Это может оставить среду частично синхронизированной до тех пор, пока конфигурация не будет исправлена и применена снова.

Rudder CLI проверяет весь проект на соответствие собственным правилам RudderStack, либо как часть планирования, либо как отдельная команда. Имея доступ ко всему графу ресурсов, он может применять правила, охватывающие несколько ресурсов. Например, рассмотрим назначение Google Ads, которое может быть подключено только к веб-источникам в режиме устройства. Проверка этого правила требует учета ресурсов источника, назначения и подключения. Конфигурация, определяющая подключение к источнику Android, сообщит об ошибке в соответствующей строке файлов проекта:

error[event-stream/connection/semantic-valid]: destination 'google-ads' (type 'googleads') does not support source 'android-app': source type 'android' is not among supported source types: web

--> connections/event-stream.yaml:9:7

9 | destination: "#destination:google-ads"

С Terraform это правило невозможно выразить: ресурс подключения имеет только идентификаторы подключенного источника и назначения, а не их типы и свойства. Та же ошибка приведет к сбою применения, потому что API RudderStack отклонит эту конфигурацию, требуя исправления и повторной попытки.

Преимущество CLI №3: Выход за рамки применения конфигураций

Управление конвейером данных — это не только вопрос создания правильных ресурсов. Рассмотрим довольно обычную настройку: Android-приложение отправляет события через источник потока событий, план отслеживания управляет ими, преобразование обогащает их, и все это доставляется в Snowflake. Настройка этого конвейера в рабочем пространстве RudderStack — это то, с чем хорошо справляются инструменты IaC, но это лишь часть работы. Правильное инструментирование приложения и проверка логики преобразования — это примеры задач, необходимых для поддержания работоспособности конвейера. Мы создаем Rudder CLI, чтобы помочь с большей частью этого рабочего процесса, а не только с синхронизацией. Проекты Rudder CLI фиксируют желаемое состояние конвейера и могут использоваться для гораздо большего.

Например, Rudder CLI предоставляет команды list для просмотра ресурсов, присутствующих в данный момент в рабочем пространстве. Его команда typer может генерировать типизированные клиенты на основе тех же конфигураций плана отслеживания, которые используются для создания конвейера, делая проект CLI единым источником истины как для состояния конвейера в рабочем пространстве RudderStack, так и для клиентов инструментирования, встроенных в приложение. Он поддерживает тесты преобразований, связанные с теми же конфигурациями тестов, которые можно использовать для проверки логики преобразования перед ее применением к рабочим конвейерам.

Это возможности, которые выходят за рамки провайдера Terraform, но при этом они используют те же файлы конфигурации. Это становится еще более важным в агентских рабочих процессах, где агент может анализировать настройку конвейера, просматривая файлы проекта и используя один инструмент для работы с этой информацией. Он может записывать конфигурации для источников, назначений и подключений, писать код преобразования вместе с тестами и выполнять их, составлять планы отслеживания и соответствующим образом инструментировать приложения — и все это работая над одним проектом CLI и используя один инструмент.

Где место каждого инструмента

Все три примера исходят из одного факта: Rudder CLI должен понимать только один API, поэтому он может кодировать вещи, для которых у универсального инструмента нет места. Это не аргумент против Terraform. Если ваша команда уже управляет своей инфраструктурой как кодом с помощью Terraform и хочет иметь единый рабочий процесс для всего этого, наш провайдер остается первоклассной частью нашего инструментария IaC, и мы продолжаем поддерживать и расширять его.

Rudder CLI лучше подходит, когда вы хотите, чтобы конфигурация вашего конвейера проверялась целиком перед применением, а один и тот же проект содержал вашу логику инструментирования и преобразования наряду с ресурсами, которые он определяет.