企业官网建设流程全解析

• 集群管理
• 任务调度
• 后端

本文基于 Apache Mesos 官方发布博客，深度解析 0.18.1 与 0.18.2 两个补丁版本的发布背景、核心变更与升级路径。这两个版本在 Mesos 演进史中具有特殊意义：0.18.1 首次引入 Maven 构建 Java artifacts、为 URI 协议新增extract标志，而 0.18.2 则紧急修复了 0.18.1 引入的 fetcher 可执行位（executable bit）缺陷。读者通过本文可以掌握 Mesos 0.18 时代 Java 构建体系的切换方式、fetcher 解压/可执行控制机制的底层实现，以及从 0.18.x 无缝升级到运行中集群的具体步骤。

发布背景：一次补丁版本的连环迭代

2014 年 5 月，Apache Mesos 团队在短时间内连续发布了两个补丁版本 0.18.1 与 0.18.2。这次快速迭代的直接原因是：0.18.1 自身引入了一个 bug，促使团队随即发布了 0.18.2 进行修复。官方博客明确建议：如果你正在使用 0.18.1，强烈建议升级到 0.18.2。

两个版本的定位均为 bug fix 版本，并未引入破坏性 API 变更，因此 0.18.0/0.18.1 用户可以平滑升级。其变更内容集中在四个领域：Java 构建体系、Java artifacts 的依赖遮蔽（shading）、URI 协议字段扩充，以及 master / containerizer / JNI / fetcher 的缺陷修复。

0.18.1 的核心变更

Maven 接管 Mesos Java 文件的编译与打包

从 0.18.1 开始，Mesos 的 Java 文件改为使用 Apache Maven 进行编译和打包。这一变更意味着 Maven 成为 Mesos 的构建依赖——只有安装 Maven，才能构建带 Java 支持（Java bindings、JNI 层）的 Mesos。

仓库中的构建配置印证了这一机制：在 src/java/CMakeLists.txt 中，Mesos JAR 的构建命令为：

COMMAND mvn -B -f mesos.pom clean package

即由 CMake 驱动 Maven 执行clean package，产出target/mesos-<版本>.jar。而 src/java/MESOS-MAVEN-README 记录了完整的发布流程：本地安装可用mvn install -f mesos.pom，推送 Apache 暂存仓库可用mvn deploy -f mesos.pom。这也解释了 0.18.1 之前用户并不需要 Maven 的原因——Java 部分由其他方式构建。

Java artifacts 遮蔽（shade）protobuf 依赖

0.18.1 的另一个重要变化是：Mesos Java artifacts 开始对 protobuf 依赖执行 shading（遮蔽），使框架可以独立声明自己的 protobuf 依赖版本，不再受 Mesos 自带 protobuf 版本的约束。

