DBCDK
Deploy an already built configuration
Hi, love the project
I currently have a CI/CD for testing and deploying nix related stuff to different hosts
In my CI I'm building the configuration and then if everything works well I want to be able to deploy this already built configuration to the remote host in my CD
It looks like morph don't allow deploying an already built configuration
Would this be possible ?
Hi
I have actually been thinking about this lately.
As it is, metadata (such as deployment order and health checks) are only available to morph when evaluating the deployment, so for such a feature to be meaningful that metadata would have to be part of the build output (and this might actually make total sense).
Can you describe more about how you would expect such a feature to work? And in what scenarios it's useful in? I imagine it being a situation where you want to be able to deploy a system without having the deployment sources available.
If you want this feature now, maybe it's easier for now to nix copy the built system onto the remote host, and trigger the switch-to-configuration machinery that is available somewhere in the system. Sadly this will be without health checks, and have to be done on each host individually.
@adamtulinius AFAIK, eval of metadata is waaaay faster than eval of a nixos config? It's sorta directly visible on morph in that the host-lists, including tags etc. shows up after just a couple of seconds, even though you have a long list of hosts. :)
So... One could imagine adding a feature to morph that would allow morph to jump to the target host and try to substitute the desired system, as a first step, and then (and only then) - if the wanted system is not present or cannot be substituted - will the system be build locally.
Of course all of this would be much more fun if morph did things in parallel :) And also, I don't wanna highjack this issue. The above is just a suggestion/thought.
EDIT: And of course you need a way to specify the desired system if you don't wanna waste time eval'ing it. :)
So... One could imagine adding a feature to morph that would allow morph to jump to the target host and try to substitute the desired system, as a first step, and then (and only then) - if the wanted system is not present or cannot be substituted - will the system be build locally.
:wave:
Yeah that's a valid point. But that's also why I'm curious about the usecase, and what is being optimized for (because my own thoughts have been a different kind of decoupling, where deployment without sources could be interesting).
Of course all of this would be much more fun if morph did things in parallel :)
Something might be in the works here :sweat_smile:
AFAIK, eval of metadata is waaaay faster than eval of a nixos config? It's sorta directly visible on morph in that the host-lists, including tags etc. shows up after just a couple of seconds, even though you have a long list of hosts. :)
That is true. I think we've used some unfortunate terminology in morph. When I said "eval the deployment" I meant the eval-machines.nix bit, which is in fact very quick (as opposed to morphs implicit "eval all the hosts step" that comes next).
With my edit above, I realized that there's probably also a variant where you:
- Still eval the NixOS systems locally
- But you don't wanna build or substitute to your local store, before copy'ing to remote
Right now you are forced to getting the system on your local machine, one way or another, which ... is not really necessary. (if your target host already has the desired system or can substitute it directly)
^^ This "variant" might be easier to fix (than trying to eliminate system eval)
With my edit above, I realized that there's probably also a variant [.. snip]
Maybe the best way forward is to create separate issues for the different variations? And then in this issue we can focus on @JustAlternate's problem. Does that sound ok?
Yes the root of my problem is to be able to build the configuration in a job of my CI, verify that the build succeeded, do other checks...
And after that, launch a CD job to deploy the configuration by reusing the built artifact that was made previously by the CI.
So I was wondering if it was possible for morph to deploy an already built configuration to one or multiple host
I imagine something like
morph deploy machine_to_deploy.nix switch --use-already-built-configuration=./result/
So that morph can still check what machine it needs to deploy using the machine_to_deploy.nix file and then skip the build process and directly scp the result on every host machine and then switch to it.
And after that, launch a CD job to deploy the configuration by reusing the built artifact that was made previously by the CI.
If that job still had access to the sources, and you invoked morph again, you would only incur the overhead of evaluating the deployment again, and morph (really, nix) would end up using the already built artifacts in the nix store already.
It's currently not possible to do what you want with morph, but I'll add this to a future 2.0 milestone, since it's a good idea, but a rather big thing to implement properly.
Sorry about the bad news on this front :(