NixOps User's Guide

Eelco Dolstra

LogicBlox

Rob Vermaas

LogicBlox

Table of Contents

1. Introduction
2. Installation
3. Overview
A. Command Reference
nixops — deploy a set of NixOS machines
B. Configuration Options
B.1. Machines
B.2. SQS Queues
B.3. EC2 Keypairs
B.4. S3 Buckets
B.5. IAM Roles
B.6. SSH Keypairs
C. Hacking
D. Release Notes
D.1. Release 1.2 (April 30, 2014)
D.2. Release 1.1.1 (October 2, 2013)
D.3. Release 1.1 (September 9, 2013)
D.4. Release 1.0.1 (July 11, 2013)
D.5. Release 1.0 (June 18, 2013)

List of Examples

3.1. trivial.nix: logical network specification
3.2. trivial-vbox.nix: VirtualBox physical network specification
3.3. load-balancer.nix: logical network specification
3.4. load-balancer-vbox.nix: VirtualBox physical network specification
3.5. load-balancer-ec2.nix: EC2 physical network specification

Chapter 1. Introduction

NixOps is a tool for deploying NixOS machines in a network or cloud. It takes as input a declarative specification of a set of “logical” machines and then performs any necessary steps actions to realise that specification: instantiate cloud machines, build and download dependencies, stop and start services, and so on. NixOps has several nice properties:

  • It’s declarative: NixOps specifications state the desired configuration of the machines, and NixOps then figures out the actions necessary to realise that configuration. So there is no difference between doing a new deployment or doing a redeployment: the resulting machine configurations will be the same.

  • It performs fully automated deployment. This is a good thing because it ensures that deployments are reproducible.

  • It performs provisioning. Based on the given deployment specification, it will start missing virtual machines, create disk volumes, and so on.

  • It’s based on the Nix package manager, which has a purely functional model that sets it apart from other package managers. Concretely this means that multiple versions of packages can coexist on a system, that packages can be upgraded or rolled back atomically, that dependency specifications can be guaranteed to be complete, and so on.

  • It’s based on NixOS, which has a declarative approach to describing the desired configuration of a machine. This makes it an ideal basis for automated configuration management of sets of machines. NixOS also has desirable properties such as (nearly) atomic upgrades, the ability to roll back to previous configurations, and more.

  • It’s multi-cloud. Machines in a single NixOps deployment can be deployed to different target environment. For instance, one logical machine can be deployed to a local “physical” machine, another to an automatically instantiated Amazon EC2 instance in the eu-west-1 region, another in the us-east-1 region, and so on. NixOps arranges the necessary network configuration to ensure that these machines can communicate securely with each other (e.g. by setting up encrypted tunnels).

  • It supports separation of “logical” and “physical” aspects of a deployment. NixOps specifications are modular, and this makes it easy to separate the parts that say what logical machines should do from where they should do it. For instance, the former might say that machine X should run a PostgreSQL database and machine Y should run an Apache web server, while the latter might state that X should be instantiated as an EC2 m1.large machine while Y should be instantiated as an m1.small. We could also have a second physical specification that says that X and Y should both be instantiated as VirtualBox VMs on the developer’s workstation. So the same logical specification can easily be deployed to different environments.

  • It uses a single formalism (the Nix expression language) for package management and system configuration management. This makes it very easy to add ad hoc packages to a deployment.

  • It combines system configuration management and provisioning. Provisioning affects configuration management: for instance, if we instantiate an EC2 machine as part of a larger deployment, it may be necessary to put the IP address or hostname of that machine in a configuration file on another machine. NixOps takes care of this automatically.

  • It can provision non-machine cloud resources such as Amazon S3 buckets and EC2 keypairs.

This manual describes how to install NixOps and how to use it. The appendix contains a copy of the NixOps manual page, which is also available by running man nixops.

Chapter 2. Installation

NixOps runs on Linux and Mac OS X. (It may also run on other platforms; the main prerequisite is that Nix runs on your platform.) Installing it requires the following steps:

  1. Install the Nix package manager. You need at least version 1.5. It’s available from the Nix website in binary form for several platforms. Please refer to the installation instruction in the Nix manual for more details.

  2. Obtain the NixOS and Nixpkgs sources and add them to NIX_PATH environment variable so that NixOps can find them. The easiest way to do this is to use the NixOS channel, which also ensures that you get pre-built binaries so that your machine doesn’t have to compile everything locally:

    $ nix-channel --add http://nixos.org/channels/nixos-unstable
    $ nix-channel --update
    $ export NIX_PATH=/nix/var/nix/profiles/per-user/root/channels/nixos
    

    (You may have to replace root in the last line by your own user name if you’ve installed Nix under another user account.)

    Alternatively, you can check out the sources using Git:

    $ cd /some/dir
    $ git clone git://github.com/NixOS/nixos.git
    $ git clone git://github.com/NixOS/nixpkgs.git
    $ export NIX_PATH=/some/dir
    

  3. Install the latest version of NixOps. The latest stable release can be found at http://hydra.nixos.org/project/nixops#tabs-releases. The easiest way to install it is by using the “one-click” install, which can be done from the command line by running

    $ nix-install-package --non-interactive --url url
    

    where url is the URL of the Nix package, e.g. http://hydra.nixos.org/build/5387007/nix/pkg/nixops-1.0pre716_8440d7c-x86_64-linux.nixpkg.

    You can also install the latest unstable build in the same way.

Chapter 3. Overview

This chapter gives a quick overview of how to use NixOps.

Deploying a VirtualBox VM

NixOps deploys machines on the basis of a declarative description of what those machines should do, and where they should be deployed to. These descriptions are specified in the Nix expression language used by the Nix package manager. Example 3.1 shows a minimal specification of a network consisting of only one logical machine named webserver.

Example 3.1. trivial.nix: logical network specification

{
  network.description = "Web server";

  webserver =
    { config, pkgs, ... }:
    { services.httpd.enable = true;
      services.httpd.adminAddr = "alice@example.org";
      services.httpd.documentRoot = "${pkgs.valgrind}/share/doc/valgrind/html";
      networking.firewall.allowedTCPPorts = [ 80 ];
    };
}

This specification consists of a set of top-level attributes describing logical machines (namely webserver) and meta-information (namely network.description). Each attribute not named network describes a logical machine. The value of each logical machine attribute is a NixOS configuration module, which describes the desired configuration of the corresponding machine. Thus, the logical machine webserver should have the Apache httpd web server running, and its document root (rather arbitrarily for demonstration purposes) should be the documentation of the Valgrind package.

To deploy this machine, we also need to provide configuration options that tell NixOps to what environment it should be deployed. Example 3.2 specifies that webserver should be deployed as a VirtualBox instance.

Example 3.2. trivial-vbox.nix: VirtualBox physical network specification

{
  webserver =
    { config, pkgs, ... }:
    { deployment.targetEnv = "virtualbox";
      deployment.virtualbox.memorySize = 1024; # megabytes
    };
}

Before we can deploy the network we need to use the command nixops create to create a NixOps deployment that contains any state associated with the deployment (such as information about instantiated VMs). At creation time, we need to specify the Nix expressions that constitute the complete deployment specification. So to create a deployment for deploying the Apache web server to VirtualBox, we would do:

$ nixops create ./trivial.nix ./trivial-vbox.nix -d trivial
33bced96-5f26-11e1-b9d7-9630d48abec1

Here -d trivial gives the symbolic name trivial to the deployment. Deployments can be identified in two ways: using the UUID printed by nixops create, or using the symbolic name you specified at creation time.

You can print a list of existing deployments using nixops list:

+--------------------------------------+-----------+--------------+------------+------------+
|                 UUID                 |   Name    | Description  | # Machines |    Type    |
+--------------------------------------+-----------+--------------+------------+------------+
| 33bced96-5f26-11e1-b9d7-9630d48abec1 |  trivial  |  Web server  |     0      |            |
+--------------------------------------+-----------+--------------+------------+------------+

The command nixops info shows the current deployment state:

$ nixops info -d trivial
Network UUID: 33bced96-5f26-11e1-b9d7-9630d48abec1
Network description: Web server

+-----------+--------+------------+-------------+------------+
|   Name    | Status |    Type    | Resource Id | IP address |
+-----------+--------+------------+-------------+------------+
| webserver |  New   | virtualbox |             |            |
+-----------+--------+------------+-------------+------------+

The machine status New indicates that the logical machine webserver hasn’t been created yet. The -d option specifies which deployment to use; you can use the symbolic name (-d trivial) or the UUID (-d 33bced96-5f26-11e1-b9d7-9630d48abec1). You can also set the the environment variable NIXOPS_DEPLOYMENT.

The actual deployment is done by running nixops deploy:

$ nixops deploy -d trivial
creating VirtualBox VM ‘webserver’...
Virtual machine 'nixops-33bced96-5f26-11e1-b9d7-9630d48abec1-webserver' is created and registered.
Clone hard disk created in format 'VDI'. UUID: 5a0b0771-7e03-4fab-9c2f-e95888b57db3
Waiting for VM "nixops-33bced96-5f26-11e1-b9d7-9630d48abec1-webserver" to power on...
VM "nixops-33bced96-5f26-11e1-b9d7-9630d48abec1-webserver" has been successfully started.
waiting for IP address of ‘webserver’........................... 192.168.56.101
waiting for SSH on ‘webserver’...
building all machine configurations...
building path(s) `/nix/store/ybrny9h744q8i3x026ccfmdav8qnw7pd-nixos-version'
building path(s) `/nix/store/zxw279xhl6l8yl94gnka8aqv1kkcrrd4-os-release'
fetching path `/nix/store/pn43d3llpsm3pc1ywaxccmw8pmzjqgz0-valgrind-3.7.0'...
…
copying closure to machine ‘webserver’...
copying 376 missing paths to ‘root@192.168.56.101’...
importing path `/nix/store/jfcs9xnfbmiwqs224sb0qqsybbfl3sab-linux-headers-2.6.35.14'
…
activating new configuration on machine ‘webserver’...
updating GRUB 2 menu...
activating the configuration...
…
starting new service ‘httpd’...

