简介

本文档介绍了如何为 MinIO 制作 hotfix（热修复）版本的二进制文件和容器镜像。文章的重点是如何将补丁回溯（backport）到指定分支，并最终构建出相应的二进制文件和容器镜像。

前置要求（更前一步）

  • 需要熟悉 MinIO 代码库及其各个组件。

  • 需要了解 AWS S3 API 的行为及其一些边界情况。

回溯补丁的前提条件

符合以下任一条件的修复，才允许进行回溯（backport）操作：

  • 修复不能是新功能，比如下面这个就不符合要求：
  1. commit faf013ec84051b92ae0f420a658b8d35bb7bb000
  2. Author: Klaus Post <klauspost@gmail.com>
  3. Date:   Thu Nov 18 12:15:22 2021 -0800
  5.     Improve performance on multiple versions (#13573)
  • 修复必须是一个在客户环境中被验证复现的问题，比如：
  1. commit 886262e58af77ebc7c836ef587c08544e9a0c271
  2. Author: Harshavardhana <harsha@minio.io>
  3. Date:   Wed Nov 17 15:49:12 2021 -0800
  5.     heal legacy objects when versioning is enabled after upgrade (#13671)
  • 如果某个安全问题影响到了客户，安全修复必须被回溯。这类情况会通过 SUBNET 机制通知受影响客户，这是强制要求：
  1. commit 99bf4d0c429f04dbd013ba98840d07b759ae1702 (tag: RELEASE.2019-06-15T23-07-18Z)
  2. Author: Harshavardhana <harsha@minio.io>
  3. Date:   Sat Jun 15 11:27:17 2019 -0700
  5.     [security] Match ${aws:username} exactly instead of prefix match (#7791)
  7.     This PR fixes a security issue where an IAM user based
  8.     on his policy is granted more privileges than restricted
  9.     by the users IAM policy.
  11.     This is due to an issue of prefix based Matcher() function
  12.     which was incorrectly matching prefix based on resource
  13.     prefixes instead of exact match.
  • 对于一些新的修复建议，开发者必须先确保其提交到主分支（master），通过审核并合并后，才进行回溯。

创建 hotfix 分支

MinIO 客户可以对他们选择作为标准版本的任意发行版启用 LTS（长期支持）。生产环境通常变化较小，需要持续维护。hotfix 分支就是为这类维护目的而存在的，让客户可以在不剧烈更改部署的前提下，持续运行生产集群。

回溯补丁操作流程

建议开发者先 clone MinIO 源码，并 checkout 到客户当前使用的 MinIO release tag。

  1. λ git checkout RELEASE.2021-04-22T15-44-28Z

创建一个分支，并将其推送到 upstream

这里的 upstream 指的是 git@github.com\:minio/minio.git

  1. λ git branch -m RELEASE.2021-04-22T15-44-28Z.hotfix
  2. λ git push -u upstream RELEASE.2021-04-22T15-44-28Z.hotfix

然后从 master 分支中挑选要回溯的 commit-id，例如：

  1. commit 4f3317effea38c203c358af9cb5ce3c0e4173976
  2. Author: Klaus Post <klauspost@gmail.com>
  3. Date:   Mon Nov 8 08:41:27 2021 -0800
  5.     Close stream on panic (#13605)
  7.     Always close streamHTTPResponse on panic on main thread to avoid
  8.     write/flush after response handler has returned.

应用这个补丁：

  1. λ git cherry-pick 4f3317effea38c203c358af9cb5ce3c0e4173976

自包含（self-contained）的 patch（补丁）通常能顺利应用到 hotfix 分支上。但如果补丁涉及的代码变动较多，可能会出现冲突。简单的冲突可以手动解决；如果冲突复杂，或涉及开发者不熟悉的代码部分，请联系 MinIOHQ 的 Slack 频道中的 #hack 以获得更多指导。避免匆忙处理，虽然可以为 hotfix 分支添加一些小修复和日志信息，但不推荐将其作为常规操作。

补丁成功应用后，开发者需要运行测试以验证补丁的正确性。可以执行以下测试命令：

单元测试：

  1. λ make test

验证不同类型的 MinIO 部署是否正常运行：

  1. λ make verify

验证故障磁盘修复和替换是否正常：

  1. λ make verify-healing

此时，回溯的补丁就可以通过 pull request 的方式提交到对应分支。推荐使用 pull request 的方式是为了确保 mint 测试可以运行，并且可以获得代码审核，从而避免潜在回归问题。

构建 hotfix 二进制文件和容器镜像

为了给二进制版本添加 hotfix 标签，并嵌入相关 commit-id，可以使用以下构建辅助命令：

构建 hotfix 二进制文件并上传至 https://dl.min.io

  1. λ CRED_DIR=/media/builder/minio make hotfix-push

构建 hotfix 容器镜像并推送至 docker.io/minio/minio

  1. λ CRED_DIR=/media/builder/minio make docker-hotfix-push

构建 hotfix 容器镜像并推送至 registry.min.dev//minio

  1. λ REPO="registry.min.dev/<customer>" CRED_DIR=/media/builder/minio make docker-hotfix-push

构建完成后，MinIO 会通过 release server 安全地将相应的二进制文件上传至：

👉 https://dl.minio.io/server/minio/hotfixes/archive/