summaryrefslogtreecommitdiffstats
path: root/wiki/src/blueprint/evaluate_Docker.mdwn
diff options
context:
space:
mode:
authorTails developers <amnesia@boum.org>2015-01-21 09:30:38 +0000
committerTails developers <amnesia@boum.org>2015-01-21 09:30:38 +0000
commit314190c18b43560114e9430c2a3578b069650759 (patch)
treeec0de241685d9745e60bfa284027d30e9acfb59c /wiki/src/blueprint/evaluate_Docker.mdwn
parent9f57cb2c2011736a43980b24b2ef8250f4ea9d8d (diff)
Docker notes++
Diffstat (limited to 'wiki/src/blueprint/evaluate_Docker.mdwn')
-rw-r--r--wiki/src/blueprint/evaluate_Docker.mdwn37
1 files changed, 36 insertions, 1 deletions
diff --git a/wiki/src/blueprint/evaluate_Docker.mdwn b/wiki/src/blueprint/evaluate_Docker.mdwn
index 575cb33..26ed1ca 100644
--- a/wiki/src/blueprint/evaluate_Docker.mdwn
+++ b/wiki/src/blueprint/evaluate_Docker.mdwn
@@ -83,4 +83,39 @@ Test run
live-config -generated `config/*` files. That's because the current
directory is shared read-write with the container somehow.
This bind-mount should be read-only, but we still need to get the
- build artifacts back on the host.
+ build artifacts back on the host:
+ - see [Managing data in
+ containers](https://docs.docker.com/userguide/dockervolumes/)
+ - use `VOLUME` to share (read-write) the place where the build
+ artifacts shall be copied
+* We're currently using the `debian:wheezy` template, that likely we
+ should not trust. How should we build, maintain, publish and use
+ our own?
+* Being in the `docker` group is basically equivalent to having full
+ root access. Do we want to encourage contributors to do that, or
+ to run `docker` commands with `sudo`, or to use Docker in
+ a virtual machine?
+* Move our Dockerfile(s) to the `docker` directory in the Git tree.
+ Then we can pass the path to that directory, instead of `.`, to
+ `docker build`.
+* We currently pass `--privileged` to `docker run`. Should we remove
+ it, and if yes, how?
+ - According to
+ <https://docs.docker.com/articles/dockerfile_best-practices/>,
+ "many of the “essential” packages from the base images will fail
+ to upgrade inside an unprivileged container". It seems that
+ the best practice is to publish _and regularly update_ a base
+ image, so that the most common usecases can avoid the APT upgrade
+ steps, and then run unprivileged.
+* Split the `RUN` command into several ones, so that cached intermediary
+ images are [reused](https://docs.docker.com/reference/builder/)?
+* Adding `.git` to the `.dockerignore` file would speed up the build,
+ but some code in our build process wants to know what branch or
+ commit we're building from => maybe we could pre-compute this
+ information, and pass it to the build command in some way?
+* What execution environment do we want to support? Only LXC
+ via libcontainer? Any usecase for e.g. the systemd- or
+ libvirt-based ones?
+* Move more stuff from `Makefile` to `Dockerfile`? E.g. `DOCKER_MOUNT`
+ could be specified as `VOLUME`. Can we specify the build command as
+ `CMD`?