有许多容器构建模板。 容器只是其自身映像的可执行版本。 因此，构建容器的方式与其启动方式密切相关。
某些容器映像可以正常工作而无需任何特殊特权；其他容器映像则需要root特权。 此外，同一图像/容器可以一次组合多个构造模式和使用方案。
下面我们将考虑最常见的容器使用案例。
（有关容器术语的介绍，请参阅
第1部分 ）
容器使用方案
应用容器
应用程序容器是最常见的容器类型。 开发人员和应用程序所有者会处理它们，它们本身包含源代码以及MySQL，Apache，MongoDB和Node.js之类的东西。
一个庞大的应用程序容器生态系统正在形成。 诸如Software Collections之类的项目为Red Hat Enterprise Linux提供了安全且受支持的应用程序容器映像。 同时，红帽社区成员正在开发和支持创新的应用程序容器。
在Red Hat，我们相信应用程序容器通常不需要特殊的特权。 但是，当建立容器生产环境时，需要其他容器。
操作系统容器
操作系统的容器是一个非常类似于完整的虚拟OS的容器。 此类容器还使用主机内核，但运行完整的init系统，这使它们可以轻松执行多个进程。 操作系统容器的示例是LXC和LXD。
原则上，可以使用docker / oci容器模拟操作系统的容器，前提是您可以在其中运行系统，以便最终用户可以按常规方式在此类容器中安装软件并将其视为完整的虚拟OS。
yum install mysql systemctl enable mysql
这极大地简化了现有应用程序的容器化。 红帽正在努力通过允许systemd在容器内运行并使用加工的守护程序来简化操作系统容器。 尽管许多客户尚未准备好使用微服务体系结构，但基于容器映像向容器化软件交付模型的转换仍然可以为他们带来很多优势。
宠物容器
尽管Red Hat在开发新应用程序时强烈建议，促进和支持使用基于
云的模板 ，但我们深知并非所有现有应用程序都将以这种方式重写。 特别是，由于它们中的许多是如此独特和独特，因此与标准应用程序相比，它们看起来像宠物（
Pets ），对着一群牛。 为此应用设计了特殊的
宠物容器 。
Pet容器将基于注册表服务器，容器映像和容器主机构建的容器基础结构的可移植性和便利性与在单独容器内实现的传统IT环境的灵活性相结合。 这里的想法是简化现有应用程序的容器化，因为
具有在容器内部使用systemd来使用现有自动化工具，软件安装和其他工具来轻松创建容器就绪映像以进行启动的相同
能力 。
超级特权容器
当基于专用容器主机（如Red Hat Enterprise Linux Atomic Host）构建容器基础结构时，系统管理员仍然必须进行管理。 事实证明，
超级特权容器 （SPC）在这样的分布式环境中非常有用，无论是Kubernetes，OpenShift还是独立容器。 SPC甚至可以加载专用的内核模块，例如systemtap。
在创建用于运行容器的基础结构中，管理员可能需要SPC容器来执行诸如监视，备份等任务。了解这一点很重要，因为SPC容器通常与主机核心的连接更多，因此管理员应该选择主机操作系统时，尤其要注意可靠性和标准化问题，尤其是在大型群集和分布式环境中，这会使故障排除变得困难。 另外，管理员需要确保SPC中的用户空间与主机核心兼容。
工具和系统软件
Linux发行版始终为用户提供系统软件，例如Rsyslogd，SSSD，sadc等。传统上，该软件以RPM或DEB软件包的形式安装，但是随着容器包装格式的出现，使用容器映像安装变得更加容易和方便。 特别是Red Hat提供了诸如Red Hat虚拟化工具，rsyslog，sssd和sadc之类的现成容器之类的东西。
容器架构
随着容器化软件交付的蓬勃发展，新的容器设计模式正在出现。 在本节中，我们将讨论其中的一些。
容器保存到磁盘的方式（换句话说，映像的格式）会极大地影响其启动方式。 例如，设计为运行sssd的容器每次启动时都必须具有特殊特权，否则它将无法执行其工作。 下面，我们简要地考虑当前正处于活跃形成阶段的主要模式。
应用图片
最终用户通过这些图像进行交易。 使用此类映像的方案范围从DBMS和Web服务器到单个应用程序和服务总线。 这些映像可以由组织内部创建，也可以由软件供应商提供。 因此，最终用户经常谨慎和谨慎地对待这种自主容器的内容物。 此外，尽管对于容器的最终用户而言，这是最简单的选择，但独立映像的设计，构建和修补更加困难。
基本图片
基本图像是最简单的图像类型之一。 但是，人们可以用各种各样的东西来表示该术语，例如，标准的公司装配甚至是应用程序映像。 尽管严格来讲，这些不是基本图像，而是中间图像。
因此，只需明确说明基本图像是没有父图层的图像。 基本映像通常包含操作系统的完整副本，以及安装软件包或以后更新映像所需的工具（yum，rpm，apt-get，dnf，microdnf）。 基本映像可以由最终用户手动收集，但实际上，它们通常是由开发社区（例如Debian，Fedora或CentOS）或软件供应商（例如Red Hat）创建和发布的。 基本映像的来源对于安全性至关重要。 总结起来，基本映像的主要目的是为创建子映像提供基础。 使用dockerfile时，显式选择基础基础映像：
FROM registry.access.redhat.com/rhel7-atomic
生成器图像
这是一种特殊类型的图像，然后基于该图像创建应用程序容器的子图像。 构建器映像包括开发人员编写的源代码以外的所有内容，即OS库，语言运行时，中间件和
源到映像工具。
启动时，构建器映像提取由开发人员编写的应用程序源代码，并创建准备启动的应用程序容器的子映像，然后可以在开发或生产环境中运行该子映像。
假设开发人员已经为应用程序编写了PHP代码，并希望在容器中运行它。 为此，他们只需获取PHP的构建器映像，然后将其传递给存储代码的GitHub网站上的URL。 结果，开发人员准备好要启动的应用程序容器映像，其中包含Red Hat Enterprise Linux，Software Collections中的PHP，当然还有该应用程序的源PHP代码。
Builder映像是将源代码转换为基于受信任组件构建的容器的强大，简便且快速的方法。
集装箱组件
容器主要旨在作为大型软件系统的组件进行部署，而不是作为独立的单元进行部署。 这主要有两个原因。
首先，微服务架构增加了组件选择的自由度，还导致组成应用程序和软件系统的组件数量增加。 容器化组件有助于更快，更轻松地部署此类系统。 例如，容器图像可以轻松解决同一组件的不同版本共存的问题。 应用程序定义工具（例如Kubernetes / OpenShift中的
部署yaml / json ，
开放服务代理 ，
OpenShift模板和
Helm Charts）提供了高级应用程序描述的创建。
其次，可以很容易地将软件系统的所有部分包装起来。 因此，有意义的是仅对结果最合适或最有希望的单个组件执行容器化。 在多服务应用程序中，一部分服务可以部署为容器，而另一部分则使用传统方法（如RPM或安装脚本）进行部署，请参见pet容器。 此外，某些组件可能难以容器化，因为它们的组件划分不佳，或者与某些特殊硬件绑定在一起，或者使用低级内核API调用等。因此，在大型软件系统中，最有可能将有可以被包装的零件和不能被包装的零件。 容器化的组件可以被容器化，也可以被容器化。 容器化组件被设计为作为特定应用程序的一部分运行，而不是单独运行。 重要的是要了解它们不是用于自主操作的，因为它们仅作为大型软件系统的一部分有用，而与之隔离实际上几乎是无用的。
例如，在OpenShift Enterprise 3.0中，大多数主要代码都是使用RPM部署的，但是在安装之后，管理员将路由器和注册表部署为容器。 OpenShift 3.1引入了针对主服务器，节点，openvswitch和etcd的容器化部署选项，安装后，管理员还可以将Elasticsearch，fluentd和kibana部署为容器。
尽管OpenShift安装程序仍在更改服务器文件系统，但现在可以使用容器映像安装所有主要软件组件。 因此，这些容器化的组件（例如，嵌入OpenShift的etcd图像的实例）永远都不会（也永远不会）用于存储客户正在使用的应用程序的源代码，仅仅是因为这些容器化的组件旨在作为一部分运行OpenShift容器平台。
在新版本的OpenShift中，组件容器化的趋势仅在加剧，其他软件开发人员也越来越多地使用这种方法。
部署器映像
部署程序映像是一种特殊的容器，启动后会部署或管理其他容器。 Deployer允许您实施复杂的部署方案，例如，以一定顺序启动容器或在首次启动时执行某些操作，例如生成数据方案或初始填充数据库。
例如，在OpenShift中，“图像/容器类型”模板用于部署日志和指标。 使用部署程序映像部署这些组件使OpenShift工程师可以控制各种组件的运行顺序，并验证它们是否可以正常工作。
中间图像
中间图像是依赖于基础图像的容器的任何图像。 内核程序集，中间件和语言运行时通常在基础映像之上实现为附加层，然后在此基础映像的FROM指令中指定。 中间映像通常不单独使用，而是作为创建自主映像的基础。
通常，图像的不同层由不同的专家组组成。 例如，系统管理员负责内核组装层，而开发人员负责中间件层。 同时，由一个团队准备的基础层充当负责高层管理人员的中间形象。 尽管有时可以自主使用此类中间图像，尤其是在测试时。
多用途（联运）图像
多用途容器映像是具有混合体系结构的映像。 例如，Red Hat Software Collections中的许多图像可以两种方式使用。 首先，作为具有完整Ruby on Rails和Apache服务器的常规应用程序容器。 其次，它们可以用作OpenShift容器平台的构建器映像，并基于它们作为子映像，其中包含Ruby on Rails，Apache和在构建此类子映像时传递给
源以处理
映像的应用程序代码。
请注意，多用途图像越来越受欢迎，因为它们使您可以使用同一图像解决两个根本不同的任务。
系统容器
在以容器形式部署系统软件时，后者通常需要超级用户特权。 为了简化此部署选项并确保在启动容器运行时和业务流程系统之前启动了此类容器，Red Hat开发了一个特殊的模板，称为
系统容器 。 这些容器是在操作系统引导过程中使用systemd和atomic命令启动的，这使它们独立于任何运行时或容器编排系统。 今天，Red Hat提供了用于rsyslog，cockpit，etcd和flanneld的系统容器，并将在将来扩展此列表。
系统容器极大地简化了向Red Hat Enterprise Linux和Atomic Host添加这些服务的选择性操作。
结论
对于最终用户而言，容器似乎是一件相当简单的事情，但是在构建容器生产环境时会出现很多问题。 为了有效地讨论构建此类环境的体系结构和方法，所有参与者都需要统一的术语。 您越深入研究此类环境的设计和构建，就会遇到更多的陷阱。 最后，我们只记得其中的几个。
人们通常看不到“容器映像”和“存储库”之间的区别，尤其是在docker命令中使用它们时。 但是，如果您可以在不了解差异的情况下使用命令，那么在处理容器环境的体系结构时，必须清楚地了解存储库实际上是主要的数据结构。
误解名称空间，存储库，图像层和标签之间的差异也很容易。 这些东西在容器体系结构中都有其用途。 尽管供应商和用户将它们用于各种目的，但它们只是工具。
本文的目的是帮助您了解术语，以便您可以创建更高级的体系结构。 例如，假设您刚刚受委托开发一种基础架构，该基础架构应根据角色和业务规则来限制名称空间，存储库以及标签和层的可用性。 最后一点-请记住，容器的组装方式在很大程度上决定了容器的启动方式（编排，特权等）。