Pulumi Blog: Laura Santamaria

Using Kubernetes Arch Templates with Poetry and Python

Laura Santamaria — Wed, 07 Dec 2022 00:00:00 +0000

When building with Kubernetes for the first time, we often need to stand up a lot of infrastructure just to get to the point of having a base to build an application. Let’s explore how we can wire together two of our architecture templates to generate a base for a web application running on Kubernetes on Google Cloud with Python and Poetry.

A primer on microservices

To work with Kubernetes, you’re generally following a microservices architecture. In short, here’s how to think about a microservices architecture: Each logical component of your application is its own individual process acting as a closed box that defines what data must come in and what data is delivered on the other end—what’s known as a service. Services communicate with one another via APIs or similar small interfaces, and each service addresses one part of your business logic inside your application.

In a typical, very basic web application set up in a generic microservices architecture, you might have a data store, a backend, and a frontend (a user interface, or UI). In practice, you might have multiple backends and data stores to address multiple activities like logging in, running a shopping cart, delivering shipping updates, and more.

To ensure all of these services work together, an orchestrator like Kubernetes ensures each service is running and healthy, is connected to the others, and runs as expected.

A typical Kubernetes architecture

A Kubernetes cluster is a collection of one or more machines (either virtual or bare-metal) called nodes that host groups of containers, with each group containing multiple copies of a microservice. These groups of containers are called pods. And then, to connect and expose those pods to one another and the world, we add in services.

For our system that we’ll build today, we’re going to have a cluster running on Google Kubernetes Engine (GKE). We’ll create a namespace on that Kubernetes instance, which will hold all of our Kubernetes app resources. We’ll have a deployment that takes the configuration we need for NGINX (a ConfigMap) and spins up a pod holding the containers running that NGINX server. Then, we’ll have a service that exposes the ports so we can access our NGINX server from anywhere.

Start with templates

We’re going to build our entire architecture starting with two templates: Our GKE template and our Kubernetes web app template. Learn more about our new architecture templates.

This will be a bit different than our usual workflow. Generally, we here at Pulumi prefer to stand up different stacks for each type of infrastructure (so one project with one or more stacks for the Kubernetes cluster and then one project with one or more stacks for the web application). However, in this case, let’s explore together what happens if we’re want to have it all go up together as one project and stack while keeping the code in different files.

First, create a new directory to hold all of our project files, and add app and infra directories inside this root directory.

$ mkdir k8s-templates && cd k8s-templates
$ mkdir app
$ mkdir infra

In the infra directory, we’ll add the GKE template first. We’re using the --generate-only flag to avoid creating the default virtual environment and the various extra stack information since we’re using Poetry and will be running everything from the root directory later:

$ cd infra
$ pulumi new kubernetes-gcp-python --generate-only

Accept all of the standard default values, except give your Google Cloud project name here instead of the default.

In the app directory, we’ll add the web app template:

$ cd ../app
$ pulumi new webapp-kubernetes-python --generate-only

When it asks you for a project name in the app directory, give it the name app-mi-k8s. Otherwise, accept all of the default values (using your Google Cloud details).

And now, the real fun begins!

Putting it all together

We’re going to use Poetry instead of the default virtual environment as we’re going to be working in a number of different directories that all need the same virtual environment and dependencies. In the root of the project, let’s initialize a Poetry project. We’ll need to define all of the dependencies from the application and infrastructure requirements:

$ cd ../ # if you need to go back to your project root
$ poetry init
# In the dynamic generation of dependencies, add pulumi, pulumi-gcp, and pulumi-kubernetes.
# Otherwise, fill in the other pieces as you would normally.

Then install the dependencies:

$ poetry install

Now, we can pull the metadata file for Pulumi in:

$ touch Pulumi.yaml
$ cat infra/Pulumi.yaml > Pulumi.yaml
$ touch Pulumi.dev.yaml

And do a quick cleanup of the Pulumi.dev.yaml file:

<root>/Pulumi.dev.yaml

config:
 namespace: fake-ns
 replicas: 1
 gcp:project: <your-project>
 gcp:region: <your-region>

Since we’re running on GKE, we need to define a different namespace than default. I used fake-ns.

We’ll need to modify the Pulumi.yaml file to remove the virtual environment:

<root>/Pulumi.yaml

name: k8s-combo-infra
description: A Python program to deploy a Kubernetes cluster and application on Google Cloud
runtime: python

And now we can set up our new __main__.py file! Create a new __main__.py file in the root of the repo, and add this code:

<root>/main.py

from pulumi import export as pulumi_export
from pulumi import Output
import app.__main__ as app
import infra.__main__ as infra_code

infra = infra_code

kubeconf = infra.cluster_kubeconfig
app_infra = kubeconf.apply(
 lambda val: app.create_app(kubeconfig_val=val)
)

pulumi_export("endpoint_url", Output.unsecret(app_infra))

We do need to make a couple small changes to the app/__main__.py file. We need to

wrap the code in a callable function so we can use that apply() call in the root file,
add a custom provider to use the right kubeconfig settings,
pass that provider context to all of the resources, and
get the endpoint from our app:

<root>/app/main.py

