Dysnomia is a tool designed to complement Nix deployments by managing the state of service-oriented systems through declarative specifications, allowing for reproducible and reliable software environment configurations. It enables automation of state management, including database snapshots and state restoration, while facilitating flexible redeployment in response to system events. However, Dysnomia has limitations, such as its inability to manage all forms of state and potential storage inefficiencies with large datasets.

1. Dysnomia: complementing Nix deployments with
state deployment
Sander van der Burg
October 26, 2018
Sander van der Burg Dysnomia

2. The Nix project: Declarative deployment
Nix – declarative specification of package build procedures
(including their dependencies)
NixOS – declarative specification of system aspects
NixOps – declarative specification of a network of machines
Disnix – declarative specifications of services, machines and
distribution of services over machines
Deployment activities are implicit – a user writes or adapts a deploy-
ment specification, and the tools will carry out the required activities,
such as building, transfering, activating, and deactivating.
Sander van der Burg Dysnomia

3. The Nix project: Non-functional properties
Automated deployment using declarative specifications with the
following properties:
Generic. Can be used with many programming languages,
component technologies, and operating systems.
Reproducible. (Almost) no impurities – if inputs are the same,
result should be the same regardless of its location
Reliable. Dependency completeness, (almost) atomic
upgrades and rollbacks.
Efficient. Only the required deployment activities are
executed.
Sander van der Burg Dysnomia

4. Deploying a NixOS configuration
{ pkgs, ... }:
{
services.mysql = {
enable = true;
package = pkgs.mysql;
};
services.httpd = {
enable = true;
documentRoot = "/var/www";
adminAddr = "admin@localhost";
enablePHP = true;
};
...
}
$ nixos-rebuild switch
Sander van der Burg Dysnomia

5. Deploying a NixOS configuration
{ pkgs, ... }:
{
services.mysql = {
enable = true;
package = pkgs.mysql;
};
services.httpd = {
enable = true;
documentRoot = "/var/www";
adminAddr = "admin@localhost";
enablePHP = true;
};
...
}
$ nixos-rebuild switch
Sander van der Burg Dysnomia
Deploying NixOS
With a NixOS configuration file, we can reproduce the exact
same configuration elsewhere.

6. Managing state
But, what about my databases?
Nix only manages the static parts of a system, not any state.
Sander van der Burg Dysnomia

7. Managing service-oriented systems with Disnix
Service-oriented systems may have many database components:
Sander van der Burg Dysnomia

8. Managing service-oriented systems with Disnix
To be flexible, we must redeploy regularly respond to events, such
as:
Load increases → distribute services over more machines
Load decreases → consolidate servers and retire obsolete
machines
A machine crashes → redistribute missing services
Sander van der Burg Dysnomia

9. Managing service-oriented systems with Disnix
To be able to migrate state, automation is required!
Sander van der Burg Dysnomia

10. Dysnomia: providing complementary state deployment
Sander van der Burg Dysnomia

11. Dysnomia: Concepts
Mutable component. A unit of state.
Container. An environment that can host one or more
mutable components.
Dysnomia module. An executable implementing deployment
activities for a given component type.
Sander van der Burg Dysnomia

12. Dysnomia: Components
Component configurations capture the (static) initial state of a
component in a container. Examples:
mysql-database: DDL instructions that set up the database
schema
tomcat-webapplication: a Java web application archive (WAR
file)
process: An executable in the bin/ sub folder that should be
launched on startup
Initial state can be generated by a Nix expression.
Sander van der Burg Dysnomia

13. Dysnomia: Example component configuration
˜/testdb
create table author
( AUTHOR_ID INTEGER NOT NULL,
FirstName VARCHAR(255) NOT NULL,
LastName VARCHAR(255) NOT NULL,
PRIMARY KEY(AUTHOR_ID)
);
create table books
( ISBN VARCHAR(255) NOT NULL,
Title VARCHAR(255) NOT NULL,
AUTHOR_ID INTEGER NOT NULL,
PRIMARY KEY(ISBN),
FOREIGN KEY(AUTHOR_ID) REFERENCES author(AUTHOR_ID)
ON UPDATE CASCADE ON DELETE CASCADE
);
Sander van der Burg Dysnomia

14. Dysnomia: Containers
A key = value pair configuration file describing the properties of a
container:
˜/mysql-prod
type=mysql-database
mysqlUsername=root
mysqlPassword=verysecret
One mandatory property: type that refers to Dysnomia
module that executes deployment activities.
Remainder of the properties are arbitrary. They are exposed as
environment variables to the Dysnomia module that executes
deployment activities.
Sander van der Burg Dysnomia

15. Dysnomia: Modules
An executable that takes two command-line parameters:
Activity to execute
Path to the initial state of the component
There are no restrictions imposed on what modules can do.
Modules follow conventions.
Sander van der Burg Dysnomia

16. Dysnomia: Modules
#!/bin/bash -e
case "$1" in
activate)
echo "Echo module: Activate service: $2"
;;
deactivate)
echo "Echo module: Deactivate service: $2"
;;
snapshot)
echo "Echo module: Snapshot state of service: $2"
;;
restore)
echo "Echo module: Restore state of service: $2"
;;
collect-garbage)
echo "Echo module: Collect garbage of service: $2"
;;
esac
Sander van der Burg Dysnomia