NixOps performs the following steps to do the deployment:

  • It creates missing machines. In this case, a VirtualBox instance for the logical machine webserver is started. NixOps then waits to obtain its IP address.

  • It builds the NixOS machine configurations locally. For instance, here Valgrind is built or downloaded because our machine configuration has a dependency on it.

  • It copies the closure of each machine configuration to the corresponding machine.

  • It activates the configuration on each machine. For instance, it starts the httpd systemd service on the webserver machine. This is the only step that has a visible effect; all prior steps do not affect the active configuration of the machines.

The nixops info command will show that a machine was created:

$ nixops info -d trivial
Network UUID: 33bced96-5f26-11e1-b9d7-9630d48abec1
Network description: Web server

+-----------+--------+------------+-----------------------------------------------------+----------------+
|   Name    | Status |    Type    |                    Resource Id                      |   IP address   |
+-----------+--------+------------+-----------------------------------------------------+----------------+
| webserver |   Up   | virtualbox | nixops-33bced96-5f26-11e1-b9d7-9630d48abec1-machine | 192.168.56.101 |
+-----------+--------+------------+-----------------------------------------------------+----------------+

Visit http://192.168.56.101 in a web browser should now show the Valgrind documentation. You can also log in to the virtual machine as root:

$ nixops ssh -d trivial webserver
connecting to 192.168.56.101...
[root@webserver:~]#

The command nixops ssh is a convenience wrapper around ssh that passes the right IP address and SSH identity for the specified logical machine. (NixOps automatically creates a unique SSH key pair for communicating with each VirtualBox instance.)

Redeployment after making a change to the specification is simply a matter of running nixops deploy again. If we do this for the example, NixOps will notice that the webserver machine already exists and that most or all dependencies are already present, so it won’t create a new VirtualBox instance or need to build and copy a lot of dependencies. Thus redeployment typically only takes a few seconds:

$ time nixops deploy -d trivial
building all machine configurations...
copying closure to machine ‘webserver’...
activating new configuration on machine ‘webserver’...
real    0m3.700s

If you want to get rid of the virtual machines created by NixOps, you can run nixops destroy:

warning: are you sure you want to destroy EC2 machine ‘webserver’? (y/N) y
$ nixops destroy -d trivial
destroying VirtualBox VM ‘webserver’...

You can use the option --confirm to confirm all questions. This is useful for automated deployment, but potentially dangerous.

Deploying multiple machines

A network consisting of only one logical machine is not very exciting. Example 3.3 shows a network consisting of three machines: a load balancer (named proxy) that uses Apache’s mod_proxy to do reverse proxying, and two backend web servers (backend1 and backend2) that serve the actual content. One important thing to note is that if you want to refer to another machine (e.g. in a configuration file), you can use a hostname equal to the logical name of the machine, as in the line

BalancerMember http://backend1 retry=0

This works because NixOps generates a /etc/hosts file that contains entries for all the logical machines in the network, mapping names to each machine’s IP address. Also note that because the two backend machines have identical configurations, we can use a let-binding to define the configuration only once.

Example 3.3. load-balancer.nix: logical network specification

let

  backend =
    { config, pkgs, ... }:
    { services.httpd.enable = true;
      services.httpd.adminAddr = "alice@example.org";
      services.httpd.documentRoot = "${pkgs.valgrind}/share/doc/valgrind/html";
    };

in

{
  network.description = "Load balancing network";

  proxy =
    { config, pkgs, nodes, ... }:
    { services.httpd.enable = true;
      services.httpd.adminAddr = "bob@example.org";
      services.httpd.extraModules = ["proxy_balancer"];
      services.httpd.extraConfig =
        ''
          <Proxy balancer://cluster>
            Allow from all
            BalancerMember http://backend1 retry=0
            BalancerMember http://backend2 retry=0
          </Proxy>
          ProxyPass         /    balancer://cluster/
          ProxyPassReverse  /    balancer://cluster/
        '';
    };

  backend1 = backend;
  backend2 = backend;
}

To deploy it, we need a physical specification, shown in Example 3.4. Deployment is as follows:

$ nixops create ./load-balancer.nix ./load-balancer-vbox.nix -d load-balancer-vbox
$ nixops deploy -d load-balancer-vbox

Note that NixOps creates and deploys the VMs in parallel to speed things up.

Example 3.4. load-balancer-vbox.nix: VirtualBox physical network specification

let
  vbox = { deployment.targetEnv = "virtualbox"; };
in
{ proxy    = vbox;
  backend1 = vbox;
  backend2 = vbox;
}

Deploying to Amazon EC2

Example 3.5 shows a physical specification that deploys the load balancer network to Amazon’s Elastic Compute Cloud (EC2). It states that the three machines need to be instantiated in EC2 region eu-west-1. It also specifies a non-machine cloud resource: namely, the EC2 key pair to be used to access the machine via SSH. (It is possible to use manually created EC2 key pairs, but it’s easier to let NixOps provision them.)

Example 3.5. load-balancer-ec2.nix: EC2 physical network specification

let

  region = "eu-west-1";
  accessKeyId = "dev"; # symbolic name looked up in ~/.ec2-keys

  ec2 =
    { resources, ... }:
    { deployment.targetEnv = "ec2";
      deployment.ec2.accessKeyId = accessKeyId;
      deployment.ec2.region = region;
      deployment.ec2.instanceType = "m1.small";
      deployment.ec2.keyPair = resources.ec2KeyPairs.my-key-pair;
    };

in
{ proxy    = ec2;
  backend1 = ec2;
  backend2 = ec2;

  # Provision an EC2 key pair.
  resources.ec2KeyPairs.my-key-pair =
    { inherit region accessKeyId; };
}

Deployment is as follows:

$ nixops create ./load-balancer.nix ./load-balancer-ec2.nix -d load-balancer-ec2
$ nixops deploy -d load-balancer-ec2
my-key-pair> uploading EC2 key pair ‘charon-8e50b4b5-d7f9-11e2-b91c-23f8eaf468f4-my-key-pair’...
backend1...> creating EC2 instance (AMI ‘ami-8badbdff’, type ‘m1.small’, region ‘eu-west-1’)...
backend2...> creating EC2 instance (AMI ‘ami-8badbdff’, type ‘m1.small’, region ‘eu-west-1’)...
proxy......> creating EC2 instance (AMI ‘ami-8badbdff’, type ‘m1.small’, region ‘eu-west-1’)...
backend2...> waiting for IP address...
...
proxy......> activation finished successfully
backend2...> activation finished successfully
backend1...> activation finished successfully

Here NixOps has created an EC2 key pair and started three EBS-backed instances running the default NixOS AMI. Other than that, deployment is the same as for VirtualBox: NixOps builds the machine configurations, copies their closure over to the EC2 instances, and activates the new configurations.

The command nixops info shows all provisioned resources, not just machines:

$ nixops info -d load-balancer-ec2
...
+-------------+-----------------+----------------------------+---------------------------------------------------------+----------------+
| Name        |      Status     | Type                       | Resource Id                                             | IP address     |
+-------------+-----------------+----------------------------+---------------------------------------------------------+----------------+
| backend1    | Up / Up-to-date | ec2 [eu-west-1a; m1.small] | i-0ec4bc43                                              | 54.228.61.132  |
| backend2    | Up / Up-to-date | ec2 [eu-west-1a; m1.small] | i-0cc4bc41                                              | 54.216.26.111  |
| proxy       | Up / Up-to-date | ec2 [eu-west-1a; m1.small] | i-08c4bc45                                              | 54.216.171.138 |
| my-key-pair | Up / Up-to-date | ec2-keypair [eu-west-1]    | charon-8e50b4b5-d7f9-11e2-b91c-23f8eaf468f4-my-key-pair |                |
+-------------+-----------------+----------------------------+---------------------------------------------------------+----------------+

The resources can be destroyed by running:

$ nixops destroy -d load-balancer-ec2

This terminates the EC2 instances and deletes the EC2 key pair.

Deployment to EC2 has some prerequisites.

  • Obviously, you need an EC2 account.

  • You need to add your AWS access key ID and secret key to the file ~/.ec2-keys, as follows:

    AKIAIUTDLWJKSLSJDLDQ Grsjf37cDKKWndklek3jdxnSKE3fkskDLqdldDl/ dev # my AWS development account
    

    Here dev is a symbolic name for the AWS account, which you can use in deployment.ec2.accessKeyId.

    Alternatively, you can set the environment variables EC2_ACCESS_KEY and EC2_SECRET_KEY.

  • You need to ensure that your EC2 security groups are set up to allow (at the very least) SSH traffic from your network. By default, NixOps uses the security group default. You can set the option deployment.ec2.securityGroups to use other security groups:

    deployment.ec2.securityGroups = [ "allow-ssh" "allow-http" ];
    

  • You need to set deployment.ec2.region to the EC2 region you want to deploy to. Note that key pairs and security groups are region-specific.

Deploying to Hetzner physical machines

In order to deploy to Hetzner machines, you need to have a valid account to their server management interface, called the Robot. This account is only used for the initial deployment and the destruction of a machine. In particular the initial deployment creates a separate Robot account just for the machine that's going to be created, so a person who has access to your deployment will only have access to the machines within the deployment and not all machines that are associated with your main Robot account. When destroying a machine, the separate admin account is removed as well.

Of course you need machines where you can deploy to, which can only be ordered by the Robot's web interface. In the expression of the NixOps network, you reference these machines by setting deployment.hetzner.mainIPv4 to the corresponding main IP address, to be found in the list of the Server tab in the Robot.

Partitioning of a machine is currently done by using Anaconda's Kickstart format. By default, it consists of two disks with two swap partitions, one on each disk and one big ext4 array with RAID1, similiar to the default layout Hetzner is using for installing their Debian machines. If you want to change the default, you can use deployment.hetzner.partitions to change the default layout. For example to install a machine with btrfs:

{
  example = {
    deployment.targetEnv = "hetzner";
    deployment.hetzner.mainIPv4 = "1.2.3.4";
    deployment.hetzner.partitions = ''
      clearpart --all --initlabel --drives=sda,sdb

      part swap1 --recommended --label=swap1 --fstype=swap --ondisk=sda
      part swap2 --recommended --label=swap2 --fstype=swap --ondisk=sdb

      part btrfs.1 --grow --ondisk=sda
      part btrfs.2 --grow --ondisk=sdb

      btrfs / --data=1 --metadata=1 --label=root btrfs.1 btrfs.2
    '';
  };
}

This will install NixOS on a machine with the main IP 1.2.3.4, using a swap partition for each drive and use everything else for a single btrfs volume.

In the previous example, there is no occurence of deployment.hetzner.robotUser and deployment.hetzner.robotPass, you can set the credentials to your main Robot account there, however it is recommended to use the environment variables HETZNER_ROBOT_USER and HETZNER_ROBOT_PASS, as you only need them for initial deployment and destruction.

Accessing machines

We have seen above that you can login to individual machines by doing nixops ssh name, where name is the name of the machine.

It’s also possible to perform a command on all machines:

$ nixops ssh-for-each -d load-balancer-ec2 -- df /tmp
backend1...> /dev/xvdb      153899044 192084 145889336   1% /tmp
proxy......> /dev/xvdb      153899044 192084 145889336   1% /tmp
backend2...> /dev/xvdb      153899044 192084 145889336   1% /tmp

By default, the command is executed sequentially on each machine. You can add the flag -p to execute it in parallel.

Checking machine status

The command nixops check checks the status of each machine in a deployment. It verifies that the machine still exists (i.e. hasn’t been destroyed outside of NixOps), is up (i.e. the instance has been started) and is reachable via SSH. It also checks that any attached disks (such as EBS volumes) are not in a failed state, and prints the names of any systemd units that are in a failed state.

For example, for the 3-machine EC2 network shown above, it might show:

$ nixops check -d load-balancer-ec2
+----------+--------+-----+-----------+----------+----------------+---------------+-------+
| Name     | Exists | Up  | Reachable | Disks OK | Load avg.      | Failed units  | Notes |
+----------+--------+-----+-----------+----------+----------------+---------------+-------+
| backend1 | Yes    | Yes | Yes       | Yes      | 0.03 0.03 0.05 | httpd.service |       |
| backend2 | Yes    | No  | N/A       | N/A      |                |               |       |
| proxy    | Yes    | Yes | Yes       | Yes      | 0.00 0.01 0.05 |               |       |
+----------+--------+-----+-----------+----------+----------------+---------------+-------+

This indicates that Apache httpd has failed on backend1 and that machine backend is not running at all. In this situation, you should run nixops deploy --check to repair the deployment.

Network arguments

In NixOps you can pass in arguments from outside the nix expression. The network file can be a nix function, which takes a set of arguments which are passed in externally and can be used to change configuration values, or even to generate a variable number of machines in the network.

Here is an example of a network with network arguments:

{ maintenance ? false
}:
{
  machine =
    { config, pkgs, ... }:
    { services.httpd.enable = maintenance;
      ...
    };
}

This network has a maintenance argument that defaults to false. This value can be used inside the network expression to set NixOS option, in this case whether or not Apache HTTPD should be enabled on the system.

You can pass network arguments using the set-args nixops command. For example, if we want to set the maintenance argument to true in the previous example, you can run:

  $ nixops set-args --arg maintenance true -d <name>

The arguments that have been set will show up:

$ nixops info -d argtest
Network name: argtest
Network UUID: 634d6273-f9f6-11e2-a004-15393537e5ff
Network description: Unnamed NixOps network
Nix expressions: .../network-arguments.nix
Nix arguments: maintenance = true

+---------+---------------+------+-------------+------------+
| Name    |     Status    | Type | Resource Id | IP address |
+---------+---------------+------+-------------+------------+
| machine | Missing / New | none |             |            |
+---------+---------------+------+-------------+------------+

Running nixops deploy after changing the arguments will deploy the new configuration.

Appendix A. Command Reference

Table of Contents

nixops — deploy a set of NixOS machines

Name

nixops — deploy a set of NixOS machines

Synopsis

nixops { --version | --help | command [arguments...] } [ { --state | -s } statefile ] [ { --deployment | -d } uuid-or-name ] [--confirm] [--debug]

Description

NixOps is a tool for deploying NixOS machines in a network or cloud.

Common options

--state, -s

Path to the state file that contains the deployments. It defaults to the value of the NIXOPS_STATE environment variable, or ~/.nixops/deployments.nixops if that one is not defined. It must have extension .nixops. The state file is actually a SQLite database that can be inspected using the sqlite3 command (for example, sqlite3 deployments.nixops .dump). If it does not exist, it is created automatically.

--deployment, -d

UUID or symbolic name of the deployment on which to operate. Defaults to the value of the NIXOPS_DEPLOYMENT environment variable.

--confirm

Automatically confirm “dangerous” actions, such as terminating EC2 instances or deleting EBS volumes. Without this option, you will be asked to confirm each dangerous action interactively.

--debug

Turn on debugging output. In particular, this causes NixOps to print a Python stack trace if an unhandled exception occurs.

--help

Print a brief summary of NixOps’s command line syntax.

--version

Print NixOps’s version number.

Environment variables

NIXOPS_STATE

The location of the state file if --state is not used. It defaults to ~/.nixops/deployments.nixops.

NIXOPS_DEPLOYMENT

UUID or symbolic name of the deployment on which to operate. Can be overriden using the -d option.

EC2_ACCESS_KEY, AWS_ACCESS_KEY_ID

AWS Access Key ID used to communicate with the Amazon EC2 cloud. Used if deployment.ec2.accessKeyId is not set in an EC2 machine’s configuration.

EC2_SECRET_KEY, AWS_SECRET_ACCESS_KEY

AWS Secret Access Key used to communicate with the Amazon EC2 cloud. It is only used if no secret key corresponding to the AWS Access Key ID is defined in ~/.ec2-keys.

HETZNER_ROBOT_USER, HETZNER_ROBOT_PASS

Username and password used to access the Robot for Hetzner deployments.

Files

~/.ec2-keys

This file maps AWS Access Key IDs to their corresponding Secret Access Keys. Each line must consist of an Access Key IDs, a Secret Access Keys and an optional symbolic identifier, separated by whitespace. Comments starting with # are stripped. An example:

AKIAIUTDLWJKSLSJDLDQ Grsjf37cDKKWndklek3jdxnSKE3fkskDLqdldDl/ dev # AWS development account
AKIAEODJSLXMDLLJKDLW DLeodsk32kldlDLSKdflexfpgiklf130r4dl23qp prod # AWS production account

The identifier can be used instead of actual Access Key IDs in deployment.ec2.accessKeyId, e.g.

deployment.ec2.accessKeyId = "prod";

This is useful if you have an AWS account with multiple user accounts and you don’t want to hard-code an Access Key ID in a NixOps specification.

Command nixops create

Synopsis

nixops create nixexprs... [ -I path ...]

Description

This command creates a new deployment state record in NixOps’s database. The paths of the Nix expressions that specify the desired deployment (nixexprs) are stored in the state file. The UUID of the new deployment is printed on standard output.

Options

-I path

Add path to the Nix expression search path for all future evaluations of the deployment specification. NixOps stores path in the state file. This option may be given multiple times. See the description of the -I option in nix-instantiate(1) for details.

--deployment, -d

Set the symbolic name of the new deployment to the given string. The name can be used to refer to the deployment by passing the option -d name or the environment variable NIXOPS_DEPLOYMENT=name to subsequent NixOps invocations. This is typically more convenient than using the deployment’s UUID. However, names are not required to be unique; if you create multiple deployments with the same name, NixOps will complain.

Examples

To create a deployment with symbolic name foo, and then perform the actual deployment:

$ nixops create expr1.nix expr2.nix -d foo
created deployment ‘32b06868-d27c-11e2-a055-81d7beb7925e’

$ nixops deploy -d foo

Command nixops modify

Synopsis

nixops modify nixexprs... [ { --name | -n } name ] [ -I path ...]

Description

This command modifies an existing deployment. The options are the same as for nixops create. The symbolic name of the deployment can be changed using the --name flag.

Examples

To change the Nix expressions specifying the deployment, and rename it from foo to bar:

$ nixops modify -d foo -n bar expr3.nix expr4.nix

Note that -d identifies the existing deployment, while -n specifies its new name.

Command nixops clone

Synopsis

nixops clone [ { --name | -n } name ]

Description

