amazon-s3 - 当 AEM 配置为使用 S3 数据存储时，它会加快蓝绿部署吗？

Question

背景

我们知道可以设置一个 devops 管道，通过使用 crx2oak 将内容从旧环境迁移到新环境，通过蓝/绿方法将更新部署到 AEM。为什么超出了这个问题的范围。

这种方法的问题在于，随着 JCR 中内容量的增长，内容复制操作可能会花费大量时间。其他减轻这种情况的想法表示赞赏。

我们还知道 AEM 可以有一个 S3 数据存储，它将二进制内容卸载到 S3 存储桶中，在蓝/绿部署期间不会重新构建，如下所示：

https://helpx.adobe.com/experience-manager/6-3/sites/deploying/using/storage-elements-in-aem-6.html#OverviewofStorageinAEM6

Adobe 的文档中不清楚是否可以跨 AEM 实例（即蓝/绿实例）共享同一个 S3 存储桶。也许只是我的google fu失败了......

问题）

当一个新的 AEM 实例被配置为使用 S3 数据存储时，该数据存储中已经包含旧实例中的内容，当使用 crx2oak 迁移内容时，新实例是否能够访问现有内容？

是否有任何文章/博客描述了这种方法可能节省的时间？

是的，我可以做一个实验，并且将来可能会这样做来回答我自己的问题。我正在寻找已经这样做过的人的信息？我是一名工程师，所以如果其他人这样做了，我不会重新发明轮子。

标签： amazon-s3aemdevopsslingjackrabbit-oak

Answer 1

您当然可以在实例之间共享同一个 S3 存储桶 - 事实上，这通常与来自 author->publisher(s) 的无二进制复制一起使用，并且是一种经过验证的真实配置。

甚至可以在完全不同的环境（例如 DEV/STAGE 或 BLUE/GREEN 在您的情况下）之间共享同一个存储桶。要注意的主要“问题”是关于 DataStore 垃圾收集 (DSGC)，因为很可能会有一些仅由共享存储桶的一些实例引用的 blob，因此在清除未使用的 blob 时，这需要考虑到。

虽然这都是设计的一部分，并且有一个专门为此目的设计的标志，它告诉 DSGC 只执行 GC 的第一阶段（“标记”阶段），并跳过第二个“扫描”阶段，直到所有实例已标记他们希望保留/丢弃的 blob。一旦所有实例都完成了，那么可以运行扫描阶段以清除任何使用存储桶的实例不需要的 blob。

有关更详细的说明，请参阅 Oak 文档： https ://jackrabbit.apache.org/oak/docs/plugins/blobstore.html#Shared_DataStore_Blob_Garbage_Collection_Since_1.2.0

我发现它有助于理解几乎所有的数据存储实现都是根据它们的校验和存储 blob，因此添加两次上传的同一个文件只会在数据存储中存储一个副本，并且会有两个段存储引用同一 blob 的记录。同样，共享同一个存储桶的多个 AEM 实例将能够找到给定的 blob，而不管哪个实例首先将它放在那里。

FileDataStore您可以通过找到一个 blob 并'ing 它轻松地观察到这sha256一点 - 例如（此示例在 OS X 上，Linux/Windows 上的校验和命令会略有不同）：

$ shasum -a256 crx-quickstart/repository/datastore/0c/9e/40/0c9e405fc8d0f0405930cd0044611cfbf014938a1837ae0cfaa266d7732d1002

0c9e405fc8d0f0405930cd0044611cfbf014938a1837ae0cfaa266d7732d1002  crx-quickstart/repository/datastore/0c/9e/40/0c9e405fc8d0f0405930cd0044611cfbf014938a1837ae0cfaa266d7732d1002

在那里您可以看到 a) 文件名是校验和，b) 它使用该校验和中的前 3 对字符嵌套，因此您可以通过仅知道哈希值以及存储相同的二进制文件来定位文件，即使如果名称或 JCR 元数据不同，则引用的 blob 将是磁盘上的相同文字文件。

从内存 S3 数据存储使用前缀而不是目录嵌套，因为这样性能更好，但原理是一样的。

最后，需要考虑的几点是：

1) S3 存储相对便宜（实际上是无限的），因此有一个论点是，除非您真的想省钱，否则没有必要执行常规 DSGC。

2) 如果您确实运行 DSGC，则需要考虑这将如何与您用于 AEM 实例的任何备份策略一起工作。例如，如果您在运行 DSGC 后不久回滚段存储，您可能必须恢复其中一些已清除的 blob。您可以使用版本控制和/或生命周期规则来帮助解决此问题，但它可能会显着增加恢复过程的复杂性和时间。

如果您选择简单地跳过 DSGC 并将 blob 无限期留在那里，最好确保 AEM 使用的访问密钥或 IAM 角色没有DeleteObject存储桶的权限，以确保流氓 GC 进程不能删除任何东西。

希望这可以帮助。

编辑 在我忘记实际回答您的问题的所有内容中 - 是的，在大多数情况下它会节省一些克隆时间。您仍然需要同步段存储（显然），并且有多种方法可以做到这一点。crx2oak肯定是一个 - 您将在文档中看到使用 S3 的特定选项，您可以在其中提供配置文件（基本上是.config与 Felix/OSGi 一起使用的序列化文件）。

您还可以使用类似rsync的方法简单地复制 TAR 文件（至少目标 AEM 已停止。Oak 通常是原子的，因此理论上可以从源进行热复制，但 YMMV）。

最后，您显然可以使用 Mongo 并以这种方式对分段存储进行集群，但所有常见的成本/复杂性/性能问题都适用）。

蓝/绿字体即将出现的另一个有趣的发展是CompositeNodeStore- 2017 年的 adaptTo() 会议上有一个很好的讨论，讨论了这个：

https://adapt.to/2017/en/schedule/zero-downtime-deployments-for-the-sling-based-apps-using-docker.html