Today we announced our partnership with GitHub on the new GitHub Actions feature. We are super excited about this bold and innovative technology, especially as it relates to Pulumi, and CI/CD more broadly. We truly believe that Pulumi plus GitHub Actions delivers the easiest, most capable, and friction-free way to achieve continuous delivery of cloud applications and infrastructure, no matter your cloud – AWS, Azure, Google Cloud, Kubernetes, or even on-premises. In this post, we’ll dig deeper to see why, and how to get up and running. It’s refreshingly easy!
This post is part 3 in a series on the Kubernetes API. Part 1 focused on the lifecycle of a
Pod, part 2 focused on the lifecycle of a
What is happening when a
Deployment rolls out a change to your app? What does it actually do when a
Pod crashes or is killed? What happens when a
Pod is re-labled so that it's not targeted by the
Deployment is probably the most complex resource type in Kubernetes core.
Deployment specifies how changes should be rolled out over
ReplicaSets, which themselves specify how
Pods should be replicated in a cluster.
In this post we continue our exploration of the Kubernetes API, cracking
Deployment open using
kubespy, a small tool we developed to observe Kubernetes resources in real-time.
kubespy trace, for example, we can observe at a high level what happens when
Deployment rolls out a new version of an application:
The newly introduced cloud.HttpServer in Pulumi makes it easy to serve a standard Node.js HTTP server as a serverless API on any cloud platform. This new API brings together the flexibility and rich ecosystem of Node.js HTTP servers, the cost and operational simplicity of serverless APIs, and the multi-cloud authoring and deployment of Pulumi. In this post, we walk through some of the background on why we introduced this new API and how it fits into the Node.js HTTP ecosystem.
When you're able to build an app for any cloud using real languages, the obvious question is "Where to start?". We hear you, and so we've built some new features to help you scaffold your app and program the cloud even faster than before.
This post is part 2 in a series on the Kubernetes API. Part 1 focused on the lifecycle of a
Why isn't my
Pod getting any traffic?
We at Pulumi love TypeScript for cloud apps and infrastructure, because of its rich type system and great ahead-of-time typechecking – making for a more productive inner loop and helping to find errors sooner. The typesystem magic behind how this works for infrastructure as code can be fascinating!
This post is part 1 in a series.
One of the most popular features of the recent v0.15.2 release of Pulumi is fine-grained status updates for Kubernetes resources. On the CLI they look like this:
In this post, we’ll take a look at 11 “pearls” – bite-sized code snippets – that demonstrate using Pulumi to build and deploy Kubernetes applications using cloud native infrastructure as code. These pearls are organized into three categories, each demonstrating a unique scenario:
- Config as Real Code: Use your favorite language for authoring applications and configuration, eliminating toil and YAML.
- Multi-Cloud Infrastructure: Mix cloud services alongside Kubernetes resources and manage them using one set of tools and workflows.
- Software Delivery as Code: Perform sophisticated continuous delivery of your Kubernetes deployments – including canaries, staged rollouts, leveraging cloud native projects like Envoy and Prometheus – authored in real code.
Today we’re pleased to announce Pulumi for Kubernetes, a way to create, deploy, and manage Kubernetes applications using your favorite programming languages, bringing the same lovable experience that works across AWS, Azure, Google Cloud, OpenStack, and other clouds, now to Kubernetes and cloud native architectures. We have built this support in response to significant user interest and real end users scenarios, and are excited to share what we’ve been up to. You can dive right in here and look at some powerful things Pulumi enables here.