Automatiser les cycles de vie des AMI

La procédure suivante montre comment utiliser Amazon Data Lifecycle Manager pour automatiser les cycles de vie des AMI Amazon EBS.

Pour créer une politique de cycle de vie d’AMI

Utilisez l’une des procédures suivantes pour créer une politique de cycle de vie d’AMI.

Console

Pour créer une politique d’AMI

1. Ouvrez la console Amazon EC2 à l’adresse https://console.aws.amazon.com/ec2/.

2. Dans le panneau de navigation, sélectionnez Elastic Block Store, Gestionnaire de cycle de vie, puis Créer une stratégie de cycle de vie d’instantané.

3. Dans l’écran Sélectionner un type de stratégie, choisissez Stratégie d’AMI EBS, puis Suivant.

4. Dans la section Ressources cibles, pour Etiquettes de ressources cibles, choisissez les étiquettes de ressources qui identifient les volumes ou les instances à sauvegarder. La politique sauvegarde uniquement les ressources ayant la clé de balise et les paires de valeurs spécifiées.

5. Pour Description, saisissez une brève description pour la stratégie.

6. Pour Rôle IAM, choisissez le rôle IAM autorisé à gérer des AMI et des instantanés, ainsi qu’à décrire des instances. Pour utiliser le rôle par défaut fourni par Amazon Data Lifecycle Manager, choisissez Rôle par défaut. Autrement, pour utiliser un rôle IAM personnalisé que vous avez créé précédemment, sélectionnez Choisir un autre rôle, puis sélectionnez le rôle à utiliser.

7. Pour Etiquettes de stratégie, ajoutez les étiquettes à appliquer à la stratégie de cycle de vie. Vous pouvez utiliser ces étiquettes pour identifier et catégoriser vos politiques.

8. Pour Statut de la stratégie après création, choisissez Activer la stratégie pour lancer l’exécutions de la stratégie lors de la prochaine heure planifiée ou Désactiver la stratégie pour empêcher l’exécution de la stratégie. Si vous n’activez pas la politique maintenant, elle ne commencera à créer des AMI que quand vous l’aurez activée manuellement après sa création.

9. Dans la section Redémarrage d’instance, indiquez si les instances doivent être redémarrées avant la création de l’AMI. Pour empêcher le redémarrage des instances ciblées, choisissez Non. Le choix de Non peut occasionner des problèmes de cohérence des données. Pour redémarrer les instances avant la création de l’AMI, choisissez Oui. Ce choix garantit la cohérence des données, mais peut entraîner le redémarrage simultané de plusieurs instances ciblées.

10. Choisissez Suivant.

