redis-tools | Tools to monitor Redis servers | Runtime Evironment library

Your question would benefit from your inclusion of the docker-compose.yaml file in its entirety so that we may understand what you're doing.

From what you have included, I have (not mutually exclusive) hypotheses:

Possibility #1: The image builds are probably only run once and not every time you run docker-compose. When you run docker-compose, if it finds the relevant images locally, it won't rebuild them. If you delete the local images, or you force a change, then the images will be rebuilt.

If the images aren't rebuilt, changes to the sources will not be reflected.

Possibility #2: Your Dockerfile uses ADD . /app. When this image is built, the files in your current directory (.) are copied to the image's /app folder. This only occurs during the build.

Possibility #3: You reference volumes and /app but this mount point already exists in the container image for which you included the Dockerfile (ADD . /app). I'm unsure what the consequence of this behavior is but you may be overriding the container's /app directory (which contained the files you ADD . /app). This is redundant.

It is considered to be a not good practice to change source files within a container image. One practice often used with containers is of immutable infrastructure. The idea is that, while the data may change, a container's application|process|binary does not change.

If I were given golang:1.12 today, it should always be exactly the same. If there were a change to Golang 1.12 -- even if it were one variable renamed -- the Go team would upgrade the version and create perhaps Golang 1.12.1. Then I'd expect a new container image golang:1.12.1.

This practice is not enforced by docker tags and this is one (of many) reason(s) why docker tags aren't 'trustworthy'.

The best practice is thus to rebuild an image every time a source file changes.

You will frequently see -- and it's a good mechanism -- that folks will rebuild the container images for every e.g. git commit. The hash of the commit is often used to tag the container image too but this is optional.

Containers have a namespaced network. Each container has its own loopback interface and an ip for the container per network you attach to. Therefore loopback or 127.0.0.1 in one container is that container and not the redis ip. To connect to redis, use the service name in your commands, which docker will resolve to the ip of the container running redis: