NixOps: Difference between revisions

From NixOS Wiki
Klinger (talk | contribs)
mNo edit summary
m change manual url (got from github readme)
 
(3 intermediate revisions by 3 users not shown)
Line 1: Line 1:
'''Note:''' NixOps is currently undergoing a transition between major versions. At this specific time it requires some elbow grease to get running. It is in active development and will soon be easier to use again. See [https://github.com/NixOS/nixops/issues/1574 nixops #1574] for updates and details. (Current as of Feb 2024)
'''NixOps''' is a tool for deploying NixOS systems in a reproducible and declarative manner. It allows users to manage and deploy entire NixOS-based infrastructures, whether to cloud platforms, virtual machines, or physical hardware.


<blockquote>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 or actions to realise that specification: instantiate cloud machines, build and download dependencies, stop and start services, and so on. NixOps has several nice properties:
{{warning|'''at this time NixOps is not actively recommended for new projects or users'''. The tool is undergoing a significant transition between major versions, which has led to some instability and increased complexity in getting it up and running. As of August 2024, it requires extra effort to set up and maintain, and it might not offer the smooth experience users typically expect from NixOS tools. See [https://github.com/NixOS/nixops/issues/1574 nixops #1574] for updates and details or check out the [https://github.com/nixops4/nixops4 nixops4] project.}}


    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.
NixOps allows users to declaratively specify the desired configuration of their systems and then automatically performs all necessary actions to realize that configuration. This includes tasks such as instantiating cloud machines, managing dependencies, and provisioning resources. NixOps is meant to be fully automated and to create reproducible deployments that leverage the Nix package manager’s purely functional model, creating consistency in the configuration and providing reliability across various environments.


    It performs fully automated deployment. This is a good thing because it ensures that deployments are reproducible.
For further details, please refer to the [https://nixos.org/nixops/manual/ NixOps manual], which provides an overview of its functionality and features, as well as an up-to-date installation guide.


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


    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.
This example demonstrates a basic NixOps configuration that sets up a staging environment with two machines: a reverse proxy and an application server running a git server (Forgejo). This example assumes that both machines already exist, that SSH in the operator's machine is well configured to reach them, and that both machines are running NixOS. The [[Overview of the Nix Language|nix language]] allows referencing the configuration of other machines using the <code>nodes</code> argument, making it easy to link services across the network.


     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.
<syntaxhighlight lang="nix">
# network-staging.nix file
let
  proxyHostname = "proxy.example.com";
  gitHostname = "10.0.0.2";
in {
  network.description = "Staging environment for our git setup";
  defaults.imports = [ ./common.nix ];
 
  reverse-proxy = { nodes, ... }: {
     deployment.targetHost = proxyHostname;
    services.nginx = {
      enable = true;
      virtualHosts."example.com".locations."/" = {
        proxyPass = "http://${gitHostname}:${nodes.gitServer.config.services.forgejo.port}";
      };
    };
    # the rest of reverse-proxy's configuration can be added here
  };
 
  gitServer = _: {
    deployment.targetHost = gitHostname;
    services.forgejo.enable = true;
    # additional git server configuration can be added here
  };
}
</syntaxhighlight>


    It’s multi-cloud. Machines in a single NixOps deployment can be deployed to different target environments. 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).
=== Invocation ===


    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.
To apply this configuration on both nodes, one must first create a deployment with the <code>nixops create</code> command, and then apply the new configuration with <code>nixops deploy</code>.


    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.
<syntaxhighlight lang="bash">
nixops create network-staging.nix -d staging
> created deployment ‘32b06868-d27c-11e2-a055-81d7beb7925e’


    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.
nixops deploy -d staging
</syntaxhighlight>


    It can provision non-machine cloud resources such as Amazon S3 buckets and EC2 keypairs.</blockquote>
== External links ==
<cite>From the [https://releases.nixos.org/nixops/latest/manual/manual.html#chap-introduction NixOps User's Guide (manual)]</cite>


The [https://releases.nixos.org/nixops/latest/manual/manual.html NixOps User's Guide] provides an overview of the functionality and features of NixOps, as well as an up-to-date installation guide. Some other topics covered:
* [https://nixos.org/manual/nixops/stable/ The NixOps Manual]
* Deploying to local targets:
* [https://www.youtube.com/watch?v=SoHtccHNOJ8 A presentation on NixOps by Kim Lindberger (talyz) - Oslo NixOS MiniCon, March 2020]
** VirtualBox machine(s)
* [https://eno.space/blog/2021/08/nixos-on-underpowered-devices An example of cross-building for ARM and x86_64 using nixops]
** Libvirtd (Qemu) machine(s)
** Existing NixOS machine(s)
* Deploying to clouds:
** Amazon EC2, Google Compute Engine, Microsoft Azure (Azure disabled since 2018)
** Hetzner, DigitalOcean
* Setting up [https://www.datadoghq.com/ DataDog] cloud monitoring.
 
== Usage ==
 
== Internals ==


== See also ==
== See also ==


* [https://www.youtube.com/watch?v=SoHtccHNOJ8 A presentation on NixOps by Kim Lindberger (talyz) - Oslo NixOS MiniCon, March 2020]
* [[krops]]
* [[krops]]
* [[morph]]
* [[morph]]
* [[nix-deploy]]
* [[nix-deploy]]
* [[nixus]]
* [[Colmena]]
 


[[Category:Pedias]]
[[Category:NixOps]]
[[Category:NixOps]]
[[Category:Deployment]]
[[Category:Deployment]]

Latest revision as of 08:10, 14 September 2024

NixOps is a tool for deploying NixOS systems in a reproducible and declarative manner. It allows users to manage and deploy entire NixOS-based infrastructures, whether to cloud platforms, virtual machines, or physical hardware.

Warning: at this time NixOps is not actively recommended for new projects or users. The tool is undergoing a significant transition between major versions, which has led to some instability and increased complexity in getting it up and running. As of August 2024, it requires extra effort to set up and maintain, and it might not offer the smooth experience users typically expect from NixOS tools. See nixops #1574 for updates and details or check out the nixops4 project.

NixOps allows users to declaratively specify the desired configuration of their systems and then automatically performs all necessary actions to realize that configuration. This includes tasks such as instantiating cloud machines, managing dependencies, and provisioning resources. NixOps is meant to be fully automated and to create reproducible deployments that leverage the Nix package manager’s purely functional model, creating consistency in the configuration and providing reliability across various environments.

For further details, please refer to the NixOps manual, which provides an overview of its functionality and features, as well as an up-to-date installation guide.

Example Configuration

This example demonstrates a basic NixOps configuration that sets up a staging environment with two machines: a reverse proxy and an application server running a git server (Forgejo). This example assumes that both machines already exist, that SSH in the operator's machine is well configured to reach them, and that both machines are running NixOS. The nix language allows referencing the configuration of other machines using the nodes argument, making it easy to link services across the network.

# network-staging.nix file
let
  proxyHostname = "proxy.example.com";
  gitHostname = "10.0.0.2";
in {
  network.description = "Staging environment for our git setup";
  defaults.imports = [ ./common.nix ];
  
  reverse-proxy = { nodes, ... }: {
    deployment.targetHost = proxyHostname;
    services.nginx = {
      enable = true;
      virtualHosts."example.com".locations."/" = {
        proxyPass = "http://${gitHostname}:${nodes.gitServer.config.services.forgejo.port}";
      };
    };
    # the rest of reverse-proxy's configuration can be added here
  };
  
  gitServer = _: {
    deployment.targetHost = gitHostname;
    services.forgejo.enable = true;
    # additional git server configuration can be added here
  };
}

Invocation

To apply this configuration on both nodes, one must first create a deployment with the nixops create command, and then apply the new configuration with nixops deploy.

nixops create network-staging.nix -d staging
> created deployment ‘32b06868-d27c-11e2-a055-81d7beb7925e’

nixops deploy -d staging

External links

See also