Container doesn't have code changes, image does - docker

Question

Yes, this question has been posted before. Yes I've applied the relevant solutions and ignored the irrelevant ones. I just don't understand what is going on here.
Problem: I make change to my source code by modifying the default return message. I COPY the src tree into my baseImage (multi-stage builds). I build a stagingImage from the baseImage. The baseImage has the code change but the container running the stagingImage returns the pre-code-change message. I've replicated this behavior on MacOs (Catalina) and Amazon Linux 2.
Note that I am doing this manually, i.e. I'm not relying on IDEs and inotfy-s and the like. The only tools involved are the CLI, vim, make and docker(-compose).
Details: I have a Dockerfile that is capable of doing multi-stage builds. Here's the relevant part of the baseImage build:
COPY ./composer.json /var/www/html/composer.json
COPY ./php-apache/auth.json /root/.composer
COPY ./ /var/www/html
and here's a sample of how I build my other images :
FROM php:7.4-apache AS cleanImage
COPY --from=baseImage / /
FROM cleanImage AS stagingImage
COPY ./.env.staging /var/www/html/.env
RUN /bin/bash -c 'rm -rf /var/lib/apt/lists/*'
# Set entrypoint
CMD ["-D", "FOREGROUND"]
ENTRYPOINT ["apachectl"]
I modified the Makefile from Chapter 10 of "Docker In Action". Here's a sample:
## image-base : Build the base image that the others are based on
.PHONY: image-base
image-base: metadata
#echo "Building Base Image"
docker image build --no-cache --force-rm --tag src:$(BUILD_ID)-base \
-f src/Dockerfile \
--target baseImage \
--build-arg BUILD_ID='$(BUILD_ID)' \
--build-arg BUILD_DATE='$(BUILD_TIME_RFC_3339)' \
--build-arg VCS_REF='$(VCS_REF)' \
./src
#echo "Built Base Image. BUILD_ID: $(BUILD_ID)"
## image-staging : Build the staging image
.PHONY: image-staging
image-staging: metadata image-base
#echo "Building Staging App Image"
docker image build -t src:$(BUILD_ID)-staging \
-f src/Dockerfile \
--target=stagingImage \
--build-arg BUILD_ID='$(BUILD_ID)' \
--build-arg BUILD_DATE='$(BUILD_TIME_RFC_3339)' \
--build-arg VCS_REF='$(VCS_REF)' \
./src
#echo "Built Staging App Image. BUILD_ID: $(BUILD_ID)-staging"
## up env=<env> : Bring up environments. env values are prod, local, staging.
.PHONY: up
up:
ifeq ($(strip $(BUILD_ID)),)
$(error BUILD_ID environment variable is not set. Run `make metadata` to generate one)
endif
docker-compose -f docker-compose.yml -f docker-$(env).yml up -d
Where BUILD_ID is of the form YYYYMMDD-epoch-git_SHA. Note that the baseImage uses the --no-cache flag.
So far, so good (I think).
My `docker-compose.yml``` file looks like this:
version: '3.7'
volumes:
web_app:
services:
php-apache:
logging:
driver: "json-file"
options:
max-file: "5"
max-size: "10m"
volumes:
- web_app:/var/www/html
env_file:
- ./src/.env.prod
and my docker-staging.yml file looks like this:
version: '3.7'
services:
php-apache:
image: 'src:20200924-174443-3f16358-staging'
container_name: perfboard-staging
ports:
- 8888:80
- 9261:443
env_file:
- ./src/.env.staging
Yes, I've hardcoded the name of the stagingImage for the purposes of debugging.
What I expect to see: when I hit localhost:8888 I expect to see my modified message. I do not.
When inspecting the baseImage, the modified message is there. I cannot directly inspect the stagingImage because I keep getting an Apache error presumably because of the entrypoint.
If I delete every image and container from my system, this behaves as expected.
Deleting the above specific baseIamge and stagingImage does not fix the problem.
Any ideas on where to look?

Answer 1

Your docker-compose.yml file specifies
volumes:
- web_app:/var/www/html
That causes the contents of the web_app volume to be mounted over the /var/www/html directory in the container, hiding whatever was initially in the image.
You should delete this volume declaration.
The first time only when you run the container, Docker will copy the contents of the image into an empty named volume. From that point onward, it treats the volume as user data and never makes any changes to it; even if the underlying image is updated, the volume contents are not, and when you run the container, the volume takes precedence over the updated image code.
There are a number of practical problems with depending on the "copy from an image into a volume" behavior (it doesn't work with host bind mounts; it doesn't work on Kubernetes; it causes image updates to be ignored) and I'd try very hard to avoid mounting any sort of volume over your application code.
If you think it's important to have the volume for some other reason, you need to cause Compose to delete it, so that it will get recreated and have the "first time only" behavior again. docker-compose down -v will delete all containers, networks, and volumes, but that will also include things like your database data. You might be able to use docker-compose down (without -v) to stop the container, then use docker volume ls; docker volume rm dirname_web_app to manually delete the volume.