NixOps User's Guide

Eelco Dolstra

LogicBlox

Rob Vermaas

LogicBlox

Table of Contents

1. Introduction
2. Installation
3. Overview
3.1. Deploying a VirtualBox VM
3.2. Deploying multiple machines
3.3. Deploying to Amazon EC2
3.4. Deploying to Google Compute Engine
3.5. Deploying to Hetzner physical machines
3.6. Accessing machines
3.7. Checking machine status
3.8. Network arguments
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
B.7. GCE Disks
B.8. GCE Images
B.9. GCE Forwarding Rules
B.10. GCE HTTP Health Checks
B.11. GCE Networks
B.12. GCE Static IPs
B.13. GCE Target Pools
B.14. GSE Buckets
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
3.6. load-balancer-gce.nix: GCE 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.

3.1. 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. Note that for this to work the vboxnet0 network has to exist - you can add it in the VirtualBox general settings under Networks - Host-only Networks if necessary.

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:

$ nixops destroy -d trivial
warning: are you sure you want to destroy VirtualBox VM ‘webserver’? (y/N) y
webserver> destroying VirtualBox VM...
webserver> 0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%

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

3.2. 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;
}

3.3. 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.

3.4. Deploying to Google Compute Engine

Example 3.6 shows a physical specification that deploys the load balancer network to Google Compute Engine(GCE). It states that the three machines need to be instantiated in GCE region europe-west1-b, based on the unstable branch of NixOS. It also specifies an alternative load balancer implemented using GCE Forwarding Rule.

Example 3.6. load-balancer-gce.nix: GCE physical network specification

let

  # change this as necessary or wipe and use ENV vars
  credentials = {
    project = "myproject";
    serviceAccount = "000000000000-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx@developer.gserviceaccount.com";
    accessKey = "/path/to/user/key.pem";
  };

  gce = { resources, ...}:  {
    networking.firewall.allowedTCPPorts = [ 80 ];
    deployment.targetEnv = "gce";
    deployment.gce = credentials // {
      region = "europe-west1-b";
      tags = [ "public-http" ];
      network = resources.gceNetworks.lb-net;
    };
  };

in {

  # use nixos-unstable image
  # this specification is identical to the default one and can omitted
  resources.gceImages.bootstrap = credentials // {
    sourceUri = "gs://nixos/nixos-14.10pre-git-x86_64-linux.raw.tar.gz";
  };

  # create a network that allows SSH traffic(by default), pings
  # and HTTP traffic for machines tagged "public-http"
  resources.gceNetworks.lb-net = credentials // {
    addressRange = "192.168.4.0/24";
    firewall = {
      allow-http = {
        targetTags = [ "public-http" ];
        allowed.tcp = [ 80 ];
      };
      allow-ping.allowed.icmp = null;
    };
  };

  # by default, health check pings port 80, so we don't have to set anything
  resources.gceHTTPHealthChecks.plain-hc = credentials;

  resources.gceTargetPools.backends = { resources, nodes, ...}: credentials // {
    region = "europe-west1";
    healthCheck = resources.gceHTTPHealthChecks.plain-hc;
    machines = with nodes; [ backend1 backend2 ];
  };

  resources.gceForwardingRules.lb = { resources, ...}: credentials // {
    protocol = "TCP";
    region = "europe-west1";
    portRange = "80";
    targetPool = resources.gceTargetPools.backends;
    description = "Alternative HTTP Load Balancer";
  };

  proxy    = gce;
  backend1 = gce;
  backend2 = gce;

}

Deployment is as follows:

$ nixops create ./load-balancer.nix ./load-balancer-gce.nix -d load-balancer-gce
$ nixops deploy -d load-balancer-gce
bootstrap> creating GCE image 'n-588718b8099211e49d39b8e8560f8b58-bootstrap'...
lb-net..> Creating GCE network 'nixops-588718b8-0992-11e4-9d39-b8e8560f8b58-lb-net'...
plain-hc> creating GCE HTTP health check 'nixops-588718b8-0992-11e4-9d39-b8e8560f8b58-plain-hc'...
backends> creating GCE target pool 'nixops-588718b8-0992-11e4-9d39-b8e8560f8b58-backends'...
lb-net..> Creating GCE firewall 'nixops-588718b8-0992-11e4-9d39-b8e8560f8b58-lb-net-allow-ssh'...
lb-net..> Creating GCE firewall 'nixops-588718b8-0992-11e4-9d39-b8e8560f8b58-lb-net-allow-ping'...
backends> updating the machine list of GCE target pool 'nixops-588718b8-0992-11e4-9d39-b8e8560f8b58-backends'...
lb-net..> Creating GCE firewall 'nixops-588718b8-0992-11e4-9d39-b8e8560f8b58-lb-net-allow-http'...
proxy....> Creating GCE disk of auto GiB from image 'n-588718b8099211e49d39b8e8560f8b58-bootstrap'...
backend1.> Creating GCE disk of auto GiB from image 'n-588718b8099211e49d39b8e8560f8b58-bootstrap'...
backend2.> Creating GCE disk of auto GiB from image 'n-588718b8099211e49d39b8e8560f8b58-bootstrap'...
lb......> creating GCE forwarding rule 'nixops-588718b8-0992-11e4-9d39-b8e8560f8b58-lb'...done.
lb......> got IP: 146.148.16.5
backend2> creating GCE machine 'nixops-588718b8-0992-11e4-9d39-b8e8560f8b58-backend2'...
proxy...> creating GCE machine 'nixops-588718b8-0992-11e4-9d39-b8e8560f8b58-proxy'...
backend1> creating GCE machine 'nixops-588718b8-0992-11e4-9d39-b8e8560f8b58-backend1'...
backend1> got IP: 130.211.95.195
backend2> got IP: 146.148.2.203
proxy...> got IP: 146.148.20.120
backend1> attaching GCE disk 'nixops-588718b8-0992-11e4-9d39-b8e8560f8b58-backend1-root'...
backend1> waiting for SSH....
backend2> attaching GCE disk 'nixops-588718b8-0992-11e4-9d39-b8e8560f8b58-backend2-root'...
backend2> waiting for SSH...
backend1> .
proxy...> attaching GCE disk 'nixops-588718b8-0992-11e4-9d39-b8e8560f8b58-proxy-root'...
...
proxy......> activation finished successfully
backend2...> activation finished successfully
backend1...> activation finished successfully

