Vagrant is a nice tool to manage development and test environments. You describe in a Vagrantfile the VMs that you need, how they are connected (e.g. private network), and what to execute after they are brought up. Unfortunately, HashiCorp changed the Vagrant license to a non-free one. Also, Vagrant uses VirtualBox by default, which is not great (it can also use libvirt and kvm, but that adds complexity and slightly less supported).
Looking at Incus features, it looks like it has everything needed to be a Vagrant replacement, except that it does not provide a nice simple way to describe everything that should be provisioned in a single place. Typically, I’d like to be able to create a IncusFile in my development project that says that to create my dev environment, I need incus to:
create a network
create 2 containers with those images, and those IP addresses
set up shared folders with the host so that I can access my code from the containers
on the first container, run those commands
on the second container, run those commands
And then run incus provision to provision everything, and when I’m done, run incus destroy to remove everything.
I saw that there’s a provider for terraform, but it looks a bit scary to bring all the complexity of terraform here.
If you want to script that without the complexity of Terraform, the simplest way would be to just transform your bullet list into a small shell script - if you don’t care about error handling and don’t get fancy, would probably around 5 to 10 lines…
Otherwise, if you want to have some kind of “official” framework but don’t want to pull in all of Terraform, I’d go with Ansible. There’s an LXD/Incus provider for that as well.
There seems to be development of a declarative and idempotent process for building Incus environments on NixOS: https://wiki.nixos.org/wiki/Incus
Another link describing a NixOS and Incus pairing as synergistic:
It would be great to see Incus become a truly developer friendly virtualisation platform competitive with the likes of Podman, Distrobox, Toolbx and Vagrant.
I’m looking at Ivan Pepelnjak’s Netlab and it uses KVM/libvirt with Vagrant but cannot support LXC or Docker based network appliances unless separate solutions are built using Containerlab or Docker: https://netlab.tools/
Incus would be a great fit for Netlab if an IncusFile for declarative builds was possible.
Incus + Netlab — no need for juggling kvm-libvirt-vagrant-docker-containerlab environments to support different network appliances: https://netlab.tools/platforms/
NixOS seems like a great platform to implement a declarative Incus until such time as it becomes a native capability in Incus.
The OP has I believe a good point about the desirability of being able to declaratively reproduce Incus state in a single file — such as a Vagrant file, or NixOS configuration.nix file.
This declarative idempotence would not only be obvious to new comers but it would be promoted in marketing and documentation as a first class method of deployment in addition to interactive configuration through a CLI.
There exists a short discussion raised under an Issue:
In the context of deploying Incus into complex data centre infrastructure the introduction of third party dependencies like Terraform and Ansible makes sense. However, in the context of a single-node developer environment a native declarative capability also makes sense and would dramatically improve usability and adoption.
The foundation for a truly declarative deployment and change method in a developer context already exists and perhaps could be matured over time with help from the community:
The pre-seed non-interactive option:
Limiting initial work to a single developer instance might simplify and reduce the size of the task.
Perhaps the first solution is to introduce a deployment method into the documentation that is specifically targeted at developers? From this declarative idempotency might grow.
Is that true? Their home page says “Community Edition: Always Free. Download the Vagrant binary and run locally or within your environments.”
Vagrant comes with built-in support for three backends: VirtualBox, HyperV and Docker. Vagrant works with Providers to support various backends. Custom providers can be written to support other backends like Incus.
Maybe it would be possible to write an Incus provider for Vagrant.
The Licensor hereby grants you the right to copy, modify, create derivative works, redistribute, and make non-production use of the Licensed Work. The Licensor may make an Additional Use Grant, above, permitting limited production use.
It seems as though Vagrant is indeed free of cost for use in non-production environments.
The software isn’t open source but that is a different issue.
It seems as though Vagrant is indeed free of cost for use in non-production environments.
I don’t think that this should be read as being about « production environments » vs « non-production environments » (e.g. development/test environments).
The license text says « production use ». If I use Vagrant to develop (produce) software, I think it is a fair interpretation to say that this is a « production use ».
This is a commercial license. It’s absolutely not “free as in speech”, and it’s only “free as in beer” under certain conditions.
It comes in two parts: the BSL itself, and the “Additional Use Grant”.
Neither of them actually defines the term “production use”, which the BSL forbids unless you purchase a commercial license, but the AUG permits production use “provided your use does not include offering the Licensed Work to third parties on a hosted or embedded basis in order to compete with HashiCorp’s paid version(s) of the Licensed Work”
The intention is that if you sell a CI/CD service, which includes Vagrant as part of the pipeline, then you’re not covered.
If you’re using it in your home lab, you’re probably fine. If you’re using it at work for internal purposes, then it depends whether your employer’s legal department is comfortable to rely on the AUG or not. Some are, some aren’t. The more conservative ones will pay for a license to eliminate the risk (which is probably what Hashicorp wants).
I don’t yet have experience with Vagrant and got interested in it and this thread because of Ivan Pepelnjak’s Netlab network building platform’s reliance on free Vagrant:
Looking at Netlab it seems to be an excellent case for Incus because there is a mix of VM and LXC workloads (and maybe some Docker/OCI).
If Incus could take the role of Vagrant in the lab Ivan could simplify it significantly. I don’t have the skill to hack it, unfortunately.
Vagrant: Development environments managed by Vagrant can run on local virtualized platforms such as VirtualBox or VMware, in the cloud via AWS or OpenStack, or in containers such as with Docker or raw LXC.
I do not know whether it’s a lower hanging fruit to get Incus to become a new local virtualized platform for Vagrant. There’s apparently already LXC support in Vagrant. Most likely it would be a task for Vagrant to take, after some encouragement (they will make the $$$ out of such an implementation).
I think these are the providers, and there is Docker, HyperV and VirtualBox in there.
Similarly, netlab has a list of virtualization providers and Incus is not in there yet. Again, the low-hanging fruit is to figure out how to add Incus as a new virtualization provider.
This post title is about adding a feature to Incus (virtualization provider) to make it equivalent to Vagrant (generate virtualization environments). I do not know how much effort is needed for such a task. Vagrant looks like quite big and mature to add as its functionality into Incus. If Incus becomes usable into Vagrant (and netlab), then users of Vagrant and netlab will get to know Incus, and then it might make sense to offer such functionality from within Incus.