Category: Enterprise App

What is Docker?

Docker is an open-source platform for developing, shipping, and running applications which enables to separate applications from infrastructure, and software that can deliver quickly. Docker provides many benefits such as runtime environment isolation, consistency via code, and portability.

What are Containers?

Containers are the organizational units of Docker. When we build an image and start running it; we are running in a container. The container analogy is used because of the portability of the software we have running in our container. The isolation and security allow you to run many containers simultaneously on a given host. There is no need for an extra load of a hypervisor so containers are lightweight, & it runs directly within the host machine’s kernel. 

Difference between virtual machines and dockers:

Docker Engine

Docker Engine lets  you to develop, assemble, ship, and run application usage of the following components:

1. Docker Daemon

It is a persistent background process that listens for Docker API requests and processes them & manages Docker images, containers, networks, and storage volumes. 

2. Docker Engine REST API

An API utilized by programs to engage with the Docker daemon; it could be accessed with the aid of an HTTP client.

3. Docker CLI

A command-line interface purchaser for interacting with the Docker daemon. It substantially simplifies how you manage container times and is one of the key reasons why developers love the use of Docker.

Docker architecture

• Docker uses a client-server architecture.
• The Docker patron talks to the Docker daemon, which does the heavy lifting of building, running, and dispensing your Docker containers.
• The Docker patron and daemon can run on the same system, or you may join a Docker consumer to a remote Docker daemon.
• The Docker client and daemon talk about the use of a REST API, over UNIX sockets, or a community interface.

1. Docker daemon

A chronic background process that manages Docker images, containers, networks, and storage volumes. The Docker daemon constantly listens for Docker API requests and methods them.

2. Docker client

Docker users can engage with Docker via a client. When any docker commands run, the client sends them to docker daemon, which carries them out. Docker API is used by Docker commands. It is possible for Docker clients to communicate with more than one daemon.

3. Docker registries

A Docker registry stores Docker images. There are public and private registries. Docker has a public registry called Docker hub, where you could also store photos privately.

If you are using Docker Datacenter (DDC), it includes Docker Trusted Registry (DTR).

docker pull or docker run commands, images are pulled from the configured registry. 

docker push command, image is pushed to the configured registry.

Docker objects

While working with Dockers, we use the following Docker objects.

Images

Docker images are read-most effective templates with instructions to create a docker container. Docker images may be pulled from a Docker hub and used or you may add additional instructions to the base image and create a new and modified docker image. Using dockerfile users can create their own docker images.

Containers

Using Docker API or CLI users can create, start, stop, move, or delete a container. Containers are runnable instances of image.

After you run a docker image, it creates a docker container. All the applications and their surroundings run inside this container. Use Docker API or CLI to start, stop, delete a docker container.

Networking

Docker implements networking in an application-driven manner and provides various options even as maintaining enough abstraction for utility developers. There are basically two styles of networks available – the default Docker network and user-described networks. By default, you get 3 specific networks on the set up of Docker – none, bridge, and host.

Storage

Data can store within the writable layer of a container but it requires a storage driver. Being non-persistent, it perishes whenever the container is not running. So it is not easy to transfer this data. Docker supports the following four options for persistent storage:

• Data Volumes
• Data Volume Container
• Directory Mounts
• Storage Plugins

.NET AND DOCKER

Containers offer a lightweight way to isolate your software from the relaxation of the host system, sharing simply the kernel, and the usage of sources given on your software.

Build a .NET Core image

You can build and run a .NET Core-based container image using the following instructions:

docker build --pull -t dotnetapp
docker run --rm dotnetapp Dockers in .Net Core

You can use the docker images command to see a listing of your image, as you can see in the following example.

% docker images dotnetapp

Package an ASP.NET Core app in the container:

To package an ASP.NET Core app in a container, there are 3 steps.

1. Create ASP.NET Core project
2. Write a Dockerfile that will describe how to construct your image
3. Create a container in order to make your image alive or permit the execution of your image like one process.

Create your ASP.NET Core Project

Step 1: Run the following commands in the Command Prompt,

mkdir dockerapp
cd dockerapp
dotnet new webapi

After that, you will have a functional API. To test it, run this command.

dotnet build
dotnet run

Type below address to get the values from ValuesController –

localhost: 5000/api/values

Here we have our WebAPI that returns [“value1”, ”value2”] in JSON.

Step 2: Deployment Environment

Here, we do not need a compiler because we will have to build our application externally from our image, integrate all built files in the image, and just use a lightweight image containing the .NET Core runtime Microsoft/aspnetcore to execute our application.

Copy and paste below instructions in your Dockerfile:

#Development Environment Process 
FROM Microsoft/aspnetcore-build:latest AS build-env 
WORKDIR /app 

