Buscar contenido e indexar

Cambios en AEM as a Cloud Service

Con AEM as a Cloud Service, el Adobe se está alejando de un modelo AEM centrado en instancias a una vista basada en servicios con contenedores de AEM n-x, impulsada por canalizaciones de CI/CD en Cloud Manager. En lugar de configurar y mantener los índices en instancias de AEM único, la configuración de Índice debe especificarse antes de una implementación. Los cambios de configuración en la producción claramente están rompiendo las políticas CI/CD. Lo mismo ocurre con los cambios de índice, ya que pueden afectar a la estabilidad y al rendimiento del sistema si no se especifica, se prueban y se reindexan antes de llevarlos a la producción.

A continuación se muestra una lista de los principales cambios en comparación con AEM 6.5 y versiones anteriores:

  1. Los usuarios ya no tendrán acceso al Administrador de índices de una sola instancia de AEM para depurar, configurar o mantener la indexación. Solo se utiliza para implementaciones locales y locales.

  2. Los usuarios no cambiarán los índices en una única instancia de AEM ni tendrán que preocuparse por las comprobaciones de coherencia o la reindexación.

  3. En general, los cambios de índice se inician antes de ir a producción para no eludir las puertas de enlace de calidad en las canalizaciones CI/CD de Cloud Manager y no tener impacto en los KPI empresariales en producción.

  4. Todas las métricas relacionadas, incluido el rendimiento de búsqueda en producción, estarán disponibles para los clientes durante la ejecución para proporcionar una vista holística de los temas de Búsqueda e Indexación.

  5. Los clientes podrán configurar alertas según sus necesidades.

  6. Las EEM supervisan el estado del sistema las 24 horas del día, los 7 días de la semana y adoptarán las medidas necesarias y lo antes posible.

  7. La configuración del índice se cambia mediante implementaciones. Los cambios en la definición del índice se configuran como otros cambios en el contenido.

  8. A un alto nivel sobre AEM as a Cloud Service, con la introducción del Modelo de implementación Blue-Green existen dos conjuntos de índices: un conjunto para la versión antigua (azul) y otro conjunto para la nueva versión (verde).

  9. Los clientes pueden ver si el trabajo de indexación se ha completado en la página de creación de Cloud Manager y recibirán una notificación cuando la nueva versión esté lista para recibir tráfico.

  10. Restricciones:

  • Actualmente, la administración de índices en AEM as a Cloud Service solo se admite para índices de tipo lucene.
  • Solo se admiten analizadores estándar (es decir, aquellos que se envían con el producto). Los analizadores personalizados no son compatibles.
  • Internamente, se pueden configurar y utilizar otros índices para las consultas. Por ejemplo, las consultas que se escriben en relación con la variable damAssetLucene índice, en Skyline, podría ser ejecutado contra una versión Elasticsearch de este índice. Esta diferencia no suele ser visible para la aplicación y el usuario, aunque algunas herramientas como la variable explain reportará un índice diferente. Para ver las diferencias entre los índices de Lucene y los índices elásticos, consulte la documentación de Elastic en Apache Jackrabbit Oak. Los clientes no necesitan ni pueden configurar los índices de Elasticsearch directamente.

Usos

La definición de índices puede incluir los tres casos de uso siguientes:

  1. Adición de una nueva definición de índice de cliente.
  2. Actualización de una definición de índice existente. Esto significa añadir una nueva versión de una definición de índice existente.
  3. Eliminación de un índice existente redundante u obsoleto.

Para los puntos 1 y 2 anteriores, debe crear una nueva definición de índice como parte del código personalizado en la programación de versiones correspondiente de Cloud Manager. Para obtener más información, consulte la Implementación en AEM documentación as a Cloud Service.

Nombres de índice

Una definición de índice puede ser:

  1. Un índice predeterminado. Un ejemplo es /oak:index/cqPageLucene-2.
  2. Personalización de un índice predeterminado. El cliente define estas personalizaciones. Un ejemplo es /oak:index/cqPageLucene-2-custom-1.
  3. Un índice totalmente personalizado. Un ejemplo es /oak:index/acme.product-1-custom-2. Para evitar conflictos de nombres, es necesario que los índices totalmente personalizados tengan un prefijo, por ejemplo acme.

