Features/minor changes netcore2 wave (Microservices eBook) (#5859)

* Minor changes related to netcore 2.1 'wave'

* Minor changes related to netcore 2.1 'wave'

* add a comma

Quick typo

Author: CESARDELATORRE

docs/standard/microservices-architecture/microservice-ddd-cqrs-patterns/media/image1.png

@@ -23,19 +23,22 @@ You can also create your own Docker image in cases where you want to use a diffe
 
 When you add the image name to your Dockerfile file, you can select the operating system and version depending on the tag you use, as in the following examples:
 
--   microsoft/**dotnet:2.0.0-runtime-jessie**
+-   microsoft/**dotnet:2.1-runtime**
 
-        .NET Core 2.0 runtime-only on Linux
+        .NET Core 2.1 multi-architecture: Supports Linux and Windows Nano Server depending on the Docker host.
 
--   microsoft/**dotnet:2.0.0-runtime-nanoserver-1709** 
-
-        .NET Core 2.0 runtime-only on Windows Nano Server (Windows Server 2016 Fall Creators Update version 1709)
-
--   microsoft/**aspnetcore:2.0**
+-   microsoft/**dotnet:2.1-aspnetcore-runtime**
 
-        .NET Core 2.0 multi-architecture: Supports Linux and Windows Nano Server depending on the Docker host.
+        ASP.NET Core 2.1 multi-architecture: Supports Linux and Windows Nano Server depending on the Docker host.
         The aspnetcore image has a few optimizations for ASP.NET Core. 
 
+-   microsoft/**dotnet:2.1-aspnetcore-runtime-alpine** 
+
+        .NET Core 2.1 runtime-only on Linux Alpine distro
+
+-   microsoft/**dotnet:2.1-aspnetcore-runtime-nanoserver-1803** 
+
+        .NET Core 2.1 runtime-only on Windows Nano Server (Windows Server version 1803)
 
 
 

docs/standard/microservices-architecture/multi-container-microservice-net-applications/media/image2.png

@@ -3,7 +3,7 @@ title: When to choose .NET Framework for Docker containers
 description: .NET Microservices Architecture for Containerized .NET Applications | When to choose .NET Framework for Docker containers
 author: CESARDELATORRE
 ms.author: wiwagn
-ms.date: 10/18/2017
+ms.date: 06/07/2018
 ---
 # When to choose .NET Framework for Docker containers
 
@@ -17,15 +17,15 @@ In most cases for this scenario, you will not need to migrate your existing appl
 
 ## Using third-party .NET libraries or NuGet packages not available for .NET Core
 
-Third-party libraries are quickly embracing the [.NET Standard](../../net-standard.md), which enables code sharing across all .NET flavors, including .NET Core. With the .NET Standard Library 2.0 and beyond the API surface compatibility across different frameworks has become significantly larger and in .NET Core 2.0 applications can also directly reference existing .NET Framework libraries (see [compat shim](https://github.com/dotnet/standard/blob/master/docs/faq.md#how-does-net-standard-versioning-work)).
+Third-party libraries are quickly embracing the [.NET Standard](../../net-standard.md), which enables code sharing across all .NET flavors, including .NET Core. With the .NET Standard Library 2.0 and beyond, the API surface compatibility across different frameworks has become significantly larger and in .NET Core 2.x applications can also directly reference existing .NET Framework libraries (see [compat shim](https://github.com/dotnet/standard/blob/master/docs/faq.md#how-does-net-standard-versioning-work)).
 
 However, even with that exceptional progression since .NET Standard 2.0 and .NET Core 2.0, there might be cases where certain NuGet packages need Windows to run and might not support .NET Core. If those packages are critical for your application, then you will need to use .NET Framework on Windows Containers.
 
 ## Using .NET technologies not available for .NET Core 
 
-Some .NET Framework technologies are not available in the current version of .NET Core (version 2.0 as of this writing). Some of them will be available in later .NET Core releases (.NET Core 2.x), but others do not apply to the new application patterns targeted by .NET Core and might never be available.
+Some .NET Framework technologies are not available in the current version of .NET Core (version 2.1 as of this writing). Some of them will be available in later .NET Core releases (.NET Core 2.x), but others do not apply to the new application patterns targeted by .NET Core and might never be available.
 
-The following list shows most of the technologies that are not available in .NET Core 2.0:
+The following list shows most of the technologies that are not available in .NET Core 2.1:
 
 -   ASP.NET Web Forms. This technology is only available on .NET Framework. Currently there are no plans to bring ASP.NET Web Forms to .NET Core.
 

docs/standard/microservices-architecture/multi-container-microservice-net-applications/media/image4.png

@@ -3,19 +3,16 @@ title: Official .NET Docker images
 description: .NET Microservices Architecture for Containerized .NET Applications | Official .NET Docker images
 author: CESARDELATORRE
 ms.author: wiwagn
-ms.date: 10/18/2017
+ms.date: 06/06/2018
 ---
 # Official .NET Docker images
 
 The Official .NET Docker images are Docker images created and optimized by Microsoft. They are publicly available in the Microsoft repositories on [Docker Hub](https://hub.docker.com/u/microsoft/). Each repository can contain multiple images, depending on .NET versions, and depending on the OS and versions (Linux Debian, Linux Alpine, Windows Nano Server, Windows Server Core, etc.).
 
-Microsoft’s vision for .NET repositories is to have granular and focused repos, where a repo represents a specific scenario or workload. For instance, the [microsoft/aspnetcore](https://hub.docker.com/r/microsoft/aspnetcore/) images should be used when using ASP.NET Core on Docker, because those ASP.NET Core images provide additional optimizations so containers can start faster.
-
-On the other hand, the .NET Core images (microsoft/dotnet) are intended for console apps based on .NET Core. For example, batch processes, Azure WebJobs, and other console scenarios should use .NET Core. Those images do not include the ASP.NET Core stack, resulting in a smaller container image.
+Since .NET Core 2.1, all the .NET Core images, including for ASP.NET Core are available at Docker Hub at the [.NET Core image repo](https://hub.docker.com/r/microsoft/dotnet/).
 
 Most image repos provide extensive tagging to help you select not just a specific framework version, but also to choose an OS (Linux distro or Windows version).
 
-For further information about the official .NET Docker images provided by Microsoft, see the [.NET Docker Images summary](https://aka.ms/dotnetdockerimages).
 
 ## .NET Core and Docker image optimizations for development versus production
 
@@ -29,27 +26,27 @@ Why multiple images? When developing, building, and running containerized applic
 
 ### During development and build
 
-During development, what is important is how fast you can iterate changes, and the ability to debug the changes. The size of the image is not as important as the ability to make changes to your code and see the changes quickly. Some tools and "build-agent containers", use the development ASP.NET Core image (microsoft/aspnetcore-build) during development and build process. When building inside a Docker container, the important aspects are the elements that are needed in order to compile your app. This includes the compiler and any other .NET dependencies, plus web development dependencies like npm, Gulp, and Bower.
+During development, what is important is how fast you can iterate changes, and the ability to debug the changes. The size of the image is not as important as the ability to make changes to your code and see the changes quickly. Some tools and "build-agent containers", use the development ASP.NET Core image (**microsoft/dotnet:2.1-sdk**) during development and build process. When building inside a Docker container, the important aspects are the elements that are needed in order to compile your app. This includes the compiler and any other .NET dependencies, plus web development dependencies.
 
-Why is this type of build image important? You do not deploy this image to production. Instead, it is an image you use to build the content you place into a production image. This image would be used in your continuous integration (CI) environment or build environment. For instance, rather than manually installing all your application dependencies directly on a build agent host (a VM, for example), the build agent would instantiate a .NET Core build image with all the dependencies required to build the application. Your build agent only needs to know how to run this Docker image. This simplifies your CI environment and makes it much more predictable.
+Why is this type of build image important? You do not deploy this image to production. Instead, it is an image you use to build the content you place into a production image. This image would be used in your continuous integration (CI) environment or build environment when using Docker Multi-stage builds.
 
 ### In production
 
-What is important in production is how fast you can deploy and start your containers based on a production .NET Core image. Therefore, the runtime-only image based on [microsoft/aspnetcore](https://hub.docker.com/r/microsoft/aspnetcore/) is small so that it can travel quickly across the network from your Docker registry to your Docker hosts. The contents are ready to run, enabling the fastest time from starting the container to processing results. In the Docker model, there is no need for compilation from C\# code, as there is when you run dotnet build or dotnet publish when using the build container.
+What is important in production is how fast you can deploy and start your containers based on a production .NET Core image. Therefore, the runtime-only image based on **microsoft/dotnet:2.1-aspnetcore-runtime** is small so that it can travel quickly across the network from your Docker registry to your Docker hosts. The contents are ready to run, enabling the fastest time from starting the container to processing results. In the Docker model, there is no need for compilation from C\# code, as there is when you run dotnet build or dotnet publish when using the build container.
 
 In this optimized image you put only the binaries and other content needed to run the application. For example, the content created by dotnet publish contains only the compiled .NET binaries, images, .js, and .css files. Over time, you will see images that contain pre-jitted packages.
 
 Although there are multiple versions of the .NET Core and ASP.NET Core images, they all share one or more layers, including the base layer. Therefore, the amount of disk space needed to store an image is small; it consists only of the delta between your custom image and its base image. The result is that it is quick to pull the image from your registry.
 
 When you explore the .NET image repositories at Docker Hub, you will find multiple image versions classified or marked with tags. These tags help to decide which one to use, depending on the version you need, like those in the following table:
 
--   microsoft/**aspnetcore:2.0**
+-   microsoft/dotnet:**2.1-aspnetcore-runtime**
 
         ASP.NET Core, with runtime only and ASP.NET Core optimizations, on Linux and Windows (multi-arch)
 
--   microsoft/**aspnetcore-build:2.0**
+-   microsoft/**dotnet:2.1-sdk**
 
-        ASP.NET Core, with SDKs included, on Linux and Windows (multi-arch)
+        .NET Core, with SDKs included, on Linux and Windows (multi-arch)
 
 
 >[!div class="step-by-step"]