#copy csproj and restore distinct layers, make sure that we all dependencies 
COPY *.csproj ./ 
RUN dotnet restore 

#Copy everything else and build the project in the container 
COPY . ./ 
RUN dotnet publish --configuration Release --output dist 

#Deployment Environment Process 
#Build runtime image 
FROM microsoft/aspnetcore:latest 
WORKDIR /app 
COPY --from=build-env /app/dist ./ 
EXPOSE 80/tcp 
ENTRYPOINT [ "dotnet","dockerapp.dll" ] 

Step 3: In command prompt type:

docker build. –t rootandadmin/dockerapp –f Dockerfile

Step 4: Create a Container

Now, we have our image rootandadmin/dockerapp but as this image is not active we should make it alive. For this we need to create a container.

There is a big difference between Image and Container; a container is a process that contains an image and executes it.

To create a container from our image type below command:

docker create command –p 555:80 –name rootandadmin/dockerapp01 rootandadmin/dockerapp

docker start rootandadmin/dockerapp01

Access your API in the browser using the following address:

localhost: 555/api/values

Benefits of containerization

Containers solved an important problem: how to make sure that software runs correctly when it is moved from one computing environment to another.

Agile methodologies are based on frequent and incremental changes in the code versions, such that frequent testing and deployment are required.

DevOps engineers frequently move software from a test environment to a production environment and to ensure that the required resources for provisioning and getting the appropriate deployment model are in place, and also validating and monitoring the performance.

The initial solution for this was Virtualization. Virtualization allows multiple operating systems to be run completely independently on a single machine.

The virtualization Idea is extended using containers. In virtualization, the hypervisor creates and runs multiple instances of an operating system so that multiple operating systems can be run on a single physical machine sharing the hardware resources.

The container model eliminates hypervisors entirely. Instead of hypervisors, containers are essentially applications, and all their dependencies packaged into virtual containers. Each application shares a single instance of the operating system and runs on the “bare metal” of the server. 

Advantages of Container:

1. All the containers share the resources of the single operating system and there is no virtualized hardware. Since the operating system is shared by means of all containers, they’re much more light-weight than traditional virtual machines. It’s possible to host far more containers on a single host than fully-fledged virtual machines.
2. Containers share a single operating system kernel start-up in a few seconds, instead of the minutes required to start-up a virtual machine.
3.  Containers are also very easy to share.

Conclusion

Docker is a mature technology that helps you package your applications. It reduces the time necessary to bring applications to production and simplifies reasoning about them. Furthermore, Docker encourages a deployment style that’s scripted and automatic. As such, it promotes reproducible deployments.

Nowadays cloud-based, microservice-based, or Internet-of-Things (IoT) applications every so often depend on communicating with other systems across an unreliable network, which leads to unavailability or unreachability for these systems due to transient faults such as network problems and timeouts, being offline, under load or maybe non-responsive.

Polly, a .NET resilience and transient-fault-handling library, offers multiple resilience policies which enable software architects to design suitable reactive strategies for handling transient faults, and also proactive strategies for promoting resilience and stability. Through this post, I will walk you through all the policies/strategies/approaches which Polly library offers to handle transient faults.

Reactive transient fault handling approaches

1. Retry

These short-term faults typically correct themselves after a short span of time, and a robust cloud application should be prepared to deal with them by using a strategy like the “Retry pattern”.

Technically Retry allows callers to retry operations in the anticipation that many faults are short-lived and may self-correct; retrying the operation may succeed maybe after a short delay.

Waiting between retries, allows faults to self-correct. For example, Practices such as ‘Exponential backoff’ and ‘jitter’ enhance this by scheduling retries to avoid them becoming sources of further load or spikes.

2. Circuit-Breaker

There can also be circumstances where faults are because of unexpected events that might take much longer to fix themselves. In these situations, it might be useless for an application to continually retry an operation that is unlikely to succeed. As an alternative, the application should be coded to accept that the operation has failed and handle the failure accordingly.

Using Http retries in these situations could lead to creating a Denial of Service (DoS) attack within your own software. Therefore, you need a defence barrier so that excessive requests stop when it is not worth to keep trying. That defence barrier is precisely the “Circuit Breaker”.

How does circuit-breaker work?

A circuit breaker design pattern perceives the level of faults in calls placed through it and prevents calls when a configured fault threshold is reached.

The circuit breaker can have the following states:

• Closed to Open
• Open to Half-Open
• Half-Open to Open
• Half-Open to Closed

