Docker Community Forums

Share and learn in the Docker community.

Docker run time container config

Any opinions on best practices for configuring an application at run time.
Currently, I allow CLI commands and ENV variables.
My entry point script manages these inputs and reinstalls the application with the inputs.
I received feedback to add ENV variables, and I was curious iff there was a best practice or alternatives people tended towards.
https://hub.docker.com/r/harperdb/hdb
Your feedback is appreciated.
Thanks,
Zachary.

The basic docker run command takes this form:

$ docker run [OPTIONS] IMAGE[:TAG|@DIGEST] [COMMAND] [ARG…]
The docker run command must specify an IMAGE to derive the container from. An image developer can define image defaults related to:

detached or foreground running
container identification
network settings
runtime constraints on CPU and memory
With the docker run [OPTIONS] an operator can add to or override the image defaults set by a developer. And, additionally, operators can override nearly all the defaults set by the Docker runtime itself. The operator’s ability to override image and Docker runtime defaults is why run has more options than any other docker command.

Certainly.
I get that. However those are container configurations, save -e and --env-file… which i now support…
I am really trying to get a feel on how people feel about accessing the containers application configurations and how can i best expose those configurations… Then during docker run -e --arg1 value --arg2 value
the application will configure and run with the passed in env or command args…
Seems like those are the best options, Save any configurations that may be available after run time that can be used without restart, which we have exposed with a REST API.
Thank you for you time and diligence.
Please check out https://hub.docker.com/r/harperdb/hdb
and let me know your thoughts.
Cheers!

I put my money on lewish95 beeing a bot or someone who just reads thread titles and respond to those…

One approach is to use a mandatory volume to store your conf files. If you want the users to edit the config files, provide a full description for it. You might want to mix it with the next approach.

Another approach is to prepare ENV variables for the environment specific configuration and render those in or more config files before you start the main process. Every ENV variable should be described, idealy with examples.

Cover docker run and docker-compose.yml style of desciptions. No one experienced in docker sticks to docker run, except for oneshot tests. If your application is design to run with multiple replicas, make sure to provide a docker-compose.yml that supports swarm deployments.

Make sure to design your image in a way that it doesn’t require a privleged user. Make sure to share the uid/gid of the user starting your main process in the dockerhub description.

1 Like

Yesir.
This is what I am currently doing…
There is a degree of config that is accessible through a REST api after the container is running available in the persistent volume.
I then I have env and command line options that allow configuration at run time.
I love and need to create an docker-compose.yml and document the user id the container is using.
Your time and diligence is appreciated.
Cheers!

Welcome!

On long term you should consider to provide kubernetes manifests as well, or even better write your own Helm Chart and share it to support an easy bootstrapping of your application in Kubernetes.

1 Like

Righteous…
That is exactly the type of input I was looking for.
I have a great path forward now.
Thanks again.
Cheers!