Docker provides a convenient / developer friendly interface for Linux container functionality. As such, it provides:
- low-overhead process isolation & security improvements
- generic support for running a service as an unprivileged user, not persisting changes, dropping capabilities & other lock-down features
- memory, IO metering via cgroups
- tools for creating and distributing fairly efficient overlay-based images
- uses aufs by default, can use btrfs
- can stack overlays for quick updates (to support container-based deploys)
- public registry is not very secure, we'll need to run / maintain our own (https://github.com/docker/docker-registry and `docker run registry`)
- [linking features](https://docs.docker.com/userguide/dockerlinks/) to manage local container dependencies
- as the currently dominant container tool, fairly good integration with other tools:
- systemd can run docker images natively
- Several config management systems including Ansible or SaltStack provide modules to spawn and orchestrate docker instances
- service orchestration systems like CoreOS fleet, Kubernetes or mesos can dynamically spawn and integrate entire docker instance clusters
Compared to other Linux container solutions like LXC or Rocket, it lacks:
- strong image signing (can't use public registry for that reason) -- supported in Rocket
- user namespaces to map users in namespaces to others in the host (ex: root in container to unprivileged user in host) -- supported in LXC
For our use cases docker could potentially help for the following use cases:
- improve isolation in continuous integration with low overhead: run tests as non-root user with limited capabilities
- staging, canary and production deployment:
- low overhead and startup times
- deploy the exact same code that was tested earlier
- ability to share hardware between several services with reasonable isolation
- ability to gradually start using newer software for individual services, for example iojs
- development and labs
- provide a simple & low-overhead way to set up a few services for development and integration testing
However, there are general downsides with container-based deployment systems that we need to consider:
- Using init scripts from packages inside the container still requires root, which we'd prefer to avoid. This can typically be worked around by starting