后端通信网络异步编程【免费下载链接】nettyNetty project - an event-driven asynchronous network application framework项目地址https://gitcode.com/gh_mirrors/ne/netty点击查看免费下载本文围绕 Netty 仓库docker/目录下的官方容器化构建体系展开系统讲解如何用 Docker Compose 在 CentOS 6 / CentOS 7 / Ubuntu / Amazon Linux 2023 上编译 Netty 全量代码、执行测试以及在 x86_64 主机上为 aarch64、riscv64 交叉编译transport-native-epoll、transport-native-io_uring、codec-native-quic等原生模块。读完本文你将掌握 Netty 官方 docker 镜像的使用姿势、compose 分层覆盖模型、JDK 版本矩阵、构建/部署/签名各服务的能力边界以及镜像内部的工具链与 OpenSSL 编译细节可直接复用到自己的 CI 或本地构建中。一、docker/ 目录官方构建环境全家桶Netty 仓库根目录下的 docker/ 目录集中存放了全部容器化构建资产包括文件用途docker-compose.yaml基础 compose 文件定义构建/部署等服务及共享公共配置docker-compose.centos-6.18.yamlCentOS 6 JDK 8Zulu 8.0.482变体docker-compose.centos-7.18.yamlCentOS 7 JDK 8Zulu 8.0.482变体docker-compose.centos-7.111.yamlCentOS 7 JDK 11Zulu 11.0.30变体docker-compose.centos-7.117.yamlCentOS 7 JDK 17Zulu 17.0.18变体docker-compose.centos-7.21.yamlCentOS 7 JDK 21Zulu 21.0.10变体docker-compose.centos-7.24.yamlCentOS 7 JDK 24Zulu 24.0.2变体docker-compose.centos-7.25.yamlCentOS 7 JDK 25Zulu 25.0.2变体docker-compose.centos-7.26.yamlCentOS 7 JDK 26-eaOpen 26.ea.35变体docker-compose.centos-7.graalvm121.yamlCentOS 7 GraalVM CE 21 变体用于 native-image 验证docker-compose.centos-7.cross.yamlaarch64 交叉编译服务定义docker-compose.ubuntu-20.04.cross.yamlriscv64 交叉编译服务定义docker-compose.al2023.yamlAmazon Linux 2023 aws-lc 构建供 netty-tcnative 使用Dockerfile.centos7 / centos6 / cross_compile_aarch64 / cross_compile_riscv64 / al2023各镜像的构建脚本这套体系的设计核心是分层覆盖compose override基础文件 docker-compose.yaml 只负责定义“做什么”构建命令、挂载、环境变量JDK 版本变体文件只负责覆盖runtime-setup服务的镜像标签与java_version参数。两者用多个-f叠加后执行即可在任意 JDK 版本下跑同一套构建逻辑。二、快速开始前置条件与命令形态官方文档 docker/README.md 的第一步是把工作目录切到 Netty 仓库根目录因为 compose 文件通过..:/code或..:/netty把整个仓库挂载进容器所有构建命令都基于 Maven Wrapper 在容器内执行cd /path/to/netty/随后即可用 docker compose 的多文件叠加方式运行某个服务命令形态统一为docker compose -f docker/docker-compose.yaml -f docker/变体文件.yaml run service其中service是叠加后 compose 文件中定义的服务名如build、build-leak、shell、deploy等详见第五节。docker-compose.yaml 中的公共配置common锚点奠定了每个服务的默认环境环境变量透传GPG_KEYNAME、GPG_PASSPHRASE、GPG_PRIVATE_KEY、MAVEN_OPTS从宿主机透传进容器供发布签名使用目录挂载~/.ssh:/root/.ssh、~/.gnupg:/root/.gnupg、~/.m2:/root/.m2复用本地 Maven 仓库加速构建、..:/code挂载仓库根目录工作目录容器内统一为/code安全选项seccomp:unconfined放开 seccomp 限制避免部分原生编译/测试被沙箱策略干扰。需要注意README 示例中的run test里的test服务名在当前仓库的 compose 文件中并未直接定义实际可用服务名以叠加后的 compose 文件为准shell、build、build-leak等例如想进入容器交互调试可直接运行docker compose ... run shell。三、CentOS 6 构建环境验证旧系统兼容性Netty 对老系统如 CentOS 6的兼容性验证依赖专用镜像 Dockerfile.centos6其基础镜像为centos:6.10amd64。官方 README 给出的两条命令为CentOS 6 Java 8docker compose -f docker/docker-compose.yaml -f docker/docker-compose.centos-6.18.yaml run testCentOS 6 Java 11docker compose -f docker/docker-compose.yaml -f docker/docker-compose.centos-6.111.yaml run test说明第二条命令引用的docker-compose.centos-6.111.yaml在当前仓库中未找到实际存在的对应文件是 docker-compose.centos-7.111.yamlCentOS 7 Zulu JDK 11.0.30与 docker-compose.centos-7.117.yamlCentOS 7 Zulu JDK 17。如需验证 CentOS 6 JDK 11请以仓库实际文件为准确认变体文件是否存在或改用 CentOS 7 的对应变体。这也是本 README 与仓库当前状态存在的一处版本漂移使用时建议先ls docker/docker-compose.centos-6*核对文件名。以 docker-compose.centos-6.18.yaml 为例其只覆盖了runtime-setup的镜像标签netty:centos-6-1.8与构建参数java_version: 8.0.482-zulu其余所有服务build、build-leak、deploy、stage-snapshot、stage-release、shell等均被统一指向该镜像从而保证整个 CI 矩阵在同一 JDK 环境下运行。从 Dockerfile.centos6 可以看到该镜像的几个关键实现细节软件源走 vaultCentOS 6 已 EOLDockerfile 通过sed将 yum 的mirrorlist替换为linuxsoft.cern.ch/centos-vault/6.10才能继续安装依赖编译工具链安装devtoolset-9-gcc与devtoolset-9-gcc-c并在.bashrc中启用source /opt/rh/devtoolset-9/enable从源码构建 OpenSSL 3.x由于系统自带 OpenSSL 太老镜像用 devtoolset-9 源码编译openssl-3.6.1./Configure linux-x86_64 --prefix/opt/openssl-3.6.1 --libdirlib shared no-asm no-apps其中no-asm是因为 devtoolset-9 无法可靠编译 OpenSSL 手写 x86_64 汇编并校验下载包的 SHA256JDK 通过 SDKMAN 安装默认java_version为8.0.302-zulu由sdk install java安装并设置JAVA_HOME可选 GraalVM native-image若当前 JDK 是 GraalVM存在gu命令则自动安装native-image组件。四、CentOS 7 构建环境JDK 版本矩阵CentOS 7 是当前构建矩阵的主力基础镜像为 Dockerfile.centos7centos:7.9.2009amd64通过 SDKMAN 可安装任意 JDK。仓库提供了从 JDK 8 到 JDK 26-ea 的完整变体变体文件镜像标签java_versiondocker-compose.centos-7.18.yamlnetty:centos-7-1.88.0.482-zuludocker-compose.centos-7.111.yamlnetty:centos-7-1.1111.0.30-zuludocker-compose.centos-7.117.yamlnetty:centos-7-1.1717.0.18-zuludocker-compose.centos-7.21.yamlnetty:centos-7-2121.0.10-zuludocker-compose.centos-7.24.yamlnetty:centos-7-2424.0.2-zuludocker-compose.centos-7.25.yamlnetty:centos-7-2525.0.2-zuludocker-compose.centos-7.26.yamlnetty:centos-7-2626.ea.35-opendocker-compose.centos-7.graalvm121.yamlnetty:centos-7-1.1121.0.2-graalce例如在 CentOS 7 JDK 11 上跑完整构建与测试docker compose -f docker/docker-compose.yaml -f docker/docker-compose.centos-7.111.yaml run buildDockerfile.centos7 相比 CentOS 6 版本工具链更完整是为构建codec-native-quicquiche等重原生依赖准备的vault 软件源 SCL同样切换 vault 源并通过centos-release-scl安装devtoolset-11-gcc / devtoolset-11-gcc-c.bashrc中默认启用patchelf从 EPEL 安装patchelf并在构建时做版本校验其作用是剔除链接进原生库的ld-linux-arch.so上的DT_NEEDED使这些库能够在 musl如 Alpine下加载这是 quiche 交叉产物可移植性的关键构建工具链预装 ninja 1.7.2、Go 1.9.3、CMake 3.26.4以及从 Netty 官方 release 下载的预编译 clang 18.1.8用于编译 quiche并设置LIBCLANG_PATH与BINDGEN_EXTRA_CLANG_ARGSOpenSSL 3.6.1 源码构建用 devtoolset-11 编译并校验 SHA256no-asm no-apps安装到/opt/openssl-3.6.1并导出LD_LIBRARY_PATHRust 工具链通过 rustup 安装用于编译 quicheGraalVM 支持当 JDK 为 GraalVM 时自动安装 native-image。五、在 x86_64 主机上交叉编译 aarch64 原生模块Netty 的transport-native-epoll、transport-native-io_uring、codec-native-quic等模块包含 C/JNI/Rust 原生代码。若 CI 跑在 x86_64 上却要为 ARM64 交付产物官方提供了 aarch64 交叉编译方案docker compose -f docker/docker-compose.yaml run cross-compile-aarch64-build这条命令来源于 docker/README.md 的说明实际的服务定义位于 docker-compose.centos-7.cross.yaml。官方文档同时指出The default version of aarch64 gcc is4.9-2016.02. Update the parametergcc_versionindocker-compose.yamlto use a version you want.aarch64 gcc 的默认版本为4.9-2016.02如需其他版本可修改docker-compose.yaml中的gcc_version参数。注意这句描述与当前仓库实际配置存在出入——docker-compose.centos-7.cross.yaml 中gcc_version的当前默认值已是10.3-2021.07java_version为8.0.482-zulu。README 属于历史版本说明实际生效值请以仓库当前文件为准。该文件定义的交叉编译服务包括cross-compile-aarch64-build执行./mvnw -B -ntp -Plinux-aarch64 -pl transport-native-unix-common,transport-native-epoll,transport-native-io_uring,codec-native-quic -am clean package -DskipTeststrue ...即激活linux-aarch64profile构建 4 个原生相关模块及其依赖-am表示同时构建依赖模块cross-compile-aarch64-build-native-quic仅构建codec-native-quic及其依赖用于 musl 验证前的快速产出cross-compile-aarch64-deploy/cross-compile-aarch64-stage-snapshot/cross-compile-aarch64-stage-release对应部署与发布含 nexus staging、gpg 签名cross-compile-aarch64-shell交互式 shell 入口。支撑交叉编译的镜像 Dockerfile.cross_compile_aarch64 的关键环节从 Arm 官方下载gcc-arm-${GCC_VERSION}-x86_64-aarch64-none-linux-gnu工具链并加入PATH安装 clang 18.1.8并将BINDGEN_EXTRA_CLANG_ARGS指向 aarch64 工具链的--sysroot.../aarch64-none-linux-gnu/libc保证 Rust bindgen 生成绑定时的头文件解析正确rustup 安装 Rust 并rustup target add aarch64-unknown-linux-gnu同时把 cargo linker 配置为aarch64-none-linux-gnu-gcc写入/root/.cargo/config安装java-11-openjdk-devel并设置JAVA_HOME。六、在 x86_64 主机上交叉编译 riscv64 原生模块riscv64 交叉编译使用 Ubuntu 20.04 镜像官方命令为docker compose -f docker/docker-compose.ubuntu-20.04.yaml run cross-compile-riscv64-build注意当前仓库中实际文件名是 docker-compose.ubuntu-20.04.cross.yamlREADME 中的docker-compose.ubuntu-20.04.yaml应为历史命名执行前请按实际文件名修正即docker compose -f docker/docker-compose.ubuntu-20.04.cross.yaml run cross-compile-riscv64-build该变体定义的cross-compile-riscv64-build服务执行./mvnw -B -ntp -Plinux-riscv64 -pl transport-native-unix-common,transport-native-epoll,transport-native-io_uring -am clean package -DskipTeststrue -Drevapi.skiptrue -Dcheckstyle.skiptrue -Dforbiddenapis.skiptrue即激活linux-riscv64profile构建transport-native-unix-common、transport-native-epoll、transport-native-io_uring三个模块当前 riscv64 矩阵未包含 quic。同样提供deploy、stage-snapshot、stage-release、shell等配套服务。基础镜像 Dockerfile.cross_compile_riscv64 非常简单基于ubuntu:20.04amd64通过 apt 安装gcc-riscv64-linux-gnu交叉编译器、libaio-devio_uring 依赖、libssl-dev、openjdk-11-jdk-headless等并设置JAVA_HOME。riscv64 场景暂未引入 Rust/quiche因此不需要 clang 与 rustup。七、compose 服务矩阵构建、测试、部署与发布base 文件 是理解整套体系的总入口它基于common锚点派生了 11 个服务各自对应一个 Maven 命令。常用服务与能力如下服务命令要点适用场景build./mvnw clean install跳过 revapi/checkstyle/forbiddenapis并追加testsuite-shading集成测试常规全量构建测试build-leak在build基础上追加-Pleak开启内存泄漏检测的测试矩阵build-native-quic-pl codec-native-quic -am clean install -DskipTeststrue仅构建 quic 模块供 musl 验证快速取用build-with-oio-testsuite-Pboringssl-Dio.netty.testsuite.includeOiotrue覆盖 OIO 传输的测试套件build-boringssl-static-Pboringssl静态链接 BoringSSL 构建build-leak-boringssl-static-Pboringssl,leakBoringSSL 泄漏检测build-leak-pooled-Pboringssl,leak-Dio.netty.allocator.typepooled池化分配器下的泄漏检测build-boringssl-snapshot-pl handler -Pboringssl-snapshot clean package验证 BoringSSL 快照版本build-boringssl-static-jdk8-tests-Pboringssl,jdk8-tests,!testsuite-jpms-DtestJavaHome/usr/lib/jvm/java-1.8.0-openjdk用 JDK 8 跑测试镜像内另装 JDK 8deploy./mvnw clean deploy -DskipTeststrue跳过测试直接发布stage-snapshotnexus-staging-maven-plugin 部署到/root/local-staging快照暂存stage-releasegpg:sign central-publishing-maven-pluginpublish正式发布需 GPG 私钥shellentrypoint: /bin/bash进入容器交互排查这些服务全部复用common锚点意味着它们共享同一镜像、同一挂载、同一工作目录只是command不同——这正是分层模型带来的可维护性一个 JDK 变体文件 一个服务名 一个完整的 CI 矩阵格。发布相关服务对密钥有硬性要求例如stage-release会执行cat (echo -e ${GPG_PRIVATE_KEY}) | gpg --batch --import ./mvnw clean javadoc:jar package gpg:sign org.sonatype.central:central-publishing-maven-plugin:publish \ -DskipPublishingtrue -DskipTeststrue \ -Dgpg.passphrase${GPG_PASSPHRASE} -Dgpg.keyname${GPG_KEYNAME} ...也就是把宿主机的GPG_PRIVATE_KEY导入容器内的 gpg 密钥环再用GPG_PASSPHRASE/GPG_KEYNAME完成签名对应的三个 GPG 环境变量正是在common中透传的。八、构建缓存让矩阵加速的关键机制JDK 变体文件普遍带有cache_from/cache_to配置指向ghcr.io/netty/netty-build-cache这一容器镜像注册表缓存cache_from: - typeregistry,refghcr.io/netty/netty-build-cache:centos7 cache_to: - typeregistry,refghcr.io/netty/netty-build-cache:centos7,modemax,ignore-errortrue缓存的命名分为centos6、centos7、cross-aarch64、cross-riscv64、al2023等几路。值得注意的设计是 docker-compose.centos-7.111.yaml 中的注释说明所有centos-7.*.yaml变体共用同一个centos7缓存引用因为它们都基于同一个 Dockerfile.centos7 构建镜像中代价高昂的公共前缀devtoolset、OpenSSL、ninja/go/cmake/clang只构建一次之后各java_version变体直接复用从而避免按矩阵维度重复编译工具链。modemax表示全量缓存导出ignore-errortrue保证缓存推送失败不阻断构建。九、延伸Amazon Linux 2023 与 tcnative 联动除上述主矩阵外docker-compose.al2023.yaml 提供了基于 Dockerfile.al2023 的 Amazon Linux 2023 构建环境其特点在于使用aws-lcAWS 的加密库替代 OpenSSL环境变量统一注入LD_LIBRARY_PATH/opt/aws-lc/lib64额外挂载宿主机的netty-tcnative仓库到/netty-tcnative提供install-tcnative同时构建 openssl-dynamic 与 boringssl-static 两个 profile与update-tcnative-version自动把 tcnative 最新版本回写进 Netty 的tcnative.version属性两个服务使用独立的~/.m2-al2023目录作为容器内 Maven 仓库避免与其它矩阵的本地仓库互相污染。十、使用提示与常见问题命令必须从仓库根目录执行所有 compose 变体都通过..相对路径挂载仓库源码脱离根目录执行会导致挂载路径错误README 与当前仓库存在版本漂移docker-compose.centos-6.111.yaml、docker-compose.ubuntu-20.04.yaml等文件名在当前仓库中已不可见riscv64 实际文件为 docker-compose.ubuntu-20.04.cross.yamlaarch64 的默认gcc_version已从 README 所述4.9-2016.02更新为10.3-2021.07。以仓库实际文件为准服务名以叠加后的 compose 为准README 示例中的run test在现有文件中没有对应服务实际可用build、build-leak、shell等密钥与网络发布类服务需要宿主机配置 GPG 密钥并透传对应环境变量首次构建镜像需拉取基础镜像与 SDKMAN、Rust 等依赖建议提前准备镜像源或复用cache_from缓存seccomp 与挂载common中启用了seccomp:unconfined并将~/.ssh、~/.gnupg、~/.m2直接挂入容器便于复用本地 SSH、GPG 与 Maven 缓存但也要注意这些目录的权限与容器内 root 的一致性。通过以上命令与配置你可以在本地或 CI 中完整复现 Netty 官方的多 JDK 构建矩阵并在 x86_64 主机上直接产出 aarch64 / riscv64 的原生模块产物整个过程不需要自建任何构建基础设施。赞分享后端通信网络异步编程【免费下载链接】nettyNetty project - an event-driven asynchronous network application framework项目地址https://gitcode.com/gh_mirrors/ne/netty点击查看免费下载相关推荐PhoneInfoga交叉编译环境Docker容器中的多平台构建PhoneInfoga交叉编译环境Docker容器中的多平台构建 引言跨平台部署的痛点与解决方案 你是否曾因目标服务器架构差异反复调试PhoneInfog网络安全后端JNA Android 开发环境搭建与交叉编译构建指南JNA Android 开发环境搭建与交叉编译构建指南 导读 本文基于 JNA 仓库中的 www/AndroidDevelopmentEnvironment.m系统编程后端Parcel 原生二进制构建指南跨平台 CI 矩阵、交叉编译与本地调试实践Parcel 原生二进制构建指南跨平台 CI 矩阵、交叉编译与本地调试实践 Parcel 的核心功能并非全部由 JavaScript 实现而是依赖一组用 R构建工具前端开发工具上一篇【亲测免费】 node-DeepResearch深度探索查询直到找到答案下一篇【亲测免费】 Agent.exe让AI接管你的电脑创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考