Tâches de maintenance dans AEM as a Cloud Service maintenance-tasks-in-aem-as-a-cloud-service
Les tâches de maintenance sont des processus qui s’exécutent selon un calendrier afin d’optimiser le référentiel. Avec AEM as a Cloud Service, le besoin des clients de configurer les propriétés opérationnelles des tâches de maintenance est minime. Les clients peuvent concentrer leurs ressources sur des préoccupations de niveau application, laissant les opérations d’infrastructure à Adobe.
Configuration des tâches de maintenance maintenance-tasks-configuring
Dans les versions précédentes d’AEM, vous pouviez configurer les tâches de maintenance à l’aide de la carte de maintenance (Outils > Opérations > Maintenance). Dans AEM as a Cloud Service, la carte de maintenance n’est plus disponible. Les configurations doivent donc être validées pour le contrôle source et déployées à l’aide de Cloud Manager. Adobe gère les tâches de maintenance dont les paramètres ne peuvent pas être configurés par les clients (par exemple, le nettoyage de la mémoire d’entrepôt de données). D’autres tâches de maintenance peuvent être configurées par les clients, comme décrit dans le tableau ci-dessous.
Le tableau suivant illustre les tâches de maintenance disponibles.
Emplacements :
- Quotidien – /apps/settings/granite/operations/maintenance/granite_daily
- Hebdomadaire – /apps/settings/granite/operations/maintenance/granite_weekly
- Mensuel – /apps/settings/granite/operations/maintenance/granite_monthly
Exemples de code :
Exemple de code 1 (quotidien)
<?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"
/>
Exemple de code 2 (hebdomadaire)
<?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"/>
Exemple de code 3 (mensuel)
<?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"/>
Tâches de maintenance de purge de version et de purge du journal d’audit purge-tasks
La purge des versions et le journal d’audit réduit la taille du référentiel et, dans certains cas, peut améliorer les performances.
Paramètres par défaut defaults
Actuellement, la purge n’est pas activée par défaut, mais cela changera à l’avenir. Les environnements créés avant l’activation de la purge par défaut auront un seuil plus conservateur, de sorte que la purge ne se produise pas de manière inattendue. Pour plus d’informations sur la stratégie de purge par défaut, reportez-vous aux sections Purge de version et Purge du journal d’audit ci-dessous.
Les valeurs de purge par défaut peuvent être remplacées en déclarant un fichier de configuration et en le déployant, comme décrit ci-dessous.
Application d’une configuration configure-purge
Déclarez un fichier de configuration et déployez-le, comme décrit dans les étapes suivantes.
1 Créez un fichier nommé mt.yaml
ou similaire.
2 Placez le fichier quelque part sous un dossier de niveau supérieur nommé config
ou similaire, comme décrit dans Utilisation des pipelines de configuration.
3 - Déclarez les propriétés dans le fichier de configuration, notamment :
-
quelques propriétés au-dessus du noeud de données — voir Utilisation de pipelines de configuration pour une description. La valeur de la propriété
kind
doit être MaintenanceTasks et la version doit être définie sur 1. -
un objet de données avec les objets
versionPurge
etauditLogPurge
.
Voir les définitions et la syntaxe des objets versionPurge
et auditLogPurge
ci-dessous.
Organisez la configuration comme dans l’exemple suivant :
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"]
Gardez à l’esprit que pour que la configuration soit valide :
- toutes les propriétés doivent être définies. Il n’existe aucun paramètre par défaut hérité.
- les types (entiers, chaînes, valeurs booléennes, etc.) dans les tableaux de propriétés ci-dessous doivent être respectés.
4 - Créez un pipeline de configuration dans Cloud Manager, comme décrit dans l’article config pipeline . Les environnements de test et les environnements de développement rapide ne prennent pas en charge la purge.
Purge de version version-purge
Valeurs par défaut de la purge de version version-purge-defaults
Actuellement, la purge n’est pas activée par défaut, mais cela changera à l’avenir.
Les environnements créés après l’activation de la purge par défaut auront les valeurs par défaut suivantes :
- Les versions de plus de 30 jours sont supprimées.
- Les cinq versions les plus récentes des 30 derniers jours sont conservées.
- Quelle que soit la règle ci-dessus, la version la plus récente (en plus du fichier actif) est conservée.
Les valeurs par défaut des environnements créés avant l’activation de la purge par défaut sont répertoriées ci-dessous, mais il est recommandé de les réduire afin d’optimiser les performances.
- Les versions de plus de 7 ans sont supprimées.
- Toutes les versions des 7 dernières années sont conservées.
- Au bout de 7 ans, les versions autres que la version la plus récente (en plus du fichier actif) sont supprimées.
Propriétés de purge de version version-purge-properties
Les propriétés autorisées sont répertoriées ci-dessous.
Les colonnes indiquant default indiquent les valeurs par défaut à l’avenir, lorsque les valeurs par défaut sont appliquées ; TBD reflète un ID d’environnement qui n’est toujours pas déterminé.
valeur par défaut future pour envs
À déterminer
Interactions de propriété
Les exemples suivants illustrent la manière dont les propriétés interagissent lorsqu’elles sont combinées.
Exemple :
maximumAgeDays = 30
maximumVersions = 10
minimumVersions = 2
S’il existe 11 versions le 23 jour, la version la plus ancienne sera purgée la prochaine fois que la tâche de maintenance de purge sera exécutée, puisque la propriété maximumVersions
est définie sur 10.
S’il existe 5 versions au jour 31, seules 3 versions seront purgées, car la propriété minimumVersions
est définie sur 2.
Exemple :
maximumAgeDays = 30
maximumVersions = 0
minimumVersions = 1
Aucune version ultérieure à 30 jours ne sera purgée, car la propriété maximumVersions
est définie sur 0.
Une version de plus de 30 jours sera conservée.
Purge du journal d’audit audit-purge
Valeurs par défaut de la purge du journal d’audit audit-purge-defaults
Actuellement, la purge n’est pas activée par défaut, mais cela changera à l’avenir.
Les environnements créés après l’activation de la purge par défaut auront les valeurs par défaut suivantes :
- Les journaux de réplication, de gestion des actifs numériques et d’audit de page datant de plus de 7 jours sont supprimés.
- Tous les événements possibles sont consignés.
Les valeurs par défaut des environnements créés avant l’activation de la purge par défaut sont répertoriées ci-dessous, mais il est recommandé de les réduire afin d’optimiser les performances.
- Les journaux de réplication, de gestion des actifs numériques et d’audit de page datant de plus de 7 ans sont supprimés.
- Tous les événements possibles sont consignés.
Propriétés de purge du journal d’audit audit-purge-properties
Les propriétés autorisées sont répertoriées ci-dessous.
Les colonnes indiquant default indiquent les valeurs par défaut à l’avenir, lorsque les valeurs par défaut sont appliquées ; TBD reflète un ID d’environnement qui n’est toujours pas déterminé.
valeur par défaut future pour envs
À déterminer