专栏首页青年夏日使用 Packer、Ansible 和 Terraform 构建不可变的基础设施
原创

使用 Packer、Ansible 和 Terraform 构建不可变的基础设施

在容器编排领域,Kubernetes 已成为事实上的标准,而容器镜像 (Docker Image) 作为容器技术栈中最关键的创新之一,极大的推动了企业内部 Devops 运动的进程。

容器镜像所具有的轻量性、便携性、分层机制和内核共享机制真正意义上实现了 “Build once, run anywhere”。这种不可变的基础设施 (Immutable Infrastruture) 高度保持了开发、测试和生产环境的一致性。因为镜像的易移植、易复制的特性,也给运维带来了很大的弹性和灵活性。

对于还无法容器化,只能部署在虚拟机里的传统应用,是否也能构建像容器镜像这样不可变的的基础设施?

可变的服务器部署 vs. 不可变的服务器部署

可变的服务器部署

在可变的服务器部署模式中,首先我们通过 Terraform 创建出所需的虚拟机以及其它基础设施资源,然后通过配置管理工具 Ansible 对已经存在的服务器资源进行应用相关的配置和部署。

上述的部署过程看似非常快速、简便,但是随着业务的需求增加,需要对服务器操作系统进行更新,或对部署的应用进行频繁的升级。这种情况下,可变的服务器部署模式所带来的挑战和风险是我们无法预估的。

在真实的用户场景里,运行的应用程序与操作系统、或第三方软件资源存在各种各样复杂的依赖。当给操作系统打补丁,亦或升级应用程序所依赖的软件包时,可能会出现应用程序无法正常启动、DNS 解析异常、网络不可达、性能下降等现象,这些异常可能是无法预测的,甚至是我们无法控制的。

即使应用程序更新成功,一旦线上环境产生不可预知的严重 Bug ,需要将应用程序回滚时,由于可变的服务器部署的不确定性,回滚的过程对于运维人员仍然是一项挑战。

当线上环境负载过高时,在可变的服务器部署模式下,响应也会显得不够高效。按照上述流程,需要创建新的虚拟机资源,再运行配置管理工具去部署该版本的应用。整个过程比较耗时,也较容易出错。

不可变的服务器部署

相对于可变的服务器部署模式,不可变的服务器部署模式要求服务器在部署完成之后,后续每次做部署变更时,不再对现存的服务器做任何更新或升级。

不可变的服务器部署模式下,我们将会基于基础的虚拟机镜像,创建新的虚拟机,为该虚拟机安装所需软件包,部署应用程序所需要的新的代码和配置。最后将该虚拟机打包成一个新的虚拟机应用镜像。

每次部署应用时,基于以上过程创建出来的应用镜像,创建新的服务器,在这个过程中,我们不会去改动当前环境中运行的基础设施资源。

同时在整个过程中,出现任何错误,我们将直接退出。待问题解决之后,基于以上过程重新打包镜像。如果一切顺利,待虚拟机启动成功,再将线上环境流量切换到该新虚拟机上,随后销毁掉的虚拟机。这样就完成了一次部署变更。

如果线上流量较高,需要横向扩展虚拟机数量时,只需将上述已经打包好的应用镜像部署成新的虚拟机,作为额外资源加入到线上集群即可。整个响应过程十分迅速且可靠。

基础设施即代码 (IAC)

基于 Packer、Ansible 和 Terraform 等开源工具,构建不可变服务器部署模式的持续集成和持续部署的 Jenkins Pipeline:

应用代码打包

为了使部署更加灵活,基础设施及配置代码将独立于应用本身代码,单独进行存放。

基于该代码仓库,创建自服务的 Jenkins Multibranch, 基于分支的变动自动触发 Build,并将软件包上传至中央制品仓库。

虚拟机镜像打包 Packer

