Представляем коллекцию Postman для API dbt Cloud: инструмент для масштабирования управления аккаунтами
❓ Для кого это: Это для опытных пользователей dbt Cloud, которые хотят расширить свои знания об API dbt с помощью интерактивной коллекции Postman. Мы рекомендуем углубляться в это только после того, как у вас будет прочное знание dbt + dbt Cloud. У вас есть несколько вариантов для изучения коллекции:
- получите актуальную версию коллекции через
.
- ознакомьтесь с документацией коллекции, чтобы узнать, как ее использовать.
API dbt Cloud имеет хорошо док ументированные конечные точки для создания, запуска и управления заданиями dbt Cloud. Но есть и другие конечные точки, которые еще не так хорошо документированы, но они чрезвычайно полезны для конечных пользователей. Эти конечные точки, предоставляемые API, позволяют организациям не только оркестрировать задания, но и управлять своими аккаунтами dbt Cloud программно. Это создает действительно интересные возможности для организаций по масштабированию их внедрений dbt Cloud.
Основная цель этой статьи — распространить информацию об этих конечных точках, пока документация еще создается, и показать вам, как их использовать.
Вы можете использовать этот пост в блоге как точку входа в эту коллекцию Postman, чтобы помочь вам автоматизировать ранее ручные задачи, такие как управление инфраструктурой аккаунта dbt Cloud, создание проектов dbt Cloud, подключений к базам данных и управление пользователями.
Пожалуйста, имейте в виду, что коллекция не является постоянно актуальной документацией. Мы активно разрабатываем и обновляем конечные точки API, используемые для взаимодействия с dbt Cloud, поэтому URL-адреса конечных точек и/или ожидаемые форматы запросов могут измениться. Каждая конечная точка в коллекции предоставляет возможности для комментариев, поэтому, пожалуйста, сообщайте нам там, если что-то выглядит неправильно.
С учетом всего сказанного, почему пользователям dbt стоит заботиться об автоматизации управления аккаунтами dbt Cloud?
Какие проблемы решает программное управление аккаунтами dbt Cloud?
При первом изучении dbt Cloud и работе в меньшем масштабе большинство конечных пользователей склонны предпочитать ручные, основанные на графическом интерфейсе рабочие процессы для создания и управления инфраструктурой своих аккаунтов. Многие из наших клиентов начинают с этого, но обычно они сталкиваются с этими узкими местами по мере увеличения количества заданий и проектов. Вот некоторые примеры узких мест, о которых я слышу от наших растущих клиентов.
- «Я трачу время на ручное прокликивание интерфейса для управления инфраструктурой, особенно после развертывания более чем нескольких проектов и сред.»
- «Я не уверен, что моя производственная среда настроена именно так, как задумано. Если новый член команды удалит или изменит что-то, мне придется устраивать пожарную тревогу, чтобы это исправить.»
- «Моя организация требует, чтобы я проводил любые изменения конфигурации среды через код-ревью и контроль версий.»
Мы обычно советуем нашим клиентам использовать API-запросы для автоматизации этих обычно ручных задач, и вам тоже стоит!
Заключительные мысли
Помимо повседневного процесса управления своими аккаунтами dbt Cloud, многие организации получают выгоду от возможности быстро реплицировать среды, экспериментируя с новыми функциями и шаблонами разработки dbt. Управление — еще одно преимущество управления инфраструктурой в коде, так как определения ресурсов могут быть подвержены контролю версий и проверке соответствующими командами до того, как изменения вступят в силу. Эти концепции занимают важное место в наших мыслях, когда мы стремимся предоставить дополнительные возможности нашим клиентам в их использовании dbt Cloud. Удачного использования API!
Ниже вы найдете серию примеров запросов — используйте их для ориентира или ознакомьтесь с коллекцией Postman, чтобы попробовать самостоятельно.
Приложение
Примеры использования коллекции Postman
Давайте рассмотрим несколько примеров, как эффективно использовать эту коллекцию Postman.
Миграция проектов dbt Cloud
Один из часто задаваемых вопросов от клиентов: «Как мы можем мигрировать ресурсы из одного проекта dbt Cloud в другой?» Часто они создают проект разработки, в котором пользователи имеют доступ к интерфейсу и могут вносить изменения вручную, а затем мигрируют выбранные ресурсы из проекта разработки в производственный проект, когда все готово.
Есть несколько причин, по которым это может понадобиться, включая:
- Вероятно, самая распространенная — это разделение сред разработки/тестирования/производства между проектами dbt Cloud, чтобы команды могли вручную строить в проекте разработки, а затем автоматически мигрировать эти среды и задания в производственный проект.
- Создание «стартовых проектов», которые они могут развернуть в качестве шаблонов для новых команд, осваивающих dbt с точки зрения обучения.
- Некоторые особенно заботящиеся о безопасности клиенты могут требовать, чтобы процессы контроля версий и управления проходили перед любыми изменениями в инфраструктуре, включая их аккаунты dbt Cloud.
Ниже мы показываем пример миграции среды и определения задания из проекта разработки в производственный проект. Обратите внимание, что это предполагает, что у вас уже настроены оба проекта. Вы можете продвинуть этот процесс автоматизации еще дальше, создавая новые проекты с подключениями к репозиторию и базе данных через API. Пожалуйста, обратитесь к коллекции для получения дополнительных деталей.
Прежде чем начать: Убедитесь, что вы получили свой API-ключ и добавили его в заголовок аутентификации ваших запросов.
Наш пример содержит следующие элементы:
Настройка
Создайте проект «разработка» и проект «производство» в dbt Cloud с помощью интерфейса Настройте подключение к хранилищу данных и подключение к репозиторию
Извлечение среды из проекта разработки
Вся эта информация доступна из API (см. коллекцию Postman), но вы также можете определить правильные идентификаторы для использования из URL, когда вы вошли в dbt Cloud:
- ID аккаунта: 28885
- ID проекта: 86704
- ID среды: 75286
Мы отправим GET-запрос на
https://cloud.getdbt.com/api/v3/accounts/28885/projects/86704/environments/75286/
Перенос среды в производственный проект
Мы берем ответ от GET-запроса выше и затем делаем следующее:
-
Настраиваем некоторые переменные для новой среды:
- Изменяем значение поля «project_id» с 86704 на 86711
- Изменяем значение поля «name» с «dev-staging» на «production–api-generated»
- Устанавливаем поле «custom_branch» на «main»
-
Отправляем POST-запрос, показанный ниже, на: https://cloud.getdbt.com/api/v3/accounts/28885/projects/86711/environments/
Тело запроса:
{
"id": null,
"account_id": 28885,
"project_id": 86711,
"credentials_id": 108731,
"name": "production–api-generated",
"dbt_version": "1.0.0",
"type": "deployment",
"state": 1,
"use_custom_branch": true,
"custom_branch": "main"
}
- Обратите внимание на ID среды, возвращенный в ответе, так как мы будем использовать его для создания задания dbt Cloud на следующем шаге
Извлечение определения задания из проекта разработки
Мы отправляем GET-запрос на:
https://cloud.getdbt.com/api/v2/accounts/28885/jobs/72025/
Перенос определения задания в производственный проект
- Настраиваем некоторые переменные для нового задания:
- Удаляем поля «created_at», «updated_at» и «is_deferrable». Логика отложенного выполнения выходит за рамки этого поста.
- Изменяем значение поля «name» на «production-run–api-generated»
- Отправляем POST-запрос, показанный ниже, на https://cloud.getdbt.com/api/v2/accounts/28885/jobs/
Тело запроса:
{
"execution": {
"timeout_seconds": 600
},
"generate_docs": false,
"run_generate_sources": false,
"id": null,
"account_id": {{account_id}},
"project_id": 86711,
"environment_id": 75296,
"name": "production-run--api-generated",
"dbt_version": null,
"execute_steps": [
"dbt build"
],
"state": 1,
"deactivated": false,
"run_failure_count": 0,
"deferring_job_definition_id": null,
"lifecycle_webhooks": false,
"lifecycle_webhooks_url": null,
"triggers": {
"github_webhook": false,
"git_provider_webhook": false,
"custom_branch_only": true,
"schedule": false
},
"settings": {
"threads": 4,
"target_name": "default"
},
"schedule": {
"cron": "0 * * * *",
"date": {
"type": "every_day"
},
"time": {
"type": "every_hour",
"interval": 1
}
},
"generate_sources": false,
"cron_humanized": "Каждый час",
"next_run": null,
"next_run_humanized": null
}
И мы закончили! Теперь у нас есть базовые механизмы для миграции объектов dbt Cloud.
Comments