Stacks de solución de problemas AWS OpsWorks

importante

El AWS OpsWorks Stacks servicio llegó al final de su vida útil el 26 de mayo 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.

Esta sección contiene algunos de los problemas más frecuentes de AWS OpsWorks Stacks y sus soluciones.

No se pueden administrar instancias

Problema: ya no puede administrar una instancia que anteriormente había podido administrar. En algunos casos, los registros pueden mostrar un error similar al siguiente.

Aws::CharlieInstanceService::Errors::UnrecognizedClientException - The security token included in the request is invalid.

Causa: esto puede ocurrir si se ha editado o eliminado un recurso externo a AWS OpsWorks del que depende la instancia. A continuación se proporcionan ejemplos de cambios de recursos que pueden interrumpir la comunicación con una instancia.

• Se ha eliminado accidentalmente un usuario o rol de IAM asociado a la instancia, fuera de AWS OpsWorks Stacks. Esto provoca un error de comunicación entre el AWS OpsWorks agente que está instalado en la instancia y el servicio AWS OpsWorks Stacks. Los usuarios de que estén asociados con una instancia deben existir durante toda la vida de la instancia.

• Si se edita la configuración de volumen o de almacenamiento mientras la instancia está sin conexión puede que esta deje de poder administrarse.

• Agregar instancias EC2 a un ELB de forma manual. AWS OpsWorks reconfigura un balanceador de cargas de Elastic Load Balancing asignado cada vez que una instancia entra o sale del estado en línea. AWS OpsWorks solo considera las instancias que conoce como miembros válidos; las instancias que se agregan fuera del AWS OpsWorks proceso o mediante algún otro proceso se eliminan. Las demás instancias se eliminan.

Solución: no elimine los usuarios o los roles de IAM de los que dependen sus instancias. Si es posible, edite las configuraciones de volumen o de almacenamiento mientras se ejecutan las instancias dependientes. Se usa AWS OpsWorks para administrar el balanceador de carga o las membresías a EIP de las instancias. AWS OpsWorks Cuando se registra una instancia, para evitar problemas de administración de las instancias registradas en caso de que el usuario se elimine por error, añada el parámetro --use-instance-profile al comando register para utilizar en su lugar el perfil de instancia integrada de la instancia.

Después de ejecutar Chef, las instancias no arrancan

Problema: en Chef 11.10 o en pilas más antiguas configuradas para utilizar libros de recetas personalizados, después de ejecutar Chef con libros de recetas de la comunidad, las instancias no arrancan. Los mensajes de registro pueden indicar que las recetas no se han compilado (error de compilación de recetas) o que no se pueden cargar porque no encuentran ninguna dependencia.

Causa: la causa más probable es que el libro de recetas personalizado o de la comunidad no admita la versión de Chef que utiliza su pila. Algunos libros de recetas populares de la comunidad, como apt y build-essential, tienen problemas de compatibilidad con Chef 11.10.

Solución: en las AWS OpsWorks pilas de pilas que tengan activada la opción Usar libros de cocina personalizados de Chef, los libros de cocina personalizados o comunitarios siempre deben ser compatibles con la versión de Chef que utilice la pila. Adjunte los libros de recetas de la comunidad a una versión (es decir, defina el número de versión del libro de recetas con una versión concreta) que sea compatible con la versión de Chef que está configurada en la configuración de la pila. Para encontrar una versión de libro de recetas de la comunidad compatible, consulte el registro de cambios de un libro de recetas cuya compilación haya fallado y utilice solo la versión más reciente del libro de recetas que admita su pila. Para adjuntar una versión de libro de recetas, especifique un número de versión exacto en el archivo Berksfile del repositorio de su libro de recetas personalizado. Por ejemplo, cookbook 'build-essential', '= 3.2.0'.

Todas las instancias de una capa dan error en la comprobación de estado del equilibrador de carga elástica

Problema: adjunta un equilibrador de carga de a una capa de servidor de aplicaciones, pero todas las instancias dan error en la comprobación de estado.

