容器和DevOps：基于容器的DevOps交付管道
❝本文翻译自：https://www.bmc.com/blogs/devops-containers/
❞
DevOps 的出现是为了满足不断增长的市场和消费者对技术应用程序的需求。它旨在在不牺牲软件质量的情况下创建更快的开发环境。DevOps 还专注于在快速开发生命周期中提高软件的整体质量。它依赖于多种技术、平台和工具的组合来实现所有这些目标。
容器化是一项彻底改变了我们开发、部署和管理应用程序方式的技术。在这篇博文中，我们将了解容器如何融入 DevOps 世界，以及基于容器的 DevOps 交付管道的优缺点。
什么是容器化应用程序？
虚拟化帮助用户创建共享硬件资源的虚拟环境。容器化通过共享操作系统内核使这种抽象更进一步。
这导致了将软件代码和所有必需的依赖项捆绑在一起的轻量级和固有的可移植对象（容器）。然后可以将这些容器部署在任何受支持的基础架构上，只需最少的外部配置或不需要外部配置。
传统部署中最复杂的部分之一是使用所有依赖项和配置来部署环境。容器化应用程序消除了这些配置要求，因为容器将应用程序所需的一切都打包在容器中。
最重要的是，与虚拟机相比，容器将需要更少的资源并且可以轻松管理。通过这种方式，容器化大大简化了部署策略，可以轻松实现自动化并集成到 DevOps 交付管道中。当它与 Kubernetes 或 Rancher 等编排平台结合使用时，用户可以：
利用这些平台的优势来管理应用程序的整个生命周期
提供更高的可用性、可扩展性、性能和安全性
什么是持续交付管道？
DevOps 依赖持续交付(CD) 作为管理软件交付的核心流程。它使软件开发团队能够更频繁地部署软件，同时保持系统的稳定性和可靠性。
持续交付利用 CI/CD 平台、测试工具等一系列工具，结合自动化来促进频繁的软件交付。通过自动化管道的所有可能任务，从测试、基础设施配置甚至部署，自动化在这些持续交付管道中发挥着重要作用。
在大多数情况下，持续交付与持续集成相结合以创建更强大的交付管道，称为 CI/CD 管道。它们使组织能够将完整的软件开发过程集成到 DevOps 管道中：
持续集成确保所有代码更改都集成到交付管道中。
持续交付可确保正确测试新更改并最终部署到生产中。
两者对于成功的 DevOps 交付管道都至关重要。
这一切是如何结合在一起的？
现在我们了解了容器化应用程序和交付管道，让我们看看这两者如何相互关联以更有效地交付软件。
传统的 DevOps 管道
首先，让我们看看传统的 DevOps 管道。一般来说，传统的交付管道将包括以下步骤。
开发软件并将新更改集成到集中存储库中。（版本控制工具在这里发挥作用。）
验证代码并合并更改。
使用新的代码更改构建应用程序。
为测试环境提供所有配置和依赖项并部署应用程序。
进行测试。（这可以根据要求进行自动化和手动测试）
完成所有测试后，在生产中部署应用程序。（这再次需要提供资源并使用运行应用程序所需的任何其他配置来配置依赖项。）
上述大部分任务都可以自动化，包括使用Terraform、CloudFormation等IaC 工具配置基础设施，使用 AWS Elastic Beanstalk 和 Azure App Service 等平台可以简化部署。然而，所有这些自动化任务仍然需要仔细的配置和管理，使用特定于供应商的工具将导致供应商锁定。
容器化交付管道
容器化应用程序部署使我们能够以更少的管理开销来简化交付管道。一个典型的容器化管道可以总结为以下步骤。
使用版本控制系统开发和集成更改。
验证并合并代码更改。
构建容器镜像。（在此阶段，代码存储库包含应用程序代码以及用于构建容器的所有必要配置文件和依赖项。）
将容器部署到测试环境。
进行应用测试。
使用同一个容器镜像将容器部署到生产环境。
正如您在上图中所看到的，容器化应用程序管道有效地消除了大多数常规基础设施和环境配置要求。但是，主要记住的是，「必须事先配置容器部署环境」。在大多数情况下，这种环境涉及：
一个容器编排平台，如 Kubernetes 或 Rancher
特定于平台的编排服务，如 Amazon Elastic Container Service (ECS)、AWS Fargate、Azure 容器服务等。
容器包括所有应用程序依赖项和配置。它减少了与配置问题相关的任何错误，并允许交付团队在不同的环境（例如测试和生产）之间快速迁移这些容器。此外，容器化大大减少了故障排除的范围，因为开发人员只需要深入挖掘容器内的应用程序，而几乎不受外部配置或服务的影响。
现代应用程序架构（例如基于微服务的架构）非常适合容器化，因为它们将应用程序功能解耦到不同的服务。容器化允许用户将这些服务作为独立的个体实体进行管理，而无需依赖任何外部配置。
即使使用容器也会有基础设施管理要求，认为容器确实简化了这些要求。最突出的基础设施管理要求将同时管理：
容器编排平台
外部服务，如负载平衡器和防火墙
但是，使用 Amazon Elastic Kubernetes Service (EKS) 或 Azure Kubernetes Service (AKS) 等托管容器编排平台无需管理容器编排平台的基础设施。这些平台进一步简化了交付管道，并允许 Kubernetes 用户使用它们而不会被供应商锁定，因为它们基于 Kubernetes。
DevOps 交付管道中的容器编排
容器编排与容器化应用程序齐头并进，因为容器化只是整个容器革命的一部分。容器编排是在容器的整个生命周期中管理容器的过程，从部署容器到管理可用性和扩展。
虽然有许多编排平台，但 Kubernetes 是最流行的选择之一，得到了全行业的支持。它几乎可以为任何环境提供动力，从单节点集群到多云集群。编排平台在容器的整个生命周期中管理容器的能力，同时确保可用性消除了手动干预来管理容器的需要。
如前所述，使用与平台无关的编排平台可以防止供应商锁定，同时允许用户利用托管解决方案并通过单一平台支持多云架构。
容器是否适合您的 DevOps 交付管道？
答案是肯定的。容器化几乎可以使所有应用程序开发受益：
DevOps 简化了快速开发和交付，同时增加了团队协作并提高了整体应用程序质量。
容器允许用户在 DevOps 交付管道中利用容器的所有优势，而不会妨碍核心 DevOps 实践，从而帮助进一步简化 DevOps 交付过程。
容器可以支持任何环境，无论编程语言、框架、部署策略等如何，同时为交付团队提供更大的灵活性，可以在不影响交付过程的情况下定制他们的环境。
往期推荐
DevOps 的未来：2022年及以后的6大趋势
GitLabCI/CD: 内置仓库轻松实现代码基线与制品关联
总结2021的DevOps实践|开源一份实践手册
使用 Traefik 中间件处理 Log4J 漏洞
GitLabCI模板库的流水线优化实践