Convert docker-compose env files into configmaps

[ghost]

Convert docker-compose env files

Context

When it comes to application development, our dev teams tend to want to use docker-compose for its simplicity. However we deploy to kuberentes as our runtime environment of choice.

kompose seems to be the right tool for the job. It is fast, clean, and comprehensive.

Problem Statement

At current out dev teams have not taken to minikube and so we need a solution to handle conversion.

We are using a combination of tools like github.com/kelseyhightower/compose2kube and github.com/dhoer/k8s-env-gen. It would be great to leverage a tool like kompose to handle all of these things in a single package.

Looking for a cleaner solution, something comprehensive and not custom managed. I tried to convert an existing project that contains docker compose env files and received the following warning.

I also found issue #30 which would relate to the scope of this request as well.

Solution

I'm proposing adding support for docker-compose env file translation.

[dhoer]

@johnt337 How would one determine if env-file was a secret or not? I would think all env-files would have to be a configmap.

[sebgoa]

Agreed. I think we can do this with a default configmap.

Dealing with secrets would be a different issue, especially that proper secret mgt is coming in Docker.

[dhoer]

When kubernetes/kubernetes#37295 is released (k8s v1.6 release?), it would be nice for env_file entries to get converted to configmaps, and deployment yaml to get updated with envFrom configMap entries.

[ghost]

@sebgoa OK make sense. @dhoer yea I agree since docker does not have this in functional form.
I see docker is incubating the idea moby/moby#13490 so this might help outline how kompose could deduce the difference (down the road).

Also see docker/compose#1534 (comment).

Would a flag specifying what file(s) or regex to use for scanning/rendering secrets be allowable in the short term?

[dhoer]

@johnt337 Should this issue be broken into 2 issues? One for env_file entries and the other on handling secrets?

[so0k]

At current out dev teams have not taken to minikube and so we need a solution to handle conversion

Do you see an evolution towards using Minikube locally? We're still at a stage where dev teams haven't adopted anything right now. I was playing with the idea of skipping the compose step and use Minikube as suggested.. We are using Helm Charts for everything and this would mean a Helm chart that takes parameters to run on a single-node Minikube install as well as a fine-tuned Prod install... and it just doesn't make sense to me.

Makes more sense to have a simplified stack in compose and a hand crafted Helm Chart for deployment to the cluster (something Kompose can't help with at all, btw)

[surajssd]

@so0k what are you trying to suggest here? Something where kompose can improve?

[cdrage]

Hi @johnt337 I've gone ahead and changed the title to ConfigMaps since we have another issue opened in regards to secrets #296 .

This is something we'd like to have on the Kompose roadmap and I've gone ahead and marked it as a milestone for a future release.

[cdrage]

With #799 merged in, this can be finally closed! env_file has been added to Kompose.

We've also coincided this with the release of Kompose 1.3.0

Feel free to check it out @johnt337 @so0k and @dhoer

[ghost]

@cdrage Thanks!! Will do!