Here NixOps has created a GCE network, a health check, a load balancer, a bootstrap image based on the unstable branch of NixOS, 3 root disks for the instances and started three instances running the default NixOS image. Other than that, deployment is the same as for VirtualBox: NixOps builds the machine configurations, copies their closure over to the GCE instances, and activates the new configurations.

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

$ nixops info -d load-balancer-gce
...
+-----------+-----------------+------------------------------------+----------------------------------------------+----------------+
| Name      |      Status     | Type                               | Resource Id                                  | IP address     |
+-----------+-----------------+------------------------------------+----------------------------------------------+----------------+
| backend1  | Up / Up-to-date | gce [europe-west1-b; g1-small]     | n-588718b8099211e49d39b8e8560f8b58-backend1  | 146.148.20.120 |
| backend2  | Up / Up-to-date | gce [europe-west1-b; g1-small]     | n-588718b8099211e49d39b8e8560f8b58-backend2  | 146.148.31.67  |
| proxy     | Up / Up-to-date | gce [europe-west1-b; g1-small]     | n-588718b8099211e49d39b8e8560f8b58-proxy     | 146.148.2.203  |
| lb        | Up / Up-to-date | gce-forwarding-rule [europe-west1] | n-588718b8099211e49d39b8e8560f8b58-lb        | 130.211.66.82  |
| plain-hc  | Up / Up-to-date | gce-http-health-check [:80/]       | n-588718b8099211e49d39b8e8560f8b58-plain-hc  |                |
| bootstrap | Up / Up-to-date | gce-image                          | n-588718b8099211e49d39b8e8560f8b58-bootstrap |                |
| lb-net    | Up / Up-to-date | gce-network [192.168.4.0/24]       | n-588718b8099211e49d39b8e8560f8b58-lb-net    |                |
| backends  | Up / Up-to-date | gce-target-pool [europe-west1]     | n-588718b8099211e49d39b8e8560f8b58-backends  |                |
+-----------+-----------------+------------------------------------+----------------------------------------------+----------------+

The resources can be destroyed by running:

$ nixops destroy -d load-balancer-gce

This terminates the GCE instances and deletes the alternative GCE-based load balancer.

Deployment to GCE has some prerequisites.

  • Obviously, you need an GCE service account which you can create from the Developer Console.

  • Once you've created a new GCE service account and downloaded the generated private key (in the PKCS12 format), you'll need to convert the key to PEM format by running the following command:

    $ openssl pkcs12 -in pkey.pkcs12 -passin pass:notasecret -nodes -nocerts | openssl rsa -out pkey.pem
    

  • All GCE resources and instances must belong to a GCE project which you can create from the Developer Console. Alternatively, you could use a project you already have. Several deployments can coexist in a single project and with manually-created resources, as long as you don't exceed the quotas.

  • You must ensure that the GCE service account you've created has sufficient permissions to manage resources in the project.

  • You must supply the credentials(project, service account name and path to the key) via either *.project, *.serviceAccount and *.accessKey options or GCE_PROJECT, GCE_SERVICE_ACCOUNT and ACCESS_KEY_PATH environment variables. Options take precedence over environment variables and are per-resource/-instance.

  • You need to ensure that GCE firewall is configured correctly. The default GCE network which is created for each project and to which all instances belong by default, only allows SSH and internal traffic. Usually, this is not enough and you want to create a network managed by NixOps with custom firewall settings. By default, the NixOps-managed networks allow SSH traffic because it is absolutely required to manage the instances. In addition to allowing traffic based on IP and port ranges, firewall can also selectively enable traffic for instances with specific tags, such as public-http in the example, which is assigned to the instances you want to receive connections on port 80.

  • Many resources are region- and zone-specific, and thus you need to set *.region options where applicable.

GCE limitations and quirks to be aware of.

  • A bootstrap image needs to be created for each deployment because it is impossible to create public images. Default bootstrap image specification can be overriden by defining resources.gceImages.bootstrap. Additionally, the instance's bootstrapImage option can be used to specify an instance-specific bootstrap image.

  • There's no "native" support for starting and stopping instances. NixOps emulates starting and stoping by creating and tearing down GCE instances, but preserving the disk contents.

    While this mostly just works, GCE ends up charging you a minimum of uptime (which was 10 minutes at the moment of writing this manual) thus too frequent start/stop cycling ends up expensive.

    Start/stop cycling of an instance which uses an ephemeral IP address often causes the IP address to change, which breaks certain features such as encrypted tunnels until repaired by deploy.

    Another important difference is that NixOps attempts to replicate the last known state of the instance(attached disks, tags). Thus, if the state was modified manually(eg via gcloud tool), such changes are lost in a start/stop cycle.

    Consider rebooting instead which doesn't have these limitation and, in addition, is faster.

  • Creation, modification and deletion of resources and instances are not idempotent in GCE.

    In practice, this means that if you hit Ctrl+C or an error happens, while NixOps is creating, destrying or otherwise changing the state a resource, the state of the resource expected by NixOps and the actual state may diverge.

    Usually, this doesn't cause too much troubles, but a good practice is to follow each failed or aborted deployment operation with a deploy --check run to detect and fix any state mismatch(es).

  • The instances which are members of target pools need a constantly-running configure-forwarding-rules service, which is enabled by default, and is not otherwise required. Substantial RAM savings for a large deployment can be obtained by disabling the service if it isn't needed.

