feat(extractors): Add support for oci-containers

[Swarsel]

This adds support for rendering docker/podman containers. The implemention proposed here is far less sophisticated then what is presented in #81; this simply renders these containers as seperate guest nodes and does not try to lookup the container image. In fact, no assumptions are made on running services at all. The assumption would be that the user then defines the services running on the container node manually.

I thought about the last point for a long time, but I have the feeling that most approaches for automating this would either be not be very accurate at all (e.g. assigning services based on container name) or would only work perfectly with a lot of extra effort (which might be the case in the solution used in #81; at least from my testing, that one fails to pick up most of the containers that I run in my infrastructure)

I show image, port, and volumes info about the container in the host tile; this is done by reading out the details of a hidden service that is defined on the guest. I guess there is a cleaner solution, but at least this did not require major changes in the code.

Preview:

[oddlama]

I'll have to compare this to #81 to get a better understanding of the differences. Any idea why #81 fails to pickup your containers?

I think matching image names is hard, but if the container is a nixos container then we should be able to propagate services collected by a topology module inside the container to the outside similar to how it's done for microvms.

Maybe a "best effort" hybrid approach would be possible?

[Swarsel]

I'll have to compare this to #81 to get a better understanding of the differences. Any idea why #81 fails to pickup your containers?

I need to check it out again, I was not able to do deep testing because of the changed structure of the PR which does not allow for completely pain-free rebasing. Could be that it did not check against the correct registries, but cannot say for sure right now.

I think matching image names is hard, but if the container is a nixos container then we should be able to propagate services collected by a topology module inside the container to the outside similar to how it's done for microvms.

Wait, I am a little confused now. I think we already provide support for "standard" nixos containers? The containers in virtualization.oci-containers (which is what this PR is for) will not expose parsable service definitions to the configuration - but possibly I am missing what you are getting at!

[johnspade]

I've rebased #81 if you want to try it again. It should output a list of containers that could not be matched:

trace: oci-container extractor: UNMATCHED containers → immich-folder-album-creator (salvoxia/immich-folder-album-creator:0.15.0), immich-postgres (tensorchord/pgvecto-rs:pg14-v0.2.1), immich-redis (redis)...

I added common image names (official, LinuxServer...) for the existing list of services, registries are not checked, only repository and name. Anyway, the idea is that you can easily declare additional repositories in your configuration if needed: topology.serviceRegistry.postgresql.oci.repos = [ “postgres” ];.

I'm excited about the image name matching approach because you can get a ready-made list of services out of the box and easily add custom ones. Also I've since moved to quadlet-nix, adding a new extractor for it based on #81 would be (almost) free.

I'm open to a hybrid approach, just not sure what it might look like yet.