4 ms·
So I guess the best-practice approach would be to chown/chmod/rm the file after reading its contents (assuming it'll be restored when you restart the container)
by mreithub 10y ago
So I guess the best-practice approach would be to chown/chmod/rm the file after reading its contents (assuming it'll be restored when you restart the container).
So far my approach was defining environment variables in the various docker-compoose files (in a separate deployment git repo), but this looks like a really nice alternative.
Do you have plans to update the library images to give us a choice between using ENV and secrets (for DB server passwords and the like)?
On an aside: I've gotten the Docker Datacenter announcement mail today. I only took the time to skim its contents quickly and at first thought this was a DDC-only thing. Glad to hear it isn't, keep up the awesome work.
edit: clarified my docker-compose usage
- diogomonicapt 10y agoThanks! - Exposing secrets as in-memory files has a lot of advantages over ENV variables (harder to leak). - We already started updating a few images (MySQL, for example), so they can use Docker secrets. - Definitely not DDC only, but note that RBAC over secrets is a feature of the commercial product.
- bluebeard 10y agoThanks, I'm interested in trying this out.