Permalink
Find file
Fetching contributors…
Cannot retrieve contributors at this time
156 lines (131 sloc) 5.63 KB
[% WRAPPER layout.tt title="About Disnix" menu='disnix' %]
<p>
Disnix is a distributed service deployment toolset which main
purpose is to deploy service oriented systems (i.e. systems
that can be decomposed into "distributable units") into networks
of machines having various characteristics (such as operating
systems) and is built on top of Nix; a package manager which
has some unique features compared to conventional package
managers to make deployment safe and reliable.
</p>
<h2>Features</h2>
<h3>Declarative distributed systems modeling</h3>
<p>
Like the standard Nix deployment system, Disnix uses
the Nix expression language, which is used to write
specifications for the deployment of distributed
systems.
</p>
<p>
Disnix requires three models each capturing a specific concern
in deploying a distributed system. The services model is used
for specifying the components of a distributed system and
its inter-dependencies. The infrastructure model is used for
specifying the network of machines and their relevant properties.
The distribution model is used to map services to machines
in the network.
</p>
<h3>Complete dependencies</h3>
<p>
The standard Nix package manager ensures that package dependency
specifications are complete on a single system, i.e. <em>intra-dependencies</em>.
Components of a distributed system may have dependencies on other components
running of different machines in the network, i.e. <em>inter-dependencies</em>.
</p>
<p>
Disnix also allows you to specify inter-dependencies of distributed system
components, which can be used to compose distributed system components
into a complete system. If a certain service has an inter-dependency on a
different service, and the dependency is missing, Disnix will notice this
before deploying the system.
</p>
<p>
Moreover, Disnix uses inter-dependency specifcations for the installation
or upgrade process of a distributed system to ensure that every service
is activated or deactivated in the right order and that the system will
not fail due to a missing inter-dependency or a broken inter-dependency
relationship.
</p>
<h3>Atomic upgrades and rollbacks</h3>
<p>
Like the standard Nix package manager, which support atomic upgrades,
Disnix extends this concept to service-oriented systems by mapping the
concepts of the two-phase commit protocol onto Nix deployment operations
to upgrade a distributed system (almost) atomically. Since the Nix
package manager always stores components next to each other in a
Nix store and never overwrites existing files, upgrading a distributed
system is very safe and we can almost always perform a rollback.
</p>
<p>
The only impure step while upgrading, is the deactivation of obsolete
services and activation of newly installed services, a phase in which
users may observe that the system is changing. To make this process
truly atomic, Disnix has an extension mechanism that can be used to
temporary queue/block incoming connections until the transition is
finished. We have developed a simple prototype example with stateful
TCP connections to demonstrate this.
</p>
<h3>Garbage collection</h3>
<p>
Like the standard Nix package manager, Disnix also provides a garbage
collector, which safely removes all obsolete components from the machines
in the network.
</p>
<h3>Portability</h3>
<p>
Disnix is, like Nix, supported on several platforms including most Unix flavours
such as Linux, FreeBSD, OpenBSD and Mac OS X. It is also supported on Windows
using Cygwin.
</p>
<p>
Apart from the portability of Disnix itself, Disnix also allows a user to
deploy a service oriented system into a heterogeneous network (i.e. a network
consisting of various types of machines, running various operating systems).
Disnix reuses Nix's delegation mechanism to build a component for an alien
target platform. Optionally, it can also delegate builds to target
machines in the network.
</p>
<h3>Extensibility</h3>
<p>
Since service-oriented systems can be deployed in heterogeneous networks
consisting of various platforms and using various communication protocols,
and their components can have basically any form, not all operations can be
solved in a generic manner.
</p>
<p>
The architecture of the Disnix toolset is very modular. Disnix uses a
plugin system called Dysnomia to integrate customly developed modules
used for the activation and deactivation of services, and a plugin
system that provides remote access through various RPC protocols.
</p>
<p>
Currently, Disnix includes a SSH wrapper which can be used to access
remote machines through a SSH connection. A seperate extension that
uses SOAP + MTOM is also available. A custom extension can be developed
in a straight forward manner.
</p>
<h3>Data migration and backups</h3>
<p>
Disnix can also optionally take and restore snapshots of the state of deployed
services for backup and migration purposes, e.g. when a service is moved from
one machine to another.
</p>
<p>
Since the snapshot and restore operations differ among component types,
Dysnomia's plugin system is consulted to execute the required snapshot and
restore operations for a given service type.
</p>
<h3>License</h3>
<p>
Disnix is free software; you can redistribute it and/or modify it
under the terms of the
<a href="https://www.gnu.org/licenses/lgpl.html">
GNU Lesser General Public License</a> as published by the
<a href="https://www.fsf.org/">Free Software Foundation</a>;
either version 2.1 of the License, or (at your option) any later
version. Disnix is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
Lesser General Public License for more details.
</p>
[% END %]