Preguntas frecuentes

Las siguientes preguntas frecuentes proporcionan respuestas a algunas preguntas frecuentes.

¿Qué AWS OpsWorks Stacks versiones puedo migrar?

Solo puede migrar las pilas de Chef 11.10 y Chef 12, Amazon Linux, Amazon Linux 2, Ubuntu y Red Hat Enterprise Linux 7.

¿Qué versiones de Chef pueden usar mis instancias migradas?

Las instancias migradas pueden usar las versiones 11 a 14 de Chef.

nota

La migración de pilas de Windows no es compatible.

¿Qué tipos de repositorios puedo migrar?

Puede migrar los tipos de repositorios S3, Git y HTTP.

¿Puedo seguir usando un repositorio Git privado?

Sí, puede seguir usando un repositorio Git privado.

Si utilizas un GitHub repositorio privado, debes crear una nueva clave de Ed25519 host para SSH. Esto se debe a que se GitHub cambiaron las claves compatibles con SSH y se eliminó el protocolo Git no cifrado. Para obtener más información sobre la clave de Ed25519 host, consulta la entrada del GitHub blog Cómo mejorar la seguridad del protocolo Git en GitHub. Tras generar una nueva clave de Ed25519 host, cree un SecureString parámetro de Systems Manager para esta clave SSH y utilice el nombre del parámetro como valor del --repo-private-key parámetro. Para obtener más información sobre cómo crear un SecureString parámetro de Systems Manager, consulte Crear un SecureString parámetro (AWS CLI) en la Guía del AWS Systems Manager usuario.

Para cualquier otro tipo de repositorio de Git, cree un SecureString parámetro de Systems Manager para esta clave SSH y utilice el nombre del parámetro como valor para el --repo-private-key parámetro del script.

¿Qué claves SSH puedo usar para acceder a mis instancias?

