6

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?

Eduardo Baitello
  • 961
  • 8
  • 26
Most Wanted
  • 671
  • 8
  • 18
  • 1
    This looks like a simple typo. Your anchor is defined as &default but you're accessing it as *defaultenv. – Mr. Llama Mar 03 '21 at 00:48
  • 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 Mar 08 '23 at 16:09
  • 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 Mar 08 '23 at 16:16

2 Answers2

8

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
Eduardo Baitello
  • 961
  • 8
  • 26
0

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

Kroustou
  • 121
  • 2