import pulumi
import pulumi_kubernetes as kubernetes


def create_app(kubeconfig_val):
 # Get some values from the Pulumi stack configuration, or use defaults
 config = pulumi.Config()
 k8s_namespace = config.get("namespace", "default")
 num_replicas = config.get_float("replicas", 1)
 app_labels = {
 "app": "nginx",
 }

 # NEW: Create a provider that consumes the upstream kubeconfig
 new_provider = kubernetes.Provider(
 "app_provider",
 kubeconfig=kubeconfig_val,
 namespace=k8s_namespace
 )

 # Create a namespace
 webserverns = kubernetes.core.v1.Namespace(
 "webserver",
 metadata=kubernetes.meta.v1.ObjectMetaArgs(
 name=k8s_namespace,
 ),
 opts=pulumi.ResourceOptions(provider=new_provider)
 )

 # Create a ConfigMap for the Nginx configuration
 webserverconfig = kubernetes.core.v1.ConfigMap(
 "webserverconfig",
 metadata=kubernetes.meta.v1.ObjectMetaArgs(
 namespace=webserverns.metadata.name,
 ),
 data={
 "nginx.conf": """events { }
 http {
 server {
 listen 80;
 root /usr/share/nginx/html;
 index index.html index.htm index.nginx-debian.html
 server_name _;
 location / {
 try_files $uri $uri/ =404;
 }
 }
 }
 """,
 },
 opts=pulumi.ResourceOptions(provider=new_provider)
 )

 # Create a Deployment with a user-defined number of replicas
 webserverdeployment = kubernetes.apps.v1.Deployment(
 "webserverdeployment",
 metadata=kubernetes.meta.v1.ObjectMetaArgs(
 namespace=webserverns.metadata.name,
 ),
 spec=kubernetes.apps.v1.DeploymentSpecArgs(
 selector=kubernetes.meta.v1.LabelSelectorArgs(
 match_labels=app_labels,
 ),
 replicas=num_replicas,
 template=kubernetes.core.v1.PodTemplateSpecArgs(
 metadata=kubernetes.meta.v1.ObjectMetaArgs(
 labels=app_labels,
 ),
 spec=kubernetes.core.v1.PodSpecArgs(
 containers=[kubernetes.core.v1.ContainerArgs(
 image="nginx",
 name="nginx",
 volume_mounts=[kubernetes.core.v1.VolumeMountArgs(
 mount_path="/etc/nginx/nginx.conf",
 name="nginx-conf-volume",
 read_only=True,
 sub_path="nginx.conf",
 )],
 )],
 volumes=[kubernetes.core.v1.VolumeArgs(
 config_map=kubernetes.core.v1.ConfigMapVolumeSourceArgs(
 items=[kubernetes.core.v1.KeyToPathArgs(
 key="nginx.conf",
 path="nginx.conf",
 )],
 name=webserverconfig.metadata.name,
 ),
 name="nginx-conf-volume",
 )],
 ),
 ),
 ),
 opts=pulumi.ResourceOptions(provider=new_provider)
 )

 # Expose the Deployment as a Kubernetes Service
 webserverservice = kubernetes.core.v1.Service(
 "webserverservice",
 metadata=kubernetes.meta.v1.ObjectMetaArgs(
 namespace=webserverns.metadata.name,
 ),
 spec=kubernetes.core.v1.ServiceSpecArgs(
 ports=[kubernetes.core.v1.ServicePortArgs(
 port=80,
 target_port=80,
 protocol="TCP",
 )],
 selector=app_labels,
 type="LoadBalancer"
 ),
 opts=pulumi.ResourceOptions(provider=new_provider)
 )

 # Export some values for use elsewhere
 pulumi.export("deploymentName", webserverdeployment.metadata.name)
 pulumi.export("serviceName", webserverservice.metadata.name)
 return webserverservice.status.apply(lambda val: val.load_balancer.ingress[0].ip)

Now that all our changes have been made, let’s try running it! We’ll need to prepend poetry run to the commands, unless you choose to switch to the Poetry shell ahead of time:

$ poetry run pulumi stack init dev
$ poetry run pulumi stack select dev
$ poetry run pulumi up

And up they all go! Note that this takes a while, so don’t panic!

output

Previewing update (dev)

View Live: https://app.pulumi.com/nimbinatus/k8s-combo-infra/dev/previews/fe73460a-a846-475c-9a69-23626e56b4e4

 Type Name Plan
 + pulumi:pulumi:Stack k8s-combo-infra-dev create
 + ├─ gcp:compute:Network gke-network create
 + ├─ gcp:compute:Subnetwork gke-subnet create
 + ├─ gcp:container:Cluster gke-cluster create
 + ├─ gcp:serviceAccount:Account gke-nodepool-sa create
 + └─ gcp:container:NodePool gke-nodepool create


Outputs:
 clusterId : output<string>
 clusterName : "gke-cluster-dd00d9f"
 endpoint_url: output<string>
 kubeconfig : output<string>
 networkId : output<string>
 networkName : "gke-network-e0ce7fb"

Resources:
 + 6 to create

Do you want to perform this update? yes
Updating (dev)

