Should the Dockerfile create volumes automatically

[nickdbush]

I'm not sure if having the Kratos Dockerfile creating volumes intentionally is beneficial in some way, and I'm more than happy for that to be the case. In the file, there's a comment that reads:

# Exposing the ory home directory to simplify passing in Kratos configuration (e.g. if the file $HOME/.kratos.yaml
# exists, it will be automatically used as the configuration file).

However, defining a volume in a Docker file doesn't mount the configuration file itself. That would still have to be done manually, using a flag on the command line or through a property in the compose definition, in which case isn't this line in the configuration redundant?

My main thinking behind this is that it may surprise some users that files persist through container lifecycles even though this has not been explicitly been set. This feels like it goes against the deterministic nature of Docker containers, but again, I'm only considering this from my use case, and I'd be interested in hearing the opinions of others.

Anyway, this is my latest step in the hunt to get the Docker configuration working. I had to change the default entrypoint and command to get the container to pickup my config, but that's for another day.

[aeneasr]

Creating the home dir for volume mounting is required to get chown to work with the non-root user set here

[feend78]

I'm confused then... secrets and passwords are a minority of the keys in the kratos.yaml file. With the quoted "make a downstream dockerfile" instructions above and in the docs, I had assumed I would put together a kratos.yaml and a series of identity schema jsons, point the proper keys in the kratos.yaml file to them, package all this up into the image, and set env vars for any actual secrets needed at deploy time. Apparently this is off base.

Should I just be using the published image as-is and set all the keys via env vars? If so, why do the docs recommend building a new image off the published image? I'd prefer to have a versioned config file than to have to set a hundred env vars in my CI system. Am I missing something obvious in the docker-based workflow for Kratos?

[aeneasr]

I don’t think we recommend that anywhere but if we do please let us know so we can update the section :)

I am not saying to have all configs as env vars. I am saying you would normally use env vars or config systems (e.g. kubernetes config maps) and not add config files to docker images. It’s an antipattern! In the end you can do it as you wish, it’s your system!

If you’re just looking to get started with stuff, maybe Ory Cloud is worth a look for you? We take care of all the config and deployment stuff there for you and we also recently changed the price (not reflected on the home page yet) to a free plan for developers!

[feend78]

Here's the section of the docs that led me in this direction: https://www.ory.sh/kratos/docs/guides/docker#creating-custom-docker-image

Thanks for the info!

[aeneasr]

Oh thank you! That is definitely outdated information and not correct / best practice :)

[aeneasr]

Basically the Docker Image is like the binary and the config file is like the CLI flags - you wouldn’t hardcode them into the binary depending on your env but instead build it once and then configure it at runtime :)