cool, thank you very much, back on track and checking things out

I'd love to see some Kubernetes examples, can you point me at some?

This week's Pulumi live stream is at 11am PDT, Wednesday 20th June, where @white-balloon-205 will walk through an introduction to multi-cloud with Pulumi. Hope to see you there.

Pulumni feels like nixops w/extended scope past operating system deployment. Lambda over SaaS/IaaS/PaaS. Very interesting. Big fan of nix.

🚢 https://noyaml.com is now a thing. 🚢

Great project, thanks for shipping this! My company has been developing(and using) a project extremely similar to Pulumi - which we're planning to open-source - because there wasn't anything else out there. A question that'll help us decide whether to push ahead or get behind Pulumi: The tool seems to be tied to your platform. Is there any way we can configure a generic object store for checkpoint state?

That is a question I had too. Having something that isn't the local filesystem out the box is definitely valuable, but only having a service is a non-starter, not least because sensitive data ends up in state unless you're doing something with the Terraform providers to prevent that.

dotnetwhen

Is it possible to use code to lookup references to existing infrastructure?

@blue-answer-29496 Yes - there are a variety of

.getXYZ

function available in the libraries which can be used to lookup existing resources. See for example https://pulumi.io/reference/pkg/nodejs/@pulumi/aws/ecs/#getCluster. You can see an example of using this sort of API here: https://github.com/pulumi/pulumi-aws-infra/blob/master/nodejs/aws-infra/network.ts#L94.

Nice

Can I create an EKS cluster and configure all my Kubernetes services currently or are there gaps

Yes - you can. EKS in particular is a bit of a beast to set up - but @microscopic-florist-22719 spent a bit of time on this last week and was planning on posting an example that can deploy a full EKS setup with a single

pulumi update

soon. Once you have that, you can deploy any Kubernetes services you want onto it easily by using

@pulumi/kubernetes

.

Sorry for all the questions. 😀 Is the idea for the cloud objects that they will eventually be like a lowest common denominator abstraction that works across clouds?

The

@pulumi/cloud

library in particular is designed to be high-level abstractions which could be created on multiple different cloud platforms. But that's just one kind of library that can be built. Things like

@pulumi/aws-serverlesss

and

@pulumi/aws-infra

provide helpful higher level abstractions that are still specific to AWS but making common patterns much easier to use.

We have an implementation of

@pulumi/cloud

for AWS currently, and are starting to work on Azure and GCP. If others are interested in helping there - let us know!

I have an open source application (Exceptionless) that I host but also people self host the application. I’m considering creating a Pulumi script to install it instead of a Helm chart, but I’m not sure if that’s good idea or not. What are your thoughts?

Sounds like a great place to use Pulumi! We've done a few ports of Helm charts ourselves as examples, and in general it's really simple to do, but then gives you a lot of flexibility in how you factor and reuse components. One example of this I really like is https://github.com/pulumi/examples/tree/master/kubernetes-ts-jenkins, which ultimately factors out the details of the Jenkins Helm chart into a resuable component which can be combined with other components into a larger application - and used with just:

import * as pulumi from "@pulumi/pulumi";
import * as jenkins from "./jenkins";

const config = new pulumi.Config("jenkins");
const instance = new jenkins.Instance("jenkins", {
    name: "jenkins",
    credentials: {
        username: config.require("username"),
        password: config.require("password"),
    },
    resources: {
        memory: "512Mi",
        cpu: "100m",
    }
});

/cc also @creamy-potato-29402 who has been doing a bunch of work in this area and probably has more thoughts as well.

Yeah I really love the idea of using code over yaml! I’m gonna try.

Is there a way to forcibly delete a project via the web UI? I accidentally removed the files locally when playing around and now have a bunch of orphaned stuff. The actual resources in AWS I deleted manually, though.

How does Pulumi handle configuring runtime environment variables? I couldn't find anything specific in the docs for this. I'm thinking specifically about the serverless side of things, but I guess it's not just limited to that.

Nevermind I just found this https://pulumi.io/reference/config.html#config-stack

Which leads to the next question, is there any way I could send runtime variables & secrets to a cloud specific storage option such as AWS Secrets Manager and then use that instead so that I'm not having decrypted secrets lying around in cloudformation stacks?

It'd be even better if that could be automated and if I could specify shims for my functions to auto-decrypt those on function startup

We have planned to make this pluggable, so you can use AWS Secrets Manager, Vault, etc. for secrets management, but have not yet done so. Note that if you run

pulumi config set ... --secret

, we will encrypt that config value using KMS, and a stack-specific application key, and store the encrypted result instead of plaintext. This is clearly weaker than storing in one of the above systems and doing decryption as late as possible at runtime, with full auditing of all accesses, but it is good enough for some users and some classes of passwords, tokens, and the like. I couldn't find the work item on our side to make this pluggable, so just filed https://github.com/pulumi/pulumi/issues/1547. This has come up twice in the past 24 hours, so I suspect we'll want to get this on the roadmap (...which we'll be publishing next week, by the way.)

Note also that you can of course already use those existing systems like AWS Secrets Manager or Vault directly from within Pulumi, instead of using Pulumi

config

settings. And in fact this is a place where you can really benefit from infra + code being managed together to provision and configure the Secrets Manager along with the code that uses secrets from it. The work @big-piano-35669 is referring to is to make this sort of workflow something you can use directly from the Pulumi config system, which will make it easier - but it's absolutely possible to use any of these systems with Pulumi today.

Is the AWS provider using Cloudformation underneath? I didn’t spot that but now the question from @big-soccer-75859 has me thinking!

I just assumed haha