Ejecución de una pila en una VPC - 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.

Ejecución de una pila en una VPC

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.

Para controlar el acceso de los usuarios a las instancias de la pila, puede crearla en una nube virtual privada (VPC). Por ejemplo, es posible que no quiera que los usuarios accedan directamente a los servidores de aplicaciones o a las bases de datos de la pila y que, en lugar de eso, todo el tráfico público se canalice a través de un Elastic Load Balancer.

A continuación, se describe el procedimiento básico para ejecutar una pila en una VPC:

  1. Crear una VPC y configurarla de la forma adecuada, ya sea mediante la consola de Amazon VPC o la API, o con una plantilla de AWS CloudFormation .

  2. Especificar el ID de la VPC al crear la pila.

  3. Lanzar las instancias de la pila en la subred correcta.

A continuación, se describe brevemente cómo funcionan las VPC en AWS OpsWorks Stacks.

importante

Si utiliza la característica de punto de conexión de VPC, tenga en cuenta que todas las instancias de la pila deberán poder completar las siguientes acciones en (Amazon Simple Storage Service (Amazon S3):

  • Instalar el agente de la instancia.

  • Instalar recursos, como Ruby.

  • Cargar los registros de ejecución de Chef.

  • Recuperar los comandos de pila.

Para habilitar estas acciones, asegúrese de que las instancias de la pila tengan acceso a los siguientes buckets, coincidentes con la región de la pila. De lo contrario, las acciones anteriores devolverán un error.

En el caso de Chef 12 para Linux y Chef 12.2; para Windows, los buckets son los siguientes:

Buckets de agente Buckets de recursos Buckets de registros Buckets de ADN
  • opsworks-instance-agent-sa-east-1

  • opsworks-instance-agent-ap-sur-1

  • opsworks-instance-agent-ap-nordeste-1

  • opsworks-instance-agent-ap-nordeste-2

  • opsworks-instance-agent-ap-sudeste-1

  • opsworks-instance-agent-ap-sudeste-2

  • opsworks-instance-agent-ca-central-1

  • opsworks-instance-agent-eu-central-1

  • opsworks-instance-agent-eu-oeste-1

  • opsworks-instance-agent-eu-oeste-2

  • opsworks-instance-agent-eu-oeste-3

  • opsworks-instance-agent-us-este-1

  • opsworks-instance-agent-us-este-2

  • opsworks-instance-agent-us-oeste-1

  • opsworks-instance-agent-us-oeste-2

  • opsworks-instance-assets-us-este-2

  • opsworks-instance-assets-us-este-1

  • opsworks-instance-assets-ap-sur-1

  • opsworks-instance-assets-ap-nordeste-1

  • opsworks-instance-assets-ap-nordeste-2

  • opsworks-instance-assets-ap-sudeste-1

  • opsworks-instance-assets-ap-sudeste-2

  • opsworks-instance-assets-ca-central-1

  • opsworks-instance-assets-eu-central-1

  • opsworks-instance-assets-eu-oeste-1

  • opsworks-instance-assets-eu-oeste-2

  • opsworks-instance-assets-eu-oeste-3

  • opsworks-instance-assets-sa-este-1

  • opsworks-instance-assets-us-oeste-1

  • opsworks-instance-assets-us-oeste-2

  • opsworks-us-east-2 troncos

  • opsworks-us-east-1 registro

  • opsworks-ap-south-1-registro

  • opsworks-ap-northeast-1-registro

  • opsworks-ap-northeast-2 registros

  • opsworks-ap-southeast-1 registro

  • opsworks-ap-southeast-2 registros

  • opsworks-ca-central-1 registro

  • opsworks-eu-central-1-registro

  • opsworks-eu-west-1-registro

  • opsworks-eu-west-2 registros

  • opsworks-eu-west-3 registros

  • opsworks-sa-east-1 registro

  • opsworks-us-west-1-registro

  • opsworks-us-west-2 registros

  • opsworks-us-east-2-ADN

  • opsworks-us-east-1-ADN

  • opsworks-ap-south-1-ADN

  • opsworks-ap-northeast-1-ADN

  • opsworks-ap-northeast-2-ADN

  • opsworks-ap-southeast-1-ADN

  • opsworks-ap-southeast-2-ADN

  • opsworks-ca-central-1-ADN

  • opsworks-eu-central-1-ADN

  • opsworks-eu-west-1-ADN

  • opsworks-eu-west-2-ADN

  • opsworks-eu-west-3-ADN

  • opsworks-sa-east-1-ADN

  • opsworks-us-west-1-ADN

  • opsworks-us-west-2-ADN

En el caso de Chef 11.10 y versiones anteriores para Linux, los buckets se enumeran a continuación. Las pilas de Chef 11.4 no son compatibles con los puntos de enlace regionales fuera de la región Región Este de EE. UU. (Norte de Virginia).

Buckets de agente Buckets de recursos Buckets de registros Buckets de ADN
  • opsworks-instance-agent-us-este-2

  • opsworks-instance-agent-us-este-1

  • opsworks-instance-agent-ap-sur-1

  • opsworks-instance-agent-ap-nordeste-1

  • opsworks-instance-agent-ap-nordeste-2

  • opsworks-instance-agent-ap-sudeste-1

  • opsworks-instance-agent-ap-sudeste-2

  • opsworks-instance-agent-ca-central-1

  • opsworks-instance-agent-eu-central-1

  • opsworks-instance-agent-eu-oeste-1

  • opsworks-instance-agent-eu-oeste-2

  • opsworks-instance-agent-eu-oeste-3

  • opsworks-instance-agent-us-este-1

  • opsworks-instance-agent-us-oeste-1

  • opsworks-instance-agent-us-oeste-2

  • opsworks-instance-assets-us-este-2

  • opsworks-instance-assets-us-este-1

  • opsworks-instance-assets-ap-sur-1

  • opsworks-instance-assets-ap-nordeste-1

  • opsworks-instance-assets-ap-nordeste-2

  • opsworks-instance-assets-ap-sudeste-1

  • opsworks-instance-assets-ap-sudeste-2

  • opsworks-instance-assets-ca-central-1

  • opsworks-instance-assets-eu-central-1

  • opsworks-instance-assets-eu-oeste-1

  • opsworks-instance-assets-eu-oeste-2

  • opsworks-instance-assets-eu-oeste-3

  • opsworks-instance-assets-sa-este-1

  • opsworks-instance-assets-us-oeste-1

  • opsworks-instance-assets-us-oeste-2

  • prod_stage-log

  • prod_stage-dna

Para obtener más información, consulte Puntos de enlace de la VPC.

nota

Para que AWS OpsWorks Stacks se conecte a los puntos de enlace de VPC que habilite, también debe configurar el enrutamiento para su NAT o IP pública, ya que AWS OpsWorks el agente de Stacks aún necesita acceder al punto de enlace público.

Conceptos básicos de la VPC

Para ver una explicación detallada de las VPC, consulte Amazon Virtual Private Cloud. En resumen, una VPC está compuesta por una o varias subredes, cada una de las cuales contiene una o varias instancias. Cada subred tiene una tabla de direccionamiento asociada que dirige el tráfico saliente en función de la dirección IP de destino.

  • De manera predeterminada, las instancias de una VPC pueden comunicarse entre sí con independencia de la subred. Sin embargo, los cambios en listas de control de acceso a la red (ACL), las políticas de grupos de seguridad o el uso de direcciones IP estáticas pueden interrumpir esta comunicación.

  • Las subredes cuyas instancias pueden comunicarse con Internet se denominan subredes públicas.

  • Las subredes cuyas instancias solo pueden comunicarse con otras instancias de la VPC, ni pueden comunicarse directamente con Internet, se denominan subredes privadas.

AWS OpsWorks Stacks requiere que la VPC esté configurada de modo que todas las instancias de la pila, incluidas las instancias de las subredes privadas, tengan acceso a los siguientes puntos de conexión:

  • Uno de los puntos finales del servicio AWS OpsWorks Stacks que figuran en la sección «Region Support» de. Cómo empezar con AWS OpsWorks Stacks

  • Uno de los siguientes puntos de enlace del servicio de instancias, utilizado por el AWS OpsWorks agente de Stacks. El agente se ejecuta en las instancias administradas de los clientes para intercambiar datos con el servicio.

    • opsworks-instance-service.us-east-2.amazonaws.com

    • opsworks-instance-service.us-east-1.amazonaws.com

    • opsworks-instance-service.us-west-1.amazonaws.com

    • opsworks-instance-service.us-west-2.amazonaws.com

    • opsworks-instance-service.ap-south-1.amazonaws.com

    • opsworks-instance-service.ap-northeast-1.amazonaws.com

    • opsworks-instance-service.ap-northeast-2.amazonaws.com

    • opsworks-instance-service.ap-southeast-1.amazonaws.com

    • opsworks-instance-service.ap-southeast-2.amazonaws.com

    • opsworks-instance-service.ca-central-1.amazonaws.com

    • opsworks-instance-service.eu-central-1.amazonaws.com

    • opsworks-instance-service.eu-west-1.amazonaws.com

    • opsworks-instance-service.eu-west-2.amazonaws.com

    • opsworks-instance-service.eu-west-3.amazonaws.com

  • Amazon S3

  • Cualquier repositorio de paquetes del que dependa el sistema operativo, por ejemplo, los repositorios de Amazon Linux o Ubuntu Linux.

  • La aplicación y los repositorios de libros de recetas personalizados.

Existen varias formas de configurar una VPC para proporcionar esta conectividad. El siguiente es un ejemplo sencillo de cómo puedes configurar una VPC para una pila de servidores de aplicaciones AWS OpsWorks Stacks.

Esta VPC tiene varios componentes:

Subredes

La VPC tiene dos subredes: una privada y una pública.

  • La subred pública incluye un equilibrador de carga y un dispositivo de traducción de direcciones de red (NAT) que puede comunicarse con direcciones externas y con las instancias de la subred privada.

  • La subred privada incluye los servidores de la aplicación que, aunque pueden comunicarse con el dispositivo de NAT y el balanceador de carga de la subred pública, no pueden comunicarse directamente con las direcciones externas.

Puerta de enlace de Internet

El puerto de enlace a Internet permite a las instancias con direcciones IP públicas, por ejemplo, el balanceador de carga, comunicarse con direcciones fuera de la VPC.

Equilibrador de carga

El balanceador de carga Elastic Load Balancing recibe el tráfico entrante los de usuarios, lo distribuye a los servidores de la aplicación en la subred privada y, a continuación, devuelve las respuestas a los usuarios.

NAT

El dispositivo (NAT) proporciona a los servidores de la aplicación un acceso a Internet limitado, lo que suele utilizarse para, por ejemplo, descargar las actualizaciones de software de un repositorio externo. Todas las instancias de AWS OpsWorks Stacks deben poder comunicarse con AWS OpsWorks Stacks y con los repositorios de Linux correspondientes. Una forma de gestionar este problema es guardar un dispositivo de NAT con una dirección IP elástica asociada en una subred pública, así podrá dirigir el tráfico saliente de las instancias de la subred privada a través de dispositivo de NAT.

nota

Una única instancia NAT crea un único punto de error en el tráfico saliente de la subred privada. Para mejorar la fiabilidad, configure la VPC con un par de instancias NAT que se releven si una de ellas devuelve un error. Para obtener más información, consulte Alta disponibilidad para instancias NAT de Amazon VPC. También puede utilizar una gateway de NAT. Para obtener más información, consulte NAT en la Guía del usuario de Amazon VPC.

La configuración óptima de la VPC depende de tu pila de AWS OpsWorks Stacks. A continuación, se muestran algunos ejemplos de cuándo podría utilizar determinadas configuraciones de la VPC. Para ver ejemplos de otros escenarios de uso de la VPC, consulte Situaciones en las que utilizar Amazon VPC.

Working with one instance in a public subnet (Trabajar con una instancia en una subred pública)

Si tiene una pila de instancia única sin recursos privados asociados, por ejemplo, una instancia de Amazon RDS que no que no deba ser pública, puede crear una VPC con una subred pública e incluir la instancia en ella. Si no va a utilizar una VPC predeterminada, la capa de la instancia debe asignar a la instancia una dirección IP elástica. Para obtener más información, consulte OpsWorks Conceptos básicos de capas.

Working with private resources (Trabajo con recursos privados)

Si tiene de recursos que no deben ser de acceso público, puede crear una VPC con una subred pública y una subred privada. Por ejemplo, en un entorno de escalado automático de carga equilibrada, puede incluir todas las Amazon EC2 en la subred privada y el equilibrador de carga en una subred pública. De esta forma, no es posible obtener acceso a las instancias de Amazon EC2 directamente desde Internet; todo el tráfico entrante debe dirigirse a través del equilibrador de carga.

La subred privada aísla las instancias de Amazon EC2 del acceso directo de los usuarios, pero deben poder enviar solicitudes de salida a AWS, así como a los repositorios de paquete de Linux correspondientes. Para permitir este tipo de solicitudes puede, por ejemplo, utilizar un dispositivo de traducción de direcciones de red (NAT) con una dirección IP elástica propia y, a continuación, dirigir el tráfico saliente a través de la NAT. Puede colocar la NAT en la misma subred pública que el balanceador de carga tal y como se muestra en el ejemplo anterior.

  • Si utiliza la base de datos de un backend, como una instancia de Amazon RDS, puede incluir dichas instancias en la subred privada. En el caso de las instancias de Amazon RDS, debe especificar al menos dos subredes diferentes en distintas zonas de disponibilidad.

  • Si necesita acceso directo a las instancias de una subred privada, por ejemplo, si desea utilizar SSH para iniciar sesión en una instancia, puede guardar un host bastión en la subred pública que distribuye las solicitudes de Internet.

Extending your own network into AWS (Ampliar su propia red a AWS)

Si desea llevar su red a la nube y obtener acceso directo a Internet desde la VPC, puede crear una gateway de VPN. Para obtener más información, consulte Situación 3: VPC con subredes públicas y privadas y acceso a VPN de hardware.

Crear una VPC para un AWS OpsWorks Stacks Stack

En esta sección, se muestra cómo crear una VPC para una pila de AWS OpsWorks Stacks mediante un ejemplo de plantilla de AWS. CloudFormation Puedes descargar la plantilla en el OpsWorksarchivo VPCtemplates.zip. Para obtener más información sobre cómo crear manualmente una VPC como la que se ha utilizado en este tema, consulte Escenario 2: VPC con subredes públicas y privadas. Para obtener más información sobre cómo configurar las tablas de direccionamiento, los grupos de seguridad, etc., consulte la plantilla de ejemplo.

nota

De forma predeterminada, AWS OpsWorks Stacks muestra los nombres de las subredes concatenando su rango de CIDR y su zona de disponibilidad, por ejemplo. 10.0.0.1/24 - us-east-1b Para que los nombres sean más legibles, crea una etiqueta para cada subred con la clave Name y el valor establecidos en el nombre de la subred. AWS OpsWorks A continuación, Stacks agrega el nombre de la subred al nombre predeterminado. Por ejemplo, la subred privada del siguiente ejemplo tiene una etiqueta con el nombre establecido enPrivate, que se muestra como. OpsWorks 10.0.0.1/24 us-east - 1b - Private

Puede lanzar una plantilla de VPC mediante la AWS CloudFormation consola con solo unos pocos pasos. El siguiente procedimiento utiliza la plantilla de ejemplo para crear una VPC en la región Este de EE. UU. (Norte de Virginia). Para obtener más información sobre cómo utilizar la plantilla para crear una VPC en otras regiones, consulte la nota que aparece al final del procedimiento.

Para crear la VPC
  1. Abra la consola de AWS CloudFormation, seleccione la región US East (N. Virginia) (EE. UU. Este (Norte de Virginia)) y elija Create Stack (Crear pila).

  2. En la página Select Template (Seleccionar plantilla), seleccione Upload a template (Subir una plantilla). Busque el OpsWorksinVPC.template archivo que descargó en el archivo OpsWorks VPCtemplates.zip. Seleccione Continuar.

    CloudFormation Seleccione la página de plantillas

    También puede lanzar esta pila abriendo plantillas de CloudFormation muestra de AWS, localizando la plantilla de VPC de AWS OpsWorks Stacks y eligiendo Launch Stack.

  3. En la página Specify Parameters (Especificar parámetros), acepte los valores predeterminados y elija Continue (Continuar).

  4. En la página Add Tags (Añadir etiquetas), cree una etiqueta con la opción Key (Clave) establecida en Name y Value (Valor) sean el nombre de la VPC. Esta etiqueta te permitirá identificar más fácilmente tu VPC cuando crees una pila de AWS OpsWorks Stacks.

  5. Elija Continue (Continuar) y, a continuación, Close (Cerrar) para lanzar la pila.

Nota: Para crear la VPC en otras regiones, realice una de las siguientes acciones.

  • Ve a Uso de plantillas en diferentes regiones, elige la región adecuada, busca la plantilla de VPC de AWS OpsWorks Stacks y, a continuación, selecciona Launch Stack.

  • Copie el archivo de plantilla en el sistema, seleccione la región adecuada en la consola de AWS CloudFormation y, a continuación, utilice la opción Create Stack (Crear pila) del asistente Upload a template to Amazon S3 (Cargar una plantilla a Amazon S3) para cargarla.

La plantilla de ejemplo incluye salidas que proporcionan los ID de VPC, subred y balanceador de carga que necesitarás para crear la pila de Stacks. AWS OpsWorks Para verlos, selecciona la pestaña Salidas en la parte inferior de la ventana de la consola. AWS CloudFormation