In ASP.NET Core with Docker Container – Part 1 Mounted Volume, I covered my experiment with Mounted Volume. In this post, I will explore the possibilities of Dockerfile. By reading on the internet, watching courses on Pluralsight, I know what Dockerfile is. “Know” means, well, just heard about it, saw people playing with it … on videos. Just like the first part, I want to explore it, do something with it.

I want to ship my application in a container. I want to be able to take that container and run it on another machine.

Dockerfile

I found a good article about it here by digital ocean. I feel it is too much to get started. And for a beginner, like me, it is hard to understand.

Dockerfile is a set of instructions to build a Docker image.

So the next question is what are the fundamental instructions to build an image? I always like to start with fundamental.

Fundamental Instructions

FROM

Instruct the base image we will use to build up. Docker gives you the ability to build your own image base on existing one. Think about it for a moment. We can take an existing aspnetcore-build image (which is made and maintained by Microsoft), and build our own image with some custom features.

FROM microsoft/aspnetcore-build

That’s all it takes to build your own custom image with full power of the aspnetcore-build.

MAINTAINER

It is nice to tell the docker that you maintain the image. It is you, the owner, the maintainer.

MAINTAINER thaianhduc

 

COPY

Start making your own custom image. The “COPY” instruction will tell Docker to copy a folder into a specific folder inside the container. It is the same concept as Mounted Volume, except, instead of creating a mapping, it copies the data.

COPY . /app

The above command will tell the Docker to copy the working directory into “app” folder inside the container. The equivalent in Mounted Volume is “-v ${pwd}:/app“.

WORKDIR

The directory that container will start. Think the same way when we open a Powershell or CMD in Windows. In our web application, it will be the web directory that we created in the COPY instruction.

WORKDIR /app

 

RUN

Given that the working directory, the container will run commands instructed by RUN. In our previous web application, we want to run “dotnet restore” and “dotnet run” commands. They might look like this

RUN dotnet restore

RUN dotnet run

Note: I might not want to build application inside the container. Most of the time, I want to ship my application, not source code.

EXPOSE

The port that a container exposes to the outside.

EXPOSE 8080

Which means other systems can communicate with it via port 8080.

ENTRYPOINT

All the above instructions tell Docker how to build an image. The ENTRYPOINT instruction tells containers what command to run once it starts. Let’s think about a web application scenario, once a container starts, we want to start our web server inside the container.

ENTRYPOINT ["dotnet", "Coconut.Web.dll"]

In Action

With the discovery from Dockerfile, I reframe my steps more precisely. I will/want

1. Build an ASPNET Core Web Application on my host machine with VS2017 Community.
2. Publish it to a local folder.
3. Build a Docker image with the published application in.
4. Start a container from my custom image.
5. Access my web application from host browser.

Before started, I want to make sure that I have a working website published. This should be easy done by asking VS2017 to publish my project to a local folder. By default, it will publish to bin\Release\PublishOutput folder.

So given at the published folder, when run “dotnet Coconut.Web.dll“, my website is up and run. So far so good.

How about recap the Mounted Volume approach? Which means I want to run this command

At the last line, I want to start an ASPNETCORE container to host my published application. Shall it work? Let’s find out.

It looks ok. Except, I cannot access the website from host browser. Which means something was wrong; well not a surprise at all. Turn out I made the wrong port mapping. It should be port 80 inside Container instead of 8080.

docker run -t -p 5000:80 -v ${pwd}:/app -w /app microsoft/aspnetcore bash -c "dotnet Coconut.Web.dll"

Create Dockerfile

A Dockerfile is a simple text file. You can create it with any your favorite editor.

# Custom image based on aspnetcore to host a web application
FROM         microsoft/aspnetcore
MAINTAINER   Thai Anh Duc
COPY         . /app
WORKDIR      /app
ENTRYPOINT   ["dotnet", "Coconut.Web.dll"]

For naming convention, I name it Dockerfile. I use VS2017.

Build a Custom Image

So far I have created a published application and a Dockerfile. Things seem ready. Next, we need to tell Docker to build an image from the Dockerfile.

The current folder structure looks like this

\bin
    \Release
            \PublishOutput
Dockerfile

Let’s try to run my very first build command. However, it failed right after build. Because that folder structure will cause some security issues. To make my life easy, I move the Dockerfile into the PublishOutput folder.

docker build -t thaianhduc/aspnetcore:0.1 .

Hey Docker, take the default Dockerfile at the current location (where the command is run), build an image, give it a name “thaianhduc/aspnetcore” and tag it with version “0.1”.

Do not forget the “.” at the end. It represents for “current location“.

// Run the command to list all the images. The new image should be there
docker images

Run It

Time to enjoy the fruit

docker run --name my-coconut -p 5000:80 thaianhduc/aspnetcore:0.1

