(translated) with. NET container image remains synchronized

Original: https://blogs.msdn.microsoft.com/dotnet/2018/06/18/staying-up-to-date-with-net-container-images/

This article describes the production and update container images we provide you with, which you can use in Docker, Kubernetes and other systems. When you use. NET and Docker images together, you may be using Microsoft's official. NET container image. We've made a lot of improvements to. NET mirroring over the past year to make it easier for you to encapsulate. NET Apps.

During last week's Dockercon No. 2018, I made an update about using. NET and Docker at the same time. It shows how to use Docker and. NET for production, development, and testing. These scenarios are based on the. NET container image on the Docker Hub.

Faster software Delivery

Docker is a game converter that gets and uses. NET updates. Recall a few years ago. You can download the latest. NET Framework as a Windows MSI installation package until we run the next release without having to download it again. Fast forward to today. We have one months to push multiple updated containers mirroring to the Docker Hub. Every time you pull a. NET image, you get updated software, an update to a. NET and/or underlying operating system, whether it's Windows or Linux.

This new software delivery model is faster and creates stronger connections between software producers and consumers. It also gives you more control, but requires a bit more knowledge on how to get the software through Docker. It is important to understand the software vendor's Docker repositories (repos) and tags (tags)-this example of microsoft--so you can get the exact version and updates you want. This article is intended to provide the information you need to select the best version of the. NET image you need.

Official image from Docker

Docker maintains an official image of the operating system and application platform. These images are maintained by Docker, a skilled community developer, and a designated technology (like Alpine) operating system or application platform maintenance personnel.

Official Image:

• Correct and optimal configuration
• Regular maintenance
• Can be shared with other applications (in memory)

. NET images are built using the official image. We build on the official images of Alpine,debian and Ubuntu x64 and ARM. By using the official image, we will periodically update the cost and complexity of operating system base images and packages (such as OpenSSL) to the developers who are closest to these technologies. Instead, our build system is configured to automatically build, test, and push. NET images, no matter where we use and update the official image. With this approach, we can provide. NET Core on multiple Linux distributions at a low cost and send updates within hours. You can also save memory.. NET, a combination of Java and node. JS applications on the most common host, such as the latest official Debian image, will share the Debian base image in memory.

. NET images from Microsoft

. NET images are not part of the official Docker image because they are only maintained by Microsoft. We also built the Windows Server image on top of the same, similar to the official Docker image, we have a. NET image that is proficient in. Nets and Docker. The result is the same benefits as the Docker official image described above.

We maintain. NET images with the following models:

• Pushes a mirrored update of the same day when a new. NET version or underlying operating system image is released.
• Push mirroring to Docker Hub after successful validation of the VSTS CI system.
• Generates a mirror that matches the. NET version available in Visual Studio.
• Make the preview software available for early feedback and use on microsoft/dotnet-nightly.

We rely on Docker's official maintainers to generate high-quality images in a timely manner so that our images are valued up-to-date. We know that you rely on us to do the same thing for. NET. We also know that when a new. NET image is available, many people will automatically rebuild the image and the included application. It is very important that this process runs well so that your application always runs on the latest. NET patch version and the rest of the software stack that you choose to use. This is part of our work together to ensure that. NET applications are safe and reliable in production.

. NET Docker Hub Warehouse

Docker Hub is a great service for storing images of public containers in the world. When we first pushed the image to the Docker hub, we created a fine-grained repository. Many fine-grained buybacks have its advantages, but it is not one of them that can be found. We've heard that it's hard to find feedback on. NET images. To help with this, we have reduced the number of warehouses we use. The current. NET Docker Hub Warehouse is as follows:

. NET Core Warehouse:

• Microsoft/dotnet-includes the. NET core runtime, SDK and ASP.
• Microsoft/aspnetcore-Includes the ASP. NET Core 2.0 and earlier versions of a runtime mirror. Use microsoft/dotnet for. NET Core 2.1 and the latest version.
• Microsoft/aspnetcore-build-Includes both the ASP. NET core SDK and the earlier version of node. js. Use microsoft/dotnet for. NET Core 2.1 and the latest version. See Aspnet/announcements #298.

