Just curious, do you (Pulumi folks) see the use of...
# general
h
Just curious, do you (Pulumi folks) see the use of CD tools like Harness or Spinnaker to take over the deployment of applications as complementary? Do you feel that Pulumi can handle those tasks just as well and as such there is no need for those tools? Or are they services you can see Pulumi integrating with?
h
As an outsider: Harness looks like another k8s/helm product? So useful in it's own realm, but pulumi has more flexibility. Spinnaker looks like it might have more flexibility? It's not super clear how it defines infrastructure or what it can/can't do?
I am looking forward to a pulumi service: manages deployment environments, integrates with gitub/etc, gives a web interface to pulumi CLI commands, etc
b
I’m not on k8s, but I can tell you that my application deployments currently consist of entering a new version number in a Pulumi config and running
pulumi up
.
I like it so far.
h
yeah, i should try pulumi with gitlab's environment features (especially the feature deployment configurations). Problem is permissions--pulumi effectively needs to run as super-root
like, that's a lot of trust on a third-party service
b
Definitely. I use an on-site CI server for that reason.
h
like, even when I wrote my CI/CD for SaltStack (SpiroFS), it only gave the server permissions to just upload new state, and that's still scare af
b
I wish it was easier to give Pulumi a more limited permissions set (i.e: you can create anything, but you can’t read or touch any resources that weren’t created by you.). But that is very hard if not impossible to express in IAM (I haven’t used the others much.)
h
yeah.... the user/resource/permissions model makes that impossible unless each resource has an owner (from what I've seen, neither AWS or GCP have this concept)
b
you can sort of using tags and conditions
but it gets messy fast
c
The way we’re handling it via GitOps. So you can use whatever tool you want, but it’s deployment operation should be limited to changing a value in Pulumi.production.yaml for example. In our case,
linio:appRevision
. So the tool (in our case Jenkins) clones our infrastructure repository, makes the appropriate change, commits and pushes it up. This triggers another build, this time in the infrastructure repository that actually handles the deployment. If you follow this, you can have pulumi running on a separate server than the one doing your CI for testing and such.
It can be much more locked down, but still be permissive to avoid having to deal with all of the permissions.
h
yeah, but that mostly just hides your godbox
and my point of the problem of pulumi-as-a-service is that you're trusting a 3rd party to be your godbox (this is the same problem that SaltStack has)
c
I’m not saying to use a third party, my suggestion is to have an “on-premise/on-cloud” private CI server such as Jenkins or whatever run pulumi, and use whatever other application wherever it is that you want it to be.
h
(for the record, I don't consider the single-point-of-failure problem to be that big of a deal for most people--your pulumi/salt server is control plane, not application serving, so if it goes down, it only effects your engineering, not customers)
oh, right
that's easy enough (use drone/jenkins, cirrus has a "bring your own infra" option, i consider this a major feature of gitlab ci, etc)
h
Ah sorry, wasn't getting notifications. Let me catch up lol
Good insights. I like the idea of GitOps. Have any of you used the Github actions for Pulumi?
c
I refuse to due to it being a PITA to configure in my opinion.
Configuring it for a hundred repos does not seem fun.
h
Good point. Wonder if there is an easier way to configure it like via an API?
c
There may be, not sure given that actions is in beta. If the API isn’t there now, it may be there tomorrow after the live stream.
h
Also, same problem: Do you trust github with the root of your entire infrastructure?