View Live: https://app.pulumi.com/nimbinatus/k8s-combo-infra/dev/updates/109

 Type Name Status
 + pulumi:pulumi:Stack k8s-combo-infra-dev created (915s)
 + ├─ gcp:compute:Network gke-network created (21s)
 + ├─ gcp:compute:Subnetwork gke-subnet created (11s)
 + ├─ gcp:container:Cluster gke-cluster created (682s)
 + ├─ pulumi:providers:kubernetes app_provider created (0.17s)
 + ├─ gcp:serviceAccount:Account gke-nodepool-sa created (1s)
 + ├─ kubernetes:core/v1:Namespace webserver created (0.52s)
 + ├─ gcp:container:NodePool gke-nodepool created (125s)
 + ├─ kubernetes:core/v1:ConfigMap webserverconfig created (0.32s)
 + ├─ kubernetes:core/v1:Service webserverservice created (193s)
 + └─ kubernetes:apps/v1:Deployment webserverdeployment created (144s)


Outputs:
 clusterId : "projects/pulumi-development/locations/us-central1/clusters/gke-cluster-6cc9507"
 clusterName : "gke-cluster-6cc9507"
 endpoint_url: "35.224.177.197"
 kubeconfig : [secret]
 networkId : "projects/pulumi-development/global/networks/gke-network-68b9493"
 networkName : "gke-network-68b9493"

Resources:
 + 11 created

Duration: 15m17s

If you CURL the endpoint, you get the default NGINX page that tells us the webserver is ready to go:

$ curl $(pulumi stack output endpoint_url)
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

Finally, if you’re done with the cluster, don’t forget to pull it down so you don’t get charged!

$ poetry run pulumi destroy -y

If you run into an issue where the cluster gets deleted before the various app resources (the namespace, the service, etc.) get removed, you may get an error that you can’t finish destroying the stack. Because the cluster is already gone, the Kubernetes provider can’t access it to update the status of the various app resources. So you’ll need to remove those resources from your state file as they were removed with the deletion of the cluster:

$ poetry run pulumi state delete urn:pulumi:dev::k8s-combo-infra::kubernetes:core/v1:Namespace::webserver --target-dependents

Then, refresh and destroy the rest of the resources, including the outputs:

$ poetry run pulumi refresh -y
$ poetry run pulumi destroy -y

If you want to try this out, head over to this example repo to explore the code and pull it down to run yourself. Don’t forget to create a Pulumi account first!

If you want to explore the other templates we have available for you, head to our templates page to explore.

Introducing Pulumi Architecture Templates

Laura Santamaria — Wed, 19 Oct 2022 10:59:37 -0500

🚀 Deploying cloud infrastructure is hard. Getting the architecture right from the start can be time-consuming. What if you could skip the hassle and start with prebuilt, best-practice templates?

📢 Pulumi Architecture Templates let you scaffold cloud infrastructure instantly with a single command. Whether you’re launching a serverless app on AWS, a container service on GCP, or a Kubernetes cluster on Azure, Pulumi gives you ready-to-use templates to get started faster.

➡️ Let’s dive in and see how these templates simplify cloud deployments.

Best Practices for Common Architectures

While Pulumi allows you to define any architecture for any cloud, we often get asked for opinionated architectures to get started with different cloud-based scenarios. To meet this need, we’ve started building templates around best-practice architectures like a serverless architecture on Google Cloud or a container service architecture on AWS. To give a sense of what these templates are like, let’s explore the serverless template for Google Cloud, which uses Cloud Storage and Cloud Functions to deploy a small application that tells the current time.

Google Cloud Functions Example

There are a lot of additional components to add to any infrastructure on modern clouds, including roles created through access management. The Google Cloud Serverless Application template defines a number of necessary components:

A storage bucket
An Identity Account Management (IAM) binding for the bucket
A Google Cloud Folder custom component to sync a local folder to the bucket (so you don’t have to create individual objects for each file in a directory!)
Another storage bucket
A bucket object to hold the function app code
A Cloud Function
Another IAM member to run the Function
An object in the bucket to hold some configuration values

Deployments Made Simpler

Using this template (or any of the other templates, for that matter), you can create a new Pulumi project with the pulumi new command. The template’s creation steps will now ask for all of the necessary configuration values for this template. No more deployment errors because you forgot to define your Google Cloud project with pulumi config set!

$ pulumi new serverless-gcp-python
This command will walk you through creating a new Pulumi project.

Enter a value or leave blank to accept the (default), and press <ENTER>.
Press ^C at any time to quit.

project name: (serverless-app)
project description: (A serverless web application on Google Cloud Platform)
Created project 'serverless-app'

Please enter your desired stack name.
To create a stack in an organization, use the format <org-name>/<stack-name> (e.g. `acmecorp/dev`).
stack name: (dev)
Created stack 'dev'

gcp:project: The Google Cloud project to deploy into: fake-proj-1
gcp:region: The Google Cloud region to deploy into: (us-central1)
appPath: The path to the folder containing the functions to be deployed: (./app)
errorDocument: The file to use for error pages: (error.html)
indexDocument: The file to use for top-level pages: (index.html)

Pulumi Templates vs Manual Setup

