Duplicated compose stack while using swarm

[AndBondStyle]

Bug description
When image is built using docker compose, it is assigned compose-specific labels like com.docker.compose.project, com.docker.compose.service and others. And when the same image is used with docker stack deploy, the resulting swarm-managed container also inherits those labels (alongside with swarm labels like com.docker.swarm.service.name). This results in portainer displaying two stacks: swarm and compose, with shared container instance inside them. I think it's at least annoying and confusing (and probably conceptually incorrect), because compose can't manage swarm containers and vice versa, therefore for any given container there always should be only one stack that it belongs to? My suggestion is to add an exclusion condition when assigning stacks, so if there is com.docker.swarm.* and com.docker.compose.*, swarm should take priority, and be the only one stack that's displayed.

Example of mixed container labels (built with compose, deployed with swarm):

"Labels": {
    "com.docker.compose.project": "datacatalog-proxy",
    "com.docker.compose.service": "proxy",
    "com.docker.compose.version": "2.12.2",
    "com.docker.stack.namespace": "proxy",
    "com.docker.swarm.node.id": "qfh192k2xfiij1pbekm00a0cs",
    "com.docker.swarm.service.id": "m9ysqkpj2l0yv9a2ciws0jroo",
    "com.docker.swarm.service.name": "proxy_proxy",
    "com.docker.swarm.task": "",
    "com.docker.swarm.task.id": "rkqn2mlvys6hdbzwml3smngq5",
    "com.docker.swarm.task.name": "proxy_proxy.1.rkqn2mlvys6hdbzwml3smngq5"
}

Steps to reproduce the issue:

1. Build and push any image with docker compose build + docker compose push
2. Deploy to swarm with docker stack deploy ... (using the same compose file is probably the most common scenario)
3. Open Portainer > Stacks, see two stacks displaying instead of one

Technical details:

• Portainer version: CE 2.18.2
• Docker version: 24.0.1 (swarm, rooted)
• Platform: ubuntu 22.04
• Command used to start Portainer: as per docs (CE + swarm)

[tamarahenson]

@AndBondStyle

Thank you for the information. I am going to further investigate. I will update you as I learn more.

Thanks!

[samdulam]

@AndBondStyle
This is a known issue and there is no workaround ATM. Because Portainer uses the same label com.docker.compose.project to detect stacks on the host.
Some of our other users moved to docker build instead because of this.

[AndBondStyle]

@samdulam that doesn't conflict with what I said. As a workaround I suggested that, if container has both com.docker.compose and com.docker.swarm labels, it should be detected as a swarm only stack. Or at least provide such option in portainer settings, maybe. Moving to docker build sounds awful, as a temporary fix I can suggest using something like docker-copyedit to remove compose labels after docker compose build.

[samdulam]

@AndBondStyle
Yup, makes sense for Swarm. I'll raise it product.

[giorgiotobia]

hello
is there any update on this topic?
I have the same issue since i upgraded my swarm to a "contemporary" docker version, i was previously on docker 1.13 (rhel 7 packages)
Now all the stacks that use images built with "docker compose build" have this "com.docker.compose.project" label and if this label value is not equal to "com.docker.stack.namespace" value portainer shows two stacks, one swarm type and the other compose type.
it should be better that portainer would not use label "com.docker.compose.project" to list anything under "Stacks".

"com.docker.stack.namespace" is working well for that.

[samdulam]

This is in our backlog and no ETA at this stage.

Internal Ref: PCT-116

[ismaail]

is there any update on this topic?

[felegy]

An other workaround, use classic builder with docker compose build.

DOCKER_BUILDKIT=0 docker compose build

[jliebert]

This is very confusing on Swarm, I have my container displaying wrong stack as com.docker.compose.project, my service with correct com.docker.stack.namespace, stack duplicated with com.docker.stack.namespace and com.docker.compose.project.

I understand that we can have mixed environment but it should deal with both correctly.

It's a bug, not a feature.