AxAp has a number of goals in the general area of software deployment, including:

  • controlling access to local resources
  • facilitating distributed development
  • efficient and flexible distribution

Docker appears to handle them (and more) in a clean, flexible, and powerful manner.

Access Control

Although AxAp needs to use resources on the user's system (e.g., generating audio, reading files), any local access should be under the user's control. By default, Docker containers cannot interact directly with local resources, but they can be granted selected access rights when they are started.

If more isolation is desired, Docker can be run inside a virtual machine. Indeed, the Docker implementations for Mac OS X and Microsoft Windows are currently supported by means of a virtual machine infrastructure.


Docker supports software composition in a couple of ways. Using image layers (as discussed in Distribution, below) allows a custom file system to be composed for a single container. This could let users experiment easily and safely with various forks of the AxAp suite.

Containers can also be composed into cooperative suites. In Dockerizing Elixir and Phoenix Applications, Cody Boggs describes an approach that should be a close fit for some of AxAp's needs. For example, containers could be created for services such as:


Docker's approach to distribution is conceptually similar to that used by Git. Immutable chunks of information are cached and exchanged by the Docker Registry and its client systems. The chunks are identified by a cryptographic hash function, allowing fast comparisons and reliable transmission.

However, the nature of the chunks is different in a couple of ways. Git "blobs" typically contain some amount of text or perhaps some Git metadata (e.g, for a commit). Docker's "layers", in contrast, contain collections of directories and files.

Layers are composed, by means of a union mount, to form the file system "image" that the "container" runs within. Most layers are immutable (i.e., read-only), so they can be shared between running containers. However, each container gets a mutable (though impermanent) layer of its own. This contains a copy of a specified set of working files.


We don't want operating system (OS) differences (or fiefdoms) to divide our resources or community. Nor do we want the burdens of multi-platform releases and support. Docker resolves this issue by decoupling the container OS from the host OS.

Internally, each Docker container provides a specified Linux environment; however, the host computer can run any of several OSes. Docker currently supports (most versions of) Linux, plus Mac OS X and Microsoft Windows. It would not surprise me to hear of other ports, including BSD flavors.

Local Devices

Docker does not provide access to local devices, unless they are mapped into the host's file system. However, it should be possible to work around this. For example, AxAp could communicate with an access daemon that resides on the host operating system.

Topic revision: r10 - 26 Jul 2016, RichMorin
This site is powered by Foswiki Copyright © by the contributing authors. All material on this wiki is the property of the contributing authors.
Foswiki version v2.1.6, Release Foswiki-2.1.6, Plugin API version 2.4
Ideas, requests, problems regarding CFCL Wiki? Send us email