Migration of resources between zones and putting previosly-existing resources under NixOps control.

  • Disks can be migrated by making a snapshot and then initializing a new NixOps-managed disk from it, possibly, in another zone or region.

  • Migrating an instance to another zone via backup functionality is currently impossible. It is still possible to create a new instance and migrate each disk by hand using snapshots.

  • Putting a manually-created static IP resource under NixOps management is done this way: create a resource to temporarily hold the IP address, such as an instance or a forwarding rule; delete the static IP resource, which still leaves the IP address itself under your control thanks to the holding resource; create a new static IP address with resources.gceStaticIPs.$NAME.ipAddress set to the IP address of the holding resource; delete the holding resource after checking that the static IP resource has been correctly created and holds the original IP address. You must practice the migration procedure on a test static IP resource.

    If by accident or after ignoring the above advice, you lose control of a valuable IP address, you must act very fast and attempt to create a new static IP resource with with resources.gceStaticIPs.$NAME.ipAddress set to the IP address itself that you want to regain control over. If you are late and the IP address has been given to someone else, it still makes sense to repeately try reserving the address because most likely it is in use as an emphemeral one and thus will become available soon. Needless to say, you want to avoid a situation like this at all costs.

    IP addresses are region-specific and thus most likely can't be migrated to another region. It is impossible to migrate an IP address to another project without temporarily losing control over it.

3.5. 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.

3.6. 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.

3.7. 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.

3.8. 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.

GCE_PROJECT

GCE Project which should own the resources in the Google Compute Engine deployment. Used if deployment.gce.project is not set in a GCE machine configuration and if resources.$TYPE.$NAME.project is not set in a GCE resource specification.

GCE_SERVICE_ACCOUNT, ACCESS_KEY_PATH

GCE Service Account ID and the path to the corresponding private key in .pem format which should be used to manage the Google Compute Engine deployment. Used if deployment.gce.serviceAccount and deployment.gce.accessKey are not set in a GCE machine configuration and if resources.$TYPE.$NAME.serviceAccount and resources.$TYPE.$NAME.accessKey are not set in a GCE resource specification.

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/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-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/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-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

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/auto-luks.nix
deployment.autoLuks.<name>.cipher

The cipher used to encrypt the volume.

Default: "aes-cbc-essiv:sha256"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/auto-luks.nix
deployment.autoLuks.<name>.device

The underlying (encrypted) device.

Example: "/dev/xvdg"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/auto-luks.nix
deployment.autoLuks.<name>.keySize

The size in bits of the encryption key.

Default: 128

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/auto-luks.nix
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: ""

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/auto-luks.nix
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/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-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" ]

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/auto-raid0.nix
deployment.container.host

The NixOS machine on which this container is to be instantiated.

Default: "localhost"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/container.nix
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/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-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/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/ec2.nix
deployment.ec2.associatePublicIpAddress

If instance in a subnet/VPC, whether to associate a public IP address with the instance.

Default: false

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-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/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/ec2.nix
deployment.ec2.blockDeviceMapping.<name>.cipher

The cipher used to encrypt the disk.

Default: "aes-cbc-essiv:sha256"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/ec2.nix
deployment.ec2.blockDeviceMapping.<name>.deleteOnTermination

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

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/ec2.nix
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"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/ec2.nix
deployment.ec2.blockDeviceMapping.<name>.encrypt

Whether the EBS volume should be encrypted using LUKS.

Default: false

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/ec2.nix
deployment.ec2.blockDeviceMapping.<name>.encryptionType

Whether the EBS volume should be encrypted using LUKS or on the underlying EBS volume (Amazon EBS feature). Possible values are "luks" (default) and "ebs".

Default: "luks"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/ec2.nix
deployment.ec2.blockDeviceMapping.<name>.fsType

Filesystem type for automatically created EBS volumes.

Default: "ext4"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/ec2.nix
deployment.ec2.blockDeviceMapping.<name>.iops

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

Default: 0

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/ec2.nix
deployment.ec2.blockDeviceMapping.<name>.keySize

The size of the encryption key.

Default: 128

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/ec2.nix
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: ""

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/ec2.nix
deployment.ec2.blockDeviceMapping.<name>.size

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

Default: 0

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/ec2.nix
deployment.ec2.blockDeviceMapping.<name>.volumeType

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

Default: "standard"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-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/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-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/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-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/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-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/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/ec2.nix
deployment.ec2.instanceId

EC2 instance id (set by nixops).

Default: ""

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-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/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-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/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-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/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-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/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/ec2.nix
deployment.ec2.placementGroup

Placement group for the instance.

Default: ""

Example: "my-cluster"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-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/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-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.ami.

Default: ""

Example: "us-east-1"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/ec2.nix
deployment.ec2.securityGroupIds

Security Group IDs for the instance. Necessary if starting an instance inside a VPC/subnet. In the non-default VPC, security groups needs to be specified by ID and not name.

Default: [ ]

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-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/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-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/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/ec2.nix
deployment.ec2.subnetId

The subnet inside a VPC to launch the instance in.

Default: ""

Example: "subnet-9d4a7b6c"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-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/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-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/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-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/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/options.nix
deployment.gce.accessKey

The path to GCE Service Account key. If left empty, it defaults to the contents of the environment variable ACCESS_KEY_PATH.

Default: ""

Example: "/path/to/secret/key.pem"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce.nix
deployment.gce.blockDeviceMapping

Block device mapping.

Default: { }

Example: { /dev/sda = { image = "bootstrap-img"; } ; /dev/sdb = { disk = "vol-d04895b8"; } ; }

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce.nix
deployment.gce.blockDeviceMapping.<name>.bootDisk

Should the instance boot from this disk.

Default: false

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce.nix
deployment.gce.blockDeviceMapping.<name>.cipher

The cipher used to encrypt the disk.

Default: "aes-cbc-essiv:sha256"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce.nix
deployment.gce.blockDeviceMapping.<name>.deleteOnTermination

For automatically created GCE disks, determines whether the disk should be deleted on instance destruction.

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce.nix
deployment.gce.blockDeviceMapping.<name>.disk

GCE Disk resource or name of a disk not managed by NixOps to be mounted.

Default: null

Example: "resources.gceDisks.exampleDisk"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce.nix
deployment.gce.blockDeviceMapping.<name>.diskType

The disk storage type (standard/ssd).

Default: "standard"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce.nix
deployment.gce.blockDeviceMapping.<name>.disk_name

Name of the GCE disk to create.

Default: null

Example: "machine-persistent-disk2"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce.nix
deployment.gce.blockDeviceMapping.<name>.encrypt

Whether the GCE disk should be encrypted using LUKS.

Default: false

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce.nix
deployment.gce.blockDeviceMapping.<name>.image

The image name or resource from which to create the GCE disk. If not specified, an empty disk is created. Changing the image name has no effect if the disk already exists.

Default: null

Example: "image-432"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce.nix
deployment.gce.blockDeviceMapping.<name>.keySize

The size of the encryption key.

Default: 128

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce.nix
deployment.gce.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 GCE disk or instance store that contains the Nix store can subsequently decrypt the encrypted volume.

Default: ""

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce.nix
deployment.gce.blockDeviceMapping.<name>.readOnly

Should the disk be attached to the instance as read-only.

Default: false

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce.nix
deployment.gce.blockDeviceMapping.<name>.size

Volume size (in gigabytes) for automatically created GCE disks. This may be left unset if you are creating the disk from a snapshot or image, in which case the size of the disk will be equal to the size of the snapshot or image. You can set a size larger than the snapshot or image, allowing the disk to be larger than the snapshot from which it is created.

Default: null

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce.nix
deployment.gce.blockDeviceMapping.<name>.snapshot

The snapshot name from which to create the GCE disk. If not specified, an empty disk is created. Changing the snapshot name has no effect if the disk already exists.

Default: null

Example: "snapshot-432"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce.nix
deployment.gce.bootstrapImage

Bootstrap image name or resource to use to create the root disk of the instance.

Default: { }

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce.nix
deployment.gce.instanceType

GCE instance type. See https://developers.google.com/compute/pricing for a list of valid instance types.

Default: "g1-small"

Example: "n1-standard-1"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce.nix
deployment.gce.ipAddress

GCE Static IP address resource to bind to or the name of an IP address not managed by NixOps.

Default: null

Example: "resources.gceStaticIPs.exampleIP"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce.nix
deployment.gce.machineName

The GCE Instance Name.

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

Example: "custom-machine-name"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce.nix
deployment.gce.metadata

Metadata to assign to the instance. These are available to the instance via the metadata server. Some metadata keys such as "startup-script" are reserved by GCE and can influence the instance.

Default: { }

Example: { loglevel = "warn"; }

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce.nix
deployment.gce.network

The GCE Network to make the instance a part of. Can be either a gceNetworks resource or a name of a network not managed by NixOps.

Default: null

Example: "resources.gceNetworks.verySecureNetwork"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce.nix
deployment.gce.project

The GCE project which should own the instance. If left empty, it defaults to the contents of the environment variable GCE_PROJECT.

Default: ""

Example: "myproject"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce.nix
deployment.gce.region

The GCE datacenter in which the instance should be created.

Example: "europe-west1-b"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce.nix
deployment.gce.rootDiskSize

Root disk size(in gigabytes). Leave unset to be the same as bootstrapImage size.

Default: null

Example: 200

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce.nix
deployment.gce.rootDiskType

The root disk storage type (standard/ssd).

Default: "standard"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce.nix
deployment.gce.scheduling.automaticRestart

Whether the Instance should be automatically restarted when it is terminated by Google Compute Engine (not terminated by user).

Default: true

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce.nix
deployment.gce.scheduling.onHostMaintenance

Defines the maintenance behavior for this instance. For more information, see https://developers.google.com/compute/docs/instances#onhostmaintenance. Allowed values are: "MIGRATE" to let GCE automatically migrate your instances out of the way of maintenance events and "TERMINATE" to allow GCE to terminate and restart the instance.

Default: "MIGRATE"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce.nix
deployment.gce.serviceAccount

The GCE Service Account Email. If left empty, it defaults to the contents of the environment variable GCE_SERVICE_ACCOUNT.

Default: ""

Example: "12345-asdf@developer.gserviceaccount.com"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce.nix
deployment.gce.tags

Tags to assign to the instance. These can be used in firewall and networking rules and are additionally available as metadata.

Default: [ ]

Example: [ "random" "tags" ]

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce.nix
deployment.hetzner.mainIPv4

Main IP address identifying the server.

Default: null

Example: "78.46.1.93"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-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/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-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/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-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/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-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/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-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/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-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/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-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/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-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/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/route53.nix
deployment.route53.usePublicDNSName

Whether to create a CNAME record with the instance's public DNS name. This will resolve inside AWS to a private IP and outside AWS to the public IP.

Default: false

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-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/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-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/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-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/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-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/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-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/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-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"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/virtualbox.nix
deployment.virtualbox.disks.<name>.port

SATA port number to which the disk is attached.

Example: 1

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/virtualbox.nix
deployment.virtualbox.disks.<name>.size

Size (in megabytes) of this disk.

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/virtualbox.nix
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/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/virtualbox.nix
deployment.virtualbox.memorySize

Memory size (M) of virtual machine.

Default: 512

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-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/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-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"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/virtualbox.nix
deployment.virtualbox.sharedFolders.<name>.readOnly

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

Default: true

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/virtualbox.nix
fileSystems

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

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce.nix
/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/ec2.nix
/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-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

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/ec2.nix
fileSystems.*.ec2.cipher

The cipher used to encrypt the disk.

Default: "aes-cbc-essiv:sha256"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/ec2.nix
fileSystems.*.ec2.deleteOnTermination

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

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/ec2.nix
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"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/ec2.nix
fileSystems.*.ec2.encrypt

Whether the EBS volume should be encrypted using LUKS.

Default: false

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/ec2.nix
fileSystems.*.ec2.encryptionType

Whether the EBS volume should be encrypted using LUKS or on the underlying EBS volume (Amazon EBS feature). Possible values are "luks" (default) and "ebs".

Default: "luks"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/ec2.nix
fileSystems.*.ec2.fsType

Filesystem type for automatically created EBS volumes.

Default: "ext4"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/ec2.nix
fileSystems.*.ec2.iops

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

Default: 0

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/ec2.nix
fileSystems.*.ec2.keySize

The size of the encryption key.

Default: 128

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/ec2.nix
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: ""

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/ec2.nix
fileSystems.*.ec2.size

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

Default: 0

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/ec2.nix
fileSystems.*.ec2.volumeType

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

Default: "standard"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/ec2.nix
fileSystems.*.gce

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

Default: null

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce.nix
fileSystems.*.gce.bootDisk

Should the instance boot from this disk.

Default: false

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce.nix
fileSystems.*.gce.cipher

The cipher used to encrypt the disk.

Default: "aes-cbc-essiv:sha256"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce.nix
fileSystems.*.gce.deleteOnTermination

For automatically created GCE disks, determines whether the disk should be deleted on instance destruction.

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce.nix
fileSystems.*.gce.disk

GCE Disk resource or name of a disk not managed by NixOps to be mounted.

Default: null

Example: "resources.gceDisks.exampleDisk"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce.nix
fileSystems.*.gce.diskType

The disk storage type (standard/ssd).

Default: "standard"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce.nix
fileSystems.*.gce.disk_name

Name of the GCE disk to create.

Default: null

Example: "machine-persistent-disk2"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce.nix
fileSystems.*.gce.encrypt

Whether the GCE disk should be encrypted using LUKS.

Default: false

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce.nix
fileSystems.*.gce.image

The image name or resource from which to create the GCE disk. If not specified, an empty disk is created. Changing the image name has no effect if the disk already exists.

Default: null

Example: "image-432"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce.nix
fileSystems.*.gce.keySize

The size of the encryption key.

Default: 128

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce.nix
fileSystems.*.gce.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 GCE disk or instance store that contains the Nix store can subsequently decrypt the encrypted volume.

Default: ""

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce.nix
fileSystems.*.gce.readOnly

Should the disk be attached to the instance as read-only.

Default: false

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce.nix
fileSystems.*.gce.size

Volume size (in gigabytes) for automatically created GCE disks. This may be left unset if you are creating the disk from a snapshot or image, in which case the size of the disk will be equal to the size of the snapshot or image. You can set a size larger than the snapshot or image, allowing the disk to be larger than the snapshot from which it is created.

Default: null

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce.nix
fileSystems.*.gce.snapshot

The snapshot name from which to create the GCE disk. If not specified, an empty disk is created. Changing the snapshot name has no effect if the disk already exists.

Default: null

Example: "snapshot-432"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce.nix
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/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/ssh-tunnel.nix
networking.p2pTunnels.ssh.<name>.localIPv4

IPv4 address of the local endpoint of the tunnel.

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/ssh-tunnel.nix
networking.p2pTunnels.ssh.<name>.localTunnel

Local tunnel device number.

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/ssh-tunnel.nix
networking.p2pTunnels.ssh.<name>.privateKey

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

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/ssh-tunnel.nix
networking.p2pTunnels.ssh.<name>.remoteIPv4

IPv4 address of the remote endpoint of the tunnel.

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/ssh-tunnel.nix
networking.p2pTunnels.ssh.<name>.remoteTunnel

Remote tunnel device number.

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/ssh-tunnel.nix
networking.p2pTunnels.ssh.<name>.target

Host name or IP address of the remote machine.

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/ssh-tunnel.nix
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/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/options.nix
networking.publicIPv4

Publicly routable IPv4 address of this machine.

Example: "198.51.100.123"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-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/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/sqs-queue.nix
arn

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

Default: ""

Declared by:

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

Name of the SQS queue.

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

Declared by:

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

Amazon EC2 region.

Declared by:

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

URL of the queue. This is set by NixOps.

Default: ""

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-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/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-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/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-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/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/s3-bucket.nix
name

Name of the S3 bucket.

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

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/s3-bucket.nix
policy

The JSON Policy string to apply to the bucket.

Default: ""

Declared by:

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

Amazon S3 region.

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-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.

B.7. GCE Disks

A GCE Disk is defined by setting resources.gceDisks.name to an attribute set containing values for the following options.

accessKey

The path to GCE Service Account key. If left empty, it defaults to the contents of the environment variable ACCESS_KEY_PATH.

Default: ""

Example: "/path/to/secret/key.pem"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce-disk.nix
diskType

The disk storage type (standard/ssd).

Default: "standard"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce-disk.nix
image

The image name or resource from which this disk will be created. If not specified, an empty disk is created. Changing the image name has no effect if the disk already exists.

Default: null

Example: "image-2cfda297"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce-disk.nix
name

Description of the GCE disk. This is the Name tag of the disk.

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

Example: "big-fat-disk"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce-disk.nix
project

The GCE project which should own the disk. If left empty, it defaults to the contents of the environment variable GCE_PROJECT.

Default: ""

Example: "myproject"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce-disk.nix
region

The GCE datacenter in which the disk should be created.

Example: "europe-west1-b"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce-disk.nix
serviceAccount

The GCE Service Account Email. If left empty, it defaults to the contents of the environment variable GCE_SERVICE_ACCOUNT.

Default: ""

Example: "12345-asdf@developer.gserviceaccount.com"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce-disk.nix
size

Disk size (in gigabytes). This may be left unset if you are creating the disk from a snapshot or image, in which case the size of the disk will be equal to the size of the snapshot or image. You can set a size larger than the snapshot or image, allowing the disk to be larger than the snapshot from which it is created.

Default: null

Example: 100

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce-disk.nix
snapshot

The snapshot name from which this disk will be created. If not specified, an empty disk is created. Changing the snapshot name has no effect if the disk already exists.

Default: null

Example: "snap-1cbda474"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce-disk.nix

B.8. GCE Images

A GCE Image is defined by setting resources.gceImages.name to an attribute set containing values for the following options.

accessKey

The path to GCE Service Account key. If left empty, it defaults to the contents of the environment variable ACCESS_KEY_PATH.

Default: ""

Example: "/path/to/secret/key.pem"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce-image.nix
description

An optional textual description of the image.

Default: null

Example: "bootstrap image for the DB node"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce-image.nix
name

Description of the GCE image. This is the Name tag of the image.

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

Example: "my-bootstrap-image"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce-image.nix
project

The GCE project which should own the image. If left empty, it defaults to the contents of the environment variable GCE_PROJECT.

Default: ""

Example: "myproject"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce-image.nix
serviceAccount

The GCE Service Account Email. If left empty, it defaults to the contents of the environment variable GCE_SERVICE_ACCOUNT.

Default: ""

Example: "12345-asdf@developer.gserviceaccount.com"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce-image.nix
sourceUri

The full Google Cloud Storage URL where the disk image is stored.

Example: "gs://nixos/nixos-14.10pre-git-x86_64-linux.raw.tar.gz"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce-image.nix

B.9. GCE Forwarding Rules

A GCE Forwarding Rule is defined by setting resources.gceForwardingRules.name to an attribute set containing values for the following options.

accessKey

The path to GCE Service Account key. If left empty, it defaults to the contents of the environment variable ACCESS_KEY_PATH.

Default: ""

Example: "/path/to/secret/key.pem"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce-forwarding-rule.nix
description

An optional textual description of the Fowarding Rule.

Default: null

Example: "load balancer for the public site"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce-forwarding-rule.nix
ipAddress

GCE Static IP address resource to bind to or the name of an IP address not managed by NixOps. If left unset, an ephemeral(random) IP address will be assigned on deployment.

Default: null

Example: "resources.gceStaticIPs.exampleIP"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce-forwarding-rule.nix
name

Description of the GCE Forwarding Rule. This is the Name tag of the rule.

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

Example: "my-public-ip"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce-forwarding-rule.nix
portRange

If protocol is TCP or UDP, packets addressed to ports in the specified range will be forwarded to the target. Leave unset to forward all ports.

Default: null

Example: "1-1000"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce-forwarding-rule.nix
project

The GCE project which should own the forwarding rule. If left empty, it defaults to the contents of the environment variable GCE_PROJECT.

Default: ""

Example: "myproject"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce-forwarding-rule.nix
protocol

The IP protocol to which this rule applies. Acceptable values are: "AH": Specifies the IP Authentication Header protocol. "ESP": Specifies the IP Encapsulating Security Payload protocol. "SCTP": Specifies the Stream Control Transmission Protocol. "TCP": Specifies the Transmission Control Protocol. "UDP": Specifies the User Datagram Protocol.

Example: "TCP"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce-forwarding-rule.nix
region

The GCE region to which the forwarding rule should belong.

Example: "europe-west1"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce-forwarding-rule.nix
serviceAccount

The GCE Service Account Email. If left empty, it defaults to the contents of the environment variable GCE_SERVICE_ACCOUNT.

Default: ""

Example: "12345-asdf@developer.gserviceaccount.com"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce-forwarding-rule.nix
targetPool

GCE Target Pool resource to receive the matched traffic or the name of a target pool not managed by NixOps.

Example: "resources.gceStaticIPs.exampleIP"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce-forwarding-rule.nix

B.10. GCE HTTP Health Checks

A GCE HTTP Health Check is defined by setting resources.gceHTTPHealthChecks.name to an attribute set containing values for the following options.

accessKey

The path to GCE Service Account key. If left empty, it defaults to the contents of the environment variable ACCESS_KEY_PATH.

Default: ""

Example: "/path/to/secret/key.pem"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce-http-health-check.nix
checkInterval

How often (in seconds) to send a health check.

Default: 5

Example: 20

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce-http-health-check.nix
description

An optional textual description of the HTTP Health Check.

Default: null

Example: "health check for databases"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce-http-health-check.nix
healthyThreshold

An unhealthy VM will be marked healthy after this many consecutive successes.

Default: 2

Example: 4

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce-http-health-check.nix
host

The value of the host header in the HTTP health check request. If left unset(default value), the public IP on behalf of which this health check is performed will be used.

Default: null

Example: "healthcheckhost.org"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce-http-health-check.nix
name

Description of the GCE HTTP Health Check. This is the Name tag of the health check.

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

Example: "my-health-check"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce-http-health-check.nix
path

The request path of the HTTP health check request.

Default: "/"

Example: "/is_healthy"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce-http-health-check.nix
port

The TCP port number for the HTTP health check request.

Default: 80

Example: 8080

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce-http-health-check.nix
project

The GCE project which should own the HTTP health check. If left empty, it defaults to the contents of the environment variable GCE_PROJECT.

Default: ""

Example: "myproject"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce-http-health-check.nix
serviceAccount

The GCE Service Account Email. If left empty, it defaults to the contents of the environment variable GCE_SERVICE_ACCOUNT.

Default: ""

Example: "12345-asdf@developer.gserviceaccount.com"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce-http-health-check.nix
timeout

How long (in seconds) to wait before claiming failure.

Default: 5

Example: 20

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce-http-health-check.nix
unhealthyThreshold

A so-far healthy VM will be marked unhealthy after this many consecutive failures.

Default: 2

Example: 4

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce-http-health-check.nix

B.11. GCE Networks

A GCE Network is defined by setting resources.gceNetworks.name to an attribute set containing values for the following options.

accessKey

The path to GCE Service Account key. If left empty, it defaults to the contents of the environment variable ACCESS_KEY_PATH.

Default: ""

Example: "/path/to/secret/key.pem"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce-network.nix
addressRange

The range of internal addresses that are legal on this network. This range is a CIDR specification.

Example: "192.168.0.0/16"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce-network.nix
firewall

Firewall rules.

Default: { allow-ssh = { allowed = { tcp = [ 22 ] ; } ; } ; }

Example: { allow-http = { allowed = { tcp = [ 80 ] ; } ; sourceRanges = [ "0.0.0.0/0" ] ; } ; }

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce-network.nix
firewall.<name>.allowed

Allowed protocols and ports. Setting protocol to null for example "icmp = null" allows all connections made using the protocol to proceed.";

Example: { icmp = null; tcp = [ 80 ] ; }

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce-network.nix
firewall.<name>.sourceRanges

The address blocks that this rule applies to, expressed in CIDR format. An inbound connection is allowed if either the range or the tag of the source matches the sourceRanges or sourceTags. As a convenience, leaving this option unset is equivalent to setting it to [ "0.0.0.0/0" ].

Default: null

Example: [ "192.168.0.0/16" ]

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce-network.nix
firewall.<name>.sourceTags

A list of instance tags which this rule applies to. Can be set in addition to sourceRanges. An inbound connection is allowed if either the range or the tag of the source matches the sourceRanges or sourceTags. Don't forget to set sourceRanges to [] or at least a more restrictive range because the default setting makes sourceTags irrelevant.

Default: [ ]

Example: [ "admin" ]

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce-network.nix
firewall.<name>.targetTags

A list of instance tags indicating sets of instances located on the network which may make network connections as specified in allowed. If no targetTags are specified, the firewall rule applies to all instances on the network.

Default: [ ]

Example: [ "public-http" ]

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce-network.nix
name

Description of the GCE Network. This is the Name tag of the network.

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

Example: "my-custom-network"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce-network.nix
project

The GCE project which should own the network. If left empty, it defaults to the contents of the environment variable GCE_PROJECT.

Default: ""

Example: "myproject"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce-network.nix
serviceAccount

The GCE Service Account Email. If left empty, it defaults to the contents of the environment variable GCE_SERVICE_ACCOUNT.

Default: ""

Example: "12345-asdf@developer.gserviceaccount.com"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce-network.nix

B.12. GCE Static IPs

A GCE Static IP is defined by setting resources.gceStaticIPs.name to an attribute set containing values for the following options.

accessKey

The path to GCE Service Account key. If left empty, it defaults to the contents of the environment variable ACCESS_KEY_PATH.

Default: ""

Example: "/path/to/secret/key.pem"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce-static-ip.nix
ipAddress

The specific ephemeral IP address to promote to a static one. This lets you permanently reserve an ephemeral address used by one of resources to preserve it across machine teardowns or reassign it to another resource. Changing value of, setting or unsetting this option has no effect once the address resource is deployed, thus you can't lose the static IP unless you explicitly destroy it.

Default: null

Example: "123.123.123.123"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce-static-ip.nix
name

Description of the GCE static IP address. This is the Name tag of the address.

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

Example: "my-public-ip"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce-static-ip.nix
project

The GCE project which should own the IP address. If left empty, it defaults to the contents of the environment variable GCE_PROJECT.

Default: ""

Example: "myproject"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce-static-ip.nix
region

The GCE region to which the IP address should be bound.

Example: "europe-west1"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce-static-ip.nix
serviceAccount

The GCE Service Account Email. If left empty, it defaults to the contents of the environment variable GCE_SERVICE_ACCOUNT.

Default: ""

Example: "12345-asdf@developer.gserviceaccount.com"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce-static-ip.nix

B.13. GCE Target Pools

A GCE Target Pool is defined by setting resources.gceTargetPools.name to an attribute set containing values for the following options.

accessKey

The path to GCE Service Account key. If left empty, it defaults to the contents of the environment variable ACCESS_KEY_PATH.

Default: ""

Example: "/path/to/secret/key.pem"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce-target-pool.nix
healthCheck

GCE HTTP Health Check resource or name of a HTTP Health Check resource not managed by NixOps. A member VM in this pool is considered healthy if and only if the specified health checks passes. Unset health check means all member virtual machines will be considered healthy at all times but the health status of this target pool will be marked as unhealthy to indicate that no health checks are being performed.

Default: null

Example: "resources.gceHTTPHealthChecks.my-check"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce-target-pool.nix
machines

