使用Packer实现自动化构建UCloud云主机镜像
背景
云主机是用户使用最高频的云产品之一。随着云主机数量的增多,如何在云主机中保证版本化部署的一致性,成为用户常见的难题。在现有情况下,用户首先需要手动或使用脚本连接主机,然后再进行部署安装,操作流程复杂且对环境要求苛刻,难以保证一致性和可用性。
为了解决此类问题,UCloud 开发了相关代码,并被自动化构建镜像工具 Packer 的官方仓库所采纳。通过 Packer 创建自定义镜像,可以减少部署时间并提高可靠性,提高了用户自动化部署的能力。8月14日,Hashicorp 官方正式发布了版本 1.4.3 ,其中包括了 UCloud Packer Builder。
Packer是什么?
Packer 是 Hashicorp 公司推出的自动化打包镜像的轻量级开源工具,云厂商通过构建自己的 Builder 集成到 Packer 中去,即可凭借单一配置文件,高效并行的为多云平台创建一致性的镜像。目前 Packer 已经形成完整生态,并与多家主流云厂商建立合作。
UCloud Packer 可以运行在常用的主流操作系统上,它不是 Chef、Puppet 等软件的替代品,而是集成并使用这些自动化配置工具在镜像上预装软件等。再配合 UCloud Terraform、UCloud CLI 等工具,可以在多云的 DevOps 场景下,实现基础设施即代码(IaC)、持续集成和快速交付。
如下图所示,Packer 通过在 Provisioner 中集成 Chef、Shell、Puppet 等工具,制作包含各类软件的不可变镜像,供多云平台的云主机、Docker 等使用。
Hashicorp 官方将 Packer 的优势描述如下:
- 基础架构迅速部署:Packer 镜像可以在几秒钟内启动完全配置的云主机,有利于生产和开发;
- 多提供商可移植性:Packer 可以为多云平台创建了相同的镜像,每个环境都能运行相同的机器镜像,提供最终的可移植性;
- 稳定性高:Packer 在构建镜像时会为机器安装和配置所有软件。如果脚本中存在错误,可以被提前捕获,而不是在启动计算机几分钟后;
- 可测试性高:Packer 在构建机器镜像后,可以快速启动该机器镜像并进行冒烟测试,以验证镜像是否正常工作。如果是正常工作,则可以确信从该镜像启动的任何其他计算机都能正常运行;
- 可扩展性高:Packer 的插件机制使得它能够自如的根据需求集成工具和拓展功能。
Packer 与传统控制台创建镜像的对比:
生命周期
利用 Packer 打包镜像的完整周期如下:
- 用户通过构建 JSON 模版,执行 packer build 命令调用 UCloud Builder;
- 参数提前校验保证可用性;
- 创建云主机、EIP 等相关临时资源(若配置为内网环境则无需 EIP);
- 通过 SSH 或 WinRM 等连接主机,执行 Provisioner 进程;
- 关闭云主机,并创建镜像;
- 复制镜像;
- 删除主机、EIP 等临时资源;
- 执行后处理进程(如本地镜像导入等)。
使用演示
下面通过一个视频来形象地展示 Packer 的使用方式。目标是构建一个装有 nginx 应用的镜像,我们首先创建一个 test.json 文件,然后执行如下命令一键构建镜像:
packer build test.json
Packer 对多云管理的价值
在此次 Hashicorp 官方发布前,UCloud 内部已经积累了一定的 Packer 使用经验。从中发现,如果需要管理多云环境,或者要在公有云与私有云间维护相同的系统,又或者构建的是虚拟机而不是容器,Packer 都是一个很好的选择。
通过一个具体例子来说明。下面这段代码定义了一个 UCloud 公有云上的虚拟机镜像,Packer 利用 ucloud-uhost Builder 配置的参数,先创建一个干净的 CentOS 7 系统,再 ssh 执行 provisioner 定义中指定的三段 shell 脚本,最终成功创建镜像并返回镜像 ID。
{ "variables": { "ucloud_public_key": "{{env `UCLOUD_PUBKEY`}}", "ucloud_private_key": "{{env `UCLOUD_SECRET`}}", "ssh_user": "root", "ssh_password": "password", "ucloud_project_id": "org-projectid", "image_id": "uimage-dpdgyw", "consul_version": "1.5.1", "region": "cn-bj2", "az": "cn-bj2-02" }, "builders": [ { "type": "ucloud-uhost", "public_key": "{{user `ucloud_public_key`}}", "private_key": "{{user `ucloud_private_key`}}", "project_id": "{{user `ucloud_project_id`}}", "region": "{{user `region`}}", "availability_zone": "{{user `az`}}", "instance_type": "n-basic-2", "source_image_id": "{{user `image_id`}}", "ssh_username": "{{user `ssh_user`}}", "ssh_password": "{{user `ssh_password`}}", "image_name": "consul-server-{{user `consul_version`}}" } ], "provisioners": [ { "type": "shell", "scripts": [ "scripts/config-yum.sh", "scripts/consul-service.sh", "scripts/consul-server.sh" ], "environment_vars": [ "CONSUL_VERSION={{user `consul_version`}}" ] } ] }
此时若有额外需求,要求将其也部署到私有云的 Kubernetes 上,该怎么办?一种方法是把 shell 脚本改写成对应的 Dockerfile,但若是构建过程非常复杂,那么改写的过程也会很复杂,并且可能引入错误。
但用 Packer,只需要修改一下 builder 配置的细节:
{ "variables": { "consul_version": "1.5.1" }, "builders": [ { "type": "docker", "image": "centos:7", "commit": true, "changes": [ "CMD [\"tail -f /dev/null\"]", "ENTRYPOINT [\"\"]" ] } ], "provisioners": [ { "type": "shell", "scripts": [ "scripts/config-yum.sh", "scripts/consul-service.sh", "scripts/consul-server.sh" ], "environment_vars": [ "CONSUL_VERSION={{user `consul_version`}}" ] } ], "post-processors": [ [ { "type": "docker-tag", "repository": "lonegunmanb/consulServer", "tag": "0.1" }, "docker-push" ] ] }
在公有云平台上已经过测试的构建脚本,就可以直接用来构建 Docker 镜像,并且在构建完成后,自动打上 tag,push 到 Docker Hub 仓库去。并且,由于 Packer 是执行完 provisioner 后,通过 docker commit 的方式构建镜像,所以 Packer 的构建只会增加额外的一个层,避免不恰当的 Dockerfile 增加多个层的问题。
Packer +Terraform,1+1>2
Packer 配合 Git、Terraform、UCloud CLI 等使用,可以实现 DevOps 下的基础设施即代码(IaC),达到持续集成和快速交付。
如下图,Packer 配合 Git 对镜像的配置文件做版本化控制,从而来实现服务的版本化,保证了实例的最终一致性,然后利用 Packer 和 Terraform 自动化构建服务的目的。
- 在自动化流程中,首先变更镜像配置仓库,触发执行 Terraform 命令;
- Terraform 执行 packer build 命令构建镜像;
- 将制作成功的镜像查询给 Terraform 使用;
- 最后由 Terraform 构建并启动新实例替换原有的旧实例,完成服务自动化部署。
UCloud 此前已提供对 Terraform 的官方集成,可通过产品文档了解更多详情。文档链接:https://docs.ucloud.cn/compute/terraform/index
总结
UCloud 通过对 Packer 的接入,提供了一种在云主机中自动化配置环境的能力,而且它可以配合 cloud-init 及一些常用的自动化部署软件使用,进一步拓展功能。另外,通过配合UCloud Terraform 、UCloud CLI 等工具,可以实现对基础架构的版本化和代码化管理,达到精准交付和快速部署以及最终一致性。
最后需要云主机的朋友可点击了解详情

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
getty 发布,一个完全基于 java 实现的 aio 框架
说说写这个框架的原因: 1、作者本人是一个码农,比较喜欢研究技术,特别是网络通讯。 2、JDK1.7升级了NIO类库,升级后的NIO类库被称为NIO 2.0。正式提供了异步文件I/O操作,同时提供了与UNIX网络编程事件驱动I/O对应的AIO。AIO的发布使得实现一套网络通讯框架变得相对简单。但如果你不努力,可能也无法理解哦。 3、本人对netty比较喜欢,无论是其性能还是编程思想(JBOSS提供的一个java开源网络框架,可以说是java网络通讯里的一哥,极其稳定和强大的性能使得被广泛使用) 4、有了netty为何还要自己造轮子?这里有两个原因,其一是本人就喜欢造轮子,这是病,改不了。其二,netty经过多年的发展,其生态体系已经比较庞大,导致其代码比较臃肿,再者其高深的设计哲学我等凡夫俗子很难悟其精髓。因而索性自己造一个。 5、netty毕竟是别人的东西,还是老外的。并且国内也有许多优秀的开源框架。想了想,为何不自己搞一个呢,于是乎脑袋发热,抽时间造了一个。 说说getty的特点: 1、完全基于java aio,整个工程只依赖 slf4j(一个日志的门面框架),对工程几乎没有入侵性...
- 下一篇
京东技术中台的Flutter实践之路
在 2019 年,Flutter 推出了多个正式版本,支持的终端越来越多,使用的项目也越来越多。Flutter 正在经历从小范围尝鲜到大面积应用的过程,越来越多的研发团队加入到 Flutter 的学习热潮中,京东作为互联网大厂之一也积极参与了 Flutter 的跨端方案研究。本文将介绍京东在 Flutter 上的应用方案和相关优化成果。 为什么考虑Flutter技术方案 其实京东很早就开始研究并实践跨端的开发解决方案,最早使用的是Hybrid App的技术方案,从2015年低开始逐步转向RN技术栈,目前应该是业内RN技术平台应用最广泛、配套设施比较完善的公司之一。从2018年中开始,我们也关注到了Flutter技术,最吸引我们的特性是高性能和兼容性。这两点也是目前RN技术相对不足的地方。高性能指的是复杂场景和交互下的渲染性能,兼容性指的是不同终端平台上的布局和体验的一致性,这点在碎片化严重的android平台上尤其重要。 京东在Flutter的实践 随着2018年底Google正式发布了Flutter预览版本,京东内部也越来越多的研发团队有用Flutter进行开发业务的诉求。我们正式启...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
- SpringBoot2更换Tomcat为Jetty,小型站点的福音
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- CentOS8编译安装MySQL8.0.19
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- SpringBoot2整合Thymeleaf,官方推荐html解决方案
- SpringBoot2整合Redis,开启缓存,提高访问速度
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题
- Docker使用Oracle官方镜像安装(12C,18C,19C)