Most web apps need login information of some kind, and it is a bad idea to put them in your source code where it gets saved to a git repository that everyone can see. Usually these are handled by environment variables, but Docker has come up with what they call Docker secrets. The idea is deceptively simple in retrospect. While you figure it out it is arcane and difficult to parse what is going on.
https://blog.docker.com/2016/06/docker-1-12-built-in-orchestration/, posted 2016 by peter in continuousdelivery deployment docker opensource
Starting with Docker 1.12, we have added features to the core Docker Engine to make multi-host and multi-container orchestration easy.
We’ve added new API objects, like Service and Node, that will let you use the Docker API to deploy and manage apps on a group of Docker Engines called a swarm. With Docker 1.12, the best way to orchestrate Docker is Docker!
A Microcontainer contains only the OS libraries and language dependencies required to run an application and the application itself. Nothing more.
Rather than starting with everything but the kitchen sink, start with the bare minimum and add dependencies on an as needed basis.
blog.wercker.com/2015/07/28/Dockerfiles-considered-harmful.html, posted 2015 by peter in deployment docker opinion security
There are some obvious issues with running third-party Dockerfiles. Like most of the Docker ecosystem, Dockerfiles were designed for personal use by an individual with root access. Once you start distributing them, however, you’re essentially giving root to a stranger. This blog post is about why you shouldn’t even be using Dockerfiles for your own projects.