shading 的实质是把依赖类重命名后打入产物，避免与使用方自身的同名类冲突。在 src/java/mesos.pom.in 中可以看到具体实现：通过maven-shade-plugin（版本 2.2）将com.google.protobuf:protobuf-java加入 artifactSet，并将包名com.google.protobuf重定位（relocate）为org.apache.mesos.protobuf，同时排除**/*.java源码以减小产物体积。产物为带 classifiershaded-protobuf的mesos-shaded-protobuf-<版本>.jar。

该配置文件同时显式声明了 shading 的用途，即让 protobuf 依赖"off the classpath of the main jar"（脱离主 jar 的 classpath），从而使依赖 Mesos Java API 的框架能够自由选择自己的 protobuf 版本，避免版本冲突。这正是当时生态中大量框架的痛点：Mesos 自身基于较老的 protobuf 版本，而框架可能希望使用更新的 protobuf。

URI 协议新增 extract 标志：控制 fetcher 是否解压

0.18.1 为 URI protocol buffer 新增了extract标志，使框架能够控制 fetcher 是否对某个 artifact 执行解压。在此之前，fetcher 对带归档扩展名的文件一律解压，无法按需关闭。

在 include/mesos/mesos.proto 中，CommandInfo::URI的完整结构如下（extract即本次新增字段）：

message CommandInfo { message URI { required string value = 1; optional bool executable = 2; optional bool extract = 3 [default = true]; optional bool cache = 4; optional string output_file = 5; } ... }

字段语义（与 docs/fetcher.md 一致）：

• value：URI 字符串；
• executable：为true时，fetch 结束后对沙箱内的文件执行chmod赋予全部用户执行权限；若为true，extract字段被忽略且不生效；
• extract：默认true，带已识别归档扩展名的文件会被解压到沙箱目录；executable为true时此字段无效；
• cache：为true时使用 fetcher cache；
• output_file：自定义本地副本文件名，可含相对路径子目录。

从源码实现看，extract标志在 fetcher 的两条路径中均被落实：src/launcher/fetcher.cpp 的fetchBypassingCache（绕过缓存直取）与 src/launcher/fetcher.cpp 的fetchFromCache（从缓存取）都会在下载/复制完成后检查uri.extract()，对归档调用extract()解压进沙箱。若文件看起来并非归档，则回退为直接复制并打印 WARNING 日志。

被识别为归档的扩展名（见 src/launcher/fetcher.cpp 与 docs/fetcher.md）包括：.tar、.tgz、.tar.gz、.tbz2、.tar.bz2、.txz、.tar.xz、.zip，以及通过外部gunzip程序处理的.gz（因为 libarchive 无法处理裸 gzip 文件）。需要注意的是：绕过缓存时，归档和解压结果会同时出现在沙箱中；而从缓存解压时，沙箱中只出现解压结果。

extract标志的典型使用场景：框架不希望 fetcher 擅自解压（例如下载的是带.tar扩展名但内容并非归档的普通文件，或希望保留原始归档），可显式设置extract = false。

其他 bug 修复

0.18.1 还修复了 Mesos master、containerizer 以及 JNI 代码中的多个缺陷。这些修复属于常规 bug fix，官方发布记录（JIRA Release Notes，问题编号 MESOS-1313 相关链接见后文）列出了详细清单，此处不逐一展开。

0.18.2：修复 mesos-fetcher 未应用可执行位的问题

0.18.2 是紧随 0.18.1 发布的紧急修复版本，其唯一核心修复是：mesos-fetcher 没有正确应用可执行位（executable bit），对应 JIRA 问题 MESOS-1313。原博客中"executer bit"为笔误，实际指 POSIX 文件权限中的可执行位。

源码层面的修复验证

当前仓库中 fetcher 的可执行位处理逻辑位于 src/launcher/fetcher.cpp 的chmodExecutable函数：当uri.executable()为真时，对下载到沙箱的文件执行

os::chmod(filePath, S_IRWXU | S_IRGRP | S_IXGRP | S_IROTH | S_IXOTH)

即赋予属主完整读写执行权限、属组读写+执行、其他用户读+执行——这正是"对每个用户都可执行"的语义（与 docs/fetcher.md 描述一致）。该函数在fetchBypassingCache与fetchFromCache两条路径中均被调用，确保直取与缓存取两种方式下可执行位都被正确应用。由于执行位设置发生在 fetch 流程末尾且仅作用于沙箱内的副本，缓存文件本身不受影响。

测试用例验证

仓库测试 src/tests/fetcher_tests.cpp 用一组参数化测试固化了"可执行位/解压"四象限行为：

• NoExtractNotExecutable（src/tests/fetcher_tests.cpp#L713-L749）：executable=false, extract=false，断言沙箱文件的 owner/group/others 均无可执行位；
• NoExtractExecutable（src/tests/fetcher_tests.cpp#L754-L791）：executable=true, extract=false，断言三类用户均可执行（permissions->owner.x、group.x、others.x均为真）；
• 另有ExtractTar、ExtractGzipFile、UNZIP_ExtractFile等用例覆盖extract=true时的解压行为。

这些测试直接回应了 MESOS-1313：0.18.1 中 fetcher 未能把可执行位应用到 fetch 结果，0.18.2 修复了该回归，并由测试保证不再复发。

升级指南

官方给出的升级路径分两种情况：

从 0.18.0 或 0.18.1 升级

可以无缝（seamlessly）升级到运行中的集群，无需停机重建。唯一需要提前准备的变更：Maven 现在是构建依赖，要构建带 Java 支持的 Mesos，必须预先安装 Maven（参考上文 Maven 构建配置）。二进制分发与滚动重启即可完成升级。

从早于 0.18.0 的版本升级

需参考完整的 升级文档。仓库中保留了该阶段的升级要点，例如 docs/upgrades.md#L1354-L1368 记录了 0.17.0 → 0.18.x 的注意项：使用 Linux cgroups 隔离的 agent 升级后需要重启系统；--isolation标志发生变化，process已废弃，应改用posix/cpu,posix/mem；cgroups 用户需从单挂载点改为每控制器独立挂载点（如/sys/fs/cgroup/memory/、/sys/fs/cgroup/cpu/），建议将 tmpfs 挂载到/sys/fs/cgroup后由 agent 自动挂载所需控制器。此外 docs/upgrades.md#L1339-L1351 还给出了 0.18.x → 0.19.x 的升级顺序（先重启 master，再重启 agent，随后升级 scheduler 与 executor），可作为规划跨版本升级的参考。

参与社区与获取发布

官方鼓励用户试用该版本，并通过用户邮件列表、Twitter（@ApacheMesos）以及社区提供的邮件列表与 IRC 渠道反馈问题。发布包可从 Apache Mesos 官方下载页获取。

小结

0.18.1 与 0.18.2 是 Mesos 在 Java 生态与资源获取能力上的关键补丁版本：Maven 正式接管 Java 构建并引入 protobuf shading，让框架可以自由选择 protobuf 版本；extract标志将解压决策权下放给框架，配合既有的executable、cache、output_file字段，使 fetcher 行为完全可配置；0.18.2 则快速修复了可执行位回归，保障了"下载即运行"语义的正确性。对于运行 0.18.x 的集群，升级是低成本且推荐的操作；对于更老的版本，则应严格参照 docs/upgrades.md 规划升级。

• 集群管理
• 任务调度
• 后端