Los fundamentos del desarrollo de código son similares en AEM as a Cloud Service en comparación con las soluciones AEM On Premise y Managed Services. Los desarrolladores escriben el código y lo prueban localmente, para a continuación insertarlo en entornos de AEM as a Cloud Service remotos. Se requiere Cloud Manager, que era una herramienta de entrega de contenido opcional para Managed Services. Este es ahora el único mecanismo para implementar código en AEM entornos as a Cloud Service de desarrollo, fase y producción. Para una validación y depuración rápidas de las funciones antes de implementar los entornos antes mencionados, el código se puede sincronizar de un entorno local a un Entorno de desarrollo rápido.
La actualización de la versión de AEM siempre es un evento de implementación independiente de la inserción de código personalizado. Visto de otra manera, las versiones de código personalizado deben probarse con la versión de AEM que está en producción, ya que esto es lo que se implementará en primer lugar. Las actualizaciones de la versión de AEM que se produzcan después, que serán frecuentes y se aplicarán automáticamente. Están pensadas para ser compatibles con el código de cliente ya implementado.
El resto de este documento describirá cómo los desarrolladores deben adaptar sus prácticas para que funcionen tanto con las actualizaciones de versiones de AEM as a Cloud Service como con las actualizaciones de clientes.
Para las soluciones de AEM anteriores, la versión de AEM más reciente cambiaba con poca frecuencia (aproximadamente anualmente con Service Packs trimestrales), y los clientes actualizaban las instancias de producción a la última versión de inicio rápido a su propio tiempo, haciendo referencia al Jar de la API. Sin embargo, las aplicaciones de AEM as a Cloud Service se actualizan automáticamente a la última versión de AEM con mayor frecuencia, por lo que el código personalizado para versiones internas debe crearse con la última versión.
Al igual que para las versiones de AEM existentes que no se basan en la nube, se admitirá un desarrollo local sin conexión basado en un inicio rápido específico y se espera que sea la herramienta preferida para la depuración en la mayoría de los casos.
Existen diferencias operativas sutiles entre el comportamiento de la aplicación en un equipo local y el de Adobe Cloud. Estas diferencias arquitectónicas deben respetarse durante el desarrollo local y podrían dar lugar a un comportamiento diferente al implementarse en la infraestructura en la nube. Debido a estas diferencias, es importante realizar pruebas exhaustivas en entornos de desarrollo y ensayo antes de implementar un nuevo código personalizado en producción.
Para desarrollar un código personalizado para una versión interna, debe descargarse e instalarse la versión correspondiente del SDK de AEM as a Cloud Service. Para obtener información adicional sobre el uso de las herramientas de Dispatcher de AEM as a Cloud Service, consulte esta página.
El siguiente vídeo proporciona información general de alto nivel sobre cómo implementar los códigos en AEM as a Cloud Service:
Los clientes implementan código personalizado en entornos de nube a través de Cloud Manager. Cabe señalar que Cloud Manager transforma los paquetes de contenido ensamblados localmente en un artefacto que se ajusta al Modelo de funciones de Sling, que es el modo en que se describe una aplicación AEM as a Cloud Service al ejecutarse en un entorno de nube. Como resultado, al consultar los paquetes en Administrador de paquetes en entornos de Cloud, el nombre incluye “cp2fm” y los paquetes transformados tienen todos los metadatos eliminados. No se puede interactuar con ellos, lo que significa que no se pueden descargar, replicar ni abrir. La documentación detallada sobre el convertidor se puede encontrar aquí.
Los paquetes de contenido escritos para aplicaciones AEM as a Cloud Service deben tener una clara separación entre contenido inmutable y mutable, y Cloud Manager solo instalará el contenido mutable, lo que también genera el siguiente mensaje:
Generated content-package <PACKAGE_ID> located in file <PATH> is of MIXED type
El resto de esta sección describirá la composición y las implicaciones de los paquetes inmutables y mutables.
Todo el contenido y el código que persiste en el repositorio inmutable deben registrarse en Git e implementarse mediante Cloud Manager. En otras palabras, a diferencia de las soluciones AEM actuales, el código nunca se implementa directamente en una instancia de AEM en ejecución. Esto garantiza que el código que se ejecuta para una versión determinada en cualquier entorno de Cloud sea idéntico, lo que elimina el riesgo de variación no intencional del código en la producción. Por ejemplo, la configuración de OSGI debe confirmarse con el control de código fuente en lugar de administrarse durante la ejecución a través del administrador de configuración de la consola web de AEM.
Como los cambios de aplicación debido al patrón de implementación Blue-Green se activan mediante un conmutador, no pueden depender de los cambios en el repositorio mutable con la excepción de los usuarios de servicio, sus ACL, los tipos de nodos y los cambios de definición de índice.
Para los clientes con bases de código existentes, es fundamental pasar por el ejercicio de reestructuración de repositorios descrito en la documentación de AEM para garantizar que el contenido que anteriormente estaba bajo /etc se mueva a la ubicación correcta.
Se aplican algunas restricciones adicionales a estos paquetes de código, por ejemplo instalar enlaces no son compatibles.
Como se ha mencionado anteriormente, la configuración OSGI debe confirmarse en el control de código fuente en lugar de a través de la consola web. Las técnicas para hacerlo incluyen las siguientes:
Obtenga más información sobre la configuración OSGI en Configuración de OSGi para AEM as a Cloud Service.
En algunos casos, puede resultar útil preparar los cambios de contenido en el control de código fuente para que Cloud Manager pueda implementarlos cada vez que se actualiza un entorno. Por ejemplo, puede que sea razonable armar ciertas estructuras de carpetas raíz o alinear los cambios en plantillas editables para habilitar las políticas en aquellas para los componentes que la implementación de la aplicación haya actualizado.
Existen dos estrategias para describir el contenido que Cloud Manager implementará en el repositorio mutable, los paquetes de contenido mutable y las instrucciones de RepoInit.
El contenido, como las jerarquías de rutas de carpetas, los usuarios de servicios y los controles de acceso (ACL), se suelen confirmar en un proyecto de AEM basado en arquetipos Maven. Las técnicas incluyen la exportación desde AEM o la escritura directamente como XML. Durante el proceso de compilación e implementación, Cloud Manager empaqueta el paquete de contenido mutable resultante. El contenido mutable se instala en tres momentos diferentes durante la fase de implementación de la canalización:
Antes del inicio de la nueva versión de la aplicación:
Durante el inicio de la nueva versión de la aplicación, pero antes del cambio:
Después de cambiar a una nueva versión de la aplicación:
/conf
) (agregar, modificar, eliminar)Es posible limitar la instalación de contenido mutable a la creación o publicación incrustando paquetes en una carpeta install.author o install.publish en /apps
. La reestructuración para reflejar esta separación se llevó a cabo en AEM 6.5 y se puede encontrar información detallada sobre la reestructuración del proyecto recomendado en la documentación de AEM 6.5.
Los paquetes de contenido se implementan en todos los tipos de entorno (des., fase, prod.). No es posible limitar la implementación a un entorno específico. Esta limitación se aplica para garantizar la opción de una ejecución de prueba de ejecución automatizada. El contenido específico de un entorno requiere una instalación manual mediante el Administrador de paquetes.
Además, no hay ningún mecanismo para revertir los cambios del paquete de contenido mutable después de haberlos aplicado. Si los clientes detectan un problema, pueden optar por solucionarlo en su próxima versión de código o, como último recurso, restaurar todo el sistema a un punto en el tiempo antes de la implementación.
Cualquier paquete de terceros incluido debe validarse como compatible con AEM as a Cloud Service; de lo contrario, su inclusión dará como resultado un error de implementación.
Como se ha mencionado anteriormente, los clientes con bases de código existentes deben ajustarse al ejercicio de reestructuración del repositorio que requieren los cambios de repositorios de la versión 6.5 descritos en la documentación de AEM 6.5.
En los siguientes casos, es preferible utilizar el método de codificación manual para la creación explícita de instrucciones de contenido repoinit
en configuraciones de fábrica OSGI:
Crear/eliminar/deshabilitar usuarios de servicios
Crear/eliminar grupos
Crear/eliminar usuarios
Agregar ACL
La definición de ACL requiere que las estructuras de nodos ya estén presentes. Por lo tanto, puede que sea necesario crear instrucciones de ruta anteriores.
Agregar ruta (por ejemplo, para estructuras de carpetas raíz)
Agregar CND (definiciones de tipos de nodos)
Es preferible un informe para estos casos de uso de modificación de contenido compatibles debido a las ventajas siguientes:
Cuando Cloud Manager implementa la aplicación, ejecuta estas instrucciones, independientemente de la instalación de cualquier paquete de contenido.
Para crear instrucciones de RepoInit, siga este procedimiento:
org.apache.sling.jcr.repoinit.RepositoryInitializer
en una carpeta de configuración del proyecto. Utilice un nombre descriptivo para la configuración como org.apache.sling.jcr.repoinit.RepositoryInitializer~initstructure./content
antes de /content/myfolder
y de /content/myfolder/mysubfolder
. Para que las ACL se establezcan en estructuras de bajo nivel, se recomienda configurarlas en un nivel superior y trabajar con una restricción rep:glob
. Por ejemplo, (allow jcr:read on /apps restriction(rep:glob,/msm/wcm/rolloutconfigs))
.Para las ACL definidas para nodos debajo de /apps
o /libs
la ejecución de RepoInit se iniciará en un repositorio en blanco. Los paquetes se instalan después de repoinit, por lo que las instrucciones no pueden depender de nada de lo definido en los paquetes, sino que se deben definir las condiciones previas como las estructuras principales que hay debajo.
En el caso de las ACL, la creación de estructuras profundas puede ser engorrosa, por lo que es más razonable definir una ACL en un nivel superior y restringir dónde se supone que debe actuar mediante una restricción rep:glob.
Puede encontrar más información sobre RepoInit en la Documentación de Sling
Hay casos de uso en los que un paquete de contenido debe instalarse con definición. Por ejemplo, importar contenido específico de la producción a ensayo para depurar un problema de producción. Para estos escenarios, el Administrador de paquetes se puede utilizar en entornos de AEM as a Cloud Service.
Dado que el Administrador de paquetes es un concepto de tiempo de ejecución, no es posible instalar contenido o código en el repositorio inmutable, por lo que estos paquetes de contenido solo deben consistir en contenido mutable (principalmente /content
o /conf
). Si el paquete de contenido incluye contenido mixto (tanto mutable como inmutable), solo se instalará el contenido mutable.
La interfaz de usuario del Administrador de paquetes puede devolver el mensaje de error Indefinido si un paquete tarda más de 10 minutos en instalarse.
Esto no se debe a un error en la instalación, sino a un tiempo de espera que Cloud Service tiene para todas las solicitudes.
No vuelva a intentar realizar la instalación si aparece un error de este tipo. La instalación continúa correctamente en el fondo. Si reinicia la instalación, podrían producirse conflictos debido a varios procesos de importación simultáneos.
Cualquier paquete de contenido instalado mediante Cloud Manager (mutable e inmutable) aparecerá en estado inmovilizado en la interfaz de usuario del Administrador de paquetes de AEM. Estos paquetes no se pueden volver a instalar, volver a crear ni descargar, y aparecerán en la lista con un sufijo cp2fm, que indica que la instalación fue administrada por Cloud Manager.
Es habitual que los clientes incluyan paquetes generados previamente de fuentes de terceros, como proveedores de software, tales como los socios de traducción de Adobe. La recomendación es alojar estos paquetes en un repositorio remoto y hacer referencia a ellos en pom.xml
. Esto es posible para repositorios públicos y también para repositorios privados con protección por contraseña, tal como se describe en repositorios maven protegidos por contraseña.
Si no es posible almacenar el paquete en un repositorio remoto, los clientes pueden ubicarlo en un repositorio Maven local, basado en el sistema de archivos, que se asigna a SCM como parte del proyecto y al que hace referencia todo lo que dependa de él. El repositorio se declararía en el elemento pom del proyecto, como se ilustra a continuación:
<repository>
<id>project.local</id>
<name>project</name>
<url>file:${maven.multiModuleProjectDirectory}/repository</url>
</repository>
Cualquier paquete de terceros incluido debe cumplir a las directrices de empaquetado y codificación de AEM as a Cloud Service descritas en este artículo; de lo contrario, su inclusión dará como resultado un error de implementación.
El siguiente fragmento POM.xml
de Maven muestra cómo los paquetes de terceros pueden integrarse en el paquete “Container” del proyecto, normalmente denominado 'all', a través de la configuración del complemento filevault-package-maven-plugin de Maven.
...
<plugin>
<groupId>org.apache.jackrabbit</groupId>
<artifactId>filevault-package-maven-plugin</artifactId>
<extensions>true</extensions>
<configuration>
...
<embeddeds>
...
<!-- Include any other extra packages -->
<embedded>
<groupId>com.vendor.x</groupId>
<artifactId>vendor.plug-in.all</artifactId>
<type>zip</type>
<target>/apps/vendor-packages/container/install</target>
</embedded>
<embeddeds>
</configuration>
</plugin>
...
Al igual que las actualizaciones de AEM, las versiones de los clientes se implementan mediante una estrategia de implementación dinámica para eliminar el tiempo de inactividad del clúster de creación en las circunstancias adecuadas. La secuencia general de eventos es la que se describe a continuación, donde Blue es la versión antigua del código de cliente y Green es la nueva versión. Tanto Blue como Green ejecutan la misma versión de código AEM.
Los índices nuevos o modificados provocarán un paso adicional de indexación o reindexación antes de que la nueva versión (verde) pueda entrar en el tráfico. Los detalles sobre la administración de índices en AEM as a Cloud Service se pueden encontrar en este artículo. Puede ver si el trabajo de indexación se ha completado en la página de generación de Cloud Manager y recibirá una notificación cuando la nueva versión esté lista para admitir tráfico.
El tiempo necesario para una implementación móvil variará según el tamaño del índice, ya que la versión verde no puede aceptar tráfico hasta que se haya generado el nuevo índice.
En este momento, AEM as a Cloud Service no funciona con herramientas de administración de índices como la herramienta ACS Commons Ensure Oak Index.
El mecanismo de publicación es compatible hacia atrás con las API de Java de replicación de AEM.
Para desarrollar y probar con la replicación con el inicio rápido de AEM listo para la nube, las funcionalidades de replicación clásicas deben usarse con la configuración de Autor/Publicación. En el caso de que el punto de entrada de la UI de AEM Autor se haya eliminado para la nube, los usuarios irían a http://localhost:4502/etc/replication
para la configuración.
Como se ha detallado anteriormente, la estrategia de implementación gradual de AEM as a Cloud Service implica que tanto las versiones anteriores como las nuevas pueden estar funcionando al mismo tiempo. Por lo tanto, tenga cuidado con los cambios de código que no sean compatibles con la versión anterior de AEM que aún está en funcionamiento.
Además, la versión antigua debe probarse para verificar la compatibilidad con cualquier estructura de contenido mutable nueva aplicada por la nueva versión en caso de revertir, ya que el contenido mutable no se elimina.
Cambiar los usuarios del servicio o las ACL necesarias para acceder al contenido o al código podría provocar errores en las versiones AEM anteriores, lo que daría como resultado acceso a ese contenido o código con usuarios de servicios obsoletos. Para solucionar este comportamiento, se recomienda hacer cambios distribuidos en al menos dos versiones, y la primera versión actúa como puente antes de limpiarla en la versión siguiente.
Si se realizan cambios en los índices, es importante que la versión Blue siga utilizando sus índices hasta que finalice, mientras que la versión Green utiliza su propio conjunto modificado de índices. El desarrollador debe seguir las técnicas de administración de índices descritas en este artículo.
Si se informa o se detecta un error después de la implementación, es posible que se requiera una reversión a la versión azul. Sería aconsejable garantizar que el código azul sea compatible con cualquier estructura nueva creada por la versión verde, ya que las nuevas estructuras (cualquier contenido mutable) no se revertirán. Si el código antiguo no es compatible, será necesario aplicar correcciones en las versiones posteriores del cliente.
Entornos de desarrollo rápido (o RDEs para abreviar) permiten a los desarrolladores implementar y revisar rápidamente los cambios, minimizando la cantidad de tiempo necesario para probar las funciones que ya están probadas para funcionar en un entorno de desarrollo local.
A diferencia de los entornos de desarrollo normales, que implementan código mediante la canalización de Cloud Manager, los desarrolladores utilizan herramientas de línea de comandos para sincronizar código desde un entorno de desarrollo local con RDE. Una vez que los cambios se hayan probado correctamente en un RDE, deben implementarse en un entorno de desarrollo de nube normal a través de la canalización de Cloud Manager, que colocará el código a través de las puertas de calidad adecuadas.
En las soluciones de AEM existentes, los clientes tienen la opción de ejecutar instancias con modos de ejecución arbitrarios y aplicar la configuración OSGI o instalar paquetes OSGI a esas instancias específicas. Los modos de ejecución definidos normalmente incluyen la variable service (autor y publicación) y el entorno (rde, dev, stage, prod).
AEM as a Cloud Service, por otro lado, tiene más opiniones sobre qué modos de ejecución están disponibles y cómo se pueden asignar a ellos los paquetes OSGI y la configuración OSGI:
<service>.<environment_type>
, mientras que estos se deben utilizar en este orden concreto (por ejemplo, author.dev
o publish.prod
). Se debe hacer referencia a los tókenes OSGI directamente desde el código en lugar de usar el método getRunModes
que ya no incluirá el environment_type
en tiempo de ejecución. Para obtener más información, consulte Configuración de OSGi para AEM as a Cloud Service.install.author
o install.publish
.AEM as a Cloud Service no permite utilizar modos de ejecución para instalar contenido para entornos o servicios específicos. Si un entorno de desarrollo debe estar preconfigurado con datos o HTML que no se encuentre en los entornos de ensayo o producción, se puede utilizar el administrador de paquetes.
Las configuraciones de modo de ejecución admitidas son las siguientes:
Se utiliza la configuración OSGI que tiene los modos de ejecución más coincidentes.
Al desarrollar localmente, un parámetro de inicio de modo de ejecución, -r
, se utiliza para especificar la configuración OSGI del modo de ejecución.
$ java -jar aem-sdk-quickstart-xxxx.x.xxx.xxxx-xxxx.jar -r publish,dev
Las configuraciones de la tarea de mantenimiento mantenerse en el control de origen, ya que la pantalla Herramientas > Operaciones ya no estará disponible en los entornos de Cloud. Esto tiene la ventaja de garantizar que los cambios se mantengan intencionalmente en lugar de aplicarse de forma reactiva y, tal vez, olvidarse. Consulte el artículo Tarea de mantenimiento para obtener más información.