Packer 是一个优秀的开源镜像打包工具。Packer 的 builder 支持主流的公有云、私有云平台以及常见的虚拟化类型。同时它支持的 provisioner 能覆盖主流的配置管理工具: Ansible, Puppet, Chef, Windows Shell, Linux Shell 等。

在不可变的服务器的应用场景中,通过 Packer 自动创建虚拟机,然后调用 Ansible provisioner 从中央制品仓库拉取软件包、部署所需额外依赖包以及相关配置,最后自动打包成虚拟机镜像并回收该虚拟机资源,上传至云平台中。

配置管理及安全加密 Ansible

Ansible 是一款简单的,易上手的开源配置管理工具。它能简化软件的安装部署,作为配置管理能提供灵活的模版渲染引擎以及针对敏感信息的加密

基础设施的创建和编排 Terraform

Terraform 作为开源的基础设施资源编排工具,能覆盖主流的云平台,非常适用于多云的环境。能提供灵活的部署选择,并能根据用户需求开发可插拔式的、自定义的 provider。

镜像部署过程中所面临的挑战

业务场景的不同,会带来部署方式的多样化要求,比如滚动部署、蓝绿部署等。

针对不可变的服务器部署模式,下面将介绍两种较典型的应用类型:

  • 负载均衡器 (LB) + 应用服务器 (Web Server)
  • 有状态的后端应用

Note: 主流的云厂商提供了类似动态虚拟机组的功能,来满足以上两种需求。本文主要介绍使用 Terraform 构建通用的解决方案。

负载均衡器配置的平滑更新

在 LB + Web Server 这种业务场景下,为了尽量减少服务不可用的时间,制定了蓝绿部署的解决方案。

在资源池中,会存在蓝和绿两种虚拟机组。每次版本更新时,会选择线上版本的一组虚拟机组做更新。

线上的版本更新完毕之后,会获取新创建的虚拟机 (VM) 的 IP 列表,将其动态更新至 LB 的后端。

在对 LB 进行更新时,定义该资源的 lifecycle 为 create_before_destroy = true。 这样每次更新时会先把新的后端虚拟机 IP 添加至 LB,待所有新虚拟机组的后端 IP 加入完毕之后,terraform 再去移除旧的虚拟机 IP 组.

Default

123456789

