Here are my best reasons for using container solutions like Docker:
I used to struggle with software deployments. Traditional software package installers work fine for simple deployments on a single platform type, but require maintenance if deployment guidelines change between OS verisons. Deployment tools that need to target multiple platforms are much harder to maintain. Dealing with configurations and potential library conflicts adds to the fun. Even software implemented in interpreted languages frequently has platform-specific dependencies that need to be managed.
Using containers has significantly cut the amount of time and effort I spend managing deployments. I especially like containers for Python projects. Having pip or conda configure the right environment once in a container saves a lot of time and trouble.
Use containers to isolate software dependencies from the host the container is running on. For example, an app requires Python 3.6 but the host OS only supports older versions natively, or needs libraries that could conflict with system libraries.
The same image can be run reliably on a variety of hosts. Containers can still be challenging to use on Windows however.
Containers like Docker build their images in layers. Images with test suites and the tools needed to run in a CI/CD build environment can be built and cleaned up when no longer needed. For Docker, either the Builder pattern or multi-stage builds can be used. Multi-stage builds are currently recommended.
Deployment tools like Kubernetes and SaltStack were built to support containers.
Containers can be restarted automatically. For example, Docker offers 4 restart policy options. Pick the one that makes the most sense for your deployment. Kubernetes pods also leverage container restart policies.
Containers like Docker can be run with limits on host resources. Filesystem access can be limited as well. Just remember to use good security practices like not using the root user.
Try out a new Python version or test a database. Recently, I needed to use the gdb debugger on a CI build agent to figure out why a tool in our data pipeline was dumping core, but didn’t want to pollute with packages I’ll only use rarely. Grabbing an image with gdb was easy and quick.
The overhead of running software in a container is usually small and manageable, unless there are very stringent performance requirements. Tricky use-cases like requiring hardware accelerated OpenGL drivers might also be a problem. Debugging crashed containers can also be challenging.
Getting software configurations and dependencies right shouldn’t be a time-consuming burden. For the projects I’ve been working on however, the benefits of using containers definitely outweigh the drawbacks.
