Docker in a nutshell is a software program that allows you a common way to build, run and ship applications irrespective of its type, programming language, or even the resources required.

Ever since its initial launch in 2013, Docker & Containerization, on the whole, can be considered as the single biggest change in the way in which applications are being developed. It provides a mechanism that guarantees to an extent that if an application runs & functions on your machine, it will have the same behavior on any other machine

The Problems

Traditionally build applications will all have different ways in which they are shipped and deployed. For example, an application running on Java will require a jar file along with a JRE environment, for .Net based app you will need the .Net runtime environment, etc. So everything depended on how the applications were built and then they were deployed on a data center or a cloud accordingly.

And after all this, the application might not even run on the server due to issues like and not limited to

• Missing configurations
• Missing environment resources
• Version mismatch
• Missing deployable resources

The Solution

The above-mentioned problems are solved by the concept of containers and that's where Docker comes into the picture. Everything is standardized now, meaning there is a standard distribution format. And if you follow that format your application will run independently of the original application type or resources it needed.

As long as you take your application, package it in the standard global format in a Dockerfile, you are guaranteed to have standard behavior throughout.

With Docker, instead of setting up a deployment server first with all the resources, you package your application with each and everything it requires to run. You then just run the package, and everything is set up on that machine, allowing it to run as expected. If my app needs, .Net Core runtime, SQL Server 2017, Rabbit MQ, etc all these will be mentioned in the Dockerfile.

Container

Docker enables the running of applications inside a container. So let's first see what they are how they differ from a virtual machine.

Containers can be treated as an isolated process running an application. This isolated process will have all the required dependencies to run the concerned application. Dependencies such as the runtime environment, a lightweight operating system, storage, threads everything.

Containers are built from Docker Images, once they run they start the application which is hosted in them.

Virtual Machine use software like Hypervisor to run a separate instance of the operating system on the host machine. So this instance will have all its own resources which need to be managed and procured. For example in case you want to start a windows VM then you need to purchase a separate Windows license along with the one you already have on the host machine

The VM is just an abstraction of the physical hardware that turns a single server into multiple ones. But considering the load it bears, it is not advised to have multiple VM's on a single machine.

Containers on the other hand are the lightweight alternative to VM's which utilize the operating system of their underlying host. They don't need separate individual allocation of resources or hardware and run like said before in an isolated environment.

One more major difference between the two is when we actually want to stop using these apps or VM. In the case of VM, we will have to individually remove all software, etc but in the case of the container with one command we can just drop the container and all its memory, resources, etc will be freed.

What is meant by Isolated Environment?

What do we mean when we say that containers run in an isolated environment? So basically the application running inside a container is totally independent of any other or similar app running on some different container in the same machine.

For example, you have an app that requires NodeJs 10 & SQL Server 2013 to run. Now you can have container 1, with the required version installed and run the app. Again, you now are working on an app that requires say SQL Server 2019 & NodeJs 14, then you don't need to worry about container 1 already running on your machine. You can just power up a new container with the required versions and both will work as if the other one doesn't exist.

Dockerize an application

There is a standard way of dockerizing any app, irrespective of its type, and it is done by adding a DockerFile. Dockerfile is a plain text file used by docker to create an image based on the instructions provided in it.

These instructions are the step-by-step description of the requirements which need to be fulfilled to run the app on any machine. For example, a docker file for an asp.net core application would have details like the dot net core build version, required to build the app, dot net runtime environment which needs to be installed on the host machine, the actual application files, details of all third party applications, environment files, configuration variables, etc.

Once this image is prepared, a Container is built using this image making sure that all mentioned resources are made available inside it. Now once this container is run, the app inside it will start running.

Below is a sample dockerfile of a dotnet core web API project which has a dependency on SQL Server. No worry if you don't understand the steps, I have just added it here for a first reference. But in case you are interested in understanding the steps, feel free to visit this page

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

FROM mcr.microsoft.com/dotnet/sdk:5.0 AS build
WORKDIR /src
COPY ["GallaSoft.RetailerOnboardingAPI/GallaSoft.RetailerOnboardingAPI.csproj", "GallaSoft.RetailerOnboardingAPI/"]
RUN dotnet restore "GallaSoft.RetailerOnboardingAPI/GallaSoft.RetailerOnboardingAPI.csproj"
COPY . .
WORKDIR "/src/GallaSoft.RetailerOnboardingAPI"
RUN dotnet build "GallaSoft.RetailerOnboardingAPI.csproj" -c Release -o /app/build

FROM build AS publish
RUN dotnet publish "GallaSoft.RetailerOnboardingAPI.csproj" -c Release -o /app/publish

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "GallaSoft.RetailerOnboardingAPI.dll"]

The built image can be shared with anyone and all they need to do is run the required commands to create a container out of it. And they would have the app running on their machine, without actually going and individually installing and setting up all the requirements for that app to run.

Docker in Development Workflow

Not only docker is useful in packaging and deploying applications, but it can also be a very time-saving and handy tool that can increase the productivity of your development workflow.

Say you join a development team that has been already working on a huge app that integrates with SQL Server, Couchbase, RabbitMq, Elasticsearch, and whatnot. Now to set up all these things, you would be required to get the executables of the exact version used, install them, set them up with the initial configuration and data, and then finally you are in a position to start working.

All this can be just a matter of single executable docker command if we start using the containerized version of these apps. We can just have a single file with the exact version of these apps mentioned in them. The new resources can just run the container out of the image and within minutes all these applications will be running on the new machine as well.

What comes in more handy here is that we can create our custom images over top of some of the official images that come in. So we don't need to create an empty SQL server every time. One of the developers and get the SQL image, configure all the database, tables, data, etc in it, and then create a custom image of it. Now when anyone uses these images they will get all the configuration done before and they can immediately start working. You can read about SQL Server custom image here

Conclusion & Next Steps

In a nutshell, Docker can be the fastest and most efficient way for you to get more and more applications runnings on the same hardware without interfering in any way. It provides one single standard format to ship, build and then deploy your apps and is not something that only concerns the system admins or the DevOps guys.

Docker is there to make the life of developers much much easier.

For the next steps, I would suggest getting some hands-on and actually start using Docker in your development workflow. The free handbook on FreeCodeCamp is a good place to start.

You can also look into courses on CodeWithMosh and FrontendMasters which are quite detailed and cover most of the topics.

You can also follow Francesco Ciulla who is quite actively sharing quality content on Docker and is currently working on his ebook for the same as well.

Till next time, keep learning & keep building 🚀📚