Reputation: 563
Google Cloud Deploy supports multi targets by creating a child target. However the profiles configuration is a part of the pipeline config so during rendering the profiles go missing.
e.g. let us assume I have a web-server and a jobs-server that I want to deploy in parallel. The following config sort of works
apiVersion: deploy.cloud.google.com/v1
kind: DeliveryPipeline
metadata:
name: parallel-deploy-example
description: Parallel deploy Example
serialPipeline:
stages:
- targetId: all-servers
profiles: [profile1, profile2]
---
apiVersion: deploy.cloud.google.com/v1
kind: Target
metadata:
name: all-servers
description: Deploy all servers
multiTarget:
targetIds:
- web-server
- jobs-server
---
apiVersion: deploy.cloud.google.com/v1
kind: Target
metadata:
name: web-server
labels:
service-type: web server
description: staging web us-central1
run:
location: projects/something/locations/us-central1
---
apiVersion: deploy.cloud.google.com/v1
kind: Target
metadata:
name: jobs-server
labels:
service-type: jobs
description: jobs server
run:
location: projects/something/locations/us-central1
Now While I can pass profile1 profile2 to both servers I can't pass a profile specifically for web-server and a different profile for jobs server.
However when doing it serially since each step has a profiles array I can give them their own profile.
Is there some secret config I am missing or is this a limitation I have to live with.
Upvotes: 0
Views: 136
Reputation: 40
you are correct in that you cannot pass separate profiles to Cloud Deploy and have those independently applied on a per child target basis. The multi-target capability is intended to deploy the same application/job across multiple targets but not to concurrently coordinate deploy of independent services/jobs. If you need to configure the same service/job deployment across multiple child targets you can however adjust these definitions on a per child target basis using deploy parameters.
The above said, treating your service/job rollouts as two separate targets in a serial progression will support their independent delivery. One workaround to having these deployed concurrently would be to use an Automation.
In this approach, consider the following:
Serial progression: [target A (service - dev)] --> [target B (job - dev) --> [target C (service -staging)] --> [target D (job - staging)]
When creating a Release - you would have to coordinate an initial rollout for the release to both A and B targets at the same time. You can do so by creating a release using --disable-initial-rollout and then using the promote --to-target flag to deploy the service/job to A and B concurrently (two separate, but concurrent, release create calls).
However, as B is successfully deployed, you could use an Automation resource with two separate promoteRelease rules to automatically promote from B to (C AND D) at the same time. In this way, upon successful deployment to B automation will initiate forward successful deployments to the next successful 2 (or 'n') targets.
I hope this is of some aid!
Upvotes: 0