infrastructure/meta
Ryan Lahfa a4de5f4d31
All checks were successful
Check meta / check_meta (pull_request) Successful in 16s
Check meta / check_dns (pull_request) Successful in 18s
build configuration / build_and_cache_geo01 (pull_request) Successful in 1m8s
build configuration / build_and_cache_rescue01 (pull_request) Successful in 1m17s
build configuration / build_and_cache_storage01 (pull_request) Successful in 1m21s
build configuration / build_and_cache_geo02 (pull_request) Successful in 1m9s
build configuration / build_and_cache_compute01 (pull_request) Successful in 1m52s
build configuration / build_and_cache_krz01 (pull_request) Successful in 2m0s
lint / check (pull_request) Successful in 25s
build configuration / build_and_cache_vault01 (pull_request) Successful in 1m18s
build configuration / build_and_cache_web02 (pull_request) Successful in 1m14s
build configuration / build_and_cache_bridge01 (pull_request) Successful in 1m2s
build configuration / build_and_cache_web01 (pull_request) Successful in 1m48s
Check meta / check_meta (push) Successful in 19s
Check meta / check_dns (push) Successful in 20s
build configuration / build_and_cache_geo01 (push) Successful in 1m5s
build configuration / build_and_cache_geo02 (push) Successful in 1m5s
build configuration / build_and_cache_storage01 (push) Successful in 1m27s
build configuration / build_and_cache_rescue01 (push) Successful in 1m32s
build configuration / build_and_cache_compute01 (push) Successful in 1m41s
lint / check (push) Successful in 24s
build configuration / build_and_cache_krz01 (push) Successful in 2m20s
build configuration / build_and_cache_bridge01 (push) Successful in 1m9s
build configuration / build_and_cache_web02 (push) Successful in 1m17s
build configuration / build_and_cache_vault01 (push) Successful in 1m22s
build configuration / build_and_cache_web01 (push) Successful in 1m54s
feat(krz01): move ollama to compute01 via a reverse proxy
krz01 has no public web IP.

Signed-off-by: Ryan Lahfa <ryan@dgnum.eu>
2024-10-10 17:40:56 +02:00
..
default.nix feat(dns): Split out config 2024-02-23 13:06:15 +01:00
dns.nix feat(krz01): move ollama to compute01 via a reverse proxy 2024-10-10 17:40:56 +02:00
network.nix fix(krz01): Enable netbird 2024-10-08 12:51:57 +02:00
nixpkgs.nix feat(nixpkgs): Update default version 2024-07-05 14:38:33 +02:00
nodes.nix feat(krz01): create and add the lab admin group to krz01 2024-10-10 13:35:34 +02:00
options.nix feat(users): Add root passwords and deactivate mutableUsers 2024-10-10 09:23:19 +02:00
organization.nix feat(krz01): create and add the lab admin group to krz01 2024-10-10 13:35:34 +02:00
README.md feat: Upgrade machines to nixos-24.05 2024-07-05 10:54:33 +02:00
verify.nix feat(infra): Internalize nix-lib, and make keys management simpler 2024-10-09 18:58:46 +02:00

Metadata of the DGNum infrastructure

DNS

The DNS configuration of our infrastructure is completely defined with the metadata contained in this folder.

The different machines have records pointing to their IP addresses when they exist:

  • $node.$site.infra.dgnum.eu points IN A $ipv4

  • $node.$site.infra.dgnum.eu points IN AAAA $ipv6

  • v4.$node.$site.infra.dgnum.eu points IN A $ipv4

  • v6.$node.$site.infra.dgnum.eu points IN AAAA $ipv6

Then the services hosted on those machines can be accessed through redirections:

  • $service.dgnum.eu IN CNAME $node.$site.infra.dgnum.eu

or, when targeting only a specific IP protocol:

  • $service4.dgnum.eu IN CNAME ipv4.$node.$site.infra.dgnum.eu
  • $service6.dgnum.eu IN CNAME ipv6.$node.$site.infra.dgnum.eu

Extra records exist for ns, mail configuration, or the main website but shouldn't change or be tinkered with.

Network

The network configuration (except the NetBird vpn) is defined statically.

TODO.

Nixpkgs

Machines can use different versions of NixOS, the supported and default ones are specified here.

How to add a new version

  • Switch to a new branch nixos-$VERSION
  • Run the following command
npins add channel nixos-$VERSION
  • Edit meta/nixpkgs.nix and add $VERSION to the supported version.
  • Read the release notes and check for changes.
  • Update the nodes versions
  • Create a PR so that the CI check that it builds

Nodes

The nodes are declared statically, several options can be configured:

  • deployment, the colmena deployment option
  • stateVersion, the state version of the node
  • nixpkgs, the version of NixOS to use
  • admins, the list of administrators specific to this node, they will be given root access
  • adminGroups, a list of groups whose members will be added to admins
  • site, the physical location of the node
  • vm-cluster, the VM cluster hosting the node when appropriate

Some options are set automatically, for example:

  • deployment.targetHost will be inferred from the network configuration
  • deployment.tags will contain infra-$site, so that a full site can be redeployed at once

Organization

The organization defines the groups and members of the infrastructure team, one day this information will be synchronized in Kanidm.

Members

For a member to be allowed access to a node, they must be defined in the members attribute set, and their SSH keys must be available in the keys folder.

Groups

Groups exist only to simplify the management of accesses:

  • The root group will be given administrator access on all nodes
  • The iso group will have its keys included in the ISOs built from the iso folder

Extra groups can be created at will, to be used in node-specific modules.

Module

The meta configuration can be evaluated as a module, to perform checks on the structure of the data.