Open the browser on my host machine, type in http://localhost:5000/hello_beautiful. Oh yeah! It works.

A Few Words

I have failed many times while experimenting and writing the post. Everything seems easy while you read it on the internet. However, when it gets down to actual do it. Evil hits your face at the first try. But that is actually a good thing. I have learned so much while trying to solve those problems. Some of them I understand, some I do not.

So far I have been playing around with the fundamentals of Docker. For every single command, for every single action, I try to explain to myself in my own language. The language that I can understand and explain to other.

Having small goals at the beginning keeps me focus. It allows me to temporary ignore some problems. Otherwise, you will wonder in the sea of information out there. Reading something is easy. Making something works for you is hard.

How do I take my custom image and use on other machines? Easy. I can push my image to Docker hub. Then I can run it just like other images. Things make sense now. I can resonate without effort.

Deployment Options Recap

I started with learning ASP.NET Core and other new cool stuff. I want to learn about the infrastructure that I can take advantages of. Let’s assume that I have a web application, how many options do I have to deploy it?

1. Local host (IIS): Obviously I can simply press F5
2. Deploy to Azure for free.
3. Run it inside a container using Mounted Volume approach.
4. Or deploy it as a Docker Image.

What’s Next?

I want to step further into the ASP.NET Core, from a fundamental point of view. Maybe later in the series, explore the possibilities of Docker in term of Microservices.

That would be fun!

 

Now that I finished the flow to push the code from my laptop up to the Cloud. I also started to play around with Docker; also a bit of ASP.NET Core. I have many dots. The next challenge, as always, is to connect them. Try to make sense from all pieces. Let’s focus a bit more on Docker; create a connection between Docker and ASP.NET Core.

There are many materials about Docker. It is easy to start playing around with Docker, as I wrote here. Pretty basic stuff. It is easy to find out how to run a command. The Docker website has an extensive documentation, which tells you everything you need to know about Docker.

But, to me, It is useless if I cannot make sense of “the why”. After playing around with commands, watching some courses (mostly from Pluralsight), I have to find the answer for questions

1. Why do I need it?
2. What problems does it solve?

I try to create an image of it in my mind. It is such an important step, that if I fail, I cannot continue. Just like, how can you run if you do not know why and where to run!

So let give it a try before moving deeper into the implementation detail.

Why Docker? Container Approach

I would like to call it “Container Approach“. Below are some benefits, in my opinion, that give me good reasons to invest in.

Improve Cooperation

If we develop small systems which are easy to setup and deploy, the need of Container might not be obvious. Because, as a developer, we can check out the code, hit F5 and we are good to go. If we want to deploy those systems to QA’s machine or some sort of central servers, it is still a trivial task.

However, when systems are big where there are many services, require complex infrastructure, things get complicated quickly and cost lots of time. Take an example of a web application. I would assume the system consists of

1. Front end application: Build on top of AngularJS. This application will connect to a backend service via WebAPI endpoints.
2. Backend service: The backend service built with ASP.NET Core. It supplies endpoints that Front end application will consume.
3. Database: SQL family server. Can be SQL Server, SQL Express, SQLight, or MySQL. Use EF as Data Access Layer (ORM).

The team consists of Frontend Developer, Backend Developer, and Tester. Each might have to install the same infrastructure to run the application. Given that we have not had a central deployment place yet. It means that

1. Front end developer has to install all requirement software, infrastructure, that only Backend Developer required.
2. Back end developer has to install the things that only Front end developer needs.
3. Tester has to install development environment even they do not know about coding. They might have to setup local IIS.

When a new member joins the team, there are so many repetitive works.

What if

1. Front end developer will take the api component, and load it up on his machine without installing anything. He will focus on building the cool frontend, and connect to that API.
2. A tester will take the application as a whole, and run it with a single click, without installing anything.

With a proper developed, Docker can help.

Develop Faster, Test Faster

Docker will give us the minimum-required infrastructure we need to build and test an application. For example, when I want to develop a system running with MongoDB. Instead of downloading and installing MondoDB locally, I can get a prebuilt docker image with MongoDB installed.

The ability to switch infrastructure gives developers a lot of flexibilities.

Develop Componentized Thinking

This might not be true for others. However, it works for me. I shape my thinking process. A system composes of many small components. Each component might run in a Container. This, in turn, will force me to think, what should I put in a single container.

What’s Next?

I try to make sense of Docker, try to explain it to me. I do not make any suggestion or judgment regarding its benefits. But will all those in mind, I am ready to invest more in the journey.

Docker helps

1. Improve cooperation
2. Develop faster, test faster
3. Develop componentized thinking

The next step is, as usual, to try things out. Connect the dots between Docker and ASP.NET Core. This post intended to write about it. However, I changed the intention as I wrote.