LogoLogo
Bonsai (0.13) DocsGitHubDiscord CommunityGarden Enterprise
Acorn (0.12)
Acorn (0.12)
  • Welcome!
  • 🌳Basics
    • How Garden Works
    • Quickstart Guide
    • The Stack Graph (Terminology)
  • 🌻Tutorials
    • Your First Project
      • 1. Initialize a Project
      • 2. Connect to a Cluster
      • 3. Deploy and Test
      • 4. Configure Your Project
  • 💐Using Garden
    • Configuration Overview
    • Projects
    • Modules
    • Services
    • Tests
    • Tasks
    • Workflows
    • Variables and templating
    • Module Templates
    • Using the CLI
  • 🌿Kubernetes Plugins
    • About
    • Remote K8s Plugin Configuration
      • 1. Create a Cluster
        • AWS
        • GCP
        • Azure
      • 2. Configure Container Registry (Optional)
        • AWS
        • GCP
        • Azure
      • 3. Set Up Ingress, TLS and DNS
      • 4. Configure the Provider
    • Local K8s Plugin Configuration
      • 1. Install Local Kubernetes
      • 2. Configure the Provider
    • Module Configuration
      • Container
      • Kubernetes
      • Helm
      • PersistentVolumeClaim
      • ConfigMap
    • Advanced
      • In-Cluster Building
      • Minimal RBAC Configuration for Development Clusters
      • Deploying to Production
  • 🌺Terraform Plugin
    • About
    • Provider Configuration
    • Module Configuration
  • ☘️Pulumi Plugin
    • About
    • Provider Configuration
    • Module Configuration
  • 🌹Other Plugins
    • Container
    • Exec (local scripts)
  • 🌼Guides
    • Installing Garden
    • Adopting Garden
    • Code Synchronization (Dev Mode)
    • Connecting a local service to a K8s cluster (Local Mode)
    • Environments and namespaces
    • Hot Reload
    • Migrating from Docker Compose to Garden
    • Using Garden in CI
  • 🌷Advanced
    • cert-manager Integration
    • Using Remote Sources
    • Custom Commands
  • 🪷Reference
    • Providers
      • conftest-container
      • conftest-kubernetes
      • conftest
      • container
      • exec
      • hadolint
      • jib
      • kubernetes
      • local-kubernetes
      • maven-container
      • octant
      • openfaas
      • pulumi
      • terraform
    • Module Types
      • configmap
      • conftest
      • container
      • exec
      • hadolint
      • helm
      • jib-container
      • kubernetes
      • maven-container
      • openfaas
      • persistentvolumeclaim
      • pulumi
      • templated
      • terraform
    • Template Strings
      • Project configuration context
      • Environment configuration context
      • Provider configuration context
      • Module configuration context
      • Remote Source configuration context
      • Project Output configuration context
      • Custom Command configuration context
      • Workflow configuration context
      • Template Helper Functions
    • Glossary
    • Commands
    • Project Configuration
    • Module Template Configuration
    • Workflow Configuration
  • 🎋Misc
    • FAQ
    • Troubleshooting
    • Telemetry
Powered by GitBook
On this page
  • Prerequisites
  • Project overview
  • Configure remote environments
  • Configure the kubectl context
  • Running Garden commands in CircleCI

Was this helpful?

  1. Guides

Using Garden in CI

PreviousMigrating from Docker Compose to GardenNextcert-manager Integration

Last updated 1 year ago

Was this helpful?

In this guide we'll demonstrate how Garden can fit into your continuous integration (CI) pipeline. Simply by adding extra environments to the project configuration, you can use Garden for local development and for testing and deploying your project in CI. This approach has several benefits:

  • Use the same tool and the same set of commands for the entire development cycle, from source to finish.

  • No need to change your CI configuration when you change your stack since Garden holds the entire stack graph.

  • The only thing you need to install in CI is the Garden CLI and its dependencies (or use a ready-made Garden container image).

  • When using your CI also uses the same build and test result cache as you and your team, which makes for a much faster pipeline.

To use Garden in your CI pipeline you need the following:

  1. A Garden project, .

  2. A on the CI agent that's configured for the remote cluster.

For the purposes of this example we'll be using and deploying to a Google Kubernetes Engine (GKE) cluster. However, the instructions below can easily be applied to other CI platforms and cloud providers.

The guide uses the example. In what follows we assume that you've read that guide and that you have a running Kubernetes cluster to work with.

Prerequisites

  • A

  • A running Kubernetes cluster that you have API access to

Project overview

