In
the previous blog post, I have analyzed
Nix and
Docker as deployment solutions and described in what ways these solutions are similar and different.
To summarize my findings:
- Nix is a source-based package manager responsible for obtaining, installing, configuring and upgrading packages in a reliable and reproducible manner and facilitating the construction of packages from source code and their dependencies.
- Docker's purpose is to fully manage the life-cycle of applications (services and ordinary processes) in a reliable and reproducible manner, including their deployments.
As explained in my previous blog post, two prominent goals both solutions have in common is to facilitate
reliable and
reproducible deployment. They both use different kinds of techniques to accomplish these goals.
Although Nix and Docker can be used for a variety of comparable use cases (such as constructing images, deploying test environments, and constructing packages from source code), one prominent feature that the Nix package manager does not provide is
process (or service)
management.
In a Nix-based workflow you need to augment Nix with another solution that can facilitate process management.
In this blog post, I will investigate how Docker could fulfill this role -- it is pretty much the opposite goal of the combined use cases scenarios I have shown in the previous blog post, in which Nix can overtake the role of a conventional package manager in supplying packages in the construction process of an image and even the complete construction process of images.
Existing Nix integrations with process management
Although Nix does not do any process management, there are sister projects that can, such as:
- NixOS builds entire machine configurations from a single declarative deployment specification and uses the Nix package manager to deploy and isolate all static artifacts of a system. It will also automatically generate and deploy systemd units for services defined in a NixOS configuration.
- nix-darwin can be used to specify a collection of services in a deployment specification and uses the Nix package manager to deploy all services and their corresponding launchd configuration files.
Although both projects do a great job (e.g. they both provide a big collection of deployable services) what I consider a disadvantage is that they are
platform specific -- both solutions only work on a single operating system (Linux and macOS) and a single process management solution (systemd and launchd).
If you are using Nix in a different environment, such as a different operating system, a conventional (non-NixOS) Linux distribution, or a different process manager, then there is no off-the-shelf solution that will help you managing services for packages provided by Nix.
Docker functionality
Docker could be considered a multi-functional solution for application management. I can categorize its functionality as follows:
- Process management. The life-cycle of a container is bound to the life-cycle of a root process that needs to be started or stopped.
- Dependency management. To ensure that applications have all the dependencies that they need and that no dependency is missing, Docker uses images containing a complete root filesystem with all required files to run an application.
- Resource isolation is heavily used for a variety of different reasons:
- Foremost, to ensure that the root filesystem of the container does not conflict with the host system's root filesystem.
- It is also used to prevent conflicts with other kinds of resources. For example, the isolated network interfaces allow services to bind to the same TCP ports that may also be in use by the host system or other containers.
- It offers some degree of protection. For example, a malicious process will not be able to see or control a process belonging to the host system or a different container.
- Resource restriction can be used to limit the amount of system resources that a process can consume, such as the amount of RAM.
Resource restriction can be useful for a variety of reasons, for example, to prevent a service from eating up all the system's resources affecting the stability of the system as a whole. - Integrations with the host system (e.g. volumes) and other services.
As described in the previous blog post, Docker uses a number of key concepts to implement the functionality shown above, such as layers,
namespaces and
cgroups.
Developing a Nix-based process management solution
For quite some time,
I have been investigating the process management domain and worked on a
prototype solution to provide a more generalized infrastructure that complements Nix with process management -- I came up with an experimental Nix-based process manager-agnostic framework that has the following objectives:
- It uses Nix to deploy all required packages and other static artifacts (such as configuration files) that a service needs.
- It integrates with a variety of process managers on a variety of operating systems. So far, it can work with: sysvinit scripts, BSD rc scripts, supervisord, systemd, cygrunsrv and launchd.
In addition to process managers, it can also automatically convert a processes model to deployment specifications that Disnix can consume. - It uses declarative specifications to define functions that construct managed processes and process instances.
Processes can be declared in a process-manager specific and process-manager agnostic way. The latter makes it possible to target all six supported process managers with the same declarative specification, albeit with a limited set of features. - It allows you to run multiple instances of processes, by introducing a convention to cope with potential resource conflicts between process instances -- instance properties and potential conflicts can be configured with function parameters and can be changed in such a way that they do not conflict.
- It can facilitate unprivileged user deployments by using Nix's ability to perform unprivileged package deployments and introducing a convention that allows you to disable user switching.
To summarize how the solution works from a user point of view, we can write a process manager-agnostic constructor function as follows:
{createManagedProcess, tmpDir}:
{port, instanceSuffix ? "", instanceName ? "webapp${instanceSuffix}"}:
let
webapp = import ../../webapp;
in
createManagedProcess {
name = instanceName;
description = "Simple web application";
inherit instanceName;
process = "${webapp}/bin/webapp";
daemonArgs = [ "-D" ];
environment = {
PORT = port;
PID_FILE = "${tmpDir}/${instanceName}.pid";
};
user = instanceName;
credentials = {
groups = {
"${instanceName}" = {};
};
users = {
"${instanceName}" = {
group = instanceName;
description = "Webapp";
};
};
};
overrides = {
sysvinit = {
runlevels = [ 3 4 5 ];
};
};
}
The Nix expression above is a nested function that defines in a process manager-agnostic way a configuration for a web application process containing an embedded web server serving a static HTML page.
- The outer function header (first line) refers to parameters that are common to all process instances: createManagedProcess is a function that can construct process manager configurations and tmpDir refers to the directory in which temp files are stored (which is /tmp in conventional Linux installations).
- The inner function header (second line) refers to instance parameters -- when it is desired to construct multiple instances of this process, we must make sure that we have configured these parameters in such as a way that they do not conflict with other processes.
For example, when we assign a unique TCP port and a unique instance name (a property used by the daemon tool to create unique PID files) we can safely have multiple instances of this service co-existing on the same system. - In the body, we invoke the createManagedProcess function to generate configurations files for a process manager.
- The process parameter specifies the executable that we need to run to start the process.
- The daemonArgs parameter specifies command-line instructions passed to the the process executable, when the process should daemonize itself (the -D parameter instructs the webapp process to daemonize).
- The environment parameter specifies all environment variables. Environment variables are used as a generic configuration facility for the service.
- The user parameter specifies the name the process should run as (each process instance has its own user and group with the same name as the instance).
- The credentials parameter is used to automatically create the group and user that the process needs.
- The overrides parameter makes it possible to override the parameters generated by the createManagedProcess function with process manager-specific overrides, to configure features that are not universally supported.
In the example above, we use an override to configure the runlevels in which the service should run (runlevels 3-5 are typically used to boot a system that is network capable). Runlevels are a sysvinit-specific concept.
In addition to defining constructor functions allowing us to construct zero or more process instances, we also need to construct process instances. These can be defined in a
processes model:
{ pkgs ? import <nixpkgs> { inherit system; }
, system ? builtins.currentSystem
, stateDir ? "/var"
, runtimeDir ? "${stateDir}/run"
, logDir ? "${stateDir}/log"
, cacheDir ? "${stateDir}/cache"
, tmpDir ? (if stateDir == "/var" then "/tmp" else "${stateDir}/tmp")
, forceDisableUserChange ? false
, processManager
}:
let
constructors = import ./constructors.nix {
inherit pkgs stateDir runtimeDir logDir tmpDir;
inherit forceDisableUserChange processManager;
};
in
rec {
webapp = rec {
port = 5000;
dnsName = "webapp.local";
pkg = constructors.webapp {
inherit port;
};
};
nginxReverseProxy = rec {
port = 8080;
pkg = constructors.nginxReverseProxyHostBased {
webapps = [ webapp ];
inherit port;
} {};
};
}
The above Nix expressions defines two process instances and uses the following conventions:
- The first line is a function header in which the function parameters correspond to ajustable properties that apply to all process instances:
- stateDir allows you to globally override the base directory in which all state is stored (the default value is: /var).
- We can also change the locations of each individual state directories: tmpDir, cacheDir, logDir, runtimeDir etc.) if desired.
- forceDisableUserChange can be enabled to prevent the process manager to change user permissions and create users and groups. This is useful to facilitate unprivileged user deployments in which the user typically has no rights to change user permissions.
- The processManager parameter allows you to pick a process manager. All process configurations will be automatically generated for the selected process manager.
For example, if we would pick: systemd then all configurations get translated to systemd units. supervisord causes all configurations to be translated to supervisord configuration files.
- To get access to constructor functions, we import a constructors expression that composes all constructor functions by calling them with their common parameters (not shown in this blog post).
The constructors expression also contains a reference to the Nix expression that deploys the webapp service, shown in our previous example. - The processes model defines two processes: a webapp instance that listens to TCP port 5000 and Nginx that acts as a reverse proxy forwarding requests to webapp process instances based on the virtual host name.
- webapp is declared a dependency of the nginxReverseProxy service (by passing webapp as a parameter to the constructor function of Nginx). This causes webapp to be activated before the nginxReverseProxy.
To deploy all process instances with a process manager, we can invoke a variety of tools that are bundled with the experimental Nix process management framework.
The process model can be deployed as sysvinit scripts for an unprivileged user, with the following command:
$ nixproc-sysvinit-switch --state-dir /home/sander/var \
--force-disable-user-change processes.nix
The above command automatically generates sysvinit scripts, changes the base directory of all state folders to a directory in the user's home directory:
/home/sander/var and disables user changing (and creation) so that an unprivileged user can run it.
The following command uses systemd as a process manager with the default parameters, for production deployments:
$ nixproc-systemd-switch processes.nix
The above command automatically generates systemd unit files and invokes systemd to deploy the processes.
In addition to the examples shown above, the framework contains many more tools, such as:
nixproc-supervisord-switch,
nixproc-launchd-switch,
nixproc-bsdrc-switch,
nixproc-cygrunsrv-switch, and
nixproc-disnix-switch that all work with the same processes model.
Integrating Docker into the process management framework
Both Docker and the Nix-based process management framework are multi-functional solutions. After comparing the functionality of Docker and the process management framework, I realized that it is possible to integrate Docker into this framework as well, if I would use it in an unconventional way, by disabling or substituting some if its conflicting features.
Using a shared Nix store
As explained in the beginning of this blog post, Docker's primary means to provide dependencies is by using images that are self-contained root file systems containing all necessary files (e.g. packages, configuration files) to allow an application to work.
In the previous blog post, I have also demonstrated that instead of using traditional
Dockerfiles to construct images, we can also use the Nix package manager as a replacement. A Docker image built by Nix is typically smaller than a conventional Docker image built from a base Linux distribution, because it only contains the runtime dependencies that an application actually needs.
A major disadvantage of using Nix constructed Docker images is that they only consist of one layer -- as a result, there is no reuse between container instances running different services that use common libraries. To alleviate this problem, Nix can also build layered images, in which common dependencies are isolated in separate layers as much as possible.
There is even a more optimal reuse strategy possible -- when running Docker on a machine that also has Nix installed, we do not need to put anything that is in the Nix store in a disk image. Instead, we can
share the host system's Nix store between Docker containers.
This may sound scary, but as I have explained in the previous blog post, paths in the Nix store are prefixed with SHA256 hash codes. When two Nix store paths with identical hash codes are built on two different machines, their build results should be (nearly) bit-identical. As a result, it is safe to share the same Nix store path between multiple machines and containers.
A hacky solution to build a container image, without actually putting any of the Nix built packages in the container, can be done with the following expression:
with import <nixpkgs> {};
let
cmd = [ "${nginx}/bin/nginx" "-g" "daemon off;" "-c" ./nginx.conf ];
in
dockerTools.buildImage {
name = "nginxexp";
tag = "test";
runAsRoot = ''
${dockerTools.shadowSetup}
groupadd -r nogroup
useradd -r nobody -g nogroup -d /dev/null
mkdir -p /var/log/nginx /var/cache/nginx /var/www
cp ${./index.html} /var/www/index.html
'';
config = {
Cmd = map (arg: builtins.unsafeDiscardStringContext arg) cmd;
Expose = {
"80/tcp" = {};
};
};
}
The above expression is quite similar to the Nix-based Docker image example shown in the previous blog post, that deploys Nginx serving a static HTML page.
The only difference is how I configure the start command (the
Cmd parameter). In the Nix expression language,
strings have context -- if a string with context is passed to a build function (any string that contains a value that evaluates to a Nix store path), then the corresponding Nix store paths automatically become a dependency of the package that the build function builds.
By using the unsafe
builtins.unsafeDiscardStringContext function I can discard the context of strings. As a result, the Nix packages that the image requires are still built. However, because their context is discarded they are no longer considered dependencies of the Docker image. As a consequence, they will not be integrated into the image that the
dockerTools.buildImage creates.
(As a sidenote: there are still two Nix store paths that end-up in the image, namely
bash and
glibc that is a runtime dependency of
bash. This is caused by the fact that the internals of the
dockerTools.buildImage function make a reference to
bash without discarding its context. In theory, it is also possible to eliminate this dependency as well).
To run the container and make sure that the required Nix store paths are available, I can mount the host system's Nix store as a shared volume:
$ docker run -p 8080:80 -v /nix/store:/nix/store -it nginxexp:latest
By mounting the host system's Nix store (with the
-v parameter), Nginx should still behave as expected -- it is not provided by the image, but referenced from the shared Nix store.
(As a sidenote: mounting the host system's Nix store for sharing is not a new idea. It has already been intensively used by the
NixOS test driver for many years to rapidly create QEMU virtual machines for system integration tests).
Using the host system's network
As explained in the previous blog post, every Docker container by default runs in its own private network namespace making it possible for services to bind to any port without conflicting with the services on the host system or services provided by any other container.
The Nix process management framework does not work with private networks, because it is not a generalizable concept (i.e. namespaces are a Linux-only feature). Aside from Docker, the only other process manager supported by the framework that can work with namespaces is systemd.
To prevent ports and other dynamic resources from conflicting with each other, the process management framework makes it possible to configure them through instance function parameters. If the instance parameters have unique values, they will not conflict with other process instances (based on the assumption that the packager has identified all possible conflicts that a process might have).
Because we already have a framework that prevents conflicts, we can also instruct Docker to use the host system's network with the
--network host parameter:
$ docker run -v /nix/store:/nix/store --network host -it nginxexp:latest
The only thing the framework cannot provide you is protection -- mallicious services in a private network namespace cannot connect to ports used by other containers or the host system, but the framework cannot protect you from that.
Mapping a base directory for storing state
Services that run in containers are not always stateless -- they may rely on data that should be persistently stored, such as databases.
The Docker recommendation to handle persistent state is not to store it in a container's writable layer, but on a shared volume on the host system.
Data stored outside the container makes it possible to reliably upgrade a container -- when it is desired to install a newer version of an application, the container can be discarded and recreated from a new image.
For the Nix process management framework, integration with a state directory outside the container is also useful. With an extra shared volume, we can mount the host system's state directory:
$ docker run -v /nix/store:/nix/store \
-v /var:/var --network host -it nginxexp:latest
Orchestrating containers
The last piece in the puzzle is to orchestrate the containers: we must create or discard them, and start or stop them, and perform all required steps in the right order.
Moreover, to prevent the Nix packages that a containers needs from being garbage collected, we need to make sure that they are a dependency of a package that is registered as in use.
I came up with my own convention to implement the container deployment process. When building the processes model for the
docker process manager, the following files are generated that help me orchestrating the deployment process:
01-webapp-docker-priority
02-nginx-docker-priority
nginx-docker-cmd
nginx-docker-createparams
nginx-docker-settings
webapp-docker-cmd
webapp-docker-createparams
webapp-docker-settings
In the above list, we have the following kinds of files:
- The files that have a -docker-settings suffix contain general properties of the container, such as the image that needs to be used a template.
- The files that have a -docker-createparams suffix contain the command line parameters that are propagated to docker create to create the container. If a container with the same name already exists, the container creation is skipped and the existing instance is used instead.
- To prevent the Nix packages that a Docker container needs from being garbage collected the generator creates a file with a -docker-cmd suffix containing the Cmd instruction including the full Nix store paths of the packages that a container needs.
Because the strings' contexts are not discarded in the generation process, the packages become a dependency of the configuration file. As long as this configuration file is deployed, the packages will not get garbage collected. - To ensure that the containers are activated in the right order we have two files that are prefixed with two numeric digits that have a -container-priority suffix. The numeric digits determine in which order the containers should be activated -- in the above example the webapp process gets activated before Nginx (that acts as a reverse proxy).
With the following command, we can automatically generate the configuration files shown above for all our processes in the processes model, and use it to automatically create and start docker containers for all process instances:
$ nixproc-docker-switch processes.nix
55d833e07428: Loading layer [==================================================>] 46.61MB/46.61MB
Loaded image: webapp:latest
f020f5ecdc6595f029cf46db9cb6f05024892ce6d9b1bbdf9eac78f8a178efd7
nixproc-webapp
95b595c533d4: Loading layer [==================================================>] 46.61MB/46.61MB
Loaded image: nginx:latest
b195cd1fba24d4ec8542c3576b4e3a3889682600f0accc3ba2a195a44bf41846
nixproc-nginx
The result is two running Docker containers that correspond to the process instances shown in the processes model:
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
b195cd1fba24 nginx:latest "/nix/store/j3v4fz9h…" 15 seconds ago Up 14 seconds nixproc-nginx
f020f5ecdc65 webapp:latest "/nix/store/b6pz847g…" 16 seconds ago Up 15 seconds nixproc-webapp
and we should be able to access the example HTML page, by opening the following URL:
http://localhost:8080 in a web browser.
Deploying Docker containers in a heteregenous and/or distributed environment
As explained in my previous blog posts about the experimental Nix process management framework, the processes model is a sub set of a
Disnix services model. When it is desired to deploy processes to a network of machines or combine processes with other kinds of services, we can easily turn a processes model into a services model.
For example, I can change the processes model shown earlier into a services model that deploys Docker containers:
{ pkgs ? import <nixpkgs> { inherit system; }
, system ? builtins.currentSystem
, stateDir ? "/var"
, runtimeDir ? "${stateDir}/run"
, logDir ? "${stateDir}/log"
, cacheDir ? "${stateDir}/cache"
, tmpDir ? (if stateDir == "/var" then "/tmp" else "${stateDir}/tmp")
, forceDisableUserChange ? false
}:
let
constructors = import ./constructors.nix {
inherit pkgs stateDir runtimeDir logDir tmpDir;
inherit forceDisableUserChange;
processManager = "docker";
};
in
rec {
webapp = rec {
name = "webapp";
port = 5000;
dnsName = "webapp.local";
pkg = constructors.webapp {
inherit port;
};
type = "docker-container";
};
nginxReverseProxy = rec {
name = "nginxReverseProxy";
port = 8080;
pkg = constructors.nginxReverseProxyHostBased {
webapps = [ webapp ];
inherit port;
} {};
type = "docker-container";
};
}
In the above example, I have added a
name attribute to each process (a required property for Disnix service models) and a
type attribute referring to:
docker-container.
In Disnix, a service could take any form. A plugin system (named
Dysnomia) is responsible for managing the life-cycle of a service, such as activating or deactivating it. The
type attribute is used to tell Disnix that we should use the
docker-container Dysnomia module. This module will automatically create and start the container on activation, and stop and discard the container on deactivation.
To deploy the above services to a network of machines, we require an
infrastructure model (that captures the available machines and their relevant deployment properties):
{
test1.properties.hostname = "test1";
}
The above infrastructure model contains only one target machine:
test1 with a hostname that is identical to the machine name.
We also require a
distribution model that maps services in the services model to machines in the infrastructure model:
{infrastructure}:
{
webapp = [ infrastructure.test1 ];
nginxReverseProxy = [ infrastructure.test1 ];
}
In the above distribution model, we map the all the processes in the services model to the
test1 target machine in the infrastructure model.
With the following command, we can deploy our Docker containers to the remote
test1 target machine:
$ disnix-env -s services.nix -i infrastructure.nix -d distribution.nix
When the above command succeeds, the
test1 target machine provides running
webapp and
nginxReverseProxy containers.
(As a sidenote: to make Docker container deployments work with Disnix, the Docker service already needs to be predeployed to the target machines in the infrastructure model, or the Docker daemon needs to be deployed as a
container provider).
Deploying conventional Docker containers with Disnix
The nice thing about the
docker-container Dysnomia module is that it is generic enough to also work with conventional Docker containers (that work with images, not a shared Nix store).
For example, we can deploy Nginx as a regular container built with the
dockerTools.buildImage function:
{dockerTools, stdenv, nginx}:
let
dockerImage = dockerTools.buildImage {
name = "nginxexp";
tag = "test";
contents = nginx;
runAsRoot = ''
${dockerTools.shadowSetup}
groupadd -r nogroup
useradd -r nobody -g nogroup -d /dev/null
mkdir -p /var/log/nginx /var/cache/nginx /var/www
cp ${./index.html} /var/www/index.html
'';
config = {
Cmd = [ "${nginx}/bin/nginx" "-g" "daemon off;" "-c" ./nginx.conf ];
Expose = {
"80/tcp" = {};
};
};
};
in
stdenv.mkDerivation {
name = "nginxexp";
buildCommand = ''
mkdir -p $out
cat > $out/nginxexp-docker-settings <<EOF
dockerImage=${dockerImage}
dockerImageTag=nginxexp:test
EOF
cat > $out/nginxexp-docker-createparams <<EOF
-p
8080:80
EOF
'';
}
In the above example, instead of using the process manager-agnostic
createManagedProcess, I directly construct a Docker-based Nginx image (by using the
dockerImage attribute) and container configuration files (in the
buildCommand parameter) to make the container deployments work with the
docker-container Dysnomia module.
It is also possible to deploy containers from images that are constructed with
Dockerfiles. After we have built an image in the traditional way, we can export it from Docker with the following command:
$ docker save nginx-debian -o nginx-debian.tar.gz
and then we can use the following Nix expression to deploy a container using our exported image:
{dockerTools, stdenv, nginx}:
stdenv.mkDerivation {
name = "nginxexp";
buildCommand = ''
mkdir -p $out
cat > $out/nginxexp-docker-settings <<EOF
dockerImage=${./nginx-debian.tar.gz}
dockerImageTag=nginxexp:test
EOF
cat > $out/nginxexp-docker-createparams <<EOF
-p
8080:80
EOF
'';
}
In the above expression, the
dockerImage property refers to our exported image.
Although Disnix is flexible enough to also orchestrate Docker containers (thanks to its generalized plugin architecture), I did not develop the
docker-container Dysnomia module to make Disnix compete with existing container orchestration solutions, such as
Kubernetes or
Docker Swarm.
Disnix is a heterogeneous deployment tool that can be used to integrate units that have all kinds of shapes and forms on all kinds of operating systems -- having a
docker-container module makes it possible to mix Docker containers with other service types that Disnix and Dysnomia support.
Discussion
In this blog post, I have demonstrated that we can integrate Docker as a process management backend option into the experimental Nix process management framework, by substituting some of its conflicting features.
Moreover, because a Disnix service model is a superset of a processes model, we can also use Disnix as a simple Docker container orchestrator and integrate Docker containers with other kinds of services.
Compared to Docker, the Nix process management framework supports a number of features that Docker does not:
- Docker is heavily developed around Linux-specific concepts, such as namespaces and cgroups. As a result, it can only be used to deploy software built for Linux.
The Nix process management framework should work on any operating system that is supported by the Nix package manager (e.g. Nix also has first class support for macOS, and can also be used on other UNIX-like operating systems such as FreeBSD). The same also applies to Disnix. - The Nix process management framework can work with sysvinit, BSD rc and Disnix process scripts, that do not require any external service to manage a process' life-cycle. This is convenient for local unprivileged user deployments. To deploy Docker containers, you need to have the Docker daemon installed first.
- Docker has an experimental rootless deployment mode, but in the Nix process management framework facilitating unprivileged user deployments is a first class concept.
On the other hand, the Nix process management framework does not take over all responsibilities of Docker:
- Docker heavily relies on namespaces to prevent resource conflicts, such as overlapping TCP ports and global state directories. The Nix process management framework solves conflicts by avoiding them (i.e. configuring properties in such a way that they are unique). The conflict avoidance approach works as long as a service is well-specified. Unfortunately, preventing conflicts is not a hard guarantee that the tool can provide you.
- Docker also provides some degree of protection by using namespaces and cgroups. The Nix process management framework does not support this out of the box, because these concepts are not generalizable over all the process management backends it supports. (As a sidenote: it is still possible to use these concepts by defining process manager-specific overrides).
From a functionality perspective,
docker-compose comes close to the features that the experimental Nix process management framework supports.
docker-compose allows you to declaratively define container instances and their dependencies, and automatically deploy them.
However, as its name implies
docker-compose is specifically designed for deploying Docker containers whereas the Nix process management framework is more general -- it should work with all kinds of process managers, uses Nix as the primary means to provide dependencies, it uses the Nix expression language for configuration and it should work on a variety of operating systems.
The fact that Docker (and containers in general) are multi-functional solutions is not an observation only made by me. For example,
this blog post also demonstrates that containers can work without images.
Availability
The Docker backend has been integrated into the
latest development version of the Nix process management framework.
To use the
docker-container Dysnomia module (so that Disnix can deploy Docker containers), you need to install the latest development version of Dysnomia.
