Can you use a manually created

aws.lambda.Function

object with a cloud.API endpoint?

im getting this error when using a specific stack.

$ pulumi preview

Previewing update of stack 'XXXXXXXX/XXXXXXX-dev'
error: could not find plugin for provider 'XXXXXXXX-dev::XXXXXXX::pulumi:providers:kubernetes::default'

looks like it was bumped a version higher than the other envs

is the provider version specific?

Yes.

You must npm install that version

I performed a parameter update on a cloudformation stack, the update failed, and the

pulumi update

did not fail.

If I pass a

name

to a

new aws.cloudformation.Stack

and a CF stack with that name exists, will it use that CF stack?

i think i mucked up my snapshot file somehow. i’m getting an error:

failed to verify snapshot: resource  ....  refers to unknown provider ...

- but as far as i can tell, the provider is defined in the snapshot

i was trying to move a resource between aws regions by changing the provider and things went haywire & i haven’t been able to recover & fear i may have made matters worse messing around

any suggestions on how to go about fixing it?

ooook - i just moved the provider resource higher up in the snapshot file & that fixed it

surrounding code seems to interleave indexing providers & derefencing them, so they need to be topologically sorted

Yeah we originally didn't encode dependencies explicitly so we couldn't topsort things ourselves. So we assume the file is ordered. @incalculable-sundown-82514 now that we capture dependencies, should we revisit this? It's definitely subtle!

still not quite back to a stable state - seems like one last issue

i’ve got a pending delete that i want to discard

i removed the entry from the pending_operations, but that seemed to do nothing

then i removed the

"delete": true

and got an assertion failure:

aaaah looks like i have a duplicate resource in the snapshot file

probably a hand-edit screw up

pulumi update

is finally successful again, but i’ll admit, i have zero confidence that this snapshot file matches reality 😛

hi guys, brand brand new to pulumi, just installed it setting up first app.. having trouble conceptualizing how the project/stacks should be organized. is it a separation thing between stacks like database vs server (persistent vs ephemeral) or is it the entire application infra prod/dev type thing, any good images or docs on this topic?

Hello! I am learning Pulumi and I am trying to find if it’s possible to share some data between stacks. Is it possible? And to avoid XY problem, I would like to have one stack that defines resources like GCP Project and Google Kubernetes Engine cluster in that project and another stack that would deploy some K8S resources to that GKE cluster (but would also need some more GCP resources like static IP addresses and DNS records). I have a single cluster where I would like to have multiple teams deploying their apps to GKE. Is there a guide how stacks should be structured/designed for bigger deployments/projects?

@gifted-island-55702 @quiet-wolf-18467 coming back to your question earlier: So we use GCP and GKE in my company too. We run about 15-20 micro-services / apps, mostly written in nodejs, some in Python and Java, on that stack. Just a small warning: This whole GCP / GKE / pulumi stuff is currently not in production, but we’re able to to spin up entire dev environments and plan to bring this to production in the next months. In general our pulumi code structure is like this: 1. we have a single

infrastructure-shared

repository which contains a few pulumi programs which setup the base infrastructure that is shared by many apps. this includes for example: GCP projects, GKE clusters, cluster-wide addons (i.e. cert-manager, kube external-dns). This repo contains multiple pulumi programs for different gcp projects and each of them usually just a single stack instance. They share a few parameters / constants which are defined as simple JS / TS files under a

common

directory at the project root. 2. we have a single

pulumi-util

repo which contains an internal reuse npm library (important: this is just a library, not a pulumi program itself) that codifies a couple of common pulumi patterns. E.g. it contains a common dockerfile to build a nodejs app, it contains a

SolvvyApp

(solvvy is the name of my company) class which creates a docker Image, Deployment and depending on the configuration also a Service or Ingress resource. This is basically a much enhanced version of https://github.com/pulumi/examples/blob/master/kubernetes-ts-guestbook/components/k8sjs.ts#L9 . It also contains a few utilities to deal with GKE particularly. 3. We have multiple application repositories (7 or so) which contain the application code for those aforementioned 15-20 services (some of those repos are a mono-repo, so contain multiple services). In each of those app repos we have a subdirectory

infra

which makes heavy use of our own pulumi-util library to build and deploy the app to the clusters that have been setup prior to that via the

infrastructure-shared

repository. One important side note is that we even setup some core infrastructure like redis and rabbitmq inside the app repositories when they are not shared by most of the apps (which is the case for redis and rabbitmq which are really only used by one application each). Typically the code inside each app repository is very brief because it reuses abstractions from our pulumi-util library. E.g. this is how the code in one of our apps

