Option to disable Stack compose pull command

[FibreTTP]

I've built an image locally with changes made and tagged it simply as xmrig:v6.21.3. With image: xmrig:v6.21.3 set in the Compose File, the docker compose pull command issued by Komodo when deploying a Stack rightly cannot pull this image as it is not on any online repository (normally available at ghcr.io/metal3d/xmrig):

 xmrig Pulling 
 xmrig Error pull access denied for xmrig, repository does not exist or may require 'docker login': denied: requested access to the resource is denied
Error response from daemon: pull access denied for xmrig, repository does not exist or may require 'docker login': denied: requested access to the resource is denied

This only occurs because of the pull command. The local image is usable with normal Docker Compose.

For reference, this is where the pull command is issued:

komodo/bin/periphery/src/compose.rs

Lines 145 to 159 in 796bcac

	// Pull images before destroying to minimize downtime.
	// If this fails, do not continue.
	let log = run_komodo_command(
	"compose pull",
	format!(
	"cd {run_dir} && {docker_compose} -p {project_name} -f {file_args} pull{service_arg}",
	),
	)
	.await;
	if !log.success {
	res.logs.push(log);
	return Err(anyhow!(
	"Failed to pull required images, stopping the run."
	));
	}

[mbecker20]

Thanks for pointing this out, I missed this as I always use self hosted Gitea as my image registry. This fix should be very straightforward, I will whip up 1.14.1 with the fix shortly.

[mbecker20]

Just considering this more, is it possible to have the compose file build the image?

like:

services:
  xmrig:
    build:
      context: /path/to/context
      dockerfile: /path/to/xmrig.Dockerfile
   ...

Then you use --build "Extra Arg"

[FibreTTP]

That is possible, yes. The command printed is cd /etc/komodo/stacks/xmrig-xmrvsbeast/docker-xmrig && docker compose -p xmrig-xmrvsbeast -f compose.yaml up -d --build (I used Files on Server). It didn't actually "build" since it was cached from before, but there were no errors, and the container started.

Before I was using Komodo, I always built the image manually beforehand (outside of the compose file), but I guess this is the proper way to do it.

Not that I'm actually going to do that. It's a single container anyway so I'm now using the Deployments feature in conjunction with the Builds feature that you've implemented (which is pretty cool). The only reason I was using it in Compose, was because Dockge only supported Compose.

[FibreTTP]

I think you should actually disable that pull command entirely, since Compose files have a pull policy that should be respected (and the up command takes care of it).

[mbecker20]

I think both cases may be useful. Many users will expect redeploy to get them to the latest version if they are using the latest tags and many won't use pull policy. Anyways, the fix I had in mind is another configuration field for Stack entity, auto_pull: boolean, which will determine if the pull command is executed before deploy.

The other reason it is nice to manually pull is to minimize the stack downtime during redeploy. Since the Stack must be composed down before the next compose up, it is best to:

1. compose pull latest images
2. compose down
3. compose up

Anyways you are correct this behavior should be able to be turned off. Thanks for the feedback and I will add this is 1.14.1 patch releasing soon.

[FibreTTP]

Thanks for implementing! If you're still considering what to make default, I'd say False, as the default for Compose is to only pull if missing.

[mbecker20]

This is implemented in 1.14.1, just released: https://github.com/mbecker20/komodo/releases/tag/v1.14.1. It does default Auto Pull Images to true, as I do believe most users want this.

[FibreTTP]

Works!