Using. NET and Docker--dockercon 2018 updates together (translation)

Original: https://blogs.msdn.microsoft.com/dotnet/2018/06/13/using-net-and-docker-together-dockercon-2018-update/

Last year I wrote an article on common use of. NET and Docker. With the start of this week's Dockercon 2018, it seems like a good time to update. Since the previous article, we have enabled a series of Docker workflows for. NET Core and. NET Framework wizards and samples for development, CI/CD, and production. We also provide more images of Windows and Linux. If you haven't recently focused on Docker and. NET, now is a good time.

Docker and containers are more and more mentioned in the dialogue with. NET developers. It has become a way for many people to deploy server-side applications. Virtual machines are replaced by the main advantages of consistency and lightweight. In Dockercon's topic, there are several. NET demonstrations of how to apply Docker to legacy applications in modern and traditional architectures. It makes it easier to encapsulate. NET applications through Microsoft and Docker tools.

For information about. NET container mirroring, see the. NET container image remains synchronized.

Try Docker

We maintain a sample warehouse for the. NET Core and. NET Framework. You can test Docker with these sample images with just a few commands on the command line.

The simplest (support for most operating systems) is the. NET Core console App sample. You only need to enter the following command:

Docker Run--rm Microsoft/dotnet-samples

You can also try other examples, both console and ASP. NET Applications:

• . NET Core Docker Samples
• . NET Framework Docker Samples

How to use Docker

Docker is flexible and allows you to use it in a number of different ways. There are three main scenarios to consider when using Docker:

• Building Source Code
• Test binary files
• Running applications/services in a production environment

You can use Docker to handle all these roles or a subset. From what we've seen, most developers start with production scenarios and then use more Docker as they discover useful infrastructure. This processing is meaningful, and choosing to use Docker typically uses it to run the application as the center.

In the. NET team, we've used Docker a lot when building and testing the code. High-fidelity and instant-start computing environments are very valuable, for example, when you can start a completely correct environment in seconds without delaying product surveys on Debian.

The following sections show examples of the. NET Core and. NET Framework mix for these three scenarios.

Building a container image using a binary file

The primary requirement for running Docker in a production environment is containerized applications. The simplest way to create a mirror in an existing build infrastructure is to copy the build file into the image. The main value of this model is the consistency of the environment, such as the staging environment and the production environment.

The following Dockerfile copies the build assets in the current directory to a new mirror based on the. NET Core runtime Mirror on the Docker Hub.

 from microsoft/dotnet:2.1-runtimeworkdir  /appCOPY  . entrypoint ["Dotnet", "App.dll"]

The following command creates an image of an app from the Dockerfile above, assuming the command runs in the same directory as the Dockerfile and App.dll:

Docker build--pull-t app.

The following command creates a running container based on the app Image:

Docker run--rm App

Note: The--RM parameter removes the container after the container has finished. Keep containers only when you want to investigate why they behave in a certain (unwanted) way.

Building a container image using source files

Docker makes it easy to build source files for your application and build container mirroring in one step. This is also known as multi-level construction. The value of building a source file within a container is as follows:

• Consistency between build and run/production environments.
• Because of the Docker layer cache, incremental builds are faster than your own build system.
• Docker does not rely on external feature building (if you build from a source file in Docker).

The bottom Dockerfile copies the source files from the current directory to the new mirror based on the. NET Framework SDK image on the Docker Hub. The Dockerfile command uses NuGet and MSBuild to build the source code. Copies the binaries based on the. NET Framework runtime image to a new mirror during the build phase. The build phase image is discarded. The selected mirror name is used only for images generated from the last stage.

The second part of the top is where the Docker flashes. Each command in Docker creates a different layer in the Docker image. If Docker finds that the input for a given layer has not changed, then the build of the subsequent Docker does not rebuild the layer. The second part duplicates the MSBuild asset, such as the project file, and then runs NuGet recovery. If the MSBuild asset does not change, then the execution recovery is skipped. This ultimately saves a lot of time. It also explains the way Dockerfile is written.

The next command creates a new image of Aspnetapp using the Dockerfile above, assuming that the command is run from the directory where the Dockerfile and source files are located:

Docker build--pull-t Aspnetapp.

For example, if the--pull parameter on the Docker Hub pulls a new microsoft/dotnet-framework image, this parameter will take longer (if no new mirrors exist) at each Docker build, but keep up to date with the environment. In the long run, the newest approach is very useful because it keeps your environment in sync with environments that do not have a cached image.

The following command creates a container based on the Aspnetapp image:

Docker Run--rm-it-p 8000:80 Aspnetapp

The-p parameter maps the host port to the Docker client port.

For more information on building the source code with Docker, refer to the following example:

• ASP (. NET Framework) Sample
• ASP. NET Core Docker Sample

Test binary files with Docker