Al ejecutar el script, este migra las claves SSH y las instancias configuradas en la pila. Puede usar las claves SSH para acceder a su instancia. Si se proporcionan claves SSH para la pila y la instancia, el script usa las claves de la pila. Si no está seguro de qué claves SSH debe utilizar, consulte las instancias en la consola EC2 (https://console.aws.amazon.com/ec2/). La página de detalles de la consola EC2 muestra las claves SSH de la instancia.

¿Por qué mis instancias se amplían y reducen automáticamente?

Escalado automático escala las instancias en función de las reglas de escalado del grupo de escalado automático. Puede establecer los valores de capacidad mínima, máxima y deseada para su grupo. El grupo de escalado automático escala automáticamente su capacidad en consecuencia cuando actualiza estos valores.

¿Puedo desactivar escalado automático?

Puede desactivar escalado automático configurando los valores de capacidad mínima, máxima y deseada del grupo de escalado automático en el mismo número. Por ejemplo, si quiere tener siempre diez instancias, establezca los valores de capacidad mínima, máxima y deseada en diez.

¿Puedo actualizar el núcleo y los paquetes en las instancias EC2 lanzadas?

De forma predeterminada, las actualizaciones del núcleo y los paquetes se producen cuando se inicia la instancia EC2. Siga estos pasos para actualizar el núcleo o el paquete en una instancia EC2 lanzada. Por ejemplo, es posible que desee aplicar actualizaciones después de ejecutar, implementar o configurar recetas.

1. Conéctese a la instancia EC2.

2. Cree la siguiente perform_upgrade función y ejecútela en su instancia.

   perform_upgrade() {
       #!/bin/bash
       if [ -e '/etc/system-release' ] || [ -e '/etc/redhat-release' ]; then
        sudo yum -y update
       elif [ -e '/etc/debian_version' ]; then
        sudo apt-get update
        sudo apt-get dist-upgrade -y
       fi
   }
   perform_upgrade

3. Una vez que se hayan actualizado el núcleo y el paquete, es posible que deba reiniciar la instancia EC2. Para comprobar si es necesario reiniciar, cree la siguiente reboot_if_required función y ejecútela en la instancia EC2.

   reboot_if_required () {
    #!/bin/bash
    if [ -e '/etc/debian_version' ]; then
      if [ -f /var/run/reboot-required ]; then
        echo "reboot is required"
      else
        echo "reboot is not required"
      fi
    elif [ -e '/etc/system-release' ] || [ -e '/etc/redhat-release' ]; then
     export LC_CTYPE=en_US.UTF-8
     export LC_ALL=en_US.UTF-8
     LATEST_INSTALLED_KERNEL=`rpm -q --last kernel | perl -X -pe 's/^kernel-(\S+).*/$1/' | head -1`
     CURRENTLY_USED_KERNEL=`uname -r`
     if [ "${LATEST_INSTALLED_KERNEL}" != "${CURRENTLY_USED_KERNEL}" ];then
        echo "reboot is required"
     else
        echo "reboot is not required"
     fi
    fi
   }
   reboot_if_required            

4. Si ejecuta los reboot_if_required resultados en un reboot is required mensaje, reinicie la instancia EC2. Si recibe un reboot is not required mensaje, no necesita reiniciar la instancia EC2.

¿Por qué los volúmenes de EBS de mis instancias no contienen ningún dato?

Al ejecutar el script, este migra la configuración de los volúmenes de EBS y crea una arquitectura sustitutiva para la OpsWorks pila y la capa. El script no migra las instancias reales ni los datos contenidos en las instancias. El script solo migra la configuración de los volúmenes de EBS a nivel de capa y adjunta los volúmenes de EBS vacíos a las instancias de EC2 lanzadas.

Siga los siguientes pasos para extraer datos de los volúmenes de EBS de las instancias anteriores.

1. Cree una instantánea de los volúmenes de EBS de instancias anteriores. Para obtener más información acerca de la creación de una instantánea, consulte Creación de una instantánea de Amazon EBS en la Guía del usuario de Amazon EC2.

2. Crear un volumen a partir de una instantánea Para obtener más información sobre la creación de un volumen a partir de una instantánea, consulte Crear un volumen a partir de una instantánea en la Guía del usuario de Amazon EC2.

3. Vuelva a adjuntar el volumen que ha creado a la instancia. Para obtener más información, consulte Adjuntar un volumen de Amazon EBS a una instancia en la Guía del usuario de Amazon EC2.

¿Por qué no están montados los volúmenes de EBS descritos en mi plantilla de lanzamiento?

Si proporciona un identificador de plantilla de lanzamiento para el --launch-template parámetro de los volúmenes de EBS, el script adjunta los volúmenes de EBS, pero no los monta. Puede montar los volúmenes de EBS adjuntos ejecutando el MountEBSVolumes RunCommand documento que el script creó para la instancia de EC2 lanzada.

Si no establece ningún parámetro --launch-template, el script crea una plantilla y, cuando el grupo de escalado automático lanza una nueva instancia EC2, el grupo de escalado automático adjunta automáticamente los volúmenes EBS y, a continuación, ejecuta el comando SetupAutomation para montar los volúmenes adjuntos en los puntos de montaje configurados en la configuración de la capa.

¿Dónde puedo encontrar la receta Chef y los registros de volúmenes Mount EBS?

OpsWorks entrega los registros a un depósito de S3 que puede especificar proporcionando un valor para el --command-logs-bucket parámetro. El nombre predeterminado del bucket de S3 tiene el formato: aws-opsworks-stacks-application-manager-logs-account-id. Los registros de recetas de Chef se almacenan en el ApplyChefRecipes prefijo. Los registros de volumen de Mount EBS se almacenan en el MountEBSVolumes prefijo. Todas las capas que se migran de una pila entregan los registros al mismo bucket de S3.

nota

• La configuración del ciclo de vida del bucket de S3 incluye una regla para eliminar los registros después de 30 días. Si desea conservar los registros durante más de 30 días, debe actualizar la regla en la configuración del ciclo de vida del bucket de S3.

• Actualmente, OpsWorks solo registra Chef setup y terminate recetas.

¿Dónde puedo encontrar el registro de depuración del script de migración?

El script coloca los registros de depuración en un bucket denominado aws-opsworks-stacks-transition-logs-account-id. Puede encontrar los registros de depuración en la migration_script carpeta del bucket de S3, en las carpetas que coinciden con el nombre de la capa que ha migrado.

¿El script de migración admite el control CloudFormation de versiones de plantillas?

El script genera documentos del tipo Systems Manager CloudFormation que sustituyen a la capa o pila que se desea migrar. Al volver a ejecutar el script, incluso con los mismos parámetros, se exporta una nueva versión de la plantilla de capa exportada anteriormente. Las versiones de la plantilla se almacenan en el mismo bucket de S3 que los registros del script.

¿Puedo migrar varias capas?

El --layer-id parámetro del script pasa a una sola capa. Para migrar varias capas, vuelva a ejecutar el script y pase una diferente --layer-id.

Las capas que forman parte de la misma OpsWorks pila se muestran en la misma aplicación en Application Manager.

1. Abra la consola de Systems Manager en https://console.aws.amazon.com/systems-manager/.

2. En el panel de navegación, elija Aplicaciones.

3. En la sección Aplicaciones, elija Aplicaciones personalizadas.

4. Elija su aplicación. El nombre de la aplicación comienza por app-stack-name-first-six-characters-stack-id.

5. El elemento de nivel superior, que comienza por la aplicación, muestra todos los componentes que corresponden a su OpsWorks pila. Esto incluye los componentes correspondientes a su OpsWorks capa.

6. Elija el componente correspondiente a la capa para ver los recursos de la capa. Los componentes que representan OpsWorks las capas también están visibles en la sección de aplicaciones personalizadas como aplicaciones individuales.

¿Cómo creo un SecureString parámetro?

Puede usar Systems Manager para crear un SecureString parámetro. Para obtener más información sobre cómo crear un SecureString parámetro de Systems Manager, consulte Crear un SecureString parámetro (AWS CLI) o Crear un parámetro de Systems Manager (consola) en la Guía del AWS Systems Manager usuario.

Debe proporcionar un parámetro SecureString como valor para los parámetros --http-username, --http-password, o --repo-private-key.

¿Cómo puedo proteger las instancias del nuevo grupo de escalado automático de los eventos de terminación?

Puede proteger las instancias configurando el --enable-instance-protection parámetro TRUE y añadiendo una clave de protected_instance etiqueta a cada instancia de EC2 que desee proteger de los eventos de terminación. Cuando configura el --enable-instance-protection parámetro en una clave de protected_instance etiqueta TRUE y la agrega, el script agrega una política de terminación personalizada a su nuevo grupo de escalado automático y suspende el ReplaceUnhealthy proceso. Las instancias con la clave de protected_instance etiqueta están protegidas de los siguientes eventos de terminación:

• Eventos de reducción horizontal

• Actualización de instancias

• Reequilibrio

• Duración del almacén de instancias

• Permitir la terminación de instancias de listados

• Terminación y reemplazo de instancias en mal estado

nota

Debe configurar la clave de protected_instance etiqueta en las instancias que desee proteger. La clave distingue entre mayúsculas y minúsculas. Cualquier instancia con esa clave de etiqueta está protegida independientemente del valor de la etiqueta.

Para reducir el tiempo de ejecución de la política de terminación personalizada, puede aumentar el número predeterminado de instancias que utiliza la función de Lambda para filtrar las instancias protegidas actualizando el valor de la variable de default_sample_size código de la función. El valor predeterminado es 15. Si aumenta default_sample_size, es posible que necesite aumentar la memoria asignada a la función de Lambda, lo que aumentaría el costo de la función de Lambda. Para obtener más información acerca de los precios de AWS Lambda , consulte Precios de AWS Lambda.

¿Qué equilibradores de carga están disponibles con el script de migración?

El script ofrece tres opciones de equilibrador de carga.

• (Recomendado) Cree un nuevo Equilibrador de carga de aplicación. De forma predeterminada, el script crea un nuevo Equilibrador de carga de aplicación. También puede configurar el parámetro --lb-type para ALB. Para obtener más información sobre equilibradores de carga de aplicación, consulte ¿Qué es un equilibrador de carga de aplicación? en la Guía del usuario de equilibradores de carga elásticos.

• Si un Equilibrador de carga de aplicación no es una opción, cree un Equilibrador de carga clásico configurando el parámetro --lb-type en. Classic Si selecciona esta opción, el Classic Load Balancer existente adjunto a la OpsWorks capa se mantiene separado de la aplicación. Para obtener más información sobre equilibradores de carga de aplicación, consulte ¿Qué es un equilibrador de carga clásico? en la Guía del usuario de equilibradores de carga elásticos: equilibradores de carga clásicos.

• Puede adjuntar un equilibrador de carga de cargas existente configurando --lb-type el parámetro en None.

  importante

  Recomendamos crear nuevos balanceadores de carga de Elastic Load Balancing para las capas de AWS OpsWorks Stacks. Si decide utilizar un equilibrador de carga Elastic Load Balancing existente, primero debe confirmar que no se utiliza para otros fines y que no tiene instancias asociadas. Una vez que el balanceador de carga esté conectado a la capa, OpsWorks elimina todas las instancias existentes y configura el balanceador de carga para que gestione solo las instancias de la capa. Aunque es técnicamente posible utilizar la consola o la API de Elastic Load Balancing para modificar la configuración de un equilibrador de carga después de adjuntarlo a una capa, no debería hacerlo; los cambios no serán permanentes.

Para adjuntar tu balanceador de cargas de OpsWorks capas existente a tu grupo de Auto Scaling

1. Ejecute el script de migración con el --lb-type parámetro establecido en None. Cuando el valor se establece en None, el script no clona ni crea un equilibrador de carga.

2. Una vez que el script despliegue la CloudFormation pila, actualice los grupos Min Max y Desired capacity valores de Auto Scaling y, a continuación, pruebe la aplicación.

3. Elija Link to the template que se muestra en la salida del script. Si ha cerrado su terminal, siga estos pasos para acceder a la plantilla.

   1. Abra la consola de Systems Manager en https://console.aws.amazon.com/systems-manager/.

   2. En el panel de navegación, elija Aplicaciones.

   3. Elija CloudFormation pilas y, a continuación, elija la biblioteca de plantillas.

   4. Elija De mi propiedad y localice su plantilla.

4. En la CloudFormation plantilla, selecciona Editar en el menú Acciones.

5. Actualice la LabelBalancerNames propiedad en la sección de ApplicationAsg recursos de la CloudFormation plantilla.

   ApplicationAsg:
      DependsOn: CustomTerminationLambdaPermission
      Properties:
      #(other properties in ApplicationAsg to remain unchanged)
         LoadBalancerNames:
           - load-balancer-name 
         HealthCheckType: ELB
                       

6. Si quiere que la comprobación de estado de las instancias de grupo de escalado automático también utilice la comprobación del estado del equilibrador de carga, elimina la siguiente sección HealthCheckType e ingresaELB. Si solo necesita comprobaciones de estado de EC2, no necesita cambiar la plantilla.

7. Guarde los cambios. Al guardar, se crea una nueva versión predeterminada de la plantilla. Si es la primera vez que ejecuta el script de la capa y la primera vez que guarda los cambios en la consola, la versión más reciente es la 2.

8. En Acciones, seleccione Aprovisionar pila.

9. Confirme que desea utilizar la versión predeterminada de la plantilla. Asegúrese de seleccionar la opción Seleccionar una pila existente y elija la CloudFormation pila que desee actualizar.

10. Elija Siguiente en cada una de las páginas siguientes hasta que aparezca la página de revisión y aprovisionamiento. En la página Revisar y aprovisionar, elija las dos opciones. Reconozco que se AWS CloudFormation podrían crear recursos de IAM con nombres personalizados y entiendo que los cambios en la plantilla seleccionada pueden AWS CloudFormation provocar la actualización o la eliminación de AWS los recursos existentes.

11. Elija Aprovisionar pilas.

Si necesita revertir las actualizaciones, siga estos pasos.

1. Elija Acciones y, a continuación, elija Eliminar pila.

2. Elija Elija una de las versiones existentes y, a continuación, elija la versión de plantilla anterior.

3. Seleccione una pila existente y, a continuación, elija la CloudFormation pila que desee actualizar.

¿Se migran las recetas configuradas a medida?

Los libros de recetas personalizados no se pueden ejecutar durante un evento de configuración. La secuencia de comandos migra las recetas de configuración del libro de cocina personalizado y crea un manual de procedimientos de Systems Manager para usted. Sin embargo, debe ejecutar las recetas manualmente.

Siga estos pasos para ejecutar las recetas de configuración.

1. Abra la consola de Systems Manager en https://console.aws.amazon.com/systems-manager/.

2. En el panel de navegación, elija Aplicaciones.

3. En la sección Aplicaciones, elija Aplicaciones personalizadas.

4. Elija su aplicación. El nombre de la aplicación comienza por app-stack-name.

5. Elija Recursos y, a continuación, elija el manual de procedimientos.

6. Elija Ejecutar automatización.

7. Elija los ID de instancia para los que quiere ejecutar las recetas de configuración y, a continuación, elija Ejecutar.

¿Puedo ejecutar recetas de despliegue y desdespliegue en mis instancias recién creadas?

El script puede crear tres posibles manuales de procedimientos en función de la configuración de la capa.

• Configuración

• Configuración

• Finalizar

El script también puede crear los siguientes parámetros de Systems Manager que contienen valores de entrada para el AWS-ApplyChefRecipes Run Command documento.

• Configuración

• Implementación

• Configuración

• Undeploy

• Finalizar

Cuando se produce un evento de escalado horizontal, el manual de procedimientos de la configuración se ejecuta automáticamente. Esto incluye la configuración y el despliegue de recetas de libros de cocina personalizadas desde la OpsWorks capa original. Cuando se produce un evento de escalado, el manual de procedimientos de finalización se ejecuta automáticamente. El manual de finalización de Automation contiene las recetas de apagado de la capa original OpsWorks .

Si desea ejecutar, anular la implementación o configurar recetas manualmente, siga estos pasos.

1. Abra la consola de Systems Manager en https://console.aws.amazon.com/systems-manager/.

2. En el panel de navegación, elija Aplicaciones.

3. En la sección Aplicaciones, elija Aplicaciones personalizadas.

4. Elija su aplicación. El nombre de la aplicación comienza por app-stack-name-first-six-characters-stack-id. El administrador de aplicaciones abre la pestaña Descripción general.

5. Elija Recursos y, a continuación, elija el manual de procedimientos de automatización.

6. Elija Ejecutar automatización.

7. Para el parámetro de entrada del manual de procedimientos de applyChefRecipesPropertiesParameter, consulte el parámetro de Systems Manager correcto. El nombre del parámetro de Systems Manager sigue el formato /ApplyChefRecipes-Preset/OpsWorks-stack-name-OpsWorks-layer-name-first-six-characters-stack-id/event, donde el valor para evento es Configure, Deploy, o Undeploy dependiendo de las recetas que desee ejecutar.

8. Elija los ID de instancia para los que quiere ejecutar las recetas de configuración y, a continuación, elija Ejecutar.

¿Puedo cambiar las subredes que abarca mi grupo de escalado automático?

De forma predeterminada, el grupo Auto Scaling abarca todas las subredes de la OpsWorks VPC apilada. Para actualizar las subredes que se deben abarcar, siga estos pasos.

1. Elija Link to the template que se muestra en la salida del script. Si ha cerrado su terminal, siga estos pasos para acceder a la plantilla.

   1. Abra la consola de Systems Manager en https://console.aws.amazon.com/systems-manager/.

   2. En el panel de navegación, elija Aplicaciones.

   3. Elija CloudFormation pilas y, a continuación, elija la biblioteca de plantillas.

   4. Elija De mi propiedad y localice su plantilla.

2. En Acciones, seleccione Pila de aprovisionamiento.

3. Confirme que desea utilizar la versión predeterminada de la plantilla. Selecciona Selecciona una pila existente y, a continuación, elige la CloudFormation pila que deseas actualizar.

   nota

   Si ejecutó el script con el --provision-application parámetro establecido enFALSE, debe crear una CloudFormation pila nueva.

4. Para el SubnetIDs parámetro, proporcione una lista separada por comas de los ID de subred que desee que abarque su grupo de escalado automático.

5. Seleccione Siguiente hasta que aparezca la página de revisión y aprovisionamiento.

6. En la página Revisar y aprovisionar, seleccione Acepto que AWS CloudFormation podría crear recursos de IAM con nombres personalizados y entiendo que los cambios en la plantilla seleccionada pueden AWS CloudFormation provocar la actualización o la eliminación de AWS los recursos existentes.

7. Elija Aprovisionar pilas.