Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support NixOS containers as targets #112

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

vapourismo
Copy link

@vapourismo vapourismo commented Jul 20, 2022

This adds support for applying a configuration to a NixOS container.

Note, this requires the respective container to already exist and be started.


Example:

Hive configuration (partial):

{
  # ...

  "test" = _: {
    deployment = {
      targetHost = "example.com";
      targetContainer = "test";
      buildOnTarget = true;
    };

    boot.isContainer = true;

    system = {
      stateVersion = "22.11";

      configurationRevision = "hello-world";
    };
  };
}

Apply the configuration:

λ colmena apply --on test
[INFO ] Using flake: git+file:///path/to/flake
[INFO ] Enumerating nodes...
[INFO ] Selected 1 out of 2 hosts.
      ✅ 7s All done!
 test ✅ 3s Evaluated test
 test ✅ 2s Built "/nix/store/n46xpmzlqvz76bnyl4dlfm26a20qhss1-nixos-system-nixos-22.11pre-git" on target node
 test ✅ 2s Activation successful

Verify:

[root@example.com:~]# nixos-container run test -- nixos-version --json
{"configurationRevision":"hello-world","nixosVersion":"22.11pre-git"}

@bjornfor
Copy link
Contributor

Interesting! Does this work with extra-container too?

Background: I recently wanted to do something similar. I wrote a script to deploy extra-container containers on some (Ubuntu) hosts and then used colmena to manage them from there on. I access the container instead of the host by simply using a non-standard sshd port.

@vapourismo
Copy link
Author

I haven't tried it, but I could imagine it might work if you use extra-container to provision the container and then update it with Colmena. However, there is the risk that extra-container detects a container has being changed (because Colmena did so) and resets it when you're trying to update some non-Colmena managed containers.

@vapourismo
Copy link
Author

vapourismo commented Jul 20, 2022

Actually, maybe Colmena can subsume your use of extra-container if it were to check and conditionally provision a container on the target host if it doesn't exist already.

@bjornfor
Copy link
Contributor

Actually, maybe Colmena can subsume your use of extra-container if it were to check and conditionally provision a container on the target host if it doesn't exist already.

In my case the host is Ubuntu, so colmena has no provisioning powers there.

(My deploy script runs extra-container if the host/container is unreachable, then continues to run colmena. When re-running the deploy script, and the host/container is up, it bypasses extra-container and calls colmena directly.)

@vapourismo
Copy link
Author

vapourismo commented Jul 20, 2022

In that case, I think this change won't help you much as the host still needs to be NixOS-ish.

This container deployment mechanism relies on the fact that NixOS shares the Nix store between host and containers.

@bjornfor
Copy link
Contributor

In that case, I think this change won't help you much as the host still needs to be NixOS-ish.

This container deployment mechanism relies on the fact that NixOS shares the Nix store between host and containers.

FYI, the extra-container container I have on Ubuntu does share the Nix store with the host.

@vapourismo
Copy link
Author

@zhaofengli, do you have time to look at this?

@zhaofengli
Copy link
Owner

Hi, sorry for the delay. This is a bit too specialized in my view, and relies on pre-existing configurations on the target host (the container already running). I think something like the profile API in deploy-rs is more flexible to accommodate multiple usecases like this without adding all of them into Colmena itself.

@vapourismo
Copy link
Author

Thanks for the comment, @zhaofengli.

This is a bit too specialized in my view, and relies on pre-existing configurations on the target host (the container already running).

I am not sure I follow this argument exactly.

The targetHost also needs to be pre-configured and up when applying, no? So this isn't too different from the existing "target" mechanism in my opinion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants