Tareas de mantenimiento en AEM as a Cloud Service maintenance-tasks-in-aem-as-a-cloud-service
Las tareas de mantenimiento son procesos que se ejecutan según una programación para optimizar el repositorio. Con AEM as a Cloud Service, la necesidad de que los clientes configuren las propiedades operativas de las tareas de mantenimiento es mínima. Los clientes pueden enfocar sus recursos en preocupaciones del nivel de la aplicación y dejar que Adobe se encargue de las operaciones de infraestructura.
Configuración de tareas de mantenimiento maintenance-tasks-configuring
En versiones anteriores de AEM, se podían configurar tareas de mantenimiento mediante la tarjeta de mantenimiento (Herramientas > Operaciones > Mantenimiento). La tarjeta de mantenimiento ya no está disponible para AEM as a Cloud Service, por lo que las configuraciones deben enviarse al control de origen e implementarse mediante Cloud Manager. Adobe administra las tareas de mantenimiento que tienen configuraciones que los clientes no pueden configurar (por ejemplo, Recopilación de elementos no utilizados del almacén de datos). Los clientes pueden configurar otras tareas de mantenimiento, como se describe en la tabla siguiente.
En la tabla siguiente se ilustran las tareas de mantenimiento disponibles.
Ubicaciones:
- Diario: /apps/settings/granite/operations/maintenance/granite_daily
- Semanal: /apps/settings/granite/operations/maintenance/granite_weekly
- Mensual: /apps/settings/granite/operations/maintenance/granite_monthly
Muestras de código:
Muestra de código 1 (diario)
<?xml version="1.0" encoding="UTF-8"?>
<jcr:root xmlns:sling="http://sling.apache.org/jcr/sling/1.0"
xmlns:jcr="http://www.jcp.org/jcr/1.0"
jcr:primaryType="sling:Folder"
sling:configCollectionInherit="true"
sling:configPropertyInherit="true"
windowSchedule="daily"
windowStartTime="03:00"
windowEndTime="05:00"
/>
Muestra de código 2 (semanal)
<?xml version="1.0" encoding="UTF-8"?>
<jcr:root xmlns:sling="http://sling.apache.org/jcr/sling/1.0"
xmlns:jcr="http://www.jcp.org/jcr/1.0"
jcr:primaryType="sling:Folder"
sling:configCollectionInherit="true"
sling:configPropertyInherit="true"
windowEndTime="15:30"
windowSchedule="weekly"
windowScheduleWeekdays="[5,5]"
windowStartTime="14:30"/>
Muestra de código 3 (mensual)
<?xml version="1.0" encoding="UTF-8"?>
<jcr:root xmlns:sling="http://sling.apache.org/jcr/sling/1.0"
xmlns:jcr="http://www.jcp.org/jcr/1.0"
jcr:primaryType="sling:Folder"
sling:configCollectionInherit="true"
sling:configPropertyInherit="true"
windowEndTime="15:30"
windowSchedule="monthly"
windowFirstLastStartDay=0
windowScheduleWeekdays="[5,5]"
windowStartTime="14:30"/>
Tareas de mantenimiento de purga de versiones y depuración de registros de auditoría purge-tasks
La depuración de versiones y del registro de auditoría reduce el tamaño del repositorio y, en algunos casos, puede mejorar el rendimiento.
Valores predeterminados defaults
Actualmente, la depuración no está habilitada de forma predeterminada, pero esto cambiará en el futuro. Los entornos que se crearon antes de habilitar la depuración predeterminada tendrán un umbral más conservador para que la depuración no se produzca de forma inesperada. Consulte las secciones Depuración de versiones y Depuración del registro de auditoría a continuación para obtener más detalles sobre la política de depuración predeterminada.
Los valores de depuración predeterminados se pueden sobrescribir declarando un archivo de configuración e implementándolo como se describe a continuación.
Aplicación de una configuración configure-purge
Declare un archivo de configuración e impleméntelo como se describe en los pasos siguientes.
1 - cree la siguiente carpeta y estructura de archivos en la carpeta de nivel superior de su proyecto en Git:
config/
mt.yaml
2 - Declarar propiedades en el archivo de configuración, que incluyen:
- una propiedad "kind" con el valor "MaintenanceTasks".
- una propiedad "version" (actualmente estamos en la versión 1).
- un objeto "metadata" opcional con la propiedad
envTypescon una lista separada por comas del tipo de entorno (dev, stage, prod) para el cual esta configuración es válida. Si no se declara ningún objeto de metadatos, la configuración es válida para todos los tipos de entorno. - un objeto de datos con
versionPurgeyauditLogPurgeobjetos.
Vea las definiciones y sintaxis de los objetos versionPurge y auditLogPurge a continuación.
La configuración debe estructurarse de forma similar al siguiente ejemplo:
kind: "MaintenanceTasks"
version: "1"
metadata:
envTypes: ["dev"]
data:
versionPurge:
maximumVersions: 15
maximumAgeDays: 20
paths: ["/content"]
minimumVersions: 1
retainLabelledVersions: false
auditLogPurge:
rules:
- replication:
maximumAgeDays: 15
contentPath: "/content"
types: ["Activate", "Deactivate", "Delete", "Test", "Reverse", "Internal Poll"]
- pages:
maximumAgeDays: 15
contentPath: "/content"
types: ["PageCreated", "PageModified", "PageMoved", "PageDeleted", "VersionCreated", "PageRestored", "PageValid", "PageInvalid"]
- dam:
maximumAgeDays: 15
contentPath: "/content"
types: ["ASSET_EXPIRING", "METADATA_UPDATED", "ASSET_EXPIRED", "ASSET_REMOVED", "RESTORED", "ASSET_MOVED", "ASSET_VIEWED", "PROJECT_VIEWED", "PUBLISHED_EXTERNAL", "COLLECTION_VIEWED", "VERSIONED", "ADDED_COMMENT", "RENDITION_UPDATED", "ACCEPTED", "DOWNLOADED", "SUBASSET_UPDATED", "SUBASSET_REMOVED", "ASSET_CREATED", "ASSET_SHARED", "RENDITION_REMOVED", "ASSET_PUBLISHED", "ORIGINAL_UPDATED", "RENDITION_DOWNLOADED", "REJECTED"]
Tenga en cuenta que para que la configuración sea válida:
- todas las propiedades deben estar definidas. No hay valores predeterminados heredados.
- se deben respetar los tipos (enteros, cadenas, booleanos, etc.) de las tablas de propiedades siguientes.
yq para validar localmente el formato YAML del archivo de configuración (por ejemplo, yq mt.yaml).3: configure las canalizaciones de configuración de no producción y producción.
Los entornos de desarrollo rápido (RDE) no admiten la depuración. Para otros tipos de entornos en programas de producción (que no sean de zona protegida), cree una canalización de configuración de implementación de destino en Cloud Manager.
Consulte configuración de canalizaciones de producción y configuración de canalizaciones que no son de producción para obtener más información.
Depuración de la versión version-purge
Valores predeterminados de depuración de versión version-purge-defaults
Actualmente, la depuración no está habilitada de forma predeterminada, pero esto cambiará en el futuro.
Los entornos que se crearon después de habilitar la depuración predeterminada tendrán los siguientes valores predeterminados:
- Se eliminan las versiones con más de 30 días.
- Se conservan las cinco versiones más recientes de los últimos 30 días.
- Independientemente de las reglas anteriores, se conserva la versión más reciente (además del archivo actual).
Los entornos que se crearon antes de habilitar la depuración predeterminada tendrán los valores predeterminados que se enumeran a continuación, pero se recomienda reducir esos valores para optimizar el rendimiento.
- Se eliminan las versiones anteriores a 7 años.
- Se conservan todas las versiones de los últimos 7 años.
- Después de 7 años, se eliminan otras versiones que no sean la más reciente (además del archivo actual).
Propiedades de purga de versiones version-purge-properties
Las propiedades permitidas se enumeran a continuación.
Las columnas que indican default indican los valores predeterminados en el futuro, cuando se apliquen los valores predeterminados; TBD refleja un identificador de entorno que aún no se ha determinado.
Interacciones de propiedades
Los siguientes ejemplos ilustran cómo interactúan las propiedades al combinarse.
Ejemplo:
maximumAgeDays = 30
maximumVersions = 10
minimumVersions = 2
Si hay 11 versiones el día 23, la versión más antigua se purgará la próxima vez que se ejecute la tarea de mantenimiento de purga, ya que la propiedad maximumVersions está establecida en 10.
Si hay 5 versiones en el día 31, solo se purgarán 3, ya que la propiedad minimumVersions está establecida en 2.
Ejemplo:
maximumAgeDays = 30
maximumVersions = 0
minimumVersions = 1
No se purgarán versiones posteriores a los 30 días debido a que la propiedad maximumVersions está establecida en 0.
Se conservará una versión con más de 30 días.
Purga del registro de auditoría audit-purge
Valores predeterminados de purga del registro de auditoría audit-purge-defaults
Actualmente, la depuración no está habilitada de forma predeterminada, pero esto cambiará en el futuro.
Los entornos que se crearon después de habilitar la depuración predeterminada tendrán los siguientes valores predeterminados:
- Se eliminan los registros de replicación, DAM y auditoría de página anteriores a 7 días.
- Se registran todos los eventos posibles.
Los entornos que se crearon antes de habilitar la depuración predeterminada tendrán los valores predeterminados que se enumeran a continuación, pero se recomienda reducir esos valores para optimizar el rendimiento.
- Se eliminan los registros de replicación, DAM y auditoría de página anteriores a 7 años.
- Se registran todos los eventos posibles.
Propiedades de purga del registro de auditoría audit-purge-properties
Las propiedades permitidas se enumeran a continuación.
Las columnas que indican default indican los valores predeterminados en el futuro, cuando se apliquen los valores predeterminados; TBD refleja un identificador de entorno que aún no se ha determinado.