infra

directory:

import { SolvvyApp } from '@solvvy/pulumi-util';

const app = new SolvvyApp({
  buildContext: __dirname + '/../',
  service: {
    internalHttpPort: 1337,
    expose: 'VPCInternal'
  },
  env: {
    NODE_ENV: 'k8s'
  }
});

export const url = app.url;

This little code builds a docker image, pushes it to gcr, creates a k8s service of type load balancer which creates a GCP internal TCP load balancer, assigns a dns entry via kube external-dns. etc. The application name is inferred by reading the package.json under buildContext (solvvyapp contains that logic) and the environment name (which gets translated to a namespace) is inferred from the last segment of the stack name (the string after the last ‘-’ in the stack name).

Now you may be wondering how the target gke cluster is determined: Every app has to be have two gcp / gke config entries in their stack config: The target gcp-project and the name of the target-cluster. E.g. it may look like this:

config:
  gcp:project: my-gcp-project
  '@solvvy/pulumi-util:cluster': my-gke-cluster

This information is used by the pulumi-util library to dynamically create a pulumi k8s provider onto which the application will be deployed. Concretely the following code is used to create a k8s provider from the the cluster name: https://gist.github.com/geekflyer/b78adab2667d8526a1dd593bc5c844bf#file-gke-ts SolvvyApp under the hood simply calls

getK8sProviderFromInferredCluster()

(https://gist.github.com/geekflyer/b78adab2667d8526a1dd593bc5c844bf#file-gke-ts-L29) to get a k8s provider. Those gke utilities basically make use of the

getCluster

function of pulumi https://pulumi.io/reference/pkg/nodejs/@pulumi/gcp/container/#getCluster to read in some stuff of existing cloud resources (that have been created by another program / stack). In general pulumi has a lot of those

get<Something>

functions to read in parameters of some cloud resource that has been defined elsewhere. I’m honestly not sure how one can use stack outputs from one pulumi program as inputs to another (without manual copy and paste) and It’d be curious on some example for this too (@big-piano-35669?)

And as for authentication: We basically rely on the developer having gcloud installed and having the right IAM permissions to do whatever he has to do. In CI we also use gcloud via a service account that we activate via

gcloud auth activate-service-account --project <project_of_service_account> --key-file=-

Many of the things of our pulumi-util library are actually pretty generalizable to other GCP + GKE users and once this library is more stable we may also open source parts of it.

Small bonus - this is an internal post I wrote to explain the philosophy behind this project structure:

At Solvvy we use pulumi to deploy and manage our infrastructure E2E.

Generally speaking we can divide our infrastructure into two kinds of “Resources”:

1. Low Level and Shared Resources, i.e. VMs, Kubernetes Clusters, Cluster-Wide services or addons (i.e. gitlab-runner, cert-manager, external-dns)

2. App Resources, i.e. for a service like the accounts-api. Typically each app is comprised of resources like a docker image and runtime container, some networking config, a service account, possibly a DNS name and optionally some app specific backing services, i.e. rabbitmq or redis.

Each application may have unique requirements for infrastructure, use unique libraries / frameworks and have an independent deployment lifecycle. Therefore we try to build a model where the app-specific infrastructure code (i.e. rabbitmq for app1, redis for app2) is held in the same location as the application, concretely in the repository of the application itself (i.e. github repo of app1). Only resources which are very common or shared between apps by technical necessity are defined in a central infrastructure-only repository (i.e. a kubernetes cluster). One advantage of this code organization is that in order to introduce a new app / service (or fit the infrastructure to new requirements of a drastically changed app), one has to only create a single Pull Request / Commit in the app repository and not an additional dependent PR in the shared infra repo. Philosophically speaking the idea behind putting infrastructure code into the app repo is to empower developers to develop and run their application end-to-end, delivering on the original goals of a “DevOps” culture vs. relying on strict division of labor and inefficient dependencies between Dev ←→ Ops in the old world. Pulumi and kubernetes are two very important ingredients to achieve this - they basically provide a common, approachable platform for consuming, building and sharing abstractions on top of low level infrastructure. I.e. Pulumi uses a general purpose language like TypeScript and npm libraries for defining infrastructure (vs an infrastructure-only DSL like Terraform’s Hashicorp Configuration Language) and with kubernetes you don’t need to be a bash + tmux superhero just to see the logs of all your app instances. This makes creating and managing infrastructure much more approachable for the average developer.