Skip to content

5 Fatal Docker Gotcha's ๐Ÿ˜ฑ - for new users

Eugene Cheah on November 19, 2018

Developing with docker containers is great! And we at uilicious run our entire backend on top of docker. It would have been impossible to have la... [Read Full]
markdown guide

One of the biggest gotchas I've encountered was about proper secrets management, e.g. API Private Key for a given container.

As far as I could understand, by default, neither Docker nor Docker-Compose provide any kind of secrets management, but that's something that is handled in Docker Swarm -if you actually want to set up a Swarm instance, that is-.

For "simple" docker infrastructures which are only managed by Docker-Compose, you must use external services, like the well-known Vault project.

I personally haven't dug into this solution (yet), but by looking at it, I have no idea on how I could integrate it in a Compose workflow, in which every "secret" environment variable would be filled on build.

If you know any good resource on using Vault (or some other tool) for managing Environment-based secrets in Docker and/or compose, I'd gladly look into them.

Another problem I personally found with docker swarm's secret management is that it seems to be text-file-based, and not environment-ready.


Ahh yes, I probably should add this in when I revise the article for 2019.

Yup secrets built into containers : especially in particular public containers are a big one.

Mitigation beyond "not placing them in dockerfile" however is much more complicated.

Beyond that : only solutions like vault, or for every docker management system - be it kubernetes or swarm, text file based secrets management. Are currently the only main options.

For compose, and environment variables however : the practise is to simply not use it publicly but internally.

For heavily regulated industries, as far as I know. They would instead isolate the docker management system, and container repository from the developers. Where only a sysadmin (who has the keys anyway) could then perform the deployment, after building the containers from the source code into repository.

Not ideal as its not full CI/CD, and can sometimes be somewhat manual in the process


Great article. I think I have touched all issues you mentioned, and most of the time as expected. This article should be a must-read for all that consider using docker, but alas, too many developers just make it work not considering future consequences like how docker behave with a full disk or low RAM.

For the security that you discuss with @Artemis;

Hashicorp Vault works fine, but is not persistent as you mention in the article. Though you can connect Vault to any backend storage like Consul, HSM or just flat storage area with Vaults own encryption.

Still there will be a problem with public containers since the secrets are stored as plain text, and even in a specific location.
In a project, we got around it by using automatic generated passwords for containers like that, which means that if a container gets hacked, all that has to be done is restart the container and a new password is given.


Great article! Although I use docker only on my system, I have nice(๐Ÿคจ) memory of 2nd point you mentioned about data persistence. I was using docker for very first time. Wrote some code with really great efforts(๐Ÿ˜Ž), and closed the system normally. Next time opened to show to a friend, and ๐Ÿ’ฅ...NOTHING WAS's feels nice when someone explains mistakes you learned from...


I feel you there - I still make this mistake every now and then till this day...

It always start with : hmm lets make a small minor 1 liner tweak to see if this will make the container better


1 page of bash script later : poof ๐Ÿ˜ฑ


Thanks for the article!

For the 1st point there is a good practice to bind port to the localhost if you only need to use service locally: -p


Unrelated to anything of substance; just something that I chuckled at... if you are reading a Docker article but don't know what RAM stands for -- you are in trouble!

code of conduct - report abuse