<p>The preferred way is to use helm and create a chart. Helm practically generates your manifests based on templates.</p>

CC BY-SA 4.0
2020-11-24T12:04:05.830Z
2020-11-24T12:04:05.830Z
Kroustou
<p>YAML anchors are supported, but only for the same YAML file. You can't create the anchor (<code>&amp;</code>) on a deployment file and reference (<code>*</code>) the value on another one.</p>
<p>If you want to share ENVs values across multiple Deployments, you can create a ConfigMap with the ENVs and use the <a href="https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/#configure-all-key-value-pairs-in-a-configmap-as-container-environment-variables" rel="noreferrer"><code>envFrom</code></a> spec. Example:</p>
<pre><code>apiVersion: v1
kind: ConfigMap
metadata:
  name: my-configmap
data:
  FIRST_ENV: my-value
  SECOND_ENV: another-value
---  
apiVersion: apps/v1
kind: Deployment
metadata:
  name: beat
spec:
  selector:
    matchLabels:
      app: beat
  template:
    metadata:
      labels:
        app: beat
    spec:
      containers:
      - name: beat
        image: myimage
        command: [&quot;celery&quot;, &quot;-A&quot;, &quot;wsgi.celery&quot;, &quot;beat&quot;]
        envFrom:
        - configMapRef:
            name: my-configmap
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: flower
spec:
  selector:
    matchLabels:
      app: flower
  template:
    metadata:
      labels:
        app: flower
    spec:
      containers:
      - name: flower
        image: myimage
        command: [&quot;celery&quot;, &quot;flower&quot;, &quot;-A&quot;, &quot;wsgi.celery&quot;]
        envFrom:
        - configMapRef:
            name: my-configmap
</code></pre>

CC BY-SA 4.0
2020-11-27T14:46:52.727Z
thanks, that's exactly what I was looking for
Most Wanted
CC BY-SA 4.0
2020-11-26T13:05:13.023Z
2020-11-26T13:05:13.023Z
Eduardo Baitello
<p>I have a <code>deployment.yaml</code> file and want to reuse the environment for all my deployments like this:</p>
<pre><code>apiVersion: apps/v1
kind: Deployment
metadata:
  name: beat
spec:
  selector:
    matchLabels:
      app: beat
  template:
    metadata:
      labels:
        app: beat
    spec:
      containers:
      - name: beat
        image: myimage
        command: [&quot;celery&quot;, &quot;-A&quot;, &quot;wsgi.celery&quot;, &quot;beat&quot;]
        env: &amp;default
        - name: FIRST_ENV
          value: my-value
        - name: SECOND_ENV
          value: another-value
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: flower
spec:
  selector:
    matchLabels:
      app: flower
  template:
    metadata:
      labels:
        app: flower
    spec:
      containers:
      - name: flower
        image: myimage
        command: [&quot;celery&quot;, &quot;flower&quot;, &quot;-A&quot;, &quot;wsgi.celery&quot;]
        env: *defaultenv
</code></pre>
<p>But it seems like <code>kubectl apply -f deployment.yaml</code> won't work with YAML anchors.</p>
<pre><code>error: error parsing deployment.yaml: error converting YAML to JSON: yaml: unknown anchor 'defaultenv' referenced
</code></pre>
<p>Is it possible to use YAML anchors or is there another preferred approach of how to reuse repeating blocks for k8s configuration?</p>

CC BY-SA 4.0
2021-03-03T00:48:23.060Z
This looks like a simple typo.  Your anchor is defined as `&default` but you're accessing it as `*defaultenv`.
Mr. Llama
CC BY-SA 4.0
2023-03-08T16:09:10.897Z
This works for me.  I just asked this question (incorrectly?) over on SO, https://stackoverflow.com/q/75675324/500902.  Actually I'm not sure - its a  different use.
Marvin
CC BY-SA 4.0
2023-03-08T16:16:42.887Z
Ok, this doesn't work - even if they are in the same FILE (separated by `---`), they are different YAML docs, which don't allow anchors to span.
Marvin
<kubernetes><deployment><yaml><kubectl>
Kubernetes configuration with yaml anchors
Most Wanted
# Kubernetes configuration with yaml anchors

(Asked by: username_0 on 2020-11-24)

I have a deployment.yaml file and want to reuse the environment for all my deployments like this:
apiVersion: apps/v1
kind: Deployment
metadata:
  name: beat
spec:
  selector:
    matchLabels:
      app: beat
  template:
    metadata:
      labels:
        app: beat
    spec:
      containers:
      - name: beat
        image: myimage
        command: ["celery", "-A", "wsgi.celery", "beat"]
        env: &default
        - name: FIRST_ENV
          value: my-value
        - name: SECOND_ENV
          value: another-value
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: flower
spec:
  selector:
    matchLabels:
      app: flower
  template:
    metadata:
      labels:
        app: flower
    spec:
      containers:
      - name: flower
        image: myimage
        command: ["celery", "flower", "-A", "wsgi.celery"]
        env: *defaultenv

But it seems like kubectl apply -f deployment.yaml won't work with YAML anchors.
error: error parsing deployment.yaml: error converting YAML to JSON: yaml: unknown anchor 'defaultenv' referenced

Is it possible to use YAML anchors or is there another preferred approach of how to reuse repeating blocks for k8s configuration?

**Tags:** kubernetes, deployment, yaml, kubectl

> **Comments:**
> **username_1**: This looks like a simple typo.  Your anchor is defined as `&default` but you're accessing it as `*defaultenv`.  
> **username_2**: This works for me.  I just asked this question (incorrectly?) over on SO, https://stackoverflow.com/q/75675324/500902.  Actually I'm not sure - its a  different use.  
> **username_2**: Ok, this doesn't work - even if they are in the same FILE (separated by `---`), they are different YAML docs, which don't allow anchors to span.  

---

## 2 answers

### Answer by username_4 on 2020-11-26. Score: 9 | Accepted answer

YAML anchors are supported, but only for the same YAML file. You can't create the anchor (&) on a deployment file and reference (*) the value on another one.
If you want to share ENVs values across multiple Deployments, you can create a ConfigMap with the ENVs and use the envFrom spec. Example:
apiVersion: v1
kind: ConfigMap
metadata:
  name: my-configmap
data:
  FIRST_ENV: my-value
  SECOND_ENV: another-value
---  
apiVersion: apps/v1
kind: Deployment
metadata:
  name: beat
spec:
  selector:
    matchLabels:
      app: beat
  template:
    metadata:
      labels:
        app: beat
    spec:
      containers:
      - name: beat
        image: myimage
        command: ["celery", "-A", "wsgi.celery", "beat"]
        envFrom:
        - configMapRef:
            name: my-configmap
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: flower
spec:
  selector:
    matchLabels:
      app: flower
  template:
    metadata:
      labels:
        app: flower
    spec:
      containers:
      - name: flower
        image: myimage
        command: ["celery", "flower", "-A", "wsgi.celery"]
        envFrom:
        - configMapRef:
            name: my-configmap

> **Comments:**
> **username_0**: thanks, that's exactly what I was looking for  

---

### Answer by username_3 on 2020-11-24. Score: 0

The preferred way is to use helm and create a chart. Helm practically generates your manifests based on templates.


---

