与 IT 领导者关于“容器”的讨论通常可以总结为以下几点：
作为一位 CxO，我面临着以更少的资源做更多事情的持续挑战。IT 预算持续减少，我的资源也越来越少，但需要交付的工作量却比以往任何时候都更大。我花费了太多时间来解决预算约束问题。此外，IT 格局正在经历快速变化，新技术层出不穷。我从信任的顾问那里听到的最新话题是实施“容器战略”。我想了解：
- 什么是容器？
- 过渡到容器的企业价值是什么？
- 为什么我现在应该转向容器？如果我们不采用，会有什么缺点吗？
- 容器是否足够成熟，可以供企业使用？
- 我如何让我的企业快速掌握容器的采用？
让我们从头开始。
容器
在过去的 10 年左右，企业已经从物理基础设施转向虚拟机 (VM)。转向 VM 的主要优势是减少了数据中心的占地面积。通过在同一物理机箱上运行多个 VM，您可以在更少的物理机器上安装更多应用程序。使用容器是另一种以更轻量级和更快的交付模型打包应用程序的方式。它们是在单个机箱上运行多个应用程序进程的一种巧妙方法，无论该机箱是 VM 还是物理机器。此外，容器在实现 DevOps、微服务和云战略方面也发挥着重要作用。
容器与 VM 的比较
容器与 VM 在一些简单方面有所不同。VM 虽然不是物理机器，但其行为方式与物理机器完全一样。它是一个隔离的环境，包含一切，从完整的（访客）操作系统开始。另一方面，容器是在同一机器上共享资源的进程，该机器可以是物理的或虚拟的。容器尤其有趣，因为：
- VM 相对来说很重。容器很轻，因为它们只包含其运行的应用程序所需的库。
- VM 启动需要几分钟。容器在几秒钟内启动。
- 通常，您的基础设施中可以容纳比 VM 更多的容器。
该技术已经发展到足以保持这些容器的安全，彼此隔离，并且通过“正确的设计选择”来确保不良容器不会影响在同一机箱上运行的其他容器的性能。实际上，操作系统旨在优化和原生运行容器。
尽管如此，在转向容器时，您需要做出正确的选择。您需要进行充分的尽职调查，以便选择合适的技术合作伙伴和供应商来启用容器。开源技术发挥着关键作用。开源 Docker 项目 使容器具有易于构建和使用的分层格式。开放容器倡议 (OCI) 已成为所有主要技术供应商支持的容器开源标准。Red Hat 等开源技术提供商提供容器就绪、安全的操作系统。例如，Red Hat Enterprise Linux 7.x，包括 Red Hat Enterprise Linux Atomic Host，经过优化可以原生运行容器，并提供工具来监控和管理容器。来自 Tectonic 的 CoreOS 等其他开源项目也正在进入市场。事实上，容器已准备好被企业采用。
容器平台
容器平台使容器可供企业使用。在过去十年中，您可能已经处理了企业中的 VM 蔓延问题，而容器蔓延可能会严重得多。跨数据中心中的各种主机大规模运行容器，确保应用程序的高可用性（尽管容器发生故障）、自动运行状况检查、基于传入工作负载自动扩展容器等，是您可以从容器平台获得的一些关键功能。
虽然在此类平台上运行容器被定位为容器即服务 (CaaS) 模型，但这些平台的一些附加功能（例如构建和部署自动化）使该平台成为成熟的平台即服务 (PaaS)。虽然 CaaS 可以大规模为您运行容器，但 PaaS 会获取您的源代码、构建它、创建容器并为您运行这些容器。此外，这些平台还提供完整的运营管理功能，例如集群的管理和监控、检测容器中的安全漏洞并运行安全容器、跟踪日志和指标等。
虽然一些供应商正在使用其专有技术来构建容器平台，但总的来说，公司正在围绕基于 Kubernetes（或简称 K8S）构建的开源技术对其进行标准化。K8S 是 Google 启动的一个开源项目，许多大型平台供应商现在都支持它。K8S 也是 云原生计算基金会 (CNCF) 的一部分，CNCF 正在发展成为云中心技术的标准机构。当您在容器平台上做出选择时，围绕开源编排技术的标准化非常重要。如果您不喜欢第一次的选择，它基本上允许您在容器平台之间移植。K8S 还允许您的容器工作负载在不同的公共云之间移植。这些是我们看到越来越多的技术公司使用 Kubernetes 的原因。
一些企业正尝试通过将包括 K8S 在内的几个开源项目拼接在一起来构建自己的 DIY 容器平台。这绝对比使用专有技术更好，但它也包括很多管道工作才能使其正常工作。但是，应认真考虑企业维持和维护此类 DIY 平台的能力。许多企业的工作不是创建 IT 平台，而是希望运营其主流业务。有许多基于 K8S 的解决方案可用，例如 Red Hat 的 OpenShift 容器平台、Apprenda、Deis、Rancher 等，它们提供企业就绪版本的平台，每个平台在它们提供的功能方面都有不同的成熟度。
这些解决方案经过供应商认证和支持。其中一些是全面的开源 PaaS 解决方案，而另一些可能是 CaaS。根据您的企业需求，这些解决方案可能比 DIY 容器平台更好。
企业关注的问题及其与容器的关系
如今，几乎每个企业都在进行数字化转型，这影响到多个领域，包括 DevOps、微服务和云战略。容器在这些领域中的每一个领域都发挥着特殊的作用。
DevOps 战略
IT 组织分为运营和应用程序开发部门。它们作为两个独立的团队运作，每个团队都有自己的一套目标。大多数企业都在朝着 DevOps 的方向发展，以将这两个团队 объединить 在一起。
容器在 DevOps 计划的成功中发挥着重要作用。DevOps 的关键成功标准之一是提高开发人员在运营中的股份。开发人员不仅应该将代码移交给运营部门，还应该关心他们的代码在生产环境中的运行方式。常见的技术是将“基础设施即代码”。开发团队不应提供容易出错的安装说明页面，而应提供作为代码的环境设置。
这正是容器解决的问题。容器镜像（容器的模板）包括整个堆栈，从基础操作系统到应用程序代码。借助容器，开发人员不仅可以将应用程序工件（例如 .jar 文件）从开发环境传递到 QA 环境再到生产环境；相反，他们将传递一个版本化的容器镜像，其中包含构建的工件和工件运行的环境。容器是全包的，从操作系统库到中间件再到应用程序都捆绑到一个镜像中。因此，容器在开发环境中运行的方式与在 QA 环境和生产环境中运行的方式完全相同。容器是 DevOps 成功的必要因素。
此外，容器平台更进一步。典型的持续集成和交付 (CICD) 工具（例如 Jenkins）作为容器提供，这些容器在容器平台本身上运行整个 CICD 流程，而无需额外的基础设施。现在，您可以使用 PaaS 平台来构建和运行您的 CICD 管道。
微服务战略
微服务是当今 IT 领域的另一个热门话题。将应用程序分解为离散的、小型服务，每个服务都做得很好，这就是应用程序的设计方式。这些微服务中的每一个都可以使用适合该技术的不同语言编写。它们将由小型（两份披萨就能喂饱的）团队创建和管理，并且可以快速更改。所有这些要求再次暗示了容器。容器足够小，可以成为微服务的基础。容器可以支持您选择的任何技术和语言。它们易于创建和运行，并且可以快速更改。微服务和容器现在被认为是结合在一起的，如果人们谈论在不使用容器的情况下实施微服务，他们通常会得到奇怪的眼神。
现实情况是，虽然微服务承诺简单性，但它们的激增也增加了复杂性。几种微服务设计和部署模式正在兴起，以简化它们的实施。这意味着开发人员现在需要一个平台，他们可以在其中轻松部署和编排这些微服务，并且：
- 以与语言无关的方式实施这些微服务设计模式
- 不会因代码侵入而增加代码的复杂性，以便开发人员必须将大量模式代码包含到他们的业务逻辑中
- 足够灵活，可以部署在您选择的基础设施上，并且不会将您绑定到特定的云
这就是选择合适的容器平台发挥作用的地方。以特定供应商的方式在特定基础设施上实施这些微服务会将您的应用程序绑定到这些供应商平台。使用 OCI 兼容容器等标准技术容器化微服务将确保您的微服务可以在任何 OCI 兼容平台上运行。
选择合适的容器平台来运行您的微服务是另一个重要的决定。今天，选择很少，而且有很多 FUD。如果您在做出此选择时不够勤奋，其中一些选择会将您带入非标准、供应商特定的路线。
云战略
云战略是 IT 领域的另一个热门话题。无论您是否喜欢，“即服务”模型都是不可避免的变化。如果您不从 IT 部门提供此服务，您的开发团队可能会找到创建影子 IT 的方法来访问云。此外，虽然使用云会将您从资本支出转变为运营支出，但管理云支出始终是一项挑战。
云提供 VM，您需要确保在启动其他 VM 之前，此云上的 CPU、内存和网络资源得到最佳利用。容器在这里发挥着重要作用。由于容器比 VM 小得多，并且如果您的应用程序在容器中运行，则您可以在 VM 中容纳比每个 VM 运行一个应用程序组件更多的容器。
公共云供应商数量众多，其中亚马逊网络服务 (AWS)、Microsoft Azure 和 Google Cloud 是其中一些较受欢迎的供应商。此外，您可能希望在您的数据中心中拥有基于 OpenStack 的私有云。这些云环境中的每一个都有自己的协议、API 和工具。虽然您希望您的应用程序在云上运行，但您不希望使您的应用程序编排成为云供应商特定的，并且您不希望维护任何云特定的代码。将您的技术锁定在特定的云供应商中就像在未来几年内给供应商开空头支票。
跨云的可移植性对于您的云战略非常重要。您可以编写您的应用程序，而无需担心它们在哪里运行，并且容器平台会将您与特定的云供应商协议隔离开来，防止您被锁定在一个云供应商中。
遗留系统
微服务架构为开发带来的优势有很多，但并非每个应用程序都可以重构为微服务架构，有些只能部分重构。传统应用程序将继续存在，它们需要维护和管理。虽然容器支持微服务，但容器不仅仅是微服务。可以想象，您可以将大型应用程序和非微服务作为容器运行，因此，只要您选择正确的容器技术和正确的应用程序平台，您就可以将许多（如果不是全部）遗留应用程序作为容器运行。
总结
我希望对各种战略和容器的深入探讨能够帮助您的公司评估下一步。请在评论中告诉我贵公司学到的经验教训，或者如果他们尚未采取行动，他们需要哪些我尚未提供的信息。
5 条评论