Pulumi Concepts

From NovaOrdis Knowledge Base
Jump to navigation Jump to search

External

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.

Pulumi Concepts.png

Architecture

TO PROCESS: https://www.pulumi.com/docs/intro/concepts/how-pulumi-works/

Organization

Other organization is also referred to as the "owner".

  • Relationship between a stack and an organization ("owner"). "New stack owner, some-org, does not match existing owner, o_feodorov."

Project

https://www.pulumi.com/docs/intro/concepts/project/#projects

A project is a directory that contains a program and metadata on how to run the program, such as what runtime to use, where to look for the program, etc. The project definition metadata is maintained in Pulumi.yaml. The presence of Pulumi.yaml is the indication that directory is a Pulumi project.

Projects can be created with pulumi new command.

The program and metadata are read by the Pulumi CLI and applied to the infrastructure platform with the pulumi up command, creating a stack.

  • Is the project stored in the backend after pulumi new. How can it be listed?
  • Does the stack need to be created explicitly or pulumi new does it implicitly?
  • Understand the relationship between a project and stacks. Can a project contain more than one stack? How does the project layout look like in that case?

Current Project

The current project is the project given by the nearest Pulumi.yaml file.

Project Name

Template

A list of available templates is presented executing pulumi new without any argument. An example is available here:

Available Templates

Intuitively, the right template can be invoked by using the name of the cloud and the language, example: aws-python.

Project Layout

 my-project
  ├─ README.md
  ├─ Pulumi.yaml
  ├─ Pulumi.my-stack.yaml
  └─ ... # language-specific elements

Language-specific layouts:

Pulumi.yaml

https://www.pulumi.com/docs/intro/concepts/project/#pulumi-yaml
https://www.pulumi.com/docs/reference/pulumi-yaml/

Contains the project definition. The name must begin with a capital "P", and both "yaml" and "yaml" extensions are valid.

Example:

name: simple-aws
runtime:
  name: python
  options:
    virtualenv: venv
description: An experimental AWS Pulumi project.

Built-in Tags

pulumi:project

pulumi:runtime

Example of a Python runtime section.

pulumi:description

gitHub:owner

gitHub:repo

vcs:owner

vcs:repo

vcs:kind

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 Runtimes and Programming Languages

https://www.pulumi.com/docs/intro/languages/

Python

The runtime name is python.

Python Pulumi

TypeScript

The runtime name is nodejs.

TypeScript Pulumi

Go

The runtime name is go.

Go Pulumi

.NET

The runtime name is dotnet.

Programming Model

The Pulumi programming model defines the core concepts in use when creating infrastructure as code programs. These concepts are made available in the Pulumi SDKs, that support Python, TypeScript and Go.

Resource

https://www.pulumi.com/docs/intro/concepts/resources/

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

https://www.pulumi.com/docs/intro/concepts/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?

Current (Active) Stack

The current stack for a project can be displayed by running pulumi about in the project, and can be set by running pulumi stack select.

Stack References

https://www.pulumi.com/docs/intro/concepts/stack/#stackreferences
https://www.pulumi.com/docs/reference/pkg/nodejs/pulumi/pulumi/#StackReference

Stack references are used by consumer stacks to get their dependencies, using the Stack Data Lookup pattern.

Stack Tags

https://www.pulumi.com/docs/intro/concepts/stack/#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

https://www.pulumi.com/docs/intro/concepts/stack/#outputs

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. Pulumi waits until all resources are shut down and deleted before it considers the destroy operation to be complete.

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 (key/value pairs) 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

Configuration

https://www.pulumi.com/docs/intro/concepts/config/#configuration

TO PROCESS when I have access to a working environment so I can try code: https://www.pulumi.com/docs/intro/concepts/config/

Namespace

Key space.

Inputs and Outputs

https://www.pulumi.com/docs/intro/concepts/inputs-outputs/

The Pulumi programming model includes the concepts of Input and Output values, which model how output of one resource flow in as inputs of another resource.

See stack outputs.

State and Backends

https://www.pulumi.com/docs/intro/concepts/state/

TO PROCESS: https://www.pulumi.com/docs/intro/concepts/state/

Pulumi State.png

State can be interacted with via both #CLICLI and programming model.

What Happens when Code Is Applied to Platform?

The pulumi up command evaluates the program and determines resource updates to make. Part of the update process, pulumi will run the preview step of the update, which computes the minimally disruptive change to achieve the desired state described by the program.

More here.

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

https://app.pulumi.com/

Secrets

https://www.pulumi.com/docs/intro/concepts/secrets/

TO PROCESS: https://www.pulumi.com/docs/intro/concepts/secrets/

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/

Packages

Pulumi Registry

https://www.pulumi.com/registry/

CLI

Pulumi vs Terraform

https://www.pulumi.com/docs/intro/vs/terraform/

Also see:

Terraform