Tenga en cuenta que tanto la personalización de un índice predeterminado como los índices completamente personalizados deben contener -custom-. Solo los índices totalmente personalizados deben comenzar con un prefijo .

Preparación de la nueva definición de índice

NOTA

Si se personaliza un índice predeterminado, por ejemplo damAssetLucene-6, copie la última definición de índice lista para usar de un entorno de Cloud Service uso del administrador de paquetes CRX DE (/crx/packmgr/). A continuación, cambie el nombre de la configuración, por ejemplo a damAssetLucene-6-custom-1y añada sus personalizaciones en la parte superior. Esto garantiza que las configuraciones necesarias no se eliminen de forma involuntaria. Por ejemplo, la variable tika nodo bajo /oak:index/damAssetLucene-6/tika es necesario en el índice personalizado del servicio en la nube. No existe en el SDK de Cloud.

Debe preparar un nuevo paquete de definición de índice que contenga la definición de índice real, siguiendo este patrón de nomenclatura:

<indexName>[-<productVersion>]-custom-<customVersion>

que luego necesita entrar ui.apps/src/main/content/jcr_root. Todas las definiciones de índice personalizadas y personalizadas deben almacenarse en /oak:index.

El filtro del paquete debe configurarse de modo que los índices existentes (predeterminados) se mantengan. En el archivo ui.apps/src/main/content/META-INF/vault/filter.xml, cada índice personalizado (o personalizado) debe enumerarse, por ejemplo, como <filter root="/oak:index/damAssetLucene-6-custom-1"/>. Si la versión del índice se cambia posteriormente, es necesario ajustar el filtro.

El paquete del ejemplo anterior se crea como com.adobe.granite:new-index-content:zip:1.0.0-SNAPSHOT.

NOTA

Cualquier paquete de contenido que contenga definiciones de índice debe tener la siguiente propiedad establecida en el archivo de propiedades del paquete de contenido, ubicado en /META-INF/vault/properties.xml:

noIntermediateSaves=true

Implementación de definiciones de índice

Las definiciones de índice se marcan como personalizadas y con versiones:

  • La definición del índice (por ejemplo /oak:index/ntBaseLucene-custom-1)

Para implementar un índice personalizado o personalizado, la definición del índice (/oak:index/definitionname) debe entregarse mediante ui.apps mediante Git y el proceso de implementación de Cloud Manager. En el filtro FileVault, por ejemplo, ui.apps/src/main/content/META-INF/vault/filter.xml, enumere cada índice personalizado y personalizado individualmente, por ejemplo, <filter root="/oak:index/damAssetLucene-7-custom-1"/>. La definición de índice personalizada/personalizada se almacenará en el archivo ui.apps/src/main/content/jcr_root/_oak_index/damAssetLucene-7-custom-1/.content.xml, como se indica a continuación:

<?xml version="1.0" encoding="UTF-8"?>
<jcr:root xmlns:oak="http://jackrabbit.apache.org/oak/ns/1.0" xmlns:dam="http://www.day.com/dam/1.0" xmlns:jcr="http://www.jcp.org/jcr/1.0" xmlns:nt="http://www.jcp.org/jcr/nt/1.0" xmlns:rep="internal"
        jcr:primaryType="oak:QueryIndexDefinition"
        async="[async,nrt]"
        compatVersion="{Long}2"
        ...
        </indexRules>
        <tika jcr:primaryType="nt:unstructured">
            <config.xml jcr:primaryType="nt:file"/>
        </tika>
</jcr:root>

El ejemplo anterior contiene una configuración para Apache Tika. El archivo de configuración de Tika se almacenaría en ui.apps/src/main/content/jcr_root/_oak_index/damAssetLucene-7-custom-1/tika/config.xml.

Configuración del proyecto

Dependiendo de la versión del plugin de paquete Jackrabbit Filevault Maven que se use, se requiere algo más de configuración en el proyecto. Cuando se utiliza la versión del complemento Jackrabbit Filevault Maven Package Plugin 1.1.6 o posterior, el archivo pom.xml debe contener la siguiente sección en la configuración del complemento para filevault-package-maven-plugin, en configuration/validatorsSettings (justo antes de jackrabbit-nodetypes):

