Pulumi Resource Type for Concourse
MIT License
A Concourse resource type that allows jobs to modify IaaS resources via Pulumi. This resource will work against the Pulumi hosted platform. Cloud based state storage backends are not supported by this resource.
NOTE: This resource is currently under development and might still contain some bugs. Use at least v0.4.0, in combination with a Pulumi 3.x based project. All previous development versions are unsupported.
For usage questions, please post a new message on the Github Discussions board for this project.
If you are not sure whether your problem is a usage problem or a bug, please reach out via the discussions first. Also reach out first via the Discussions if you have a suggestion for an improvement.
Only file a new Github issue when you are really sure there is a bug.
To use this resource type in your pipeline, you have to register it under the resource_types
section in your pipeline:
resource_types:
- name: pulumi
type: registry-image
source:
repository: ghcr.io/ringods/pulumi-resource
tag: v0.4.0
Concourse will now know about the resource type called pulumi
in your list of resources.
Every stack you want to manage in your pipeline needs to be registered as a resource in your pipeline. Each stack is identified by the following 3 properties, extended with authentication credentials:
organization
: Required. The name of the organization you use on the Pulumi platform.project
: Required. The name of your Pulumi project.stack
: Required. Name of the stack to manage, e.g. staging
.token
: Required. Access token which will be used to login on the Pulumi platform. Use Concourse Credential Management to keep your token safe!resources:
- name: my-staging-network
type: pulumi
source:
organization: companyname
project: network
stack: staging
token: pul-XXXXXXXXXXXXXXXXX
check
: Check for new infrastructure deploymentsThis uses a non-public REST endpoint on the hosted platform, authenticated with the provided
access token, to check for new revisions of the configured stack. The check
step filters out
failed deployments and will only provide new versions for successful deploys.
in
: Get the details of a new infrastructure revisionYou can use a Pulumi resource in a get
step to act as a trigger for downstream builds.
This triggering will happen once the check
step finds new succesful deploys of the
configured stack.
The details of this new infrastructure revision are not yet provided for downstream processing.
- name: after-update-of-my-staging-network
plan:
- get: my-staging-network
trigger: true
- task: do-something-after-deploying-staging-network-stack
...
out
: run pulumi to deploy the latest infrastructure codeUse a pulumi resource in a put
step if you want to run pulumi in your infrastructure code via Concourse.
Pulumi can use different language runtimes. The amount of possibilities in language runtime, language runtime version as well as additional tools on the side makes it sheer impossible to provide that all within the container image for this resource type. Therefor, this resource type is implemented in a way that you can pass your custom runtime image via config.
runtime
: should point to a registry-image
resource containing your specific language runtime,sources
: should point to an input retrieved via get
or to an output
from a previous step.config
: this section may contain any valid configuration which you would normally put in yourPulumi.<stack>.yaml
file. Secrets are not yet supported.env
: this section may contain environment variables which are needed. E.g., for authenticationLet's show this at work with an example of a NodeJS based Pulumi stack:
Pipeline file:
resources:
- name: nodejs14
type: registry-image
source:
repository: node
- name: myinfracode
type: git
uri: [email protected]:owner/myinfracode.git
branch: main
- name: my-staging-network
type: pulumi
source:
organization: companyname
project: network
stack: staging
token: pul-XXXXXXXXXXXXXXXXX
jobs:
- name: update-infra
plan:
- get: myinfracode
trigger: true
- get: nodejs14
- task: npm-install
image: nodejs14
input_mapping: { code: myinfracode }
file: code/npm-install.yml
- put: my-staging-network
params:
runtime: nodejs14
sources: code
config:
network:setting1: value1
network:setting2: value2
env:
CLOUD_PROVIDER_CREDENTIALS: |
{
"private_key_id": "<private key id string>",
"private_key": "<private key string here>",
...
}
CLOUD_PROVIDER_REGION: value1
CLOUD_PROVIDER_ZONE: value2
The example task file:
---
platform: linux
inputs:
- name: code
outputs:
- name: code
run:
path: /bin/bash
args:
- -c
- |
set -euo pipefail
cd ./code
npm ci
The resources section contains 3 resources:
nodejs14
: a container image for NodeJS 14 and support tools like npm or yarn.myinfracode
: a git resource pointing to your Pulumi code in a git repository,main
my-staging-network
: the pulumi resource pointing to our staging network stack.We then create a job which does 4 steps:
get: myinfracode
step.get: nodejs14
step. Do not forget to get
your runtimeput
step.npm install
first on the retrieved code using the nodejs14
image as the containerget
resource, you still have your clean sources.Pulumi.<stack>.yaml
file residing in the source repositoryTo wire all the pieces together, here is a full example combining all the previous snippets together:
resource_types:
- name: pulumi
type: registry-image
source:
repository: ghcr.io/ringods/pulumi-resource
tag: v0.2.0
resources:
- name: nodejs14
type: registry-image
source:
repository: node
- name: myinfracode
type: git
uri: [email protected]:owner/myinfracode.git
branch: master
- name: my-staging-network
type: pulumi
source:
organization: companyname
project: network
stack: staging
token: pul-XXXXXXXXXXXXXXXXX
jobs:
- name: update-infra
plan:
- get: myinfracode
trigger: true
- get: nodejs14
- task:
image: nodejs14
input_mapping: { code: myinfracode }
file: code/npm-install.yml
- put: my-staging-network
params:
runtime: nodejs14
sources: code
config:
network:setting1: value1
network:setting2: value2
env:
CLOUD_PROVIDER_CREDENTIALS: |
{
"private_key_id": "<private key id string>",
"private_key": "<private key string here>",
...
}
CLOUD_PROVIDER_REGION: value1
CLOUD_PROVIDER_ZONE: value2
- name: after-update-infra
plan:
- get: my-staging-network
trigger: true
- task: do-something-after-rolling-out-network-stack
...