17. Dysnomia: executing deployment activities generically
Create and initialize a database:
$ dysnomia --operation activate
--component ~/testdb
--container ~/mysql-prod
Take a snapshot of a database’s current state:
$ dysnomia --operation snapshot
--component ~/testdb
--container ~/mysql-prod
Mark a database as obsolete:
$ dysnomia --operation deactivate
--component ~/testdb
--container ~/mysql-prod
Sander van der Burg Dysnomia

18. Dysnomia: executing deployment activities generically
Delete a database that has been marked as obsolete:
$ dysnomia --operation collect-garbage
--component ~/testdb
--container ~/mysql-prod
Create and initialize a database again:
$ dysnomia --operation activate
--component ~/testdb
--container ~/mysql-prod
Restore the last database snapshot:
$ dysnomia --operation restore
--component ~/testdb
--container ~/mysql-prod
Sander van der Burg Dysnomia

19. Dysnomia: managing snapshots
Dysnomia provides a snapshot store that manages multiple genera-
tions of snapshots:
$ dysnomia-snapshots --query-all
mysql-production/testdb/9b0c3562b57dafd00e480c6b3a...
mysql-production/testdb/1df326254d596dd31d9d9db30e...
mysql-production/testdb/330232eda02b77c3629a4623b4...
Each component type follows its own naming convention for
snapshots
The MySQL module computes the SHA256 hash of the
output and uses it as the snapshot name
Sander van der Burg Dysnomia

20. Dysnomia: managing snapshots
We can automatically delete obsolete snapshots:
$ dysnomia-snapshots --gc --keep 3
The above command keeps the last 3 snapshot generations and
removes the remainder.
Sander van der Burg Dysnomia

21. Deploying a NixOS configuration with state
{ pkgs, ... }:
{
services = {
mysql = {
enable = true;
package = pkgs.mysql;
};
httpd = {
enable = true;
documentRoot = "/var/www";
adminAddr = "admin@localhost";
enablePHP = true;
};
dysnomia = {
enable = true;
components.mysql-database.testdb = ./testdb;
};
};
}
$ nixos-rebuild switch
$ dysnomia-containers --deploy
Sander van der Burg Dysnomia

22. Enabling state deployment in Disnix
{distribution, invDistribution, pkgs, system}:
let
customPkgs = import ../top-level/all-packages.nix {
inherit pkgs system;
};
in
rec {
portaldb = {
name = "portaldb";
pkg = customPkgs.portaldb;
type = "mysql-database";
deployState = true;
};
...
}
State deployment is disabled by default
Annotate each relevant service with deployState = true;
Enable globally by providing the --deploy-state parameter
or by setting the DISNIX DEPLOY STATE environment variable
Sander van der Burg Dysnomia

23. Migrating databases with Disnix
{infrastructure}:
{
usersdb = [ infrastructure.test1 ];
cmsdb = [ infrastructure.test2 ];
cmsgallerydb = [ infrastructure.test1 ];
homeworkdb = [ infrastructure.test2 ];
literaturedb = [ infrastructure.test1 ];
portaldb = [ infrastructure.test2 ];
}
$ disnix-env -s services.nix -i infrastructure.nix -d distribution.nix
Updating the location of a database in the distribution model and
redeploying the system also migrates state from one machine to
another.
Sander van der Burg Dysnomia

24. Disnix: snapshots and restores
It is also possible to use Dysnomia as a primitive backup tool.
To take a snapshot of all deployed mutable components, run:
$ disnix-snapshot
To restore an individual database’s state:
$ disnix-restore --component portaldb
Sander van der Burg Dysnomia

25. Demo
Sander van der Burg Dysnomia

26. Is the state deployment problem solved?
Sander van der Burg Dysnomia

27. Drawbacks
Not all state can be managed by Dysnomia. It only works
with well separated units of state.
Impractical to e.g. manage user accounts and groups
Dysnomia relies on exporting and syncing state to the
filesystem.
May be too expensive (in terms of storage) and time
consuming for large data sets
Impractical to use on a system level in a network.
A snapshot of the entire system is taken. Difficult to manage
components individually.
Dysnomia works well for (large) collections of small data.
It is possible to manage ˜100 MongoDB databases with sizes
between several megabytes/several gigabytes
Sander van der Burg Dysnomia

28. Alternative approaches
Filesystem-level snapshots:
An experimental version of Nix called S-Nix has been developed
using Ext3COW (2008): http://www.cs.uu.nl/education/
scripties/scriptie.php?SID=INF/SCR-2007-053
Faster, cheaper
Difficult to guarantee portability and consistency.
Partition-level snapshots:
NixOps is capable of taking EBS snapshots
Faster, cheaper
Works on system-level. Hard to manage individual databases.
Use database replication engines:
More efficient, no additional storage required beyond the
binary log
Hard to generalize in a framework.
Sander van der Burg Dysnomia

29. Availability
Dysnomia can be used as an independent tool:
https://github.com/svanderburg/dysnomia
Does not require Nix or any Nix-related tools
Integrated in NixOS, by enabling the
services.dysnomia.enable = true; setting
All relevant Dysnomia modules and container configurations
are configured automatically
Integrated in Disnix
Dysnomia should be considered an advanced prototype tool!
Sander van der Burg Dysnomia

30. Questions
Sander van der Burg Dysnomia