<jackrabbit-packagetype>
    <options>
        <immutableRootNodeNames>apps,libs,oak:index</immutableRootNodeNames>
    </options>
</jackrabbit-packagetype>

Además, en este caso, la variable vault-validation La versión debe actualizarse a una versión más reciente:

<dependency>
    <groupId>org.apache.jackrabbit.vault</groupId>
    <artifactId>vault-validation</artifactId>
    <version>3.5.6</version>
</dependency>

A continuación, en ui.apps.structure/pom.xml y ui.apps/pom.xml, la configuración del filevault-package-maven-plugin necesita tener allowIndexDefinitions así como noIntermediateSaves activada. La opción noIntermediateSaves garantiza que las configuraciones de índice se añadan automáticamente.

<groupId>org.apache.jackrabbit</groupId>
    <artifactId>filevault-package-maven-plugin</artifactId>
    <configuration>
        <allowIndexDefinitions>true</allowIndexDefinitions>
        <properties>
            <cloudManagerTarget>none</cloudManagerTarget>
            <noIntermediateSaves>true</noIntermediateSaves>
        </properties>
    ...

En ui.apps.structure/pom.xml, el filters para este complemento debe contener una raíz de filtro como se indica a continuación:

<filter><root>/oak:index</root></filter>

Una vez añadida la nueva definición de índice, la nueva aplicación debe implementarse mediante Cloud Manager. Tras la implementación se inician dos trabajos, responsables de agregar (y combinar si es necesario) las definiciones de índice a MongoDB y Azure Segment Store para la creación y publicación, respectivamente. Los repositorios subyacentes se están reindexando con las nuevas definiciones de índice, antes de que tenga lugar el conmutador Blue-Green.

SUGERENCIA

Para obtener más información sobre la estructura de paquetes necesaria para AEM as a Cloud Service, consulte el documento AEM estructura del proyecto.

Administración de índices mediante implementaciones Blue-Green

¿Qué es la administración de índices?

La administración de índices consiste en agregar, quitar y cambiar índices. Cambio de la variable definición de un índice es rápido, pero la aplicación del cambio (a menudo llamado "creación de un índice" o, para los índices existentes, "reindexación") requiere tiempo. No es instantánea: el repositorio debe analizarse para indizar los datos.

Qué es la implementación Blue-Green

La implementación Blue-Green puede reducir el tiempo de inactividad. También permite realizar upgrades sin downtime y proporciona reversiones rápidas. La versión antigua de la aplicación (azul) se ejecuta al mismo tiempo que la nueva versión de la aplicación (verde).

Áreas de solo lectura y lectura-escritura

Algunas áreas del repositorio (partes de solo lectura del repositorio) pueden ser diferentes en la versión antigua (azul) y en la nueva (verde) versión de la aplicación. Las áreas de solo lectura del repositorio suelen ser "/app" y "/libs". En el siguiente ejemplo, se utiliza cursiva para marcar áreas de solo lectura, mientras que negrita se utiliza para áreas de lectura-escritura.

  • /
  • /apps (solo lectura)
  • /content
  • /libs (solo lectura)
  • /oak:index
  • /oak:index/acme.
  • /jcr:system
  • /system
  • /var

Las áreas de lectura y escritura del repositorio se comparten entre todas las versiones de la aplicación, mientras que para cada versión de la aplicación, hay un conjunto específico de /apps y /libs.

Administración de índices sin implementación Blue-Green

Durante el desarrollo o al utilizar instalaciones locales, los índices se pueden añadir, eliminar o cambiar durante la ejecución. Los índices se utilizan en cuanto están disponibles. Si se supone que un índice no debe utilizarse en la versión antigua de la aplicación todavía, el índice se crea normalmente durante un tiempo de inactividad programado. Lo mismo ocurre cuando se elimina un índice o se cambia un índice existente. Al eliminar un índice, deja de estar disponible en cuanto se elimina.

Administración De Índices Con Implementación Azul-Verde

