亚马逊AWS官方博客
深度解析 AWS Firecracker 实战篇 – 一起动手点炮竹
摘要
上篇文章介绍了 AWS Firecracker 的原理,今天笔者将介绍两种在 Firecracker 上运行容器应用的方法,并演示 Ignite 与 Footloose 方式。
Firecracker 单词中文翻译是『炮竹』,本文的动手实验环节就将教大家如何安全的『点燃』炮竹,而点燃这个动词对应的英语单词恰好是 Ignite,也就是今天将要用到的开源组件。
Firecracker-containerd 介绍
上一篇文章讲到 containerd 作为容器运行时生命周期管理工具,已经成为了事实标准,为了方便大家沿用同样的方式管理 Firecracker 虚拟化容器,AWS 开源了Firecracker- containerd 这个项目,并计划在未来支持 Kubernetes 与 ECS 编排工具。但由于这个项目还在比较早期阶段,部署和操作都比较,因此本文中将不再进行演示,为了便于大家理解将官方的架构图和流程图附带到了文中,并简单介绍主要的组件:
- Snapshotter:通过创建文件形式为 MicroVM 提供块设备,该 Snapshotter 用于将容器映像提供给 MicroVM。 Snapshotter 作为进程外 gRPC 代理插件运行,与 Docker 不同的是目前仅支持 Native 和 Device Mapper 两种方式。
- Control Plugin:用于管理运行时的生命周期,并实现控制 API 来管理 MicroVM 的生命周期。
- Runtime:连接 MicroVM 外的 containerd 到 Firecracker VMM,同时用于 VM 生命周期管理以及 Agent 对应的容器生命周期管理,该 Runtime 以进程外 Shim Runtime 方式实现,使用 ttrpc 通信。
- Agent:运行在 MicroVM 内与 RunC 交互负责创建容器,同时通过 vsock 与 MicroVM 外部 Firecracker 运行时进行通信。
- Image Builder:用于构建 Firecracker 虚拟机镜像系统根文件系统(ext4 格式,包含 RunC 和 Agent),配合上 ELF 格式的内核镜像 vmlinux 文件,就可以启动 Firecracker MicroVM 了。
- Network:支持容器的 CNI 插件,每个 MicroVM 通过创建 TAP 网口(二层设备,宿主机可直接对字符设备文件进行读写),同时在自己的网络命名空间中,创建虚拟网线连接到 CNI 网桥,以这样的方式与外界通信。
- MMDS: MicroVM Metadata Service,为 MicroVM 提供元数据服务
WeaveWorks Ignite 与 Footloose 介绍
这两个开源工具由 WeaveWorks 这家在开源容器领域的著名公司开发,而对于熟悉 AWS 的朋友,想必对这家公司的另外一款工具 eksctl 肯定不会陌生,它现在已经是 AWS 成为了官方 EKS 集群管理工具了,而 Weave 项目也是最主流的容器网络通信方案之一。
作为 Docker Engine 或者 Vagrant 的替代开源项目 Ignite 用于运行虚拟化容器,同时在命令行、操作方式上保持了与 Docker 尽可能一致。同时还开发 Footloose 以及 Firekube 对应 Docker-Compose 与 Kubernetes 用于虚拟化容器编排。
Ignite 实现原理上类似 Firecracker-containerd,能够兼容 OCI 镜像格式和 Dockerfile文件,而应用则不需要再次包裹在 RunC 容器中,而是直接在 Firecracker 虚拟机上运行并由容器中运行的 ignite-spawn 与 MicroVM 进行管理通信。
Firecracker 运行环境目前支持 Intel CPU(AMD 与 ARM 支持截止到发稿时还是预览状态),宿主机使用 Linux 操作系统,内核版本需要大于等于4.14。为了方便大家在本地环境中测试,笔者将在动手实验部分使用最为主流 CentOS 7 操作系统(手动升级内核到4.19版本),同时 Ubuntu 18.04 以及 Fedora 30 操作系统环境经测试也能正常运行,安装操作方法类似。
动手实践一:通过 Ignite 启动 MicroVM
一、首先启动一台裸金属 EC2 服务器(metal, m5.metal, r5.metal 或 i3.metal),或者使用本地计算机(如果是虚拟化环境需要打开 nested 嵌套虚拟化),使用 CentOS Linux 7 AMI,选择 Public 子网。
二、SSH 登录该 EC2,运行 sudo su,切换到 root 用户,执行以下命令检查系统环境
- 检查 CPU 是否支持虚拟化,如结果不是 VT-x 而是 full 则表示当前环境为虚拟机不支持 Firecracker VMM。
- 检查 Linux 是否支持 KVM,命令无显示表示不支持。
- 检查 Linux Kernel 版本,如果低于 14(CentOS 默认为3.10)请执行步骤三
三、执行以下命令,完毕后重启 EC2,升级操作系统内核版本到19。
重启后检查 Linux Kernel 版本已升级到4.19。
四、安装 ignite 相关软件以及配置相应参数(ignite 运行并不依赖 docker,但是当前62版本存在依赖检查的 bug,见05ad564提交,所以下面依然安装了 docker 组件)。
五、导入 Docker 基础镜像(使用 Weavworks 提供的 Amazon Linux 2 Dockerfile),读者也可以根据需要换成 Alpine (weaveworks/ignite-alpine)、CentOS 7(weaveworks/ignite-centos)或者 Ubuntu 18.04 (weaveworks/ignite-ubuntu)镜像,或者构建应用镜像(建议在以上操作系统基础镜像上构建,否则需要安装 openssh、bash 等基础工具)。
六、导入 MicroVM 操作系统 Kernel 文件镜像,为了区别于宿主机这里选择14.123版本。
七、创建并启动名为 micro-vm 的虚拟机。
八、通过 ssh 登录 micro-vm(如果希望 tty 方式登录,使用 ignite vm attach 命令,此时需要操作系统帐号和密码),然后就可以在 MicroVM 中运行任何 linux 操作命令了。
九、Ignite 在操作上和 docker 命令十分类似,这里列举了一些常见命令:
- 查看所有MicroVM
- 查看MicroVM 日志
- 关闭 MicroVM
- 删除 MicroVM
- 检查 MicroVM/Image/Kernels 信息
动手实践二:通过 Footloose 部署 httpd 应用集群
接下来通过 footloose 的 yaml 编排文件来运行3台部署了 httpd 应用 MicroVM,它作为一个编排工具后端支持 docker 和 ignite 两种模式,使用上与 docker-compose 类似。
一、编写 httpd 的 Dockerfile 文件。
二、编写 html 文件。
三 、编写yaml 编排文件。
四、创建本地镜像仓库(这里简单起见使用 Docker Registry 当然也可以使用 Amazon ECR),打包镜像并上传。
五、使用 footloose 创建httpd 应用。
六、由于裸金属 EC2实例费用较高,完成测试后记得及时终止实例,如果希望保留环境可以对操作系统镜像进行快照。
小结
相信认真做完实验的读者心里一定会有这么一个问题,我明明打包的是一个容器镜像,为什么启动运行却是一台虚拟机?没错,事实的确如此,在过去虚拟化和容器隔离技术泾渭分明,而今天这两项技术开始相互融合取长补短。笔者相信在不远的未来,随着 Serverless 架构的普及,作为应用的开发和部署人员,一定不再需要去操心工作负载跑在何种运行时环境中。专注于业务将计算环境放心的交给安全可靠的云服务商就行了。
引用
https://github.com/firecracker-microvm/firecracker-containerd
https://www.weave.works/blog/fire-up-your-vms-with-weave-ignite
https://github.com/weaveworks/ignite
https://github.com/weaveworks/footloose/