defining configmap/secret data in a way that auto-creates the container env vars

[jstrachan]

so defining configmaps and exposing them as env vars is very painful. e.g. this:

name: web
replicas: 1
containers:
- image: wordpress:4
  env:
  - name: WORDPRESS_DB_PASSWORD
    valueFrom:
      secretKeyRef:
        name: wordpress
        key: DB_PASSWD
  - name: WORDPRESS_DB_NAME
    valueFrom:
      configMapKeyRef:
        key: MYSQL_DATABASE
        name: database
  - name: WORDPRESS_DB_HOST
    valueFrom:
      configMapKeyRef:
        key: WORDPRESS_DB_HOST
        name: web
  - name: WORDPRESS_DB_USER
    valueFrom:
      configMapKeyRef:
        key: MYSQL_USER
        name: database
  livenessProbe:
    httpGet:
      path: /
      port: 80
    initialDelaySeconds: 120
    timeoutSeconds: 5
  readinessProbe:
    httpGet:
      path: /
      port: 80
    initialDelaySeconds: 5
    timeoutSeconds: 2
services:
- name: wordpress
  type: LoadBalancer
  ports:
  - port: 8080
    targetPort: 80
  rules:
  - host: minikube.local
    http:
      paths:
      - backend:
          serviceName: wordpress
          servicePort: 8080
        path: /
configData:
  WORDPRESS_DB_HOST: "database:3306"

we could use magic character prefixes on env vars like $FOO or /bar for files. Maybe separate nested structs could help; as they can also let us define multiple secrets/configmaps too. e.g. here's one way of doing the above:

name: web
replicas: 1
containers:
- image: wordpress:4
  livenessProbe:
    httpGet:
      path: /
      port: 80
    initialDelaySeconds: 120
    timeoutSeconds: 5
services:
- ports:
  - port: 8080
    targetPort: 80
  expose: true   
envSecret:
- name: wordpress
  data:
    WORDPRESS_DB_PASSWORD: something
envConfig:
- name: database    
  data:
    WORDPRESS_DB_NAME: foo
    MYSQL_USER: myuser
- name: web    
  data:
    WORDPRESS_DB_HOST: "database:3306"

where we use envConfig to specify environment variables which populate a ConfigMap and ditto envSecret for secrets.

Note that in the case where there's 1 ConfigMap and 1 Secret it looks like:

name: web
replicas: 1
containers:
- image: wordpress:4
  livenessProbe:
    httpGet:
      path: /
      port: 80
    initialDelaySeconds: 120
    timeoutSeconds: 5
services:
- ports:
  - port: 8080
    targetPort: 80
  expose: true   
envSecret:
- data:
    WORDPRESS_DB_PASSWORD: something
envConfig:
- data:
    WORDPRESS_DB_NAME: foo
    MYSQL_USER: myuser
- data:
    WORDPRESS_DB_HOST: "database:3306"

also since we have nested structs for the secret / config map data we can also add an extra map for files

containers:
- image: wordpress:4
 envSecret:
- data:
    WORDPRESS_DB_PASSWORD: something
  files:
   pub.ssh.key: ~/.ssh/foo_rsa.pub
envConfig:
- data:
    WORDPRESS_DB_NAME: foo
    MYSQL_USER: myuser
  files:
    application.properties: target/classes/application.properties

[jstrachan]

if folks wanted to work with multiple configmaps/secrets and want to make the exposing as env vars more container specific they could maybe do this kinda thing, nesting them inside the container...

name: foo
replicas: 1
containers:
- name: wordpress
  image: wordpress:4
  livenessProbe:
    httpGet:
      path: /
      port: 80
    initialDelaySeconds: 120
    timeoutSeconds: 5
  envConfig:
  - data:
      WORDPRESS_DB_HOST: "database:3306"        
  envSecret:
  - data:
      WORDPRESS_DB_PASSWORD: something
- name: database
  image: postgres
  envConfig:
  - data:
      WORDPRESS_DB_NAME: foo
      MYSQL_USER: myuser
services:
- ports:
  - port: 8080
    targetPort: 80
  expose: true   

where the configmaps / secrets would be generated using ${pod.name}-${container.name} by default. e.g. the above would generate foo-wordpress and foo-database ConfigMaps and foo-database Secret

[jstrachan]

I guess for files there's 2 separate concerns; importing data from local files; then mounting configmap/secret entries as volumes. I guess you can always do an explicit mount of the latter; but it might be nice to have some kinds of mounts within the envConfig / envSecret?

[jstrachan]

another implementation idea is that we keep the definitions of configmaps / secrets as top level things; then we have a way to import env vars inside the container structs; using wildcards?

name: web
replicas: 1
containers:
- image: wordpress:4
  envValuesFrom:
  - kind: Secret
    imports:
    - FOO_BAR
    - WHATNOT_*
  - kind: ConfigMap
    name: cheese
  livenessProbe:
    httpGet:
      path: /
      port: 80
    initialDelaySeconds: 120
    timeoutSeconds: 5
