forked from mirrors/nixpkgs
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>
|
||
|
|
|