<p>I've a NextJS app which needs a .env file mounted. I usually do this with providing a configMap:</p>
<pre class="lang-yaml prettyprint-override"><code>kind: ConfigMap
apiVersion: v1
metadata:
  name: frontend-configmap
  namespace: default
data:
  .env: |-
    NEXT_PUBLIC_API_URL=http://my.domain.com
    API_URL=http://my.domain.com
</code></pre>
<p>But how to do this with Kustomize?</p>
<p>I try it with <code>envs</code>, but how do I get the values inside?</p>
<pre class="lang-yaml prettyprint-override"><code>configMapGenerator:
  - name: frontend-configmap
    envs:
      - .env

</code></pre>
<p>Thank you in advance</p>

Jan
<p>You need to have <code>.env</code> file created first. And ideally even creating configmaps should be based on the existing file (below are examples for <code>kustomize</code> and <code>kubectl --from-file</code>).</p>
<p>Then there are two options how to create a configmap:</p>
<ul>
<li>create <code>.env</code> file with environment variables within (which is your example configmap)</li>
<li>create a configmap with environment variables from <code>.env</code> file (each variable is a separate key)</li>
</ul>
<p><strong>Test structure</strong>:</p>
<pre><code>$ tree -a
.
├── .env
└── kustomization.yaml


$ cat .env # same as your test data

NEXT_PUBLIC_API_URL=http://my.domain.com
API_URL=http://my.domain.com
</code></pre>
<hr />
<p><strong>configmap with <code>.env</code> file with envvars inside:</strong></p>
<p><code>kustomization.yaml</code> with an additional option :</p>
<pre><code>$ cat kustomization.yaml 

configMapGenerator:
  - name: frontend-configmap
    files: # using files here as we want to create a whole file
      - .env
generatorOptions:
  disableNameSuffixHash: true # use a static name
</code></pre>
<p><code>disableNameSuffixHash</code> - disable appending a content hash suffix to the names of generated resources, see <a href="https://github.com/kubernetes-sigs/kustomize/blob/master/examples/generatorOptions.md#generator-options" rel="noreferrer">generator options</a>.</p>
<p>And all left is to run it:</p>
<pre><code>$ kustomize build .

apiVersion: v1
data:
  .env: | # you can see it's a file with context within
    NEXT_PUBLIC_API_URL=http://my.domain.com
    API_URL=http://my.domain.com
kind: ConfigMap
metadata:
  name: frontend-configmap
</code></pre>
<p>The same result can be achieved by running using <code>--from-file</code> option:</p>
<pre><code>$ kubectl create cm test-configmap --from-file=.env --dry-run=client -o yaml

apiVersion: v1
data:
  .env: |
    NEXT_PUBLIC_API_URL=http://my.domain.com
    API_URL=http://my.domain.com
kind: ConfigMap
metadata:
  creationTimestamp: null
  name: test-configmap
</code></pre>
<hr />
<p><strong>configmap with envvars as keys within:</strong></p>
<pre><code>$ cat kustomization.yaml 

configMapGenerator:
  - name: frontend-configmap
    envs: # now using envs to create a configmap with envvars as keys inside
      - .env
generatorOptions:
  disableNameSuffixHash: true # use a static name
</code></pre>
<p>Run it to see the output:</p>
<pre><code>$ kustomize build .

apiVersion: v1
data: # you can see there's no file and keys are created directly
  API_URL: http://my.domain.com
  NEXT_PUBLIC_API_URL: http://my.domain.com
kind: ConfigMap
metadata:
  name: frontend-configmap
</code></pre>
<p>Same with <code>kubectl</code> and <code>--from-env-file</code> option:</p>
<pre><code>$ kubectl create cm test-configmap --from-env-file=.env --dry-run=client -o yaml

apiVersion: v1
data:
  API_URL: http://my.domain.com
  NEXT_PUBLIC_API_URL: http://my.domain.com
kind: ConfigMap
metadata:
  creationTimestamp: null
  name: test-configmap
</code></pre>
<hr />
<p><strong>More details:</strong></p>
<ul>
<li><a href="https://kubernetes.io/docs/tasks/manage-kubernetes-objects/kustomization/#configmapgenerator" rel="noreferrer">configMapGenerator</a></li>
</ul>
<hr />
<p><strong>Edit - use already existing configmap.yaml</strong></p>
<p>If <code>configmap</code> already exists, then it's possible to reference to it from <code>kustomization.yaml</code> (as mentioned in comment, <code>kustomize</code> is a template engine and using it with this direct reference only without any transformations doesn't really make sense. <a href="https://kubectl.docs.kubernetes.io/guides/example/multi_base/" rel="noreferrer">Here</a> is one of the examples of why you need to use <code>kustomize</code>).</p>
<pre><code>$ tree
.
├── cm.yaml
└── kustomization.yaml
</code></pre>
<p><code>cm.yaml</code> has exactly the same config from the question.</p>
<pre><code>$ cat kustomization.yaml
 
resources:
- cm.yaml
namePrefix: test- # used namePrefix for demo purpose (you can omit it as well)
</code></pre>
<p>Building this and getting the same <code>configmap</code> with <code>.env</code> file inside:</p>
<pre><code>$ kustomize build .

apiVersion: v1
data:
  .env: |-
    NEXT_PUBLIC_API_URL=http://my.domain.com
    API_URL=http://my.domain.com
kind: ConfigMap
metadata:
  name: test-frontend-configmap # name with prefix as it was setup for demo
  namespace: default
</code></pre>
