Solución de problemas OpsWorks para Puppet Enterprise - AWS OpsWorks

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.

Solución de problemas OpsWorks para Puppet Enterprise

importante

El AWS OpsWorks for Puppet Enterprise servicio llegó al final de su vida útil el 31 de marzo de 2024 y se ha desactivado tanto para los clientes nuevos como para los actuales. Recomendamos encarecidamente a los clientes que migren sus cargas de trabajo a otras soluciones lo antes posible. Si tienes preguntas sobre la migración, ponte en contacto con el AWS Support equipo en AWS Re:post o a través de Premium AWS Support.

Este tema contiene algunos problemas comunes OpsWorks relacionados con Puppet Enterprise y sugerencias de soluciones para dichos problemas.

Consejos generales para la solución de problemas

Si no puede crear o trabajar con un nodo maestro de Puppet, los mensajes de error o los registros pueden serle útiles para solucionar el problema. En las tareas siguientes se describe por qué ubicaciones generales hay que comenzar para solucionar un problema relacionado con un nodo maestro de Puppet. Para obtener más información sobre errores y soluciones concretos, consulte la sección Solución de problemas específicos de este tema.

  • Utilice la consola de Puppet Enterprise OpsWorks para ver los mensajes de error si un Puppet Master no se puede iniciar. En la página de propiedades del nodo maestro de Puppet, en la parte superior de la página se muestran los mensajes de error relacionados con el lanzamiento y la ejecución del servidor. Los errores pueden provenir OpsWorks de los servicios de Puppet Enterprise o Amazon EC2 que se utilizan para crear un Puppet Master. AWS CloudFormation En la página de propiedades, también podrá ver los eventos que se producen en un servidor que se está ejecutando y que pueden contener mensajes de eventos de error.

  • Para ayudar a resolver EC2 los problemas, conéctese a la instancia de su servidor mediante SSH y consulte los registros. EC2 los registros de las instancias se almacenan en el /var/log/aws/opsworks-cm directorio. Estos registros capturan los resultados de los comandos mientras OpsWorks Puppet Enterprise lanza un Puppet master.

Solución de problemas específicos

El servidor está en un estado de Conexión Perdida

Problema: el estado de un servidor es conexión Perdida.

Causa: esto suele ocurrir cuando una entidad externa o AWS OpsWorks realiza cambios en un OpsWorks servidor de Puppet Enterprise o en sus recursos auxiliares. AWS OpsWorks no puede conectarse a los servidores de Puppet Enterprise en estados de conexión perdida para realizar tareas de mantenimiento, como crear copias de seguridad, aplicar parches del sistema operativo o actualizar Puppet. Como resultado, es posible que al servidor le falten actualizaciones importantes, que se le presenten problemas de seguridad o que no funcione como se esperaba.

Solución: pruebe los siguientes pasos para restablecer la conexión del servidor.

  1. Asegúrese de que su rol de servicio tenga todos los permisos necesarios.

    1. En la página Configuración de su servidor, en Red y seguridad, seleccione el enlace correspondiente al rol de servicio que utiliza el servidor. Esto abre el rol de servicio para su visualización en la consola de IAM.

    2. En la pestaña Permisos, compruebe que AWSOpsWorksCMServiceRole se encuentra en la lista de Políticas de permisos. Si no aparece en la lista, agregue la política AWSOpsWorksCMServiceRole administrada manualmente al rol.

    3. En la pestaña Relaciones de confianza, compruebe que el rol de servicio tenga una política de confianza que confíe en que el opsworks-cm.amazonaws.com servicio asuma las funciones en su nombre. Para obtener más información sobre cómo usar las políticas de confianza con los roles, consulte Modificación de un rol (consola) o la entrada del blog de AWS seguridad, Cómo usar las políticas de confianza con los roles de IAM.

  2. Asegúrese de que el perfil de instancia tenga todos los permisos necesarios.

    1. En la página Configuración de su servidor, en Red y seguridad, elija el enlace para el perfil de instancia que está utilizando el servidor. Esto abre el perfil de instancia para su visualización en la consola de IAM.

    2. En la pestaña Permisos, compruebe que AmazonEC2RoleforSSM y AWSOpsWorksCMInstanceProfileRole se encuentran en la lista de políticas de permisos. Si una o ambas no aparecen en la lista, añada estas políticas administradas manualmente al rol.

    3. En la pestaña Relaciones de confianza, compruebe que el rol de servicio tenga una política de confianza que confíe en que el ec2.amazonaws.com servicio asuma las funciones en su nombre. Para obtener más información sobre cómo usar las políticas de confianza con los roles, consulte Modificación de un rol (consola) o la entrada del blog de AWS seguridad, Cómo usar las políticas de confianza con los roles de IAM.

  3. En la EC2 consola de Amazon, asegúrese de que se encuentra en la misma región que la región del OpsWorks servidor de Puppet Enterprise y, a continuación, reinicie la EC2 instancia que está utilizando su servidor.

    1. Elija la EC2 instancia a la que se le asigne el nombre aws-opsworks-cm-instance-server-name.

    2. En el menu Estado de la instancia, elija Reiniciar instancia.

    3. Espere hasta 15 minutos para que el servidor se reinicie y esté completamente en línea.

  4. En la consola OpsWorks de Puppet Enterprise, en la página de detalles del servidor, compruebe que el estado del servidor es correcto.

