draft of P3: some assembly required post #12647
Conversation
|
Your site preview for commit 675302a is ready! 🎉 http://www-testing-pulumi-docs-origin-pr-12647-675302ab.s3-website.us-west-2.amazonaws.com. |
|
Your site preview for commit ee2fe65 is ready! 🎉 http://www-testing-pulumi-docs-origin-pr-12647-ee2fe656.s3-website.us-west-2.amazonaws.com. |
aaronkao
requested review from
toriancrane
and removed request for
interurban and
cnunciato
|
Your site preview for commit f204bc0 is ready! 🎉 http://www-testing-pulumi-docs-origin-pr-12647-f204bc0f.s3-website.us-west-2.amazonaws.com. |
|
This is ready for publishing on Monday. |
|
Your site preview for commit 793fa1b is ready! 🎉 http://www-testing-pulumi-docs-origin-pr-12647-793fa1b7.s3-website.us-west-2.amazonaws.com. |
|
|
||
| In Pulumi Cloud, you have the ability to create organizations. A [Pulumi Cloud organization](https://www.pulumi.com/docs/pulumi-cloud/organizations/) can help you manage teams, roles, stacks, settings, and provide a dashboard across the entire organization. Pulumi Cloud also allows you to use a variety of identity providers to login, including GitHub. | ||
|
|
||
| For simplicity’s sake, we suggest that you start with your GitHub organization. [Create the GitHub organization](https://docs.github.com/en/organizations/collaborating-with-groups-in-organizations/creating-a-new-organization-from-scratch), [set up teams](https://docs.github.com/en/organizations/organizing-members-into-teams/about-teams), and [add members](https://docs.github.com/en/organizations/organizing-members-into-teams/adding-organization-members-to-a-team) to those teams, assigning either admin or user [roles](https://docs.github.com/en/enterprise-cloud@latest/organizations/managing-peoples-access-to-your-organization-with-roles/using-organization-roles) to each member. |
There was a problem hiding this comment.
I think there should be a reference to the SAML and SCIM docs pages so readers are aware there or other ways of managing access and team membership.
https://www.pulumi.com/docs/pulumi-cloud/access-management/saml/
https://www.pulumi.com/docs/pulumi-cloud/access-management/scim/
I also think a link to the docs page for Github teams integration would be good
https://www.pulumi.com/docs/pulumi-cloud/access-management/teams/#github-based-teams
|
|
||
| ## Pulumi ESC: Managing credentials, configuration, and other secrets | ||
|
|
||
| In order to deploy a stack you will need secrets such as cloud credentials and other configuration values that are provided to the deployment engine. Pulumi ESC is a secure system for managing secrets. They are organized by *[environments](https://www.pulumi.com/docs/concepts/environments/)*. |
There was a problem hiding this comment.
I think a sentence briefly mentioning stack config files (https://www.pulumi.com/docs/iac/concepts/config/) would be good so readers don't think that ESC is the only way to provide config and secrets.
|
|
||
| In this manner, you can configure separate environments for staging and production, with a complex set of configuration values and secrets, using different environments for each one. From the developer’s perspective they would only need to change `aws-staging` to `aws-production` when they go to deploy their stack. | ||
|
|
||
| Another strong benefit of this approach is that all secrets will be encrypted both in-flight and at-rest. Pulumi waits until the last moment to decrypt secrets at runtime. By default, uses automatic, per-stack encryption keys provided by Pulumi Cloud, but you could use a [provider of your own choosing](http://www-testing-pulumi-docs-origin-pr-12530-f0b1e6aa.s3-website.us-west-2.amazonaws.com/docs/concepts/secrets/#configuring-secrets-encryption) instead. |
There was a problem hiding this comment.
I think there's some missing words or punctuation:
By default, uses automatic, per-stack encryption keys ....
|
|
||
| ## Multi-Language Components (MLC) | ||
|
|
||
| In Pulumi, a *[component resource](https://www.pulumi.com/docs/concepts/resources/components/)* is something that your developers can import in their Pulumi program, instantiate and modify. These are made available via a *[provider](https://www.pulumi.com/docs/concepts/resources/providers/)*, which is in turn, made available to Pulumi via a *[provider package](https://www.pulumi.com/docs/using-pulumi/pulumi-packages/)*. There are many of these already available in the [Pulumi Registry](https://www.pulumi.com/registry/). However, in a custom internal developer platform you can define your own components, and bake appropriate settings/configuration directly into the underlying code. |
There was a problem hiding this comment.
I'm not sure this sentence makes sense in the context of this component resource section:
These are made available via a *[provider](https://www.pulumi.com/docs/concepts/resources/providers/)*, which is in turn, made available to Pulumi via a *[provider package](https://www.pulumi.com/docs/using-pulumi/pulumi-packages/)*.
The sentence that follows about "many of these already available is fine "- although I suggest narrowing it down to the topic of packages (e.g. awsx, eks) since that more closely aligns what this section is about.
|
|
||
| Some other great features of Crossguard are the ability to [version policies](https://www.pulumi.com/docs/using-pulumi/crossguard/faq/#how-do-i-version-a-policy-pack), define multiple [policy groups](https://www.pulumi.com/docs/using-pulumi/crossguard/core-concepts/#policy-groups), and create [remediation policies](https://www.pulumi.com/blog/remediation-policies/) that automatically fix policy violations when possible. We will cover these topics in a future post where we go deeper on how to use policies effectively. | ||
|
|
||
| ## Multi-Language Components (MLC) |
There was a problem hiding this comment.
I'm inclined to title this with something more generic like "Reusable Components" since MLCs are a not for the timid but the basic component resource construct is very accessible and solves all the same problems in a mono-language environment. Although component resources are mentioned up front, the title may lead readers to think MLCs are the "best practice" when that's not necessary.
| Each template needs the following parts: | ||
| * A `Pulumi.yaml` describing the template and its configuration values | ||
| * A GitHub repo (public or private) containing the code for the templated Pulumi program | ||
|
|
There was a problem hiding this comment.
The list of needed parts glosses over the stack (production and staging) config files that are shown in the following paragraphs.
But this prompts a discussion about how to couch some of these shortcomings of NPW.
Pequod has stack config files to enable an as-frictionless-as-possible NPW flow ("two clicks').
But, NPW does allow one to specify (only one currently) environment during the flow which obviates the need to have pre-existing stack config files. And I think at this time that's the better narrative.
A draft for the second in the P3 blog post series. The purpose of this blog post is to show the various parts of the P3 architecture, give a brief example of what each part looks like to build, and how they all work together to produce a fully featured platform with a simple developer experience.