Answers: <p>The preferred way is to use helm and create a chart. Helm practically generates your manifests based on templates.</p>
  
Answers: CC BY-SA 4.0
Answers: 2020-11-24T12:04:05.830Z
Answers: 2020-11-24T12:04:05.830Z
Answers: Kroustou
Answers: <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>
  
Answers: CC BY-SA 4.0
Answers: 2020-11-27T14:46:52.727Z
Answers: thanks, that's exactly what I was looking for
Answers: Most Wanted
Answers: CC BY-SA 4.0
Answers: 2020-11-26T13:05:13.023Z
Answers: 2020-11-26T13:05:13.023Z
Answers: Eduardo Baitello
Body: <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>
  
Comments: CC BY-SA 4.0
Comments: 2021-03-03T00:48:23.060Z
Comments: This looks like a simple typo.  Your anchor is defined as `&default` but you're accessing it as `*defaultenv`.
Comments: Mr. Llama
Comments: CC BY-SA 4.0
Comments: 2023-03-08T16:09:10.897Z
Comments: 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.
Comments: Marvin
Comments: CC BY-SA 4.0
Comments: 2023-03-08T16:16:42.887Z
Comments: 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.
Comments: Marvin
Tags: <kubernetes><deployment><yaml><kubectl>
Title: Kubernetes configuration with yaml anchors
UserDisplayName: Most Wanted
ThreadText: # 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`](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/#configure-all-key-value-pairs-in-a-configmap-as-container-environment-variables) 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.
  
  
  ---
  
  