Get startedSign in

Plural Stacks

API-Driven Infrastructure As Code CD

The goal of Plural Stacks is to provide a scalable framework to manage infrastructure as code like Terraform, Ansible and Pulumi with a kubernetes-friendly, api-driven approach. The core workflow is as follows:

  • Declaratively define a stack with a type (terraform, ansible, etc), a location in a git repository to source code from, and a cluster on which it will execute
  • On each commit to the tracked git repository, a run is created which the Plural deployment operator will detect and execute on the targeted cluster
    • this allows users to fine grain permissions and network location of IaC runs where both are necessary to configure.
  • Plural will carefully execute the run for you, and besides basic information like communicating stdout to the UI, we will also gather and present useful information like inputs/outputs, terraform state diagrams and more
  • On PRs to the tracked repository, a "plan" run is also executed and comments posted on the relevant PR where possible.

To get a better idea of the full power of the experience, feel free to take a look at this demo video (at 2x speed if you want to save some time):

A Basic Stack

The most common way to instantiate a stack is via Kubernetes CRD. This gives a flexible, modular way of recreating infrastructure with Terraform and pairs nicely with our PR Automation tooling for full self-service around IaC.

Here's an example:

kind: InfrastructureStack
  name: gke-demo
  namespace: stacks
  name: gke-demo
  approval: true
  detach: false
  manageState: true
    version: 1.8.2
    name: fleet
    namespace: fleets
    name: mgmt
    namespace: infra
  workdir: gke-cluster
    ref: main
    folder: terraform
  - mountPath: /plural
      name: gcp-creds
    value: /plural/creds.json
  - name: TF_VAR_cluster
    value: gke-demo
  - name: TF_VAR_tier
    value: dev
  - name: TF_VAR_fleet
    value: gke-dem

The meaning of this yaml is pretty self-documenting, we are:

  • creating a TERRAFORM stack, so it will execute the standard terraform workflow
  • we're using Plural as the state store, removing the need to configure S3 or other backends manually
  • approval will be required before terraform apply will trigger, ensuring a human verifies the plan first to reduce misconfiguration risk
  • we're sourcing manifests from the fleet repository (referencing a GitRepository crd)
  • we're executing on the mgmt cluster (referencing a Cluster crd)
  • and we're executing in the terraform/gke-cluster folder

You can also see you can bind files and environment variables into the environment, although it is still best practice to use IRSA, GKE workload identity or similar mechanisms for issuing cloud credentials.