Exploring Redis Cache With Docker Using ASP.NET Core - Part Two

It is used to define the working directory of the docker container. Commands such as ADD, COPY, RUN, CMD, and ENTRYPOINT can be executed in the specified working directory.

If the WORKDIR command is not written in DockerFile then in that scenario, the docker compiler will automatically create it for you. It can be concluded that WORKDIR is similar to MKDIR and cd.

In the above line, we are instructing Docker to create a working directory as an app, if the directory doesn't exist.

It is used to inform Docker about the container listening on the specified network port.

We are exposing port 80(HTTP) and port 443(https) for our container.

You might be wondering why we need SDK when we already have the run-time image. Correct? The answer is that we are using a multi-stage build.

Now the question arises, what is multi-stage build? The idea being, to “build” your project you need a different set of things. But to “run” your built code, you need a different set of things.

For instance, a .NET core application can be built using microsoft/aspnetcore-build base image whereas, microsoft/aspnetcore can be used to run the application.

Here we are copying our project to the current directory.

By using the RUN dotnet restore command, we are instructing NuGet to restore all the dependencies that are specified in the project.

The "COPY . ." copies the entire project recursively into the container for the build. The main reason behind the separation of two copy commands with dotnet restore and then the complete copy command with dotnet build is a Docker caching trick to speed up the builds. It is done this way to avoid the installation of project dependency upon every code change.

Here, we are publishing the .net core application in the release mode.

The above command is used to copy the contents of the output directory from the publish stage into the root directory of our run time stage.

It allows you to configure a container that runs as an executable. You can consider ENTRYPOINT to be similar to CMD as it allows you to specify the command with parameters.

The Docker build command builds the Docker image from the DockerFile. Here's the command for Docker build

You need to execute this command from the directory in which the DockerFile exists.

This will generate an image that will be stored on your local machine. You may see a list of all the images installed by running:

docker image ls

docker run -p 32768:80 rediscachedemo:v1

Here, the application running on rediscachedemo:v1 image and publishing the container's port to host on port number 32768.

After running an application, you will get an error stating "unable to connect on localhost:6379". The error seems to be reasonable because on one hand, Redis is running in different containers whereas, our application is in a different container. With this logic in place, our application cannot connect with Redis using localhost

In order to make our application work, you need to specify the Gateway IP address of Redis in the connection multiplexer. You can get the Gateway details by running:

Now lets modify our code in the Startup.cs