Feature	Pulumi Architecture Templates	Manual Setup
Preconfigured Best Practices	✅ Yes	❌ No
Multi-Cloud Support	✅ AWS, GCP, Azure	❌ Typically single-cloud
Faster Deployments	✅ One command setup	❌ Manual coding required
Scalability	✅ Easily extensible	⚠️ Needs custom scripts
Infrastructure-as-Code (IaC)	✅ Pulumi-native	❌ Requires manual IaC setup

Test Templates Yourself

There are already a number of templates built, and more are coming over the next weeks and months. We’ll be exploring more templates in detail here on the blog and on PulumiTV in the future. Review all the currently available architecture templates at our templates page. We’d love to hear what you think!

Upgrade Strategies: An Introduction for IaC

Laura Santamaria — Mon, 07 Mar 2022 09:59:56 -0600

When you’re working with infrastructure, you’re inevitably going to need to upgrade or update that infrastructure. Whether it’s an operating system update or a desire to get CPU or memory upgrades, you will need the ability to pick resources and change them as necessary. In the past, this kind of upgrade would be done on the basis of individual resources, with each one being updated and checked either by hand or programmatically before moving onto the next resource. If you’ve ever done a database migration or if you ever did the recommended way of upgrading your computer’s operating system including all of the backup steps, you’re familiar with this process. Stand up the new resource. Check everything works. Move over the data. Check again. Tear down the old infrastructure. In a cloud computing environment, though, you’re often dealing with hundreds or thousands of resources, and doing one-by-one replacement is a nightmare that takes ages. However, there are other options, many borrowed from the application deployment world, that we have available to us because we write infrastructure as code.

Generally, there’s a few strategies for replacing something in a cloud computing environment. You’ll often hear about them as deployment strategies. These strategies generally differ based on the order of operations: Do you create a new resource before you delete the old one? Do you replace some and pause to gather data? Do you YOLO and just toss everything out and build new? All of these strategies are worth considering depending on the needs of your situation. A production system likely needs to maintain uptime, or the amount of time a system is available to the end user, to meet service-level agreements (SLAs), which might include an availability promise such as a promise of 5 nines (99.999%) of uptime. In that case, a YOLO strategy won’t be very acceptable, will it?

As many of these deployment strategies initially came from the application world, we can’t just use the same deployment strategies exactly as they appear for an application because there’s a bit more going on under the hood. We need to consider what we’re building and where we are on our stack. If we have multiple instances of our application running on identical containers, for example, we can treat the containers a bit differently than, say, the single load balancer in front of all of the containers or the node underneath a single-node Kubernetes cluster.

To illustrate all of the following deployment scenarios, let’s imagine we have a system where an application is deployed on some infrastructure. What the application is doesn’t really matter; we’re going to focus on the infrastructure here. We’ll pick a simple situation: There’s a security update for one of your pieces of infrastructure.

Big Bang

Let’s say the infrastructure you’re working with is a large number of virtual machines (VMs) that are running an outdated, insecure version of an operating system. If you weren’t concerned about uptime or the stored data on those systems, you could certainly just tear them down and stand up new ones—this situation could reflect that perhaps you’re working with a development environment that is ephemeral and isn’t in use right now, or you don’t have any load just yet. Some folks refer to this kind of upgrade strategy as a “big bang” strategy, though folks who run data centers would likely say that the big bang strategy still at least required testing and careful consideration of data transitions and you would rarely completely wipe the original system before replacing it with another. If you’re wondering where this upgrade strategy came from, it was originally used in non-cloud-native systems where you likely didn’t have the hardware available to run other deployment strategies. In these cases, you would have maintenance windows and change processes, and the whole process was mapped out well ahead of time. This kind of fast switchover, especially with little to no testing, really is not a good idea for a cloud-native or cloud-based production environment, and it’s frowned upon if you’re working with a cloud-based environment that others are also using. There’s so many better options than scheduling maintenance windows and ripping apart systems when you have the capability to stand up parallel virtual hardware.

Blue-Green Deployments

Now, let’s say that instead of tearing down and then standing up new VMs, you instead were to create an almost identical environment with the new operating system, test it under load, and then transition your traffic over and wait for success before tearing down the old version. This is known as a blue-green deployment, and it’s a fairly popular strategy. A blue-green deployment is, in short, a create-check-delete process. You may have heard this strategy called “red/black deployment” or “a/b deployment.” The rationale behind using “blue” and “green” as names originally comes from needing easy names that didn’t have any kind of connotation of one group of systems being “better” than the other (e.g., “red” is the same color as alert lights, so don’t you want to keep the “black” deployment?). So you certainly can name it whatever you’d like in your company, but the concept is the same. The “blue” environment is currently running. To upgrade, you stand up an almost identical environment with the upgrade you want to perform. That environment is your “green” environment. Then, you run any test that you can against that green environment to ensure it’s ready. Finally, you switch your traffic over to the green system and monitor for any issues. Once you’re sure the environment is stable and can handle the load of your normal traffic (typically measured in hours to days depending on when you made the switch and what your traffic patterns demonstrate), you tear down the blue environment.

