Differences

This shows you the differences between two versions of the page.

--- docker [2019/11/28 18:40] – [Proposed solution] mimbert
+++ docker [2019/11/29 15:00] – [Proposed solution] mimbert
@@ Line 1: / Line 1: @@
+===== Docker =====
 Since November 2019, a new way to conduct experiments is implemented in CorteXlab.
-====== Why ======
+==== Why ====
 The legacy way of running experiments is to run one (or more) commands on each node of the experiment. These commands are run from the minus task. This has some drawbacks:
@@ Line 17: / Line 19: @@
   * All the results are gathered with the task directory, compressed, and sent back to airlock. This means that the results may include huge unneeded things, such as experiment code, input datasets, etc.
-====== Proposed solution ======
+==== Proposed solution ====
 The proposed solution is to use [[https://www.docker.com/|Docker]] containers to run experiments. Here's the way it is supposed to work and solve the issues:
-  * [[https://docs.docker.com/get-started/#images-and-containers|Docker images]] are used to package a full toolchain, such as gnuradio 3.8, gnuradio 3.7, or custom tools such as OpenBTS, [[https://www.openairinterface.org/|OpenAirInterface]] etc. Some images will be provided and maintained by the CorteXlab team, while others may be created by experimenters, possibly based on ours or not. This strongly relaxes the constraints on what experimenters can do on the platform. It is even possible to use a different linux distribution if needed (we did this for OpenBTS, which was much easier to build on Ubuntu Xenial than on Debian.
+  * [[https://docs.docker.com/get-started/#images-and-containers|Docker images]] are used to package a full toolchain, such as gnuradio 3.8, gnuradio 3.7, or custom tools such as OpenBTS, [[https://www.openairinterface.org/|OpenAirInterface]] etc. Some images will be provided and maintained by the CorteXlab team, while others may be created by experimenters, possibly based on ours or not. This strongly relaxes the constraints on what experimenters can do on the platform. It is even possible to use a different linux distribution if needed (we did this for OpenBTS, which was much easier to build on Ubuntu Xenial than on Debian).
   * Preparing an image is a much more convenient process than preparing a task, when it comes to complex software bundles such as TensorFlow, OpenBTS, etc. One just needs to install dependencies and build as if it was a real machine, there is no need to tweak or hack build steps, it just works directly.
   * Image preparation can be an interactive process, or it can be automated with a [[https://docs.docker.com/engine/reference/builder/|Dockerfile]]. The interactive way is nice for development and debug, and the automated way is an interresting step towards experimental reproducibility.