I am using the k8s.yaml.ConfigFile (and ConfigGroup) to pass standard kubernetes YAML declarations/deployments… This is desirable for polycloud portability. At the same time, I’d like to declare variables… like the microservice image version number and have them pass with the Custom Resource so that I can centralize environment/version changes… Any guidance on being able to use something like this in a YAML:

image:<http://ghcr.io/organization/microservice:${RELEASE_ID}|ghcr.io/organization/microservice:${RELEASE_ID}>

called by a ConfigFile or ConfigGroup

const

via TypeScript?

Interpolate

is the function you probably want.

My Pulumi project is an AWS:TypeScript project…. When I pass in a…

new k8s.yaml.ConfigFile(…

and its associated parameters. it seems Pulumi drops into an isolated virtual terminal session using my local

kubectl

executable and its current ‘kube’ context. The YAML that is executed, is executed as a raw YAML file. The Pulumi TypeScript environment, variables, and declarations (e.g. interpolation, dependsOn, etc) don’t seem to be valid in the

ConfigFile

and

ConfigGroup

custom resource… I can write an edit for each of the cluster deployments, but that means I still need to revisit the source YAML files to ensure that I maintain operational version integrity.. I’d like to do this in a single step, even if it is initially more difficult. Does that make any sense?

I'm not entirely sure I follow tbh. Though, I want to throw in some documentation into the mix:

By default, Pulumi will use a local kubeconfig if available, or one can be passed as a provider argument in the request.

With the

kubeconfig

available, Pulumi communicates with the API Server using the official Kubernetes client-go library, just like

kubectl

does.

From https://www.pulumi.com/registry/packages/kubernetes/installation-configuration/ So if you don't want to use kubectl, you can pass in a Kubernetes

provider

as a resource option and the HTTP API will be used instead. IIRC ConfigFile is for raw YAML, and you can create instances of

Deployment

,

Service

, etc. if you need dynamic values. If you really need to use ConfigFile with dynamic values, you can get a little crazy: in TypeScript, you can read in your YAML, parse it, template in your values, and write it out to disk again in a temporary file. Then, point your

ConfigFile

resource to the temp file.

I mean that my PRODUCTION ENVIRONMENT has an image with the correct version number, whether that image is in the TypeScript project or the YAML code that is brought in via ConfigFile and ConfigGroup… If I get a manual deployment edit script running or interpolation apply and then the YAML files in the repo have a different version, any subsequent

Pulumi up

will revert… Now, granted… One should never do an up on a PROD environment… BUT. elimination of potential is also a goal…