Causa: al crear un equilibrador de carga de debe especificar la ruta de ping que llama el equilibrador de carga para determinar si el estado de la instancia es correcto. Asegúrese de especificar una ruta de ping adecuada para su aplicación. El valor predeterminado es /index.html. Si la aplicación no incluye un valor index.html, debe especificar una ruta adecuada o la comprobación de estado fallará. Por ejemplo, la aplicación SimplePHPApp que se utiliza en Introducción a las pilas de Linux en Chef 11 no usa index.html. La ruta de ping adecuada para dichos servidores es /.

Solución: edite la ruta de ping del balanceador de carga. Para obtener más información, consulte Elastic Load Balancing

No se puede comunicar con un equilibrador de carga

Problema: crea un equilibrados de carga de y lo adjunta a una capa de servidor de aplicaciones, pero al hacer clic en el nombre de DNS o en la dirección IP del equilibrador de carga para ejecutar la aplicación recibe un error que indica que el servidor remoto no responde.

Causa: si la pila se ejecuta en una VPC predeterminada, al crear un equilibrador de carga de en la región, debe especificar un grupo de seguridad. El grupo de seguridad debe tener reglas de entrada que permitan el tráfico entrante desde su dirección IP. Si especifica default VPC security group (grupo de seguridad de VPC predeterminado), la regla de entrada predeterminada no aceptará el tráfico entrante.

Solución: edite las reglas de entrada del grupo de seguridad para que permitan el tráfico entrante desde direcciones IP adecuadas.

1. Haga clic en Security Groups en el panel de navegación de la consola de Amazon EC2.

2. Seleccione el grupo de seguridad del balanceador de carga.

3. Haga clic en Edit (Editar) en la pestaña Inbound (Entrada).

4. Añada una regla de entrada con el campo Source (Fuente) establecido en un CIDR adecuado.

   Por ejemplo, si se especifica Anywhere (Cualquier lugar), el CIDR se establece en 0.0.0.0/0, lo que hace que el balanceador de carga acepte el tráfico entrante desde cualquier dirección IP.

Una instancia on-premises importada no consigue finalizar la configuración de volumen tras un reinicio

Problema: reinicias una instancia de EC2 que has importado a AWS OpsWorks Stacks y la consola de Stacks muestra el AWS OpsWorks estado de la instancia como error. Esto puede ocurrir en instancias de Chef 11 o Chef 12.

Causa: es posible que AWS OpsWorks Stacks no pueda adjuntar un volumen a la instancia durante el proceso de configuración. Un motivo de ello puede ser que AWS OpsWorks Stacks sobrescriba la configuración de volumen en la instancia al ejecutar el comando setup.

Solución: abra la página Details (Detalles) de la instancia y compruebe la configuración del volumen en el área Volumes (Volúmenes). Tenga en cuenta que solo puede cambiar la configuración de volumen cuando la instancia está en estado stopped (detenido). Asegúrese de que cada volumen tiene un punto de montaje y un nombre especificados. Confirma que proporcionaste el punto de montaje correcto en tu configuración de AWS OpsWorks Stacks antes de reiniciar la instancia.

Un volumen de EBS no vuelve a adjuntarse tras reiniciar

Problema: utiliza la consola de Amazon EC2 para adjuntar un volumen de Amazon EBS a una instancia, pero al reiniciar la instancia, el volumen ya no aparece adjunto.

Causa: AWS OpsWorks Stacks solo puede volver a adjuntar los volúmenes de Amazon EBS que conozca, que se limitan a lo siguiente:

• Volúmenes creados por Stacks. AWS OpsWorks

• Los volúmenes de su cuenta y que ha registrado de forma explícita con una pila desde la página Resources (Recursos).

Solución: administre sus volúmenes de Amazon EBS únicamente mediante la consola, la API o la CLI de AWS OpsWorks Stacks. Si desea utilizar uno de los volúmenes de de su cuenta con una pila, utilice la página Recursos de la pila para registrar el volumen y adjuntarlo a una instancia. Para obtener más información, consulte Administración de recursos.

No se pueden eliminar grupos de seguridad de AWS OpsWorks Stacks

Problema: después de eliminar una pila, quedan varios grupos de seguridad de AWS OpsWorks Stacks que no se pueden eliminar.