11. Dans l’écran Configurer une planification, configurez les planifications de stratégie. Une politique peut avoir jusqu’à quatre planifications. La planification 1 est obligatoire. Les planifications 2, 3 et 4 sont facultatives. Pour chaque planification de politique que vous ajoutez, procédez comme suit :

    1. Dans la section Détails de la planification, procédez comme suit :

       1. Pour Nom de la planification, spécifiez un nom descriptif pour la planification.

       2. Pour Fréquence et les champs associés, configurez l’intervalle entre les exécutions de stratégie.

          Vous pouvez configurer les exécutions de politique selon une planification quotidienne, hebdomadaire, mensuelle ou annuelle. Vous pouvez également sélectionner Expression cron personnalisée pour spécifier un intervalle allant jusqu’à un an. Pour plus d'informations, consultez les expressions Cron dans le guide de l'utilisateur Amazon CloudWatch Events.

          Afficher plusAfficher moins

       3. Pour Démarrage à, spécifiez l’heure de démarrage des exécutions de la stratégie. La première exécution de la politique commence dans l’heure qui suit l’heure que vous planifiez. L’heure doit être au format UTC hh:mm.

       4. Pour Type de rétention, spécifiez la stratégie de rétention des AMI créées par la planification.

          Vous pouvez retenir les AMI en fonction de leur nombre total ou de leur âge.

          Pour la rétention basée sur le nombre, la plage s’étend de 1 à 1000. Une fois le nombre maximum atteint, l’AMI la plus ancienne est supprimée lors de la création d’une nouvelle AMI.

          Pour la rétention basée sur l’âge, la plage s’étend de 1 jour à 100 ans. Une fois la période de rétention de chaque AMI expirée, celle-ci est supprimée.

          Note

          Toutes les planifications doivent avoir le même type de conservation. Vous pouvez spécifier le type de conservation pour la planification 1 uniquement. Les planifications 2, 3 et 4 héritent du type de conservation de la planification 1. Chaque planification peut avoir son propre nombre ou sa propre période de conservation.

          Afficher plusAfficher moins

    2. Configurez le balisage pour les AMI.

       Dans la section Etiquetage, procédez comme suit :

       1. Pour copier toutes les étiquettes définies par l’utilisateur à partir de l’instance source vers les AMI créées par la planification, sélectionnez Copier les étiquettes à partir de la source.

       2. Par défaut, les AMI créées par la planification sont automatiquement étiquetées avec l’ID de l’instance source. Afin d’empêcher ce balisage automatique, pour Etiquettes de variables, supprimez la vignette instance-id:$(instance-id).

       3. Pour spécifier des étiquettes supplémentaires à attribuer aux AMI créées par cette planification, choisissez Ajouter des étiquettes.

       Afficher plusAfficher moins

    3. Configurez l’obsolescence des AMI.

       Pour rendre obsolètes les AMI lorsqu’elles ne doivent plus être utilisées, dans le champAMI deprecation (Obsolescence d’AMI), sélectionnez Enable AMI deprecation for this schedule (Activer l’obsolescence des AMI pour cette planification), puis spécifiez la règle d’obsolescence des AMI. La règle d’obsolescence des AMI spécifie quand les AMI deviennent obsolètes.

       Si la planification utilise la rétention d’AMI basée sur le nombre, vous devez spécifier le nombre d’AMI les plus anciennes à rendre obsolètes. Le nombre d’obsolescences doit être inférieur ou égal au nombre de rétention d’AMI de la planification, et il ne peut être supérieur à 1 000. Par exemple, si la planification est configurée pour conserver un maximum de 5 AMI, vous pouvez configurer la planification pour rendre obsolètes jusqu’à 5 anciennes AMI.

       Si la planification utilise la rétention d’AMI basée sur l’âge, vous devez spécifier la période après laquelle les AMI deviennent obsolètes. Le délai d’obsolescence doit être inférieur ou égal à la période de rétention d’AMI du planificateur, et il ne peut pas être supérieur à 10 ans (soit 120 mois, 520 semaines ou 3 650 jours). Par exemple, si la planification est configurée pour conserver les AMI pendant 10 jours, vous pouvez configurer les AMI planifiées pour les rendre obsolètes après des périodes allant jusqu’à 10 jours après leur création.

       Afficher plusAfficher moins

    4. Configurez la copie entre régions.

       Pour copier les AMI créées par la planification vers d’autres régions, dans la section Copie entre régions, sélectionnez Activer de la copie entre régions. Vous pouvez copier des AMI vers jusqu’à trois régions supplémentaires dans votre compte. Vous devez spécifier une règle de copie entre régions distincte pour chaque région de destination.

       Pour chaque Région de destination, vous pouvez spécifier les informations suivantes :

       • Règle de rétention pour les copies d’AMI. Lorsque la période de rétention expire, la copie dans la Région de destination est automatiquement supprimée.

       • Statut de chiffrement des copies d’AMI. Si l’AMI source est chiffrée, ou si le chiffrement par défaut est activé, alors les AMI copiées sont chiffrées. Si l’AMI source n’est pas chiffrée et que le chiffrement par défaut est désactivé, vous pouvez activer le chiffrement. Si vous ne spécifiez pas de clé KMS, les AMI sont chiffrées à l’aide de la clé KMS par défaut pour le chiffrement EBS dans chaque région de destination. Si vous spécifiez une clé KMS pour la Région de destination, le rôle IAM sélectionné doit avoir accès à la clé KMS.

       • Règle d’obsolescence pour les copies d’AMI. Les copies d’AMI deviennent automatiquement obsolètes lorsque la période d’obsolescence expire. La période d’obsolescence doit être inférieure ou égale à la période de rétention de la copie et ne peut être supérieure à 10 ans.

       • Que ce soit pour copier toutes les balises ou aucune balise de l’AMI source.

       Note

       Ne dépassez pas le nombre de copies d’AMI simultanées par région.

       Afficher plusAfficher moins

    5. Pour ajouter des planifications, choisissez l’option Ajouter une planification en haut de l’écran. Pour chaque planification supplémentaire, remplissez les champs comme décrit précédemment dans cette rubrique.

    6. Après avoir ajouté les planifications requises, choisissez Examiner une stratégie.

12. Examinez le récapitulatif de la stratégie, puis choisissez Créer une stratégie.

    Note

    Si vous obtenez l’erreur Role with name AWSDataLifecycleManagerDefaultRoleForAMIManagement already exists, consultez Résolution des problèmes pour plus d’informations.

