Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Recuperar el estado de ciclo de vida de destino a través de los metadatos de instancia
Cada instancia de Auto Scaling que se lanza pasa por varios estados de ciclo de vida. Para invocar acciones personalizadas desde el interior de una instancia para que actúen en determinadas transiciones de estado de ciclo de vida, puede hacerlo recuperando el estado de ciclo de vida de destino a través de los metadatos de instancia.
Por ejemplo, es posible que necesite un mecanismo que detecte la terminación de la instancia desde dentro de la instancia para ejecutar parte del código en la instancia antes de que finalice. Para ello, escriba un código que sondee el estado del ciclo de vida de una instancia directamente desde la instancia. A continuación, puede agregar un enlace de ciclo de vida al grupo de escalado automático para mantener la instancia en ejecución hasta que el código envíe el comando complete-lifecycle-action para continuar.
El ciclo de vida de las instancias de Auto Scaling tiene dos estados estables principales (InService
y Terminated
) y dos estados estables secundarios (Detached
y Standby
). Si utiliza un grupo de calentamiento, el ciclo de vida tiene cuatro estados estables adicionales: Warmed:Hibernated
, Warmed:Running
, Warmed:Stopped
y Warmed:Terminated
.
Cuando una instancia se prepara para pasar a uno de los estados estables anteriores, Amazon EC2 Auto Scaling actualiza el valor del elemento autoscaling/target-lifecycle-state
de los metadatos de instancia. Para obtener el estado de ciclo de vida de destino desde la propia instancia, debe utilizar el Servicio de metadatos de instancia para recuperarlo desde los metadatos de instancia.
nota
Los metadatos de instancia son datos de una instancia de Amazon EC2 que las aplicaciones pueden utilizar para consultar información sobre esa instancia. El Servicio de metadatos de instancia es un componente de la instancia que el código local utiliza para acceder a los metadatos de instancia. El código local puede incluir scripts de datos de usuario o aplicaciones que se ejecuten en la instancia.
El código local puede acceder a los metadatos de instancia de una instancia en ejecución mediante uno de estos dos métodos: Instance Metadata Service versión 1 (IMDSv1) o Instance Metadata Service versión 2 (IMDSv2). IMDSv2 utiliza solicitudes orientadas a la sesión y mitiga varios tipos de vulnerabilidades que se podrían utilizar para intentar acceder a los metadatos de instancia. Para obtener más información sobre estos dos métodos, consulte Uso de IMDSv2 en la Guía del usuario de Amazon EC2.
A continuación, se muestra un ejemplo del resultado.
InService
El estado de ciclo de vida de destino es el estado al que va a pasar la instancia. El estado de ciclo de vida actual es el estado en el que se encuentra la instancia. Ambos pueden ser el mismo una vez que se complete la acción de ciclo de vida y la instancia finalice su paso al estado de ciclo de vida de destino. No se puede recuperar el estado de ciclo de vida actual de la instancia a partir de los metadatos de instancia.
Amazon EC2 Auto Scaling comenzó a generar el estado de ciclo de vida de destino el 10 de marzo de 2022. Si la instancia pasa a alguno de los estados de ciclo de vida de destino después de esa fecha, el elemento del estado de ciclo de vida de destino aparece en los metadatos de instancia. En caso contrario, no aparece, y verá un error HTTP 404.
Para obtener más información sobre la recuperación de metadatos de instancias, consulte Recuperar metadatos de instancias en la Guía del usuario de Amazon EC2.
Para ver un tutorial que muestra cómo crear un enlace de ciclo de vida con una acción personalizada en un script de datos de usuario que utiliza el estado de ciclo de vida de destino, consulte Tutorial: Utilice los metadatos del script de datos y de la instancia para recuperar el estado del ciclo de vida.
importante
Para asegurarse de que puede invocar una acción personalizada lo antes posible, su código local debería sondear el IMDS con frecuencia y volver a intentarlo en caso de errores.