DISNIX-ENV(1)

πŸ“¦ version 0.10.2, in nixos 26.05, nixpkgs unstable

πŸ’… DISNIX-ENV(1) β€” the disnix-env girlies' edition ✨

okay so bestie, this is the manual page for disnix-env from the User Commands section β€” and like, it's genuinely a whole vibe. it installs or updates the environment of a distributed system. that's the whole personality. let's get into it 🫢


✨ SYNOPSIS ✨

like, here are all the ways you can call her:

disnix-env -s services_nix -i infrastructure_nix -d distribution_nix
[OPTION]
disnix-env -P packages_nix -i infrastructure_nix [OPTION]
disnix-env --rollback [OPTION]
disnix-env --undeploy [OPTION]
disnix-env --switch-generation NUM [OPTION]
disnix-env --list-generations [OPTION]
disnix-env --delete-generations NUM [OPTION]
disnix-env --delete-all-generations NUM [OPTION]
disnix-env -A architecture_nix [OPTION]
disnix-env -D deployment_nix [OPTION]

πŸ’– DESCRIPTION πŸ’–

The command disnix-env is used to install, upgrade, or roll back a service-oriented system in a given environment. that's the job, that's the assignment, she ate πŸ’…

This command requires three Nix expressions as input parameters β€” a services model capturing the components of a distributed system and its inter-dependencies, an infrastructure model capturing the machines in the network and its properties, and a distribution model which maps services to machines. three nix files walk into a bar, and honestly? iconic.

By invoking this command, first all the services that are defined in the distribution model are built from source code including all its dependencies. If all the services are successfully built, the closures of the services are transferred to the target machines in the network. Finally, the services are activated by traversing the inter-dependency graph of all the services. it's giving build β†’ transfer β†’ activate and honestly the pipeline is main character energy ✨

In case of a failure, a rollback is performed to bring the system back in its previous configuration. she's got your back, no cap 😭

If there is already a distributed system configuration deployed, an upgrade is performed. In this phase only the changed parts of the system are deactivated and activated. In this process we also deal with the inter-dependencies so that no services fails due to a missing inter-dependency. lowkey efficient, highkey responsible πŸŽ€

Since the target machines could be of a different type or architecture as the coordinator machine, we may not be able to build a specific service for the given target machine. In such cases, disnix-env also provides the option to build the services on the target machines and to keep the build results for future use. adaptive queen behavior fr fr πŸ‘‘

If state deployment has been enabled for a service and that particular service has been moved from one machine to another, then a snapshot of the state is taken, transferred to the new machine, and finally restored. the state literally packs its bags and moves with the service, we love a smooth relocation πŸ§³πŸ¦‹


🌸 OPTIONS 🌸

okay, the big list. every single one, bestie, i'm not skipping a single flag, we're doing this properly πŸ’œ

  • -s, --services=services_nix β€” Services Nix expression which describes all components of the distributed system
  • -i, --infrastructure=infrastructure_nix β€” Infrastructure Nix expression which captures properties of machines in the network
  • -d, --distribution=distribution_nix β€” Distribution Nix expression which maps services to machines in the network
  • -P, --packages=packages_nix β€” Packages Nix expression specifying the packages that should be deployed in a Nix profile mapped to each machine in the network
  • -A, --architecture=architecture_nix β€” Deployment architecture Nix expression that captures all properties of the services and infrastructure including the distribution of services to targets
  • -D, --deployment=deployment_nix β€” Deployment Nix expression that describes all the mappings that have a one-on-one relationship with the deployment activities that are carried out

  • --undeploy β€” Generates a manifest file that conveniently undeploys all services
  • --switch-to-generation=NUM β€” Switches to a specific profile generation
  • --rollback β€” Switches back to the previously deployed configuration
  • --list-generations β€” Lists all profile generations of the current deployment
  • --delete-generations=NUM β€” Deletes the specified generations. The number can correspond to generation numbers, days (d postfix) or 'old'.
  • --delete-all-generations β€” Deletes all profile generations. This is useful when a deployment has been discarded

  • --target-property=PROP β€” The target property of an infrastructure model, that specifies how to connect to the remote Disnix interface. (Defaults to hostname)
  • --interface=INTERFACE β€” Path to executable that communicates with a Disnix interface. Defaults to: disnix-ssh-client
  • --deploy-state β€” Indicates whether to globally deploy state (disabled by default)
  • -p, --profile=PROFILE β€” Name of the profile that is used for this system. Defaults to: default
  • -m, --max-concurrent-transfers=NUM β€” Maximum amount of concurrent closure transfers. Defaults to: 2
  • --build-on-targets β€” Build the services on the target machines in the network instead of managing the build by the coordinator
  • --extra-params=PARAMS β€” A string with an attribute set in the Nix expression language propagating extra parameters to the input models
  • --coordinator-profile-path=PATH β€” Path where to store the coordinator profile generations

  • --no-upgrade β€” Do not perform an upgrade, but activate all services of the new configuration
  • --no-lock β€” Do not attempt to acquire and release any locks
  • --no-coordinator-profile β€” Specifies that the coordinator profile should not be updated
  • --no-target-profiles β€” Specifies that the target profiles should not be updated
  • --no-migration β€” Do not migrate the state of services from one machine to another, even if they have been annotated as such
⚠️ bestie, watch out for the --no-* family β€” they literally turn off the safety nets and the nice automatic stuff. --no-lock means no locks get acquired or released, and --no-migration means state does not move with the service. turn these off only if you know exactly what you're doing πŸ’€
  • --delete-state β€” Remove the obsolete state of deactivated services
  • --depth-first β€” Snapshots components depth-first as opposed to breadth-first. This approach is more space efficient, but slower.
  • --keep=NUM β€” Amount of snapshot generations to keep. Defaults to: 1
  • --show-trace β€” Shows a trace of the output

  • -h, --help β€” Shows the usage of this command
  • -v, --version β€” Shows the version of this command

πŸ¦‹ ENVIRONMENT πŸ¦‹

because sometimes you don't wanna type the flags, and honestly? valid πŸ™ˆ

  • DISNIX_CLIENT_INTERFACE β€” Sets the client interface (defaults to: disnix-ssh-client)
  • DISNIX_TARGET_PROPERTY β€” Sets the target property of an infrastructure model, that specifies how to connect to the remote Disnix interface. (Defaults to: hostname)
  • DISNIX_PROFILE β€” Sets the name of the profile that stores the manifest on the coordinator machine and the deployed services per machine on each target (Defaults to: default).
  • DISNIX_DEPLOY_STATE β€” If set to 1 it also deploys the state of all components. (defaults to: 0)
  • DISNIX_DELETE_STATE β€” If set to 1 it automatically deletes the obsolete state after upgrading. (defaults to: 0)
  • DYSNOMIA_STATEDIR β€” Specifies where the snapshots must be stored on the coordinator machine (defaults to: /var/state/dysnomia)

Copyright Β© 2008-2022 Sander van der Burg


and that's the whole page, bestie πŸŽ€ you read the whole thing, i'm so proud of you fr fr πŸ’œ this was disnix-env from disnix 0.10.2, dated January 1980 β€” yes, the date is a whole aesthetic, we don't question it πŸ˜­πŸ’… slay, go deploy something 🌈⭐

πŸ“¦ where this page comes from