resource "xx_cloud_load_balance" "lb" {  # ...   lifecycle {    create_before_destroy = true  } }

有状态应用的平滑升级

同样为了有状态的应用更平滑的更新,在旧版本虚拟机销毁之前,需要发送一些个性化的指令,让应用程序能够优雅地退出。

除了对该虚拟机组资源的 lifecycle 指定 create_before_destroy = true, 还指定了一个 local-exec 的 provisioner 去优雅的停掉旧虚拟机组里的应用。

Note: 在本例子中,脚本 drain_nodes.sh 相对复杂,因为会并行创建多台虚拟机,所以需要加入类似锁的机制来避免竞争的情况发生。

Default

1234567891011121314

resource "xx_cloud_vm_instance" "instances" {  count = "${var.instance_count}"   # ...  lifecycle {    create_before_destroy = true  }   provisioner "local-exec" {    command = "bash ${path.module}/scripts/drain_nodes.sh ${var.old_instance_list}  } }

Note: 由于 terraform issue, 当指定了 create_before_destroy = true 时, 不能再使用 Destroy-Time Provisioners

部署的可靠性和稳定性

为了提高部署的可靠性,在销毁旧的虚拟机组或者更新 LB 配置之前,需要确保新创建的虚拟机是健康可用的。为此从两个角度去优化:

  • 为了尽早发现潜在的问题,在使用 Packer 打包镜像的时候,加入简单的健康检查机制,确保应用代码和配置是匹配的。
  • 在新的虚拟机启动之后,加入自我健康检查的脚本:

Default

12345678910

resource "xx_cloud_vm_instance" "instances" {   # ...   provisioner "local-exec" {    command = "bash ${path.module}/scripts/health_check.sh ${self.ipv4_address}  } }

镜像构建一次,多处部署

不同的环境 (Dev, QA, Prod), 会对应不同的配置文件。云环境中,支持给虚拟机传入 user_metadata 去区分不同的环境,由于镜像中包含所有环境的配置文件,可以通过传入的 user_metadata 去选择相应的配置文件启动应用程序。

Default

1234567

resource "xx_cloud_vm_instance" "instances" {   # ...  user_metadata = "dev" }

快速伸缩和回滚

从运维角度来看,可伸缩、可回滚性是平台维护中不可或缺的特性。

在 Terraform 中,我们可以通过简单的指定 count 数量来伸缩虚拟机数量:

Default

1234567

resource "xx_cloud_vm_instance" "instances" {   count = "${var.instance_count}  # ... }

由于镜像包含应用程序所需要的所有配置和代码,虚拟机镜像的版本也就代表了应用程序的版本。回滚应用程序相当于指定虚拟机镜像的版本重新部署:

Default

1234567

resource "xx_cloud_vm_instance" "instances" {   # ...  image_version = "${var.image_version}" }

镜像的打包效率

相对于可变服务器部署模式,由于打包虚拟机镜像过程较为耗时,在一定程度上会加长整个部署的时间。

因为镜像里包含了应用程序所需要的代码和配置,每一次配置更新或者代码更新需要重新打包镜像时,可以考虑把配置和代码从镜像中分离出来提高打包效率:

  • 将镜像分层管理,分为基础操作系统镜像和应用镜像。基础操作系统镜像中包含软件运行所需要的基本环境以及相关依赖(Python、C#、 第三方工具或者相关依赖包等)。这样在构建应用镜像时只安装与应用相关的代码和配置,不必再重新安装基础镜像中存在的基础软件包、配置,缩短了应用镜像的打包时间。
  • 将配置迁移至配置管理服务,应用程序启动时从该配置服务中动态获取配置信息,避免每次因为配置文件更新需要重新打包镜像。
  • 将配置和代码迁移至网络文件存储(NFS),虚拟机每次启动时挂载该网络文件存储去读取配置和代码。每次代码或者配置文件更新只需更新挂载的文件系统中的内容。可以极大的降低镜像打包频率。

总结

相对于 AWS auto scaling groupGoogle Autoscaling groups 和 Azure VMSS 等公有云平台提供的原生服务,以上解决方案还未能集成云平台中的监控系统做到资源的自动伸缩。但在多云的环境,或云平台提供的虚拟机组功能欠缺时,这种基于 Terraform 本身构造的通用解决方案仍有用武之地。在实际场景中用户可以灵活选择。

相对于传统的应用部署方式,不可变服务器部署模式延长了从代码提交到收到部署反馈的时间,在初期也会给开发者带来相应的学习成本,在一定程度上牺牲了开发体验。但不可否认,它所带来的环境的一致性、运维的弹性,仍然是 Devops 运动中首推的解决方案。

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 如何利用开源DevOps工具完成云上的自动运维

    内容概况 云计算的特点是开箱即用,可以随时的扩缩容,不用考虑硬件的损坏问题,也有丰富的云服务和云平台供我们选择。在本次演讲中,黎山通过实际应用场景为我们讲述了基...

    IT大咖说
  • 基础架构之百变魔方

    “基础架构即代码(Infrastructure-as-Code,IaC)”是一种使用新的技术来构建和管理动态基础设施的方式。它把基础设施、工具和服务以及对基础设...

    yuanyi928
  • 10节课带你深入学习 DevOps 工程

    DevOps 现在真的很热门,对于杰出的工程师和 DevOps 专业人员来说有许多工作机会。 如果你想成为一名 DevOps 工程师,那么你来对地方了。在本文中...

    LinuxSuRen
  • ​DevOps 工程师成长日记系列二:配置

    在第一篇文章中,我对 DevOps 工程师的工作定义是搭建一个数字化的全自动流水线来高效地将代码从编写环节部署到生产环境中:《DevOps 工程师成长日记系列一...

    CODING
  • 从技术雷达看DevOps的十年 - 基础设施即代码和云计算

    在上一篇文章中,我们讲到了DevOps和持续交付的关系。本篇将回顾最先改变运维工作的相关技术 —— 基础设施即代码和云计算,通过技术雷达上相关条目的变动来跟踪其...

    ThoughtWorks
  • 基础架构即代码入门介绍-packer

    基础设施即代码的意思是把基础设施的实现方式写成代码。告别手工配置各类资源而采用基础设施即代码的方式,可以获得多种好处:

    刘宇雷
  • Terratest:一个用于自动化基础设施测试的开源Go库

    Gruntwork开源了他们的Go框架Terratest。该框架可以用于编写测试基础设施的自动化测试。该库内置了对Terraform和Packer的支持。

    李海彬
  • 什么是云编排?

    SDNLAB
  • 10 倍效率提升!开源工具 Packer 开启敏捷开发第一步

    如今多云部署日趋普遍,它在帮用户提高业务可用性、降低故障风险的同时,也带来了多云平台网络互通的问题。为了给用户提供可无缝连接的多云网络加速服务,UCloud 推...

    GitHubDaily
  • 以代码的形式构建 Jenkins

    在我们公司,我们尝试使用‘一切事物即代码’的模式,该模式涉及到可复制的基础架构,监控,任务等方面。但是在这篇文章当中,我将向你展示怎样将这种模式运用到 Jenk...

    LinuxSuRen
  • 使用 Docker、Kubernetes 和 Azure DevOps 实现 DevOps

    这篇文章,我们将会介绍所有你想了解的 DevOps 知识,看完后你可以着手构建自己的 CI/CD 流水线。

    LinuxSuRen
  • AWS 上的云原生 Jenkins

    我们使用 Jenkins 搭建持续交付流水线,和其他很多团队一样,这些年我们围绕 Jenkins 创建了很多工作流程和自动化。Jenkins 是我们团队取得成功...

    LinuxSuRen
  • 追赶 terraform,让基础设施代码化更加容易,pulumi 都做了些什么?

    好久不写 devOps 代码,程序君感觉莫名手欠。最近看着一个开源项目 pulumi 比较有意思,这个周末就在自己的 aws 账号里作死尝试了一把,嗯,还挺香。...

    tyrchen
  • 云原生应用程序:原因、内容及方法

    本文阐释了构建云原生应用程序的重要性、优点及其实现方式。

    Techeek
  • 云原生应用程序:为什么,是什么和如何做

    云原生是一种构建和运行应用程序的方法,可以利用云计算模式的优势 —— 按需计算的能力和即用即付的定价模式。这些应用程序是以云计算平台的快速响应为基础构建和部署的...

    厚厚墩儿
  • 介绍Terraform Cloud - 免费远程状态管理

    在阅读了前几篇生态产品的文章以后,希望大家对基础架构即代码在腾讯云上应用的基础概念和步骤有了了解:

    刘宇雷
  • 最佳的云计算基础设施自动化工具有哪些?

    数据丢失是IT行业中最大的问题之一,可以解决这个问题的一个方法是使用基础设施自动化工具。它们用于自动化、协调和帮助管理软件和硬件,以处理重复性任务。

    静一
  • HashiCorp Vault | 技术雷达

    HashiCorp Vault是一款企业级私密信息管理工具。说起Vault,不得不提它的创造者HashiCorp公司。HashiCorp是一家专注于DevOps...

    ThoughtWorks
  • 解读基础设施即代码|洞见

    现代软件开发对基础设施的管理提出了更苛刻的要求: 产品要适应瞬息万变的市场,要求基础设施有更快的响应速度。持续交付和DevOps的推行要求产品团队对部署和运维要...

    ThoughtWorks

扫码关注云+社区

领取腾讯云代金券