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 — renderstazuna.yamlas a Go template and embeds the environment name passed via-e/--environmentas its value. spec.environments— declarescontext_matchesper 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 stagingruns only when the current-context isstaging-tokyoorstaging-osaka. It aborts for any other context.tazuna apply -e productionruns only when the current-context isprod-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
| Goal | Mechanism |
|---|---|
| Substitute values / paths by environment name | {{ .Environment }} |
| Restrict target clusters per environment | spec.environments[].context_matches |
| Validate environment configuration before applying | tazuna check -e <name> |