目录
很久以前，在互联网时代的早期，世界上最大的零售商投入巨资建立他们的网络运营，并在蓬勃发展的在线市场中挖掘许多机会。上线意味着他们可以全天候处理订单，但同时也带来了前所未有的运营挑战。
由于假日购物吸引了许多在线用户，而硬件最终会崩溃，因此这些零售商不得不购买比通常所需更多的服务器。购买一组新服务器非常昂贵，但在销售高峰期失去消费者是这些公司无法承受的风险。
借助VMWare和Virtual Box等产品，虚拟机改变了游戏规则，使公司能够更好地利用硬件资源。在一台主机上运行多个应用程序意味着企业不必购买这么多服务器。这就像运行“计算机中的计算机”。
尽管如此，虚拟化仍有其挑战。开发人员在他们的本地机器上工作，这可能与他们部署到的虚拟机不同。环境之间的这种不匹配导致了可怕的“在我的机器上工作”的借口和沮丧的开发人员，因为他们不得不担心在应用程序之外发生的故障。
虚拟机后来让位于容器化，尽管容器背后的想法并不新鲜。早在1979年，chroot系统就在Unix系统中引入了进程隔离和文件访问隔离。2000年，FreeBSD jails将Linux计算机划分为更小的系统，2005年，OpenVZ使用Linux Kernel进行系统虚拟化和隔离。然后，在2008年，Linux Kernel引入了控制组。
这些都是朝着我们今天使用的容器迈出的一步。最终，Docker在竞争中脱颖而出，原因有很多，包括面向开发人员的工具、易于配置、出色的可移植性和强大的管理生态系统。
现代容器的兴起
随着Docker的普及，容器化席卷了IT行业。容器与VM类似，但没有客户操作系统(OS)，因此包更简单。
开发人员的“在我的机器上工作”的借口不再是问题，因为应用程序及其依赖项都是自包含的，并被运送到称为容器镜像的同一个单元中。镜像是应用程序的可部署副本，而从这些镜像创建的容器实例通常在Azure等云平台中运行。
新架构缺少管理程序，因为不再需要它。但是，我们仍然需要管理新的容器，因此引入了容器引擎的概念。
容器是不可变的，这意味着您无法在其生命周期内更改容器镜像：您无法应用更新、补丁或配置更改。如果您必须更新您的应用程序，您应该构建一个新镜像（它本质上是一个现有容器镜像之上的变更集）并重新部署它。不变性使容器部署变得简单和安全，并确保部署的应用程序始终按预期工作，无论在哪里。
与虚拟机相比，新容器极其轻巧便携。此外，容器启动速度要快得多。由于体积小，容器有助于最大限度地利用主机操作系统及其资源。
您可以在Docker容器中运行Linux和Windows程序。Docker平台在Linux和Windows上本地运行，Docker的工具使开发人员能够在Linux、Windows和macOS上构建和运行容器。
您不能使用容器来运行本地文件系统上的应用程序。但是，您可以使用绑定挂载和卷访问Docker容器外部的文件。它们很相似，但绑定挂载可以指向主机上的任何目录，并且不由Docker直接管理。
Docker容器在Linux上访问物理主机硬件，如GPU，但不在Windows上。这是因为Linux上的Docker直接在内核上运行，而Windows上的Docker工作在虚拟机中，因为Windows没有Linux内核可以直接与之通信。
容器：从编码到部署
假设您正在开发一个容器化电子商务应用程序。作为开发人员，您可以将应用程序构建到容器中。接下来，您编写一个docker文件，其中包含在容器中为每个应用程序或服务设置和运行应用程序所需的命令。然后，您编写一个docker-compose.yml文件来设置多容器Docker应用程序中不同容器应用程序和服务之间的关系。
通过执行指定本地端口的docker run命令，然后在浏览器中打开http://localhost:[PORT]，您可以在开发机器上本地运行和测试容器。
要构建和运行您的应用程序，您可以将其部署到Docker主机（VM或物理服务器），或将其部署为组合应用程序，使用单个命令行界面 (CLI) 命令或集成开发环境(IDE) )像Visual Studio。
一旦您的应用程序或服务经过测试，构建过程就会生成一个或多个容器镜像。但是怎么处理它们呢？这就是Azure Container Registry或Docker Hub之类的存储库的用武之地：生成容器镜像后，开发人员将它们推送到公共或私有注册表。然后，他们可以将镜像拉入数据中心、云中或应用程序可以运行的任何其他地方。
要了解如何实现使用GitHub操作将镜像推送到容器注册表的持续集成和持续部署(CI/CD)，请关注此YouTube播放列表：使用GitHub操作构建CI/CD工作流。
使用注册表的一些优点是：
- 您可以严格控制谁可以访问您的图像以及它们的存储位置。
- 注册表可以是您要运行的图像的唯一真实来源。
- 您可以根据需要扫描容器中的漏洞。
假设您的应用程序或服务可以在没有编排的独立容器中运行。在这种情况下，您可以使用Azure容器实例(ACI)等解决方案手动或从开发管道直接从容器注册表将镜像部署到生产中。
超越部署：使用Kubernetes进行编排
当公司开始将他们的解决方案迁移到容器时，他们意识到扩展应用程序并非易事。该Kubernetes平台很快涌现了作为黄金标准来运行应用程序集装箱化，从建立想要探索集装箱业务的兴趣空前的激增。
容器编排可以自动执行运行容器化工作负载和服务所需的许多任务，这需要在大型系统中付出巨大努力。Kubernetes通过管理容器的生命周期来解决这一挑战，包括供应、部署、扩展、网络和负载平衡。
当您部署Kubernetes时，您将获得一个集群。Kubernetes集群由一组称为工作器或节点的机器组成，它们在容器中运行应用程序。每个集群必须至少有一个工作节点。在工作节点内，应用程序工作负载沿着称为Pod的组件分布。
集群的控制平面管理工作节点和Pod。在生产环境中，控制平面和集群通常分布在多台机器和节点上，提供高可用性和弹性。
您可以使用minikube或托管Kubernetes服务创建本地Kubernetes集群。Kubernetes是一项复杂的技术，需要足够的安全知识、支持技能、频繁升级和对细节的关注。Azure Kubernetes服务(AKS)等托管Kubernetes服务提供了许多方便的管理功能，可将您从这些重复性任务中解放出来，让您可以专注于您的业务。
使用Kubernetes 的CI/CD管道
让我们看一下CI/CD管道，它将您的代码容器化，将其推送到注册表，然后从那里进入Kubernetes集群中的生产环境。
这一切都始于您的代码。在适当的代码审查、单元测试和其他控制之后，合并请求合并到Git存储库的主分支中。这会触发一个事件，导致构建管道将您的应用程序构建到容器镜像中。然后生成管道将这些镜像推送到Azure容器注册表(ACR)。
可以为Azure容器注册表中创建的每个对象定义策略、合规性和规则。然后CI/CD管道从ACR中提取容器镜像，并将它们作为Pod部署在Kubernetes集群中的工作节点内。容器镜像可以复制到多个工作节点内的多个Pod中，具体取决于您在部署配置文件中定义的副本数。
从现在开始，您的新代码已经在Kubernetes集群上的生产环境中运行。每当您向Git存储库提交新代码时，构建管道都会重复该过程。
Kubernetes的工作原理是将一组虚拟机或物理机转换为统一的API接口，供开发人员与之交互的容器使用，并编排他们的应用程序，而不管底层物理机是什么。
在Kubernetes中，您的容器位于Pods中，Pods是最小的部署单元。Kubernetes的ReplicationController有助于确保您的应用程序跨节点的Pod健康。当您定义所需数量的Pod副本时，ReplicationController保证该副本数量始终保持不变。因此，当Pod发生故障时，控制器会注意到并在集群中的其他位置启动一个Pod。
Azure Kubernetes服务使你能够通过自动调整运行工作负载的节点数量来维护高效、经济高效的群集。集群自动伸缩组件检测资源限制何时发生，因此节点池中的节点数量会增加以满足您的应用程序需求。同样，当需求下降时，节点数量也会减少，因此您无需为未使用的云资源付费。
除了在Kubernetes集群中创建额外的节点和Pod之外，您还必须确保这些新资源的使用程度与现有资源相同。负载平衡组件（例如Azure负载平衡器）从AKS虚拟网络内部或外部分发流，成功扩展应用程序并创建高度可用的服务。
下一步
您刚刚了解了容器为何如此重要的旋风之旅：目前，它们似乎是企业应用程序部署的未来。随着技术的成熟，越来越多的开发人员和DevOps团队将从容器化提高的可移植性、可扩展性和效率中受益。
想了解更多？探索以下资源：
- 学习使用Kubernetes构建和管理基于容器的应用程序。获取这本免费的三本电子书包，以在一个地方学习Kubernetes的基础知识。
- 使用Azure上的Kubernetes加速开发。通过在此Packt电子书中学习如何大规模部署和管理容器集群开始。
- 容器是云原生应用开发的基础。云原生应用程序基于微服务。每个应用程序都包含彼此独立运行的小型服务，利用持续交付来实现可靠性和更快的上市时间。
- 了解如何使用公共负载均衡器通过Azure Kubernetes服务(AKS)公开您的服务。
Creating a Complete Serverless Cloud Native Application on Azure - CodeProject