1229e735ac
this adds support for structural includes to nixos-render-docs. structural includes provide a way to denote the (sub)structure of the nixos manual in the markdown source files, very similar to how we used literal docbook blocks before, and are processed by nixos-render-docs without involvement of xml tooling. this will ultimately allow us to emit the nixos manual in other formats as well, e.g. html, without going through docbook at all. alternatives to this source layout were also considered: a parallel structure using e.g. toml files that describe the document tree and links to each part is possible, but much more complicated to implement than the solution chosen here and makes it harder to follow which files have what substructure. it also makes it much harder to include a substructure in the middle of a file. much the same goes for command-line arguments to the converter, only that command-lined arguments are even harder to specify correctly and cannot be reasonably pulled together from many places without involving another layer of tooling. cli arguments would also mean that the manual structure would be fixed in default.nix, which is also not ideal.
29 lines
1.1 KiB
Markdown
29 lines
1.1 KiB
Markdown
# Container Management {#ch-containers}
|
|
|
|
NixOS allows you to easily run other NixOS instances as *containers*.
|
|
Containers are a light-weight approach to virtualisation that runs
|
|
software in the container at the same speed as in the host system. NixOS
|
|
containers share the Nix store of the host, making container creation
|
|
very efficient.
|
|
|
|
::: {.warning}
|
|
Currently, NixOS containers are not perfectly isolated from the host
|
|
system. This means that a user with root access to the container can do
|
|
things that affect the host. So you should not give container root
|
|
access to untrusted users.
|
|
:::
|
|
|
|
NixOS containers can be created in two ways: imperatively, using the
|
|
command `nixos-container`, and declaratively, by specifying them in your
|
|
`configuration.nix`. The declarative approach implies that containers
|
|
get upgraded along with your host system when you run `nixos-rebuild`,
|
|
which is often not what you want. By contrast, in the imperative
|
|
approach, containers are configured and updated independently from the
|
|
host system.
|
|
|
|
```{=include=} sections
|
|
imperative-containers.section.md
|
|
declarative-containers.section.md
|
|
container-networking.section.md
|
|
```
|