Ndtyjky

I just start using docker, and at this moment I have some questions about docker in the production environment.

1. First of all, what permissions should I use on prod server? 
Should I create non root user and run docker under this user? Or it does not matter.




2. What about firewall, should I open ports for docker?




3. The big problem for me - where I should store the source code of my application? 
In compose docs is written, that I should move all my sources into the image, avoid using volume bindings at all https://docs.docker.com/compose/production/. 
But how the update process using git will look like in this case? Does it mean that each time i would update all image?




4. How to move all sources into the image using compose?




5. Where to store DB data, in container or i should bind it using volume?




6. What about permissions in a container? Should i create a non root user inside the container? Before docker it was preferred way, best practice, but with docker I don’t see any reasons for this.

1. Any user who can run any docker command has unrestricted access to the system (you can, for instance, docker run -v /:/host --rm -it -u root busybox sh to make arbitrary changes to the host filesystem). You can lock things down a little bit but it's very easy to "escape the box". Consider using a dedicated orchestrator (Docker Swarm, Kubernetes, Amazon ECS, Nomad, ...) and only running Docker containers on your system.




2. If you have some sort of firewall, yes, you'll need to open up the ports that your Docker applications listen on externally. (And in an AWS environment, also allow them in a security group.)




3. You use docker build to create an image out of your source code. In a production environment you usually don't want to be manually pushing the source code around alongside the images you're building. The two key pieces you need to support this are a Docker registry (Docker Hub, Amazon ECR, Google GCR, run your own) and a continuous integration system (Jenkins is popular or there are a bajillion cloud-based ones). Set up the CI system so that every commit to your source repository creates a new uniquely-tagged image. Deploy specific builds of your images. Leave your source control in its happy home (GitHub, Bitbucket, Subversion, Perforce, ...).




4. You don't. The source code gets built into the image. Consider using a dedicated orchestrator that's remotely accessible (pretty much anything other than Docker Compose) so that your CI system can update your deployment to the latest builds.




5. Never store data "in containers": they get deleted frequently and the associated data would get lost. I'd personally recommend running databases on dedicated hosts outside of Docker, but there's an argument to running everything in Docker too. Just make sure you're correctly using volumes or host directories to store the actual data, you back it up, and you practice restoring it. (An argument for "all Docker" is that it's very easy to clone and restore your entire environment.)




6. Using a non-root user inside a Docker container is still generally considered a best practice. It usually doesn't matter much, but if you do have some sort of security issue, it can at least protect the application from rewriting its own code inside the container.

First of all for production i would use for the beginning docker-stack instead of compose. It is compatible, needs not additional installation and has some service healing features. To your questions.

1. You create a separate user and put them in a specific docker group


2. It depends from your running container and from your swarm/stack
   configuration. If you use a single machine no additional ports are needed


3. You can mount your file system persistence layer to your host system or you can use dedicated volumes for that. In general you programm code is part of one of your docker images, as part of a CI process that creates the image.


4. As mentioned you do that while you create your docker image. The references to your sources are defined in your dockerfile.


5. For a better overview I use in simple installations a directory from the host system that is mounted into a docker container.


6. I have never changed the permissions inside the container until today and haven't found any drawbacks

Terms used in the docker world:

• Image - the same as a class in software development


• Container - an object built from an Image at runtime - basically no persistence inside


• Dockerfile - desciptions how a image is build and from what 'parent' it is derived


• Volume - Docker container file system extension to link the non persistent container to the host file system or to other containers


• Host - der Machine that runs docker