WORKDIR in Dockerfile set to aliased volume in docker-compose is ignored?

Docker Desktop for Windows
1

I have a working docker-compose and Dockerfile but I had to put in what seems like an unnecessary step and I’m hoping someone can explain to me why its necessary and help me understand. :slight_smile:

Relevant piece of docker-compose.ylm

    build:
      context: .
      dockerfile: src/Web/Dockerfile
      target: build
    volumes:
      - C:\repos\Repo\src\Web:/app

The first part of my Dockerfile is:

FROM microsoft/dotnet:2.1-sdk AS build
WORKDIR /app

Here I would expect to be working directly in my mounted volume. However, if I simply execute a

RUN dotnet restore

It complains that the .csproj does not exist (the .csproj is in this directory).

It seems that the context setting of ‘.’ from the docker-compose.ylm is overwriting the WORKDIR command in my Dockerfile because to get my file to work I had to update this piece to:

COPY ./src/Web .
RUN dotnet restore

Which seems unnecessary and seems like I am copying files over themselves, which does not seem to be occurring.

Can anyone explain this to me? How the mounted volume alias, context setting and WORKDIR play together?

2

The build sequence runs to completion before your mounted volume is considered at all. The mounted volume isn’t part of the Dockerfile at all and nothing in the Dockerfile can see it; it may or may not be present with any particular contents when the image eventually gets run.

COPY ./src/Web .
RUN dotnet restore

I’d consider best practice to be exactly this: build and test your application locally, then COPY it into an image, run integration tests on that, and deploy that final image. This sequence doesn’t require a volumes: declaration in the docker-compose.yml; it also doesn’t require the application code to be present on the system where the image is eventually run. It also requires you to rebuild the Docker image every time you would rebuild/retest your application normally.

3

Thank you David - this was the missing piece in my understanding. The mounted volume is AFTER the Dockerfile. It makes total sense now, of course!

To satisfy my curiosity… What exactly is behavior if my WORKDIR is the same as the alias that’s being mounted? As is the case in my image. In other words, when I’m copying those files from ./src/Web to the /app WORKDIR and executing the final ENTRYPOINT of my Dockerfile and then after all of that it mounts the volume to the same alias of /app, is this going to cause any problems? Why or why not?