Расширяем Deployment Manager через провайдеры типов

Прошло всего 2 недели после того, как я жаловался, что Гугловый Deployment Manager не поддерживает свежую версию гуглового же Cloud Functions API, как случайно наткнулся на фичу, которая может это обойти. Прикол в том, что если у вас есть RESTful CRUD API и OpenAPI спецификация для него, то такой апи можно зарегистрировать в DM в качестве провайдера типов (Type Provider) и пользоваться им так же как и любым другим типом. Cloud Functions API v1 полностью подходит под эти требования, так что его можно регистрировать и пользоваться свежайшим апи столько, сколько душе угодно.

Используем стандартные провайдеры типов

Если целая куча провайдеров, которые доступны прямо из коробки. Что интересно, они дают даже больше функциональности, чем стандартные типа ресурсов, с которыми, казалось бы, можно было создать всё, что душе угодно. Например, с командой gcloud beta deployment-manager types list можно наткнуться на провайдера gcp-types/compute-v1. У него есть целая уйма своих типов, многие из которых пересекаются со стандартными ресурсами, вроде виртуальной машины.

Но есть и что-то уникальное. Например diskTypes. Новый тип диска, конечно, не создашь, но в спецификации к compute-v1 можно подсмотреть, что у него есть метод list, который можно вызвать прямо из конфига для Deployment Manager:

Чтобы было что увидеть в консоли после запуска конфига, я добавил в него секцию outputs со ссылкой на имя первого попавшегося результата:

Это достаточно бесполезный пример, но кроме compute-v1 есть тот же cloudresourcemanager-v1, который кроме всего прочего может читать и устанавливать IAM полиси, а это уже очень круто.

Ну и для вышеупомянутого Cloud Functions тоже есть свой провайдер.

Добавляем новый провайдер типов

Как я говорил выше, если у нас есть RESTful API со спецификацией, то его можно зарегистрировать в качестве провайдера типов. Гугловый Dataflow API очень даже подпадает под эту категорию, так что почему бы и не попробовать. Тем более что по умолчанию в Deployment Manager нету ничего для работы с Dataflow.

Всего одна команда и:

Пыщ! Что-то добавилось. Посмотрим, какие типы мы теперь можем поиспользовать:

Много чего. Среди всего прочего мы теперь можем запускать шаблоны для Dataflow прямо из Deployment Manager. Круто ведь.

Создаём провайдера типа через.. провайдера типа

recurisonХотя Dataflow провайдер теперь и работает в моём GCP проекте, в других его всё ещё нет, и пока кто-то руками не повторит в них вышеописанную процедуру, ничего там и не появится. А делать что-то руками в современном Infrastructure as a Code — греховный, не джедайский путь.

Как насчёт такого способа: зарегистрируем-ка мы провайдера типов прямо из YAML конфигурации деплоймент менеджера. Попользуемся им и удалим, как надоест.

Так вот, один из дефолтных провайдеров типов в DM является… сам DM. То есть провернуть вышеописанную идею проще простого:

Запустим  эту штуку:

Блин, ну здорово же! Это деплоймент не оставляет следов, но если закомментить второй шаг, запустить деплоймент и посмотреть на доступных провайдеров типов, то там точно появится dataflow. Колдунство, да и только.

Мораль

Среди всех фич Deployment Manager эта — моя любимая. Есть что-то невероятно мощное в возможности добавить кастомный API в DM и менять вселенную прямо из него. Конечно, из крупных недостатков будет то, что при удалении деплоймента созданные им побочные эффекты не всегда удалятся вместе с ним. Но, возможно, есть какой-то крючок, на который можно повесить свой обработчик и заполнить сей пробел. Просто он мне пока не попался.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *