Table of Contents
List of Examples
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.
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:
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.
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
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.
This chapter gives a quick overview of how to use NixOps.
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"; }; }
This specification consists of a set of top-level attributes
describing logical machines (namely webserver
) and
meta-information (namely network.description
).
Each attribute not named network
describes a
logical machine. The value of each logical machine attribute is a
NixOS configuration module, which describes the
desired configuration of the corresponding machine. Thus, the logical
machine webserver
should have the Apache
httpd web server running, and its document root
(rather arbitrarily for demonstration purposes) should be the
documentation of the Valgrind package.
To deploy this machine, we also need to provide configuration
options that tell NixOps to what environment it should be deployed.
Example 3.2 specifies that
webserver
should be deployed as a VirtualBox
instance.
Example 3.2. trivial-vbox.nix
: VirtualBox physical network specification
{ webserver = { config, pkgs, ... }: { deployment.targetEnv = "virtualbox"; deployment.virtualbox.memorySize = 1024; # megabytes }; }
Before we can deploy the network we need to use the command nixops create to create a NixOps deployment that contains any state associated with the deployment (such as information about instantiated VMs). At creation time, we need to specify the Nix expressions that constitute the complete deployment specification. So to create a deployment for deploying the Apache web server to VirtualBox, we would do:
$ nixops create ./trivial.nix ./trivial-vbox.nix -d trivial 33bced96-5f26-11e1-b9d7-9630d48abec1
Here -d trivial
gives the symbolic name
trivial
to the deployment. Deployments can be
identified in two ways: using the UUID printed by nixops
create, or using the symbolic name you specified at creation
time.
You can print a list of existing deployments using nixops list:
+--------------------------------------+-----------+--------------+------------+------------+ | UUID | Name | Description | # Machines | Type | +--------------------------------------+-----------+--------------+------------+------------+ | 33bced96-5f26-11e1-b9d7-9630d48abec1 | trivial | Web server | 0 | | +--------------------------------------+-----------+--------------+------------+------------+
The command nixops info shows the current deployment state:
$ nixops info -d trivial Network UUID: 33bced96-5f26-11e1-b9d7-9630d48abec1 Network description: Web server +-----------+--------+------------+-------------+------------+ | Name | Status | Type | Resource Id | IP address | +-----------+--------+------------+-------------+------------+ | webserver | New | virtualbox | | | +-----------+--------+------------+-------------+------------+
The machine status New
indicates that the logical
machine webserver
hasn’t been created yet. The
-d
option specifies which deployment to use; you can
use the symbolic name (-d trivial
) or the UUID
(-d 33bced96-5f26-11e1-b9d7-9630d48abec1
). You
can also set the the environment variable
NIXOPS_DEPLOYMENT
.
The actual deployment is done by running nixops deploy:
$ nixops deploy -d trivial creating VirtualBox VM ‘webserver’... Virtual machine 'nixops-33bced96-5f26-11e1-b9d7-9630d48abec1-webserver' is created and registered. Clone hard disk created in format 'VDI'. UUID: 5a0b0771-7e03-4fab-9c2f-e95888b57db3 Waiting for VM "nixops-33bced96-5f26-11e1-b9d7-9630d48abec1-webserver" to power on... VM "nixops-33bced96-5f26-11e1-b9d7-9630d48abec1-webserver" has been successfully started. waiting for IP address of ‘webserver’........................... 192.168.56.101 waiting for SSH on ‘webserver’... building all machine configurations... building path(s) `/nix/store/ybrny9h744q8i3x026ccfmdav8qnw7pd-nixos-version' building path(s) `/nix/store/zxw279xhl6l8yl94gnka8aqv1kkcrrd4-os-release' fetching path `/nix/store/pn43d3llpsm3pc1ywaxccmw8pmzjqgz0-valgrind-3.7.0'... … copying closure to machine ‘webserver’... copying 376 missing paths to ‘root@192.168.56.101’... importing path `/nix/store/jfcs9xnfbmiwqs224sb0qqsybbfl3sab-linux-headers-2.6.35.14' … activating new configuration on machine ‘webserver’... updating GRUB 2 menu... activating the configuration... … starting new service ‘httpd’...
NixOps performs the following steps to do the deployment:
It creates missing machines. In this case, a
VirtualBox instance for the logical machine
webserver
is started. NixOps then waits to
obtain its IP address.
It builds the NixOS machine configurations locally. For instance, here Valgrind is built or downloaded because our machine configuration has a dependency on it.
It copies the closure of each machine configuration to the corresponding machine.
It activates the configuration on each machine. For
instance, it starts the httpd
systemd service on
the webserver
machine. This is the only step
that has a visible effect; all prior steps do not affect the active
configuration of the machines.
The nixops info command will show that a machine was created:
$ nixops info -d trivial Network UUID: 33bced96-5f26-11e1-b9d7-9630d48abec1 Network description: Web server +-----------+--------+------------+-----------------------------------------------------+----------------+ | Name | Status | Type | Resource Id | IP address | +-----------+--------+------------+-----------------------------------------------------+----------------+ | webserver | Up | virtualbox | nixops-33bced96-5f26-11e1-b9d7-9630d48abec1-machine | 192.168.56.101 | +-----------+--------+------------+-----------------------------------------------------+----------------+
Visit http://192.168.56.101
in a web browser
should now show the Valgrind documentation. You can also log in to
the virtual machine as root
:
$ nixops ssh -d trivial webserver connecting to 192.168.56.101... [root@webserver:~]#
The command nixops ssh is a convenience wrapper around ssh that passes the right IP address and SSH identity for the specified logical machine. (NixOps automatically creates a unique SSH key pair for communicating with each VirtualBox instance.)
Redeployment after making a change to the specification is
simply a matter of running nixops deploy again. If
we do this for the example, NixOps will notice that the
webserver
machine already exists and that most or
all dependencies are already present, so it won’t create a new
VirtualBox instance or need to build and copy a lot of dependencies.
Thus redeployment typically only takes a few seconds:
$ time nixops deploy -d trivial building all machine configurations... copying closure to machine ‘webserver’... activating new configuration on machine ‘webserver’... real 0m3.700s
If you want to get rid of the virtual machines created by NixOps, you can run nixops destroy:
warning: are you sure you want to destroy EC2 machine ‘webserver’? (y/N) y $ nixops destroy -d trivial destroying VirtualBox VM ‘webserver’...
You can use the option --confirm
to confirm all
questions. This is useful for automated deployment, but potentially
dangerous.
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; }
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.name; }; 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.
We have seen above that you can login to individual machines by
doing nixops ssh
,
where name
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.
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.
Table of Contents
nixops — deploy a set of NixOS machines
nixops
{ --version
| --help
| command
[arguments
...] } [
{ --state
| -s
}
statefile
] [
{ --deployment
| -d
}
uuid-or-name
] [--confirm
] [--debug
]
--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.
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
.
~/.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.
nixops create
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.
-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
or the environment
variable
name
NIXOPS_DEPLOYMENT=
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.name
nixops modify
nixops clone
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.
nixops delete
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.
nixops deploy
nixops deploy
[ --kill-obsolete
| -k
] [--dry-run
] [--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
]
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.
--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.
--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.
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
nixops destroy
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).
nixops stop
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).
nixops start
nixops list
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.
$ 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 | | +--------------------------------------+------------------------+------------------------+------------+------------+
nixops info
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.)
--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).
$ 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 | +----------+-----------------+------------------------------+------------+-----------------+
nixops check
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.
nixops ssh
nixops ssh-for-each
nixops ssh-for-each
[ --parallel
| -p
] [
--include
machine-name
...
] [
--exclude
machine-name
...
] [
command
[args
...]
]
nixops reboot
nixops reboot
[
--include
machine-name
...
] [
--exclude
machine-name
...
] [ --no-wait
] [
command
[args
...]
]
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.
nixops backup
This command makes a backup of all persistent disks of all machines. Currently this is only implemented for EC2 EBS instances/volumes.
nixops restore
nixops restore
[
--include
machine-name
...
] [
--exclude
machine-name
...
] [
--backup-id
backup-id
...
]
--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-id
backup-id
Restore the persistent disks of all machines to a given backup except the ones listed here.
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
nixops show-option
nixops set-args
--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.
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
nixops show-console-output
nixops export
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.
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
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.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/hfdgq4q3ijcchcdhdrllf5962qb9xb08-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/hfdgq4q3ijcchcdhdrllf5962qb9xb08-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/hfdgq4q3ijcchcdhdrllf5962qb9xb08-git-export/nix/auto-luks.nix |
deployment.autoLuks.<name>.device
The underlying (encrypted) device.
Default: none
Example:
"/dev/xvdg"
Declared by:
/nix/store/hfdgq4q3ijcchcdhdrllf5962qb9xb08-git-export/nix/auto-luks.nix |
deployment.autoLuks.<name>.keySize
The size in bits of the encryption key.
Default:
128
Declared by:
/nix/store/hfdgq4q3ijcchcdhdrllf5962qb9xb08-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/hfdgq4q3ijcchcdhdrllf5962qb9xb08-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/hfdgq4q3ijcchcdhdrllf5962qb9xb08-git-export/nix/auto-raid0.nix |
deployment.autoRaid0.<name>.devices
The underlying devices to be combined into a RAID-0 volume.
Default: none
Example:
[
"/dev/xvdg" "/dev/xvdh"
]
Declared by:
/nix/store/hfdgq4q3ijcchcdhdrllf5962qb9xb08-git-export/nix/auto-raid0.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/hfdgq4q3ijcchcdhdrllf5962qb9xb08-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.
Default: none
Example:
"ami-ecb49e98"
Declared by:
/nix/store/hfdgq4q3ijcchcdhdrllf5962qb9xb08-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/hfdgq4q3ijcchcdhdrllf5962qb9xb08-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/hfdgq4q3ijcchcdhdrllf5962qb9xb08-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.
Default: none
Declared by:
/nix/store/hfdgq4q3ijcchcdhdrllf5962qb9xb08-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.
Default:
""
Example:
"vol-d04895b8"
Declared by:
/nix/store/hfdgq4q3ijcchcdhdrllf5962qb9xb08-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/hfdgq4q3ijcchcdhdrllf5962qb9xb08-git-export/nix/ec2.nix |
deployment.ec2.blockDeviceMapping.<name>.fsType
Filesystem type for automatically created EBS volumes.
Default:
"ext4"
Declared by:
/nix/store/hfdgq4q3ijcchcdhdrllf5962qb9xb08-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/hfdgq4q3ijcchcdhdrllf5962qb9xb08-git-export/nix/ec2.nix |
deployment.ec2.blockDeviceMapping.<name>.keySize
The size of the encryption key.
Default:
128
Declared by:
/nix/store/hfdgq4q3ijcchcdhdrllf5962qb9xb08-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/hfdgq4q3ijcchcdhdrllf5962qb9xb08-git-export/nix/ec2.nix |
deployment.ec2.blockDeviceMapping.<name>.size
Filesystem size (in gigabytes) for automatically created EBS volumes.
Default:
0
Declared by:
/nix/store/hfdgq4q3ijcchcdhdrllf5962qb9xb08-git-export/nix/ec2.nix |
deployment.ec2.controller
URI of an Amazon EC2-compatible cloud controller web service,
used to create and manage virtual machines. If you're using
EC2, it's more convenient to set
deployment.ec2.region
.
Default: none
Example:
"https://ec2.eu-west-1.amazonaws.com/"
Declared by:
/nix/store/hfdgq4q3ijcchcdhdrllf5962qb9xb08-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/hfdgq4q3ijcchcdhdrllf5962qb9xb08-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/hfdgq4q3ijcchcdhdrllf5962qb9xb08-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/hfdgq4q3ijcchcdhdrllf5962qb9xb08-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/hfdgq4q3ijcchcdhdrllf5962qb9xb08-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/hfdgq4q3ijcchcdhdrllf5962qb9xb08-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.
Default: none
Example:
"my-keypair"
Declared by:
/nix/store/hfdgq4q3ijcchcdhdrllf5962qb9xb08-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/hfdgq4q3ijcchcdhdrllf5962qb9xb08-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/hfdgq4q3ijcchcdhdrllf5962qb9xb08-git-export/nix/ec2.nix |
deployment.ec2.region
Amazon EC2 region in which the instance is to be deployed.
This option only applies when using EC2. It implicitly sets
deployment.ec2.controller
and
deployment.ec2.ami
.
Default:
""
Example:
"us-east-1"
Declared by:
/nix/store/hfdgq4q3ijcchcdhdrllf5962qb9xb08-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/hfdgq4q3ijcchcdhdrllf5962qb9xb08-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/hfdgq4q3ijcchcdhdrllf5962qb9xb08-git-export/nix/ec2.nix |
deployment.ec2.type
Specifies the type of cloud. This affects the machine
configuration. Current values are "ec2"
and "nova"
.
Default:
"ec2"
Example:
"nova"
Declared by:
/nix/store/hfdgq4q3ijcchcdhdrllf5962qb9xb08-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/hfdgq4q3ijcchcdhdrllf5962qb9xb08-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
for each machine.
machine
-encrypted
Default:
[
]
Declared by:
/nix/store/hfdgq4q3ijcchcdhdrllf5962qb9xb08-git-export/nix/options.nix |
deployment.keys
The set of keys to be deployed to the machine. Each attribute
maps a key name to a key string. On the machine, the key can
be accessed as
/run/keys/
.
Thus, name>
{ password = "foobar"; }
causes a
file /run/keys/password
to be created
with contents foobar
. The directory
/run/keys
is only accessible to root.
Default:
{
}
Example:
{
password = "foobar";
}
Declared by:
/nix/store/hfdgq4q3ijcchcdhdrllf5962qb9xb08-git-export/nix/keys.nix |
deployment.owners
List of emailaddresses of the owners of the machines. Used to send email on performing certain actions.
Default:
[
]
Declared by:
/nix/store/hfdgq4q3ijcchcdhdrllf5962qb9xb08-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/hfdgq4q3ijcchcdhdrllf5962qb9xb08-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/hfdgq4q3ijcchcdhdrllf5962qb9xb08-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/hfdgq4q3ijcchcdhdrllf5962qb9xb08-git-export/nix/route53.nix |
deployment.storeKeysOnMachine
If true (default), 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:
true
Declared by:
/nix/store/hfdgq4q3ijcchcdhdrllf5962qb9xb08-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/hfdgq4q3ijcchcdhdrllf5962qb9xb08-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.
Default: none
Declared by:
/nix/store/hfdgq4q3ijcchcdhdrllf5962qb9xb08-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/hfdgq4q3ijcchcdhdrllf5962qb9xb08-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:
Example:
"/home/alice/base-disk.vdi"
Declared by:
/nix/store/hfdgq4q3ijcchcdhdrllf5962qb9xb08-git-export/nix/virtualbox.nix |
deployment.virtualbox.disks.<name>.port
SATA port number to which the disk is attached.
Default: none
Example:
1
Declared by:
/nix/store/hfdgq4q3ijcchcdhdrllf5962qb9xb08-git-export/nix/virtualbox.nix |
deployment.virtualbox.disks.<name>.size
Size (in megabytes) of this disk.
Default: none
Declared by:
/nix/store/hfdgq4q3ijcchcdhdrllf5962qb9xb08-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/hfdgq4q3ijcchcdhdrllf5962qb9xb08-git-export/nix/virtualbox.nix |
deployment.virtualbox.memorySize
Memory size (M) of virtual machine.
Default:
512
Declared by:
/nix/store/hfdgq4q3ijcchcdhdrllf5962qb9xb08-git-export/nix/virtualbox.nix |
fileSystems
NixOps extends NixOS' fileSystem
option to
allow convenient attaching of EC2 volumes.
Default: none
Declared by:
/nix/store/hfdgq4q3ijcchcdhdrllf5962qb9xb08-git-export/nix/ec2.nix |
/nix/store/hfdgq4q3ijcchcdhdrllf5962qb9xb08-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:
Declared by:
/nix/store/hfdgq4q3ijcchcdhdrllf5962qb9xb08-git-export/nix/ec2.nix |
fileSystems.*.ec2.cipher
The cipher used to encrypt the disk.
Default:
"aes-cbc-essiv:sha256"
Declared by:
/nix/store/hfdgq4q3ijcchcdhdrllf5962qb9xb08-git-export/nix/ec2.nix |
fileSystems.*.ec2.deleteOnTermination
For automatically created EBS volumes, determines whether the volume should be deleted on instance termination.
Default: none
Declared by:
/nix/store/hfdgq4q3ijcchcdhdrllf5962qb9xb08-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.
Default:
""
Example:
"vol-d04895b8"
Declared by:
/nix/store/hfdgq4q3ijcchcdhdrllf5962qb9xb08-git-export/nix/ec2.nix |
fileSystems.*.ec2.encrypt
Whether the EBS volume should be encrypted using LUKS.
Default:
false
Declared by:
/nix/store/hfdgq4q3ijcchcdhdrllf5962qb9xb08-git-export/nix/ec2.nix |
fileSystems.*.ec2.fsType
Filesystem type for automatically created EBS volumes.
Default:
"ext4"
Declared by:
/nix/store/hfdgq4q3ijcchcdhdrllf5962qb9xb08-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/hfdgq4q3ijcchcdhdrllf5962qb9xb08-git-export/nix/ec2.nix |
fileSystems.*.ec2.keySize
The size of the encryption key.
Default:
128
Declared by:
/nix/store/hfdgq4q3ijcchcdhdrllf5962qb9xb08-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/hfdgq4q3ijcchcdhdrllf5962qb9xb08-git-export/nix/ec2.nix |
fileSystems.*.ec2.size
Filesystem size (in gigabytes) for automatically created EBS volumes.
Default:
0
Declared by:
/nix/store/hfdgq4q3ijcchcdhdrllf5962qb9xb08-git-export/nix/ec2.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/hfdgq4q3ijcchcdhdrllf5962qb9xb08-git-export/nix/ssh-tunnel.nix |
networking.p2pTunnels.ssh.<name>.localIPv4
IPv4 address of the local endpoint of the tunnel.
Default: none
Declared by:
/nix/store/hfdgq4q3ijcchcdhdrllf5962qb9xb08-git-export/nix/ssh-tunnel.nix |
networking.p2pTunnels.ssh.<name>.localTunnel
Local tunnel device number.
Default: none
Declared by:
/nix/store/hfdgq4q3ijcchcdhdrllf5962qb9xb08-git-export/nix/ssh-tunnel.nix |
networking.p2pTunnels.ssh.<name>.privateKey
Path to the private key file used to connect to the remote machine.
Default: none
Declared by:
/nix/store/hfdgq4q3ijcchcdhdrllf5962qb9xb08-git-export/nix/ssh-tunnel.nix |
networking.p2pTunnels.ssh.<name>.remoteIPv4
IPv4 address of the remote endpoint of the tunnel.
Default: none
Declared by:
/nix/store/hfdgq4q3ijcchcdhdrllf5962qb9xb08-git-export/nix/ssh-tunnel.nix |
networking.p2pTunnels.ssh.<name>.remoteTunnel
Remote tunnel device number.
Default: none
Declared by:
/nix/store/hfdgq4q3ijcchcdhdrllf5962qb9xb08-git-export/nix/ssh-tunnel.nix |
networking.p2pTunnels.ssh.<name>.target
Host name or IP address of the remote machine.
Default: none
Declared by:
/nix/store/hfdgq4q3ijcchcdhdrllf5962qb9xb08-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).
Default: none
Example:
"10.1.2.3"
Declared by:
/nix/store/hfdgq4q3ijcchcdhdrllf5962qb9xb08-git-export/nix/options.nix |
networking.publicIPv4
Publicly routable IPv4 address of this machine.
Default: none
Example:
"198.51.100.123"
Declared by:
/nix/store/hfdgq4q3ijcchcdhdrllf5962qb9xb08-git-export/nix/options.nix |
An Amazon SQS queue is defined by setting
resources.sqsQueues.
to an attribute set containing values for the following
options.name
accessKeyId
The AWS Access Key ID.
Default: none
Declared by:
/nix/store/hfdgq4q3ijcchcdhdrllf5962qb9xb08-git-export/nix/sqs-queue.nix |
arn
Amazon Resource Name (ARN) of the queue. This is set by NixOps.
Default:
""
Declared by:
/nix/store/hfdgq4q3ijcchcdhdrllf5962qb9xb08-git-export/nix/sqs-queue.nix |
name
Name of the SQS queue.
Default:
"charon-<uuid>-<name>"
Declared by:
/nix/store/hfdgq4q3ijcchcdhdrllf5962qb9xb08-git-export/nix/sqs-queue.nix |
region
Amazon EC2 region.
Default: none
Declared by:
/nix/store/hfdgq4q3ijcchcdhdrllf5962qb9xb08-git-export/nix/sqs-queue.nix |
url
URL of the queue. This is set by NixOps.
Default:
""
Declared by:
/nix/store/hfdgq4q3ijcchcdhdrllf5962qb9xb08-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/hfdgq4q3ijcchcdhdrllf5962qb9xb08-git-export/nix/sqs-queue.nix |
An Amazon EC2 keypair is defined by setting
resources.ec2KeyPairs.
to an attribute set containing values for the following
options.name
accessKeyId
The AWS Access Key ID.
Default: none
Declared by:
/nix/store/hfdgq4q3ijcchcdhdrllf5962qb9xb08-git-export/nix/ec2-keypair.nix |
name
Name of the EC2 key pair.
Default:
"charon-<uuid>-<name>"
Declared by:
/nix/store/hfdgq4q3ijcchcdhdrllf5962qb9xb08-git-export/nix/ec2-keypair.nix |
region
Amazon EC2 region.
Default: none
Declared by:
/nix/store/hfdgq4q3ijcchcdhdrllf5962qb9xb08-git-export/nix/ec2-keypair.nix |
An Amazon S3 bucket is defined by setting
resources.s3Buckets.
to an attribute set containing values for the following
options.name
accessKeyId
The AWS Access Key ID.
Default: none
Declared by:
/nix/store/hfdgq4q3ijcchcdhdrllf5962qb9xb08-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/hfdgq4q3ijcchcdhdrllf5962qb9xb08-git-export/nix/s3-bucket.nix |
name
Name of the S3 bucket.
Default:
"charon-<uuid>-<name>"
Declared by:
/nix/store/hfdgq4q3ijcchcdhdrllf5962qb9xb08-git-export/nix/s3-bucket.nix |
region
Amazon S3 region.
Default: none
Declared by:
/nix/store/hfdgq4q3ijcchcdhdrllf5962qb9xb08-git-export/nix/s3-bucket.nix |
An Amazon IAM role is defined by setting
resources.iamRoles.
to an attribute set containing values for the following
options.name
accessKeyId
The AWS Access Key ID.
Default: none
Declared by:
/nix/store/hfdgq4q3ijcchcdhdrllf5962qb9xb08-git-export/nix/iam-role.nix |
name
Name of the IAM role.
Default:
"charon-<uuid>-<name>"
Declared by:
/nix/store/hfdgq4q3ijcchcdhdrllf5962qb9xb08-git-export/nix/iam-role.nix |
policy
The IAM policy definition (in JSON format).
Default: none
Declared by:
/nix/store/hfdgq4q3ijcchcdhdrllf5962qb9xb08-git-export/nix/iam-role.nix |
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-build --run-env 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 the NixOps in your source tree as follows:
$ nixops
Table of Contents