https://pulumi.com logo
Join Slack
Powered by
This message was deleted.
# typescript
s
This message was deleted.
w
Interpolate
is the function you probably want.
c
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?
w
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.
Can you clarify what you mean by "operational version integrity" in this context?
c
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…
Thanks… I get the provider argument… What I’m literally saying is that I cannot pass any arguments from the code when using ConfigGroup as documented…
Copy code
// services
const Services = new k8s.yaml.ConfigGroup("platform-service", {
        files: [ path.join("../common/yaml", "svc-*.yaml") ],
    },{dependsOn: my_SecretCreds}
);
It doesn’t even honor the 
dependsOn
clause. I’m just a lowly DevOps guy, trying to get our group’s code running polycloud. I’m just hoping for an undocumented feature or a workaround. Should I just pull this out into its own project:stack and do it as YAML? The goal is to be portable across AWS, GCS, and DigitalOcean… where the client base is, essentially.
7 Views
Open in Slack
PreviousNext
Powered by