This message was deleted.
s
This message was deleted.
b
We support this model via
renderYamlToDirectory
https://www.pulumi.com/blog/kubernetes-yaml-generation/ You can also use the Pulumi Kubernetes Operator for a Kubernetes native way
g
I often sit and wondering if this not really what I should be using Pulumi for, but I want to... I like the idea that the code-base is similar for other providers and k8s
I want to avoid thinking of jsonnet/kustomize/etc etc
I think one of my issues with Pulumi with render, @billowy-army-68599, is this weird hack I have to do:
Copy code
pulumi_state_temp=$(mktemp -d)
		cd $HOME
		${PULUMI_CMD} login file://$pulumi_state_temp
		cd -
		${PULUMI_CMD} stack init \
			--cwd projects/${ARGOCD_ENV_PULUMI_PROJECT_NAME} \
			${ARGOCD_ENV_PULUMI_STACK_NAME}
		${PULUMI_CMD} update \
			--cwd projects/${ARGOCD_ENV_PULUMI_PROJECT_NAME} \
			--stack ${ARGOCD_ENV_PULUMI_STACK_NAME} \
			--suppress-outputs \
			--yes
if Pulumi had a flag that could skip the entire stateful mode it would be nice..
As it sits today, I have to use a throw-away stack and/or local FS state
b
yeah there’s been discussions around using Pulumi for just authoring, but it’s not our roadmap
👍 1
g
The issue I have with the k8s operator: I have to choose between that and ArgoCD, and so far we want to keep ArgoCD since it's more generic (not just limited to Pulumi generating YAML).
I'm sure the k8s operator is awesome, but it's not in our use-case.
@billowy-army-68599 what are the Pulumi k8s operator limitations? can it be used for the AWS provider resources? Does Pulumi have something that offers the equivalence of say, Atlantis did with terraform (now terraform cloud)?
b
it can be used to provision any pulumi program
g
understood
the operator IRSA role (if AWS) would just have to have the right permission to deal with AWS resources, I presume?
b
and yes the pulumi service has deployments, similar to tf cloud (and some other exciting stuff launch next week 😉 )
yep! IRSA will allow you to run pulumi AWS stuff within the cluster
g
cool. Thanks Lee.
c
I am stuck on this exact same problem - I'm trying to bootstrap fluxcd with pulumi currently
but I keep wondering if this is all just a waste of effort - I'm already using pulumi configs that are in the same github repo as our helm charts
👀 1
can I just use the same pulumi that creates my gke cluster to install the yaml in other directories in this repo?
g
@creamy-guitar-8902 Yeah I am actually not even using the native Pulumi config (using a sops/YAML loader that creates pulumi.Output.secret()), and loading all our config from simple YAML files since I wanted to do true GitOps with SealedSecrets... It feels like Pulumi is pushing on their Operator and I think you have to buy into it to realize the full benefit. As Lee stated, there's no immediate plans to make Pulumi an authoring-only tool, whic his more of what I was hoping for with some of our k8s projects...... Might have to just use Jsonnet/Kustomize/or cdk8s for the time being for things I want to ship through ArgoCD....
It's a shame because I really wanted to take avantage of all the other providers (like the AWS, Azure, etc) and use a set of common code libraries across our projects...
l
Do you mean, you want a way to (re)generate the output without any prior state every time?
I also ended up with an approach like the script you posted earlier
I’ve been considering GitOps more, but I’m not sure i’m fully sold yet (Since Pulumi does all of the reconciling I need anyway). I like the transparency of having the rendered manifests as an artifact/in version control, especially since we dynamically render a lot of resources based on the stack’s config. But you also lose the benefit of Pulumi’s diffing (delegating to another tool like Argo or Flux). Are there any major drawbacks with the
renderYamlToDirectory
and temporary state directory approach that you’ve found, or is it just the ergonomics?