Pulumi Concepts: Difference between revisions
| Line 60: | Line 60: | ||
Each stack of a project will have a file named <code>Pulumi.<stackname>.yaml</code> that contains [[#Configuration|configuration]] specific to the stack it is associated with. The file typically resides in the project root directory. Secret values are encrypted, which, according to the Pulumi documentation, makes them safe to be checked in into a repository. This is debatable. The stack settings for [[#Ephemeral_Stack|ephemeral stacks]] are typically not checked into source control. | Each stack of a project will have a file named <code>Pulumi.<stackname>.yaml</code> that contains [[#Configuration|configuration]] specific to the stack it is associated with. The file typically resides in the project root directory. Secret values are encrypted, which, according to the Pulumi documentation, makes them safe to be checked in into a repository. This is debatable. The stack settings for [[#Ephemeral_Stack|ephemeral stacks]] are typically not checked into source control. | ||
==Ephemeral Stack== | ==Ephemeral Stack== | ||
Ephemeral stacks may have [[#Stack_Setting_File|stack settings files]]. | |||
==Stack Operations== | ==Stack Operations== | ||
Revision as of 01:38, 11 January 2022
Internal
Overview
Pulumi is an Infrastructure as Code platform that allows using common programming languages, tools, and frameworks, to provision, update, and manage cloud infrastructure resources. Pulumi is one of the tools that can be used to manage generic Infrastructure as Code stacks. In Pulumi, Infrastructure resources are declared in programs. Programs reside in a project. The programs are instantiated as stacks in the infrastructure platform. A stack is an isolated and configurable instance of the program.
Architecture
TO PROCESS: https://www.pulumi.com/docs/intro/concepts/how-pulumi-works/
Program
A program contains code that describes how cloud infrastructure should be composed. It can be written in Python, TypeScript or Go. Infrastructure is declared by defining resource objects whose properties correspond to the desire state of the infrastructure. The properties are also used to express dependencies between resources, and can be exported outside the stack. It is recommended to group resource with common lifecycles together. Programs reside in projects.
Supported Programming Languages
Project
A project is a directory that contains program and metadata on how to run the program. The program and metadata are read by the Pulumi CLI and applied to the infrastructure platform with the pulumi up command, creating a stack.
Current Project
The current project is the project given by the nearest Pulumi.yaml file.
Organization
Resource
TO PROCESS: https://www.pulumi.com/docs/intro/concepts/resources/
Pulumi understands dependencies between resources and uses the relationship between resources to maximize execution parallelism and ensure correct ordering when a stack is instantiated.
Property
Difference between resource and stack inputs/outputs.
Input Property
Output Property
Stack
A stack is an isolated, independently configurable instance of a Pulumi program. Stacks are commonly used to denote different phases of development, such as "development", "staging" and "production", or feature branches. A project can have an arbitrary number of stacks. By default, Pulumi creates a new stack per project when pulumi new is used.
Stack Name
A fully qualified stack name includes the organization and the project name: <org-name>/<project-name>/<stack-name>.
Stack URI
What is the semantics of a stack URI?
Active Stack
Stack References
Stack references are used by consumer stacks to get their dependencies, using the Stack Data Lookup pattern.
Stack Tags
Stacks have associated metadata as tags. Each tags has a name and a value. A set of built-in tags are automatically assigned and updated each time is updated). Tags are only supported with the Pulumi Service backend.
Stack Output
Stack outputs can be shared with other teams.
Destroying and Deleting a Stack
Destroying a stack means releasing and deleting resources associated with the stack.
Deleting a stack means removing all stack history from the backend and the stack configuration file Pulumi.<stack-name>.yaml.
⚠️ Forcefully deleting a stack before destroying it may leave orphaned resources behind.
Stack Settings File
Each stack of a project will have a file named Pulumi.<stackname>.yaml that contains configuration specific to the stack it is associated with. The file typically resides in the project root directory. Secret values are encrypted, which, according to the Pulumi documentation, makes them safe to be checked in into a repository. This is debatable. The stack settings for ephemeral stacks are typically not checked into source control.
Ephemeral Stack
Ephemeral stacks may have stack settings files.
Stack Operations
- List stacks
- Select a stack
- Display stack resources
- Display stack tags
- Create a stack
- Select a stack
- Remove (delete) a stack
Inputs and Outputs
TO PROCESS: https://www.pulumi.com/docs/intro/concepts/inputs-outputs/
See stack outputs.
State and Backends
TO PROCESS: https://www.pulumi.com/docs/intro/concepts/state/
Backend
The main job of a service backend is to reliably manage the state of stacks. It provides dependencies to consumer stacks via the Stack Data Lookup pattern.
Name
URL
Authentication and Identity
The backend decides what a user can and cannot see, for example organizations, based on user's OD group configuration. A user's OD group list, as known by the Pulumi backend, is given by pulumi whoami --verbose.
Service Backend
Configuration
TO PROCESS: https://www.pulumi.com/docs/intro/concepts/config/
Template
Secrets
TO PROCESS: https://www.pulumi.com/docs/intro/concepts/secrets/
Pulumi.yaml
Built-in Tags
pulumi:project
pulumi:runtime
pulumi:description
gitHub:owner
gitHub:repo
vcs:owner
vcs:repo
vcs:kind
Logging
TO PROCESS: https://www.pulumi.com/docs/intro/concepts/logging/
Assets and Archives
TO PROCESS: https://www.pulumi.com/docs/intro/concepts/assets-archives/
Plugin
Plugin Operations
Function Serialization
TO PROCESS: https://www.pulumi.com/docs/intro/concepts/function-serialization/
Workspace
Modularization
TO PROCESS: https://www.pulumi.com/blog/creating-and-reusing-cloud-components-using-package-managers/
Pulumi vs Terraform
Also see: