TL ; DR
在 WebP Cloud Services ,我们所有的组件都是容器化部署的,代码托管和 CI/CD 都是在 GitHub 和 GitHub Actions 上面完成,这套比较 “现代” 的工作流让我们的工作量节省了很多时间和成本。
但是在之前的文章 Hetzner CAX 系列 ARM64 服务器性能简评以及 WebP Cloud Services 在其上的实践 中我们测试发现 Hetzner ARM64 的机器性价比非常不错之后我们便将基础设施全部迁移到了 Hetzner 上。
由于开始使用 ARM64 的机器,我们便需要支持 Multi-Arch 的 Docker 镜像,一开始我们继续沿用了 GitHub Actions 的 Job ,用 QEMU 直接构建镜像:
- name: Build and push tagged images
if: startsWith(github.ref, 'refs/tags/')
uses: docker/build-push-action@v3
with:
context: .
platforms: linux/amd64, linux/arm64
push: true
tags: |
ghcr.io/${{ github.event.repository.full_name }}:${{ steps.imageTag.outputs.tag }}
然后便发现这么做会导致我们镜像构建速度从之前的 2min 不到变为了 20+min
为了解决这个问题,我们尝试使用 GitHub Actions 官方 Runner 和我们在 Hetzner 上的 Self-hosted runner 分别原生构建对应架构的镜像并通过一个额外 Job 缝合两个镜像的方式制作 Multi-Arch 镜像,将时间缩短到了 2min 左右
为此,我们写了一篇博客记录了我们的完整的改造步骤和其中遇到的坑:「混合部署 GitHub Actions Runner:Multi Arch 镜像构建速度飙升 10 倍!」: https://blog.webp.se/github-actions-hybrid-runner-zh/
1
winterpotato 2023-07-31 21:09:20 +08:00
优秀,就等谁给我赞助一个 arm 机器了!
|
2
crsmk01 2023-08-01 11:55:04 +08:00
LZ Project 的 Dockerfile 里面有 CPU 密集型任务(编译等) ?我之前也遇到过,如果用 QEMU 模拟器,在 macOS M1 芯片的主机上用 docker buildx build --platform linux/arm64,linux/amd64 ... 构建双架构镜像时,2 分钟+ 的构建任务,时间拉长到 20 分钟+ ,后来把 linux/amd64 镜像的构建单独找了一台 x86-64 架构的主机去构建,速度嗖嗖的提升。
不过这还不够,还可以通过交叉编译,构建速度有 100 倍的提升。 https://medium.com/@tonistiigi/faster-multi-platform-builds-dockerfile-cross-compilation-guide-part-1-ec087c719eaf |
3
n0vad3v OP @tdy218 是的,如我们文章中所描述,这里的任务主要是 CI 测试 + 构建镜像(包括了编译 Binary ),相比较我们直接拆分机器原生构建,我们还多了个通过操作 manifest 缝合镜像的动作。
我们这里没有使用交叉编译的原因是因为有个 `vips` 库的存在不方便交叉编译,关于这个问题我们之前踩了一堆坑,并写了一篇文章分享: [libvips, CGO 与 purego——如何让 Go 应用跨平台编译运行]( https://blog.webp.se/golang-libvips-cgo-zh/) |