Causa: los grupos de seguridad deben eliminarse en un orden concreto.

Solución: en primer lugar, asegúrese de que ninguna instancia utilice los grupos de seguridad. A continuación, elimine cualquiera de los siguientes grupos de seguridad, si existen, en el orden que se indica a continuación:

1. Servidor AWS- OpsWorks -Blank-Server

2. Servidor maestro de monitoreo OpsWorks de AWS

3. Servidor AWS OpsWorks -DB-Master

4. Servidor AWS - OpsWorks Memcache

5. AWS: servidor OpsWorks personalizado

6. Servidor de aplicaciones AWS - OpsWorks NodeJS

7. Servidor de aplicaciones PHP OpsWorks de AWS

8. Servidor de aplicaciones AWS- OpsWorks -Rails

9. Servidor web OpsWorks AWS

10. Servidor predeterminado de OpsWorks AWS

11. Servidor AWS- OpsWorks -LB

Eliminó accidentalmente un grupo de seguridad de AWS OpsWorks Stacks

Problema: has eliminado uno de los grupos de seguridad de AWS OpsWorks Stacks y necesitas volver a crearlo.

Causa: estos grupos de seguridad suelen eliminarse por error.

Solución: el grupo que se cree de nuevo debe ser un duplicado exacto del original, usando las mismas mayúsculas y minúsculas en el nombre del grupo. En lugar de volver a crear el grupo manualmente, se recomienda que AWS OpsWorks Stacks realice esta tarea. Solo tiene que crear una pila nueva en la misma región de AWS (y en la VPC, si existe AWS OpsWorks ) y Stacks volverá a crear automáticamente todos los grupos de seguridad integrados, incluido el que haya eliminado. Después podrá borrar la pila si ya no la va a usar más; los grupos de seguridad permanecerán.

El registro de Chef terminada bruscamente

Problema: un registro de Chef termina bruscamente. El final del registro no indica si se ha ejecutado correctamente ni muestra una excepción ni un rastro de la pila.

Causa: esto suele ocurrir cuando falta memoria.

Solución: cree una instancia más grande y utilice el comando run_command del agente de la CLI para ejecutar las recetas de nuevo. Para obtener más información, consulte Ejecución de recetas.

El libro de recetas no se actualiza

Problema: actualizó su libro de recetas, pero las instancias de la pila siguen ejecutándose con las recetas antiguas.

Causa: AWS OpsWorks Stacks almacena en caché los libros de cocina en cada instancia y ejecuta las recetas desde la caché, no desde el repositorio. Cuando inicias una nueva instancia, AWS OpsWorks Stacks descarga tus libros de cocina del repositorio a la caché de la instancia. No obstante, si posteriormente modifica sus libros de recetas personalizados, AWS OpsWorks Stacks no actualizará automáticamente las memorias caché de las instancias online.

Solución: ejecuta el comando Update Cookbooks stack para indicar explícitamente a AWS OpsWorks Stacks que actualice las cachés de libros de cocina de tus instancias online.

Las instancias se bloquean en el estado de arranque

Problema: al reiniciar una instancia o si la recuperación automática la reinicia automáticamente, la operación de reinicio se bloquea en el estado booting.

Causa: una posible causa de este problema es la configuración de la VPC, también la de una VPC predeterminada. Las instancias siempre deben poder comunicarse con el servicio AWS OpsWorks Stacks, Amazon S3 y los repositorios de paquetes, libros de cocina y aplicaciones. Si, por ejemplo, eliminas una puerta de enlace predeterminada de una VPC predeterminada, las instancias pierden la conexión con el servicio AWS OpsWorks Stacks. Como AWS OpsWorks Stacks ya no puede comunicarse con el agente de instancias, trata la instancia como fallida y la cura automáticamente. Sin embargo, sin una conexión, AWS OpsWorks Stacks no puede instalar un agente de instancias en la instancia reparada. Sin un agente, AWS OpsWorks Stacks no puede ejecutar las recetas de configuración en la instancia, por lo que la operación de inicio no puede avanzar más allá del estado de «arranque».

