Popular posts

Structuring images, if I've got your concern properly, is done by your docker registry and it's the best thing about infrastructure-as-code.

Using some lightweight orchestrator like docker-compose or more advanced options such as Kubernetes, you can control both your resource management and how you deploy your images. They give you the ability to constrain how many resources you give to any of your containers and easily scale them when a single container couldn't handle all of your traffic.

The testing process can be done through your CI/CD and using Docker-based architecture won't get in the way of doing that properly.

This is a challenge I've seen as well. I was hoping that docker's file system would get smart enough about this so the problem would go away, but it hasn't happened yet.

In the past, I've solved the situation using a combination of the following:

1. Have the files included in the image. If the file rarely changes, you have it on a base image (or multi-stage build) to benefit from docker and buildkit's cache.
2. Use rsync to move the files to the container or the volume (I launch a separate container with ssh server to receive the files, and have the volume shared between containers)
3. A file watcher to run rsync when a file changed.

I like this setup because it works locally, or if my docker containers are running on a VM or on a cloud VM (ssh+rsync magic FTW). Also, rsync is way faster than sending lots of files via the docker context.

If you're running your application in Kubernetes, we recently open sourced a tool we build at my company to automate all of this: github.com/okteto/okteto.