Background:
By using containers, enterprises are increasingly realizing cost savings, solving deployment problems, and improving DevOps and production operations. Microsoft has been rolling out container innovations for Windows and Linux by creating products like Azure Kubernetes Service, Azure Service Fabric, and partnering with industry leaders like Docker, Mesosphere, and Kubernetes. These products provide container solutions that help companies build and deploy applications at the speed and scale of the cloud, regardless of the platform or tool of choice.
Docker is emerging as the de facto standard in the container industry, supported by the most important vendors in the Windows and Linux ecosystems. (Microsoft is one of the major cloud vendors that support Docker.) In the future, Docker may become ubiquitous in any data center, either in the cloud or on-premises.
Docker containers, images, and registries
With Docker, a developer creates an app or service and packages it and its dependencies into a container image. An image is a static representation of an app or service and its configuration and dependencies.
To run an app or service, the app’s image is instantiated to create a container that runs on a Docker host. Initially, containers are tested in a development environment or PC.
Developers should store images in a registry that acts as a mapping library and is used when deploying to a production orchestrator. Docker maintains a public registry through Docker Hub; Other vendors provide registries for different image collections, including Azure Container Registry. Alternatively, enterprises can have an on-premises, private registry for their Docker images.
Choose .NET 5 or .NET Framework for your Docker container
There are two supported frameworks for building server-side containerized Docker applications with .NET: .NET Framework and .NET 5. The two share many .NET platform components that can be used to share code between them. But there are fundamental differences between the two, and the framework can be chosen according to what needs to be achieved.
Official website address:
https://dotnet.microsoft.com/download
Build containerized applications based on microservices
Microservices offer many benefits, but they also present new and significant challenges. When creating a microservices-based application, the microservices architecture pattern is the foundational pillar.
Container design principles: In the container model, a container image instance represents a single process. Defining a container image as a process boundary allows you to create primitives that can be used to scale or batch process a process.
When you design a container image, you can see the entry point definition in the Dockerfile. This definition defines a process whose lifecycle controls the lifecycle of a container. When the process is complete, the lifecycle of the container ends. Containers can represent long-running processes, such as web servers, but they can also represent shorter-lived processes, such as batch jobs, that may have previously been implemented as Azure WebJobs.
If the process fails, the container ends and the Orchestrator takes over. If the Orchestrator is configured to keep five instances running and one of them fails, the Orchestrator creates another container instance to replace the failed process. In a batch job, start the process with parameters. When the process is complete, the work is complete.
The development process for Docker-based applications
Whether you prefer a rich, powerful IDE or a lightweight, flexible ground editor, Microsoft has the tools for developing Docker applications.
Visual Studio for Windows. Docker-based .NET 5 application development with Visual Studio requires Visual Studio 2019 version 16.8 or later. Visual Studio 2019 comes with Tools for Docker already built-in. Tools for Docker allow you to develop, run, and validate applications in the target Docker environment. You can press F5 to run and debug your application (single container or multiple containers) directly in the Docker host, or you can press Ctrl+F5 to edit and refresh your application without having to rebuild the container. To develop Docker-based applications, this IDE is the most powerful choice.
Visual Studio for Mac。 It is an IDE that evolved from Xamarin Studio and runs in macOS. For .NET 5 development, it requires version 8.4 or later. This tool should be ideal for developers who work on macOS computers and want to use a powerful IDE.
Visual Studio Code and Docker CLI. If you prefer a lightweight, cross-platform editor that supports any development language, you can use Visual Studio Code and the Docker CLI. This IDE is a cross-platform development approach for macOS, Linux, and Windows. In addition, Visual Studio Code supports Docker extensions, such as IntelliSense for Dockerfiles, and shortcut tasks that run Docker commands in the editor.
Implement resilient applications
Microservices and cloud-based applications must allow for partial failures that are bound to occur eventually. The application must be designed so that it can recover from these partial failures.
Resiliency refers to the ability to recover from failures and continue to work. It’s not about avoiding failure, it’s about accepting that failure will happen and responding to it in a way that avoids downtime or data loss. The goal of recovery is to bring the application back to a fully functional state after a failure.
Designing and deploying microservices-based applications is already challenging. However, the application also needs to be kept up and running in an environment where some kind of failure is bound to occur. Therefore, the application should be resilient. It should be designed to handle partial failures, such as network outages or node or VM failures in the cloud. Even moving a microservice (container) to another node within the cluster can cause intermittent feature shortage failures in your application.
In distributed systems such as microservices-based applications, partial failure errors often occur. For example, a single microservice/container may fail or fail to respond in a short period of time, or a single VM or server may fail. Because the client and the service are separate processes, the service may not be able to respond to the client’s request in a timely manner. The service may be overloaded and slow to respond to requests, or simply be inaccessible for a short period of time due to network issues.
For example, look at the order details page of the eShopOnContainers sample application. If the ordering microservice doesn’t respond when the user tries to submit an order, an incorrect implementation of the client process (MVC web application) (for example, if the client code uses synchronous RPC without a timeout) will prevent the thread from waiting for a response indefinitely. In addition to creating a poor user experience, each unresponsive wait consumes or blocks threads, which are extremely valuable in highly scalable applications. If the number of blocked threads is high, the runtime of the application will eventually exhaust all threads. In this case, the application will be globally unresponsive, not just partially unresponsive, as shown in the diagram above.
In addition, the recovery capabilities include: handling partial failed policies, implementing retries using the exponential backoff algorithm, restoring Entity Framework Core SQL connections, using IHttpClineFactory to restore Http requests, implementing Polly retries of Http calls using the exponential backoff algorithm, implementing circuit breaker mode, and monitoring the running status.
More details: Click to download