Solución: modifique la configuración de la VPC de modo que las instancias tengan la conectividad necesaria.

Reinicio inesperado de las instancias

Problema: una instancia detenida se reinicia de forma inesperada.

Causa 1: si ha activado la recuperación automática para sus instancias, AWS OpsWorks Stacks realizará periódicamente una comprobación de estado en las instancias de Amazon EC2 asociadas y reiniciará las que tengan un estado incorrecto. Si detienes o cancelas una instancia AWS OpsWorks administrada por Stacks mediante la consola, la API o la CLI de Amazon EC2, no se le notificará a Stacks. AWS OpsWorks En lugar de ello, entenderá que el estado de la instancia detenida es incorrecto y la reiniciará automáticamente.

Solución: administre sus instancias solo con la consola de AWS OpsWorks Stacks, la API o CLI. Si utilizas AWS OpsWorks Stacks para detener o eliminar una instancia, no se reiniciará. Para obtener más información, consulte Proceso manual de inicio, paro y reinicio de instancias de funcionamiento ininterrumpido y Eliminar instancias AWS OpsWorks de Stacks.

Causa 2: las instancias pueden fallar por diversas razones. Si tienes habilitada la reparación automática, AWS OpsWorks Stacks reinicia automáticamente las instancias fallidas.

Solución: esta es una operación normal; no hay necesidad de hacer nada a menos que quieras que AWS OpsWorks Stacks reinicie las instancias fallidas. En ese caso, deberá desactivar la recuperación automática.

Los procesos opsworks-agent se ejecutan en instancias

Problema: se ejecutan varios procesos opsworks-agent en las instancias. Por ejemplo:

aws 24543 0.0 1.3 172360 53332 ? S Feb24 0:29 opsworks-agent: master 24543
aws 24545 0.1 2.0 208932 79224 ? S Feb24 22:02 opsworks-agent: keep_alive of master 24543
aws 24557 0.0 2.0 209012 79412 ? S Feb24 8:04 opsworks-agent: statistics of master 24543
aws 24559 0.0 2.2 216604 86992 ? S Feb24 4:14 opsworks-agent: process_command of master 24

Causa: son procesos legítimos necesarios para el funcionamiento normal del agente. Realizan tareas como la gestión de las implementaciones y el reenvío de mensajes keep-alive al servicio.

Solución: es normal. No detenga estos procesos. Si lo hace, interferirá en el buen funcionamiento del agente.

Comandos execute_recipes inesperados

Problema: la sección Logs (Registros) de la página de detalles de una instancia incluye comandos execute_recipes inesperados. Los comandos execute_recipes inesperados también pueden aparecer en las páginas Stack (Pila) y Deployments (Implementaciones).

Causa: este problema suele producirse por cambios en los permisos. Cuando cambias los permisos SSH o sudo de un usuario o grupo, AWS OpsWorks Stacks se ejecuta execute_recipes para actualizar las instancias de la pila y también activa un evento de configuración. Otro origen de aparición de comandos execute_recipes es la actualización del agente de instancia por parte de AWS OpsWorks Stacks.

Solución: esto es normal. No es necesario hacer nada.

Para ver qué acciones ha realizado un comando execute_recipes, vaya a la página Deployments (Implementaciones) y haga clic en la marca temporal del comando. Esto abre la página de detalles del comando, que enumera las principales recetas que se han ejecutado. Por ejemplo, la siguiente página de detalles es de un comando execute_recipes que ha ejecutado ssh_users para actualizar los permisos de SSH.

Para ver todos los detalles, haga clic en show (mostrar) en la columna Log (Registro) del comando para consultar el registro de Chef asociado. Busca en el registro. Run List AWS OpsWorks Las recetas de mantenimiento de Stacks estarán debajoOpsWorks Custom Run List. Por ejemplo, a continuación se ve la lista para ejecutar el comando execute_recipes que aparece en la imagen anterior y que muestra cada receta asociada con el comando.

[2014-02-21T17:16:30+00:00] INFO: OpsWorks Custom Run List: ["opsworks_stack_state_sync",
  "ssh_users", "test_suite", "opsworks_cleanup"]