Roopak Venkatakrishnan
Roopak Venkatakrishnan

Reputation: 563

Using profiles with multi target deploys

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

Answers (1)

S. Bogdan
S. Bogdan

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

Related Questions