github 装逼指南_集装箱主管指南-CSDN博客

github 装逼指南

与IT领导者有关“ 容器 ”的讨论通常可以总结为：

作为一名CxO，我面临着不断挑战，即事半功倍。 IT预算继续减少，我的资源更少，但是要交付的工作量比以往任何时候都要多。 我花了太多时间专门解决预算限制。 此外，IT格局正在发生快速变化，并且一直在引入新技术。 我从可信赖的顾问那里听到的最新话题是“容器策略”的实施。 我想了解：

什么是容器？
向容器过渡的企业价值是什么？
为什么现在应该转向容器？ 如果不采用，会有弊端吗？
容器是否成熟到足以供企业使用？
如何使我的企业跟上容器采用的步伐？

让我们从头开始。

货柜

在过去的十年左右的时间里，企业已从物理基础架构迁移到虚拟机（VM）。转向虚拟机的主要优势是减少了数据中心的占地面积。通过在同一物理设备上运行多个VM，可以在更少的物理计算机上安装更多的应用程序。使用容器是包装应用程序的另一种方式，其重量更轻，交付模型更快。它们是在单个设备上运行多个应用程序进程的理想方法，无论该设备是VM还是物理计算机。此外，容器在实现DevOps，微服务和云策略的环境中也起着重要作用。

容器与虚拟机

容器在几个简单的方面与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还是Cloud Native Computing Foundation （CNCF）的一部分，该基金会正在发展为以云为中心的技术的标准机构。在容器平台上进行选择时，围绕开源编排技术的标准化非常重要。如果您不喜欢第一次做出的选择，它基本上可以让您跨容器平台移植。 K8S还允许您将容器工作负载跨不同的公共云移植。这就是为什么我们看到越来越多的科技公司使用Kubernetes的原因。

一些企业正在通过将包括K8S在内的几个开源项目整合在一起来构建自己的DIY容器平台。与使用专有技术相比，这绝对是一个更好的解决方案，但是它也包含很多使它起作用的方法。但是，应认真考虑企业维持和维护此类DIY平台的能力。许多企业不是在创建IT平台，而是希望运行其主流业务。有许多基于K8S的解决方案可用，例如Red Hat的OpenShift容器平台， Apprenda ， Deis ， Rancher等，它们提供平台的企业级版本，每种版本在提供的功能方面具有不同的成熟度。

这些解决方案已获得供应商的认证和支持。其中一些是全面的开源PaaS解决方案，而另一些可能是CaaS。根据您的企业需求，这些解决方案可能比DIY容器平台更好。

企业关注点及其与容器的关系

如今，几乎每个企业都在处理影响多个领域的数字化转型，包括DevOps，微服务和云战略。容器在每个领域都扮演着特殊的角色。

DevOps策略

IT组织分为运营和应用程序开发。他们作为两个独立的团队运作，每个团队都有自己的目标。大多数企业都朝着DevOps的方向发展，以将这两个团队整合在一起。

容器在DevOps计划的成功中起着重要作用。 DevOps成功的关键标准之一是增加开发人员在运营中的投入。开发人员不仅应该将代码交给操作，而且应该关注代码在生产中的运行方式。常见的技术是将“基础结构视为代码”。开发团队应该提供环境设置作为代码，而不是提供容易出错的安装说明页面。

这是容器要解决的确切问题。容器映像是容器的模板，从基础操作系统到应用程序代码，包括整个堆栈。使用容器，开发人员不仅会构建从Dev到QA再到Prod的应用程序工件（例如.jar文件）；相反，它们将传递一个版本化的容器映像，该映像既包含构建的工件，又包含工件在其中运行的环境。容器包含所有内容，从操作系统库到中间件再到捆绑到一个映像的应用程序，一应俱全。因此，容器在开发中的运行方式与在质量检查和生产中的运行方式完全相同。容器是DevOps成功的关键要素。

此外，集装箱平台正在进一步发展。典型的持续集成和交付（CICD）工具（例如Jenkins ）可以作为容器使用，这些容器可以在容器平台本身上运行整个CICD流程，而无需其他基础结构。现在，您可以使用PaaS平台来构建和运行CICD管道。

微服务策略

微服务是当今IT的另一个热门话题。将应用程序分解为离散的小型服务，每个应用程序都做得很好，这是设计应用程序的方式。这些微服务中的每一个都可以基于适用的技术以不同的语言编写。它们将由小型（由两个比萨饼供餐）的团队创建和管理，并且可以快速更改。所有这些要求再次暗示了容器。容器足够小，可以成为微服务的基础。容器可以支持您选择的任何技术和语言。它们易于创建和运行，并且可以快速更改。微服务和容器现在被认为是已婚的，如果人们谈论不使用容器来实现微服务，它们的外观通常会很奇怪。

现实是，尽管微服务承诺简单，但它们的扩散也增加了复杂性。为了简化其实现，提出了几种微服务设计和部署模式。这意味着开发人员现在需要一个可以轻松部署和协调这些微服务的平台，并且：

以与语言无关的方式实现这些微服务设计模式
不会因代码入侵而增加代码的复杂性，因此开发人员必须在其业务逻辑中包含大量模式代码
具有足够的灵活性以在您选择的基础架构上进行部署，并且不会将您与特定的云捆绑在一起

这是选择合适的集装箱平台的地方。以特定供应商的方式在特定基础架构上实现这些微服务会将您的应用程序绑定到那些供应商平台。使用标准技术（例如，符合OCI的容器）对微服务进行容器化将确保您的微服务可以在任何符合OCI的平台上运行。

选择正确的容器平台来运行微服务是另一个重要的决定。今天，选择很少，FUD也很多。如果您在进行此选择时不够勤奋，则其中某些选择会使您选择非标准的，特定于供应商的路线。

云战略

云策略是IT领域的另一个热门话题。无论您是否喜欢，“即服务”模型都是不可避免的变化。如果您不从IT提供此服务，那么您的开发团队可能会找到创建影子IT并进入云的方法。此外，使用云会将您从资本支出转移到运营支出，而管理云支出则是一个持续的挑战。

云提供了虚拟机，并且在启动其他虚拟机之前，您需要确保该云上的CPU，内存和网络资源得到最佳利用。容器在这里起着重要的作用。因为容器比VM小得多，并且如果您的应用程序在容器中运行，则与每个VM运行一个应用程序组件相比，您可以在VM中容纳更多的容器。

公共云供应商众多，其中包括Amazon Web Services（AWS），Microsoft Azure和Google Cloud。此外，您可能希望在基于OpenStack的数据中心中拥有自己的私有云。这些云环境中的每一个都有自己的协议，API和工具。当您希望您的应用程序在云上运行时，您不想使应用程序业务流程特定于云供应商，也不想维护任何特定于云的代码。与特定的云供应商锁定您的技术就像在未来的几年中向供应商签署空白支票一样。

跨云的可移植性对于您的云策略很重要。您可以编写应用程序而不必担心它们的运行位置，并且容器平台使您免受特定的云供应商协议的影响，从而防止您被某个云供应商锁定。

旧版系统

微服务架构带给开发人员的好处很多，但并不是每个应用程序都可以重构为其中的一部分，而有些则只能部分重构。传统应用程序将保留下来，需要对其进行维护和管理。尽管容器启用了微服务，但容器不仅仅是微服务。可以想象，您可以将大型应用程序和非微服务作为容器运行，因此，只要选择正确的容器技术和正确的应用程序平台，就可以将许多（如果不是全部）旧应用程序作为容器运行。