Command line

Utilisez la commande create-lifecycle-policy pour créer une stratégie de cycle de vie d’AMI. Pour PolicyType, spécifiez IMAGE_MANAGEMENT.

Note

Pour simplifier la syntaxe, les exemples suivants utilisent un fichier JSON, policyDetails.json, qui comportent les détails de la stratégie.

Exemple 1 : rétention basée sur l’âge et obsolescence d’AMI

Cet exemple présente une stratégie de cycle de vie d’AMI qui crée des AMI de toutes les instances qui possèdent une clé de balise purpose avec une valeur de production sans redémarrer les instances ciblées. La politique comporte une planification qui crée une AMI tous les jours à 01:00 (UTC). La politique conserve les AMI pour 2 jours et les rend obsolètes après 1 jour. Elle copie également les étiquettes de l’instance source vers les AMI qu’elle crée.

aws dlm create-lifecycle-policy \
    --description "My AMI policy" \
    --state ENABLED \
    --execution-role-arn arn:aws:iam::12345678910:role/AWSDataLifecycleManagerDefaultRoleForAMIManagement \
    --policy-details file://policyDetails.json

Voici un exemple du fichier policyDetails.json.

{
    "PolicyType": "IMAGE_MANAGEMENT",
    "ResourceTypes": [
        "INSTANCE"
    ],
    "TargetTags": [{
        "Key": "purpose",
        "Value": "production"
    }],
    "Schedules": [{
            "Name": "DailyAMIs",
            "TagsToAdd": [{
                "Key": "type",
                "Value": "myDailyAMI"
            }],
            "CreateRule": {
                "Interval": 24,
                "IntervalUnit": "HOURS",
                "Times": [
                    "01:00"
                ]
            },
            RetainRule":{
                "Interval" : 2,
                "IntervalUnit" : "DAYS"
            },
            DeprecateRule": {
                "Interval" : 1,
                "IntervalUnit" : "DAYS"
            },
            "CopyTags": true
        }
    ],
    "Parameters" : {
        "NoReboot":true
    }
}

Si la demande aboutit, la commande renvoie l’ID de la politique nouvellement créée. Voici un exemple de sortie.

{
   "PolicyId": "policy-9876543210abcdef0"
}

Exemple 2 : rétention basée sur le nombre et obsolescence de l’AMI avec copie inter-Régions

Cet exemple présente une politique de cycle de vie d’AMI qui crée des AMI de toutes les instances qui possèdent une clé de balise de purpose avec une valeur de production et redémarre les instances ciblées. La politique comporte une planification qui crée une AMI toutes les 6 heures à partir de 17:30 (UTC). La politique conserve les AMI 3 et rend automatiquement obsolètes les AMI 2 les plus anciennes. Elle comprend également une règle de copie inter-Régions qui copie les AMI dans us-east-1, conserve copies d’AMI 2 et rend automatiquement obsolète l’AMI la plus ancienne.

aws dlm create-lifecycle-policy \
    --description "My AMI policy" \
    --state ENABLED \
    --execution-role-arn arn:aws:iam::12345678910:role/AWSDataLifecycleManagerDefaultRoleForAMIManagement \
    --policy-details file://policyDetails.json

Voici un exemple du fichier policyDetails.json.

{
    "PolicyType": "IMAGE_MANAGEMENT",
    "ResourceTypes" : [
        "INSTANCE"
    ],
    "TargetTags": [{
        "Key":"purpose", 
        "Value":"production"
    }],
    "Parameters" : {
          "NoReboot": true
    },
    "Schedules" : [{
        "Name" : "Schedule1",
        "CopyTags": true,
        "CreateRule" : {
            "Interval": 6,
            "IntervalUnit": "HOURS",
            "Times" : ["17:30"]
        },
        "RetainRule":{
            "Count" : 3
        },
        "DeprecateRule":{
            "Count" : 2
        },
        "CrossRegionCopyRules": [{
            "TargetRegion": "us-east-1",
            "Encrypted": true,
            "RetainRule":{
                "IntervalUnit": "DAYS",
                "Interval": 2
            },
            "DeprecateRule":{
                "IntervalUnit": "DAYS",
                "Interval": 1
            },
            "CopyTags": true
        }]
    }]
}

Considérations relatives aux stratégies de cycle de vie des AMI

Les considérations générales suivantes s’appliquent lors de la création de stratégies de cycle de vie d’AMI :

• Les politiques de cycle de vie des AMI ciblent uniquement les instances qui se trouvent dans la même région que la politique.

