Closed sweenu closed 2 years ago
Same problem here and didn't find a solution yet
I suspect what's going on is docker-compose
has started to resolve symlinks before guessing the project name.
Getting any information from outside the repo is a bad idea, and in the Nix space that includes baseNameOf (dirOf ./.)
and, sadly, ./.
at the root of a repo, as that also has the directory name, which is unreliable. Anyway, now I'm just rambling. I think we should make project.name
mandatory and solve this once and for all.
https://github.com/hercules-ci/arion/pull/157 sets it automatically for the NixOS module. Could you give that a try?
Unfortunately on my 3 projects, the name is already set but it still results in 3 networks named the same way and thus ambiguous.
I also tried that
system.activationScripts.mkServicesNetwork = let
docker = config.virtualisation.oci-containers.backend;
dockerBin = "${pkgs.${docker}}/bin/${docker}";
in ''
${dockerBin} network inspect services_network >/dev/null 2>&1 || ${dockerBin} network create services_network
'';
It creates the network before the container but it also display a warning about not finding the CNI plugins
This seems like a docker-compose problem more than an arion problem.
You could configure the network
field, which hasn't been modeled with NixOS options yet, using docker-compose.raw.
Something like this:
# arion-compose.nix (or an imported module)
{ config, ... }: {
config.docker-compose.raw.networks.default.name = config.project.name;
}
Unfortunately it does not work either. I need the services of the 3 projects to share the same network.
I wonder if the problem is not coming from the fact the 3 systemctl units are started simultaneously and docker-compose don't see that the 3 projects are creating the same network. For the moment with the previous snippet I got this warning but the network is correctly created:
WARN[0000] Error validating CNI config file /etc/cni/net.d/services_network.conflist: [failed to find plugin "bridge" in path [/usr/local/libexec/cni /usr/libexec/cni /usr/local/lib/cni /usr/lib/cni /opt/cni/bin] failed to find plugin "portmap" in path [/usr/local/libexec/cni /usr/libexec/cni /usr/local/lib/cni /usr/lib/cni /opt/cni/bin] failed to find plugin "firewall" in path [/usr/local/libexec/cni /usr/libexec/cni /usr/local/lib/cni /usr/lib/cni /opt/cni/bin] failed to find plugin "tuning" in path [/usr/local/libexec/cni /usr/libexec/cni /usr/local/lib/cni /usr/lib/cni /opt/cni/bin]]
# arion-compose.nix (or an imported module) { config, ... }: { config.docker-compose.raw.networks.default.name = config.project.name; }
Thank you for this, it got it working for me.
Working flake example using it: https://gitlab.com/nix17/nixos-config/-/blob/e05b36eeaff0cfbbfb38e5d32822e66d33fb7725/apps/games.nix
I've updated master to manage the project name better and assign it to the default network name.
It shouldn't be necessary to use the previously shared snippet anymore.
So, just to be clear, this is kind of a breaking change, right? Because they all used to share one network, now they have their own.
@sweenu that is correct.
I've updated the changelog to stress this. https://github.com/hercules-ci/arion/blob/master/CHANGELOG.md
The old behavior was quite counter-intuitive, which is why I believe this breaking change is a net positive. It does not solve your original problem; actually makes your setup a bit harder and I'm sorry for that.
It seems that your problem is caused by a race in podman or docker-compose that allows three identically named networks to be created. This seems like something to be fixed in those tools, although perhaps it's possible to work around it by ordering and delaying their startup with systemd configuration.
Okay yeah, that makes sense. It did work out pretty well for me, but I was confused by the fact that the network was the same for all.
@roberth Coming back to this, there seem to be a one-one relationship between the Arion project and the docker-compose project. I cannot have an Arion project with several docker-compose projects. For example I have this:
virtualisation.arion.projects.homelab.settings.project.name = "homelab";
It's redundant. I'd rather the project name be by default the name of the Arion project or not have an Arion project notion at all. Having both is quite confusing.
@sweenu
For example I have this:
virtualisation.arion.projects.homelab.settings.project.name = "homelab";
This line shouldn't be necessary because it already get that value as a default here
I'd rather the project name be by default the name of the Arion project or not have an Arion project notion at all.
To run an arion project stand-alone using the CLI without putting it in a NixOS config, we'll still need the option.
Oh I see. That works well for me then! It is a bit confusing that in the doc it says there is no default https://docs.hercules-ci.com/arion/options/#_project_name.
I think we can close this issue as it is not a problem with Arion and we won't have that behavior by default anymore.
I have three different projects:
virtualisation.arion.projects.traefik
virtualisation.arion.projects.authelia
virtualisation.arion.projects.nextcloud
And when I rebuild, none of the containers are up because of the following error:
When I list docker networks,
store_default
appears three times. Strangely enough, I've never had this problem on my previous install, only onestore_default
network was created and used by my containers. If I restart the service one by one manually, it fixes the issue.