Si el estado del servidor sigue siendo Conexión perdida tras realizar los pasos anteriores, intente una de las siguientes acciones.

La creación del servidor da error con un mensaje parecido al siguiente "requested configuration is currently not supported".

Problema: está intentando crear un servidor Puppet Enterprise, pero el proceso de creación del servidor da error y aparece un mensaje parecido a "The requested configuration is currently not supported. Please check the documentation for supported configurations".

Causa: puede que se haya especificado un tipo de instancia no admitido en el nodo maestro de Puppet. Si decide crear el servidor de Puppet en una VPC que tenga una tenencia no predeterminada, como una tenencia para instancias dedicadas, todas las instancias del interior de la VPC especificada tienen que estar asociadas a una tenencia dedicada o de host. Dado que algunos tipos de instancias, como las t2, solo están disponibles con tenencias predeterminadas, puede que la VPC especificada no admita el tipo de instancia de nodo maestro de Puppet y que se produzca un error en la creación del servidor.

Solución: si elige una VPC con tenencia no predeterminada, use un tipo de instancia m4, que admita tenencias dedicadas.

No se puede crear la EC2 instancia de Amazon del servidor

Problema: No se pudo crear el servidor y apareció un mensaje de error similar al siguiente: «No se pudieron crear los siguientes recursos: [EC2Instancia]. Failed to receive 1 resource signal(s) within the specified duration".

Causa: lo más probable es que esto se deba a que la EC2 instancia no tiene acceso a la red.

Solución: asegúrese de que la instancia tenga acceso saliente a Internet y de que el agente de AWS servicio pueda emitir comandos. Asegúrese de que su VPC (una VPC con una sola subred pública) tenga DNS resolution (Resolución de DNS) habilitada y que su subred tenga la configuración Auto-assign Public IP (Asignar automáticamente IP pública) habilitada.

Un error de rol de servicio impide la creación del servidor.

Problema: la creación del servidor falla y aparece un mensaje de error que indica: «No estoy autorizado para ejecutar sts:AssumeRole».

Causa: este caso puede darse cuando el rol del servicio que utiliza no tiene los permisos suficientes para crear un servidor nuevo.

Solución: abra la OpsWorks consola de Puppet Enterprise y utilícela para generar un nuevo rol de servicio y un rol de perfil de instancia. Si prefiere utilizar su propio rol de servicio, adjunte la política de CMServiceroles de AWSOps Works al rol. Verifique que opsworks-cm.amazonaws.com aparezca entre los servicios en la lista Relaciones de confianza del rol. Compruebe que la función de servicio que está asociada a Puppet Master tenga adjunta la política de gestión de la CMServicefunción de AWSOps trabajo.

Se ha superado el límite de direcciones IP elásticas.

Problema: la creación del servidor falla y aparece un mensaje de error que indica: «No se pudieron crear los siguientes recursos: [EIP, EC2 instancia]. Resource creation cancelled, the maximum number of addresses has been reached."

Causa: este error se produce cuando su cuenta ha utilizado la cantidad máxima de direcciones IP elásticas (EIP). El límite predeterminado de direcciones EIP es cinco.

Solución: puede liberar las direcciones EIP existentes o eliminar las que su cuenta no utilice activamente, o puede ponerse en contacto con AWS Customer Support para aumentar el límite de direcciones EIP asociadas a su cuenta.

Una asociación de nodo desatendida da error.

Problema: la asociación automática o desatendida de nuevos EC2 nodos de Amazon está fallando. Nodos que debería haber añadido al nodo maestro de Puppet no aparecen en el panel de Puppet Enterprise.

Causa: esto puede ocurrir cuando no tienes un rol de IAM configurado como perfil de instancia que permita que las llamadas a la opsworks-cm API se comuniquen con nuevas EC2 instancias.

Solución: adjunta una política a tu perfil de EC2 instancia que permita trabajar con las llamadas a la DescribeNodeAssociationStatus API AssociateNode y las llamadas a la API EC2, tal y como se describe enAñadir nodos automáticamente en OpsWorks Puppet Enterprise.

Fallos en el mantenimiento del sistema

AWS OpsWorks CM realiza un mantenimiento semanal del sistema para garantizar que las últimas versiones AWS probadas de Puppet Server, incluidas las actualizaciones de seguridad, se ejecuten siempre en un OpsWorks servidor compatible con Puppet Enterprise. Si, por cualquier motivo, se produce un error en el mantenimiento del sistema, se AWS OpsWorks CM le notifica el error. Para obtener más información sobre el mantenimiento del sistema, consulte Mantenimiento del sistema en OpsWorks Puppet Enterprise.

En esta sección se describen los posibles motivos del fallo y se sugieren soluciones.

Un error en el rol de servicio o en el perfil de instancia impide el mantenimiento del sistema

Problema: el mantenimiento del sistema no funciona y aparece un mensaje de error que indica «No estoy autorizado para ejecutar el comando sts:AssumeRole» o un mensaje de error similar sobre los permisos.

Causa: esto puede ocurrir cuando el rol de servicio o el perfil de instancia que está utilizando carecen de los permisos adecuados para realizar el mantenimiento del sistema en el servidor.

Solución: asegúrese de que el rol de servicio y el perfil de instancia tengan todos los permisos necesarios.

  1. Asegúrese de que su rol de servicio tenga todos los permisos necesarios.

    1. En la página Configuración de su servidor, en Red y seguridad, seleccione el enlace correspondiente al rol de servicio que utiliza el servidor. Esto abre el rol de servicio para su visualización en la consola de IAM.

    2. En la pestaña Permisos, verifique que AWSOpsWorksCMServiceRole esté asociada al rol de servicio. Si AWSOpsWorksCMServiceRole no aparece en la lista, añada esta política al rol.

    3. Verifique que opsworks-cm.amazonaws.com aparezca entre los servicios en la lista Relaciones de confianza del rol. Para obtener más información sobre cómo usar las políticas de confianza con los roles, consulte Modificación de un rol (consola) o la entrada del blog de AWS seguridad, Cómo usar las políticas de confianza con los roles de IAM.

  2. Asegúrese de que el perfil de instancia tenga todos los permisos necesarios.

    1. En la página Configuración de su servidor, en Red y seguridad, elija el enlace para el perfil de instancia que está utilizando el servidor. Esto abre el perfil de instancia para su visualización en la consola de IAM.

    2. En la pestaña Permisos, compruebe que AmazonEC2RoleforSSM y AWSOpsWorksCMInstanceProfileRole se encuentran en la lista de políticas de permisos. Si una o ambas no aparecen en la lista, añada estas políticas administradas manualmente al rol.

    3. En la pestaña Relaciones de confianza, compruebe que el rol de servicio tenga una política de confianza que confíe en que el ec2.amazonaws.com servicio asuma las funciones en su nombre. Para obtener más información sobre cómo usar las políticas de confianza con los roles, consulte Modificación de un rol (consola) o la entrada del blog de AWS seguridad, Cómo usar las políticas de confianza con los roles de IAM.

Ayuda y soporte adicional

Si no ve su problema específico descrito en este tema o ha aplicado las sugerencias de este tema y sigue teniendo problemas, visite los foros de AWS OpsWorks.

También puede visitar el Centro de AWS Support. El AWS Support Center es el centro donde se crean y gestionan los casos de AWS Support. El AWS Support Center también incluye enlaces a otros recursos útiles, como foros, información técnica FAQs, estado del servicio y AWS Trusted Advisor.