The project is based on our basic example, but configured for multiple environments. Additionally it contains a CircleCI config file. You'll find the entire source code .

The CI pipeline is configured so that Garden tests the project and deploys it to a preview environment on every pull request. Additionally, it tests the project and deploys it to a separate staging environment on every merge to the main branch.

To see it in action, you can fork the repository and follow the set-up steps below. Once you've set everything up, you can submit a pull request to the fork to trigger a CircleCI job which in turns deploys the project to your remote Kubernetes cluster.

Configure remote environments

For this project we're using three environments: local, preview and staging. The local environment is the default and is configured for a local Kubernetes cluster that runs on the user's machine. The other two run on remote clusters.

We deploy to the preview environment every time someone makes a pull request on Github. The configuration looks like this:

# garden.yml
kind: Project
name: ci-demo-project
environments:
  ...
  - name: preview
    defaultNamespace: preview-${local.env.CIRCLE_BRANCH || local.username}
providers:
  - name: kubernetes
    environments: [preview]
    context: my-preview-cluster
    defaultHostname: ${environment.namespace}.preview.my-domain
    buildMode: kaniko

Notice that we're using the CIRCLE_BRANCH environment variable to label the project namespace. This ensures that each pull request gets deployed into its own namespace.

The staging environment is configured in a similar manner. The relevant CI job is triggered on merges to the main branch.

Configure the kubectl context

Note: Below we use the gardendev/garden-gcloud container image, that extends the standard gardendev/garden image to bundle the gcloud binary. You could also add an installation step to install gcloud (or any other binaries needed for your setup), or you could fashion your own container image to save time when testing. (You're also more than welcome to ask us to add another pre-packaged container to our release pipeline :))

We create a re-usable command for configuring the kubectl context:

# .circleci/config
commands:
  configure_kubectl_context:
    description: Configure the kubectl context so that we can access our remote cluster
    steps:
      - run:
          name: Configure kubectl context via gcloud
          command: |
            gcloud --quiet components update
            echo $GCLOUD_SERVICE_KEY | gcloud auth activate-service-account --key-file=-
            gcloud --quiet config set project $GCLOUD_PROJECT_ID && gcloud --quiet config set compute/zone $GCLOUD_COMPUTE_ZONE
            gcloud --quiet container clusters get-credentials $GCLOUD_CLUSTER_ID --zone $GCLOUD_COMPUTE_ZONE
            gcloud --quiet auth configure-docker
  • GCLOUD_PROJECT_ID, GCLOUD_COMPUTE_ZONE, and GCLOUD_CLUSTER_ID: These you'll find under the relevant project in your Google Cloud Platform console.

Running Garden commands in CircleCI

Here's what our preview job looks like:

# .circleci/config
jobs:
  preview:
    docker:
      - image: gardendev/garden-gcloud:v0.10.0-1
    environment:
      GARDEN_LOG_LEVEL: debug # set the log level to your preference here
      GARDEN_LOGGER_TYPE: basic # this is important, since the default logger doesn't play nice with CI :)
    steps:
      - checkout
      - configure_kubectl_context
      - run:
          name: Test project
          command: garden test --logger-type=basic --env=preview
      - run:
          name: Deploy project
          command: garden deploy --logger-type=basic --env=preview

Note the two environment variables. Setting GARDEN_LOGGER_TYPE=basic is important, because the default fancy logger will not play nice with CI and just spam it with spinner glyphs.

Also, notice that there are no configuration steps outside of just configuring the kubectl context. And no matter how you change your stack, these steps will remain the same, making for a highly portable workflow—and much less fiddling around with CI!

Configuring Garden to work against a remote Kubernetes cluster is explained step by step in our . For this example, we also use .

You'll find the rest of the config .

We need to make sure that it can access our remote cluster. We do this by setting up a on the CI agent. How you set this up will vary by how and where you have deployed your cluster. What follows is specific to GKE.

The commands use the following environment variables that you can set on the Project Environment Variables page (see ) in the CircleCI dashboard:

GCLOUD_SERVICE_KEY: Follow to get a service account key.

Please refer to this for more information on using the Google Cloud SDK in CircleCI.

You'll find the entire CircleCI config for this project .

Now that we have everything set up, we can to CircleCI and start using Garden in our CI pipelines.

🌼
Remote Kubernetes guide
in-cluster building
here
kubectl context
here
these instructions
doc
here
add the project
in-cluster building
CircleCI
Remote Kubernetes plugin
CircleCI account
demo-project
here
configured to deploy to a remote cluster
Kubectl context