Roadmap: Configmap Support

SophCarp commented 1 year ago

ETA: End of June 2023

ezYakaEagle442 commented 1 year ago

I have a Use Case : Spring Boot App deployed using a ConfigMap instead of the Spring-Config-Server https://github.com/ezYakaEagle442/aks-spring-with-config-map we need ACA to support ConfigMap to ensure a seamless portability between ACA & AKS.

shawndjw commented 1 year ago

I also have a use case for configMaps for a Drupal implementation that my organization is trying to deliver.

tiwood commented 1 year ago

Hi @SophCarp,

I just wanted to know if a public/private preview is available to try this before the actual release? We have a service that could be deployed with ACA instead of AKS, but we would like to have configmap support for easier migration.

mdrakiburrahman commented 1 year ago

Hi @torosent, @SophCarp -

Hope you're well. One of the major blockers we have is our existing Source Code depends heavily on config files being available in privileged directory. In Kubernetes, this was fine, because Kubelet auto-mounts files before Pods start.

Couple questions:

Will the configMap support work similar to Kubernetes;

e.g.:

    spec:
      containers:
       ....
          volumeMounts:
            - name: kafka-properties-vol
              mountPath: /kafka.properties
              subPath: kafka.properties # <---- Can we mount a specific file to subPath?
      volumes:
        - configMap:
            name: otel-agent-conf
          name: kafka-properties-vol

Is this still on track for End-of-June?

torosent commented 1 year ago

@mdrakiburrahman , we will have to delay this feature a bit. The new ETA is summer 2023. Config maps will support volume mount like secret in ACA today with directories or files.

timwebster9 commented 1 year ago

I'm a bit late to the party here, but just wondering what this is going to look like.

One of the things that I'm looking forward to about container apps is the abstraction from Kubernetes. That is, I'm hoping it will be way simpler to configure but retain the functionality and scalability. However it looks like it's mapping a lot of the features like-for-like, right down to the implementation.

With ConfigMaps, most of the use cases I imagine will be to just stick a file into the container filesystem. The use case will be something like "I want to place a file in this directory'. Thus the configuration for this feature could simply be something like:

file: file.txt path in container: /etc/config

I don't want to mess around with volumes, volume mounts, keys, values, etc. Also, unless you have prior k8s experience, you won't even know what a 'ConfigMap' is, nor should you care.

The ingress implementation kind of followed this approach I think, where 'ingress' is really 'k8s services'. Anyways, it would be cool if this followed a similar approach.