La fonctionnalité « cycle de vie » (ou lifecycle en anglais) permet de stocker des objets de façon économe (parce que le stockage n’est pas gratuit).
Une configuration lifecycle est un ensemble de règles qui va s’appliquer automatiquement et régulièrement à un groupe d’objets dans un compartiment (ou bucket en anglais).
Chaque règle (rule en anglais) contient un filtre (filter en anglais) qui définit à quels objets elle va s’appliquer.
Une règle est activée (enabled) or désactivée (disabled).
Elle contient une ou plusieurs actions.
Un filtre contient un des éléments suivants:
un préfixe vide (cad. aucun filtrage)
un préfixe
une ou plusieurs valeurs de tag
à la fois un préfixe et une ou plusieurs valeurs de tag
une limite supérieure ou inférieure de taille d’objet
Cas d’usage typique:
effacement d’ancien logs
conservation au maximum de n versions d’objet
de façon générale, contrôler la quantité totale de stockage utilisé et donc son coût
Remarque: c’est une bonne pratique d’utiliser lifecycle quand la gestion des versions (versioning) est activée sur un compartiment (bucket).
Actions de transition
Elles définissent à quel moment les objets seront déplacés vers une autre catégorie de stockage.
ATTENTION : non supporté pour l’instant
Actions d’expiration
Elles définissent comment et à quel moment les objets seront expirés (effacés).
Les actions possibles sont:
Expiration c.-à-d. effacer les versions courantes d’objet (y compris les marqueurs de suppression expirés en option)
après n jours ( Days ) ou après une date ( Date )
ou seulement effacer les marqueurs de suppression expirés avec ExpiredObjectDeleteMarker
NoncurrentVersionExpiration c.-à-d. effacer les versions non courantes d’objet
après n jours ( Days )
ou en conservant au maximum n versions non courantes ( NewerNoncurrentVersions )
AbortIncompleteMultipartUpload c.-à-d. effacer les chargements partitionnés (multipart uploads en anglais)
après n jours ( Days ) (depuis le démarrage)
Remarques:
les actions d’expiration sont appliquées chaque jour
donc l’effacement peut être retardé
à partir du moment où l’expiration des objets est prévue, ils seront effacés de toute façon
l’expiration fonctionne quel que soit l’état de la gestion des versions d’un compartiment (mais les résultats varient)
Cas d’usage avec AWS CLI
AWS CLI (Command Line Interface) est un outil à code source libre permettant de configurer et d’utiliser le stockage objet en passant des commandes dans un interface textuelle (un shell Linux ou la ligne de commande Windows).
le filtre ( Filter ) a un prefix vide afin de traiter tous les objets (d’un compartiment)
le statut ( Status ) est activé (enabled) afin de rendre effective la configuration
l’action est Expiration afin d’effacer les versions courantes
le critère temporel pour l’action est une Date afin de déclencher l’action strictement après cette date (un certain délai est à prévoir)
Un critère temporel plus utile pour l’action Expiration est Days. Il permet l’expiration de la version courante après avoir atteint une certaine durée de vie (en jours).
Ceci effacerait les versions courantes âgées de plus de 5 jours:
... "Expiration": { "Days": 5 }, ...
Compartiment avec la gestion des versions non activée
La metadata VersionId est toujours à null (car non requise).
La metadata IsLatest est toujours à vraie (true) (c.-à-d. que la version est courante).
le filtre ( Filter ) a un prefix vide afin de traiter tous les objets (d’un compartiment)
le statut ( Status ) est activé (enabled) afin de rendre effective la configuration
l’action est Expiration afin d’effacer les versions courantes
le critère temporel pour l’action est un nombre de jours ( Days ) afin de déclencher l’action strictement après une certaine durée de vie des versions non courantes (un certain délai est à prévoir)
Compartiment avec la gestion des versions non activée
L’expiration des versions non courantes est sans objet dans ce cas.
Compartiment avec la gestion des versions activée
Avant
Voir Après_2
Après
le compartiment est presque vide (seulement des marqueurs de suppression)
obj1
reste effacé: la version courante est un marqueur de suppression (pas de changement)
la version non courante avec de la data a été effacée
obj2
reste effacé: la version courante est un marqueur de suppression (pas de changement)
les 2 versions non courantes avec de la data ont été effacées
obj3
reste effacé: la version courante est un marqueur de suppression (pas de changement)
la version non courante avec de la data a été effacée
Compartiment avec la gestion des versions désactivée
ATTENTION : non supporté pour l’instant
Autres options
Effacer les uploads multipart incomplets
Un upload multipart (en plusieurs parties) est une bonne pratique pour un gros objet.
Cela permet d’améliorer le temps de transfert et de mieux récupérer en cas de problème réseau.
Parfois un upload multipart échoue sans être suivi (quelle que soit la raison).
Vous pouvez utiliser l’action AbortIncompleteMultipartUpload pour supprimer les uploads multipart non terminés depuis un certain temps ( DaysAfterInitiation ).
Exemple (uploads multipart non terminés depuis 2 jours):
Quand vous utilisez l’action Expiration avec les paramètres Days et Date, les marqueurs de suppression expirés et concernés sont effacés.
Pour effacer systématiquement tous les marqueurs de suppression expirés indépendamment de leur âge, vous pouvez utiliser le paramètre ExpiredObjectDeleteMarker.
Ce paramètre doit être utilisé seul dans une règle (rule).