i hate to say it, but i kind of want a yunohost-like-interface, for distributed deployments, for non-technical-folks to manage a fleet of servers, backups between them, migrating apps between servers. possibly a yunohost-simple graphical interface, ansible roles in the backend
the feature i really want here is:
- you can backup apps to some type of encrypted format at rest
- you can restore apps from the backup repositories to different target machines
* the backups are stored in a very idempotent and self-contained way, so they can be deployed to different machines without any pre-configuration
this is all possible, to some degree, with yunohost backups. but not in one multi-machine interface
cc @yunohost
@notplants @yunohost@toot.aquilenet.fi i really think VMs might be the tree you are barking up here
@forestjohnson I'm curious why you are thinking of vms as opposed to some other type of app encapsulation/container like docker (like what coop-cloud is based off).
why might one want to package an app as a vm instead of into a coop cloud package?
I could imagine the multi-machine app + backup ui I was imagining having coop cloud or something else (like deployable vm images) in the background
> Why vms?
Because qemu qcow images have a great way of implementing differential backups : high reliability, no external dependency, and low performance impact to the disk. Backing up the entire VM can be desirable because its much more likely to "just work" every time when the VM is restored.
By "no external dependency" I mean that special software is not required to receive the backup data on the other side, no need for something like borgbase or setting up your own borgbackup server. Its just files, they can be rsync'd or even live on object storage like backblaze b2 for example.
> why package an app as a VM instead of a [docker container]?
I didn't say package apps as vms. I think docker (like what coop cloud uses) is way better for that.
But vms are probably a better way to manage the operation of a collection of containers, more holistic backup that's easier to "lift and shift".
Long term my plan has been to make a coop cloud image for capsul, and potentially even make a web ui for coop cloud.
So its not vms instead of coop cloud, its coop cloud inside a VM.
I think thats how the coop cloud backups work?
The docker configs get backed up somehow and then the contents of the docker volumes get borgbackuped . similar to yunohost but probly cleaner due to the containerization
@forestjohnson I need to spend some more time with coop cloud, but maybe the thing I most want then is just a web UI that could streamline and handle coop cloud deployments (+ backups & migrations) across multiple machines
@notplants side note: p4u1 from @klasse_methode just raised that abra app move should be well supported: https://git.coopcloud.tech/toolshed/abra/issues/586
oh funny coincidence. yes we are on the same wave.
I just had to do this with yunohost for a couple apps and it was a big headache (many manual steps, restore didn't work as planned, repeating everything)... eventually finished the migration.. but was such a headache... imagining the `abra app move <domain> <server>` command sounds like just what I needed and very relieving
@forestjohnson
I feel like having VMs and backups of those VMs sounds like a good part of the stack, but maybe also a side quest from the app-specific backups that I think are also really necessary for portability
e.g. if there is a server or VM that has a few different services on it, that needs to get split up (maybe an individual is taking one of those services elsewhere)
vm-level backups and restoration sounds particularly helpful if something breaks, and you just want to go back to where you were, or you just want to switch hardware
but I think having app-specific backups as first-order parts of the system that you can really depend on for being easily migrated and restored is just as important a feature