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迁移内容，新实例将能够访问现有内容吗？

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

是的，我可以做一个实验，将来可能会回答我自己的问题。我正在寻找已经这样做的人的信息？我是工程师，因此如果有人这样做，就不会重新发明轮子。

Answer 1

您当然可以在实例之间共享相同的S3存储桶-实际上，它通常与author-> publisher的无二进制复制一起使用，这是一种经过尝试的真实配置。

甚至有可能在完全不同的环境之间共享同一存储桶(例如DEV / STAGE或您的情况下为BLUE / GREEN)。要了解的主要“陷阱”是关于DataStore垃圾收集(DSGC)的，因为很有可能会有仅由共享该存储桶的某些实例引用的Blob，因此在清除未使用的Blob时，需要考虑在内。

不过，这都是设计的全部内容，并且有一个专门为此目的设计的标志，该标志告诉DSGC仅执行GC的第一阶段(“标记”阶段)，并跳过第二“扫掠”阶段，直到所有实例为止标记了他们希望保留/丢弃的斑点。完成所有实例后，便可以运行扫描阶段来清除任何使用该存储桶的实例不需要的斑点。

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

我发现这有助于理解几乎所有数据存储区实现均已完成，从而根据其校验和来存储blob，因此，两次上载的同一文件添加将仅在数据存储区中存储一个副本，并且将有两个段存储区记录引用相同的Blob。以相同的方式，共享同一个存储桶的多个AEM实例将能够找到给定的blob，而不管首先放在哪个实例中。

您可以通过找到一个blob并为其添加FileDataStore来观察sha256轻松地看到这一点-例如(此示例在OS X上，Linux / Windows上的checksum命令将略有不同):

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

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

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

从内存S3数据存储区开始，它使用前缀而不是目录嵌套，因为这种性能更好，但是原理是相同的。

最后，需要考虑以下两点:

1)S3存储相对便宜(并且实际上是无限的)，因此有一个论点是，除非您确实想花几分钱，否则不必执行常规DSGC。

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

如果您选择简单地跳过DSGC并无限期地保留斑点，则最好确保AEM正在使用的访问密钥或IAM角色没有存储区的 DeleteObject权限，只是要确保恶意GC进程可以删除任何内容。

希望这可以帮助。

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

您也可以使用 rsync之类的内容来简单地复制TAR文件(至少在停止目标AEM的同时。Oak通常是原子性的，因此从源上进行热复制在理论上可以起作用，但YMMV可以)。

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

蓝色/绿色类型的另一个有趣的发展是 CompositeNodeStore-2017年的AdaptTo() session 上有一篇很好的演讲谈到了这一点:

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