Azure 用户的网关弃用影响

正如我们在四月份提到的，MinIO 将在几周内弃用网关功能。正如 Harsha 当时写道，网关已经完成了它的使命，不再可行。

虽然所有网关用户都需要做出一些决定，但有一些 Azure 网关用户（针对云），这篇文章描述了这些用户需要做出的决定以及如何思考这些决定。

网关的整个概念始于 Azure。微软找到我们，询问我们是否可以为 S3/Blob API 创建对等功能。对于 MinIO 来说，这需要付出相当大的努力，但我们认为这将有利于社区并推动 MinIO 的采用。随着时间的推移，在这种模式下保证一致性和完整性变得不可能。太多关键功能，例如复制和不可变性/勒索软件保护，都依赖于版本控制，而版本控制与对象的内联转换冲突。加密、压缩和许多其他重要功能也被禁用。S3/Blob API 对等功能方法在基本对象操作之外停止了。因此，我们决定放弃网关模型。

在服务器模型中，所有对象都写入 MinIO，S3 API 是唯一支持的方法。依赖 Azure Blob API 的应用程序需要重新编写以使用 S3 API，以便成为云中立。

以下是进行转换的方法。

通过在 Azure 上自行滚动 Kubernetes 或 VM 实例，或者选择市场选项，在 Azure 上启动 MinIO。

设置好 MinIO 实例后，您可以使用 `minio-client` 一次镜像一个桶，例如 `mc mirror -w <source alias>/<bucket> <target alias>/<bucket>`，或者通过复制整个命名空间来简化整个过程，例如 `mc mirror -w <source alias> <target alias>`。

数据复制完成后，您可以使用 `mc diff <source alias> <target alias>` 进行验证。

将应用程序指向新的端点。

作为回报，用户将获得 MinIO 二进制文件的全部功能，包括内联擦除编码、位腐烂保护、对象锁定、主动-主动多站点复制、加密、监控、生命周期管理等等。您可以继续使用 Azure 基础设施元素，只需将 Blob 替换为 MinIO 作为对象存储。您甚至可以使用 MinIO 中的 过渡功能 将对象分层到 Blob 存储，例如，对于超出您确定阈值的旧数据。

如果您的应用程序或您使用的服务对 Azure Blob API 有硬依赖，那么 MinIO 网关将不再是可行的选择。

我们认识到，对于某些企业来说，网关的弃用并不理想，但我们相信我们已经提供了足够的过渡时间（2020 年 7 月）来满足社区的需求。

正如 Harsha 的文章中提到的，商业客户将在过渡期间获得自定义构建的支持。如果您在过渡过程中有任何问题，请随时联系我们 加入公共 Slack 频道。 没有 SLA，故障排除有限，但我们在这里回答一般性问题。