Note that, while a blue-green deployment traditionally is standing up and tearing down entire systems, you don’t have to do an entire system if you can do a subsystem instead so long as that subsystem is self-contained. The idea behind the rollout strategy is the same: You use a load balancer to transition traffic from one complete system to another. Since we’re talking infrastructure, the more traditional version needs to be modified by thinking of subsystems. For example, if you’re replacing the load balancer as well, you would stand up the green load balancer, point it at the rest of the blue deployment, make the switch of the traffic to the green load balancer, and then complete the move from the rest of the blue deployment to the green deployment. Then, finally, the blue load balancer and the rest of the blue deployment can be decommissioned.

Canary Deployments

Now, a blue-green deployment isn’t the only upgrade strategy, and it’s not always the best one for a cloud-native system. There’s also a strategy called a canary deployment. In a canary deployment, you stand up new infrastructure and move traffic over in small increments, such as 5% of overall traffic. That small slice of traffic is considered a “canary,” an indicator of failure or success of such a move. While it’s often used in application deployment as a way to gather user feedback on an application change, this strategy is also useful for infrastructure as it highlights issues that only occur under true, random load before they become a problem for a full deployment. This strategy is fairly popular in microservices architectures and with platforms like Kubernetes as it’s much easier to implement than with more traditional, VM-based systems.

Rolling Deployments

The final upgrade strategy we’ll consider is called a rolling deployment. In a rolling deployment, each element of a system is replaced one at a time, with each new instance being checked before decommissioning and removing the old instance. That check is called a health check on some platforms, and the basic idea is that the deployment tool sends a request to the new element and waits for a response that indicates the system is functional and responsive as expected. Once the health check on the new element clears, the old one is removed, and the deployment tool “rolls” to the next element in the system being updated. We find this one in many Kubernetes-based applications, and it can work well for cloud-native infrastructure, as well.

In the next article in this series, we’ll explore how these three strategies are similar and different for infrastructure as code, and why you would use one over the other. Stay tuned!

In the next parts of the series, we’ll try these deployment strategies with Pulumi, exploring how to use code to define each kind with a test system. Watch this space!

Meanwhile, while you’re waiting, we did a few videos on this topic over at PulumiTV, like this one on blue-green deployments with Pulumi and Python on GCP.

Six Things You Might Not Know About the Pulumi Service

Chris Smith — Mon, 24 Jan 2022 00:00:00 +0000

As a reader of this blog, you’ve probably heard of the Pulumi Service, the default state-management backend of the Pulumi CLI. If that’s the case, there’s also a good chance you’ve heard of a number of the Service’s key features, like helping you organize your projects and stacks, collaborate with others with the help of organizations, or handle sensitive data securely with built-in support for encrypted secrets.

What you might not know, though, is that we’re adding new features to the Pulumi Service all the time, and that some of these features can be fairly easy to miss. So in this post, we’ll highlight a handful of the features you might not be aware of, and that we think make it even easier to manage your infrastructure with Pulumi.

Let’s get started!

Feature 1: Stack Tags

The first thing we’ll cover is the Pulumi stack tags feature. Stack tags are key/value pairs that are associated with your Pulumi stack. You can use them for any number of purposes, from keeping things organized to even flagging whether or not it’s okay for a script to reclaim the stack’s resources.

While you can create, edit, and remove stack tags using the Pulumi CLI (see pulumi stack tag), you can also do so in the Pulumi Console:

Once set, you can quickly filter stacks on your organization’s Projects tab as well.

Feature 2: Link Updates to your CI/CD pipeline

Another helpful thing the Pulumi Service can do is link the Pulumi stack update to the CI/CD job or run that was used to perform it, as well as to the specific source commit:

When Pulumi updates a stack, it will store some information about the local machine state, such the current git SHA if the stack resides in a git repository. It is with this data that the Pulumi Service links to relevant services where possible.

If you’re curious to know all of the information Pulumi has for a stack update, you can navigate to the Environment tab for that update:

Feature 3: Custom Update Messages

One of the most useful pieces of additional data stored with each update is the message property. By default, Pulumi will use whatever the latest git commit message is. But did you know you can customize that message from the command line?

By passing the --message (or -m) flag to pulumi up, you can provide a custom update message, which can help explain the context for why you made a particular infrastructure change:

$ pulumi up --message "Release the hounds\!"

Feature 4: Viewing Resource Changes

Another thing you might have missed is that the Pulumi Service supports multiple views for a stack update’s logs.

The standard view mimics the Pulumi CLI’s output. However, you can switch to the Diff or Diagnostic views, too.

The Diff view displays all of the properties of modified resources, along with their previous/updated values. This can be helpful when trying to understand exactly what happened for a stack update.

The Diagnostic view just outputs so-called “diagnostic” messages from the Pulumi update. Most commonly, this is where you will see the output of things like calls to JavaScript’s console.log(...) or Python’s print(...) functions. It’ll also include the output of dependent tools, like the output when building Docker containers.

Feature 5: Stack Resource Visualization

Another cool feature of the Pulumi Service is being able to visualize a stack’s resources and their relationships to one another. This is a really important feature!

