Containerized lifecycle/consolidated updates (#19798)

* Add cover page

* Update images to VS 2019

* General update of the VS Code-related docker workflow

* Update and fix extension case

* Update process and images

* Update aks creation parameters for sample/dev app

* General update of the article

* Delete moved image

* Fix markdownlint error - Image alt text

* Update to restart pipeline b/c of error 500

* Including changes from PR #17865 and #17879

* containerized-lifecycle-3.1/3.1-index

* MIssing hypen fixes on the cover page.

* Consolidated updates on containerized-lifecycle e-book files.

* Fixed broken link of container entry point.

* Removed net core 2.2 reference

* Removed inconsistent spaces in between lines.

* Fixed broken previous & next link.

* Changed cover page image.

* Fixed wrong image number under section - 4

* Update docs/architecture/containerized-lifecycle/Microsoft-platform-tools-containerized-apps/index.md

Accepted suggestions by Nish.

Co-authored-by: Nish Anil <nish@microsoft.com>

* Update docs/architecture/containerized-lifecycle/Microsoft-platform-tools-containerized-apps/index.md

Accepted suggestion.

Co-authored-by: Nish Anil <nish@microsoft.com>

* Update docs/architecture/containerized-lifecycle/design-develop-containerized-apps/visual-studio-tools-for-docker.md

Accepted suggestion.

Co-authored-by: Nish Anil <nish@microsoft.com>

* Update docs/architecture/containerized-lifecycle/design-develop-containerized-apps/build-aspnet-core-applications-linux-containers-aks-kubernetes.md

Accepted suggestion.

Co-authored-by: Nish Anil <nish@microsoft.com>

* Included reviewer and participant name.

* Updated ms.date in all pages.

* Updated Azure CLI installation section for AKS

* Changed conversation context to second person.

* Removed Preview information

* Missing hypen related fixes.

* Removed Trailing Spaces

* Removed en-us from the link.

* Fixed broken link and rephrased sentence.

* Fixed Docker Desktop broken link.

* Fixed broken link.

* Rephrased AKS interaction segment.

* Rephrased sentence

* Update docs/architecture/containerized-lifecycle/design-develop-containerized-apps/build-aspnet-core-applications-linux-containers-aks-kubernetes.md

* Update docs/architecture/containerized-lifecycle/design-develop-containerized-apps/deploy-azure-kubernetes-service.md

* Included review comments.

* Updated table.

Co-authored-by: Miguel Veloso <mvelosop@gmail.com>
Co-authored-by: Nish Anil <nish@microsoft.com>

docs/architecture/containerized-lifecycle/Docker-application-lifecycle/containers-foundation-for-devops-collaboration.md

@@ -1,7 +1,7 @@
 ---
 title: Containers as the foundation for DevOps collaboration
 description: Understand the key role of containers to streamline DevOps.
-ms.date: 04/16/2020
+ms.date: 08/06/2020
 ---
 # Containers as the foundation for DevOps collaboration
 
@@ -21,27 +21,27 @@ In the pillar on the right, operations teams manage deployed applications and in
 
 The two teams are collaborating through a foundational platform (Docker containers) that provides a separation of concerns as a contract, while greatly improving the two teams' collaboration in the application life cycle. The developers own the container contents, its operating environment, and the container interdependencies, whereas the operations teams take the built images along with the manifest and runs them in their orchestration system.
 
-## Challenges in application life cycle when using Docker.
+## Challenges in the application life cycle when using Docker.
 
 There are many reasons that will increase the number of containerized applications in the upcoming years, and one of these reasons is the creation of applications based on microservices.
 
-During the last 15 years, the use of web services has been the base of thousands of applications, and probably, after a few years, we'll find the same situation with microservice-based applications running on Docker containers.
+During the last 15 years, the use of web services has been the base of thousands of applications, and probably, after a few years, you'll find the same situation with microservice-based applications running on Docker containers.
 
 It is also worth to mention that you can also use Docker containers for monolithic applications and you still get most of the benefits of Docker. Containers are not targeting only microservices.
 
 The use of Docker containerization and microservices causes new challenges in the development process of your organizations and therefore, you need a solid strategy to maintain many containers and microservices running on production systems. Eventually, enterprise applications will have hundreds or thousands of containers/instances running in production.
 
-These challenges create new demands when using DevOps tools, so you'll have to define new processes in your DevOps activities, and find answers for this type of questions:
+These challenges create new demands when using DevOps tools, so you'll have to define new processes in your DevOps activities, and find answers for the following type of questions:
 
-- Which tools can I use for development, for CI/CD, management and operations?
+- Which tools can I use for development, CI/CD, management and operations??
 
 - How can my company manage errors in containers when running in production?
 
 - How can we change pieces of our software in production with minimum downtime?
 
-- How can we scale and how can we monitor our production system?
+- How can we scale and monitor our production system?
 
-- How can we include testing and deployment of containers in our release pipeline?
+- How can we include the testing and deployment of containers in our release pipeline?
 
 - How can we use Open Source tools/platforms for containers in Microsoft Azure?
 
@@ -57,9 +57,9 @@ Figure 2-2 presents a more detailed workflow for a Docker application life cycle
 
 Everything begins with the developer, who starts writing code in the inner-loop workflow. The inner-loop stage is where developers define everything that happens before pushing code into the code repository (for example, a source control system such as Git). After it's committed, the repository triggers Continuous Integration (CI) and the rest of the workflow.
 
-The inner loop basically consists of typical steps like "code," "run," "test," and "debug," plus the additional steps needed right before running the app locally. This is the developer's process to run and test the app as a Docker container. The inner-loop workflow will be explained in the sections that follow.
+The inner loop consists of typical steps like "code," "run," "test," and "debug," plus the additional steps needed right before running the app locally. This is the developer's process to run and test the app as a Docker container. The inner-loop workflow will be explained in the sections that follow.
 
-Taking a step back to look at the end-to end workflow, the DevOps workflow is more than a technology or a tool set: it's a mindset that requires cultural evolution. It's people, processes, and the appropriate tools to make your application life cycle faster and more predictable. Enterprises that adopt a containerized workflow typically restructure their organizations to represent people and processes that match the containerized workflow.
+Taking a step back to look at the end-to-end workflow, the DevOps workflow is more than a technology or a tool set, it's a mindset that requires cultural evolution. It's people, processes, and the appropriate tools to make your application life cycle faster and more predictable. Enterprises that adopt a containerized workflow typically restructure their organizations to represent people and processes that match the containerized workflow.
 
 Practicing DevOps can help teams respond faster together to competitive pressures by replacing error-prone manual processes with automation, which results in improved traceability and repeatable workflows. Organizations also can manage environments more efficiently and realize cost savings with a combination of on-premises and cloud resources as well as tightly integrated tooling.
 

docs/architecture/containerized-lifecycle/Docker-application-lifecycle/index.md

@@ -1,7 +1,7 @@
 ---
 title: Introduction to the Docker application life cycle
 description: Begin here the journey of containerized application development.
-ms.date: 11/23/2018
+ms.date: 08/06/2020
 ---
 # Introduction to the Docker application life cycle
 

docs/architecture/containerized-lifecycle/Microsoft-platform-tools-containerized-apps/index.md

@@ -1,45 +1,43 @@
 ---
 title: Introduction to the Microsoft platform and tools for containerized apps
 description: Get to know Microsoft's offerings to support Docker applications lifecycle.
-ms.date: 02/15/2019
+ms.date: 08/06/2020
 ---
 # Introduction to the Microsoft platform and tools for containerized apps
 
 *Vision: Create an adaptable, enterprise-grade, containerized application life cycle that spans your development, IT operations, and production management.*
 
 Figure 3-1 shows the main pillars in the life cycle of Docker apps classified by the type of work delivered by multiple teams (app-development, DevOps infrastructure processes, and IT management and operations). Usually, in the enterprise, the profiles of "the persona" responsible for each area are different. So are their skills.
 
-:::image type="complex" source="./media/index/microsoft-tools-contanerized-docker-app.png" alt-text="Diagram showing the Microsoft tools needed to maintain Docker apps.":::
-Microsoft tools. For the Develop/Design workload: Docker engine for Windows, Visual Studio and Visual Studio Code, .NET Core, Azure Kubernetes Service. For the Build/Test/Ship workload: Azure DevOps, Team Foundation Server, Docker CLI, Azure Kubernetes Service. For the Run/Monitor/Manage workload: Azure Monitor, Azure portal, Azure Kubernetes Services, Service Fabric, other orchestrators.
-:::image-end:::
+![Add new project window in Visual Studio, selecting ASP.NET Core Web Application.](media/index/microsoft-tools-contanerized-docker-app.png)
 
 **Figure 3-1.** Main pillars in the life cycle for containerized Docker applications with Microsoft platform and tools
 
-A containerized Docker life-cycle workflow can be initially prescriptive based on "by-default product choices," making it easier for developers to get started faster, but it's fundamental that under the hood there must be an open framework so that it will be a flexible workflow capable of adjusting to the different contexts from each organization or enterprise. The workflow infrastructure (components and products) must be flexible enough to cover the environment that each company will have in the future, even being capable of swapping development or DevOps products to others. This flexibility, openness, and broad choice of technologies in the platform and infrastructure are precisely the Microsoft priorities for containerized Docker applications, as explained in the chapters that follow.
+A containerized Docker life-cycle workflow can be initially prescriptive based on "by-default product choices," making it easier for developers to get started faster, but it's fundamental that under the hood there must be an open framework so that it will be a flexible workflow capable of adjusting to the different contexts from each organization or enterprise. The workflow infrastructure (components and products) must be flexible enough to cover the environment that each company will have in the future, even being capable of swapping development or DevOps products to others. This flexibility, openness, and the broad choice of technologies in the platform and infrastructure are precisely the Microsoft priorities for containerized Docker applications, as explained in the chapters that follow.
 
-Table 3-1 demonstrates that the intention of the Microsoft DevOps for containerized Docker applications is to provide an open DevOps workflow so that you can choose what products to use for each phase (Microsoft or third party) while providing a simplified workflow that provides "by-default-products" already connected; thus, you can quickly get started with your enterprise-level DevOps workflow for Docker apps.
+Table 3-1 demonstrates that the intention of the Azure DevOps for containerized Docker applications is to provide an open DevOps workflow so that you can choose what products to use for each phase (Microsoft or third-party) while providing a simplified workflow that provides "by-default-products" already connected; thus, you can quickly get started with your enterprise-level DevOps workflow for Docker apps.
 
-**Table 3-1.** DevOps workflows, open to any technology
+**Table 3-1.** Azure DevOps workflows, open to any technology
 
-| Host | Microsoft technologies | Third-party—Azure pluggable |
+| Host | Microsoft technologies | Third-party (Azure pluggable) |
 | ---------------------------| ----------------------------------------------------| --------------------------------------------------------------------------------|
-| Platform for Docker apps   | • Microsoft Visual Studio and Visual Studio Code<br /> • .NET<br /> • Microsoft Azure Kubernetes Service (AKS)<br /> • Azure Service Fabric<br /> • Azure Container Registry<br /> | • Any code editor (for example, Sublime)<br /> • Any language (Node.js, Java, Go, etc.)<br /> • Any orchestrator and scheduler<br /> • Any Docker registry<br /> |
-| DevOps for Docker apps     | • Azure DevOps Services<br /> • Microsoft Team Foundation Server<br /> • Azure Kubernetes Service (AKS)<br /> • Azure Service Fabric<br /> | • GitHub, Git, Subversion, etc.<br /> • Jenkins, Chef, Puppet, Velocity, CircleCI, TravisCI, etc.<br /> • On-premises Docker Datacenter, Docker Swarm, Mesos DC/OS, Kubernetes, etc.<br /> |
+| Platform for Docker apps   | • Microsoft Visual Studio and Visual Studio Code<br /> • .NET<br /> • Microsoft Azure Kubernetes Service (AKS)<br /> • Azure Container Registry<br /> | • Any code editor (for example, Sublime)<br /> • Any language (Node.js, Java, Go, etc.)<br /> • Any orchestrator and scheduler<br />  • Any Docker registry<br /> |
+| DevOps for Docker apps     | • Azure DevOps Services<br /> • Microsoft Team Foundation Server<br /> • Azure Kubernetes Service (AKS)<br /> | • GitHub, Git, Subversion, etc.<br /> • Jenkins, Chef, Puppet, Velocity, CircleCI, TravisCI, etc.<br /> • On-premises Docker Datacenter, Kubernetes, Mesos DC/OS, etc.<br /> |
 | Management and monitoring  | • Azure Monitor | • Marathon, Chronos, etc.<br />|
 
 The Microsoft platform and tools for containerized Docker apps, as defined in Table 3-1, comprise the following components:
 
 - **Platform for Docker Apps development** The development of a service, or collection of services that make up an "app." The development platform provides all the work developers requires prior to pushing their code to a shared code repository. Developing services, deployed as containers, are similar to the development of the same apps or services without Docker. You continue to use your preferred language (.NET, Node.js, Go, etc.) and preferred editor or IDE like Visual Studio or Visual Studio Code. However, rather than consider Docker a deployment destination, you develop your services in the Docker environment. You build, run, test, and debug your code in containers locally, providing the destination environment at development time. By providing the destination environment locally, Docker containers set up what will drastically help you improve your DevOps life cycle. Visual Studio and Visual Studio Code have extensions to integrate Docker containers within your development process.
 
-- **DevOps for Docker Apps** Developers creating Docker applications can use [Azure DevOps Services](https://azure.microsoft.com/services/devops/) or any other third-party product, like Jenkins, to build out a comprehensive automated application life-cycle management (ALM).
+- **DevOps for Docker Apps** Developers creating Docker applications can use [Azure DevOps](https://azure.microsoft.com/services/devops/) or any other third-party product, like Jenkins, to build out a comprehensive automated application life-cycle management (ALM).
 
-  With Azure DevOps Services, developers can create container-focused DevOps for a fast, iterative process that covers source-code control from anywhere (Azure DevOps Services-Git, GitHub, any remote Git repository, or Subversion), Continuous Integration (CI), internal unit tests, inter-container/service integration tests, Continuous Delivery (CD), and release management (RM). Developers can also automate their Docker application releases into Azure Kubernetes Service (AKS), from development to staging and production environments.
+  With Azure DevOps, developers can create container-focused DevOps for a fast, iterative process that covers source-code control from anywhere (Azure DevOps-Git, GitHub, any remote Git repository, or Subversion), Continuous Integration (CI), internal unit tests, inter-container/service integration tests, Continuous Delivery (CD), and release management (RM). Developers also can automate their Docker application releases into Azure Kubernetes Service (AKS), from development to staging and production environments.
 
 - **Management and Monitoring** IT can manage and monitor production applications and services in several ways, integrating both perspectives in a consolidated experience.
 
-  - **Azure portal** If you're using open-source orchestrators, Azure Kubernetes Service (AKS), Service Fabric and other orchestrators help you to set up and maintain your Docker environments. If you're using Azure Service Fabric, the Service Fabric Explorer tool makes it possible for you to visualize and configure your cluster.
+  - **Azure portal** Azure Kubernetes Service (AKS) helps you to set up and maintain your Docker environments. You can also use other orchestrators to visualize and configure your cluster.
 
-  - **Docker tools** You can manage your container applications using familiar tools. There's no need to change your existing Docker management practices to move container workloads to the cloud. Use the application management tools you're already familiar with and connect via the standard API endpoints for the orchestrator of your choice. You can also use other third-party tools to manage your Docker applications, such as Docker Datacenter or even CLI Docker tools.
+  - **Docker tools** You can manage your container applications using familiar tools. There's no need to change your existing Docker management practices to move container workloads to the cloud. Use the application management tools you're already familiar with and connect via the standard API endpoints for the orchestrator of your choice. You also can use other third-party tools to manage your Docker applications or even CLI Docker tools.
 
     Even if you're familiar with Linux commands, you can manage your container applications using Microsoft Windows and PowerShell with a Linux Subsystem command line and the products (Docker, Kubernetes…) clients running on this Linux Subsystem capability. You'll learn more about using these tools under Linux Subsystem using your favorite Microsoft Windows OS later in this book.