This command clones an existing deployment; that is, it create a new deployment that has the same deployment specification and parameters, but a different UUID and (optionally) name. Note that nixops clone does not currently clone the state of the machines in the existing deployment. Thus, when you first run nixops deploy on the cloned deployment, NixOps will create new instances from scratch.

Examples

To create a new deployment bar by cloning the deployment foo:

$ nixops clone -d foo -n bar

Command nixops delete

Synopsis

nixops delete [--all] [--force]

Description

This command deletes a deployment from the state file. NixOps will normally refuse to delete the deployment if any resources belonging to the deployment (such as virtual machines) still exist. You must run nixops destroy first to get rid of any such resources. However, if you pass --force, NixOps will forget about any still-existing resources; this should be used with caution.

If the --all flag is given, all deployments in the state file are deleted.

Examples

To delete the deployment named foo:

$ nixops delete -d foo

Command nixops deploy

Synopsis

nixops deploy [ --kill-obsolete | -k ] [--dry-run] [--repair] [--create-only] [--build-only] [--copy-only] [--check] [--allow-reboot] [--force-reboot] [--allow-recreate] [ --include machine-name... ] [ --exclude machine-name... ] [ -I path ...] [ --max-concurrent-copy N ]

Description

This command deploys a set of machines on the basis of the specification described by the Nix expressions given in the preceding nixops create call. It creates missing virtual machines, builds each machine configuration, copies the closure of each configuration to the corresponding machine, and activates them.

Options

--kill-obsolete, -k

Destroy (terminate) virtual machines that were previously created as part of this deployment, but are obsolete because they are no longer mentioned in the deployment specification. This happens if you remove a machine from the specification after having run nixops deploy to create it. Without this flag, such obsolete machines are left untouched.

--dry-run

Dry run; show what would be done by this command without actually doing it.

--repair

Use --repair when calling nix-build. This is useful for repairing the nix store when some inconsistency is found and nix-copy-closure is failing as a result. Note that this option only works in nix setups that run without the nix daemon.

--create-only

Exit after creating any missing machines. Nothing is built and no existing machines are touched.

--build-only

Just build the configuration locally; don’t create or deploy any machines. Note that this may fail if the configuration refers to information only known after machines have been created (such as IP addresses).

--copy-only

Exit after creating missing machines, building the configuration and copying closures to the target machines; i.e., do everything except activate the new configuration.

--check

Normally, NixOps assumes that the deployment state of machines doesn’t change behind its back. For instance, it assumes that a VirtualBox VM, once started, will continue to run unless you run nixops destroy to terminate it. If this is not the case, e.g., because you shut down or destroyed a machine through other means, you should pass the --check option to tell NixOps to verify its current knowledge.

--allow-reboot

Allow NixOps to reboot the instance if necessary. For instance, if you change the type of an EC2 instance, NixOps must stop, modify and restart the instance to effectuate this change.

--force-reboot

Reboot the machine to activate the new configuration (using nixos-rebuild boot).

--allow-recreate

Recreate resources that have disappeared (e.g. destroyed through mechanisms outside of NixOps). Without this flag, NixOps will print an error if a resource that should exist no longer does.

--include machine-name...

Only operate on the machines explicitly mentioned here, excluding other machines.

--exclude machine-name...

Only operate on the machines that are not mentioned here.

-I path

Add path to the Nix expression search path. This option may be given multiple times and takes precedence over the -I flags used in the preceding nixops create invocation. See the description of the -I option in nix-instantiate(1) for details.

--max-concurrent-copy N

Use at most N concurrent nix-copy-closure processes to deploy closures to the target machines. N defaults to 5.

Examples

To deploy all machines:

$ nixops deploy

To deploy only the logical machines foo and bar, checking whether their recorded deployment state is correct:

$ nixops deploy --check --include foo bar

To create any missing machines (except foo) without doing anything else:

$ nixops deploy --create-only --exclude foo

Command nixops destroy

Synopsis

nixops destroy [--all] [ --include machine-name... ] [ --exclude machine-name... ]

Description

This command destroys (terminates) all virtual machines previously created as part of this deployment, and similarly deletes all disk volumes if they’re marked as “delete on termination”. Unless you pass the --confirm option, you will be asked to approve every machine destruction.

This command has no effect on machines that cannot be destroyed automatically; for instance, machines in the none target environment (such as physical machines, or virtual machines not created by NixOps).

Options

--all

Destroy all deployments.

--include machine-name...

Only destroy the machines listed here.

--exclude machine-name...

Destroy all machines except the ones listed here.

Examples

To destroy all machines:

$ nixops destroy

To destroy the machine named foo:

$ nixops destroy foo

Command nixops stop

Synopsis

nixops stop [ --include machine-name... ] [ --exclude machine-name... ]

Description

This command stops (shuts down) all non-obsolete machines that can be automatically started. This includes EC2 and VirtualBox machines, but not machines using the none backend (because NixOps doesn’t know how to start them automatically).

Options

--include machine-name...

Only stop the machines listed here.

--exclude machine-name...

Stop all machines except the ones listed here.

Examples

To stop all machines that support being stopped:

$ nixops stop

Command nixops start

Synopsis

nixops start [ --include machine-name... ] [ --exclude machine-name... ]

Description

This command starts all non-obsolete machines previously stopped using nixops stop.

Options

--include machine-name...

Only start the machines listed here.

--exclude machine-name...

Start all machines except the ones listed here.

Examples

To start all machines that were previously stopped:

$ nixops start

Command nixops list

Synopsis

nixops list

Description

This command prints information about all deployments in the database: the UUID, the name, the description, the number of running or stopped machines, and the types of those machines.

Examples

$ nixops list
+--------------------------------------+------------------------+------------------------+------------+------------+
|                 UUID                 |          Name          |      Description       | # Machines |    Type    |
+--------------------------------------+------------------------+------------------------+------------+------------+
| 80dc8e11-287d-11e2-b05a-a810fd2f513f |          test          |      Test network      |     4      |    ec2     |
| 79fe0e26-d1ec-11e1-8ba3-a1d56c8a5447 |   nixos-systemd-test   | Unnamed NixOps network |     1      | virtualbox |
| 742c2a4f-0817-11e2-9889-49d70558c59e |       xorg-test        | NixOS X11 Updates Test |     0      |            |
+--------------------------------------+------------------------+------------------------+------------+------------+

Command nixops info

Synopsis

nixops info [--all] [--plain] [--no-eval]

Description

This command prints some information about the current state of the deployment. For each machine, it prints:

  • The logical name of the machine.

  • Its state, which is one of New (not deployed yet), Up (created and up to date), Outdated (created but not up to date with the current configuration, e.g. due to use of the --exclude option to nixops deploy) and Obsolete (created but no longer present in the configuration).

  • The type of the machine (i.e. the value of deployment.targetEnv, such as ec2). For EC2 machines, it also shows the machine’s region or availability zone.

  • The virtual machine identifier, if applicable. For EC2 machines, this is the instance ID. For VirtualBox VMs, it’s the virtual machine name.

  • The IP address of the machine. This is its public IP address, if it has one, or its private IP address otherwise. (For instance, VirtualBox machines only have a private IP address.)

Options

--all

Print information about all resources in all known deployments, rather than in a specific deployment.

--plain

Print the information in a more easily parsed format where columns are separated by tab characters and there are no column headers.

--no-eval

Do not evaluate the deployment specification. Note that as a consequence the “Status” field in the output will show all machines as “Obsolete” (since the effective deployment specification is empty).

Examples

$ nixops info -d foo
Network name: test
Network UUID: 80dc8e11-287d-11e2-b05a-a810fd2f513f
Network description: Test network
Nix expressions: /home/alice/test-network.nix

+----------+-----------------+------------------------------+------------+-----------------+
|   Name   |      Status     |             Type             |   VM Id    |    IP address   |
+----------+-----------------+------------------------------+------------+-----------------+
| backend0 |  Up / Outdated  | ec2 [us-east-1b; m2.2xlarge] | i-905e9def |   23.23.12.249  |
| backend1 |  Up / Outdated  | ec2 [us-east-1b; m2.2xlarge] | i-925e9ded |  184.73.128.122 |
| backend2 |  Up / Obsolete  | ec2 [us-east-1b; m2.2xlarge] | i-885e9df7 | 204.236.192.216 |
| frontend | Up / Up-to-date |  ec2 [us-east-1c; m1.large]  | i-945e9deb |  23.23.161.169  |
+----------+-----------------+------------------------------+------------+-----------------+

Command nixops check

Synopsis

nixops check [--all]

Description

This command checks and prints the status of each machine in the deployment. For instance, for an EC2 machine, it will ask EC2 whether the machine is running or stopped. If a machine is supposed to be up, NixOps will try to connect to the machine via SSH and get the current load average statistics.

Options

--all

Check all machines in all known deployments, rather than in a specific deployment.

Examples

For a running VirtualBox instance, NixOps will print something like:

$ nixops status
machine> VM state is ‘running’
machine> pinging SSH... up [1.03 0.34 0.12]

For a stopped EC2 instance, NixOps might show:

machine> instance state is ‘stopped’

Command nixops ssh

Synopsis

nixops ssh [username@]machine [ command [args...] ]

Description

This command opens an SSH connection to the specified machine and executes the specified command. If no command if specified, an interactive shell is started.

Options

--include-keys

Include the public SSH host keys into .ssh/known_hosts for all machines in the imported network.

Examples

To start a shell on machine foo:

$ nixops ssh foo

To run Emacs on machine bar:

$ nixops ssh bar -- -X emacs