One of the advantages of using an infrastructure as code tool like Pulumi is that you aren’t just creating a flat list of resources. Instead, by the virtue of how the code and resource graph is structured, you are building a graph of resources.

This means that Pulumi has a semantic understanding of not only what resources are in your stack but also how they relate to one another.

If you navigate to a stack’s Resources tab, by default you see them listed in a table. You can filter this list by resource type, or by providing a custom filter:

However, in order to see the expanded resource graph, click the Graph View button. This will switch to rendering the resources as an interactive graph.

Notice here that the resources that are part of a component are grouped together. Also, you can double click on those nodes in the graph to expand or collapse them!

Feature 6: Drilling into Resource Properties

But you don’t need to just settle for a “top-level view” of your resources. You can click on any specific resource on the Resources tab, and see all of the properties of that resource.

This allows you to see all of the properties that Pulumi is tracking for that resource. It will also show you any relationships to other resources in the same stack.

The Pulumi Service also links you to the resource’s cloud provider’s console where possible, so you can see even more details.

Is your resource missing a link to the cloud provider console? With new services being launched from the myriad providers Pulumi supports every day, it’s hard to keep up. So if you would like us to add cloud provider links, please file an issue over in the pulumi/console-requests GitHub repository so we can update our database.

There are plenty of other features to check out in the Pulumi Service, and we have exciting improvements on the way! As always, feel free to stop by the Pulumi Community Slack to learn more, ask questions, or share anything cool you’re up to!

2021 December Hackathon: Introduction

Laura Santamaria — Fri, 07 Jan 2022 09:39:28 -0600

Pulumi’s hackathon tradition continued in the last weeks of 2021 with our 2021 December hackathon. For one solid week, we had teams from across the company focus on improvements across the Pulumi ecosystem, and we brought in people from outside the engineering org to get perspectives on different needs. While there were some projects that were focused on internal work, there were still quite a few open-source projects that we can talk about publicly. We’ll get more details from some of those teams over a few more posts. In this post, however, we’re going to explore a bit about how we worked.

Setting up for success

We set up the teams for success before the hackathon began by starting discussions around project ideas in a Slack channel asynchronously. In in-person hackathons, teams often decide on projects the day of the start of the hackathon. By starting discussions early, we let folks decide on projects they’d be interested in contributing to and drove early architectural discussions so teams could hit the ground running. People also started to get excited about working on the various projects, and they were able to start connecting with folks outside of the engineering team to find time on their calendars early.

Using a survey, we gathered what sorts of projects or areas of the ecosystem people were interested in working on, their timezone, and how they would like to collaborate. By using this data to sort people into teams, we ensured that people who were interested in learning about new areas of the ecosystem could find the right projects, that people who needed to work in a more synchronous environment could be paired with others in their timezone, and that people who worked similarly could find people who worked like them. It was an interesting experiment.

Working remotely

One cool thing that we tracked this round is all of the different ways we collaborated across the different projects. In general, Pulumi is a remote workplace, and none of the teams were co-located for this hackathon. As a result, we had to consider how teams might work across timezones and outside of the classic physical co-located team dynamic. Each team got to pick the best ways for them to collaborate. Our teams’ preferences ranged from daily standups over Zoom to collaboration solely on Slack to extensive pair programming and Zoom hangouts. In all, each team used multiple ways to communicate and engage depending on which parts of their projects they were working on. Teams working on explorations of possible solutions often found that pair programming remotely was a great way to brainstorm, for example. Once teams had a solid sense of what needed to be done to get to the next part of a project, many still attended a hackathon-wide Zoom hangout session daily to have someone to hang out with and discuss any issues that arose. The whole org also had the opportunity to get to know one another a little better, and it did not have the feeling of lost time or forced socialization that weekly virtual watercoolers can have after a couple of meetings as many have found during this period of forced virtual interactions.

Showing off what we did

During the demo at the end of the hackathon, we asked teams to self-report which strategies they found the most helpful, what they learned, and obviously what the results of their hackathon project were. We found that everyone level-set to how their team chose to work, and the pairing of people based on location and work preferences helped a lot to have teams succeed.

We’ll have more from each team soon! Keep watch on this space for new posts about hackathon projects.

If you like our way of working and are interested in a new position, we have a lot of positions open right now and will have more in the future! Please head over to our careers page to find out how to apply.

2021 End of Year Review

Laura Santamaria — Fri, 31 Dec 2021 10:26:47 -0600

It’s the end of the 2021 calendar year here at Pulumi, and like everyone, we’re counting down until 2022 while looking back at our year. We’ve had a very exciting year! In case you missed anything from our past year, here’s a rundown of the top stories from Pulumi:

January

Pulumi became SOC2 certified in early January 2021.

February

We brought support for all four official Pulumi languages to EKS.

We released Python support for our powerful Automation API.

March

We immediately followed up with releasing C# support for the Automation API.

The Azure Native provider, which communicates directly with the Azure resource model, went GA (general availability) after a period of being in beta.

April

We had a bit of fun on April Fool’s Day with Pulumi Interstellar (if you don’t understand April Fool’s Day because it’s not something you have in your country, please know this is a joke for fun).

The biggest news for April, though, was our PulumiUP event, where we showcased new releases for the Pulumi platform. Here are the big announcements:

