Автор: Прошло всего 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:
|
1 2 3 4 5 6 7 8 |
resources: - name: 'list-disks' action: 'gcp-types/compute-v1:compute.diskTypes.list' properties: zone: us-central1-f outputs: - name: 'firstTypeName' value: '$(ref.list-disks.items[0].name)' |
Чтобы было что увидеть в консоли после запуска конфига, я добавил в него секцию outputs со ссылкой на имя первого попавшегося результата:
|
1 2 3 4 5 6 7 |
gcloud deployment-manager deployments create test-deployment \ --config types.yaml # ... # NAME TYPE STATE ERRORS INTENT # list-disks gcp-types/compute-v1:compute.diskTypes.list COMPLETED [] # OUTPUTS VALUE # firstTypeName local-ssd |
Это достаточно бесполезный пример, но кроме compute-v1 есть тот же cloudresourcemanager-v1, который кроме всего прочего может читать и устанавливать IAM полиси, а это уже очень круто.
Ну и для вышеупомянутого Cloud Functions тоже есть свой провайдер.
Добавляем новый провайдер типов
Как я говорил выше, если у нас есть RESTful API со спецификацией, то его можно зарегистрировать в качестве провайдера типов. Гугловый Dataflow API очень даже подпадает под эту категорию, так что почему бы и не попробовать. Тем более что по умолчанию в Deployment Manager нету ничего для работы с Dataflow.
Всего одна команда и:
|
1 2 3 4 |
gcloud beta deployment-manager type-providers create dataflow \ --descriptor-url='https://dataflow.googleapis.com/$discovery/rest?version=v1b3' # Waiting for insert [operation-1537586774524-5766d5181c062-8a80b066-d2437132]...done. # Created type_provider [dataflow]. |
Пыщ! Что-то добавилось. Посмотрим, какие типы мы теперь можем поиспользовать:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
gcloud beta deployment-manager types list --provider dataflow # ... # types: # - projects # - projects.templates # - projects.locations # - projects.locations.templates # - projects.locations.jobs # - projects.locations.jobs.debug # - projects.locations.jobs.workItems # - projects.locations.jobs.messages # - projects.jobs # - projects.jobs.debug # - projects.jobs.workItems # - projects.jobs.messages |
Много чего. Среди всего прочего мы теперь можем запускать шаблоны для Dataflow прямо из Deployment Manager. Круто ведь.
Создаём провайдера типа через.. провайдера типа
Хотя Dataflow провайдер теперь и работает в моём GCP проекте, в других его всё ещё нет, и пока кто-то руками не повторит в них вышеописанную процедуру, ничего там и не появится. А делать что-то руками в современном Infrastructure as a Code — греховный, не джедайский путь.
Как насчёт такого способа: зарегистрируем-ка мы провайдера типов прямо из YAML конфигурации деплоймент менеджера. Попользуемся им и удалим, как надоест.
Так вот, один из дефолтных провайдеров типов в DM является… сам DM. То есть провернуть вышеописанную идею проще простого:
|
1 2 3 4 5 6 7 8 9 10 11 |
resources: - name: 'register-dataflow' action: 'gcp-types/deploymentmanager-v2beta:deploymentmanager.typeProviders.insert' properties: name: 'dataflow' descriptorUrl: 'https://dataflow.googleapis.com/$discovery/rest?version=v1b3' # DO YOUR STUFF WITH DATAFLOW - name: 'unregister-dataflow' action: 'gcp-types/deploymentmanager-v2beta:deploymentmanager.typeProviders.delete' properties: typeProvider: '$(ref.register-dataflow.name)' |
Запустим эту штуку:
|
1 2 3 4 5 6 7 |
gcloud deployment-manager deployments create pav-test --config types2.yaml # The fingerprint of the deployment is r1Kb5jHwGKnEFy5g5Y3nWA== # Waiting for create [operation-1537587612269-5766d8370b9c9-17a790e6-3444937a]...done. # Create operation operation-1537587612269-5766d8370b9c9-17a790e6-3444937a completed successfully. # NAME TYPE STATE ERRORS INTENT # register-dataflow gcp-types/deploymentmanager-v2beta:deploymentmanager.typeProviders.insert COMPLETED [] # unregister-dataflow gcp-types/deploymentmanager-v2beta:deploymentmanager.typeProviders.delete COMPLETED [] |
Блин, ну здорово же! Это деплоймент не оставляет следов, но если закомментить второй шаг, запустить деплоймент и посмотреть на доступных провайдеров типов, то там точно появится dataflow. Колдунство, да и только.
Мораль
Среди всех фич Deployment Manager эта — моя любимая. Есть что-то невероятно мощное в возможности добавить кастомный API в DM и менять вселенную прямо из него. Конечно, из крупных недостатков будет то, что при удалении деплоймента созданные им побочные эффекты не всегда удалятся вместе с ним. Но, возможно, есть какой-то крючок, на который можно повесить свой обработчик и заполнить сей пробел. Просто он мне пока не попался.