. NET Framework Repositories:

• Microsoft/dotnet-framework-Includes the. NET Framework runtime and SDK mirroring.
• Microsoft/aspnet-Includes an ASP. NET runtime image that is used to configure ASP. NET Web Forms and MVC for IIS.
• MICROSOFT/WCF-Includes WCF run-time mirroring configured for IIS.
• Microsoft/iis-Includes IIS on the Windows Server Core base image. For. NET Framework applications instead of optimizations. It is recommended that you use microsoft/aspnet and MICROSOFT/WCF warehouses instead of running their respective application types.

Obsolete warehouses:

• Microsoft/dotnet-framework-build-Includes the. NET Framework SDK. The SDK image is now available microsoft/dotnet-framework.

. NET Mirroring Labels

The mirror tag used in the Dockerfile file may be the most important artifact in various docker-relaterd assets. The tag defines the underlying software and applications that are expected to be used when running the Docker build to run in production. tags give you a lot of control over the images you pull, but if you use tags that don't match your needs, it can also be a source of pain.

The label has four main options, from general to most specific:

• Latest Version -The default version of the latest tab and software available in the repository (regardless of what the repository maintainer thinks is the default, it may or may not be the most recent version). When you do not make a label, your request will pull up the latest tab. From one pull to the next, you may get software and/or major version updates for the underlying operating system. For example, when we carry. NET Core 2.0, the latest label (for Linux) jumps from. NET core 1.1 to 2.0 while Debian jumps from 8 to 9. The latest version is for better experimentation, and nothing is a good choice for anything else. You don't want your application to use the latest version in Auto-build.
• Major Version -a secondary tag, such as 2.0-runtime or 2.1-SKD, locks you into a specific software update series. These sample labels will each receive only. NET Core 2.0 or. NET 2.1 updates. When you build with Docker, you can expect to get patch updates for software and underlying operating systems. In most cases we recommend this form of labeling. It balances the competitive relationship between ease of use and the risk of renewal. For example, the 4.7.2-SDK. NET Framework Tag matches this label style.
• Patch version -Major version. Minor version. Patch version tags, such as 2.0.7-runtime lock you to a specific patch version of the software. From a predictable point of view, this is good. But every time you update to a new patch version, you need to update Dockerfile. If you need to deploy. NET security updates for multiple applications, you need a lot of work. For example, the 4.7.2-sdk-20180523-windowsservercore-1803. NET Framework Label matches the secondary label style. We do not update the. NET content in the patch version image, but we may introduce a new image for the tag because of changes in the underlying image. Therefore, do not assume that the Patch version label is immutable.
• Summary --you can refer directly to a mirror summary. This approach gives you maximum predictability. The label can be overwritten by a new image, but the digest cannot. Tags can also be deleted. We recommend that you use the digest when the application is interrupted due to a mirrored update, and you need to return to the latest known working version. It may be challenging to determine a summary of a mirror that is no longer in use. Logs can be added to the mirrored build infrastructure, with mobile phone information as an insurance policy for accidental damage.

A label is a contract on the. NET version that you want. Every time we run, we try to meet the contract. We do two main things to produce a quality container image: CI validation and code review. CI authentication runs on several operating systems, and each pull requests to the. NET Repository. This level of pre-validation gives us the quality of the Docker image pushed to the Docker Hub.

For each major and minor. NET version, we can adopt a new major operating system version dependency. As mentioned earlier, we use Debian 9 as the base image for. NET Core 2.0. We stay in Debian 9 for. NET Core 2.1. Because Debian 10 (aka "Buster") has not been issued yet. Debian 9 is still the default base image for. NET Core 2.1 for the life cycle of. NET Core 2.1. Once we have adopted the major version of the underlying operating system, we will not change it for the life cycle of a given. NET version.

Each release has its own patch model. For the. NET Patch, we will use a smaller Debian version, for example (Debian 9.3-9.4). If you look at. NET Core Dockerfiles, you can see the dependencies of various Linux operating systems, such as Debian and Ubuntu. We make meaningful decisions in the context of our supported Windows and Linux operating systems and in the communities in which they are used.