• La première opération de création d’AMI démarre dans l’heure suivant l’heure de début spécifiée. Les opérations suivantes de création d’AMI démarrent dans l’heure suivant leur heure planifiée.

• Lorsque Amazon Data Lifecycle Manager désenregistre une AMI, il la supprime automatiquement.

• Les balises de ressource cible sont sensibles à la casse.

• Si vous supprimez les balises cibles d’une instance ciblée par une politique, Amazon Data Lifecycle Manager ne gère plus les AMI existantes dans la norme. Vous devez les supprimer manuellement si elles ne sont plus nécessaires.

• Vous pouvez créer plusieurs stratégies pour sauvegarder une instance . Par exemple, si une instance comporte deux identifications, l’identification A étant la cible de la politique A qui permet de créer une AMI toutes les 12 heures et l’identification B étant la cible de la politique B qui permet de créer une AMI toutes les 24 heures, Amazon Data Lifecycle Manager crée des AMI en fonction des planifications des deux politiques. Vous pouvez également obtenir le même résultat en créant une seule politique comportant plusieurs planifications. Par exemple, vous pouvez créer une politique unique qui cible uniquement la balise A et spécifier deux planifications : l’une pour toutes les 12 heures et l’autre pour toutes les 24 heures.

• Les nouveaux volumes attachés à une instance cible après la création de la stratégie sont automatiquement inclus dans la sauvegarde lors de la prochaine exécution de la stratégie. Tous les volumes attachés à l’instance au moment de l’exécution de la politique sont inclus.

• Si vous créez une stratégie avec une planification personnalisée basée sur les crons configurée pour créer une seule AMI, la stratégie ne désenregistrera pas automatiquement cette AMI lorsque le seuil de rétention est atteint. Vous devez désenregistrer manuellement l’AMI si elle n’est plus nécessaire.

• Si vous créez une politique basée sur l’âge dans laquelle la période de conservation est plus courte que la fréquence de création, Amazon Data Lifecycle Manager conservera toujours la dernière AMI jusqu’à la création de la suivante. Par exemple, si une politique basée sur l’âge crée une AMI par mois avec une période de conservation de sept jours, Amazon Data Lifecycle Manager conservera chaque AMI pendant un mois, même si la période de conservation est de sept jours.

• Pour les politiques basées sur le nombre, Amazon Data Lifecycle Manager crée toujours des AMI en fonction de la fréquence de création avant de tenter de désenregistrer l’AMI la plus ancienne, conformément à la politique de rétention.

• Le désenregistrement d’une AMI et la suppression des instantanés de sauvegarde associés peuvent prendre plusieurs heures. Si Amazon Data Lifecycle Manager crée l’AMI suivante avant que l’AMI précédemment créée ne soit correctement désenregistrée, vous pouvez conserver temporairement un nombre d’AMI supérieur à votre nombre de conservation.

Les considérations suivantes s’appliquent à la résiliation des instances ciblées par une politique :

• Si vous résiliez une instance qui était ciblée par une politique avec une planification de la rétention basée sur le nombre, la politique ne gère plus les AMI qu’elle a précédemment créés à partir de l’instance résiliée. Vous devez désenregistrer manuellement ces AMI précédents lorsqu’ils ne sont plus nécessaires.

• Si vous résiliez une instance qui était ciblée par une politique avec une planification de rétention basée sur l’âge, la politique continue à désenregistrer les AMI qui ont été précédemment créés à partir de l’instance résiliée selon la planification définie, jusqu’au dernier AMI, mais sans l’inclure. Vous devez désenregistrer manuellement la dernière AMI si elle n’est plus nécessaire.

Les considérations suivantes s’appliquent aux politiques d’AMI et à l’obsolescence des AMI :

• Si vous augmentez le nombre d’AMI à rendre obsolètes pour une planification avec rétention basée sur le nombre, la modification sera appliquée à toutes les AMI (existantes et nouvelles) créées par la planification.

• Si vous augmentez la période d’obsolescence de l’AMI pour une planification avec rétention basée sur l’âge, la modification sera uniquement appliquée aux nouvelles AMI. Les AMI existantes ne sont pas affectées.

• Si vous supprimez la règle d’obsolescence d’AMI d’une planification, Amazon Data Lifecycle Manager n’annulera pas l’obsolescence pour les AMI qui étaient précédemment obsolètes conformément à cette planification.

• Si vous supprimez la règle d’obsolescence d’AMI d’une planification, Amazon Data Lifecycle Manager n’annulera pas l’obsolescence pour les AMI qui étaient précédemment obsolètes conformément à cette planification.

