制作一个能构建 dotnet AOT 的 gitlab runner 的 Debian docker 镜像
内容提要
本文介绍了在Debian Docker镜像中构建dotnet AOT应用的方法，并配置GitLab Runner进行自动构建。作者使用了debian:buster-slim镜像，并安装了必要的依赖。然后下载了dotnet 8和dotnet 6的sdk压缩包，并解压到docker镜像中。接下来配置了GitLab Runner，并将配置文件打入docker镜像中。最后，作者提供了一些踩坑记录和解决方法。
延伸解读
glibc 版本兼容性：选择 Debian Buster 的关键原因
文章指出，WSL 中的 glibc 版本为 2.36，而目标系统 UOS 20.1050.11068.102 的 glibc 为 2.28，麒麟 Desktop-V10-SP1 为 2.31。在 WSL 中构建的 AOT 应用会因 glibc 版本过高而无法在目标系统运行。因此作者选用 debian:buster-slim 镜像，其 glibc 版本为 2.28，恰好与 UOS 相同，且低于麒麟，从而确保构建出的应用能在两者上运行。这提醒读者，AOT 构建必须考虑目标环境的 glibc 版本。
交叉编译：在 x64 上构建 ARM64 AOT 应用
由于缺少 ARM64 机器，作者通过交叉编译在 x64 系统上构建 ARM64 应用。在 Dockerfile 中，添加 arm64 架构并安装 gcc-aarch64-linux-gnu、binutils-aarch64-linux-gnu 等工具链，发布时指定 -r linux-arm64 即可。这为没有 ARM64 硬件的开发者提供了可行方案，但需注意安装正确的依赖包，并参考微软官方交叉编译文档。
GitLab Runner 配置：注册与持久化
作者采用取巧方式配置 GitLab Runner：先运行容器并挂载目录，在容器内执行注册命令生成 config.toml，再将配置文件复制到 Dockerfile 中打入镜像。这样镜像启动后即带有注册信息。注意注册时需指定正确的 URL 和 token，并设置与 .gitlab-ci.yml 中一致的 tags。入口命令必须使用 gitlab-runner run，而非 start，否则容器会退出或 runner 不上线。
构建优化与常见问题规避
为提升构建速度，作者建议挂载 NuGet 缓存目录（如 /root/.nuget/packages 和 /root/.local/share/NuGet），避免每次重启容器重新拉取包。同时，不建议挂载代码仓库路径，以免多容器构建相互影响，且可能因 Windows 杀毒软件导致 llvm-objcopy 失败。此外，需在 Dockerfile 中创建 dotnet 软链接，确保 CI 脚本中能全局调用 dotnet 命令。
Q&A
如何在Debian Docker镜像中构建dotnet AOT应用？
可以使用基于debian:buster-slim的Dockerfile，安装必要的依赖，下载dotnet SDK压缩包并解压，配置环境变量和GitLab Runner。
为什么选择debian:buster-slim作为基础镜像？
因为debian:buster-slim的glibc版本较低，适合构建可以在UOS和麒麟系统上运行的AOT包。
如何解决构建过程中glibc版本不兼容的问题？
通过使用debian:buster-slim镜像，确保构建环境的glibc版本与目标系统兼容。
如何配置GitLab Runner与Docker镜像对接？
下载GitLab Runner的二进制压缩包，拷贝到Docker镜像中，并配置相关权限和配置文件。
在Dockerfile中如何设置dotnet命令的全局使用？
通过设置环境变量DOTNET_ROOT和PATH，并使用ln命令创建dotnet的符号链接。
如何使用交叉编译技术构建ARM64应用？
在x64系统上添加arm64架构支持，安装必要的依赖，并在构建时指定-r参数为linux-arm64。
