It’s been just s few weeks since I complained that Google’s Deployment Manager (DM) doesn’t support its own latest Cloud Functions API, when I accidentally found an alternative way to use it. Thing is that if you have a RESTful CRUD-like API and OpenAPI specification for it, you can register it as DM’s type provider and use it almost like any other type from inside of a YAML configuration. Cloud Functions API v1 does have such specification, so in fact I could use it with DM.
Using default type providers
There’s whole bunch of type providers available by default. Surprisingly, they provide way more functionality than regular resource types do. For instance, running gcloud beta deployment-manager types list
will show me that among the other things, I have access to gcp-types/compute-v1
type provider. There’s bunch of regular compute resource types, sure, but this type provider also have, for example, diskTypes
. I can’t create a new disk type, but diskTypes
has list
method, which I can call right from Deployment Manager’s config:
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)' |
I also added outputs
section with the reference to first found result, so when configuration gets deployed, there’s something to see in the output:
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 |
This might look useless (and it is), but instead of compute-v1
we could’ve used another default type provider: cloudresourcemanager-v1
. Among many other things it knows how to get and set IAM policies, and that is very, very powerful.
Adding a new type provider
As I said before, if you have a RESTful CRUD API with OpenAPI specification, it can be used as a type provider. Dataflow API is just like that, and that’s a perfect candidate for becoming a new provider, because out of the box DM can’t do anything about Dataflow at all. API specification is available right at the home page, so just in one command:
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]. |
Ta-daaam! Let’s check what types does it have:
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 |
Lots of them. One of them will even let you to launch Dataflow templates directly from Deployment Manager. Something that DM can’t do any other way.
Creating type provider by type provider
Even though Dataflow type provider is available for my GCP project now, unless I repeat installation steps elsewhere, I can’t expect it will be available anywhere else. This means that in order to create a deployment configuration that uses Dataflow, someone must manually register the type first. And it goes without saying that this is not the Jedi way.
How about that: let’s register a type provider from Deployment Manager itself, and then delete it once we finished using its types. Wouldn’t that be cool?
One of default DM type providers is a DM itself, so that deployment-manager deployments create
actually can be turned into action: gcp-types/deploymentmanager...insert
and delete
:
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)' |
If we try to run this:
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 [] |
Cool, isn’t it? This deployment leaves no traces, but if you comment out the deletion step, you could easily see that the Dataflow type provider indeed was there.
Conclusion
Among the all Deployment Manager features I saw so far, the ability to use and to add new type providers is probably the coolest one. If I can register a new type from inside of DM and use that type afterwards, I hardly can see what DM couldn’t do. I could create and configure custom resources, call external APIs, implement complex setup logic – I could do lots of things. The only and probably the main downside of type providers is that unlike regular types, deleting the deployment won’t always undo the side effects it introduced. There might be some hooks to use for custom cleanup, but I haven’t came across any of them yet. Other than that it’s incredibly powerful feature.
Must needed, saved my time.
I am trying to do the same for secret manager(type provider), facing a authentication error. Can u post a blog on this.