The test scenario demonstrates the value of Docker because testing has more value when the test environment and the target environment remain highly consistent. Let's say your app supports multiple operating systems or operating system versions. You can test your app in each of their Docker. It is easy to do and very valuable.

So far, in this article you've seen the Dockerfile that runs the command, which describes the logic that needs to be built with Docker and the end result of running with Docker. It is useful to build run tests through Docker as an early feedback, primarily by printing to console/terminal pass/fail results. This model can be used well for testing, but two reasons are small:

• If there are errors inherent in the test, the Docker build will fail.
• The Docker build does not allow volume installation, which is required for the phone test log.

Using Docker to run tests is a good choice because it is not affected by any one of these two challenges. Building tests with Docker is useful, and you want to make your build fail if the test fails. The instructions in this document show how to Run tests using Docker.

The following Dockerfile are similar to the. NET Framework seen above in normal use. Then, it contains some tricks to implement the test. Including one that is usually very close to the No-op testrunner phase, but this is very useful for testing.

To test, create a testrunner phase image, which will include all the content built into one point. The resulting image is based on the. NET core SDK image, including all. NET core test infrastructures. The trick of this Dockerfile is that the Testrunner phase provides an alternative entrypoint, calling dotnet test to start the test. If you have been running Dockerfile (not for a specific stage), then the first entrypoint will be replaced by the last one, which is the entrypoint of the application.

The following command creates a new image of Dotnetapp:test, using the Dockerfile above to build and include the testrunner phase only, assuming that the command is run from the Dockerfile and source files directory:

Docker build--pull--target testrunner-t dotnetapp:test.

In order to test the logs on the local machine, you need to use volume installation. In short, you can import the directories on your machine as a unified directory into the container. Volume installation is a good way to get inside or out of a container.

The following command creates a container based on dotnetapp:test. Volume installs the C:\app\TestResults local directory to the/app/tests/testresults in the app. The local directory must already exist, and the C drive must be shared to Docker.

Docker Run--rm-v c:\app\testresults:/app/tests/testresults dotnetapp:test

After you run the command, you should see the. trx file in the C:\app\TestResults file.

Running. NET Core unit tests with Docker shows how to test in more detail in a container. Includes Windows,macos and Linux. Also includes scripts for managing test workflows described in this section.

Developing in containers

The above scenario focuses on generating or validating container mirroring. The use of Docker can be further developed upstream.

Visual Studio allows development in the container. You can add Dockerfile to a. NET project, a Windows container, or a Linux container. Experience is almost seamless. It's hard to say you're using Docker, as you can see in the picture below.

You can also develop within the command-line container. The. NET Core SDK Image contains a number of features that you can create a Dockerfile to use effortlessly. In fact, you can run, build, or test your application from the command line.

Developing an ASP. NET core application in a container illustrates how to build and rebuild ASP. NET core applications via Docker, for example, you can edit them from Visual Studio Code on your local machine on your native machines.

The following command line hosts an ASP. NET Core application on MacOS or Linux via dotnet. The Windows instructions are available in developing an ASP. NET Core application in a container. Each time the application is edited and saved on the local machine, it is rebuilt in the container. I've never tried to do this 1000 times in a row, but you're probably doing it. This scenario relies on the volume installation to project localized source code into a running container. As you can see, writing Dockerfile to implement volume installation is a powerful option.

Docker run--rm-it-p 8000:80-v ~/git/aspnetapp:/app/-w/app/aspnetapp microsoft/dotnet:2.1-sdk dotnet Watch Run

For similar directives about. NET Core console applications, see Developing. NET core applications in containers.

ASP. NET Core and HTTPS

It's Central Asia to host WEB applications with HTTPS. In many cases, HTTPS requests are terminated before they reach the ASP. When ASP. NET Core needs to handle HTTPS traffic directly and run your site in a container, you need a solution.

Hosting an ASP. NET Core Image through HTTPS describes how to host our ASP. NET core sample images with HTTPS. The model described is very similar to how you can host your own image with your own certificate.

The following command can be used to run the ASP. NET Core sample image of the dev certificate on Windows using the Linux container:

8000:80-p 8001:443-e aspnetcore_urls= "https://+;http://+"-e aspnetcore_https_port=8001-e aspnetcore_kestrel__ Certificates__default__password= "Crypticpassword"-e aspnetcore_kestrel__certificates__default__path=/https/ Aspnetapp.pfx-v%userprofile%\.aspnet\https:/https/microsoft/dotnet-samples:aspnetapp

Hosting an ASP. NET Core image through the HTTPS directive in Docker can be used on Windows,macos and Linux.

End

You may find that we are working together on. NET and Docker more than we did in the original 2017 topic article. We are far from completing all conceivable container controls, but have provided you with a more complete foundation for your use of Docker.

Using. NET and Docker--dockercon 2018 updates together (translation)