Docker Community Forums

Share and learn in the Docker community.

Noob production usage strategy questions

I get how containers make running a stateless service easy.

However if you are developing, you don’t want to build and rerun a container every time you change a line of code so you have the raw components and code running on your machine nativity. Also it would be inconvenient to have to ssh into each container to view its log files etc.

In production, containers are mostly statefull, e.g databases, Java process which need on the fly. Tuning, web servers which have content uploaded. Presumably these are bad candidates for containers as they are deployed once only then upgraded with scripts and managed with ssh (which is more laborious). For log files I guess you can setup filebeat or similar on each box.

Also, I have seen test apps put on the internet by devs have the Docker containers hacked in minutes because devs don’t setup any ssh security such as fail2ban, disabling root, using keys, rate limits in UFW, changing default passwords etc. Now containers are banned in our dev and test envs as our ISP shuts down the whole server when one container gets hacked. Obviously in prod you would not allow ssh from outside VPN’s etc. But poor container security is still a concern.

So given the stateful and security requirement, what are the main use cases for docker?

There are not many valid use cases that realy demand sshd in a container. Usualy it is just wanted because people are used to it.

No one actualy keeps logs in containers - some people first have to experience a full disc because of nodes to finaly either write the logs in volumes, send the logs to a log managment solution like ELK or simply log to STDOUT and use Docker logging drivers to handle the log data.

Depending on what you pick, you might require SSH access to your host or to the ui of your log management.

I am not sure if a comparision between a container, started from a random image, is comparible with a hardend system. If you have special requirements, you will need to create your image according your requirements yourself.

When it commes to java: devs can create a binding between a local host folder and the deployment folder in the container (make sure to not directly bin your jar, war, ear! This will prevent that you can modify the file on the host!) or even use a maven plugin to deploy into the running container. Make sure to create images that add unpriviliged users and the executed processes are able to work without root permissions. Make sure to make the userid/groupid modifyable using ENV variables; start each container with a differnent uid/gid != 0!

In production, a database should be a seperate infrastructure component, idealy managed by DBAs. If your Java applications can run in a container without requiring any state appart of the in-memory cotext states, why wouldn’t it play nice inside a container? Though, be aware that older Java versions do not respect CGROUP limits (<Java8u132) and behave like they would be the alone king of the ressources. For devs and local testing running databases in containers is fine.

Docker is flexible and allows to bend a lot of things. If done carelss, harm can/will hapen. Though, the same is true without docker.