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 familiar 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.
In this post, we’ll look at how to use
pulumi new and our selection
of templates to build your Pulumi
Why isn’t my
Pod getting any traffic?
An experienced ops team running on GKE might assemble the following checklist to help answer this question:
- Does a
Serviceexist? Does that service have a
.spec.selectorthat matches some number of
- Are the
Pods alive and has their readiness probe passed?
- Did the
Endpointsobject that specifies one or more
Pods to direct traffic to?
- Is the
Servicereachable via DNS? When you
Podand you use
curlto poke the
Servicehostname, do you get a response? (If not, does any
Servicehave a DNS entry?)
- Is the
Servicereachable via IP? When you SSH into a
Nodeand you use
curlto poke the
ServiceIP, do you get a response?
kube-proxyup? Is it writing iptables rules? Is it proxying to the
This question might have the highest complexity-to-sentence-length ratio of any question in the Kubernetes ecosystem. Unfortunately, it’s also a question that every user finds themselves asking at some point. And when they do, it usually means their app is down.
To help answer questions like this, we’ve been developing a small
kubespy. In this post we’ll look at the new
kubespy trace command, which is broadly aimed at automating questions
1, 2, 3, and providing “hints” about 4 and 5.
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!
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 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 code using familiar languages.
Kubernetes has quickly become the “gold standard” for running containers in production, spanning public, private, and hybrid cloud scenarios. It’s been remarkable to watch its explosive growth just this past year alone. Every cloud vendor now supports an easy-to-use managed Kubernetes solution — Google GKE, Azure AKS, and AWS AKS — making it easier than ever to start writing and deploying Kubernetes applications.
Pulumi for Kubernetes is a way to create, deploy, and manage Kubernetes applications using your favorite programming languages. that works across AWS, Azure, Google Cloud, OpenStack, and other clouds, now to Kubernetes and cloud native architectures. You can dive right in here and look at some powerful things Pulumi enables here.
Kubernetes is a powerful container orchestrator for cloud native
applications that can run on any cloud – AWS, Azure, GCP – in
addition to hybrid and on-premises environments. Its CLI,
offers basic built-in support for performing deployments, but
intentionally stops short here. In particular, it doesn’t offer diffs
and previews, the ability to know when a deployment has succeeded or
failed, and why, and/or sophisticated deployment orchestration.
In this post, we’ll see how Pulumi, an open source cloud native development platform, can not only let you express Kubernetes programs in familiar programming languages, like TypeScript, instead of endless YAML templates, but also how Pulumi delivers simple and reproducible, yet powerful, Kubernetes deployment workflows.
Just over a month ago we publicly launched Pulumi, a new cloud native development platform. The response has been overwhelming and we’ve been hard at work responding to your feedback ever since. Today, we are excited to release Pulumi 0.15 and make it available to download. This release includes improvements across the entire Pulumi development experience. Pulumi supports more platforms (Kubernetes and OpenStack), is faster (Parallelism, simpler (native TypeScript support), richer (serverless frameworks for Azure and GCP), and is more deeply integrated into the application lifecycle (GitHub App for CI/CD integration).
Hello! A few weeks back I wrote a post on serving static websites on AWS with Pulumi detailing how to host a static website on AWS. Pulumi allowed me to wire four different AWS products together in only 200 lines of code. It would be a shame, however if I needed to copy and paste that code every time I wanted to to stand up a new website. Instead, we can package up, share, and reuse our code just like any other Node.js library. It just so happens that this one can be used to create cloud infrastructure.