services:
- ports:
  - port: 8080
    targetPort: 80
  expose: true   
secrets:
- name: wordpress
  data:
    WORDPRESS_DB_PASSWORD: something
configs:
- name: database    
  data:
    WORDPRESS_DB_NAME: foo
    MYSQL_USER: myuser
  files:
    cheese: ../foo/bar.txt
- name: web    
  data:
    WORDPRESS_DB_HOST: "database:3306"

whats kinda nice about the import approach is we can more easily do container specific imports with wildcards; we can default the name of the configmap/secret to the app name too to make things more concise.

e.g. when there's only 1 Secret and ConfigMap (which would be the common default) its like this:

name: web
replicas: 1
containers:
- image: wordpress:4
  envValuesFrom:
  - kind: Secret
    imports:
    - FOO_BAR
    - WHATNOT_*
  - kind: ConfigMap
  livenessProbe:
    httpGet:
      path: /
      port: 80
    initialDelaySeconds: 120
    timeoutSeconds: 5
services:
- ports:
  - port: 8080
    targetPort: 80
  expose: true   
secrets:
- data:
    WORDPRESS_DB_PASSWORD: something
configs:
- data:
    WORDPRESS_DB_HOST: "database:3306"
    WORDPRESS_DB_NAME: foo
    MYSQL_USER: myuser
  files:
    cheese: ../foo/bar.txt

with an optional imports structure to list the names or wildcards to import; so you can list all the values imported; or use wildcards (if no imports I guess default to all values?)

[jstrachan]

I wonder if merging the kind field into a nested structure is cleaner - it does mean we need to add the 'import:' or 'name:' field though...

name: web
replicas: 1
containers:
- image: wordpress:4
  envValuesFromSecrets:
  - imports:
    - *
  envValuesFromConfigMaps:
  - imports:
    - *
  livenessProbe:
    httpGet:
      path: /
      port: 80
    initialDelaySeconds: 120
    timeoutSeconds: 5
services:
- ports:
  - port: 8080
    targetPort: 80
  expose: true   
secrets:
- data:
    WORDPRESS_DB_PASSWORD: something
configs:
- data:
    WORDPRESS_DB_HOST: "database:3306"
    WORDPRESS_DB_NAME: foo
    MYSQL_USER: myuser
  files:
    cheese: ../foo/bar.txt

or

name: web
replicas: 1
containers:
- image: wordpress:4
  envValuesFromSecrets:
  - name: database
  envValuesFromConfigMaps:
  - name: database:
  - name: wordpress
  livenessProbe:
    httpGet:
      path: /
      port: 80
    initialDelaySeconds: 120
    timeoutSeconds: 5
services:
- ports:
  - port: 8080
    targetPort: 80
  expose: true   
secrets:
- data:
    WORDPRESS_DB_PASSWORD: something
configs:
- data:
    WORDPRESS_DB_HOST: "database:3306"
    WORDPRESS_DB_NAME: foo
    MYSQL_USER: myuser
  files:
    cheese: ../foo/bar.txt

[surajssd]

@jstrachan

where we use envConfig to specify environment variables which populate a ConfigMap and ditto envSecret for secrets. src

About the root level envSecret, how do we know which container do we populate it to? We cannot populate it to all the containers?

I am okay with populating configMap like that because it does not have much secret information, but I am skeptical on doing so with secrets.

also since we have nested structs for the secret / config map data we can also add an extra map for files src

I like this idea of allowing users to specify a relative path to embed files and when converting we embed the file content in the configMap.

if folks wanted to work with multiple configmaps/secrets and want to make the exposing as env vars more container specific they could maybe do this kinda thing, nesting them inside the container... src

this will create secrets and configmaps which are container specific, here how do we enable someone else to use the secret defined here?

For e.g. the MYSQL_PASSWORD defined in database will be accessed in wordpress as WORDPRESS_DB_PASSWORD, how do we enable that?

I guess for files there's 2 separate concerns; importing data from local files; then mounting configmap/secret entries as volumes. I guess you can always do an explicit mount of the latter; but it might be nice to have some kinds of mounts within the envConfig / envSecret? src

I think mountPath can go with file as shown below? But if mountPath is not given it get exposed as env variable?

envConfig:
- data:
    WORDPRESS_DB_NAME: foo
    MYSQL_USER: myuser
  files:
    application.properties: target/classes/application.properties
    mountPath: /foo/bar

whats kinda nice about the import approach is we can more easily do container specific imports with wildcards; we can default the name of the configmap/secret to the app name too to make things more concise. src

why do we need to have wildcards when containerSpec now has a key called envFrom? I think we need to look more into how we enable user to import individual key from secret or configmap data respectively?
envFrom: https://kubernetes.io/docs/api-reference/v1.6/#envfromsource-v1-core and https://kubernetes.io/docs/api-reference/v1.6/#container-v1-core

[concaf]

Can we close this since envFrom is supported now?
ping @kadel @surajssd

[surajssd]

Yes I think so we can close this one!