When faults exceed the threshold, the circuit breaks itself (Opens). An open circuit will result in call failure placed through it instead of being actioned and throws an exception immediately. Which means that call is not attempted at all. Thus, it will significantly protect both, a faulting system from an extra load, and allows the working system to avoid placing calls which are unlikely to succeed. Failing instantly in this scenario usually also promotes a better user experience.

After a certain configured time has been elapsed, the circuit moves to a half-open state, where the next call will be considered as a trial to determine the faulty system’s well-being. Based on this trial call, the breaker decides whether to close the circuit (resume normal operation) or break it again.

Note: Circuit-breaker implementation in software systems is like what is in electrical wiring; substantial faults will ‘trip’ the circuit, protecting systems regulated by the circuit.

3. Fallback

A Fallback policy defines how the operation should react in case, even with retries – or because of a broken circuit – the underlying operation fails repeatedly. How much well resilience-engineered your system, failures likely to occur. Fallback means defining a substitute as what you will do when that happens. Its a plan for failure, rather than leave it to have unpredictable effects on your system.

Proactive transient fault handling approaches

Retry and Circuit-Breaker are primary approaches for resilience to transient faults, however, both are reactive, as they react after the failure response to a call has been received.

What will happen if…???

1. Response never comes 
2. The response so delayed that we do not wish to continue waiting
3. Waiting-delay / Waiting-to-React logic could itself have problems

Therefore, to handle the above questions, is it possible to be more proactive in our approach to resource management and resilience? 

Consider a scenario, wherein a high-throughput system, many calls can be put through to a recently failed system before the first timeout is received. For illustration (Example one), with 100 calls/second to a faulted system that is configured with a 10-second timeout, 1000 calls could have been placed before the first timeout is received. A circuit-breaker will react to this situation as soon as defined threshold failures are reached, but till then a resource bulge has certainly occurred and cannot be backtracked.

While Retry and Circuit-Breaker are reactive; Timeout, Bulkhead, and Caching policies configurations allow pre-emptive and proactive strategies. High-throughput systems can achieve increased resilience by explicitly managing load for stability. We will walk through each of these in the below sections one by one.

1. Timeout

Timeout allows callers to walk away from an awaiting call. It will improve resilience by setting callers free when a response seems unlikely.

Moreover, as the above given ‘Example one’ data demonstrates, opting for timeouts can influence resource consumption in a faulting, high-throughput system. 

These kinds of scenarios often lead to blocking up of threads or connections, the memory those awaiting calls consume, and which causes further failures. Consider how long you want to let your awaiting calls consume these costly system resources.

2. Bulkhead

The excessive load is one of the main reasons for system instability and failure. Therefore, building resilience into systems involves explicitly dealing with that load and/or pro-actively scaling to support it.

Excessive load can either be due to:

1. Genuine external demand, for example, spikes in user traffic 
2. Or maybe due to faulting scenarios, where large numbers of calls back up.

Bulkhead policies promote stability by directly managing load and thus resource consumption. The Polly Bulkhead limits parallelism of calls placed through it, with the option to queue and/or reject excessive calls.

• Bulkhead as isolation : Enforcing a bulkhead policy, a parallelism limit, around one stream of calls, limits the resource that stream of calls can consume. If that stream faults, it cannot consume all resources in the host and thus save bringing down the whole host.
• Bulkhead as load segregation : More than one Bulkhead policy can also be enforced in the same process to accomplish load segregation and relative resource allocation.
  A good comparison will be the check-out lanes of supermarkets, where there are often distinct lanes for “baskets only” as opposed to full shopping carts. This segregation permits for ‘baskets-only’ always to check-out quickly. Otherwise, they could be blocked waiting behind an excess of full shopping carts.
  Configuring multiple bulkhead policies to separate software operations delivers similar advantages, both in terms of relative resource allocation for different call streams; and in ensuring one kind of call cannot exclusively prevent another.
• Bulkhead as load-shedding : Bulkhead policies can also be configured to proactively reject calls beyond a certain limit.
  Why actively reject calls when the host might yet have more capability to service them?
  The answer is it depends on whether you prefer managed or unmanaged failure. Recommending explicit limits enables your systems to fail in predictable and testable ways. Intentionally ignoring the system’s capacity to the server does not mean there is not a limit; it just shows you do not know where the limit ends. Thus, your system is liable to unpredictable, unexpected failures.

3. Cache

Whatever that lessens network traffic, and overall call duration; in turn, rises resilience and improves user experience.

Caching can be configured with multiple caches – in-memory/local caches/distributed caches – in combination. Polly CachePolicy provisions multiple caches in the same call, using PolicyWrap.

Conclusion: This post walks us through multiple configurable resilience policies offered by Polly Library. Neova has the expertise to implement in business applications to make them fault resilient.

Note: For code level details you can reach GitHub community demonstrating all these configurations in detail.