部署到 AEM as a Cloud Service

最近更新： 2025年2月5日

创建对象：

  • 管理员

简介

与 AEM 内部部署和 Managed Services 解决方案相比，AEM as a Cloud Service 中的代码开发基础是相似的。开发人员编写代码并在本地进行测试，然后将代码推送到 AEM as a Cloud Service 上的远程环境。需要使用 Cloud Manager，它是 Managed Services 的一个可选内容交付工具。现在，该交付工具是用于将代码部署到 AEM as a Cloud Service 开发、暂存和生产环境的唯一机制。要在部署上述环境之前进行快速功能验证和调试，可以将代码从本地环境同步到快速开发环境。

AEM 版本的更新始终是独立于推送自定义代码的部署事件。从另一个角度来看，自定义代码版本应针对生产中的 AEM 版本进行测试，因为这是它部署到其上的版本。之后进行的AEM版本更新（经常进行并自动应用）旨在与已部署的客户代码向后兼容。

本文档的其余部分描述开发人员应如何调整他们的实践，以便他们同时使用 AEM as a Cloud Service 的版本更新和客户更新。

客户发行版本

针对正确的 AEM 版本进行编码

对于以前的 AEM 解决方案，最新的 AEM 版本很少发生更改（约每年使用季度 Service Pack 更新一次），客户将根据自己的时间将生产实例更新到最新的快速入门，并参考 API Jar。但是，AEM as a Cloud Service 上的应用程序会更频繁地自动更新到最新版本的 AEM，因此，应针对最新的 AEM 版本构建内部版本的自定义代码。

与现有的非云 AEM 版本一样，支持基于特定快速入门的本地离线开发，并有望在大多数情况下成为调试的首选工具。

NOTE
应用程序在本地计算机上的行为方式与在 Adobe Cloud 上的行为方式之间存在细小的操作差异。在本地开发过程中必须考虑这些架构差异，并且这些差异会导致在云基础架构上部署时发生不同的行为。由于存在这些差异，在生产中推出新的自定义代码之前，在开发和暂存环境中执行详尽的测试非常重要。

若要为内部版本开发自定义代码，应下载并安装相关版本的 AEM as a Cloud Service SDK。有关使用AEM as a Cloud Service Dispatcher工具的其他信息，请参阅云中的Dispatcher。

以下视频高度概述了如何将代码部署到 AEM as a Cloud Service：

video poster

通过 Cloud Manager 和包管理器部署内容包

通过 Cloud Manager 部署

客户通过 Cloud Manager 将自定义代码部署到云环境。Cloud Manager 将本地汇编的内容包转换为符合 Sling 功能模型的构件，这就是在云环境中运行时描述 AEM as a Cloud Service 上的应用程序的方式。因此，在云环境中的包管理器中查看包时，名称会包含“cp2fm”，并且转换后的包中的所有元数据已被删除。它们无法进行交互，这意味着无法下载、复制或打开它们。有关转换器的详细文档，请参阅🔗
GitHub上的sling-org-apache-sling-feature-cpconverter 。

为 AEM as a Cloud Service 上的应用程序编写的内容包必须明确区分不可变内容和可变内容，并且 Cloud Manager 仅会安装可变内容，并输出如下消息：

Generated content-package <PACKAGE_ID> located in file <PATH> is of MIXED type

此部分的其余内容描述的是不可变包和可变包的构成和含义。

不可变内容包

必须阿静存储在不可变存储库中的所有内容和代码签入 Git，并通过 Cloud Manager 部署它们。换句话说，与当前的 AEM 解决方案不同，代码绝不会直接部署到正在运行的 AEM 实例。该工作流程程可确保在任意云环境中为给定版本运行的代码是相同的，从而消除生产中发生意外代码变化的风险。例如，OSGI 配置应提交给源代码管理，而不是在运行时通过 AEM Web 控制台的配置管理器进行管理。

由于因部署模式产生的应用程序更改由开关启用，因此，它们不能依赖于可变存储库中的更改，但服务用户、其 ACL、节点类型和索引定义更改除外。

对于拥有现有代码库的客户，请务必完成 AEM 文档中描述的存储库重构实践，以确保将以前位于 /etc 下的内容移动到正确的位置。

这些代码包还受到一些其他限制，例如，安装挂接不受支持。

OSGI 配置

如上所述，OSGI 配置应提交给源代码管理，而不是通过 Web 控制台管理。用于执行此操作的方法包括：

  • 使用 AEM Web 控制台的配置管理器对开发人员的本地 AEM 环境进行必要的更改，然后将结果导出到本地文件系统上的 AEM 项目
  • 在本地文件系统上的 AEM 项目中手动创建 OSGI 配置，然后为属性名称引用 AEM 控制台的配置管理器。

参阅为 AEM as a Cloud Service 配置 OSGi，了解有关 OSGI 配置的更多信息。

可变内容

在某些情况下，在源代码管理中准备内容更改可能会很有用，这样它就能在更新环境时由 Cloud Manager 进行部署。例如，可能需要对某些根文件夹结构进行播种。或者，排列可编辑模板中的更改，以启用由应用程序部署更新的策略组件。

可通过两种策略来描述由 Cloud Manager 部署到可变存储库的内容、可变内容包和 repoinit 语句。

