35 lines
1.5 KiB
XML
35 lines
1.5 KiB
XML
|
<chapter xmlns="http://docbook.org/ns/docbook"
|
||
|
|
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||
|
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||
|
|
version="5.0"
|
||
|
|
xml:id="ch-containers">
|
||
|
|
<title>Container Management</title>
|
||
|
|
<para>
|
||
|
|
NixOS allows you to easily run other NixOS instances as
|
||
|
|
<emphasis>containers</emphasis>. 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.
|
||
|
|
</para>
|
||
|
|
<warning>
|
||
|
|
<para>
|
||
|
|
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.
|
||
|
|
</para>
|
||
|
|
</warning>
|
||
|
|
<para>
|
||
|
|
NixOS containers can be created in two ways: imperatively, using the command
|
||
|
|
<command>nixos-container</command>, and declaratively, by specifying them in
|
||
|
|
your <filename>configuration.nix</filename>. The declarative approach implies
|
||
|
|
that containers get upgraded along with your host system when you run
|
||
|
|
<command>nixos-rebuild</command>, which is often not what you want. By
|
||
|
|
contrast, in the imperative approach, containers are configured and updated
|
||
|
|
independently from the host system.
|
||
|
|
</para>
|
||
|
|
<xi:include href="imperative-containers.xml" />
|
||
|
|
<xi:include href="declarative-containers.xml" />
|
||
|
|
<xi:include href="container-networking.xml" />
|
||
|
|
</chapter>
|