:two: multicluster deployment Just modified my ...
# kubernetes
c
2️⃣ multicluster deployment Just modified my plan to do:
Copy code
---
clusters:
  - name: cluster1
    kubeconfig:
        secure: .....
  - name: cluster2
    kubeconfig:
        secure: .....
Now I just added in main a new config object and wrapped the entire deployment setup I had in a for each. Boom. Loop over clusters and go. Due to pulumi's routinues and all the magic going on I figured I'd do a dumb old loop instead of trying concurrent deployments, but looking for a sanity check.
Copy code
pulumi.Run(func(ctx *pulumi.Context) error {
  for _, cluster := range clusterList {
	cfgMap, err := configmap.ConfigMap(
				ctx,
				renderProvider,
				&configData,
				&appConfig,
				&sharedConfig,
			)
     err = ingress.NetworkingIngress(ctx, renderProvider, &configData, &sharedConfig)
     err = service.Service(ctx, renderProvider, &configData, &sharedConfig)
     //     etc....
	_ = <http://ctx.Log.Info|ctx.Log.Info>(fmt.Sprintf("finished processing cluster: %s", cluster.Name), &pulumi.LogArgs{})
    }
})
Make sense to do the same deployment this way on 2 clusters without concurrency or any other way you'd say is better? Multiple pulumi.Run or anything else you'd recommend? I love my experience overall, but it's a lot more complex initially than plain yaml, so I'm double check my approach here makes sense and is reasonable. Much appreciated!
So far it worked. It did expose the problem with clashing URN. I was trying to adhere to the naming convention others used with plain yaml and as a result found that naming with metadata is where problems come into play for this. I have to refactor to rely less on fixed naked which I prefer anyway, just gets more complex.
I think this extra complexity will solve helping prepare for blue green though, at least that's my guess.
q
Rather than have your Pulumi program reach out and deploy to all clusters, you could install the Pulumi Operator on each cluster and have it pull down a repo and deploy your stack that way. It's the more GitOps approach
c
Would it take the same exact Go Pulumi plan? How much of a shift is it from agent driven to operator? Not opposed to this but not certain about it yet. I'll reread docs soon on this more as I had looked on the past but it seemed a big shift from the approach I was taking.
Added follow-up related to unique URN's and using random here: https://github.com/pulumi/pulumi-random Thanks!