Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Switch Configuration per Environment

It is common to want to reuse a single tazuna.yaml across multiple clusters such as staging / production. Tazuna supports this with the following two mechanisms.

  • The {{ .Environment }} template variable — renders tazuna.yaml as a Go template and embeds the environment name passed via -e/--environment as its value.
  • spec.environments — declares context_matches per environment, and switches which clusters may be applied to based on the value of the environment selected with -e.

This guide walks through combining these two so that you can switch overlays per environment while preventing application to the wrong cluster. For the full specification, see tazuna.yaml schema - environments / Template variables.

1. Embed {{ .Environment }}

First, switch the manifest path by environment name.

apiVersion: tazuna.pepabo.com/v1
kind: Tazuna
spec:
  manifests:
    - name: app
      type: kustomize
      path: ./overlays/{{ .Environment }}

Passing -e staging renders path as ./overlays/staging, and -e production as ./overlays/production.

$ tazuna build -e staging   # ./overlays/staging をレンダリング
$ tazuna build -e production # ./overlays/production をレンダリング

If you do not pass -e, {{ .Environment }} expands to an empty string (in this example, path: ./overlays/). Since rendering happens for every command that reads tazuna.yaml, it is a good idea to check the result with build before running apply.

2. Restrict Target Clusters per Environment

Template variables alone cannot prevent accidents such as applying a production configuration to the staging cluster by mistake. To handle that, declare context_matches (a regular expression for the allowed kubeconfig context names) per environment under spec.environments.

apiVersion: tazuna.pepabo.com/v1
kind: Tazuna
spec:
  environments:
    staging:
      context_matches:
        - ^staging-tokyo$
        - ^staging-osaka$
      context_match_mode: or
    production:
      context_matches:
        - ^prod-tokyo$
      context_match_mode: and
  manifests:
    - name: app
      type: kustomize
      path: ./overlays/{{ .Environment }}
  • tazuna apply -e staging runs only when the current-context is staging-tokyo or staging-osaka. It aborts for any other context.
  • tazuna apply -e production runs only when the current-context is prod-tokyo.

If the environment corresponding to -e is not declared under environments, apply / destroy / check fail with an error. This also prevents mis-application caused by typos.

3. Pre-validate With check

In addition to rendering and validating tazuna.yaml, tazuna check -e <name> also verifies that the specified environment exists under environments. Running tazuna check -e production in CI lets you detect configuration mistakes before applying to production.

$ tazuna check -e production
$ tazuna check -e typo-env
error: environment "typo-env" is not declared under spec.environments

When You Do Not Pass -e (Local Development)

If you omit -e, environments is ignored and the top-level context_matches / context_match_mode are used. You can, for example, keep settings for a local kind cluster at the top level while placing staging / production under environments.

spec:
  context_matches:
    - ^kind-        # used for local runs without -e
  environments:
    staging:
      context_matches: [^staging-]
    production:
      context_matches: [^prod-]
  manifests:
    - name: app
      type: kustomize
      path: ./overlays/{{ .Environment }}

Summary

GoalMechanism
Substitute values / paths by environment name{{ .Environment }}
Restrict target clusters per environmentspec.environments[].context_matches
Validate environment configuration before applyingtazuna check -e <name>