Pulumi 3.0: Automation API, native Providers, Packages and Components, improved SDKs for Python and Go, and new integrations and features.
Pulumi Packages and multi-language Components
The Google Cloud Native Provider

May

We took a bit of a break in May from the blog to be heads down working on the next features after the excitement of PulumiUP. We did talk a bit about integration with App Runner, though!

June

We started posting our release notes as regular updates to the blog.

We took some time to dive into testing infrastructure in one of our many educational articles.

We worked with the community for a hackathon on multi-language components.

We announced Pulumi Team Edition with usage-based pricing and a free tier to get you started and Pulumi Enterprise Edition with access control and more on the same usage-based pricing system.

July

July was a month of education, with articles on Cloud Engineering as a concept, more on testing, and a new series on Kubernetes:

August

We kicked off an entire series on Azure developers for this month. Start here.

September

September saw preparations for Cloud Engineering Summit, with blog posts talking about the upcoming event. Still, we had time for more features!

We announced a public preview of a Helm Release resource.

We launched a Provider for Snowflake.

We shipped the public release of the Pulumi REST API, which had been a behind-the-scenes powerhouse.

We started supporting AWS Lambdas on Gravitron2 processors.

We opened up our roadmap to the public to vote on and discuss upcoming projects.

And finally, just squeezing into the end of September, we launched the public preview of the AWS Native Provider, powered by AWS’s Cloud Control API, so you can use Pulumi to work directly with the AWS resource model.

October

Cloud Engineering Summit was our biggest event of the year, and you can enjoy all of the sessions over on PulumiTV. That being said, we still had a lot to share on the blog.

We introduced resource methods for Pulumi Packages.

We shipped the 1.0 release of the Kubernetes Operator.

We delivered the Pulumi Registry.

November

We started providing same-day support for Azure Container Apps.

We reworked functions to accept outputs.

December

We started some more educational series:

… and Beyond

As we look forward to 2022, we’re not done yet! We’ve done a lot of things in 2021, and we’re on course to do a lot more in the next year. I’m excited that we’re all along for the ride, and we can’t wait to share more features and launches with you. Thanks for being with us, and here’s to 2022.

By the way, did you know we’re hiring?

Understanding State

Laura Santamaria — Mon, 13 Dec 2021 00:00:00 +0000

Let’s talk about state, shall we? State is the collective properties of the system from one point in time. Think of it effectively as a snapshot of a system. State in computer science is actually a lot like state in physics, so let’s start with something that’s a bit easier to understand.

State in the Physical World

We’re going to examine a physical system: A ball dropping from my hand to the ground one meter (1m) below. The ball starts out at one point in time where it is at rest in my hand. It has no velocity, no motion. It has properties like color, texture, etc. that do not and will not change. The state of the ball can be thought of as a position of 1m off the ground, with a color, texture, etc., and no velocity. Each of these variables has a specific value at that point in time.

Now I open my hand. At the instant the ball leaves my hand, the ball has moved some distance to the ground, and its velocity has increased. Its state, therefore, has changed. If we imagine capturing the ball’s motion with a slow-motion camera, we see a single frame for each position of the ball. Each frame is a single state of the system, and the difference between the frames is a change in state. When our state changes, one or more variables change. In this case, the variables of speed and direction (combined as velocity) and distance from the ground all change in each snapshot of time, or each state. We can use this knowledge to predict how the ball’s state will change, allowing us to identify patterns.

State in Infrastructure

When we think about our infrastructure that we manage with systems like Pulumi, we’re thinking about states of the infrastructure system. How we move from one state to another, which variables change from state to state, and what the starting state and ending state are would all be considered and tracked. Most infrastructure-as-code systems track state in some fashion, though most rely on you, the user, to manage that state tracking with state files or other systems that you have to manage and choose. For this deep dive, though, I’m going to focus on how the hosted Pulumi service manages state.

Tracking State Transitions

When considering the state of your infrastructure over time, we need to think about the transition of the infrastructure’s state between one point in time and another. Our program for any infrastructure-as-code platform defines the ideal, final state of the system. As the code executes, the infrastructure goes through a sequence of states, which we call the behavior of the system. For each tick of processing of the code, there is a defined state. Therefore, during the execution of the code, we see transitions in state. That state change needs to be tracked so that, at any point in time, we know how the behavior of the system changed. That’s important for having multiple programs trying to execute at once, debugging system changes, and other important considerations for working in teams across a remote, cloud-based environment. In short, it’s good to know what changed! When you use Pulumi, you have access to that change information through audit logging and can use webhooks to feed those changes into other systems for observation, like a shared monitoring system with your security team or a distributed team that can’t look over your shoulder as something deploys.

The Complexity of State Machines

Now, code execution doesn’t always happen exactly as we want it to due to all kinds of environmental factors from different chipsets to varying network connectivity and more. If you really want to go down the rabbit hole here, I’m going to point you to formal methods, especially TLA+. Formal methods are a great way to model state for distributed, concurrent systems to identify race conditions, poor assumptions, and other common flaws in temporal logic. For now, though, we’re going to keep talking about state in the more abstract sense.