Note the use of -- to force the flag -X (“enable X11 forwarding”) to be passed to SSH.

Command nixops ssh-for-each

Synopsis

nixops ssh-for-each [ --parallel | -p ] [ --include machine-name... ] [ --exclude machine-name... ] [ command [args...] ]

Description

This operation executes the specified shell command on all non-obsolete machines.

Options

--parallel

Execute the command on each machine in parallel. The default is to do each machine sequentially.

--include machine-name...

Execute the command only on the machines listed here.

--exclude machine-name...

Execute the command on all machines except the ones listed here.

Examples

To reboot all machines in parallel:

$ nixops ssh-for-each -p reboot

Command nixops reboot

Synopsis

nixops reboot [ --include machine-name... ] [ --exclude machine-name... ] [ --no-wait ] [ command [args...] ]

Description

This command reboots all non-obsolete machines. If the option --parallel is given, the command is executed on all machines in parallel; otherwise, it’s executed sequentially.

Options

--include machine-name...

Only reboot the machines listed here.

--exclude machine-name...

Reboot all machines except the ones listed here.

--no-wait

Do not wait until the machines have finished rebooting.

Examples

To reboot all machines except foo and wait until they’re up again, that is, are reachable via SSH again:

$ nixops reboot --exclude foo

Command nixops backup

Synopsis

nixops backup [ --include machine-name... ] [ --exclude machine-name... ]

Description

This command makes a backup of all persistent disks of all machines. Currently this is only implemented for EC2 EBS instances/volumes.

Options

--include machine-name...

Only backup the persistent disks of the machines listed here.

--exclude machine-name...

Backup the persistent disks of all machines except the ones listed here.

Examples

To backup the persistent disks of all machines:

$ nixops backup

Command nixops restore

Synopsis

nixops restore [ --include machine-name... ] [ --exclude machine-name... ] [ --backup-id backup-id... ]

Description

This command restores a machine to a backup.

Options

--include machine-name...

Only backup the persistent disks of the machines listed here.

--exclude machine-name...

Restore the persistent disks of all machines to a given backup except the ones listed here.

--devices device-name...

Restore only the persistent disks which are mapped to the specified device names.

--backup-idbackup-id

Restore the persistent disks of all machines to a given backup except the ones listed here.

Examples

To list the available backups and restore the persistent disks of all machines to a given backup:

            $ nixops backup-status
            $ nixops restore --backup-id 20120803151302

Restore the persistent disks at device /dev/xvdf of all machines to a given backup:

            $ nixops restore --devices /dev/xvdf --backup-id 20120803151302

Command nixops show-option

Synopsis

nixops show-option [--xml] machine option

Description

This command prints the value of the specified NixOS configuration option for the specified machine.

Examples

$ nixops show-option machine services.xserver.enable
false

$ nixops show-option --xml machine boot.initrd.availableKernelModules
<?xml version='1.0' encoding='utf-8'?>
<expr>
  <list>
    <string value="md_mod" />
    <string value="raid0" />
    
  </list>
</expr>

Command nixops set-args

Synopsis

nixops set-args [ --arg name value ...] [ --argstr name value ...] [ --unset name ...]

Description

This command persistently sets arguments to be passed to the deployment specification.

Options

--arg name value

Set the function argument name to value, where the latter is an arbitrary Nix expression.

--argstr name value

Like --arg, but the value is a literal string rather than a Nix expression. Thus, --argstr name value is equivalent to --arg name \"value\".

--unset name

Remove a previously set function argument.

Examples

Consider the following deployment specification (servers.nix):

{ nrMachines, active }:

with import <nixpkgs/pkgs/lib>;

let

  makeMachine = n: nameValuePair "webserver-${toString n}"
    ({ config, pkgs, ... }:
    { deployment.targetEnv = "virtualbox";
      services.httpd.enable = active;
      services.httpd.adminAddr = "foo@example.org";
    });

in listToAttrs (map makeMachine (range 1 nrMachines))

This specifies a network of nrMachines identical VirtualBox VMs that run the Apache web server if active is set. To create 10 machines without Apache:

$ nixops create servers.nix
$ nixops set-args --arg nrMachines 10 --arg active false
$ nixops deploy

Next we can enable Apache on the existing machines:

$ nixops set-args --arg active true
$ nixops deploy

or provision additional machines:

$ nixops set-args --arg nrMachines 20
$ nixops deploy

Command nixops show-console-output

Synopsis

nixops show-console-output machine

Description

This command prints the console output of the specified machine, if available. Currently this is only supported for the EC2 backend.

Examples

$ nixops show-console-output machine
Xen Minimal OS!
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 3.2.36 (nixbld@) (gcc version 4.6.3 (GCC) ) #1 SMP Fri Jan 4 16:07:14 UTC 2013

Command nixops export

Synopsis

nixops export [--all]

Description

This command exports the state of the specified deployment, or all deployments if --all is given, as a JSON represention to standard output. The deployment(s) can be imported into another state file using nixops import.

Examples

To export a specific deployment, and import it into the state file other.nixops:

$ nixops export -d foo > foo.json
$ nixops import -s other.nixops < foo.json
added deployment ‘2bbaddca-01cb-11e2-88b2-19d91ca51c50’

If desired, you can then remove the deployment from the old state file:

$ nixops delete -d foo --force

To export all deployments:

$ nixops export --all > all.json

Command nixops import

Synopsis

nixops import [--include-keys]

Description

This command creates deployments from the state data exported by nixops export. The state is read from standard input. See nixops export for examples.

Appendix B. Configuration Options

B.1. Machines

NixOps adds several options to the NixOS machine configuration system. For the standard NixOS configuration options, please see the NixOS manual or the configuration.nix(5) man page.

deployment.alwaysActivate

Always run the activation script, no matter whether the configuration has changed (the default). This behaviour can be enforced even if it's set to false using the command line option --always-activate on deployment. If this is set to false, activation is done only if the new system profile doesn't match the previous one.

Default: true

Declared by:

/nix/store/bdqc6a697zls0wdpi5319qdlj10r3sx5-git-export/nix/options.nix
deployment.autoLuks

The LUKS volumes to be created. The name of each attribute set specifies the name of the LUKS volume; thus, the resulting device will be named /dev/mapper/name.

Default: { }

Example: { secretdisk = { device = "/dev/xvdf"; passphrase = "foobar"; } ; }

Declared by:

/nix/store/bdqc6a697zls0wdpi5319qdlj10r3sx5-git-export/nix/auto-luks.nix
deployment.autoLuks.<name>.autoFormat

