将 Docker 容器技术与 F5 产品和服务结合使用
IT 不断发展的需求以及敏捷开发和部署策略的出现导致了“容器化”的出现，它是全机虚拟化的替代方案，其中应用被封装在具有自己的操作环境的容器中。 容器化是一种很有吸引力的解决方案，它使开发人员能够更快地进行迭代。 它还提供额外的好处，解决与虚拟机相关的开销，从而提高软件定义数据中心 (SDDC) 中资源的利用率。
尽管容器化并不是一个新概念，但由Docker, Inc.开发的 Docker 因其广泛的行业支持、标准化和全面的功能广度而被广泛认为是首选实现方式。 用该公司的话来说，Docker 是“一个用于构建、运输和运行分布式应用的开放平台。 它为程序员、开发团队和运营工程师提供了所需的通用工具箱，以利用现代应用的分布式和网络化特性。” 因此，Docker 简化了从开发到部署的应用生命周期管理，并实现了应用的可移植性。 考虑到应用有多种托管选项（无论是在公共云还是私有云基础设施中），这种简化对于企业来说至关重要。
本文概述了 F5 在 F5 技术中使用容器以及支持 Docker 进行应用交付和安全性的方向。 在我们讨论这一策略之前，重要的是要认识到数据中心的痛点以及为什么这些技术对于下一代企业应用交付至关重要。
笔记： 本文档适用于 IT 决策者、架构师和开发人员。 假设读者已经了解虚拟化技术、软件开发和发布生命周期流程。
最近几项关于数据中心基础设施痛点的研究发现了数据中心发展的一系列一致需求：
- 更快的应用部署方法
- 改进的工作流管理流程
- 提高计算资源的可用性和利用率
- 提高根据需要移动工作负载的灵活性
随着应用开发中出现新的趋势，企业客户对应用生命周期管理模型的看法正在转变如下：
- 下一代应用越来越多地以“云优先”为基础构建。
- Linux 已成为云开发事实上的操作系统 (OS)。
- 下一代云应用：
- 被设计为无状态并利用松散耦合的微服务架构。
- 利用允许独立构建服务而无需软件版本或服务依赖的框架。
- 企业越来越多地采用自动化，通过使用配置管理工具（如 Puppet、Chef 和 Ansible）和 DevOps 编排来提高发布软件的灵活性。
- 当企业开发新的应用程序并将现有的应用迁移到公共云时，可移植性是避免供应商锁定的关键。 尽管虚拟机(VM) 技术提供了一定程度的抽象，但每个虚拟机管理程序都以不同的方式实现其环境，因此并非完全可移植。
Docker 试图解决这些挑战，因此成为了虚拟化基础设施的领先且引人注目的技术。
容器通过将每个应用隔离为一个操作系统进程，实现了操作系统级别的虚拟化。 这一概念在操作系统中以多种形式出现，例如 BSD 中的 Jails、Oracle Solaris 中的 Zones，以及最近 Linux 中的 LXC。Docker 以 LXC 为基础，并添加了“简易按钮”，使开发人员无需虚拟机管理程序即可跨云基础架构构建、打包和部署应用。
以下特点使 Docker 有别于其他容器技术：
- 操作系统之上的轻量级抽象层（Docker 引擎）用于管理应用之间的隔离和网络。
- 记录的应用编程接口 (API)，使基于 Linux 的应用部署更加简单。
- Docker Registry 用于与其他用户和开发人员共享应用。
- 支持 Docker 的主机之间的application可移植性，无论是物理、虚拟还是云托管。
- 联合文件系统向所有 Docker 容器公开一个通用的文件系统。
- 合作伙伴公司生态系统提供增值服务和软件，使 Docker 能够很好地融入各种各样的开发工作方式。
联合文件系统允许每个容器提供特定于该容器的服务，即使底层路径和文件名与底层文件冲突。 例如，一个容器可能需要 Python 库的 2.6 版本，而另一个容器可能需要更高版本。 底层文件系统可能提供 2.6 版本，在这种情况下一个容器就满足了。 但是，需要更高版本的容器可以将其作为其容器映像的一部分提供。 这会减少容器镜像的占用空间，因为它们仅需要包含运行时所严格必需的内容。
图 1 中的图表说明了 VM 和 Docker应用部署中使用的组件。 请注意，在此示例中，VM 方法有两个客户操作系统来支持两个应用。 相比之下，Docker 只需要一个主机操作系统就能实现相同的应用密度，但当然，这样做的开销较低。
下表显示了VM和Docker功能的比较。
| 虚拟机 | Docker | |
|---|---|---|
| application存储开销 | 每个应用的操作系统开销达 GB。 | 所有容器共用一个操作系统。Docker 引擎开销较小（兆字节）。 |
| 实例化 | 操作系统和应用的启动时间。 | 仅限application启动时间。 |
| 资源分配 | 坚固且整体。 虚拟 CPU 通常分配给物理 CPU 核心或超线程。 磁盘空间通常预先分配给 VM 主机。 |
灵活的。 Docker 容器可以被分配 CPU 限制，并且可以非常有效地共享物理主机 CPU 核心。 如果需要，可以限制 Docker 内存的使用，但使用的内存可以在主机及其容器上的进程之间有效分配。 磁盘通过联合文件系统共享。 |
| 安全 | 出色的。 虚拟机生活在完全独立的世界中，除非托管环境有意允许，否则它们之间很少共享。 |
好的。 操作系统内核阻止容器访问彼此的内存空间。 联合文件系统为每个容器提供了共享容器的只读视图。 当容器修改任何内容时，它会获得该数据的特定于容器的副本，该副本只有该容器才能看到。 |
如前所述，Docker 的主要目标是简化应用生命周期管理。 虽然裸机上运行 Docker 无疑是一个引人注目的选择，但在虚拟机管理程序上运行 Docker 也有其好处。 这些包括快照功能和允许整个客户的实时迁移 - 这两者都可能是在不丢失飞行状态的情况下进行灾难恢复的关键要求。
领先的基础设施管理和编排解决方案（例如 VMware vRealize Suite、OpenStack）以及公共云（例如 AWS 和 Azure）都在特定类型的虚拟机管理程序上支持 Docker，但它们向 Docker 容器公开了一个通用环境，从而无需考虑环境即可实现应用的可移植性。 这种异构部署模型使得客户可以开始使用Docker，并获得无需改变底层基础设施就能更快迭代的好处。
通过将每个主机迁移到单个虚拟机和操作系统，客户还可以获得资源优势，因为虚拟机不必争夺资源。 效率的提高是由于可以将内存和本地磁盘分配给单个操作系统，而虚拟机管理程序不再必须在多个操作系统之间进行仲裁。
网络允许您在 Docker Engine 中创建跨多个主机的虚拟网络。 无论容器位于何处，都可以连接到这些网络，从而完全控制网络拓扑以及哪些容器可以与哪些其他网络元素通信。 不仅如此，网络供电系统还可以通过插件进行交换，让您无需修改应用即可与任何所需的网络系统集成。
为了适应任何给定主机上的高密度容器，了解每个容器加入网络的机制非常重要。 开箱即用，Docker 为每个容器提供了一个私有地址，该地址只能从驻留在同一主机上的另一个容器直接访问。
为了让服务从另一台主机到达容器，必须通过 Docker 基于 iptables 的网络地址转换（NAT）功能进行路由。 图 2 显示了一个示例。
主机接口（Eth0）使用另一个地址（在本例中为另一个 RFC1918 地址 192.168.10.10）公开。 每个 Docker 容器在启动时都会自动分配 172.x.x/16 空间中的地址。 为了使容器能够以双向方式与其主机外部的实体通信，必须通过 iptables 为其分配一组明确的规则。
在图 2 所示的示例中，规则已配置为使得容器可以通过 IP 和端口映射进行通信，将容器 A 公开为 192.168.10.10/端口 80，将容器 B 公开为 192.168.10.10/端口 81。 但是，容器 C 只能使用 172.17.0.x 寻址与其他两个容器通信。
Docker 还支持 IPv6 并允许使用完全可路由的地址。 这使得容器能够与不同主机上的其他容器进行通信，而无需地址映射。 但是，这仅适用于 IPv6，因此对于某些环境来说其适用性可能有限。
许多软件定义数据中心使用软件定义网络（SDN）的概念来灵活部署其客户。 SDN 允许为同一物理硬件上的独立租户配置隔离的网络隧道。 在云数据中心内部提供隧道第 2 层也很有用，否则将完全路由。 Docker 网络是围绕 Docker Bridge 的概念构建的，它可以连接到 Open vSwitch，以实现与 VXLAN 或 GRE 等技术的互操作性。
以这种方式使用 Open vSwitch 可实现多租户的第 2 层网络隔离以及连接到其他虚拟化环境的选项。 例如，使用 Docker 的数据中心很可能仍将使用虚拟机来提供已知应保留专用资源的关键服务。 这些可能是应用交付服务或高性能资源，例如数据库和处理节点。 这些资源可能通过 VXLAN 或 GRE 等技术连接到网络，因此一个租户的流量对另一个租户是不可见的。
在这种类型的环境中扩展应用需要能够本地参与隧道协议的 ADC 服务。 F5 提供多租户 VXLAN 和 GRE 功能，以便可以通过隧道向网络上的客户端提供负载均衡、SSL 卸载、防火墙、应用安全、NAT 和 DNS 服务等功能。 此外，F5 还提供隧道封装类型之间的互操作性，包括 802.1Q VLAN。
在图 3 所示的示例中，数据库等核心应用层可能位于数据中心与用于托管 Docker 实例的资源不同的部分。 在这种情况下，租户网络可能会使用 GRE 或 VXLAN 来隔离和连接两个物理上不同的子网。
通过在 BIG-IP 实例上创建 VXLAN 隧道端点 (VTEP)，可以将 BIG-IP 解决方案无缝插入租户级别的网络。 然后它成为租户网络的一部分，并连接到 Docker 和虚拟机实例。
从 1.7 版本开始，Docker 开始提供一些实验性功能，利用 SDN 概念扩展基础 Docker 网络功能。 插件架构提供了一个激动人心的机会，允许将 F5 网络和应用交付服务插入到各种新用例中，包括具有应用程序流畅容器的下一代防火墙、容器流分析和策略实施以及每流流量管理。
F5 提供一系列产品来实现虚拟化。 作为 ADC 市场领导者，F5 拥有业内最广泛的 L4-L7应用交付和安全服务组合，不断探索创新技术并将这些技术扩展到 BIG-IP 平台，因为它们都共享一个通用的底层框架。 图 4 显示了 F5 的产品范围，从定制硬件到完整的基于云的 L4-L7 服务即服务产品。 BIG-IP 平台能够很好地支持在 Docker 容器上运行的应用。
如上所述，F5 认识到 Docker 在不同用例中的优势。 然而，容器化基础设施中的部署仍处于起步阶段，服务发现（如 Consul、etcd 和 Mesos-DNS）、编排和管理容器服务生命周期（包括 Mesos、OpenStack、Kubernetes、Docker 和 Cloud Foundry）存在多种选项。 虽然网络服务是这个生态系统的一个重要方面，但与编排环境紧密集成以确保无缝部署也很重要。 这种集成对于使 L4-L7 服务对在容器化基础设施中部署基于微服务的应用的用户可用且透明也至关重要。 F5 方法旨在提供跨裸机、虚拟化或容器化部署的一致服务体验和可视化。
解决问题的第一部分是为南北 (N-S) 流量（即“面向客户端的微服务”的流量）提供网络服务。大多数领先的编排平台处理从容器化服务到外界的连接部署、扩展和公开。 通过与领先的容器编排平台紧密集成，F5 确保 BIG-IP 系统能够自动发现 N-S 微服务，然后管理这些服务的流量。 例如，Mesosphere Marathon 和 Kubernetes 提供了“标记”服务的选项。 这些标签可用于发现面向客户端的服务（启动、拆卸或扩展），并可自动作为池成员添加到 BIG-IP 系统。
将上述方法与 BIG-IP 硬件或虚拟版本 (VE) 结合使用，可以通过硬件加速集中关键功能，例如：
- 通过集中证书管理进行 SSL 卸载。
- 压缩、TCP优化、SPDY/HTTP2等加速。
- 具有 DoS 保护功能的复杂防火墙。
- 应用流畅性，可阻止应用层攻击。
- 所有传入和传出网络连接的可见性。
- 通过智能日志记录和异常检测大大改进了调试。
F5 解决方案提供了扩展容器化应用的能力，以及在 Docker 基础设施和外部网络之间执行 IPv4 到 IPv6 和 DNS 转换的能力。 为了利用完全可路由的 Docker 容器基础设施，组织不仅需要高效的 IPv4 到 IPv6 网络功能，还需要支持转换 DNS 请求。 Docker 容器基础设施可以纯粹在 IPv6 中运行，完全与 IPv4 隔离，同时保持与 IPv4 连接的无缝路径。
在图 5 所示的示例中，NAT64 和 DNS64 服务已配置（同样，以任何形式，物理或虚拟）。 Docker 容器尝试连接www.example.com，但在此示例中，该站点不存在 IPv6 地址。
BIG-IP 系统配置为 Docker 平台安装的 DNS 解析器。 它配置了一个用于 DNS 解析器本身的 IPv6 地址以及一个用于 IPv4 到 IPv6 转换的特殊 IPv6 前缀地址（以红色显示）。
一旦 BIG-IP 设备收到 IPv6 DNS 查询，它首先执行递归操作以查看是否有可用的 IPv6 地址。 但是，在此示例中，www.example.com 的权威 DNS 服务器对 AAAA 请求响应了一个空记录。 然后，BIG-IP 设备执行 IPv4 查询，并收到 DNS A 记录。 它将特殊前缀地址添加到 IPv4 地址上并将其发送回 Docker 客户端。
Docker 客户端现已解析其地址并启动 TCP 连接。 由于 Docker 使用特殊前缀，因此 NAT64 功能识别出需要从 IPv6 到 IPv4 的转换。
NAT64 功能为 Docker IPv6 地址、此 IPv4 服务器的特殊前缀 NAT64 地址和 IPv4 服务器之间的连接创建绑定。 连接请求被发送到 IPv4 服务器。 该服务器通过 IPv4 响应的所有响应均由 NAT64 功能转换，以建立 Docker 容器与 IPv4 服务器之间的连接。
创建紧密集成的下一个关键步骤是提供东西向 (E-W) 流量服务 - 即需要 ADC 服务的微服务之间传递的数据。 考虑到需要在几秒钟内启动服务以及微服务的短暂性，F5 的方法是启用轻量级 ADC。 （对于身份验证或 L7、应用程序级保护等高级服务，流量将被重定向到 N-S 边缘的 BIG-IP 实例。）
微服务架构中容器化服务的数量将比传统架构高得多，并且微服务之间具有多条通信路径。 这种架构的可能的副作用可能是复杂性，使得解决性能问题变得更加困难。 例如，如果应用的性能不佳，那么从 NS 边缘跨不同服务实现端到端的可见性就非常重要。 因此，一种能够关联南北域中的 BIG-IP 系统和东西域中的轻量级 ADC 之间的流量模式的集中式可视化方法对于故障排除至关重要。
F5 BIG-IP 解决方案实例还可以插入应用之间，以提供负载均衡或安全服务，解决 EW 流量的安全问题。 例如，可以配置 Docker 主机，让来自一个容器的流量在进入另一个容器之前穿过 BIG-IP 系统进行分析。 这可以使用 BIG-IP应用安全管理器™ (ASM) 来执行，该管理器具有应用程序流畅性，可以检测相关容器是否受到攻击（例如利用漏洞）。
目前，F5 客户的许多成功部署都大规模运用了容器化。 这些组织涵盖许多垂直市场，包括金融、电信和 SaaS 提供商。 F5 解决方案在这些环境中的作用目前包括向这些环境提供 ADC 服务，以确保应用快速、安全和可用。 这些服务可以集成在一起，为应用所有者或 DevOps 提供自助服务，或通过容器管理系统协调这些服务。
F5 计划将这些服务扩展到容器化基础设施本身，以解决服务发现、东西流量管理和安全性问题。 F5 还计划在其产品套件中利用容器化，在物理平台上利用该技术，在容器中提供软件服务，并在 F5 Silverline® 云基服务平台中使用容器化架构。
下表简要介绍了 F5 正在探索或积极开发的方向：
| 现已推出 | 近期 | 中期 | 未来 |
|---|---|---|---|
BIG-IP 产品通过 VIP 到 L4 端口和 IP 映射确保容器应用的高可用性和可扩展性，并通过完整的 REST API 进行编排集成。 全方位的可用性、加速、缓存和 DNS 功能均可部署于 Docker 环境，同时还具备领先的 F5 安全保护和缓解功能。 此外，F5 还提供插件，允许所有 BIG-IP 外形尺寸在利用 OpenStack 的 Docker 环境中运行。 |
F5 Silverline 平台将利用弹性计算能力作为订阅服务的一部分，实现高级行为 DDoS 功能。 Docker 的新网络功能将允许插入新服务，以实现高级东西流量分析、策略实施和安全分析，并具有流量检查和可见性功能。 |
F5 正在积极探索 F5 vCMP ®技术的新功能，以实现高虚拟机密度，并为 vCMP 利用包括 Docker 在内的新部署模型奠定基础。 |
F5 正在寻求扩大弹性计算管理器的覆盖范围以供客户使用，从而允许任何格式的 BIG-IP 解决方案利用容器化计算功能来满足苛刻的工作负载。 F5 支持开放容器标准 (OCS)，使 F5 虚拟化服务能够跨多种容器格式运行。 |
Docker 为提高数据中心效率提供了明显的机会，无论是物理的还是基于云的。 同时，Docker 采用者可以更加确信他们的应用可以移植到新的环境中。 至关重要的是，Docker 使应用开发人员变得更加敏捷并能够更快地将应用推向市场。 在将 DevOps 发展到 Docker 模型时，客户通常会借此机会引入新的工作流程，以实现基于小型标准化服务的自助服务，开发人员可以在其中放置他们的应用。
Docker 通过轻量级容器实例允许应用快速扩展，F5应用交付产品完全支持此类环境。 使用 F5 BIG-IP 解决方案，客户可以协调应用的整个生命周期。 这可以通过针对关键操作的全面 REST API 来实现，例如创建和维护 VIP、集中式 SSL/证书管理、防火墙服务以及多租户架构中高可用性的应用安全。
Docker 可用于多种模型，包括公共和私有云部署。 F5 在为这些环境提供互操作性和支持方面处于领先地位，提供专门针对 OpenStack、VMware 以及 Amazon AWS 和 Microsoft Azure 等主要云提供商的关键功能。
客户正在转向以 Docker 为主要组件的 DevOps 模型，他们认识到可能获得的运营改进取决于可扩展、安全、高可用性且如新工作流程所要求的一样敏捷的平台。 F5 产品和服务旨在与业内最广泛的技术和技术合作伙伴合作，兑现 Docker 愿景的承诺。 F5 对 Docker 的承诺得到了坚实的路线图投资和持续的产品改进的支持，以确保其成功成为软件定义数据中心的主导部署模型之一。