Con las implementaciones en azul y verde, no hay tiempo de inactividad. Durante una actualización, durante algún tiempo, tanto la versión antigua (por ejemplo, la versión 1) de la aplicación, como la nueva versión (versión 2), se ejecutan simultáneamente en el mismo repositorio. Si la versión 1 requiere que haya un determinado índice disponible, este índice no debe eliminarse en la versión 2: el índice debe eliminarse más adelante, por ejemplo en la versión 3, momento en el que se garantiza que la versión 1 de la aplicación ya no se está ejecutando. Además, las aplicaciones deben escribirse de tal manera que la versión 1 funcione bien, incluso si la versión 2 se está ejecutando, y si hay índices de la versión 2 disponibles.

Una vez completada la actualización a la nueva versión, el sistema puede recoger los índices antiguos. Es posible que los índices antiguos se mantengan durante algún tiempo para acelerar las devoluciones (si se necesita una reversión).

La tabla siguiente muestra cinco definiciones de índice: index cqPageLucene se utiliza en ambas versiones mientras que index damAssetLucene-custom-1 solo se usa en la versión 2.

NOTA

<indexName>-custom-<customerVersionNumber> es necesario para que AEM as a Cloud Service marque esto como reemplazo de un índice existente.

Índice Índice predeterminado Uso en la versión 1 Uso en la versión 2
/oak:index/damAssetLucene No
/oak:index/damAssetLucene-custom-1 Sí (personalizado) No
/oak:index/acme.product-custom-1 No No
/oak:index/acme.product-custom-2 No No
/oak:index/cqPageLucene

El número de versión se incrementa cada vez que se cambia el índice. Para evitar que los nombres de índice personalizados entren en conflicto con los nombres de índice del propio producto, los índices personalizados, así como los cambios en los índices externos, deben terminar con -custom-<number>.

Cambios en los índices predeterminados

Una vez que el Adobe cambia un índice predeterminado como "damAssetLucene" o "cqPageLucene", un nuevo índice denominado damAssetLucene-2 o cqPageLucene-2 o, si el índice ya se ha personalizado, la definición del índice personalizado se combina con los cambios en el índice predeterminado, como se muestra a continuación. La combinación de cambios se produce automáticamente. Esto significa que no es necesario que haga nada si cambia un índice predeterminado. Sin embargo, es posible volver a personalizar el índice más adelante.

Índice Índice predeterminado Uso en la versión 2 Uso en la versión 3
/oak:index/damAssetLucene-custom-1 Sí (personalizado) No
/oak:index/damAssetLucene-2-custom-1 Sí (se fusiona automáticamente desde damAssetLucene-custom-1 y damAssetLucene-2) No
/oak:index/cqPageLucene No
/oak:index/cqPageLucene-2 No

Limitaciones actuales

Actualmente, la administración de índices solo es compatible con índices del tipo lucene. Internamente, se pueden configurar otros índices y utilizar para consultas, por ejemplo índices elásticos.

Adición de un índice

Para agregar un índice totalmente personalizado llamado /oak:index/acme.product-custom-1 para utilizarse en una nueva versión de la aplicación y posterior, el índice debe configurarse de la siguiente manera:

acme.product-1-custom-1

Esto funciona anteponiendo un identificador personalizado al nombre del índice, seguido de un punto (.). El identificador debe tener entre 2 y 5 caracteres de longitud.

Como se ha indicado anteriormente, esto garantiza que el índice solo sea utilizado por la nueva versión de la aplicación.

Cambio de un índice

Cuando se cambia un índice existente, es necesario agregar un nuevo índice con la definición de índice modificada. Por ejemplo, considere el índice existente /oak:index/acme.product-custom-1 cambia. El índice antiguo se almacena en /oak:index/acme.product-custom-1y el nuevo índice se almacena en /oak:index/acme.product-custom-2.

La versión antigua de la aplicación utiliza la siguiente configuración:

/oak:index/acme.product-custom-1

La nueva versión de la aplicación utiliza la siguiente configuración (modificada):

/oak:index/acme.product-custom-2

NOTA

Es posible que las definiciones de índice de AEM as a Cloud Service no coincidan completamente con las definiciones de índice de una instancia de desarrollo local. La instancia de desarrollo no tiene una configuración de Tika, mientras que AEM instancias as a Cloud Service sí la tienen. Si personaliza un índice con una configuración de Tika, mantenga la configuración de Tika.

Deshacer un cambio

A veces, es necesario revertir un cambio en una definición de índice. Las razones podrían ser que se hizo un cambio por error o que ya no es necesario. Por ejemplo, la definición de índice damAssetLucene-8-custom-3 se creó por error y ya está implementado. Por ello, es posible que desee volver a la definición de índice anterior damAssetLucene-8-custom-2. Para ello, debe añadir un nuevo índice denominado damAssetLucene-8-custom-4 que contiene la definición del índice anterior, damAssetLucene-8-custom-2.

Eliminación de un índice

Lo siguiente solo se aplica a los índices personalizados. Los índices de productos no se pueden eliminar porque los AEM los utilizan.

Si se va a eliminar un índice en una versión posterior de la aplicación, se puede definir un índice vacío (un índice vacío que no se utiliza nunca y que no contiene datos), con un nombre nuevo. Para este ejemplo, puede asignarle un nombre /oak:index/acme.product-custom-3. Esto reemplaza al índice /oak:index/acme.product-custom-2. Una vez /oak:index/acme.product-custom-2 es eliminado por el sistema, el índice vacío /oak:index/acme.product-custom-3 a continuación, también se puede eliminar. Un ejemplo de este índice vacío es:

<acme.product-custom-3
        jcr:primaryType="oak:QueryIndexDefinition"
        async="async"
        compatVersion="2"
        includedPaths="/dummy"
        queryPaths="/dummy"
        type="lucene">
        <indexRules jcr:primaryType="nt:unstructured">
            <rep:root jcr:primaryType="nt:unstructured">
                <properties jcr:primaryType="nt:unstructured">
                    <dummy
                        jcr:primaryType="nt:unstructured"
                        name="dummy"
                        propertyIndex="{Boolean}true"/>
                </properties>
            </rep:root>
        </indexRules>
    </acme.product-custom-3>

Si ya no es necesario tener una personalización de un índice predeterminado, debe copiar la definición de índice predeterminada. Por ejemplo, si ya ha implementado damAssetLucene-8-custom-3, pero ya no necesita las personalizaciones y desea volver al valor predeterminado damAssetLucene-8 índice, debe añadir un índice damAssetLucene-8-custom-4 que contiene la definición de índice de damAssetLucene-8.

Optimizaciones de índice

Apache Jackrabbit Oak permite configuraciones de índice flexibles para gestionar de forma eficiente las consultas de búsqueda. Los índices son especialmente importantes para repositorios más grandes. Asegúrese de que todas las consultas estén respaldadas por un índice adecuado. Las consultas sin un índice adecuado pueden leer miles de nodos, que luego se registran como advertencia. Estas consultas deben identificarse analizando los archivos de registro para poder optimizar las definiciones de índice. Consulte esta página para obtener más información.

Índice de texto completo de Lucene en AEM as a Cloud Service

Índice de texto completo /oak:index/lucene-2 puede llegar a ser muy grande porque indexa todos los nodos del repositorio de AEM de forma predeterminada. Siguiendo los planes de Adobe para retirar este índice, ya no se utilizará en el lado del producto en AEM as a Cloud Service y no se debería necesitar ejecutar el código de cliente. Para AEM entornos as a Cloud Service con índices Lucene comunes, Adobe está trabajando con los clientes individualmente para un enfoque coordinado para compensar este índice y para utilizar índices mejores y optimizados. Los clientes no necesitan ninguna acción sin previo aviso del Adobe. AEM clientes as a Cloud Service serán informados por Adobe cuando haya necesidad de actuar con respecto a esta optimización. Si este índice es necesario para consultas personalizadas, como solución temporal, se debe crear una copia de este índice con un nombre diferente, por ejemplo: /oak:index/acme.lucene-1-custom-1, tal como se describe here.
Esta optimización no se aplica de forma predeterminada a otros entornos de AEM alojados in situ o administrados por Adobe Managed Services.

Optimizaciones de consultas

La variable Rendimiento de la consulta permite observar consultas JCR populares y lentas. Además, puede analizar consultas y mostrar información diversa sobre, especialmente si se está utilizando un índice para esta consulta o no.

A diferencia de en AEM local, AEM as a Cloud Service no muestra la variable Rendimiento de la consulta en la interfaz de usuario de . Ahora está disponible a través de Developer Console (en Cloud Manager) en el Consultas pestaña .

En esta página