AxAp has a number of goals in the general area
of software deployment
- controlling access to local resources
- facilitating distributed development
- efficient and flexible distribution
appears to handle them (and more)
in a clean, flexible, and powerful manner.
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
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
(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.
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.