Why does docker image rebuild every time when running an ASP.Net Core application using Dockerfile?

I'm using Rider 2023.2.1 to run an ASP.Net Core 7 application from a Dockerfile, with the “Fast Build” feature. Every time I run or start debugging, the container image is rebuilt. The entire process, in my case, takes around a minute, and makes the feature nearly unusable, since it takes upwards of  a minute to start the app, or relaunch after making changes.

Shouldn't the image only be rebuilt if I make changes to the Dockerfile? I have a pretty standard multi-stage build setup, and I have verified that the image created when Fast Build is used is only using the “base” stage. The base stage is defined as follows, so the image should be cached, and not need to be rebuilt unless I make a change to the Dockerfile right?

FROM mcr.microsoft.com/dotnet/aspnet:7.0 AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443

 

Each time I run or debug, I see output similar to the following in the container Build Log, regardless of whether or not I've made any changes to the base stage build.

Deploying '<unknown> Dockerfile: MyProject/Dockerfile'…
Building image…
Preparing build context archive…
[==================================================>]17803/17803 files
Done

Sending build context to Docker daemon…
[==================================================>] 315.5MB
Done

Step 1/4 : FROM mcr.microsoft.com/dotnet/aspnet:7.0 AS base
 ---> 75bbe6a90eb8
Step 2/4 : WORKDIR /app
 ---> Using cache
 ---> 5ba930f4c5bd
Step 3/4 : EXPOSE 80
 ---> Using cache
 ---> 5c35c21ac5c4
Step 4/4 : EXPOSE 443
 ---> Using cache
 ---> 19e79ec81a87

Successfully built 19e79ec81a87
Successfully tagged myproject:dev
Creating container…
Container Id: f3e5429b3f9191b8e38556edb6de6842f5405cf48fd7579815c27c0caa828cd7
Container name: 'myproject'
Starting container 'myproject'
...

 

FWIW, the “Preparing build context archive…” and “Sending build context to Docker daemon…” steps are the ones that take a long time.

0
4 comments

Hello,

From your build log you are already running under Docker Fast Mode. 
In the Docker Fast Mode, only base stage of the dockerfile will be executed. Applicaiton will be complied locally and will execute by mounting the folder into the container. 
When changing the bind mount configuration of the container, docker will rebuild it.
You can compare the time spent with disabling Docker Fast Mode.  This instruction introduces how to modify docker debug configurations.
We also have a blog that introduced How Docker Fast Mode Works in Rider, hope it will help you.

Regards,

Tao

0

Tao Sun thank you for the reply. I do not want to disable Fast Mode. I want to use it to help work locally with containers.

I understand that if the volume/bind mount changes, then the container needs to be rebuilt. But my issue does not have to do with rebuilding the container, which is very fast, but with rebuilding the image. Rider appears to be rebuilding the image every time, and it is quite slow. Why should the image, which is simply based on the “base” stage from the Dockerfile build, need to be rebuilt if my Dockerfile has not changed?

 

Notice that this output appears every single time I use a “Dockerfile” launch configuration to run my application, even if I do not touch the Dockerfile at all. The “Preparing build context archive…” step is the one that generally takes the longest (typically 30-45s in my case)

Building image…
Preparing build context archive…
[==================================================>]17803/17803 files
Done

 

I have done a very similar setup using docker-compose, instead of launching directly with the Dockerfile, also using Fast Mode, and I do not experience the same problem. When using docker-compose, everything builds and launches very fast. Why should running from a Dockerfile, without docker-compose, not be equally as fast?

0

Hello,

If you use the default dockerfile for Fast Mode, the image will not be rebuilt every time. It will be reused for building new containers.
You can check the image ID in Rider's Services tool window or Docker Desktop, if the application image has been rebuilt, the image ID will be changed. 

By creating a simple new ASP.NET Core solution in Rider (with Docker support enabled), will you see the image ID been changed every time run your code in Rider?

If you still can see the image ID has been changed when click Run button in Rider (with Fast Mode enabled), please provide a sample project that can reproduce the issue, and your Rider/Docker version information.


I will try it on my machine to isolate whether the issue relates to Docker settings or Rider.

Regards,

Tao

0

Tao Sun ,

Perhaps I described/framed the issue incorrectly. Rider may not be rebuilding the image each time, but what is happening each time is the “Preparing build context archive” step is run:

Preparing build context archive…
[==================================================>]17803/17803 files

The problem seems to be that for larger projects, with 1000s of files, the “Preparing build context archive” step is quite slow. Like I said, it typically takes 30-45s for me, and it was looking at over 17,000 files (a few hundred MB in size).

If I use docker-compose to launch a container, the “Preparing build context archive” step does not seem to happen every time, so subsequent launches after the image is initially built are very quick.

I also tested by running docker build from the command line, to rebuild the image, and this was incredibly fast as well, since Docker had already cached everything locally, and nothing had changed. I used the --target=base option to simulate what would happen with fast mode enabled.

I did put together a very basic ASP.Net Core project and solution, which you can download using the link below, but it does not demonstrate the issue very well at all. That's because the build context only contains 51 files, and is just a few KB in size. The “Preparing build context archive” step does run each time, but it is nearly instantaneous, where on a larger project, with a larger build context, it certainly is not.

https://drive.google.com/file/d/12JafPk_tfELOYhVByJeF-ENjYTvQ6BQ5/view?usp=sharing

0

Please sign in to leave a comment.