2020-02-26 16:21:04 -07:00
---
Eliminate "real languages" from our website (#4032)
* Eliminate "real languages" from our website
We know that this terminology is unfriendly and can be seen as
gatekeeping. We've moved away from it over time, but there are many
traces of it in our documentation -- most notably, even on our
homepage. Instead of "real languages", let's use "familiar languages",
and in places where deeper explanation makes sense in context, we
can say "familiar, general-purpose languages."
The current 2nd-level blurb on the homepage isn't very good right now
anyhow, so this is a convenient change. As we make progress on various
marketing efforts, we will likely make more extensive changes, but
for now this at least fixes this problem. We recently A/B tested
updates without much of an impact, so let's move ahead with this change
and then if we want to test alternatives to "familiar", we can do that.
For instance, we considered "popular", etc.
* Also eliminate "real code"
2020-08-19 06:19:50 -07:00
title: "Generate Kubernetes YAML with Familiar Programming Languages"
2020-03-03 09:27:36 -07:00
date: 2020-03-03
2020-02-26 16:21:04 -07:00
draft: false
Eliminate "real languages" from our website (#4032)
* Eliminate "real languages" from our website
We know that this terminology is unfriendly and can be seen as
gatekeeping. We've moved away from it over time, but there are many
traces of it in our documentation -- most notably, even on our
homepage. Instead of "real languages", let's use "familiar languages",
and in places where deeper explanation makes sense in context, we
can say "familiar, general-purpose languages."
The current 2nd-level blurb on the homepage isn't very good right now
anyhow, so this is a convenient change. As we make progress on various
marketing efforts, we will likely make more extensive changes, but
for now this at least fixes this problem. We recently A/B tested
updates without much of an impact, so let's move ahead with this change
and then if we want to test alternatives to "familiar", we can do that.
For instance, we considered "popular", etc.
* Also eliminate "real code"
2020-08-19 06:19:50 -07:00
meta_desc: Stop writing Kubernetes YAML by hand, and start using the power of familiar programming languages! Pulumi now supports rendering YAML for Kubernetes resources.
2020-02-26 16:21:04 -07:00
meta_image: yamlRuler.png
authors:
- levi-blackstone
tags:
- kubernetes
Filter blog tags to Top 40, and add back some metadata (#350)
* Only show the top 40 blog tags
In https://github.com/pulumi/pulumi-hugo/pull/215, I had suggested
that instead of physically deleting tags we didn't want to show, we
compute it algorithmically, by only showing the "Top N" tags. This
commit introduces said functionality.
This has a few advantages:
* Preserves old metadata (the authors added the tags because they
felt they were meaningful and captured information about the posts).
* Enables us to surface those tags differently in the future (who
knows, maybe someday we'll want to run a "spinnaker" campaign).
* Notably, also keeps the tag index pages, which Google has indexed.
* Enables us to add a "View More ..." link at the bottom of the
page if folks want to see the entire list.
* Perhaps most importantly, protects against future bloat. For
example, since this tag cleanup happened, we have added top-level
tags for "aliases", "app-runner", "iam", "open-source", and
"refactoring", each of which has only a single post.
I chose 40 as the N in Top N, because that's how many we show today.
I could see an argument for filtering this based on post count
instead (e.g., only those with >3 posts).
* Add back some tags
Now that we filter out unpopular tags, we can add back some of the
ones previously removed.
2021-06-21 17:31:35 -07:00
- yaml
2022-10-26 07:22:15 -07:00
2020-02-26 16:21:04 -07:00
---
Eliminate "real languages" from our website (#4032)
* Eliminate "real languages" from our website
We know that this terminology is unfriendly and can be seen as
gatekeeping. We've moved away from it over time, but there are many
traces of it in our documentation -- most notably, even on our
homepage. Instead of "real languages", let's use "familiar languages",
and in places where deeper explanation makes sense in context, we
can say "familiar, general-purpose languages."
The current 2nd-level blurb on the homepage isn't very good right now
anyhow, so this is a convenient change. As we make progress on various
marketing efforts, we will likely make more extensive changes, but
for now this at least fixes this problem. We recently A/B tested
updates without much of an impact, so let's move ahead with this change
and then if we want to test alternatives to "familiar", we can do that.
For instance, we considered "popular", etc.
* Also eliminate "real code"
2020-08-19 06:19:50 -07:00
Stop writing Kubernetes YAML by hand, and start using the power of familiar programming languages! Pulumi can
2020-03-02 13:46:41 -07:00
generate Kubernetes manifests that easily integrate into existing CI/CD workflows.
2020-02-26 16:21:04 -07:00
<!-- more -->
2023-05-15 15:25:28 -07:00
While Pulumi has [excellent support ](https://www.pulumi.com/docs/clouds/kubernetes/get-started/ ) for deploying and updating
2020-02-26 16:21:04 -07:00
Kubernetes resources on a cluster, many users have asked for the option to render YAML that they can integrate into
existing workflows. The [v1.5.4 ](https://github.com/pulumi/pulumi-kubernetes/releases/tag/v1.5.4 ) release of
`pulumi-kubernetes` adds the [renderYamlToDirectory ](https://www.pulumi.com/docs/reference/pkg/nodejs/pulumi/kubernetes/#ProviderArgs-renderYamlToDirectory )
2020-02-28 10:03:43 -06:00
option, which enables this feature. This option is available in every Pulumi-supported language, including
2020-02-26 16:21:04 -07:00
TypeScript/JavaScript, Python, and .NET ([Go support is coming soon! ](https://github.com/pulumi/pulumi-kubernetes/issues/70 )).
Eliminate "real languages" from our website (#4032)
* Eliminate "real languages" from our website
We know that this terminology is unfriendly and can be seen as
gatekeeping. We've moved away from it over time, but there are many
traces of it in our documentation -- most notably, even on our
homepage. Instead of "real languages", let's use "familiar languages",
and in places where deeper explanation makes sense in context, we
can say "familiar, general-purpose languages."
The current 2nd-level blurb on the homepage isn't very good right now
anyhow, so this is a convenient change. As we make progress on various
marketing efforts, we will likely make more extensive changes, but
for now this at least fixes this problem. We recently A/B tested
updates without much of an impact, so let's move ahead with this change
and then if we want to test alternatives to "familiar", we can do that.
For instance, we considered "popular", etc.
* Also eliminate "real code"
2020-08-19 06:19:50 -07:00
Aside from easily templating configuration across resources, using a familiar programming language allows you to write and
2020-02-26 16:21:04 -07:00
consume libraries, and easily mix in infrastructure configuration (e.g., managed database endpoints, object storage,
etc.), all in the same program.
## Rendering YAML from TypeScript
First, choose a directory for the rendered manifests, and specify that path on a `Provider` .
```typescript
import * as k8s from "@pulumi/kubernetes ";
import * as kx from "@pulumi/kubernetesx ";
// Instantiate a Kubernetes Provider and specify the render directory.
const provider = new k8s.Provider("render-yaml", {
2020-03-02 13:53:16 -07:00
renderYamlToDirectory: "rendered",
2020-02-26 16:21:04 -07:00
});
```
Next, use that `Provider` for any Kubernetes resources you want to render as YAML.
```typescript
// Create a Kubernetes PersistentVolumeClaim.
const pvc = new kx.PersistentVolumeClaim("data", {
spec: {
accessModes: [ "ReadWriteOnce" ],
2020-03-02 13:53:16 -07:00
resources: { requests: { storage: "1Gi" } },
2020-02-26 16:21:04 -07:00
}
}, { provider });
// Create a Kubernetes ConfigMap.
const cm = new kx.ConfigMap("cm", {
2020-03-02 13:53:16 -07:00
data: { "config": "very important data" },
2020-02-26 16:21:04 -07:00
}, { provider });
// Create a Kubernetes Secret.
const secret = new kx.Secret("secret", {
stringData: {
"password": new random.RandomPassword("pw", {
length: 12}).result,
}
}, { provider });
// Define a Pod.
const pb = new kx.PodBuilder({
containers: [{
env: {
CONFIG: cm.asEnvValue("config"),
PASSWORD: secret.asEnvValue("password"),
},
image: "nginx",
ports: {http: 8080},
volumeMounts: [ pvc.mount("/data") ],
}]
});
// Create a Kubernetes Deployment.
const deployment = new kx.Deployment("nginx", {
2020-03-02 13:53:16 -07:00
spec: pb.asDeploymentSpec( { replicas: 3 } ),
2020-02-26 16:21:04 -07:00
}, { provider });
// Create a Kubernetes Service.
2020-03-02 13:53:16 -07:00
const service = deployment.createService({
type: kx.types.ServiceType.LoadBalancer,
});
2020-02-26 16:21:04 -07:00
```
2023-05-15 15:25:28 -07:00
Now, run `pulumi update` , and Pulumi renders these resources to YAML. The update process resolves [Outputs ](/docs/concepts/inputs-outputs/ )
2020-02-28 10:03:43 -06:00
as usual, so that the manifests can include other infrastructure configuration specified in your program. The rendered
2020-02-26 16:21:04 -07:00
manifests are kept in sync with changes to the program on each update.
Here's what the resulting directory looks like:

Note that `CustomResourceDefinition` resources need to be applied first, so they are rendered in a separate
subdirectory. (This example doesn't include any CRDs, so the directory is empty). You could deploy the rendered
manifests with `kubectl` like this:
```shell script
kubectl apply -f "${RENDER_DIRECTORY}/0-crd"
kubectl apply -f "${RENDER_DIRECTORY}/1-manifest"
```
Voilà! From 33 (44 with whitespace and comments) lines of TypeScript code to 102 lines of YAML!
Here's the rendered `Deployment` resource.
2020-02-28 10:03:43 -06:00
{{< gist lblackstone 686935edf7fdcd23d916f34d35bba64a " deployment-nginx-nyn4tlkx . yaml " > }}
2020-02-26 16:21:04 -07:00
See [this gist ](https://gist.github.com/lblackstone/686935edf7fdcd23d916f34d35bba64a ) for the complete rendered output.
## Caveats
There are two important caveats to note about YAML rendering support:
1. The YAML-rendered resources are **not created** on a Kubernetes cluster, so information that is computed server-side
will not be available in your program. For example, a `Service` will not have IP assignments, so attempting to export
2020-02-28 10:03:43 -06:00
these values will not work as usual (i.e., the value will be `undefined` ).
2020-02-26 16:21:04 -07:00
1. **Any Secret values will appear in plaintext in the rendered manifests.** This includes any values marked as
secret in Pulumi. A warning will be printed for any secret values being rendered to YAML, but it is your responsibility
to protect the rendered files.
## Learn More
If you'd like to learn about Pulumi and how to manage your
2023-06-16 14:10:53 -07:00
infrastructure and Kubernetes through code, [get started today ](/docs/get-started/ ). Pulumi is open
2020-02-26 16:21:04 -07:00
source and free to use.
For further examples on how to use Pulumi to create Kubernetes
clusters, or deploy workloads to a cluster, check out the rest of the
2022-10-26 07:22:15 -07:00
[Kubernetes tutorials ](/registry/packages/kubernetes/how-to-guides/ ).
2020-02-26 16:21:04 -07:00
As always, you can check out our code on
[GitHub ](https://github.com/pulumi ), follow us on
[Twitter ](https://twitter.com/pulumicorp ), subscribe to our [YouTube
channel](https://www.youtube.com/channel/UC2Dhyn4Ev52YSbcpfnfP0Mw), or
join our [Community Slack ](https://slack.pulumi.com/ ) channel if you have
any questions, need support, or just want to say hello.