• Si vous rendez manuellement obsolète une AMI créée par une politique d’AMI, Amazon Data Lifecycle Manager ne remplacera pas l’obsolescence.

• Si vous annulez manuellement l’obsolescence d’une AMI précédemment rendue obsolète par une politique AMI, Amazon Data Lifecycle Manager ne remplacera pas l’annulation.

• Si une AMI est créée par plusieurs planifications conflictuelles et qu’une ou plusieurs de ces planifications n’ont pas de règle d’obsolescence des AMI, Amazon Data Lifecycle Manager ne rendra pas cette AMI obsolète.

• Si une AMI est créée par plusieurs planifications conflictuelles et que toutes ces planifications disposent d’une règle d’obsolescence des AMI, Amazon Data Lifecycle Manager utilisera la règle d’obsolescence qui donne la date d’obsolescence la plus tardive.

Les considérations suivantes s'appliquent aux politiques de l'AMI et à la corbeille :

• Si Amazon Data Lifecycle Manager annule l’enregistrement d’une AMI et l’envoie à la corbeille lorsque le seuil de rétention de la politique est atteint, et que vous restaurez manuellement l’AMI à partir de la corbeille, vous devez annuler manuellement l’enregistrement de cette AMI lorsqu’elle n’est plus nécessaire. Amazon Data Lifecycle Manager ne gérera plus l’AMI.

• Si vous annulez manuellement l’enregistrement d’une AMI créée par une politique et que cette AMI se trouve dans la corbeille lorsque le seuil de rétention de la politique est atteint, Amazon Data Lifecycle Manager n’annule pas l’enregistrement de l’AMI. Amazon Data Lifecycle Manager ne gère pas les AMI lorsqu’elles sont dans la corbeille.

  Si l’AMI est restaurée à partir de la corbeille avant que le seuil de rétention de la politique soit atteint, Amazon Data Lifecycle Manager annule l’enregistrement de l’AMI lorsque le seuil de rétention de la politique est atteint.

  Si l’AMI est restaurée à partir de la corbeille après que le seuil de rétention de la politique soit atteint, Amazon Data Lifecycle Manager n’annule plus l’enregistrement de l’AMI. Vous devez la supprimer manuellement lorsqu’elle n’est plus nécessaire.

Les considérations suivantes s’appliquent aux politiques d’AMI qui sont à l’état d’erreur :

• Pour les politiques avec des planifications de rétention basées sur l’âge, les AMI qui sont configurés pour expirer alors que la politique est dans l’état error sont conservés indéfiniment. Vous devez annuler l’enregistrement des AMI manuellement. Lorsque vous réactivez la politique, Amazon Data Lifecycle Manager reprend l’annulation de l’enregistrement des AMI à mesure que leurs périodes de rétention expirent.

• Pour les politiques avec des planifications de rétention basée sur le nombre, la politique arrête de créer et d’annuler l’enregistrement des AMI pendant qu’elle est dans l’état error. Lorsque vous réactivez la politique, Amazon Data Lifecycle Manager reprend la création des AMI, ainsi que l’annulation de l’enregistrement des AMI lorsque le seuil de rétention est atteint.

Les considérations suivantes s'appliquent aux politiques d'AMI et à la désactivation des AMI :

• Si vous désactivez une AMI créée par Amazon Data Lifecycle Manager et que cette AMI est désactivée lorsque son seuil de rétention est atteint, Amazon Data Lifecycle Manager désenregistre l’AMI et supprime les instantanés associés.

• Si vous désactivez une AMI créée par Amazon Data Lifecycle Manager et que vous archivez manuellement les instantanés associés, et que ces instantanés sont archivés lorsque leur seuil de rétention est atteint, Amazon Data Lifecycle Manager ne supprimera pas ces instantanés et ne les gérera plus.

Les considérations suivantes s'appliquent aux politiques de l'AMI et à la protection contre le désenregistrement de l'AMI :

• Si vous activez manuellement la protection de désenregistrement pour une AMI créée par Amazon Data Lifecycle Manager et qu'elle est toujours activée lorsque le seuil de rétention de l'AMI est atteint, Amazon Data Lifecycle Manager ne gère plus cette AMI. Vous devez annuler manuellement l'enregistrement de l'AMI et supprimer ses instantanés sous-jacents s'ils ne sont plus nécessaires.

Ressources supplémentaires

Pour plus d'informations, consultez le blog Automating Amazon EBS snapshot and AMI management using Amazon Data Lifecycle Manager AWS storage.