The list of machine resources or fully-qualified GCE Node URLs to add to this pool.

Default: [ ]

Example: [ "machines.httpserver1" "machines.httpserver2" ]

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce-target-pool.nix
name

Description of the GCE Target Pool. This is the Name tag of the target pool.

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

Example: "my-target-pool"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce-target-pool.nix
project

The GCE project which should own the target pool. If left empty, it defaults to the contents of the environment variable GCE_PROJECT.

Default: ""

Example: "myproject"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce-target-pool.nix
region

The GCE region to where the GCE Target Pool instances should reside.

Example: "europe-west1"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce-target-pool.nix
serviceAccount

The GCE Service Account Email. If left empty, it defaults to the contents of the environment variable GCE_SERVICE_ACCOUNT.

Default: ""

Example: "12345-asdf@developer.gserviceaccount.com"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gce-target-pool.nix

B.14. GSE Buckets

A GSE Bucket is defined by setting resources.gseBuckets.name to an attribute set containing values for the following options.

accessKey

The path to GCE Service Account key. If left empty, it defaults to the contents of the environment variable ACCESS_KEY_PATH.

Default: ""

Example: "/path/to/secret/key.pem"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gse-bucket.nix
cors

Cross-Origin Resource Sharing configuration.

Default: [ ]

Example: [ { maxAgeSeconds = 100; methods = [ "GET" "PUT" ] ; origins = [ "http://site.com" "http://site.org" ] ; responseHeaders = [ "header1" "header2" ] ; } ]

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gse-bucket.nix
cors.*.maxAgeSeconds

The value, in seconds, to return in the Access-Control-Max-Age header used in preflight responses.

Default: 3600

Example: 360

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gse-bucket.nix
cors.*.methods

The list of HTTP methods on which to include CORS response headers, (GET, OPTIONS, POST, etc). Note: "*" is permitted in the list, and means "any method".

Default: [ ]

Example: [ "GET" "POST" ]

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gse-bucket.nix
cors.*.origins

The list of Origins eligible to receive CORS response headers. Note: "*" is permitted in the list, and means "any Origin".

Default: [ ]

Example: [ "http://example.org" ]

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gse-bucket.nix
cors.*.responseHeaders

The list of HTTP headers other than the simple response headers to give permission for the user-agent to share across domains.

Default: [ ]

Example: [ "FIXME" ]

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gse-bucket.nix
lifecycle

Object Lifecycle Configuration for the bucket contents.

Default: [ ]

Example: [ { conditions = { age = 40; } ; } ]

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gse-bucket.nix
lifecycle.*.action

The action to perform when all conditions are met. Currently only "Delete" is supported by GCE.

Default: "Delete"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gse-bucket.nix
lifecycle.*.conditions.age

This condition is satisfied when an object reaches the specified age (in days).

Default: null

Example: 365

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gse-bucket.nix
lifecycle.*.conditions.createdBefore

This condition is satisfied when an object is created before midnight of the specified date in UTC.

Default: null

Example: "2013-01-10"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gse-bucket.nix
lifecycle.*.conditions.isLive

Relevant only for versioned objects. If the value is true, this condition matches the live objects; if the value is false, it matches archived objects.

Default: null

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gse-bucket.nix
lifecycle.*.conditions.numberOfNewerVersions

Relevant only for versioned objects. If the value is N, this condition is satisfied when there are at least N versions (including the live version) newer than this version of the object. For live objects, the number of newer versions is considered to be 0. For the most recent archived version, the number of newer versions is 1 (or 0 if there is no live object), and so on.

Default: null

Example: 3

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gse-bucket.nix
location

Object data for objects in the bucket resides in physical storage within this region. Defaults to US. See the developer's guide for the authoritative list.

Default: "US"

Example: "EU"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gse-bucket.nix
logging.logBucket

The destination bucket where the current bucket's logs should be placed. FIXME: is this a bucket name or a fully-qualified url?

Default: null

Example: "resources.gseBuckets.logBucket"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gse-bucket.nix
logging.logObjectPrefix

A prefix for log object names.

Default: null

Example: "log"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gse-bucket.nix
name

This is the Name tag of the bucket.

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

Example: "my-bucket"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gse-bucket.nix
project

The GCE project which should own the bucket. If left empty, it defaults to the contents of the environment variable GCE_PROJECT.

Default: ""

Example: "myproject"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gse-bucket.nix
serviceAccount

The GCE Service Account Email. If left empty, it defaults to the contents of the environment variable GCE_SERVICE_ACCOUNT.

Default: ""

Example: "12345-asdf@developer.gserviceaccount.com"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gse-bucket.nix
storageClass

This defines how objects in the bucket are stored and determines the SLA and the cost of storage. Typical values are STANDARD and DURABLE_REDUCED_AVAILABILITY. See the developer's guide for the authoritative list.

Default: "STANDARD"

Example: "DURABLE_REDUCED_AVAILABILITY"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gse-bucket.nix
versioning.enabled

While set to true, versioning is fully enabled for this bucket.

Default: false

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gse-bucket.nix
website.mainPageSuffix

Behaves as the bucket's directory index where missing objects are treated as potential directories. For example, with mainPageSuffix main_page_suffix configured to be index.html, a GET request for http://example.com would retrieve http://example.com/index.html, and a GET request for http://example.com/photos would retrieve http://example.com/photos/index.html.

Default: null

Example: "index.html"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gse-bucket.nix
website.notFoundPage

Serve this object on request for a non-existent object.

Default: null

Example: "404.html"

Declared by:

/nix/store/i53dcj7fi6zcmp5dfj89kfywz6k52y3z-git-export/nix/gse-bucket.nix

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 Section 3.3.) 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.