Change Details

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 most popular container tool / format, docker enjoys 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](https://github.com/coreos/fleet), [Kubernetes](https://github.com/googlecloudplatform/kubernetes) or [Apache Mesos](http://mesos.apache.org/) can dynamically spawn and integrate entire docker instance clusters - [boot2docker](https://github.com/boot2docker/boot2docker) provides a very light-weight platform for running docker instances on [Windows and OSX](http://boot2docker.io/) Compared to other Linux container solutions like [LXC](https://linuxcontainers.org/) or [Rocket](https://coreos.com/blog/rocket/), it lacks: - strong image signatures (can't use public registry for that reason) -- supported in Rocket - user namespaces to map users in containers to others in the host (ex: root in container to unprivileged user in host) -- [supported in LXC](https://www.stgraber.org/2014/01/17/lxc-1-0-unprivileged-containers/) Docker could potentially help us with 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: - improve service isolation / security with low-enough overheads to make this reasonable in production - safely share hardware between different services - deploy the exact same code that was tested earlier - 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 would require root, which we don't want to grant. This can typically be worked around by starting services with a custom start command specified in the dockerfile, but this mostly loses the integration work package maintainers have already performed. - To ensure timely security updates, we'll need to make sure that all images are based off our own, properly maintained base image. Security updates in system libraries like OpenSSL will need to be rolled out to this base image and all derived images in an automated manner.

Docker promises a convenient / developer friendly interface for regular Linux container functionality: - 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 - fairly good integration with other tools (largely owed to its popularity): - 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](https://github.com/coreos/fleet), [Kubernetes](https://github.com/googlecloudplatform/kubernetes) or [Apache Mesos](http://mesos.apache.org/) can dynamically spawn and integrate entire docker instance clusters - [boot2docker](https://github.com/boot2docker/boot2docker) provides a very light-weight platform for running docker instances on [Windows and OSX](http://boot2docker.io/) Compared to other Linux container solutions like [LXC](https://linuxcontainers.org/) or [Rocket](https://coreos.com/blog/rocket/), it lacks: - strong image signatures (can't use public registry for that reason) -- supported in Rocket - user namespaces to map users in containers to others in the host (ex: root in container to unprivileged user in host) -- [supported in LXC](https://www.stgraber.org/2014/01/17/lxc-1-0-unprivileged-containers/) Docker could potentially help us with 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: - improve service isolation / security with low-enough overheads to make this reasonable in production - safely share hardware between different services - deploy the exact same code that was tested earlier - 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 would require root, which we don't want to grant. This can typically be worked around by starting services with a custom start command specified in the dockerfile, but this mostly loses the integration work package maintainers have already performed. - To ensure timely security updates, we'll need to make sure that all images are based off our own, properly maintained base image. Security updates in system libraries like OpenSSL will need to be rolled out to this base image and all derived images in an automated manner.

Docker providesmises a convenient / developer friendly interface for regular 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 most popular container tool / format, docker enjoys fairly good integration with other tools:- fairly good integration with other tools (largely owed to its popularity): - 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](https://github.com/coreos/fleet), [Kubernetes](https://github.com/googlecloudplatform/kubernetes) or [Apache Mesos](http://mesos.apache.org/) can dynamically spawn and integrate entire docker instance clusters - [boot2docker](https://github.com/boot2docker/boot2docker) provides a very light-weight platform for running docker instances on [Windows and OSX](http://boot2docker.io/) Compared to other Linux container solutions like [LXC](https://linuxcontainers.org/) or [Rocket](https://coreos.com/blog/rocket/), it lacks: - strong image signatures (can't use public registry for that reason) -- supported in Rocket - user namespaces to map users in containers to others in the host (ex: root in container to unprivileged user in host) -- [supported in LXC](https://www.stgraber.org/2014/01/17/lxc-1-0-unprivileged-containers/) Docker could potentially help us with 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: - improve service isolation / security with low-enough overheads to make this reasonable in production - safely share hardware between different services - deploy the exact same code that was tested earlier - 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 would require root, which we don't want to grant. This can typically be worked around by starting services with a custom start command specified in the dockerfile, but this mostly loses the integration work package maintainers have already performed. - To ensure timely security updates, we'll need to make sure that all images are based off our own, properly maintained base image. Security updates in system libraries like OpenSSL will need to be rolled out to this base image and all derived images in an automated manner.