可变内容包

文件夹路径层次结构、服务用户和访问控制 (ACL) 等内容通常将提交到基于 Maven 原型的 AEM 项目。方法包括从 AEM 导出或以 XML 形式直接写入。在构建和部署过程中，Cloud Manager 将打包生成的可变内容包。将在管道的部署阶段的三个不同时间安装可变内容：

在启动新版本的应用程序之前：

  • 索引定义（添加、修改、删除）

在启动新版本的应用程序期间，但在切换之前：

  • 服务用户（添加）
  • 服务用户 ACL（添加）
  • 节点类型（添加）

切换到新版本的应用程序之后：

  • 可通过 Jackrabbit 库定义的所有其他内容。例如：

    • 文件夹（添加、修改、删除）
    • 可编辑模板（添加、修改、删除）
    • 上下文感知配置（/conf 下的任何内容）（添加、修改、删除）
    • 脚本（包可以在包安装的安装过程的各个阶段触发安装挂钩。有关安装挂钩的信息，请参阅 Jackrabbit filevault 文档。AEM CS 目前使用 Filevault 版本 3.4.0，它仅允许管理员用户、系统用户和管理员组的成员安装挂钩）。

可以通过在 /apps 下的 install.author 或 install.publish 文件夹中嵌入包，来仅允许创作或发布可变内容安装。反映此分隔的重构已在AEM 6.5中完成，有关建议的项目重构的详细信息可在AEM 6.5文档中找到。

NOTE
内容包将部署到所有环境类型（开发、暂存、生产）。无法将部署限于特定环境。施加此限制以确保能够选择自动执行的测试运行。特定于环境的内容需要通过包管理器手动安装。

此外，没有用于在应用可变内容包更改后回滚这些更改的机制。如果客户检测到问题，他们可以选择在下一个代码版本中修复它，或者在万不得已的情况下，将整个系统恢复到部署前的某个时间点。

必须确认任何包含的第三方包与 AEM as a Cloud Service 兼容，否则包含此包会导致部署失败。

如上所述，具有现有代码库的客户应遵循AEM 6.5文档中所述的6.5存储库更改所需的存储库重构练习。

Repoinit

对于以下情况，最好是采用在 OSGI 工厂配置中手动为显式内容创建 repoinit 语句编码的方法：

  • 创建/删除/禁用服务用户

  • 创建/删除组

  • 创建/删除用户

  • 添加 ACL

    NOTE
    ACL 的定义要求节点结构已存在。因此，前面的创建路径语句可能是必需的。

  • 添加路径（例如，根文件夹结构的路径）

  • 添加 CND（节点类型定义）

由于 Repoinit 的以下好处，对于这些受支持的内容修改用例，Repoinit 更可取：

  • Repoinit 在启动时创建资源，因此，逻辑可以将这些资源的存在视为理所当然。在可变内容包方法中，资源是在启动后创建的，因此依赖这些资源的应用程序代码可能会失败。
  • Repoinit 是一个相对安全的指令集，因为您可以明确控制要执行的操作。此外，唯一支持的操作是累加的，但几种与安全相关的情况除外，这些情况允许删除用户、服务用户和组。相比之下，在可变内容包方法中删除某些内容是明确的；在定义过滤器时，过滤器涵盖的任何内容都会被删除。不过，应谨慎行事，因为对于任何内容，在一些场景中，新内容的存在都会更改应用程序的行为。
  • Repoinit 执行快速和原子操作。相比之下，可变内容包在性能方面可能在很大程度上取决于过滤器涵盖的结构。即使您更新单个节点，也可能创建大型树的快照。
  • 可以在运行时在本地开发环境中验证 repoinit 语句，因为在注册 OSGi 配置时会运行这些语句。
  • Repoinit 语句是原子和显式的，如果状态已匹配，则会跳过它们。

当 Cloud Manager 部署应用程序时，它会独立于任何内容包的安装来执行这些语句。

要创建 repoinit 语句，请遵循以下过程：

  1. 在项目的配置文件夹中，为工厂 PID org.apache.sling.jcr.repoinit.RepositoryInitializer 添加 OSGi 配置。为配置使用描述性名称，例如 org.apache.sling.jcr.repoinit.RepositoryInitializer~initstructure。
  2. 将 repoinit 语句添加到配置的脚本属性中。Sling 文档中记录了语法和选项。应该在其子文件夹之前显式创建父文件夹。例如，在 /content/myfolder 和 /content/myfolder/mysubfolder 之前显式创建 /content。对于在低层次结构上设置的 ACL，建议在更高层次设置它们并使用 rep:glob 限制。例如：(allow jcr:read on /apps restriction(rep:glob,/msm/wcm/rolloutconfigs))。
  3. 在运行时在本地开发环境上进行验证。
WARNING
对于为 /apps 或 /libs repoinit 下的节点定义的 ACL， 执行会在空白存储库上开始。这些包是在 repoinit 之后安装的，因此，语句无法依赖包中定义的任何内容，但必须定义先决条件，例如下面的父结构。
TIP
对于 ACL，创建深层结构可能很麻烦。因此，更合理的做法是在更高的级别上定义 ACL，并通过 rep:glob 限制的方式限制其应采取的行动。

有关 repoinit 的更多详细信息，请参阅 Sling 文档