网关弃用对 Azure 客户的影响

正如我们在 4 月份指出的那样，MinIO 将在几周后弃用网关功能。正如 Harsha 当时所写，网关已经达到了它的目的，不再可行。

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

网关的整个概念始于 Azure。Microsoft 来找我们，询问我们是否会为 S3/Blob API 创建二元性。这对 MinIO 来说是一个相当沉重的提升，但我们认为这将有利于社区并在此过程中增加 MinIO 的采用。随着时间的推移，无法保证此模型的一致性和完整性。太多关键功能，例如复制和不可变性/勒索软件保护，取决于与对象的内联翻译冲突的版本控制。加密、压缩和其他几个重要功能也被禁用。S3/Blob API 双重性方法在基本对象操作之外停止了。因此，决定放弃网关模型。

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

以下是如何进行这种转变：

通过滚动您自己的 Kubernetes 或 VM 实例或选择市场选项在 Azure 上启动 MinIO ：

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

复制数据后，您可以使用 对其进行验证mc diff。

将应用程序指向新端点。

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

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

虽然我们认识到对于某些企业而言，网关的弃用不是最佳选择，但我们很高兴我们提供了足够的过渡时间（2020 年 7 月）来适应社区。

正如 Harsha 的帖子中所述，商业客户在过渡时将得到定制构建的支持。如果您对过渡有任何疑问，请随时在通用 Slack 频道上联系我们。没有 SLA 和有限的故障排除，但我们在这里回答一般问题。