I have a nixops network where I deploy containers using the `container`
backend which uses `nixos-container` intenrally to deploy several
containers to a certain host.
During that time I removed and added new containers and while trying to
deploy those to a different host I realized that it isn't guaranteed
that each container gets the same IP address which is a problem as some
parts of the deployment need to know which container is using which IP
(i.e. to configure port forwarding on the host).
With this change you can specify the container's IP like this (and don't
have to use the arbitrarily used 10.233.0.0/16 subnet):
```
$ nixos-container create test --config-file test-container.nix \
--local-address 10.235.1.2 --host-address 10.235.1.1
```
The containers local address can be given as ipv4 only or with a subnetmask in
CIDR notation in the container configuration, see [1]. This works fine but the
'nixos-container show-ip' only supports plain ipv4 addresses without the netmask
suffix.
Changed the regex to also match in case of a CIDR netmask suffix.
[1] 9939032e35/nixos/modules/virtualisation/containers.nix (L382)
This reverts commit
c37e76b4d2. Unfortunately, using
"machinectl shell" has two bad side effects:
* It sends the command's stderr to stdout.
* It doesn't propagate the command's exit status.
This broke NixOps.
PR #18825.
This should be completely backwards compatible. It allows the '-f' part
of the nix-env command to be configured. This greatly eases using
nixos-container as part of development where several nixpkgs
repositories might be tested at the same time.
My earlier commit to have `nixos-container destroy` use `kill` broke
the `container-imperative` test, see[1]. As suggested by @aszlig,
`machinectl terminate` doesn't have that problem, and is the command
that should have been used to begin with rather then `kill`.
1| 60c6c7bc9a (commitcomment-18478032)
Using 'machinectl kill' is much faster then gracefully stopping the
container.
In the case of 'destroy', since we're destroying it anyway, there's no
reason to do a graceful shutdown.
This moves nixos-containers into its own package so that it can be
relied upon by other packages/systems. This should make development
using dynamic containers much easier.
2016-07-19 08:13:06 +02:00
Renamed from nixos/modules/virtualisation/nixos-container.pl (Browse further)