Putting all of the states together along with the transitions they can have so that we have pathways from initial states to next states in a clean pattern, we get what’s called a state machine. When working with concurrent distributed systems, or systems that can have multiple things happening simultaneously that are spread out over many machines—basically, any cloud system created ever,—knowing the various states, changes, and combinations thereof is extremely important to ensuring that the one path we want the system to take to a final desired state is the one that is taken.

How Pulumi Manages State For You

When using Pulumi, you don’t have to worry about the state machine. The Pulumi Service tracks all of those states for you once the infrastructure’s initial state is declared by importing the infrastructure to or creating it with Pulumi. You declare the desired state in code in the language of your choosing, and then that code tells the Pulumi CLI what you want. The CLI does all of the state computation, requesting and defining the pathway to the infrastructure final state defined in the program, and the Pulumi Service stores the state at each moment in time. The Pulumi dashboard, by extension, is your window into the Pulumi Service where you can see current state, desired state, and the behaviors of the system.

Conclusion

I hope this short introduction to how state works, especially with infrastructure-as-code platforms, helps get you on your way! If you want to read more about state with Pulumi (and get some nifty diagrams), head to State and Backends. Until next time!

Additional Resources

Leslie Lamport has some fantastic, free resources and videos about the formal specifications in TLA+, which he created, at his site on TLA+. I’m a huge fan.

Also, if you want to watch a short video on state to get a better sense of the physics example, check out:

You can also head on over to PulumiTV for more educational videos and our Quick Bites of Cloud Engineering series all about state.

Preview of the Deploy Track at Cloud Engineering Summit 2021

Laura Santamaria — Wed, 15 Sep 2021 09:00:00 -0500

Cloud Engineering Summit 2021 is almost here! We’ve got a great line up this year.

Our tracks are built around the three pillars of cloud engineering: Build, Deploy, and Manage. I’m your track chair for the Deploy track, the track focused on automating and managing infrastructure. Deploy is all about unifying systems so everything in a cloud-based system is shipped together from the same automated, auditable process, reducing human error and improving quality across the board. That could mean focusing on automated testing and linting of infrastructure as code, providing shared services platforms for others to use in their pipelines, or exploring how unified and automated infrastructure changes engineering culture in an organization.

In no particular order, let’s go explore the Deploy track lineup.

Trying to get a handle on way too many environments across your pipelines? Adora Nwodo, Software Engineer at Microsoft, will explore bringing standard software engineering practices to solve the problem of maintaining many environments and configurations in a repeatable fashion. Adora has a very accessible way of explaining complex concepts in her blog and videos (find her at AdoraHacks), and I’m really looking forward to getting her perspective.

How can we improve the security of these unified processes? Alyssa Miller, Business Information Security Officer (BISO) at S&P Global Ratings, will discuss how threat modeling can improve CI/CD pipelines and general security. I’m excited to have Alyssa join us to help us understand how security should be part of the Deploy pillar; her Pitmaster’s Guide to Security is really good and I recommend watching it!

When you’re trying to share what you’re doing, you could share your code, but how do you share your infrastructure? Peter McKee, Head of Developer Relations and Advocacy at Docker, will demonstrate how to build into pipelines the ability to share features and changes in applications with others as a continuous preview. Peter’s a fantastic teacher who always has a great hands-on presentation in his back pocket, so I’m really looking forward to finding out what he has in store for us.

Data builds up while you’re building out, deploying, and managing cloud-based systems. How can you manage data while deploying your cloud infrastructure? Andy Dang, Co-Founder and Engineering Lead at WhyLabs, will talk about data integrity, observability, and monitoring with an open-source project called whylogs. Always love having a preview of an open-source project in the program, and I think data’s going to continue to be a big question for cloud engineering, so Andy’s talk was very welcome!

What about ARM-based systems? Apple certainly got into the game with their M1 chip, so it’s a platform you have to consider when doing deployments. Angel Rivera, Senior Developer Advocate at CircleCI, will explore how to make pipelines and workloads ARM compatible and capable of supporting ARM on various products. ARM-based systems are some of my favorites (yay Arduino and Raspberry Pi!), and they’re also really important considerations if you’re in the mobile or embedded space, so I can’t wait to hear Angel’s take.

How about some focus on doing all of this at scale? Jenna Pederson, Developer Advocate at AWS, will explore how bringing all of the best practices from software development to pipelines will help make working with cloud-based resources consistent and secure. I’m so happy Jenna could join us! Her content is wonderfully accessible and really explains technical concepts and complex systems clearly for all levels (which is my jam!). You don’t want to miss her talk!

Finally, how does all of this stuff work in a real life team? Evan Bradley, Software Engineer, and Tom Carrio, Senior Software Engineer, from Dynatrace are going to take us through bringing it all together with a real-life team, discussing the experiences they’ve had over time as they’ve implemented everything. I’m really excited to have folks bring their stories of what it’s all like so we can share pitfalls and solutions to move forward together. I think you’ll enjoy Evan and Tom’s talk, too!

Explore all the sessions, and don’t forget to register for Cloud Engineering Summit. I can’t wait to chat with you virtually at Cloud Engineering Summit 2021!