If the underlying device does not currently contain a filesystem (as determined by blkid, then automatically initialise it using cryptsetup luksFormat.

Default: false

deployment.autoLuks.<name>.cipher

The cipher used to encrypt the volume.

Default: "aes-cbc-essiv:sha256"

deployment.autoLuks.<name>.device

The underlying (encrypted) device.

Example: "/dev/xvdg"

deployment.autoLuks.<name>.keySize

The size in bits of the encryption key.

Default: 128

deployment.autoLuks.<name>.passphrase

The passphrase (key file) used to decrypt the key to access the volume. If left empty, a passphrase is generated automatically; this passphrase is lost when you destroy the machine or underlying device, unless you copy it from NixOps's state file. Note that unless deployment.storeKeysOnMachine is set to false, the passphrase is stored in the Nix store of the instance, so an attacker who gains access to the disk containing the store can subsequently decrypt the encrypted volume.

Default: ""

deployment.autoRaid0

The RAID-0 volumes to be created. The name of each attribute set specifies the name of both the volume group and the logical volume; thus, the resulting device will be named /dev/name/name.

Default: { }

Example: { bigdisk = { devices = [ "/dev/xvdg" "/dev/xvdh" ] ; } ; }

Declared by:

/nix/store/bdqc6a697zls0wdpi5319qdlj10r3sx5-git-export/nix/auto-raid0.nix
deployment.autoRaid0.<name>.devices

The underlying devices to be combined into a RAID-0 volume.

Example: [ "/dev/xvdg" "/dev/xvdh" ]

deployment.ec2.accessKeyId

The AWS Access Key ID. If left empty, it defaults to the contents of the environment variables EC2_ACCESS_KEY or AWS_ACCESS_KEY_ID (in that order). The corresponding Secret Access Key is not specified in the deployment model, but looked up in the file ~/.ec2-keys, which should specify, on each line, an Access Key ID followed by the corresponding Secret Access Key. If it does not appear in that file, the environment variables environment variables EC2_SECRET_KEY or AWS_SECRET_ACCESS_KEY are used.

Default: ""

Example: "AKIAIEMEJZVMPOHZWKZQ"

Declared by:

/nix/store/bdqc6a697zls0wdpi5319qdlj10r3sx5-git-export/nix/ec2.nix
deployment.ec2.ami

EC2 identifier of the AMI disk image used in the virtual machine. This must be a NixOS image providing SSH access.

Example: "ami-ecb49e98"

Declared by:

/nix/store/bdqc6a697zls0wdpi5319qdlj10r3sx5-git-export/nix/ec2.nix
deployment.ec2.blockDeviceMapping

Block device mapping. /dev/xvd[a-e] must be ephemeral devices.

Default: { }

Example: { /dev/xvdb = { disk = "ephemeral0"; } ; /dev/xvdg = { disk = "vol-d04895b8"; } ; }

Declared by:

/nix/store/bdqc6a697zls0wdpi5319qdlj10r3sx5-git-export/nix/ec2.nix
deployment.ec2.blockDeviceMapping.<name>.cipher

The cipher used to encrypt the disk.

Default: "aes-cbc-essiv:sha256"

deployment.ec2.blockDeviceMapping.<name>.deleteOnTermination

For automatically created EBS volumes, determines whether the volume should be deleted on instance termination.

deployment.ec2.blockDeviceMapping.<name>.disk

EC2 identifier of the disk to be mounted. This can be an ephemeral disk (e.g. ephemeral0), a snapshot ID (e.g. snap-1cbda474) or a volume ID (e.g. vol-d04895b8). Leave empty to create an EBS volume automatically. It can also be an EBS resource (e.g. resources.ebsVolumes.big-disk).

Default: ""

Example: "vol-d04895b8"

deployment.ec2.blockDeviceMapping.<name>.encrypt

Whether the EBS volume should be encrypted using LUKS.

Default: false

deployment.ec2.blockDeviceMapping.<name>.fsType

Filesystem type for automatically created EBS volumes.

Default: "ext4"

deployment.ec2.blockDeviceMapping.<name>.iops

The provisioned IOPs you want to associate with this EBS volume.

Default: 0

deployment.ec2.blockDeviceMapping.<name>.keySize

The size of the encryption key.

Default: 128

deployment.ec2.blockDeviceMapping.<name>.passphrase

The passphrase (key file) used to decrypt the key to access the device. If left empty, a passphrase is generated automatically; this passphrase is lost when you destroy the machine or remove the volume, unless you copy it from NixOps's state file. Note that the passphrase is stored in the Nix store of the instance, so an attacker who gains access to the EBS volume or instance store that contains the Nix store can subsequently decrypt the encrypted volume.

Default: ""

deployment.ec2.blockDeviceMapping.<name>.size

Volume size (in gigabytes) for automatically created EBS volumes.

Default: 0

deployment.ec2.blockDeviceMapping.<name>.volumeType

The volume type for the EBS volume. (standard/io1/gp2)

Default: "standard"

deployment.ec2.controller

URI of an Amazon EC2-compatible cloud controller web service, used to create and manage virtual machines. If you're using EC2, it's more convenient to set deployment.ec2.region.

Example: "https://ec2.eu-west-1.amazonaws.com/"

Declared by:

/nix/store/bdqc6a697zls0wdpi5319qdlj10r3sx5-git-export/nix/ec2.nix
deployment.ec2.ebsBoot

Whether you want to boot from an EBS-backed AMI. Only EBS-backed instances can be stopped and restarted, and attach other EBS volumes at boot time. This option determines the selection of the default AMI; if you explicitly specify deployment.ec2.ami, it has no effect.

Default: true

Declared by:

/nix/store/bdqc6a697zls0wdpi5319qdlj10r3sx5-git-export/nix/ec2.nix
deployment.ec2.ebsInitialRootDiskSize

Preferred size (G) of the root disk of the EBS-backed instance. By default, EBS-backed images have a root disk of 20G. Only supported on creation of the instance.

Default: 0

Declared by:

/nix/store/bdqc6a697zls0wdpi5319qdlj10r3sx5-git-export/nix/ec2.nix
deployment.ec2.ebsOptimized

Whether the EC2 instance should be created as an EBS Optimized instance.

Default: false

Declared by:

/nix/store/bdqc6a697zls0wdpi5319qdlj10r3sx5-git-export/nix/ec2.nix
deployment.ec2.elasticIPv4

Elastic IPv4 address to be associated with this machine.

Default: ""

Example: "203.0.113.123"

Declared by:

/nix/store/bdqc6a697zls0wdpi5319qdlj10r3sx5-git-export/nix/ec2.nix
deployment.ec2.instanceId

EC2 instance id (set by nixops).

Default: ""

Declared by:

/nix/store/bdqc6a697zls0wdpi5319qdlj10r3sx5-git-export/nix/ec2.nix
deployment.ec2.instanceProfile

The name of the IAM Instance Profile (IIP) to associate with the instances.

Default: ""

Example: "rolename"

Declared by:

/nix/store/bdqc6a697zls0wdpi5319qdlj10r3sx5-git-export/nix/ec2.nix
deployment.ec2.instanceType

EC2 instance type. See http://aws.amazon.com/ec2/instance-types/ for a list of valid Amazon EC2 instance types.

Default: "m1.small"

Example: "m1.large"

Declared by:

/nix/store/bdqc6a697zls0wdpi5319qdlj10r3sx5-git-export/nix/ec2.nix
deployment.ec2.keyPair

Name of the SSH key pair to be used to communicate securely with the instance. Key pairs can be created using the ec2-add-keypair command.

Example: "my-keypair"

Declared by:

/nix/store/bdqc6a697zls0wdpi5319qdlj10r3sx5-git-export/nix/ec2.nix
deployment.ec2.physicalProperties

Attribute set containing number of CPUs and memory available to the machine.

Default: { }

Example: { cores = 4; memory = 14985; }

Declared by:

/nix/store/bdqc6a697zls0wdpi5319qdlj10r3sx5-git-export/nix/ec2.nix
deployment.ec2.placementGroup

Placement group for the instance.

Default: ""

Example: "my-cluster"

Declared by:

/nix/store/bdqc6a697zls0wdpi5319qdlj10r3sx5-git-export/nix/ec2.nix
deployment.ec2.privateKey

Path of the SSH private key file corresponding with deployment.ec2.keyPair. NixOps will use this private key if set; otherwise, the key must be findable by SSH through its normal mechanisms (e.g. it should be listed in ~/.ssh/config or added to the ssh-agent).

Default: ""

Example: "/home/alice/.ssh/id_rsa-my-keypair"

Declared by:

/nix/store/bdqc6a697zls0wdpi5319qdlj10r3sx5-git-export/nix/ec2.nix
deployment.ec2.region

Amazon EC2 region in which the instance is to be deployed. This option only applies when using EC2. It implicitly sets deployment.ec2.controller and deployment.ec2.ami.

Default: ""

Example: "us-east-1"

Declared by:

/nix/store/bdqc6a697zls0wdpi5319qdlj10r3sx5-git-export/nix/ec2.nix
deployment.ec2.securityGroups

Security groups for the instance. These determine the firewall rules applied to the instance.

Default: [ "default" ]

Example: [ "my-group" "my-other-group" ]

Declared by:

/nix/store/bdqc6a697zls0wdpi5319qdlj10r3sx5-git-export/nix/ec2.nix
deployment.ec2.spotInstancePrice

Price (in dollar cents per hour) to use for spot instances request for the machine. If the value is equal to 0 (default), then spot instances are not used.

Default: 0

Declared by:

/nix/store/bdqc6a697zls0wdpi5319qdlj10r3sx5-git-export/nix/ec2.nix
deployment.ec2.tags

EC2 tags assigned to the instance. Each tag name can be at most 128 characters, and each tag value can be at most 256 characters. There can be at most 10 tags.

Default: { }

Example: { foo = "bar"; xyzzy = "bla"; }

Declared by:

/nix/store/bdqc6a697zls0wdpi5319qdlj10r3sx5-git-export/nix/ec2.nix
deployment.ec2.type

Specifies the type of cloud. This affects the machine configuration. Current values are "ec2" and "nova".

Default: "ec2"

Example: "nova"

Declared by:

/nix/store/bdqc6a697zls0wdpi5319qdlj10r3sx5-git-export/nix/ec2.nix
deployment.ec2.zone

The EC2 availability zone in which the instance should be created. If not specified, a zone is selected automatically.

Default: ""

Example: "us-east-1c"

Declared by:

/nix/store/bdqc6a697zls0wdpi5319qdlj10r3sx5-git-export/nix/ec2.nix
deployment.encryptedLinksTo

NixOps will set up an encrypted tunnel (via SSH) to the machines listed here. Since this is a two-way (peer to peer) connection, it is not necessary to set this option on both endpoints. NixOps will set up /etc/hosts so that the host names of the machines listed here resolve to the IP addresses of the tunnels. It will also add the alias machine-encrypted for each machine.

Default: [ ]

Declared by:

/nix/store/bdqc6a697zls0wdpi5319qdlj10r3sx5-git-export/nix/options.nix
deployment.hetzner.mainIPv4

Main IP address identifying the server.

Default: null

Example: "78.46.1.93"

Declared by:

/nix/store/bdqc6a697zls0wdpi5319qdlj10r3sx5-git-export/nix/hetzner.nix
deployment.hetzner.partitions

Specify layout of partitions and file systems using Anacondas Kickstart format. For possible options and commands, please have a look at: http://fedoraproject.org/wiki/Anaconda/Kickstart

Default:

''
clearpart --all --initlabel --drives=sda,sdb

part swap1 --recommended --label=swap1 --fstype=swap --ondisk=sda
part swap2 --recommended --label=swap2 --fstype=swap --ondisk=sdb

part raid.1 --grow --ondisk=sda
part raid.2 --grow --ondisk=sdb

raid / --level=1 --device=md0 --fstype=ext4 --label=root raid.1 raid.2
''

Example:

''
# Example for partitioning on a vServer:
clearpart --all --initlabel --drives=vda
part swap --recommended --label=swap --fstype=swap --ondisk=vda
part / --fstype=ext4 --label=root --grow --ondisk=vda
''

Declared by:

/nix/store/bdqc6a697zls0wdpi5319qdlj10r3sx5-git-export/nix/hetzner.nix
deployment.hetzner.robotPass

Password of the Hetzner robot account. If left empty, the value of the environment variable HETZNER_ROBOT_PASS is used instead.

Default: ""

Declared by:

/nix/store/bdqc6a697zls0wdpi5319qdlj10r3sx5-git-export/nix/hetzner.nix
deployment.hetzner.robotUser

Username of the Hetzner robot account. If left empty, the value of the environment variable HETZNER_ROBOT_USER is used instead.

Default: ""

Declared by:

/nix/store/bdqc6a697zls0wdpi5319qdlj10r3sx5-git-export/nix/hetzner.nix
deployment.keys

The set of keys to be deployed to the machine. Each attribute maps a key name to a file that can be accessed as /run/keys/name. Thus, { password.text = "foobar"; } causes a file /run/keys/password to be created with contents foobar. The directory /run/keys is only accessible to root and the keys group. So keep in mind to add any users that need to have access to a particular key to this group.

Default: { }

Example: { password = { text = "foobar"; } ; }

Declared by:

/nix/store/bdqc6a697zls0wdpi5319qdlj10r3sx5-git-export/nix/keys.nix
deployment.keys.<name>.group

The group that will be set for the key file.

Default: "root"

deployment.keys.<name>.permissions

The default permissions to set for the key file, needs to be in the format accepted by chmod(1).

Default: "0600"

Example: "0640"

deployment.keys.<name>.text

The text the key should contain. So if the key name is password and foobar is set here, the contents of the file /run/keys/password will be foobar.

Example: "super secret stuff"

deployment.keys.<name>.user

The user which will be the owner of the key file.

Default: "root"

deployment.owners

List of email addresses of the owners of the machines. Used to send email on performing certain actions.

Default: [ ]

Declared by:

/nix/store/bdqc6a697zls0wdpi5319qdlj10r3sx5-git-export/nix/options.nix
deployment.route53.accessKeyId

The AWS Access Key ID. If left empty, it defaults to the contents of the environment variables EC2_ACCESS_KEY or AWS_ACCESS_KEY_ID (in that order). The corresponding Secret Access Key is not specified in the deployment model, but looked up in the file ~/.ec2-keys, which should specify, on each line, an Access Key ID followed by the corresponding Secret Access Key. If it does not appear in that file, the environment variables environment variables EC2_SECRET_KEY or AWS_SECRET_ACCESS_KEY are used.

Default: ""

Example: "AKIAIEMEJZVMPOHZWKZQ"

Declared by:

/nix/store/bdqc6a697zls0wdpi5319qdlj10r3sx5-git-export/nix/route53.nix
deployment.route53.hostName

The DNS hostname to bind the public IP address to.

Default: ""

Example: "test.x.logicblox.com"

Declared by:

/nix/store/bdqc6a697zls0wdpi5319qdlj10r3sx5-git-export/nix/route53.nix
deployment.route53.ttl

The time to live (TTL) for the A record created for the specified DNS hostname.

Default: 300

Example: 300

Declared by:

/nix/store/bdqc6a697zls0wdpi5319qdlj10r3sx5-git-export/nix/route53.nix
deployment.storeKeysOnMachine

If true, secret information such as LUKS encryption keys or SSL private keys is stored on the root disk of the machine, allowing the machine to do unattended reboots. If false, secrets are not stored; NixOps supplies them to the machine at mount time. This means that a reboot will not complete entirely until you run nixops deploy or nixops send-keys.

Default: false

Declared by:

/nix/store/bdqc6a697zls0wdpi5319qdlj10r3sx5-git-export/nix/keys.nix
deployment.targetEnv

This option specifies the type of the environment in which the machine is to be deployed by NixOps. Currently, it can have the following values. "none" means deploying to a pre-existing physical or virtual NixOS machine, reachable via SSH under the hostname or IP address specified in deployment.targetHost. "ec2" means that a virtual machine should be instantiated in an Amazon EC2-compatible cloud environment (see deployment.ec2.*). "virtualbox" causes a VirtualBox VM to be created on your machine. (This requires VirtualBox to be configured on your system.)

Default: "none"

Example: "ec2"

Declared by:

/nix/store/bdqc6a697zls0wdpi5319qdlj10r3sx5-git-export/nix/options.nix
deployment.targetHost

This option specifies the hostname or IP address to be used by NixOps to execute remote deployment operations.

Declared by:

/nix/store/bdqc6a697zls0wdpi5319qdlj10r3sx5-git-export/nix/options.nix
deployment.targetPort

This option specifies the SSH port to be used by NixOps to execute remote deployment operations.

Declared by:

/nix/store/bdqc6a697zls0wdpi5319qdlj10r3sx5-git-export/nix/options.nix
deployment.virtualbox.disks

Definition of the virtual disks attached to this instance.

Default: { }

Example: { big-disk = { port = 1; size = 1048576; } ; }

Declared by:

/nix/store/bdqc6a697zls0wdpi5319qdlj10r3sx5-git-export/nix/virtualbox.nix
deployment.virtualbox.disks.<name>.baseImage

If set, this disk is created as a clone of the specified disk image (and the size attribute is ignored).

Default: null

Example: "/home/alice/base-disk.vdi"

deployment.virtualbox.disks.<name>.port

SATA port number to which the disk is attached.

Example: 1

deployment.virtualbox.disks.<name>.size

Size (in megabytes) of this disk.

deployment.virtualbox.headless

If set, the VirtualBox instance is started in headless mode, i.e., without a visible display on the host's desktop.

Default: false

Declared by:

/nix/store/bdqc6a697zls0wdpi5319qdlj10r3sx5-git-export/nix/virtualbox.nix
deployment.virtualbox.memorySize

Memory size (M) of virtual machine.

Default: 512

Declared by:

/nix/store/bdqc6a697zls0wdpi5319qdlj10r3sx5-git-export/nix/virtualbox.nix
deployment.virtualbox.sharedFolders

Definition of the host folders that should be shared with this instance.

Default: { }

Example: { home = { hostPath = "/home"; readOnly = false; } ; }

Declared by:

/nix/store/bdqc6a697zls0wdpi5319qdlj10r3sx5-git-export/nix/virtualbox.nix
deployment.virtualbox.sharedFolders.<name>.hostPath

The path of the host directory that should be shared to the guest

Example: "/home"

deployment.virtualbox.sharedFolders.<name>.readOnly

Specifies if the shared folder should be read-only for the guest

Default: true

fileSystems

NixOps extends NixOS' fileSystem option to allow convenient attaching of EC2 volumes.

Declared by:

/nix/store/bdqc6a697zls0wdpi5319qdlj10r3sx5-git-export/nix/ec2.nix
/nix/store/bdqc6a697zls0wdpi5319qdlj10r3sx5-git-export/doc/manual/dummy.nix
fileSystems.*.ec2

EC2 disk to be attached to this mount point. This is shorthand for defining a separate deployment.ec2.blockDeviceMapping attribute.

Default: null

fileSystems.*.ec2.cipher

The cipher used to encrypt the disk.

Default: "aes-cbc-essiv:sha256"

fileSystems.*.ec2.deleteOnTermination

For automatically created EBS volumes, determines whether the volume should be deleted on instance termination.

fileSystems.*.ec2.disk

EC2 identifier of the disk to be mounted. This can be an ephemeral disk (e.g. ephemeral0), a snapshot ID (e.g. snap-1cbda474) or a volume ID (e.g. vol-d04895b8). Leave empty to create an EBS volume automatically. It can also be an EBS resource (e.g. resources.ebsVolumes.big-disk).

Default: ""

Example: "vol-d04895b8"

fileSystems.*.ec2.encrypt

Whether the EBS volume should be encrypted using LUKS.

Default: false

fileSystems.*.ec2.fsType

Filesystem type for automatically created EBS volumes.

Default: "ext4"

fileSystems.*.ec2.iops

The provisioned IOPs you want to associate with this EBS volume.

Default: 0

fileSystems.*.ec2.keySize

The size of the encryption key.

Default: 128

fileSystems.*.ec2.passphrase

The passphrase (key file) used to decrypt the key to access the device. If left empty, a passphrase is generated automatically; this passphrase is lost when you destroy the machine or remove the volume, unless you copy it from NixOps's state file. Note that the passphrase is stored in the Nix store of the instance, so an attacker who gains access to the EBS volume or instance store that contains the Nix store can subsequently decrypt the encrypted volume.

Default: ""

fileSystems.*.ec2.size

Volume size (in gigabytes) for automatically created EBS volumes.

Default: 0

fileSystems.*.ec2.volumeType

The volume type for the EBS volume. (standard/io1/gp2)

Default: "standard"

networking.p2pTunnels.ssh

A set of peer-to-peer tunnels set up automatically over SSH.

Default: { }

Example: { tunnel1 = { localIPv4 = "172.16.12.1"; localTunnel = 0; privateKey = "/root/.ssh/id_vpn"; remoteIPv4 = "172.16.12.2"; remoteTunnel = 1; target = "192.0.2.1"; } ; }

Declared by:

/nix/store/bdqc6a697zls0wdpi5319qdlj10r3sx5-git-export/nix/ssh-tunnel.nix
networking.p2pTunnels.ssh.<name>.localIPv4

IPv4 address of the local endpoint of the tunnel.

networking.p2pTunnels.ssh.<name>.localTunnel

Local tunnel device number.

networking.p2pTunnels.ssh.<name>.privateKey

Path to the private key file used to connect to the remote machine.

networking.p2pTunnels.ssh.<name>.remoteIPv4

IPv4 address of the remote endpoint of the tunnel.

networking.p2pTunnels.ssh.<name>.remoteTunnel

Remote tunnel device number.

networking.p2pTunnels.ssh.<name>.target

Host name or IP address of the remote machine.

networking.privateIPv4

IPv4 address of this machine within in the logical network. This address can be used by other machines in the logical network to reach this machine. However, it need not be visible to the outside (i.e., publicly routable).

Example: "10.1.2.3"

Declared by:

/nix/store/bdqc6a697zls0wdpi5319qdlj10r3sx5-git-export/nix/options.nix
networking.publicIPv4

Publicly routable IPv4 address of this machine.

Example: "198.51.100.123"

Declared by:

/nix/store/bdqc6a697zls0wdpi5319qdlj10r3sx5-git-export/nix/options.nix

B.2. SQS Queues

An Amazon SQS queue is defined by setting resources.sqsQueues.name to an attribute set containing values for the following options.

accessKeyId

The AWS Access Key ID.

Declared by:

/nix/store/bdqc6a697zls0wdpi5319qdlj10r3sx5-git-export/nix/sqs-queue.nix
arn

Amazon Resource Name (ARN) of the queue. This is set by NixOps.

Default: ""

Declared by:

/nix/store/bdqc6a697zls0wdpi5319qdlj10r3sx5-git-export/nix/sqs-queue.nix
name

Name of the SQS queue.

Default: "charon-<uuid>-<name>"

Declared by:

/nix/store/bdqc6a697zls0wdpi5319qdlj10r3sx5-git-export/nix/sqs-queue.nix
region

Amazon EC2 region.

Declared by:

/nix/store/bdqc6a697zls0wdpi5319qdlj10r3sx5-git-export/nix/sqs-queue.nix
url

URL of the queue. This is set by NixOps.

Default: ""

Declared by:

/nix/store/bdqc6a697zls0wdpi5319qdlj10r3sx5-git-export/nix/sqs-queue.nix
visibilityTimeout

The time interval in seconds after a message has been received until it becomes visible again.

Default: 30

Declared by:

/nix/store/bdqc6a697zls0wdpi5319qdlj10r3sx5-git-export/nix/sqs-queue.nix

B.3. EC2 Keypairs

An Amazon EC2 keypair is defined by setting resources.ec2KeyPairs.name to an attribute set containing values for the following options.

B.4. S3 Buckets

An Amazon S3 bucket is defined by setting resources.s3Buckets.name to an attribute set containing values for the following options.

accessKeyId

The AWS Access Key ID.

Declared by:

/nix/store/bdqc6a697zls0wdpi5319qdlj10r3sx5-git-export/nix/s3-bucket.nix
arn

Amazon Resource Name (ARN) of the S3 bucket. This is set by NixOps.

Default: "arn:aws:s3:::charon-<uuid>-<name>"

Declared by:

/nix/store/bdqc6a697zls0wdpi5319qdlj10r3sx5-git-export/nix/s3-bucket.nix
name

Name of the S3 bucket.

Default: "charon-<uuid>-<name>"

Declared by:

/nix/store/bdqc6a697zls0wdpi5319qdlj10r3sx5-git-export/nix/s3-bucket.nix
region

Amazon S3 region.

Declared by:

/nix/store/bdqc6a697zls0wdpi5319qdlj10r3sx5-git-export/nix/s3-bucket.nix

B.5. IAM Roles

An Amazon IAM role is defined by setting resources.iamRoles.name to an attribute set containing values for the following options.

B.6. SSH Keypairs

An SSH keypair is defined by setting resources.sshKeyPairs.name to an empty attribute set. You can access the generated keypair by using the following options.

Appendix C. Hacking

This section provides some notes on how to hack on NixOps. To get the latest version of NixOps from GitHub:

$ git clone git://github.com/NixOS/nixops.git
$ cd nixops

To build it and its dependencies:

$ nix-build release.nix -A build.x86_64-linux

The resulting NixOps can be run as ./result/bin/nixops.

To build all dependencies and start a shell in which all environment variables (such as PYTHONPATH) are set up so that those dependencies can be found:

$ nix-shell release.nix -A build.x86_64-linux --exclude tarball
$ echo $PYTHONPATH
/nix/store/yzj6p5f7iyh247pwxrg97y3klm6d0cni-python-2.7.3/lib/python2.7/site-packages:...

You can then run NixOps in your source tree as follows:

$ nixops

To run the tests, do

$ python tests.py

Note that some of the tests involve the creation of EC2 resources and thus cost money. You must set the environment variable EC2_ACCESS_KEY and (optionally) EC2_SECRET_KEY. (If the latter is not set, it will be looked up in ~/.ec2-keys, as described in the section called “Deploying to Amazon EC2”.) To run a specific test, run python tests.py test-name, e.g.

$ python tests.py tests.functional.test_encrypted_links

There are also a few NixOS VM tests. These can be run as follows:

$ nix-build release.nix -A tests.none_backend

Appendix D. Release Notes

D.1. Release 1.2 (April 30, 2014)

  • General

    • NixOps now requires NixOS 13.10 and up.

    • Add --all option to nixops destroy, nixops delete and nixops ssh-for-each.

    • The -d option now matches based on prefix for convenience when the specified uuid/id is not found.

    • Resources can now be accessed via direct reference, i.e. you can use securityGroups = [ resources.ec2SecurityGroups.foo ]; in stead of securityGroups = [ resources.ec2SecurityGroups.foo.name ];.

    • Changed default value of deployment.storeKeysOnMachine to false, which is the more secure option. This can prevent unattended reboot from finishing, as keys will need to be pushed to the machine.

  • Amazon EC2

    • Support provisioning of elastic IP addresses.

    • Support provisioning of EC2 security groups.

    • Support all HVM instance types.

    • Support ap-southeast-1 region.

    • Better handling of errors in pushing Route53 records.

    • Support using ARN's for applying instance profiles to EC2 instances. This allows cross-account API access.

    • Base HVM image was updated to allow using all emphemeral devices.

    • Instance ID is now available in nix through the deployment.ec2.instanceId option, set by nixops.

    • Support independent provisioning of EBS volumes. Previously, EBS volumes could only be created as part of an EC2 instance, meaning their lifetime was tied to the instance and they could not be managed separately. Now they can be provisioned independently, e.g.:

            resources.ebsVolumes.bigdata =
              { name = "My Big Fat Data";
                region = "eu-west-1";
                zone = "eu-west-1a";
                accessKeyId = "...";
                size = 1000;
              };
            

    • To allow cross-account API access, the deployment.ec2.instanceProfile option can now be set to either a name (previous behaviour) or an Amazon Resource Names (ARN) of the instance profile you want to apply.

  • Hetzner

    • Always hard reset on destroying machine.

    • Support for Hetzner vServers.

    • Disabled root password by default.

    • Fix hard reset for rebooting to rescue mode.. This is particularly useful if you have a dead server and want to put it in rescue mode. Now it's possible to do that simply by running:

            nixops reboot --hard --rescue --include=deadmachine
            

  • VirtualBox

    • Require VirtualBox >= 4.3.0.

    • Support for shared folders in VirtualBox. You can mount host folder on the guest by setting the deployment.virtualbox.sharedFolders option.

    • Allow destroy if the VM is gone already

This release has contributions from aszlig, Corey O'Connor, Domen Kožar, Eelco Dolstra, Michael Stone, Oliver Charles, Rickard Nilsson, Rob Vermaas, Shea Levy and Vladimir Kirillov.

D.2. Release 1.1.1 (October 2, 2013)

This a minor bugfix release.

  • Added a command-line option --include-keys to allow importing SSH public host keys, of the machines that will be imported, to the .ssh/known_hosts of the user.

  • Fixed a bug that prevented switching the deployment.storeKeysOnMachine option value.

  • On non-EC2 systems, nixops will generate ecdsa SSH host keypairs in stead of dsa from now on.

  • VirtualBox deployments use generated SSH host keypairs.

  • For all machines which nixops generates an SSH host keypair for, it will add the SSH public host key to the known_hosts configuration of all machines in the network.

  • For EC2 deployments, if the nixops expression specifies a set of security groups for a machine that is different from the security groups applied to the existing machine, it will produce a warning that the change cannot be made.

  • For EC2 deployments, disks that are not supposed to be attached to the machine are detached only after system activation has been completed. Previously this was done before, but that could lead to volumes not being able to detach without needing to stop the machine.

  • Added a command-line option --repair as a convient way to pass this option, which allows repairing of broken or changed paths in the nix store, to nix-build calls that nixops performs. Note that this option only works in nix setups that run without the nix daemon.

This release has contributions from aszlig, Ricardo Correia, Eelco Dolstra, Rob Vermaas.

D.3. Release 1.1 (September 9, 2013)

  • Backend for Hetzner, a German data center provider. More information and a demo video can be found here.

  • When using the deployment.keys.* options, the keys in /run/keys are now created with mode 600.

  • Fixed bug where EBS snapshots name tag was overridden by the instance name tag.

  • The nixops executable now has the default OpenSSH from nixpkgs in its PATH now by default, to work around issues with left-over SSH master connections on older version of OpenSSH, such as the version that is installed by default on CentOS.

  • A new resource type has been introduced to generate sets of SSH public/private keys.

  • Support for spot instances in the EC2 backend. By specifying the deployment.ec2.spotInstancePrice option for a machine, you can set the spot instance price in cents. NixOps will wait 10 minutes for a spot instance to be fulfilled, if not, then it will error out for that machine.

D.4. Release 1.0.1 (July 11, 2013)

This is a minor bugfix release.

  • Reduce parallelism for running EC2 backups, to prevent hammering the AWS API in case of many disks.

  • Propagate the instance tags to the EBS volumes (except for Name tag, which is overriden with a detailed description of the volume and its use).

D.5. Release 1.0 (June 18, 2013)

Initial release.