Windows versioning for Docker is different from Linux, just as the multi-arch tags work the same way. Simply put, when you pull a. NET Core or. NET Framework image on Windows, if you use the Multi-arch tag, we'll get a mirror that matches the host Windows version (more on this later). If you need a different version, you need to use a specific label for the Windows version. Some azure services, like Azure Container Instances (ACI), support only Windows Server 2016 (at the time of writing). If your goal is ACI, you need to use Windows Server 2016 tags, such as 4.7.2-runtime-windowsservercore-ltsc2016 or 2.1- aspnetcore-runtime-nanoserver-sac2016, respectively, for the. NET Framework and ASP.

. NET Core Labeling Scenarios

There are multiple mirrors in the Microsoft/dotnet warehouse:

• SDK ——. NET Core SDK images, including. NET core cli,.net core runtime and ASP.
• aspnetcore-runtime --asp.net core images, including. NET core runtimes and ASP.
• runtime ——. NET core runtime mirroring, including the. NET core runtime.
• runtime-deps ——. NET core runtime relies on mirroring, including only. NET core dependencies and. NET core itself. This image is for self-contained applications and is available only to Linux. For Windows, you can use the operating system base image directly for self-contained applications because it satisfies all. NET Core dependencies.

We made a Docker image of the following operating system:

• Windows Nano Server 2016+
• Debian 8+
• Alpine 3.7
• Ubuntu 18.04

. NET Core supports multiple chips:

• X64
• Arm32v7

Note: The ARM64V8 image will be available at a later time, possibly with. NET Core 3.0.

The. NET core tag follows a scenario that describes the various combinations of mirrors, operating systems, and chips supported by. NET Core.

[Version]-[kind]-[os]-[chip]

Note: This scenario is a new scenario that accompanies. NET Core 2.1, with earlier versions using similar but slightly different scenarios.
The following. NET Core 2.1 Tags are examples of this scenario:

• 2.1.300-sdk-alpine3.6
• 2.1.0-aspnetcore-runtime-stretch-slim
• 2.1.0-runtime-nanoserver-1803
• 2.1.0-runtime-deps-bionic-arm32v7

Note: You may notice that some of these tags use strange names. "Bionic" and "Stretch" are the versions of Ubuntu 18.04 and Debian 9 respectively. They are the label names of Ubuntu and the Debian Repository, respectively. "Stretch-slim" is a small variant of "stretch". We use smaller mirrors when they are available. "nanoser-1803" represents the Spring 2018 update for Windows Nano Server. "Arm32v7" describes a 32-bit ARM base image. ARMV7 is a 32-bit instruction set defined by ARM holding company.

They are also short formats for. NET Core tags. Short formats are available in two different ways. They use a two-part version number and skip the operating system. In most cases, short format labels are the tags you want to use because they are simpler, easier to maintain, and multi-arch, so they can be ported across operating systems.

We recommend that you use the following. NET Core short format tags in Dockerfile:

• 2.1-sdk
• 2.1-aspnetcore-runtime
• 2.1-runtime
• 2.1-runtime-deps

As mentioned above, some Azure services only support Windows Server 2016 (not Windows Server 1709 or later). If you use one of these, you may not be able to use a short label unless you are building mirroring on Windows Server 2016.

. NET Framework Labeling Scenarios

There are multiple mirrors in the Microsoft/dotnet-framework warehouse:

• The SDK ——. NET Framework SDK images, including the. NET Framework runtime and the SDK.
• Runtime ——. NET Framework runtime mirroring, including the. NET Framework runtime.

We made a Docker image of the following Windows Server versions:

• Windows Server core,version 1803
• Windows Server core,version 1709
• Windows Server Core 2016

The. NET Framework label follows a scenario that describes the different combinations of various mirrors and the version of Windows Server supported by the. NET Framework:

[Version]-[kind]-[timestamp]-[os]

The. NET Framework version number does not use the major version. Minor version. Patch version scenario. The third part of the version number does not represent a patch version. Therefore, we added a timestamp to the label to create a unique label name.

The following. NET Framework tags are examples of this scenario:

