wiki/src/blueprint/evaluate_Docker.mdwn

   1 For an overview of the more general problem, see [[blueprint/replace_vagrant]].
   2 For the detailed plans and things to evaluate in Docker, see [[!tails_ticket 7530]].
   3
   4 [[!toc levels=1]]
   5
   6 Availability on target platforms
   7 ================================
   8
   9 (as of 20141130)
  10
  11 Primary target platforms:
  12
  13 * Debian Wheezy: no, even in backports; installation is [possible
  14   using ugly methods](https://docs.docker.com/installation/debian/)
  15 * Debian Jessie: 1.3.1~dfsg1-2, and an unblock request has been filed
  16   to let 1.3.2 in
  17 * Debian sid: 1.3.2~dfsg1-1
  18 * Ubuntu 14.04 LTS: 0.9.1, with 1.0.1 available in trusty-updates
  19 * Ubuntu 14.10: 1.2.0
  20
  21 Bonus:
  22
  23 * Arch: 1.3.2
  24 * Fedora: 1.3.0 flagged as stable, 1.3.2 in testing
  25
  26 API stability and backwards-compatibility
  27 =========================================
  28
  29 - "all [Docker] containers are backwards compatible, pretty much to
  30   the first version. [...] In general backwards compatibility is a
  31   big deal in the Docker project"
  32   ([source](https://news.ycombinator.com/item?id=7985142), shykes
  33   is a Docker developer)
  34 - Apparently the Docker 1.0 release broke older stuff, see e.g. the
  35   0.6 release in
  36   [the jenkins plugin changelog](https://wiki.jenkins-ci.org/display/JENKINS/Docker+Plugin).
  37 - Environment replacement was formalized in Docker 1.3, and the new
  38   behavior ["will be
  39   preserved"](https://docs.docker.com/reference/builder/#environment-replacement).
  40
  41 Image creation and maintenance
  42 ==============================
  43
  44 This is about [[!tails_ticket 7533]]. That's Docker's equivalent of
  45 Vagrant's basebox.
  46
  47 The Debian images' creation process has been [described by Joey
  48 Hess](http://joeyh.name/blog/entry/docker_run_debian/). They are built
  49 with <https://github.com/tianon/docker-brew-debian.git>, which itself
  50 uses
  51 [`mkimage.sh`](https://github.com/docker/docker/blob/master/contrib/mkimage.sh).
  52 There are `rootfs.tar.xz` files in the former repository.
  53
  54 The [[!debwiki Cloud/CreateDockerImage]] Debian wiki page documents
  55 how to use only stuff shipped in Debian to create a Debian image with
  56 a single command. That's presumably what we should do.
  57
  58 See also <https://docs.docker.com/articles/baseimages/>.
  59
  60 Do we want to:
  61
  62 1. Let the build system build and maintain its own images on the
  63    developer's system, the same way we would do it if we were
  64    publishing our images?
  65 1. Produce and publish these images automatically, e.g.
  66    daily or weekly?
  67 1. Build them locally and then upload? If so, who would do it,
  68    and when?
  69
  70 Do something different for our base images (e.g. Debian Wheezy)
  71 from we do for the specialized containers (e.g. ISO builder)?
  72
  73 Image publication
  74 =================
  75
  76 By default, Docker downloads images from the [Docker Hub
  77 Registry](https://registry.hub.docker.com/). If we want to publish our
  78 images, of course we want to self-host them somehow.
  79
  80 One can [run their own
  81 registry](https://github.com/docker/docker-registry):
  82
  83  * [specs](https://docs.docker.com/reference/api/hub_registry_spec/)
  84
  85 Or, one can use `docker save` an image or `docker export` a container,
  86 and then use `docker load` or `docker import`.
  87
  88 Random notes
  89 ============
  90
  91 * Since Docker 0.9, the default execution environment is libcontainer,
  92   instead of LXC. It now supports e.g. systemd-nspawn, libvirt-lxc,
  93   libvirt-sandbox, qemu/kvm, in addition to LXC.
  94 * Docker seems to support sharing a directory between the host and
  95   a container, so on this front, we would not lose anything compared
  96   to Vagrant.
  97 * Docker supports Linux and OSX.
  98 * According to
  99   <https://stackoverflow.com/questions/17989306/what-does-docker-add-to-just-plain-lxc>,
 100   Docker comes with tools to automatically build a container from
 101   source, version it, and upgrade it incrementally.
 102 * Michael Prokop [gives
 103   pointers](http://michael-prokop.at/blog/2014/07/23/book-review-the-docker-book/)
 104   about Docker integration with Jenkins.
 105 * As far as our build system is concerned, we don't care much to
 106   protect the host system from the build container. The main goal is
 107   to produce a reliable build environment.
 108 * For security info about Linux containers in general, see the
 109   [[dedicated blueprint|blueprint/Linux_containers]].
 110 * [overclockix](https://github.com/mbentley/overclockix) uses
 111   live-build and provides a Dockerfile for easier building.
 112 * overlayfs support was added in Docker 1.4.0; we'll need that when
 113   using Debian Stretch/sid once Linux 3.18 lands in there after
 114   Jessie is released.
 115
 116 Test run
 117 ========
 118
 119 (20150120, Debian sid host, `feature/7530-docker` Git branch)
 120
 121         sudo apt --no-install-recommends install docker.io aufs-tools
 122         sudo adduser "$(whoami)" docker
 123         su - "$(whoami)"
 124         make
 125
 126 * `TAILS_BUILD_OPTIONS="noproxy"` => run [apt-cacher-ng in a different
 127   container](https://docs.docker.com/examples/apt-cacher-ng/);
 128   - [Linking these containers
 129     together](https://docs.docker.com/userguide/dockerlinks/) would
 130     allow to expose apt-cacher-ng's port only to our build container;
 131     OTOH some of us will want to use the same apt-cacher-ng instance for
 132     other use cases
 133   - Docker will [have container
 134     groups](https://github.com/docker/docker/issues/9694) at some
 135     point, but we're not there yet; in the meantime, there are
 136     [crane](https://github.com/michaelsauter/crane) and
 137     [Fig](http://www.fig.sh/)
 138 * Even with `--cache false`, some directories (`chroot`, `cache`) are
 139   saved and retrieved from the container upon shutdown; same for
 140   live-config -generated `config/*` files. That's because the current
 141   directory is shared read-write with the container somehow.
 142   This bind-mount should be read-only, but we still need to get the
 143   build artifacts back on the host:
 144   - see [Managing data in
 145     containers](https://docs.docker.com/userguide/dockervolumes/)
 146   - use `VOLUME` to share (read-write) the place where the build
 147     artifacts shall be copied
 148 * We're currently using the `debian:wheezy` template, that likely we
 149   should not trust. How should we build, maintain, publish and use
 150   our own? That's [[!tails_ticket 7533]].
 151 * Being in the `docker` group is basically equivalent to having full
 152   root access. Do we want to encourage contributors to do that, or
 153   to run `docker` commands with `sudo`, or to use Docker in
 154   a virtual machine?
 155 * We currently pass `--privileged` to `docker run`. Should we remove
 156   it, and if yes, how?
 157   - According to
 158     <https://docs.docker.com/articles/dockerfile_best-practices/>,
 159     "many of the “essential” packages from the base images will fail
 160     to upgrade inside an unprivileged container". It seems that
 161     the best practice is to publish _and regularly update_ a base
 162     image, so that the most common usecases can avoid the APT upgrade
 163     steps, and then run unprivileged.
 164 * Adding `.git` to the `.dockerignore` file would speed up the build,
 165   but some code in our build process wants to know what branch or
 166   commit we're building from => maybe we could pre-compute this
 167   information, and pass it to the build command in some way?
 168 * What execution environment do we want to support? Only LXC
 169   via libcontainer? Any usecase for e.g. the systemd- or
 170   libvirt-based ones?
 171 * Move more stuff from `Makefile` to `Dockerfile`? E.g. `DOCKER_MOUNT`
 172   could be specified as `VOLUME`. Can we specify the build command as
 173   `CMD`?