[BUG] New scale down sorting is done in the wrong order for the logic of stopping containers that occurs afterwards #11460
Description
Description
Seeing this feature was added i've updated to the latest docker engine and compose versions and tried including this in our deployment scripts. I've found though if i scale up to 2 instances, then scale down to 1, the newest container is the one that's removed.
I believe from looking at the code (bare in mind i don't ever work with go so apologies if i've missed anything obvious) the issue seems to be we're sorting the list of containers in ascending date created order. After this, we loop through and if the collection index equal to or above the desired scale number, we remove the containers, so new ones are removed instead of older containers.
To resolve i'm guessing the sort could be improved to sort by date descending?
The sort logic:
sort.Slice(containers, func(i, j int) bool {
return containers[i].Created < containers[j].Created
})The loop following:
for i, container := range containers {
if i >= expected {
// Scale Down
container := container
traceOpts := append(tracing.ServiceOptions(service), tracing.ContainerOptions(container)...)
eg.Go(tracing.SpanWrapFuncForErrGroup(ctx, "service/scale/down", traceOpts, func(ctx context.Context) error {
return c.service.stopAndRemoveContainer(ctx, container, timeout, false)
}))
continue
}
...Steps To Reproduce
- Create a compose file with single service and no scale options set, then run compose up to launch the container.
- Use
docker compose up --scale (service-name)=2which will launch a second container for the same service. - Now this has been confirmed to be running, scale back down to 1 instance.
- The newer container is removed.
Compose Version
Docker Compose version v2.24.5
Docker Environment
Client: Docker Engine - Community
Version: 25.0.2
Context: default
Debug Mode: false
Plugins:
buildx: Docker Buildx (Docker Inc.)
Version: v0.12.1
Path: /usr/libexec/docker/cli-plugins/docker-buildx
compose: Docker Compose (Docker Inc.)
Version: v2.24.5
Path: /usr/libexec/docker/cli-plugins/docker-compose
scan: Docker Scan (Docker Inc.)
Version: v0.23.0
Path: /usr/libexec/docker/cli-plugins/docker-scan
Server:
Containers: 37
Running: 37
Paused: 0
Stopped: 0
Images: 38
Server Version: 25.0.2
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Using metacopy: false
Native Overlay Diff: true
userxattr: false
Logging Driver: json-file
Cgroup Driver: cgroupfs
Cgroup Version: 1
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
Swarm: inactive
Runtimes: io.containerd.runc.v2 runc
Default Runtime: runc
Init Binary: docker-init
containerd version: ae07eda36dd25f8a1b98dfbf587313b99c0190bb
runc version: v1.1.12-0-g51d5e94
init version: de40ad0
Security Options:
apparmor
seccomp
Profile: builtin
Kernel Version: 5.4.0-146-generic
Operating System: Ubuntu 20.04.6 LTS
OSType: linux
Architecture: x86_64
CPUs: 8
Total Memory: 14.64GiB
Name: dev-03
ID: 8b38f69f-2080-40b4-b7d8-2486ef736685
Docker Root Dir: /var/lib/docker
Debug Mode: false
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
WARNING: No swap limit support
Anything else?
No response