Quarkus: Docs: Briefly explain how Configuration via K8s ConfigMap works

[vorburger]

The Kubernetes Guide alludes to _"the configuration support allows mounting the application configuration using config map",_ and while reading the doc for the first time it would have seemed useful to me to have a paragraph in the Configuration Guide at least briefly elaborating on that? E.g. how do you have to name the ConfigMap and what not...

What would be REALLY cool for bonus points would be an IT in the protean-quickstarts/application-configuration which actually illustrates and exercises this. Not sure how to write an IT for k8s, but AFAIK there was some stuff in Arquillian and/or fabric8 somewhere for this? (I wasn't around at the time.)

[cescoffier]

Right, this is not yet explained how the config map can provide the configuration.

[csotiriou]

Is there any update to this? I am scratching my head on how this can work, the smallrye microprofile config also does not have any definitive solution/documentation for this.

[owennewo]

I can stitch a solution together but docs would be helpful.

Here are my thoughts/solution

• quarkus main config story is application.properties typically found in src/main/resources. This file gets copied into package jar (or embedded in graal binary)
• quarkus has an undocumented feature that prefers to use an external properties file workingdir/config/application.properties if present
• the Dockerfile.jvm's working dir (by default) is '/deployments'
• the Dockerfile.native's working dir is '/work'
• if you use standard kubernetes volume mounts you can mount a kubenetes secret or configmap 'in the right place' for quarkus i.e. /deployments/config/application.properties or /work/config/application.properties
• the properties are layered e.g. you only need to override properties that are different

Example configmap

apiVersion: v1
kind: ConfigMap
metadata:
  name: quarkus-config
data:
  application.properties: |-
    greeting.message=Overriden message

Example deployment

apiVersion: extensions/v1beta1                                      
kind: Deployment                                                    
metadata:                                                           
  labels:                                                           
    app: quarkus-websockets                                         
  name: quarkus-websockets                                          
spec:                                                               
  replicas: 1                                                       
  selector:                                                         
    matchLabels:                                                    
      app: quarkus-websockets                                       
  template:                                                         
    metadata:                                                       
      labels:                                                       
        app: quarkus-websockets                                     
    spec:                                                           
      containers:                                                   
      - image: XXXXXXX/quarkus-websocket:latest
        imagePullPolicy: Always                                     
        name: quarkus-websockets                                    
        volumeMounts:                                               
        - name: quarkus-config-volume                               
          mountPath: /deployments/config                            
      restartPolicy: Always                                         
      volumes:                                                      
        - name: quarkus-config-volume                               
          configMap:                                                
            name: quarkus-config

[ppalaga]

This needs to get addressed. Due Secrets and ConfigMaps usage not being documented properly, we loose in comparisons against Micronaut - see https://speakerdeck.com/fbascheper/2020-a-space-odyssey-with-micronaut-and-quarkus?slide=29

[sebastienblanc]

This needs to get addressed. Due Secrets and ConfigMaps usage not being documented properly, we loose in comparisons against Micronaut - see https://speakerdeck.com/fbascheper/2020-a-space-odyssey-with-micronaut-and-quarkus?slide=29

+1 I was also triggered by the K8S guide mentioning support of ConfigMap and I could not find anything in the Configuration guide.

[maxandersen]

@sebastienblanc now you got a blog out on it could you be up for updating the quarkus kubernetes guide ?

[sebastienblanc]

@maxandersen I can but what is the good approach / best practice approach ? The on is describe in my blogpost or mounting the configMap as a file as described here https://github.com/quarkusio/quarkus/issues/305#issuecomment-516830160 ?

[maxandersen]

@maxandersen I can but what is the good approach / best practice approach ? The on is describe in my blogpost or mounting the configMap as a file as described here #305 (comment) ?

Yeah that’s the question - I started #6745 to get the solution and a corresponding maili thread on the quarkus group - but until then I think it would be good to get the approaches documented. lets see what the mail thread reveals or if @dmlloyd can confirm or deny the approach described #305 (comment)

As functionally that appraoch seems more flexible at my first hunch.

[dmlloyd]

I can stitch a solution together but docs would be helpful.

Here are my thoughts/solution

• quarkus main config story is application.properties typically found in src/main/resources. This file gets copied into package jar (or embedded in graal binary)

Sort of... it's complicated.

• quarkus has an undocumented feature that prefers to use an external properties file workingdir/config/application.properties if present

Is it undocumented? That behavior has been there since almost the very beginning...

• the Dockerfile.jvm's working dir (by default) is '/deployments'
• the Dockerfile.native's working dir is '/work'
• if you use standard kubernetes volume mounts you can mount a kubenetes secret or configmap 'in the right place' for quarkus i.e. /deployments/config/application.properties or /work/config/application.properties
• the properties are layered e.g. you only need to override properties that are different

Would it not be easier to support FileSystemConfigSource, which was designed specifically for the purpose of supporting config maps? Would this simplify the Kubernetes configuration?

[radcortez]

I've made an example on how to use FileSystemConfigSource in SmallRye Config with Kubernetes ConfigMap. It should be the same in Quarkus:
https://github.com/smallrye/smallrye-config/tree/master/examples/configmap

Quarkus does have some additional support as well:
https://quarkus.io/guides/kubernetes-config

[ppalaga]

https://quarkus.io/guides/kubernetes-config is a sufficient fix and this issue can be closed IMO.

[radcortez]

Great!