• 4.7.2-sdk-20180615-windowsservercore-1803
• 4.7.2-runtime-20180615-windowsservercore-1709
• 3.5-sdk-20180615-windowsservercore-ltsc2016

They also have a short format for the. NET Framework label. Short formats are available in two different ways. They omit timestamps and omit Windows Server versions. In most cases, these are the tags you want to use because they are simpler, easier to maintain, and multi-arch. So you can migrate across Windows versions.

We recommend that you use the following short-form tags in Dockerfile, such as the. NET Framework 4.7.2 and 3.5:

• 4.7.2-sdk
• 4.7.2-runtime
• 3.5-sdk
• 3.5-runtime

As discussed above, some Azure services only support Windows Server 2016 (not Windows Server 1709 or later). If you use one of these, you may not be able to use the short mark unless you happen to only build the mirror on Windows Server 2016.

Microsoft/aspnet and MICROSOFT/WCF use variants of this labeling scheme and may move to this scenario in the future.

Security updates and vulnerability scanning

Since you may already be aware of this, we regularly update. NET images so that you can use the latest. NET and operating system patches. For Windows, our mirroring update is essentially similar to the general "Tuesday Patch" version that the Windows team provides on Windows Update. In fact, we update our Windows Base image with two patches per week through the latest Windows patches. You cannot run Windows update in a container. You can rebuild with the latest container image on the Docker Hub.

The update experience on Linux is more subtle. We support multiple Linux distributions and can be updated at any time. There is no specific timetable. Additionally, a common set of vulnerabilities (AKA cves) is not patched and there are no fixes available. This is not particularly true for using Linux in containers, but Linux is often used.

A customer asked us why. NET Core Debian's underlying image cannot be scanned for vulnerabilities. I scanned with Anchore.io and verified the same scan that the customer shared with us. The vulnerability comes from the underlying image we use.

You can view the same scan that I viewed:

• Alpine Latest
• Debian Latest
• Ubuntu Latest

One of my observations is that the scan results of Debian and Ubuntu have changed dramatically over time. For Alpine, they remain stable, with few reported vulnerabilities.

We use three ways to partially mitigate the challenge:

• Rebuild and send a. NET image (within a few hours) as soon as the latest Linux discovery patches are updated.
• Once available, the latest version of the major version is supported. We have observed that the newest distros are often patched faster.
• Support for Alpine, which is smaller, so there are fewer components that are vulnerable.

These three ways give you a lot of options. We recommend that you use a. NET Core image, using the latest version of the Linux distribution that you choose. If you are more concerned about the vulnerabilities on Linux, use the latest patch version of the. NET Core 2.1 Alpine image. If you are still dissatisfied with this situation, consider using our Nano Server image.

Using pre-release mirroring

We maintain a pre-release Docker Hub repository, dotnet-nightly. The. NET core 2.1 images built at night before. NET Core 2.1 are available in that warehouse. Currently, the warehouse has a. NET Core 1.x and 2.x service branch built at night. Soon, you'll see the. NET Core 2.2 and 3.0 that you can test for nightly builds.

We also offer pre-release versions of. NET Core and Linux distros. We offer Ubuntu 18.04 (aka "bionic") before it is released. We currently offer a pre-release version of the. NET Core image with the Debian 10 (aka "Buster") and the Alpine Edge branch.

Conclusion

We want to make it easy for you to intuitively use the official. NET images that we generate for Windows and Linux. Docker offers a great software delivery system that makes it easy to stay up to date. We hope you now have the information you need to configure Dockerfile and build your system to use a label style that provides service characteristics and image consistency for your environment.

We will continue to make changes to the. NET container image When we receive feedback and the Docker feature has changed. We are regularly updated in dotnet/announcements. "Watch" This warehouse to keep up with the latest updates.

If you're a novice docker, check with. NET and Docker. It explains how to use. NET in various scenarios using Docker. We also provide examples of semantic domain use and learning for the. NET Core and. NET Framework.

Tell us in the comments how you can use. NET and Docker together. We would love to know how you use. NET and containers and the improvements you want to see.

(translated) with. NET container image remains synchronized