
本文旨在梳理和对比当前主流的NFV(网络功能虚拟化)编排与基础设施自动化工具,涵盖裸机配置、通用配置管理、OpenStack部署及容器编排等多个层面,为技术选型提供参考。
一、裸机配置工具
此类工具专注于物理服务器的操作系统部署与初始化。
- Cobbler: Dell开源的基于PXE的裸机部署工具。
- Ironic: OpenStack官方的裸机部署服务,基于PXE+IPMI。
- MAAS (Canonical): 基于PXE的裸机部署与管理工具。其电源管理支持广泛,包括IPMI、HMC等物理协议,也支持如
virsh、VMware等虚拟化环境。
二、通用配置管理工具
这些工具用于在已有的操作系统上进行软件安装、配置和管理。
- Puppet: 配置管理工具的鼻祖,使用基于Ruby的自有描述语言。语法相对复杂,可移植性一般。
- Chef: 类似Puppet,使用Ruby编写配置脚本(称为“食谱”),客户端从服务器拉取并执行。
- Ansible: 采用Agentless架构,通过SSH连接节点,使用YAML语言编写“剧本”进行配置管理。它与Juju思想类似,但设计更轻量,适合运维与DevOps场景中的自动化任务。
- Salt (SaltStack): 支持Agent和Agentless两种模式。在Agentless模式下,通过SSH连接并使用Python模块进行管理。
- Docker: 通过容器化技术将应用及其运行环境打包,实现应用与底层基础设施的解耦。
- Terraform: 基础设施即代码(IaC)工具,专注于云服务资源的创建、管理和编排,而非节点上的软件配置。
三、OpenStack部署工具
专门用于自动化部署OpenStack云平台的工具集。
- Devstack: 快速部署OpenStack开发环境。
- Packstack: 利用Puppet通过SSH在RHEL/CentOS上部署OpenStack。
- Red Hat RDO: 使用Ansible在RHEL/CentOS上部署OpenStack。
- OpenStack-Ansible (OSA): Rackspace发起,使用Ansible在Ubuntu和CentOS上部署OpenStack。
- Mirantis Fuel: 使用Puppet在Ubuntu上部署OpenStack(已停止主要开发)。
- OpenStack TripleO: 利用OpenStack自身组件(Nova, Neutron, Ironic, Heat)来部署和扩展OpenStack集群,即“OpenStack on OpenStack”。
- OpenStack Kolla: 将OpenStack所有组件容器化部署,简化依赖管理和升级回滚。它可以使用Ansible或Kubernetes来管理容器化的OpenStack节点。
- Atmosphere: 一个用于在本地硬件上交付虚拟机、Kubernetes集群和裸机的部署工具。
四、NFV编排工具
这些工具直接用于编排虚拟网络功能(VNF)及其管理器(VNFM)和编排器(NFVO)。
- OpenStack Heat: OpenStack的原生编排服务。它根据HOT模板编排一组虚拟机及之上的应用配置,支持负载均衡等高级编排。
- Canonical Juju: 一种应用程序建模和编排工具,通过“Charm”来部署、配置、扩展和管理应用。可用于编排VNFM与NFVO。
- 通用配置管理工具: 如Ansible、Puppet、Chef等,也可用于VNF的配置与编排。
- Kubernetes与Kolla: Kubernetes作为容器编排平台,结合Kolla项目,可以将VNFM与NFVO以容器形式进行部署和管理。
五、Mesos + Marathon方案
这是一个通用的集群管理与应用部署方案。
- Apache Mesos: 是一个两层调度的集群资源管理器(数据中心操作系统)。
- Marathon: 是运行在Mesos上的一个Framework,用于部署和管理长期运行的服务,类似于分布式的
init.d。
- 方案评价:该组合在通用应用编排上有其价值,但在NFV编排领域社区活跃度和相关资料较少。相较于Kubernetes为微服务设计的精良数据模型(Pod, Service等),Mesos的API在易用性上有所不足,且其生态系统组件使用的编程语言较为繁杂。
六、Juju与Kubernetes设计思想对比
两者都是优秀的编排工具,但设计哲学不同:
- Juju 专注于应用程序层面的建模、部署和全生命周期管理。它通过“Charm”抽象应用的操作知识,核心是管理应用之间的关系。
- Kubernetes 专注于容器化工作负载的编排、调度和基础设施管理。它通过“Pod”、“Service”等原语抽象计算、网络和存储资源,核心是管理容器及其资源。
简而言之,Juju是“应用感知”的,而Kubernetes是“容器感知”的。在云原生场景下,两者甚至可以结合使用,例如用Juju来部署和管理运行在Kubernetes上的复杂应用。
Terraform的核心能力是在多云和本地环境上声明式地创建和管理基础设施资源(如虚拟机、网络、数据库),而非在已有OS上安装软件。
常见的协作模式包括:
- Terraform + Cloud-init: Terraform创建云主机,并通过
cloud-init脚本进行初步应用配置。
- Terraform + Ansible: Terraform搭建基础设施,然后由Ansible进行详细的软件部署和配置。这是运维与DevOps中经典的“供应+配置”组合。
- Terraform + Packer: 使用Packer将预配置好的应用和OS打成镜像,再由Terraform基于该镜像部署资源。
- Terraform与编排工具结合: 例如,用Terraform创建Kubernetes集群,再使用Kubernetes或Juju在其上部署应用。
IaC工具分类与最佳实践
- 专项脚本 (如Bash):灵活但实现幂等性和可维护性成本高。
- 配置管理工具 (如Ansible, Puppet):在现有服务器上安装和管理软件,强调统一、幂等和分布式执行。
- 服务器模板工具 (如Docker, Packer):创建包含OS和应用的标准化镜像。
- 编排工具 (如Kubernetes):管理集群内容器的部署、扩展和网络。
- 服务开通工具 (如Terraform, OpenStack Heat):创建和管理服务器、网络、数据库等基础设施本身。
最佳实践组合示例:
- Terraform (开通) + Ansible (配置)
- Terraform (开通) + Packer (模板) + Kubernetes (编排)
定义与使用变量:
variable "server_port" {
description = "The port the server will use for HTTP requests"
type = number
default = 8080
}
可以通过命令行覆盖:terraform plan -var="server_port=8080",或使用环境变量:export TF_VAR_server_port=8080。在配置中引用变量:${var.server_port}。
状态管理:terraform.tfstate文件记录了资源映射。团队协作时,应将其存储在远程后端(如AWS S3)并启用状态锁定。
引用资源属性:引用格式为<PROVIDER>_<TYPE>.<NAME>.<ATTRIBUTE>,例如 aws_security_group.instance.id。terraform graph 命令可用于可视化资源间的依赖关系。
八、结论与选型建议
- NFV虚拟机编排:可优先考虑 OpenStack Heat(OpenStack环境内)或 Canonical Juju(多云或混合云场景)。
- NFV容器化编排:可选用 Kubernetes,或结合 OpenStack Kolla 项目。Juju 同样适用于编排容器化应用。
- 基础设施即代码 (IaC):对于云资源创建和管理,Terraform 是行业标准选择。
- 配置管理:Ansible 因其Agentless和易用性,在配置管理领域占据重要地位。
实际选型需根据具体技术栈(如是否基于OpenStack)、团队技能和运维流程进行综合评估。
|