Repository navigation
docker compose up no longer recreates container if image is updated #9259
Description
Description
As of v2.3.0, running docker compose up -d will no longer recreate containers whose images have been updated. Previously a docker compose pull; docker compose up -d would ensure all containers in the compose file were running the latest images.
Steps to reproduce the issue:
- Create a simple compose file:
version: '3.5'
services:
test:
image: some-registry/image
restart: always
- Start the container with
docker compose up -d - Push a new image to the registry
docker compose pulldocker compose up -d
Describe the results you received:
The pull step pulls the updated image, but up -d does nothing.
Describe the results you expected:
The pull step pulls the updated image, then up -d recreates the container using the new image.
Additional information you deem important (e.g. issue happens only occasionally):
Bisect shows b5b8e7a as the first bad commit. In this example I am running a container with a version=8 label, but have pushed a new image to the registry with version=9:
$ git checkout b5b8e7a116ccd8a9183c6661589b1c051fca17d9
Previous HEAD position was 16914e37 Bump compose-go 1.1.0
HEAD is now at b5b8e7a1 exclude com.docker.compose.image label from service hash
$ docker-compose pull; go run ./cmd/ up -d; docker inspect compose-test-1 | grep '"version"'
[+] Running 1/0
⠿ test Pulled 0.1s
[+] Running 1/0
⠿ Container compose-test-1 Started 0.0s
"version": "8"
$ git checkout b5b8e7a116ccd8a9183c6661589b1c051fca17d9^
Previous HEAD position was b5b8e7a1 exclude com.docker.compose.image label from service hash
HEAD is now at f7a6c3bc Bump github.com/containerd/containerd from 1.5.8 to 1.6.0
$ docker-compose pull; go run ./cmd/ up -d; docker inspect compose-test-1 | grep '"version"'
[+] Running 1/0
⠿ test Pulled 0.1s
[+] Running 1/1
⠿ Container compose-test-1 Started 0.4s
"version": "9"
You can see with commit b5b8e7a the container isn't recreated (it takes no time and still has the version=8 label) but as of the commit immediately prior to that the container is recreated as expected.
Output of docker info:
Client:
Context: default
Debug Mode: false
Plugins:
buildx: Docker Buildx (Docker Inc., v0.7.1-docker)
compose: Docker Compose (Docker Inc., 2.3.0)
Server:
Containers: 591
Running: 67
Paused: 0
Stopped: 524
Images: 1121
Server Version: 20.10.11
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Native Overlay Diff: false
userxattr: false
Logging Driver: json-file
Cgroup Driver: systemd
Cgroup Version: 2
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
Swarm: inactive
Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 1e5ef943eb76627a6d3b6de8cd1ef6537f393a71.m
runc version: v1.1.0-0-g067aaf85
init version: de40ad0
Security Options:
seccomp
Profile: default
cgroupns
Kernel Version: 5.15.7-arch1-1
Operating System: Arch Linux
OSType: linux
Architecture: x86_64
CPUs: 12
Total Memory: 62.79GiB
Name: hetzner2.fi.929w.net
ID: G7J4:PHCS:XKMI:GIGZ:E5J4:IDDW:3CAF:UCDG:SV3Y:VZGO:ERHR:LSZV
Docker Root Dir: /var/lib/docker
Debug Mode: false
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
Activity
csmith commentedon Mar 9, 2022
cc @ndeloof
StewGoin commentedon Mar 10, 2022
Also seeing this behavior on Debian 11 w/ docker-compose from this project and docker repo from docker.com.
Output of my
docker info:dtcooper commentedon Mar 10, 2022
Observing this behaviour on Ubuntu 20.04 as well. Rolling back to version 2.2.3 (latest pre-2.3.x version) fixes the problem for me.
ndeloof commentedon Mar 10, 2022
Looking into this ...