Garden Documentation

Garden is a DevOps automation tool designed to accelerate the development and testing of Kubernetes applications. It allows teams to spin up production-like environments on demand for development, testing, and CI/CD workflows.

Key benefits include:

• Consistent Configuration: Use the same configuration and workflows across every stage of software delivery.
• Smart Caching: Dramatically speeds up builds and test runs through intelligent caching mechanisms.

The local-kubernetes provider is a specialized version of the kubernetes provider designed to automate and simplify workflows with local Kubernetes clusters.

Use this provider when working with local clusters. For remote Kubernetes clusters, use the standard kubernetes provider instead.

Garden provides a wide range of features and integrations to enhance development workflows:

Core Features

• Remote Container Builder: Offload container builds to remote infrastructure.
• Team Caching: Share build artifacts across your team.
• Code Synchronization: Enable hot-reloading via code syncing.
• Workflows & Matrix Templates: Define complex execution patterns.
• Variables & Secrets: Manage remote variables and secrets securely.

Integrations

• Containers: Build and run containers using remote or local builders.
• Kubernetes: Deploy resources, install Helm charts, and run tests/tasks in K8s.
• Infrastructure as Code: Native support for Terraform and Pulumi stacks.
• Local Scripts: Execute local scripts as part of your workflow.

Garden interacts with Kubernetes clusters using the Kubernetes API and kubectl.

Key operational concepts:

• Isolation: Garden typically uses Kubernetes Namespaces to isolate developer environments, CI tests, and preview environments (this is configurable).
• Task Execution: For tests and tasks, Garden spins up Pods from the specified image to execute the command.
• Live Code Sync: Garden uses Mutagen to synchronize code changes directly into running containers for live development.

Garden supports several providers to manage and deploy infrastructure and applications. You can use these providers to interact with different environments and tools. The available providers are:

• container: Manage container images and runtimes.
• exec: Execute commands directly.
• jib: Build container images using Google's Jib.
• kubernetes: Manage resources in a Kubernetes cluster.
• local-kubernetes: Manage resources in a local Kubernetes environment.
• terraform: Manage infrastructure using Terraform.
• pulumi: Manage infrastructure using Pulumi.

Garden uses smart caching to determine which actions (building, deploying, testing, etc.) need to be re-executed. It calculates a version hash (v-<some hash>) for each action based on:

1. Source files involved in the action.
2. Configuration files involved.
3. Upstream dependencies.

These versions are stored in the Garden Cloud backend, allowing cache hits to be shared across your entire team and across different CI runs. For example, if a pull request triggers multiple tests and you push a commit that only affects files related to one test, only that specific test will re-run; the others will use the cached results.

The Istio example project uses a mix of Garden container actions and Helm actions:

• Container Actions: The details, productpage, and ratings services are implemented as Garden container actions pointing to remote images.
• Helm Actions:
  • The reviews service is deployed via a Helm action to support multiple versions of the service being deployed and routed in a round-robin fashion (a pattern not currently supported by native Garden multiple deployments for a single service).
  • The gateway service is a Helm module that utilizes Custom Resource Definitions (CRDs) from the Istio base chart to configure a VirtualServer and Gateway for routing traffic to the productpage frontend.

The k8s-util image is a utility used by Garden to facilitate synchronization between a local project's source files and a target Kubernetes container when using in-cluster build modes (kaniko or cluster-buildkit).

Key functions include:

• Build Context Sync: It mounts a shared volume used by builder pods to provide an up-to-date build context from the local machine.
• Image Verification: It runs skopeo to check if a specific image has already been built, utilizing a mounted secret to communicate with the container registry.

For organizations looking to standardize workflows across multiple teams, Garden provides several mechanisms for consolidation:

• Config Templates: Author reusable configuration that can be shared across teams to ensure consistency and compliance.
• Custom Commands: Standardize specific workflows by defining custom commands.
• Infrastructure Codification: Integrate with tools like Pulumi or Terraform to include infrastructure provisioning within your Garden-managed delivery process.

Garden provides several Run action types to execute commands within different environments. Depending on your target infrastructure, you can use one of the following actions:

• container: Run commands within a specific container.
• kubernetes-exec: Execute commands in an existing Kubernetes pod using kubectl exec logic.
• kubernetes-pod: Run commands within a new or existing Kubernetes pod.
• helm-pod: Run commands within a pod managed by a Helm release.
• exec: Execute commands directly on the host or within the local environment.