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.
# Uso de OpsWorks Stacks Instances
**importante**
El AWS OpsWorks Stacks servicio llegó al final de su vida útil el 26 de mayo de 2024 y se inhabilitó tanto para los clientes nuevos como para los existentes. 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](https://repost.aws/) o a través de Premium [AWS Support](https://aws.amazon.com/support).
Puedes usar las OpsWorks pilas para crear instancias y añadirlas a la pila.
**Topics**
+ [OpsWorks Sistemas operativos Stacks](workinginstances-os.md)
+ [Añadir una instancia a una capa](workinginstances-add.md)
+ [Uso de Custom AMIs](workinginstances-custom-ami.md)
+ [Proceso manual de inicio, paro y reinicio de instancias de funcionamiento ininterrumpido](workinginstances-starting.md)
+ [Gestión de la carga con instancias basadas en tiempo y en carga](workinginstances-autoscaling.md)
# OpsWorks Sistemas operativos Stacks
**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 existentes. 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](https://repost.aws/) o a través de Premium [AWS Support](https://aws.amazon.com/support).
OpsWorks Stacks es compatible con las versiones de 64 bits de varios sistemas operativos integrados, incluidas las distribuciones Amazon y Ubuntu Linux y Microsoft Windows Server. Notas generales:
+ Las instancias de una pila pueden ejecutar Linux o Windows.
Una pila puede tener diferentes versiones o distribuciones de Linux en instancias distintas, pero no es posible combinar instancias de Linux y Windows.
+ Puedes usar imágenes [personalizadas AMIs](workinginstances-custom-ami.md) (Amazon Machine Images), pero deben estar basadas en una de las versiones OpsWorks compatibles con Stacks AMIs que se describen en los temas de esta sección. Si bien es posible crear o registrar instancias con otros sistemas operativos (como CentOS 6). *x*) que se han creado a partir de datos personalizados o generados por la comunidad AMIs, no cuentan con soporte oficial.
+ [Sistemas operativos Linux](workinginstances-os-linux.md)
+ [Microsoft Windows Server](workinginstances-os-windows.md)
+ Puede [iniciar y detener las instancias manualmente](workinginstances-starting.md) o hacer que OpsWorks Stacks [escale automáticamente](workinginstances-autoscaling.md) el número de instancias.
Puede utilizar el escalado automático basado en tiempo con cualquier pila; las pilas de Linux también pueden utilizar el escalado basado en carga.
+ Además de usar OpsWorks Stacks para crear EC2 instancias de Amazon, también puedes [registrar instancias con una pila de Linux](workinginstances-autoscaling.md) que se hayan creado fuera de OpsWorks Stacks.
Esto incluye EC2 las instancias de Amazon y las instancias que se ejecutan en su propio hardware. No obstante, deben ejecutar una de las distribuciones de Linux compatibles. No puedes registrar instancias de Amazon EC2 o de Windows locales.
Puedes ejecutar la [https://docs.aws.amazon.com/opsworks/latest/APIReference/API_DescribeOperatingSystems.html](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_DescribeOperatingSystems.html)API de OpsWorks Stacks para obtener una lista de los sistemas operativos compatibles y sus versiones compatibles de Chef. A continuación se muestra un comando de ejemplo que utiliza la AWS CLI.
```
aws opsworks describe-operating-systems
```
A continuación, se muestra un ejemplo de respuesta.
```
{
"OperatingSystems": [
{
"Name": "Amazon Linux",
"Id": "Amazon Linux",
"Type": "Linux",
"ConfigurationManagers": [
{
"Name": "Chef",
"Version": "11.10"
},
{
"Name": "Chef",
"Version": "11.4"
},
{
"Name": "Chef",
"Version": "0.9"
}
],
"ReportedName": "amazon",
"ReportedVersion": "2014.03",
"Supported": false
},
{
"Name": "Amazon Linux 2",
"Id": "Amazon Linux 2",
"Type": "Linux",
"ConfigurationManagers": [
{
"Name": "Chef",
"Version": "12"
}
],
"ReportedName": "amazon",
"ReportedVersion": "2"
},
{
"Name": "Amazon Linux 2014.09",
"Id": "Amazon Linux 2014.09",
"Type": "Linux",
"ConfigurationManagers": [
{
"Name": "Chef",
"Version": "11.10"
},
{
"Name": "Chef",
"Version": "11.4"
},
{
"Name": "Chef",
"Version": "0.9"
}
],
"ReportedName": "amazon",
"ReportedVersion": "2014.09",
"Supported": false
},
{
"Name": "Amazon Linux 2015.03",
"Id": "Amazon Linux 2015.03",
"Type": "Linux",
"ConfigurationManagers": [
{
"Name": "Chef",
"Version": "12"
},
{
"Name": "Chef",
"Version": "11.10"
},
{
"Name": "Chef",
"Version": "11.4"
},
{
"Name": "Chef",
"Version": "0.9"
}
],
"ReportedName": "amazon",
"ReportedVersion": "2015.03",
"Supported": false
},
{
"Name": "Amazon Linux 2015.09",
"Id": "Amazon Linux 2015.09",
"Type": "Linux",
"ConfigurationManagers": [
{
"Name": "Chef",
"Version": "12"
},
{
"Name": "Chef",
"Version": "11.10"
},
{
"Name": "Chef",
"Version": "11.4"
},
{
"Name": "Chef",
"Version": "0.9"
}
],
"ReportedName": "amazon",
"ReportedVersion": "2015.09",
"Supported": false
},
{
"Name": "Amazon Linux 2016.03",
"Id": "Amazon Linux 2016.03",
"Type": "Linux",
"ConfigurationManagers": [
{
"Name": "Chef",
"Version": "12"
},
{
"Name": "Chef",
"Version": "11.10"
},
{
"Name": "Chef",
"Version": "11.4"
},
{
"Name": "Chef",
"Version": "0.9"
}
],
"ReportedName": "amazon",
"ReportedVersion": "2016.03"
},
{
"Name": "Amazon Linux 2016.09",
"Id": "Amazon Linux 2016.09",
"Type": "Linux",
"ConfigurationManagers": [
{
"Name": "Chef",
"Version": "12"
},
{
"Name": "Chef",
"Version": "11.10"
},
{
"Name": "Chef",
"Version": "11.4"
},
{
"Name": "Chef",
"Version": "0.9"
}
],
"ReportedName": "amazon",
"ReportedVersion": "2016.09"
},
{
"Name": "Amazon Linux 2017.03",
"Id": "Amazon Linux 2017.03",
"Type": "Linux",
"ConfigurationManagers": [
{
"Name": "Chef",
"Version": "12"
},
{
"Name": "Chef",
"Version": "11.10"
},
{
"Name": "Chef",
"Version": "11.4"
},
{
"Name": "Chef",
"Version": "0.9"
}
],
"ReportedName": "amazon",
"ReportedVersion": "2017.03"
},
{
"Name": "Amazon Linux 2017.09",
"Id": "Amazon Linux 2017.09",
"Type": "Linux",
"ConfigurationManagers": [
{
"Name": "Chef",
"Version": "12"
},
{
"Name": "Chef",
"Version": "11.10"
},
{
"Name": "Chef",
"Version": "11.4"
},
{
"Name": "Chef",
"Version": "0.9"
}
],
"ReportedName": "amazon",
"ReportedVersion": "2017.09"
},
{
"Name": "Amazon Linux 2018.03",
"Id": "Amazon Linux 2018.03",
"Type": "Linux",
"ConfigurationManagers": [
{
"Name": "Chef",
"Version": "12"
},
{
"Name": "Chef",
"Version": "11.10"
}
],
"ReportedName": "amazon",
"ReportedVersion": "2018.03"
},
{
"Name": "CentOS Linux 7",
"Id": "CentOS Linux 7",
"Type": "Linux",
"ConfigurationManagers": [
{
"Name": "Chef",
"Version": "12"
}
],
"ReportedName": "CentOS Linux",
"ReportedVersion": "7"
},
{
"Name": "Microsoft Windows Server 2012 R2 Base",
"Id": "Microsoft Windows Server 2012 R2 Base",
"Type": "Windows",
"ConfigurationManagers": [
{
"Name": "Chef",
"Version": "12.2"
}
],
"ReportedName": "microsoft windows server",
"ReportedVersion": "2012 r2 standard",
"Supported": false
},
{
"Name": "Microsoft Windows Server 2012 R2 with SQL Server Express",
"Id": "Microsoft Windows Server 2012 R2 with SQL Server Express",
"Type": "Windows",
"ConfigurationManagers": [
{
"Name": "Chef",
"Version": "12.2"
}
],
"ReportedName": "microsoft windows server",
"ReportedVersion": "2012 r2 standard",
"Supported": false
},
{
"Name": "Microsoft Windows Server 2012 R2 with SQL Server Standard",
"Id": "Microsoft Windows Server 2012 R2 with SQL Server Standard",
"Type": "Windows",
"ConfigurationManagers": [
{
"Name": "Chef",
"Version": "12.2"
}
],
"ReportedName": "microsoft windows server",
"ReportedVersion": "2012 r2 standard",
"Supported": false
},
{
"Name": "Microsoft Windows Server 2012 R2 with SQL Server Web",
"Id": "Microsoft Windows Server 2012 R2 with SQL Server Web",
"Type": "Windows",
"ConfigurationManagers": [
{
"Name": "Chef",
"Version": "12.2"
}
],
"ReportedName": "microsoft windows server",
"ReportedVersion": "2012 r2 standard",
"Supported": false
},
{
"Name": "Microsoft Windows Server 2019 Base",
"Id": "Microsoft Windows Server 2019 Base",
"Type": "Windows",
"ConfigurationManagers": [
{
"Name": "Chef",
"Version": "12.2"
}
],
"ReportedName": "microsoft windows server",
"ReportedVersion": "2019 datacenter"
},
{
"Name": "Microsoft Windows Server 2019 with SQL Server Express",
"Id": "Microsoft Windows Server 2019 with SQL Server Express",
"Type": "Windows",
"ConfigurationManagers": [
{
"Name": "Chef",
"Version": "12.2"
}
],
"ReportedName": "microsoft windows server",
"ReportedVersion": "2019 datacenter"
},
{
"Name": "Microsoft Windows Server 2019 with SQL Server Standard",
"Id": "Microsoft Windows Server 2019 with SQL Server Standard",
"Type": "Windows",
"ConfigurationManagers": [
{
"Name": "Chef",
"Version": "12.2"
}
],
"ReportedName": "microsoft windows server",
"ReportedVersion": "2019 datacenter"
},
{
"Name": "Microsoft Windows Server 2019 with SQL Server Web",
"Id": "Microsoft Windows Server 2019 with SQL Server Web",
"Type": "Windows",
"ConfigurationManagers": [
{
"Name": "Chef",
"Version": "12.2"
}
],
"ReportedName": "microsoft windows server",
"ReportedVersion": "2019 datacenter"
},
{
"Name": "Microsoft Windows Server 2022 Base",
"Id": "Microsoft Windows Server 2022 Base",
"Type": "Windows",
"ConfigurationManagers": [
{
"Name": "Chef",
"Version": "12.2"
}
],
"ReportedName": "microsoft windows server",
"ReportedVersion": "2022 datacenter"
},
{
"Name": "Microsoft Windows Server 2022 with SQL Server Express",
"Id": "Microsoft Windows Server 2022 with SQL Server Express",
"Type": "Windows",
"ConfigurationManagers": [
{
"Name": "Chef",
"Version": "12.2"
}
],
"ReportedName": "microsoft windows server",
"ReportedVersion": "2022 datacenter"
},
{
"Name": "Microsoft Windows Server 2022 with SQL Server Standard",
"Id": "Microsoft Windows Server 2022 with SQL Server Standard",
"Type": "Windows",
"ConfigurationManagers": [
{
"Name": "Chef",
"Version": "12.2"
}
],
"ReportedName": "microsoft windows server",
"ReportedVersion": "2022 datacenter"
},
{
"Name": "Microsoft Windows Server 2022 with SQL Server Web",
"Id": "Microsoft Windows Server 2022 with SQL Server Web",
"Type": "Windows",
"ConfigurationManagers": [
{
"Name": "Chef",
"Version": "12.2"
}
],
"ReportedName": "microsoft windows server",
"ReportedVersion": "2022 datacenter"
},
{
"Name": "Red Hat Enterprise Linux 7",
"Id": "Red Hat Enterprise Linux 7",
"Type": "Linux",
"ConfigurationManagers": [
{
"Name": "Chef",
"Version": "12"
},
{
"Name": "Chef",
"Version": "11.10"
}
],
"ReportedName": "Red Hat Enterprise Linux",
"ReportedVersion": "7"
},
{
"Name": "Ubuntu 12.04 LTS",
"Id": "Ubuntu 12.04 LTS",
"Type": "Linux",
"ConfigurationManagers": [
{
"Name": "Chef",
"Version": "12"
},
{
"Name": "Chef",
"Version": "11.10"
},
{
"Name": "Chef",
"Version": "11.4"
},
{
"Name": "Chef",
"Version": "0.9"
}
],
"ReportedName": "ubuntu",
"ReportedVersion": "12.04",
"Supported": false
},
{
"Name": "Ubuntu 14.04 LTS",
"Id": "Ubuntu 14.04 LTS",
"Type": "Linux",
"ConfigurationManagers": [
{
"Name": "Chef",
"Version": "12"
},
{
"Name": "Chef",
"Version": "11.10"
}
],
"ReportedName": "ubuntu",
"ReportedVersion": "14.04"
},
{
"Name": "Ubuntu 16.04 LTS",
"Id": "Ubuntu 16.04 LTS",
"Type": "Linux",
"ConfigurationManagers": [
{
"Name": "Chef",
"Version": "12"
}
],
"ReportedName": "ubuntu",
"ReportedVersion": "16.04"
},
{
"Name": "Ubuntu 18.04 LTS",
"Id": "Ubuntu 18.04 LTS",
"Type": "Linux",
"ConfigurationManagers": [
{
"Name": "Chef",
"Version": "12"
}
],
"ReportedName": "ubuntu",
"ReportedVersion": "18.04"
},
{
"Name": "Ubuntu 20.04 LTS",
"Id": "Ubuntu 20.04 LTS",
"Type": "Linux",
"ConfigurationManagers": [
{
"Name": "Chef",
"Version": "12"
}
],
"ReportedName": "ubuntu",
"ReportedVersion": "20.04"
},
{
"Name": "Custom",
"Id": "Custom",
"Type": "Linux",
"ConfigurationManagers": [
{
"Name": "Chef",
"Version": "12"
},
{
"Name": "Chef",
"Version": "11.10"
},
{
"Name": "Chef",
"Version": "11.4"
},
{
"Name": "Chef",
"Version": "0.9"
}
]
},
{
"Name": "CustomWindows",
"Id": "CustomWindows",
"Type": "Windows",
"ConfigurationManagers": [
{
"Name": "Chef",
"Version": "12.2"
}
]
}
]
}
```
**Topics**
+ [Sistemas operativos Linux](workinginstances-os-linux.md)
+ [Microsoft Windows Server](workinginstances-os-windows.md)
# Sistemas operativos Linux
**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 existentes. 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](https://repost.aws/) o a través de Premium [AWS Support](https://aws.amazon.com/support).
OpsWorks Stacks es compatible con las versiones de 64 bits de los siguientes sistemas operativos Linux.
+ [Amazon Linux](https://aws.amazon.com/amazon-linux-ami/faqs/) y [Amazon Linux 2](https://aws.amazon.com/amazon-linux-2/) (consulte la [consola de OpsWorks Stacks](https://console.aws.amazon.com/opsworks/) para ver las versiones compatibles actualmente)
+ [Ubuntu 20.04 LTS](https://wiki.ubuntu.com/FocalFossa/ReleaseNotes)
+ [CentOS 7](https://docs.centos.org/en-US/centos/install-guide/Revision_History/)
+ [Red Hat Enterprise Linux 7](https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/)
También puedes usar sistemas [personalizados AMIs](workinginstances-custom-ami.md) basados en estos sistemas operativos.
Notas generales sobre las instancias de Linux:
**Versiones de paquetes compatibles**
Las versiones compatibles y los niveles de parches para paquetes, como Ruby, dependen del sistema operativo y la versión, tal como se describe en las secciones siguientes.
**Actualizaciones**
De forma predeterminada, OpsWorks Stacks se asegura de que las instancias de Linux tengan los últimos parches de seguridad mediante una llamada automática `yum update` o `apt-get update` después del arranque de la instancia. Para deshabilitar las actualizaciones automáticas, utilice las [UpdateLayer](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_UpdateLayer.html)acciones [CreateInstance[UpdateInstance[CreateLayer](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_CreateLayer.html)](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_UpdateInstance.html)](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_CreateInstance.html), o los métodos del [SDK de AWS](https://aws.amazon.com/tools/) equivalentes o los comandos de la [CLI](https://aws.amazon.com/documentation/cli/) de AWS, para establecer el `InstallUpdatesOnBoot` parámetro en. `false`
Para evitar interrupciones en el servicio, OpsWorks Stacks no instala automáticamente las actualizaciones una vez que una instancia está en línea. Puede actualizar manualmente el sistema operativo de una instancia online en cualquier momento ejecutando el [comando de pila Upgrade Operating System](workingstacks-commands.md). Para obtener más información sobre cómo administrar las actualizaciones de seguridad, consulte [Administración de actualizaciones de seguridad](workingsecurity-updates.md).
Para tener más control sobre la forma en que OpsWorks Stacks actualiza tus instancias, crea una AMI personalizada basada en uno de los sistemas operativos compatibles. Por ejemplo, con custom AMIs puedes especificar qué versiones de paquetes se instalan en una instancia. Cada distribución de Linux cuenta con diferentes calendarios de soporte y políticas de combinación de paquetes, de manera que le conviene tener en cuenta el método que mejor se adapte a sus necesidades. Para obtener más información, consulte [Uso de Custom AMIs](workinginstances-custom-ami.md).
**Archivo hosts**
Cada instancia en línea tiene un `/etc/hosts` archivo que asigna las direcciones IP a los nombres de los hosts. OpsWorks Las pilas incluyen las direcciones públicas y privadas de todas las instancias en línea de la pila en el `hosts` archivo de cada instancia. Por ejemplo, supongamos que tiene una pila con dos instancias de Node.js App Server, nodejs-app1 y nodejs-app2, y una instancia de MySQL, db-master1. El archivo `hosts` de la instancia nodejs-app1 tendrá un aspecto parecido al siguiente ejemplo y la otra instancia tendrá archivos `hosts` similares.
```
...
# OpsWorks Layer State
192.0.2.0 nodejs-app1.localdomain nodejs-app1
10.145.160.232 db-master1
198.51.100.0 db-master1-ext
10.243.77.78 nodejs-app2
203.0.113.0 nodejs-app2-ext
10.84.66.6 nodejs-app1
192.0.2.0 nodejs-app1-ext
```
**OpsWorks Soporte de agente proxy de Stacks**
El agente OpsWorks Stacks para Chef 11.10 y versiones posteriores incluye soporte básico para servidores proxy, que normalmente se utilizan de forma aislada. VPCs Para habilitar el soporte de servidor proxy, una instancia debe tener un archivo `/etc/environment` que proporcione la configuración adecuada para el tráfico HTTP y HTTPS. El archivo debe ser similar a lo siguiente, donde el texto resaltado se reemplaza con la URL y el puerto del servidor proxy:
```
http_proxy="http://myproxy.example.com:8080/"
https_proxy="http://myproxy.example.com:8080/"
no_proxy="169.254.169.254"
```
Para habilitar el soporte del proxy, recomendamos [crear una AMI personalizada](workinginstances-custom-ami.md) que incluya un archivo `/etc/environment` adecuado y usar dicha AMI para crear las instancias.
No recomendamos usar una receta personalizada para crear un `/etc/environment` archivo en tus instancias. OpsWorks Stacks necesita los datos del servidor proxy al principio del proceso de configuración, antes de que se ejecute cualquier receta personalizada.
**Topics**
+ [Amazon Linux](#workinginstances-os-amazon)
+ [Ubuntu LTS](#workinginstances-os-linux-ubuntu)
+ [CentOS](#workinginstances-os-linux-centos)
+ [Red Hat Enterprise Linux](#workinginstances-os-linux-rhel)
## Amazon Linux
OpsWorks Stacks es compatible con las versiones de 64 bits de Amazon Linux y Amazon Linux 2. Además de las actualizaciones y parches periódicos, Amazon Linux lanza una nueva versión cada seis meses, aproximadamente, que puede conllevar cambios significativos. Cuando se crea una pila o una instancia, se debe especificar la versión de Amazon Linux que se va a utilizar. Cuando AWS lanza una nueva versión, las instancias continúan ejecutando la versión especificada hasta que se cambie explícitamente. Después del lanzamiento de una nueva versión de Amazon Linux, hay un período de migración de cuatro semanas durante el que AWS continúa proporcionando actualizaciones regulares para la versión anterior. Una vez finalizado el período de migración, las instancias pueden seguir ejecutando la versión anterior, pero AWS no proporciona más actualizaciones. Para obtener más información, consulte [AMI de Amazon Linux FAQs](https://aws.amazon.com/amazon-linux-ami/faqs/#lock).
Cuando salga una nueva versión de Amazon Linux, recomendamos que se actualice dentro del período de migración para que las instancias continúen recibiendo las actualizaciones de seguridad. Antes de actualizar las instancias de la pila de producción, le recomendamos que inicie una nueva instancia y verifique que la aplicación se ejecuta correctamente en la nueva versión. Después puede actualizar las instancias de la pila de producción.
**nota**
De forma predeterminada, las versiones personalizadas AMIs basadas en Amazon Linux se actualizan automáticamente a la nueva versión cuando se publica. La práctica recomendada consiste en bloquear la AMI personalizada en una versión específica de Amazon Linux para aplazar la actualización hasta que haya probado la nueva versión. Para obtener más información, consulte [¿Cómo puedo bloquear la AMI para una versión concreta?](https://aws.amazon.com/amazon-linux-ami/faqs/#lock)
Si utilizas una CloudFormation plantilla para crear pilas con instancias que ejecuten Amazon Linux, las plantillas deben especificar explícitamente una versión de Amazon Linux. En concreto, si la plantilla especifica `Amazon Linux`, las instancias seguirán ejecutando la versión 2016.09. Para obtener más información, consulte [AWS::OpsWorks::Stack](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-opsworks-stack.html) y [AWS::OpsWorks::Instance](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-opsworks-instance.html).
Para actualizar la versión de Amazon Linux de una instancia, lleve a cabo una de las siguientes operaciones:
+ Para las instancias en línea, ejecute el [comando de stack **Upgrade Operating System (Actualizar sistema operativo)**](workingstacks-commands.md).
Cuando hay una nueva versión de Amazon Linux disponible, las páginas **Instances (Instancias)** y **Stack (Pila)** muestran un anuncio con un enlace que lleva a la página **Run Command (Ejecutar comando)**. Entonces podrá ejecutar **Upgrade Operating System (Actualizar sistema operativo)** para actualizar la instancia.
+ Para las instancias sin conexión respaldadas por Amazon Elastic Block Store (respaldadas por EBS), inícielas y ejecute **Actualizar sistema operativo**, tal como se describe en el punto anterior.
+ Para instancias sin conexión con respaldo en el almacenamiento de la instancia, incluidas las instancias basadas en tiempo y en carga, [modifique la configuración **Operating system (Sistema operativo)**](workinginstances-properties.md) de la instancia para especificar la nueva versión.
OpsWorks Stacks actualiza automáticamente las instancias a la nueva versión cuando se reinician.
**Amazon Linux: versiones de Node.js compatibles**
| Versión de Amazon Linux | Versiones de Node.js |
| --- | --- |
| 2
| (Not applicable to operating systems that are available for Chef 12 and higher stacks only)
|
| 2018.03
| 0.12.18
|
| 2017.09
| 0.12.18
|
| 2017.03
| 0.12.18
|
| 2016.09
| 0.12.18
0.12.17
0.12.16
0.12.15
|
| 2016.03
| 0.12.18
0.12.17
0.12.16
0.12.15
0.12.14
0.12.13
0.12.12
0.12.10
|
**Amazon Linux: versiones de Chef compatibles**
| Versión de Chef | Versiones de Amazon Linux compatibles |
| --- | --- |
| 12
| Amazon Linux 2
Amazon Linux 2018.03
Amazon Linux 2017.09
Amazon Linux 2017.03
Amazon Linux 2016.09
Amazon Linux 2016.03
|
| 11.10
| Amazon Linux 2018.03
Amazon Linux 2017.09
Amazon Linux 2017.03
Amazon Linux 2016.09
Amazon Linux 2016.03
|
| 11.4 (deprecated)
| Amazon Linux 2016.09
Amazon Linux 2016.03
|
**importante**
Antes de actualizar las instancias t1.micro, asegúrese de que tiene un archivo de intercambio temporal, `/var/swapfile`. Las instancias t1.micro en las pilas de Chef 0.9 no tienen un archivo de intercambio. En las pilas de Chef 11.4 y Chef 11.10, las versiones recientes del agente de instancia crean automáticamente un archivo de intercambio para instancias t1.micro. No obstante, este cambio se introdujo durante un período de varias semanas, por lo que deberá comprobar si existe el archivo `/var/swapfile` en las instancias creadas antes del 24 de marzo de 2014, aproximadamente.
Cree un archivo de intercambio para las instancias t1.micro que no lo tengan del modo siguiente:
Para 11.10 y versiones posteriores, cree nuevas instancias t1.micro, las cuales incluirán automáticamente un archivo de intercambio.
Para pilas de Chef 0.9, ejecute los siguientes comandos en cada instancia como usuario raíz.
```
dd if=/dev/zero of=/var/swapfile bs=1M count=256
mkswap /var/swapfile
chown root:root /var/swapfile
chmod 0600 /var/swapfile
swapon /var/swapfile
```
También puede utilizar estos comandos en stacks Chef 11.10 y posteriores si no desea crear instancias.
## Ubuntu LTS
Ubuntu lanza una nueva versión Ubuntu LTS cada dos años aproximadamente y da soporte a cada versión durante unos cinco años. Ubuntu proporciona parches de seguridad y actualizaciones durante el período de soporte del sistema operativo. Para obtener más información, consulte [LTS - Ubuntu Wiki](https://wiki.ubuntu.com/LTS).
+ No puede actualizar una instancia de Ubuntu existente a una nueva versión de Ubuntu.
Debe [crear una instancia de 14.04 o Ubuntu 16.04 nueva](workinginstances-add.md) y [eliminar la anterior](workinginstances-delete.md).
+ Ubuntu 20.04 LTS únicamente es compatible con pilas de Chef 12 y posteriores.
## CentOS
OpsWorks Stacks es compatible con la versión de 64 bits de [Centos 7](https://docs.centos.org/en-US/docs/). La primera versión compatible es CentOS 7 y CentOS lanza una nueva versión cada dos años aproximadamente.
Cuando inicias una nueva instancia en una pila de CentOS, OpsWorks Stacks instala automáticamente la versión más reciente de CentOS. Como OpsWorks Stacks no actualiza automáticamente el sistema operativo en las instancias existentes cuando se publica una nueva versión secundaria de CentOS, es posible que una instancia recién creada reciba una versión más reciente que las instancias existentes de la pila. Para mantener la coherencia de versiones en toda la pila, actualice las instancias existentes con la última versión de CentOS del modo siguiente:
+ Para las instancias online, ejecute el [comando de stack **Upgrade Operating System (Actualizar sistema operativo)**](workingstacks-commands.md), que ejecuta `yum update` en las instancias especificadas para actualizarlas a la versión actual.
Cuando hay una nueva versión secundaria de CentOS 7 disponible, las páginas **Instances (Instancias)** y **Stack (Pila)** muestran un anuncio con un enlace que lleva a la página **Run Command (Ejecutar comando)**. Entonces podrá ejecutar **Upgrade Operating System (Actualizar sistema operativo)** para actualizar las instancias.
+ Para las instancias sin conexión respaldadas por , inícielas y ejecute **Actualizar sistema operativo**, tal como se describe en el punto anterior.
+ En el caso de las instancias sin conexión y respaldadas en tiendas, OpsWorks Stacks instala automáticamente la nueva versión cuando se reinician las instancias.
**CentOS: versiones de Chef compatibles**
| Versión de Chef | Versión de CentOS compatible |
| --- | --- |
| 12
| CentOS 7
|
| 11.10
| (None supported)
|
| 11.4 (deprecated)
| (None supported)
|
**nota**
OpsWorks Stacks es compatible con Apache 2.4 para instancias de CentOS.
## Red Hat Enterprise Linux
OpsWorks Stacks es compatible con la versión de 64 bits de [Red Hat Enterprise Linux 7 (RHEL 7](https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/)). La primera versión compatible es RHEL 7.1 y Red Hat lanza una nueva versión menor aproximadamente cada nueve meses. Las versiones menores deberían ser compatibles con RHEL 7.0. Para obtener más información, consulte [Ciclo de vida y políticas de actualización](https://access.redhat.com/support/policy/update_policies).
Cuando inicias una nueva instancia, OpsWorks Stacks instala automáticamente la versión actual de RHEL 7. Como OpsWorks Stacks no actualiza automáticamente el sistema operativo en las instancias existentes cuando se publica una nueva versión secundaria de RHEL 7, es posible que una instancia recién creada reciba una versión más reciente que las instancias existentes de la pila. Para mantener la coherencia entre las versiones de toda la pila, actualice las instancias existentes con la última versión de RHEL 7 del modo siguiente:
+ Para las instancias online, ejecute el [comando de stack **Upgrade Operating System (Actualizar sistema operativo)**](workingstacks-commands.md), que ejecuta `yum update` en las instancias especificadas para actualizarlas a la versión actual.
Cuando hay una nueva versión secundaria de RHEL 7 disponible, las páginas **Instances (Instancias)** y **Stack (Pila)** muestran un anuncio con un enlace que lleva a la página **Run Command (Ejecutar comando)**. Entonces podrá ejecutar **Upgrade Operating System (Actualizar sistema operativo)** para actualizar las instancias.
+ Para las instancias sin conexión respaldadas por , inícielas y ejecute **Actualizar sistema operativo**, tal como se describe en el punto anterior.
+ En el caso de las instancias sin conexión guardadas en tiendas, OpsWorks Stacks instala automáticamente la nueva versión cuando se reinician las instancias.
**Red Hat Enterprise Linux: versiones de Node.js compatibles**
| Versión de RHEL | Versiones de Node.js |
| --- | --- |
| 7
| (Node.js versions only apply to Chef 11.10 stacks)
0.8.19
0.8.26
0.10.11
0.10.21
0.10.24
0.10.25
0.10.27
0.10.29
0.10.40
0.12.10
0.12.12
0.12.13
0.12.15
|
**Red Hat Enterprise Linux: versiones de Chef compatibles**
| Versión de Chef | Versión de RHEL compatible |
| --- | --- |
| 12
| Red Hat Enterprise Linux 7
|
| 11.10
| Red Hat Enterprise Linux 7
|
| 11.4 (deprecated)
| (None supported)
|
Todas las versiones de Node.js anteriores a 0.10.40 están obsoletas. Las versiones 0.12.7 y 0.12.9 también están obsoletas.
**nota**
OpsWorks Stacks es compatible con Apache 2.4 para instancias de RHEL 7.
# Microsoft Windows Server
**importante**
El AWS OpsWorks Stacks servicio llegó al final de su vida útil el 26 de mayo de 2024 y se inhabilitó tanto para los clientes nuevos como para los existentes. 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](https://repost.aws/) o a través de Premium [AWS Support](https://aws.amazon.com/support).
En las siguientes notas, se describe la compatibilidad de OpsWorks Stacks con las instancias de Windows. Las instancias de Windows están disponibles únicamente para las pilas de Chef 12.2. La versión exacta de Chef en una pila de Windows es 12.22.
Actualmente, el agente de OpsWorks Stacks no se puede instalar en instancias basadas en Windows que utilizan un idioma de interfaz de usuario del sistema distinto del inglés (**Estados Unidos**) (en-US), y OpsWorks Stacks no puede administrarlas.
**Versiones**
OpsWorks Stacks es compatible con las siguientes versiones de Windows de 64 bits:
+ Microsoft Windows Server 2022 Base
+ Microsoft Windows Server 2022 con SQL Server Express
+ Microsoft Windows Server 2022 con SQL Server Standard
+ Microsoft Windows Server 2022 con SQL Server Web
+ Microsoft Windows Server 2019 Base
+ Microsoft Windows Server 2019 con SQL Server Express
+ Microsoft Windows Server 2019 con SQL Server Standard
+ Microsoft Windows Server 2019 con SQL Server Web
**Creación de instancias**
Las instancias de Windows se crean con la consola, la API o la CLI de OpsWorks Stacks. Las instancias de Windows están respaldadas por Amazon EBS, pero no se pueden montar volúmenes de Amazon EBS adicionales.
Las pilas de Windows pueden utilizar instancias de [funcionamiento ininterrumpido](workinginstances-starting.md), que se inician y detienen manualmente. También pueden utilizar el [escalado automático basado en tiempo](workinginstances-autoscaling-timebased.md), que inicia y detiene las instancias automáticamente en función de un programa definido por el usuario. Las pilas basadas en Windows no pueden utilizar el [escalado automático basado en cargas](workinginstances-autoscaling-loadbased.md).
No puedes [registrar instancias de Windows](registered-instances.md) que se crearon fuera de OpsWorks Stacks con una pila.
**Actualizaciones**
AWS actualiza Windows AMIs para cada conjunto de parches, por lo que, cuando cree una instancia, tendrá las actualizaciones más recientes. Sin embargo, OpsWorks Stacks no proporciona una forma de aplicar actualizaciones a las instancias de Windows en línea. La forma más sencilla de garantizar que Windows está actualizado es sustituir las instancias con regularidad para que siempre ejecuten la AMI más reciente.
**Capas**
Para gestionar tareas como la instalación y la configuración de software o la implementación de aplicaciones, deberá implementar una o varias [capas personalizadas](workinglayers-custom.md) con recetas personalizadas.
**Chef**
Las instancias de Windows utilizan Chef 12.22 y ejecutan [el cliente de Chef en modo local](https://docs.chef.io/ctl_chef_client.html#run-in-local-mode), lo que inicia un servidor de Chef en memoria local llamado [chef-zero](https://docs.chef.io/ctl_chef_client.html#about-chef-zero). La presencia de este servidor permite que las recetas personalizadas usen las bolsas de datos y la búsqueda de Chef.
**Inicio de sesión remoto**
OpsWorks Stacks proporciona a los usuarios de IAM autorizados una contraseña que pueden usar para iniciar sesión en las instancias de Windows. Esta contraseña caduca después de un tiempo especificado. Los administradores pueden utilizar un par de claves de SSH para recuperar la contraseña de administrador de una instancia, que proporciona [acceso RDP](workinginstances-rdp.md) ilimitado. Para obtener más información, consulte [Inicio de sesión con RDP](workinginstances-rdp.md).
**SDK de AWS**
OpsWorks Stacks la instala automáticamente en cada instancia. [AWS SDK para .NET](https://aws.amazon.com/sdk-for-net/) Este paquete incluye las bibliotecas AW.NET y las herramientas de AWS para Windows, incluidas las [herramientas de AWS para PowerShell](https://aws.amazon.com/powershell/). Para utilizar el SDK de Ruby, haga que una receta personalizada instale la gema adecuada.
**Monitorización y métricas**
Las instancias de Windows admiten las [métricas estándar de Amazon CloudWatch (CloudWatch)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/WhatIsCloudWatch.html), que puedes ver en la CloudWatch consola.
**Ruby**
El cliente Chef 12.22 que OpsWorks Stacks instala en las instancias de Windows viene con Ruby 2.3.6. Sin embargo, OpsWorks Stacks no agrega el directorio del ejecutable a la variable de entorno PATH. Para que sus aplicaciones usen esta versión de Ruby, la encontrará, por lo general, en `C:\opscode\chef\embedded\bin\`.
**OpsWorks CLI de Stacks Agent**
El agente OpsWorks Stacks en las instancias de Windows no expone una interfaz de línea de [comandos](agent.md).
**Soporte del proxy**
Haga lo siguiente para configurar la compatibilidad del proxy para las instancias de Windows:
1. Modifica `machine.config` para añadir lo siguiente, que añade compatibilidad con proxy a las aplicaciones Windows PowerShell (arranque inicial) y .NET (agente OpsWorks Stacks):
```
```
1. Ejecute estos comandos para definir las variables de entorno para que Chef y Git las utilicen posteriormente:
```
setx /m no_proxy "localhost,169.254.169.254"
setx /m http_proxy "http://10.100.1.91:3128"
setx /m https_proxy "http://10.100.1.91:3128"
```
**nota**
Para tener más control sobre la forma en que OpsWorks Stacks actualiza tus instancias, crea una AMI personalizada basada en Microsoft Windows Server 2022 Base. Por ejemplo, con custom AMIs puedes especificar qué software se instala en una instancia, como un servidor web (IIS). Para obtener más información, consulte [Uso de Custom AMIs](workinginstances-custom-ami.md).
# Añadir una instancia a una capa
**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 existentes. 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](https://repost.aws/) o a través de Premium [AWS Support](https://aws.amazon.com/support).
Después de crear una capa, normalmente añade como mínimo una instancia. Puede añadir más instancias más tarde si el conjunto actual no puede gestionar la carga. También puede utilizar [instancias basadas en el tiempo o la carga](workinginstances-autoscaling.md) para escalar automáticamente el número de instancias.
Puede añadir instancias nuevas o existentes a una capa:
+ **Nuevo**: OpsWorks crea una nueva instancia, configurada según sus especificaciones, y la convierte en miembro de la capa.
+ **Existente**: puede añadir una instancia existente desde cualquier capa compatible, pero debe estar en estado sin conexión (detenido).
Si una instancia pertenece a varias capas, OpsWorks Stacks ejecuta las recetas de cada una de las capas de la instancia cuando se produce un evento del ciclo de vida, o al ejecutar un comando [stack](workingstacks-commands.md) o [deployment](workingapps-deploying.md).
También puede hacer que una instancia sea miembro de varias capas editando su configuración. Para obtener más información, consulte [Edición de la configuración de las instancias](workinginstances-properties.md).
**Para añadir una nueva instancia a una capa**
1. En la página **Instances (Instancias)**, elija **\$1Instance (\$1Instancia)** para la capa adecuada y (si es necesario) y elija la pestaña **New (Nueva)**. Si desea configurar algo más que **Host name (Nombre de host)**, **Size (Tamaño)** y **Subnet (Subred)** o **Availability Zone (Zona de disponibilidad)**, elija **Advanced >> (Avanzado)** para ver más opciones. A continuación se muestra el conjunto completo de opciones:
![\[+Instance para instancias nuevas en la página Instances\]](http://docs.aws.amazon.com/es_es/opsworks/latest/userguide/images/add_instance.png)
1. Si lo desea, puede anular la configuración predeterminada, especificada en su mayor parte al crear la pila. Para obtener más información, consulte [Crear una pila nueva](workingstacks-creating.md).
**Hostname**
Identifica la instancia en la red. De forma predeterminada, OpsWorks Stacks genera el nombre de host de cada instancia mediante el **tema Hostname** que especificaste al crear la pila. Puede anular este valor y especificar su nombre de host preferido.
**Tamaño**
Un tipo de EC2 instancia de Amazon, que especifica los recursos de la instancia, como la cantidad de memoria o el número de núcleos virtuales. OpsWorks Stacks especifica un tamaño predeterminado para cada instancia, que puedes anular con el tipo de instancia que prefieras.
Los tipos de instancias que admiten las OpsWorks pilas dependen de si la pila está o no en una VPC. Los tipos de instancia también están limitados si su cuenta está utilizando la capa gratuita de AWS. La lista desplegable **Size (Tamaño)** muestra los tipos de instancia admitidos para la versión de Chef compatible con su pila. Tenga en cuenta que es posible que las microinstancias como t1.micro no tengan suficientes recursos para admitir algunas capas. Para obtener más información, consulte [Tipos de instancia ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html).
Si está utilizando [instancias con carga balanceada](workinginstances-autoscaling-loadbased.md), tenga en cuenta que la [Configuración de los eventos del ciclo de vida](workingcookbook-events.md) puede producir un importante pico de carga de CPU que puede durar un minuto o más. Con instancias más pequeñas, este pico de carga puede ser suficiente para desencadenar un incremento, en particular en el caso de pilas con grandes cargas balanceadas y eventos Configure frecuentes. A continuación se muestran algunas formas de reducir la probabilidad de que un evento Configure cause un incremento innecesario.
+ Utilice instancias más grandes, de forma que la carga adicional de un evento Configure no sea suficiente para desencadenar un incremento.
+ No utilice tipos de instancia como T2, que comparte recursos de CPU.
Esto garantiza que cuando se produzca un evento Configure, todos los recursos de la CPU de la instancia estén disponibles inmediatamente.
+ Haga que el tiempo de `exceeded threshold` sea significativamente más largo que el tiempo necesario para procesar un evento Configure (quizás 5 minutos).
Para obtener más información, consulte [Uso del escalado automático basado en carga](workinginstances-autoscaling-loadbased.md).
**Availability Zone/Subnet**
Si la pila no está en una VPC, esta opción se etiqueta como ** Availability Zone (Zona de disponibilidad)** y muestra una lista de zonas de la región. Puede utilizar esta opción para anular la zona de disponibilidad predeterminada que especificó al crear la pila.
Si la pila se ejecuta en una VPC, esta opción se etiqueta como **Subnet (Subred)** y muestra una lista de subredes de VPC. Puede utilizar esta opción para anular la subred predeterminada que especificó al crear la pila.
De forma predeterminada, OpsWorks Stacks muestra los rangos de CIDR de la subred. Para que la lista sea más legible, usa la consola de VPC o la API para agregar una etiqueta a cada subred con la **clave** **Name** y el **valor** establecidos en el nombre de la subred. OpsWorks Stacks agrega ese nombre al rango CIDR. En el ejemplo anterior, la etiqueta Name de la subred se establece en **Private**.
**Scaling Type**
Determina cómo se inicia y se detiene la instancia.
+ El valor predeterminado es una instancia de **24/7** que se inicia y se detiene manualmente.
+ OpsWorks Stacks inicia y detiene las instancias **basadas en el tiempo** según un cronograma específico.
+ (Solo para Linux) OpsWorks Stacks inicia y detiene las instancias **basadas en la carga** según las métricas de carga especificadas.
No puede iniciar ni parar usted mismo instancias basadas en el tiempo o en la carga. En su lugar, configuras las instancias y OpsWorks Stacks las inicia y detiene según la configuración. Para obtener más información, consulte [Gestión de la carga con instancias basadas en tiempo y en carga](workinginstances-autoscaling.md).
**SSH key**
Un EC2 key pair de Amazon. OpsWorks Stacks instala la clave pública en la instancia.
+ En el caso de las instancias de Linux, puede utilizar la correspondiente clave privada con un cliente SSH para [iniciar sesión en la instancia](workinginstances-ssh.md).
+ En cuanto a las instancias de Windows, puede utilizar la clave privada correspondiente para [recuperar la contraseña de administrador de la instancia](workinginstances-rdp.md#workinginstances-rdp-admin). A continuación, puede utilizar la contraseña con RDP para iniciar sesión en la instancia como administrador.
Inicialmente, esta opción es el valor **Default SSH key (Clave SSH predeterminada)** que especificó al crear la pila.
+ Si el valor predeterminado está establecido en **No usar una clave SSH predeterminada**, puedes especificar una de EC2 las claves de Amazon de tu cuenta.
+ Si el valor predeterminado se establece en una EC2 clave de Amazon, puedes especificar una clave diferente o ninguna clave.
**Sistema operativo**
**El sistema operativo** especifica el sistema operativo que ejecuta la instancia. OpsWorks Stacks solo admite sistemas operativos de 64 bits.
Inicialmente, esta opción es el valor **Default operating system (Sistema operativo predeterminado)** que especificó al crear la pila. Puede anular el valor predeterminado para especificar otro sistema operativo Linux o una imagen de máquina de Amazon (AMI) personalizada. Sin embargo, no puede cambiar de Linux a Windows o viceversa.
Si selecciona **Usar AMI personalizada**, la página mostrará una lista de **dispositivos personalizados AMIs en lugar de los de **arquitectura** y raíz**.
![\[+Instance para instancias nuevas en la página Instances\]](http://docs.aws.amazon.com/es_es/opsworks/latest/userguide/images/add_instance_ami.png)
Para obtener más información, consulte [Uso de Custom AMIs](workinginstances-custom-ami.md).
**OpsWorks Versión del agente**
OpsWorks La **versión del agente** especifica la versión del agente de OpsWorks Stacks que quieres ejecutar en la instancia. Si quiere que OpsWorks Stacks actualice automáticamente al agente, elija **Inherit from stack (Heredar de pila)**. Para instalar una versión específica del agente y actualizar manualmente el agente en la instancia, seleccione una versión en la lista desplegable.
No todas las versiones del agente funcionan con todas las versiones del sistema operativo. Si tu instancia ejecuta un agente (o si instalas un agente en una instancia) que no es totalmente compatible con el sistema operativo de la instancia, la consola de OpsWorks Stacks muestra mensajes de error que te indican que instales un agente compatible.
**Propiedad**
Elija la opción de propiedad para su instancia. Puede elegir ejecutar sus instancias en servidores físicos totalmente dedicados a su uso.
+ **Default - Rely on VPC settings (Predeterminado - basado en configuración VPC)**. Sin propiedad o hereda la configuración de la propiedad de su VPC.
+ **Dedicated - Run a dedicated instance (Predeterminado - ejecución en una instancia dedicada)**. Pague por hora las instancias que se ejecutan en hardware de un solo propietario. Para obtener más información, consulte [Instancias dedicadas](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/dedicated-instance.html) en la Guía del usuario de Amazon VPC e Instancias [ EC2 dedicadas de Amazon](https://aws.amazon.com/ec2/purchasing-options/dedicated-instances/).
+ **Dedicated host - Run this instance on a dedicated host (Host dedicado - ejecutar esta instancia en un host dedicado)**. Pague por un host físico dedicado exclusivamente a ejecutar sus instancias y utilice sus propias licencias de software por conector, por núcleo o por VM para reducir costos. Para obtener más información, consulte [Descripción general de los hosts dedicados](https://aws.amazon.com/ec2/dedicated-hosts/) en la EC2 documentación de Amazon y [Amazon EC2 Dedicated Hosts](https://aws.amazon.com/ec2/dedicated-hosts/).
**Root device type**
Especifica el almacenamiento del dispositivo raíz de la instancia.
+ Las instancias de Linux pueden tener el respaldo en Amazon EBS o en el almacén de instancias.
+ Las instancias de Windows deben tener el respaldo en Amazon EBS.
Para obtener más información, consulte [Almacenamiento](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Storage.html).
Tras el arranque inicial, las instancias respaldadas por Amazon EBS se inician más rápido que las instancias respaldadas por el almacén de instancias, ya que OpsWorks Stacks no tiene que volver a instalar el software de la instancia desde cero. Para obtener más información, consulte [Almacenamiento de dispositivo raíz](best-practices-storage.md).
**Tipo de volumen**
Especifica el tipo de volumen de dispositivo raíz: **Magnetic (Magnético)**, **Provisioned IOPS (SSD) (IOPS provisionadas (SSD))** o **General Purpose (SSD) (Uso general (SSD))**. Para obtener más información, consulte [Tipos de volúmenes de Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html).
**Tamaño del volumen**
Especifica el tamaño del volumen de dispositivo raíz para el tipo de volumen especificado. Para obtener más información, consulte [Tipos de volúmenes de Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html).
+ **General Purpose (SSD) (Uso general (SSD))**. El tamaño mínimo permitido es 8 GiB, mientras que el tamaño máximo es 16384 GiB.
+ **Provisioned IOPS (SSD) (IOPS provisionadas (SSD))**. El tamaño mínimo permitido es 8 GiB, mientras que el tamaño máximo es 16384 GiB. Puedes establecer un mínimo de 100 input/output operaciones por segundo (IOPS) y un máximo de 240 IOPS.
+ **Magnetic (Magnético)**. El tamaño mínimo permitido es 8 GiB, mientras que el tamaño máximo es 1024 GiB.
1. Elija **Add Instance (Añadir instancia)** para crear la nueva instancia.
**nota**
No puede anular la opción de [versión de agente predeterminada de la pila](workingstacks-creating.md#workingstacks-creating-advanced-agent) cuando crea una instancia. Para especificar una opción de versión de agente personalizada, cree la instancia y, a continuación, [edite su configuración](workinginstances-properties.md).
**Para añadir una instancia ya existente a una capa**
1. En la página **Instances (Instancias)**, elija **\$1Instance (\$1Instancia)** para la capa adecuada y, a continuación, abra la pestaña **Existing (Existente)**.
**nota**
Si cambia de opinión sobre el uso de una instancia ya existente, elija **New (Nuevo)** para crear una instancia nueva, tal y como se describe en el procedimiento anterior.
1. En la pestaña **Existing (Existente)**, seleccione una instancia de la lista.
1. Elija **Add Instance (Añadir instancia)** para crear la nueva instancia.
Una instancia representa una EC2 instancia de Amazon, pero básicamente es solo una estructura de datos de OpsWorks Stacks. Se debe iniciar una instancia para crear una EC2 instancia de Amazon en ejecución, tal y como se describe en las siguientes secciones.
**importante**
Si lanza instancias en una VPC predeterminada, debe ser precavido a la hora de modificar la configuración de VPC. Las instancias deben poder comunicarse siempre con el servicio OpsWorks Stacks, Amazon S3 y los repositorios de paquetes. Si, por ejemplo, eliminas una puerta de enlace predeterminada, las instancias perderán su conexión con el servicio OpsWorks Stacks, que luego tratará las instancias como fallidas y las reparará [automáticamente](workinginstances-autohealing.md). Sin embargo, OpsWorks Stacks no podrá instalar el agente de la instancia en las instancias recuperadas. Sin un agente, las instancias no podrán comunicarse con el servicio y el proceso de puesta en marcha no superará el estado `booting`. Para obtener más información acerca de la VPC predeterminada, consulte [Plataformas compatibles](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-supported-platforms.html).
También puedes incorporar recursos informáticos de Linux en una pila que se haya creado fuera de OpsWorks Stacks:
+ EC2 Instancias de Amazon que creó directamente mediante la EC2 consola, la CLI o la API de Amazon.
+ Las instancias *on-premises* que se ejecutan en su propio hardware, incluidas las instancias que se ejecutan en máquinas virtuales
Para obtener más información, consulte [Uso de recursos informáticos creados fuera de OpsWorks Stacks](registered-instances.md).
# Uso de Custom AMIs
**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 existentes. 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](https://repost.aws/) o a través de Premium [AWS Support](https://aws.amazon.com/support).
OpsWorks Stacks admite dos formas de personalizar las instancias: [Amazon Machine Images (AMIs)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html) personalizadas y recetas de Chef. Ambos enfoques le permiten controlar qué paquetes y versiones de paquete se instalan, cómo se configuran, etc. Sin embargo, cada uno tiene diferentes ventajas, por lo que el mejor enfoque dependerá de sus necesidades.
A continuación, se enumeran los motivos más importantes para utilizar una AMI personalizada:
+ Desea realizar un empaquetado previo de paquetes concretos en lugar de instalarlos una vez que la instancia se ha iniciado.
+ Desea controlar cuándo se producirán las actualizaciones de paquetes para proporcionar a la capa una imagen base coherente.
+ Desea instancias [basadas en carga](workinginstances-autoscaling.md) en particular, para arrancar lo más rápido posible.
A continuación, se enumeran los motivos más importantes para utilizar las recetas de Chef:
+ Son más flexibles que las personalizadas AMIs.
+ Son más fáciles de actualizar.
+ Pueden actualizar las instancias que se están ejecutando.
En la práctica, la mejor solución puede ser una combinación de ambos enfoques. Para obtener más información acerca de las recetas, consulte [Cookbooks and Recipes](workingcookbook.md).
**Topics**
+ [Cómo AMIs funciona Custom con OpsWorks Stacks](#workinginstances-custom-ami-work)
+ [Creación de una AMI personalizada para OpsWorks Stacks](#workinginstances-custom-ami-create)
## Cómo AMIs funciona Custom con OpsWorks Stacks
Para especificar una AMI personalizada para las instancias, selecciona **Usar una AMI personalizada** como sistema operativo de la instancia al crear una nueva instancia. OpsWorks A continuación, Stacks muestra una lista de las personalizadas AMIs de la región de la pila y tú seleccionas la que corresponda de la lista. Para obtener más información, consulte [Añadir una instancia a una capa](workinginstances-add.md).
**nota**
No puede especificar una AMI personalizada determinada como el sistema operativo predeterminado de una pila. Puede definir `Use custom AMI` como el sistema operativo predeterminado de la pila, pero solo puede especificar una AMI determinada si añade nuevas instancias a las capas. Para obtener más información, consulte [Añadir una instancia a una capa](workinginstances-add.md) y [Crear una pila nueva](workingstacks-creating.md). Si bien es posible crear instancias con otros sistemas operativos (como CentOS 6). *x*) que se hayan creado a partir de datos personalizados o generados por la comunidad AMIs, no se admiten oficialmente.
Este tema trata algunas cuestiones generales que debería tener en cuenta antes de crear o utilizar una AMI personalizada.
**Topics**
+ [Comportamiento de inicio](#workinginstances-custom-ami-work-startup)
+ [Elección de una capa](#workinginstances-custom-ami-work-layer)
+ [Administración de aplicaciones](#workinginstances-custom-ami-work-apps)
### Comportamiento de inicio
Cuando inicias la instancia, OpsWorks Stacks usa la AMI personalizada especificada para lanzar una nueva EC2 instancia de Amazon. OpsWorks Luego, Stacks usa [cloud-init](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonLinuxAMIBasics.html#included-aws-command-line-tools) para instalar el agente de OpsWorks Stacks en la instancia y el agente ejecuta las recetas de configuración de la instancia seguidas de las de implementación. Cuando la instancia esté online, el agente ejecutará las recetas de configuración en todas las instancias de la pila, también en la instancia que acaba de añadir.
### Elección de una capa
El agente de OpsWorks Stacks no suele entrar en conflicto con los paquetes instalados. Sin embargo, la instancia debe ser miembro de al menos una capa. OpsWorks Stacks siempre ejecuta las recetas de esa capa, lo que podría causar problemas. Debe saber qué hacen exactamente las recetas de una capa en una instancia antes de añadir una instancia con una AMI personalizada a dicha capa.
Para ver qué recetas ejecuta un determinado tipo de capa en la instancia, abra una pila que incluya la capa en cuestión. A continuación, haga clic en **Layers (Capas)** en el panel de navegación y, a continuación, en **Recipes (Recetas)** en la capa. Para ver el código real, haga clic en el nombre de la receta.
**nota**
En el caso de Linux AMIs, una forma de reducir la posibilidad de conflictos consiste en utilizar OpsWorks Stacks para aprovisionar y configurar la instancia que constituye la base de la AMI personalizada. Para obtener más información, consulte [Cree una AMI de Linux personalizada a partir de una instancia de OpsWorks Stacks](#workinginstances-custom-ami-create-opsworks).
### Administración de aplicaciones
Además de paquetes, es posible que también desee incluir una aplicación en la AMI. Si tiene una aplicación compleja y de gran tamaño, incluirla en la AMI puede reducir el tiempo de inicio de la instancia. Puede incluir aplicaciones pequeñas en su AMI, pero normalmente la ventaja de tiempo en relación con la implementación de la aplicación por parte de OpsWorks Stacks es mínima o nula.
Una opción es incluir la aplicación en la AMI y también [crear una aplicación](workingapps-creating.md) que la implemente en las instancias de un repositorio. Este enfoque reduce el tiempo de inicio, pero también constituye una forma fácil de actualizar la aplicación si la instancia se está ejecutando. Tenga en cuenta que las recetas de Chef son idempotentes, lo que significa que las recetas de implementación no modificarán la aplicación si la versión del repositorio es la misma que la de la instancia.
## Creación de una AMI personalizada para OpsWorks Stacks
Para usar una AMI personalizada con OpsWorks Stacks, primero debes crear una AMI a partir de una instancia personalizada. Puede elegir entre dos opciones.
+ Usa la EC2 consola o la API de Amazon para crear y personalizar una instancia, basada en una versión de 64 bits de una de las compatibles con [OpsWorks Stacks AMIs](workinginstances-os.md).
+ En el caso de Linux AMIs, se utiliza OpsWorks para crear una EC2 instancia de Amazon en función de la configuración de sus capas asociadas.
Antes de crear una AMI de Linux personalizada, inhabilita `noexec` la `/tmp` partición para permitir que OpsWorks Stacks instale su agente en instancias de Linux personalizadas.
**nota**
Tenga en cuenta que es posible que una AMI no funcione en todos los tipos de instancias, por lo que deberá asegurarse de que la AMI de origen es compatible con los tipos de instancia que va a utilizar. En concreto, los tipos de instancia [R3](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/r3-instances.html) necesitan una AMI de virtualización asistida por hardware (HVM).
A continuación, utiliza la EC2 consola o la API de Amazon para crear una AMI personalizada a partir de la instancia personalizada. Puede usar su personalización AMIs en cualquier pila que esté en la misma región añadiendo una instancia a una capa y especificando su AMI personalizada. Para obtener más información sobre cómo crear una instancia que utilice una AMI personalizada, consulte [Añadir una instancia a una capa](workinginstances-add.md).
**nota**
De forma predeterminada, OpsWorks Stacks instala todas las actualizaciones de Amazon Linux en el arranque, lo que te proporciona la versión más reciente. Además, Amazon Linux publica una versión nueva aproximadamente cada seis meses, lo que puede conllevar cambios significativos. De forma predeterminada, las versiones personalizadas AMIs basadas en Amazon Linux se actualizan automáticamente a la nueva versión cuando se publica. La práctica recomendada es bloquear la AMI personalizada en una versión específica de Amazon Linux y aplazar la actualización hasta que haya probado la nueva versión. Para obtener más información, consulte [¿Cómo puedo bloquear la AMI para una versión concreta?](https://aws.amazon.com/amazon-linux-ami/faqs/#lock)
**Topics**
+ [Cree una AMI personalizada con Amazon EC2](#workinginstances-custom-ami-create-ec2)
+ [Cree una AMI de Linux personalizada a partir de una instancia de OpsWorks Stacks](#workinginstances-custom-ami-create-opsworks)
+ [Creación de una AMI de Windows personalizada](#w2ab1c14c55c15c13c21c20)
### Cree una AMI personalizada con Amazon EC2
La forma más sencilla de crear una AMI personalizada, y la única opción para Windows AMIs, es realizar toda la tarea mediante la EC2 consola o la API de Amazon. Para obtener más información sobre los siguientes pasos, consulta [Cómo crear la tuya](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/creating-an-ami.html) propia. AMIs
**Para crear una AMI personalizada mediante la EC2 consola o la API de Amazon**
1. Cree una instancia con una versión de 64 bits de una de las versiones compatibles con [OpsWorks Stacks AMIs](workinginstances-os.md).
1. Personalice la instancia a partir del paso 1; configúrela, instale los paquetes, etc. Recuerde que todo lo que instale se reproducirá en todas las instancias basadas en la AMI, por lo que se recomienda no incluir elementos que deberían ser específicos de una determinada instancia.
1. Detenga la instancia y cree una AMI personalizada.
### Cree una AMI de Linux personalizada a partir de una instancia de OpsWorks Stacks
Si quieres usar una instancia de OpsWorks Stacks Linux personalizada para crear una AMI, ten en cuenta que cada EC2 instancia de Amazon creada por OpsWorks incluye una identidad única. Si crea una AMI personalizada a partir de una instancia de este tipo, contendrá la identidad y todas las instancias basadas en esa AMI tendrán la misma identidad. Para garantizar que la instancia basada en la AMI personalizada tiene una identidad única, debe eliminar la identidad de la instancia personalizada antes de crear la AMI.
**Para crear una AMI personalizada a partir de una instancia de OpsWorks Stacks**
1. [Cree una pila de Linux](workingstacks-creating.md) y [agregue una o varias capas](workinglayers-basics-create.md) para definir la configuración de la instancia personalizada. Puede utilizar las capas integradas personalizadas según sea necesario, o también capas totalmente personalizadas. Para obtener más información, consulte [Personalizar Stacks OpsWorks](customizing.md).
1. [Edita las capas](workinglayers-basics-edit.md) y AutoHealing desactívalas.
1. [Añada una instancia con su distribución de Linux preferida](workinginstances-add.md) a la capa o capas e [iníciela](workinginstances-starting.md). Le recomendamos que utilice una instancia respaldada por Amazon EBS. Abre la página de detalles de la instancia y registra su Amazon EC2 ID para más adelante.
1. Cuando la instancia esté online, [inicie sesión con SSH](workinginstances-ssh.md) y realice uno de los cuatro pasos siguientes, según el sistema operativo de la instancia.
1. En el caso de una instancia de Amazon Linux en una pila de Chef 11 o Chef 12 o una instancia de Red Hat Enterprise Linux 7 en una pila de Chef 11, haga lo siguiente.
1. `sudo /etc/init.d/monit stop`
1. `sudo /etc/init.d/opsworks-agent stop`
1. `sudo rm -rf /etc/aws/opsworks/ /opt/aws/opsworks/ /var/log/aws/opsworks/ /var/lib/aws/opsworks/ /etc/monit.d/opsworks-agent.monitrc /etc/monit/conf.d/opsworks-agent.monitrc /var/lib/cloud/ /etc/chef`
**nota**
En el caso de instancias en una pila de Chef 12, añada las siguientes dos carpetas a este comando:
`/var/chef`
`/opt/chef`
1. `sudo rpm -e opsworks-agent-ruby`
1. `sudo rpm -e chef`
1. En el caso de una instancia de Ubuntu 16.04 LTS o 18.04 LTS en una pila de Chef 12, haga lo siguiente.
1. `sudo systemctl stop opsworks-agent`
1. `sudo rm -rf /etc/aws/opsworks/ /opt/aws/opsworks/ /var/log/aws/opsworks/ /var/lib/aws/opsworks/ /etc/monit.d/opsworks-agent.monitrc /etc/monit/conf.d/opsworks-agent.monitrc /var/lib/cloud/ /var/chef /opt/chef /etc/chef`
1. `sudo apt-get -y remove chef`
1. `sudo dpkg -r opsworks-agent-ruby`
1. `systemctl stop apt-daily.timer`
1. `systemctl stop apt-daily-upgrade.timer`
1. `rm /var/lib/systemd/timers/stamp-apt-daily.timer`
1. `rm /var/lib/systemd/timers/stamp-apt-daily-upgrade.timer`
1. En el caso de otras versiones de Ubuntu compatibles en una pila de Chef 12, haga lo siguiente.
1. `sudo /etc/init.d/monit stop`
1. `sudo /etc/init.d/opsworks-agent stop`
1. `sudo rm -rf /etc/aws/opsworks/ /opt/aws/opsworks/ /var/log/aws/opsworks/ /var/lib/aws/opsworks/ /etc/monit.d/opsworks-agent.monitrc /etc/monit/conf.d/opsworks-agent.monitrc /var/lib/cloud/ /var/chef /opt/chef /etc/chef`
1. `sudo apt-get -y remove chef`
1. `sudo dpkg -r opsworks-agent-ruby`
1. En el caso de una instancia de Red Hat Enterprise Linux 7 en una pila de Chef 12, haga lo siguiente.
1. `sudo systemctl stop opsworks-agent`
1. `sudo rm -rf /etc/aws/opsworks/ /opt/aws/opsworks/ /var/log/aws/opsworks/ /var/lib/aws/opsworks/ /etc/monit.d/opsworks-agent.monitrc /etc/monit/conf.d/opsworks-agent.monitrc /var/lib/cloud/ /etc/chef /var/chef`
1. `sudo rpm -e opsworks-agent-ruby`
1. `sudo rpm -e chef`
1. Este paso depende del tipo de instancia:
+ En el caso de una instancia respaldada por Amazon EBS, usa la consola OpsWorks Stacks para [detener la instancia y crear la](workinginstances-starting.md) AMI, tal y como se describe en Creación de [una AMI de Linux respaldada por Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/creating-an-ami-ebs.html).
+ En el caso de una instancia con respaldo en un almacén de instancias, crea la AMI tal y como se describe en [Cómo crear una AMI de Linux con respaldo en un almacén de instancias y, a continuación, usa OpsWorks la consola Stacks para detener](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/creating-an-ami-instance-store.html) la instancia.
Cuando cree la AMI, asegúrese de incluir los archivos de certificado. Por ejemplo, puede llamar al comando [https://docs.aws.amazon.com/AWSEC2/latest/CommandLineReference/CLTRG-ami-bundle-vol.html](https://docs.aws.amazon.com/AWSEC2/latest/CommandLineReference/CLTRG-ami-bundle-vol.html) con el argumento `-i` establecido en `-i $(find /etc /usr /opt -name '*.pem' -o -name '*.crt' -o -name '*.gpg' | tr '\n' ',')`. No retire las claves públicas de APT cuando realice la agrupación. El comando `ec2-bundle-vol` predeterminado se encarga de esta tarea.
1. Para limpiar tu pila, vuelve a la consola de OpsWorks Stacks y [elimina](workinginstances-delete.md) la instancia de la pila.
### Creación de una AMI de Windows personalizada
Los siguientes procedimientos crean una configuración personalizada AMIs para Windows Server 2022 Base. Puede elegir otros sistemas operativos Windows Server en la consola de EC2 administración de Amazon.
**importante**
Actualmente, el agente de OpsWorks Stacks no se puede instalar en instancias basadas en Windows que utilizan un idioma de interfaz de usuario del sistema distinto del inglés (**Estados Unidos**) (en-US), y OpsWorks Stacks no puede administrarlas.
**Topics**
+ [Creación de una AMI de Windows personalizada con `Sysprep`](#w2ab1c14c55c15c13c21c20b9)
+ [Creación de una AMI de Windows personalizada sin `Sysprep`](#w2ab1c14c55c15c13c21c20c11)
+ [Adición de una nueva instancia mediante el uso de una AMI de Windows personalizada](#w2ab1c14c55c15c13c21c20c13)
#### Creación de una AMI de Windows personalizada con `Sysprep`
Al crear un Windows AMIs personalizado con Sysprep, normalmente el lanzamiento de la instancia es más lento, pero el proceso es más limpio. El inicio por primera vez de una instancia creada a partir de una imagen creada con ella `Sysprep` lleva más tiempo debido a `Sysprep` las actividades, los reinicios, el aprovisionamiento de OpsWorks Stacks y la primera ejecución de OpsWorks Stacks, incluida la instalación y la configuración. Complete los pasos para crear una AMI de Windows personalizada en la EC2 consola de Amazon.
**Para crear una AMI de Windows personalizada con Sysprep**
1. En la EC2 consola de Amazon, selecciona **Launch Instance**.
1. Busque **Microsoft Windows Server 2022 Base** y, a continuación, elija **Seleccionar**.
1. Elija el tipo de instancia que desee y, a continuación, elija **Configure Instance Details (Configurar detalles de la instancia)**. Realice los cambios de configuración en la AMI, incluidos nombre del equipo, almacenamiento y configuración del grupo de seguridad. Elija **Iniciar**.
1. Una vez que el proceso de arranque de la instancia haya finalizado, introduzca la contraseña y conéctese a la instancia en una ventana **Remote Desktop Connection (Conexión de escritorio remota)** de Windows.
1. En la pantalla de **inicio** de Windows, selecciona **Inicio** y comienza a escribir **ec2configservice** hasta que los resultados muestren la **EC2ConfigServiceSettings**consola. Abra la consola de .
1. En la pestaña **General**, asegúrate de que la casilla **Habilitar la UserData ejecución** esté llena (aunque esta opción no es necesaria`Sysprep`, sí lo es para que OpsWorks Stacks instale su agente). Desactive la casilla de verificación de la opción **Set the computer name of the instance... (Establecer el nombre del equipo de la instancia)**, ya que esta opción puede provocar un bucle de reinicio con OpsWorks Stacks.
1. En la pestaña **Imagen**, establece la **contraseña de administrador** en **Aleatoria** para permitir que Amazon EC2 genere automáticamente una contraseña que puedas recuperar con una clave SSH, o en **Especificar** para especificar tu propia contraseña. `Sysprep`guarda esta configuración. Si especifica su propia contraseña, guárdela en un lugar adecuado. Le recomendamos que no elija **Keep Existing (Conservar existente)**.
1. Elija **Apply (Aplicar)** y, a continuación, elija **Shutdown with Sysprep (Cerrar con Sysprep)**. Cuando se le pida confirmación, elija **Yes (Sí)**.
1. Una vez detenida la instancia, en la EC2 consola de Amazon, haz clic con el botón derecho en la instancia de la lista de **instancias**, selecciona **Imagen** y, a continuación, selecciona **Crear imagen**.
1. En la página **Create Image (Crear imagen)**, introduzca un nombre y una descripción para la imagen y especifique la configuración de volumen. Cuando haya terminado, seleccione **Create Image (Crear imagen)**.
1. Abra la página **Images (Imágenes)** y espere a que la imagen pase del estado **pending (pendiente)** a **available (disponible)**. Ya se puede utilizar la nueva AMI.
#### Creación de una AMI de Windows personalizada sin `Sysprep`
Complete los pasos para crear una AMI de Windows personalizada en la EC2 consola de Amazon.
**Para crear una AMI de Windows personalizada sin Sysprep**
1. En la EC2 consola de Amazon, selecciona **Launch Instance**.
1. Busque **Microsoft Windows Server 2022 Base** y, a continuación, elija **Seleccionar**.
1. Elija el tipo de instancia que desee y, a continuación, elija **Configure Instance Details (Configurar detalles de la instancia)**. Realice los cambios de configuración en la AMI, incluidos nombre del equipo, almacenamiento y configuración del grupo de seguridad. Elija **Iniciar**.
1. Una vez que el proceso de arranque de la instancia haya finalizado, introduzca la contraseña y conéctese a la instancia en una ventana **Remote Desktop Connection (Conexión de escritorio remota)** de Windows.
1. En la instancia, abra `C:\Program Files\Amazon\Ec2ConfigService\Settings\config.xml`, cambie los dos valores siguientes y, a continuación, guarde y cierre el archivo:
+ De `Ec2SetPassword` a `Enabled`
+ De `Ec2HandleUserData` a `Enabled`
1. Desconéctese de la sesión de **Escritorio remoto** y vuelva a la EC2 consola de Amazon.
1. En la lista **Instances (Instancias)**, detenga la instancia.
1. Una vez detenida la instancia, en la EC2 consola de Amazon, haz clic con el botón derecho en la instancia de la lista de **instancias**, selecciona **Imagen** y, a continuación, selecciona **Crear imagen**.
1. En la página **Create Image (Crear imagen)**, introduzca un nombre y una descripción para la imagen y especifique la configuración de volumen. Cuando haya terminado, seleccione **Create Image (Crear imagen)**.
1. Abra la página **Images (Imágenes)** y espere a que la imagen pase del estado **pending (pendiente)** a **available (disponible)**. Ya se puede utilizar la nueva AMI.
#### Adición de una nueva instancia mediante el uso de una AMI de Windows personalizada
Una vez que la imagen haya cambiado al estado **available (disponible)**, podrá crear instancias basadas en la AMI de Windows personalizada. Al elegir **Usar AMI de Windows personalizada** en la lista de **sistemas operativos**, OpsWorks Stacks muestra una lista de configuraciones personalizadas AMIs.
**Para añadir una nueva instancia basada en una AMI de Windows personalizada**
1. Cuando tu nueva AMI esté disponible, ve a la consola OpsWorks Stacks, abre la página de **instancias** de una pila de Windows y selecciona **\$1 Instance** en la parte inferior de la página para añadir una nueva instancia.
1. En la pestaña **New (Nueva)**, elija **Advanced (Avanzado)**.
1. En la lista desplegable **Operating system (Sistema operativo)**, elija **Use custom Windows AMI (Usar AMI de Windows personalizada)**.
1. En la lista desplegable **Custom AMI (AMI personalizada)**, seleccione la AMI que ha creado y, a continuación, elija **Add Instance (Añadir instancia)**.
Ahora puede arrancar y ejecutar la instancia.
# Proceso manual de inicio, paro y reinicio de instancias de funcionamiento ininterrumpido
**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 existentes. 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](https://repost.aws/) o a través de Premium [AWS Support](https://aws.amazon.com/support).
**nota**
Puede utilizar instancias de funcionamiento ininterrumpido con pilas de Linux y de Windows.
Después de añadir una instancia ininterrumpida a una capa, debe iniciar la instancia manualmente para lanzar la instancia de Amazon Elastic Compute Cloud (Amazon EC2 ) correspondiente y detenerla manualmente para terminar la EC2 instancia de Amazon. También puedes reiniciar manualmente las instancias que no funcionan correctamente. OpsWorks Stacks inicia y detiene automáticamente las instancias basadas en el tiempo y en la carga. Para obtener más información, consulte [Gestión de la carga con instancias basadas en tiempo y en carga](workinginstances-autoscaling.md).
**importante**
OpsWorks Las instancias de Stacks se deben iniciar, detener y reiniciar solo en la consola. OpsWorks OpsWorks no reconoce las operaciones de inicio, detención o reinicio realizadas en la EC2 consola de Amazon.
**Topics**
+ [Inicio o reinicio de una instancia](#workinginstances-starting-start)
+ [Detener una instancia](#workinginstances-starting-stop)
+ [Reiniciar una instancia](#workinginstances-starting-reboot)
## Inicio o reinicio de una instancia
Para iniciar una nueva instancia, en la página **Instances (Instancias)**, haga clic en **start (iniciar)** en la columna **Actions (Acciones)** de la instancia.
![\[acción de iniciar en la página Instances\]](http://docs.aws.amazon.com/es_es/opsworks/latest/userguide/images/start_instance.png)
También puede crear varias instancias y, a continuación, iniciarlas todas al mismo tiempo haciendo clic en** Start all Instances (Iniciar todas las instancias)**.
Tras iniciar la instancia, OpsWorks Stacks lanza una EC2 instancia de Amazon y arranca el sistema operativo. El proceso de arranque suele tardar unos minutos y suele ser más lento para las instancias Windows que para las instancias Linux. A medida que avanza el arranque, el campo **Status (Estado)** de la instancia muestra la siguiente serie de valores:
1. **solicitado**: OpsWorks Stacks ha llamado al EC2 servicio de Amazon para crear la EC2 instancia de Amazon.
1. **pendiente**: OpsWorks Stacks está esperando a que se inicie la EC2 instancia de Amazon.
1. **arranque: la** EC2 instancia de Amazon se está iniciando.
1. **running\$1setup**: OpsWorks Stacks ha activado el evento Setup y está ejecutando las recetas de la capa, seguidas de sus Setup recetas. Deploy Para obtener más información, consulte [Ejecución de recetas](workingcookbook-executing.md). Si has [añadido libros de cocina personalizados](workingcookbook-installingcustom-enable.md) a la pila, OpsWorks Stacks instala la versión actual desde tu repositorio antes de ejecutar las recetas y. Setup Deploy
1. **online**: ya se puede utilizar la instancia.
Cuando el valor de **Status (Estado)** cambia a **online**, la instancia es totalmente operativa.
+ Si la capa tiene un balanceador de carga adjunto, OpsWorks Stacks le agrega la instancia.
+ OpsWorks Stacks desencadena un Configure evento que ejecuta las recetas de cada instancia. Configure
Según sea necesario, estas recetas actualizan la instancia para adaptarse a la nueva instancia.
+ OpsWorks Stacks reemplaza la acción de **inicio** de la instancia por la de **detener**, que puedes usar para detener la instancia.
Si la instancia no se ha iniciado correctamente o si las recetas Setup han dado error, el estado se define como **start\$1failed** o **setup\$1failed**, respectivamente. Puede examinar los logs para determinar la causa del error. Para obtener más información, consulte [Guía de depuración y solución de problemas](troubleshoot.md).
Una instancia detenida sigue formando parte de la pila y conserva todos los recursos. Por ejemplo, los volúmenes de Amazon EBS y las direcciones IP elásticas siguen asociadas a una instancia detenida. Para reiniciar una instancia detenida, elija **start (iniciar)** en la columna **Actions (Acciones)** de la instancia. Reiniciar una instancia detenida provoca lo siguiente:
+ Instancias respaldadas en almacenes de instancias: OpsWorks Stacks lanza una nueva EC2 instancia de Amazon con la misma configuración.
+ Instancias respaldadas por Amazon EBS: OpsWorks Stacks reinicia la instancia de EC2 Amazon, que vuelve a conectar el volumen raíz.
Cuando la instancia termina de arrancar, OpsWorks Stacks instala las actualizaciones del sistema operativo y ejecuta las recetas y, igual que al Setup inicio inicial. Deploy OpsWorks Stacks también hace lo siguiente para las instancias reiniciadas, según corresponda.
+ Reasocia las direcciones IP elásticas
+ Vuelve a adjuntar volúmenes de Amazon Elastic Block Store (Amazon EBS)
+ Para las instancias respaldadas por el almacén de instancias, instala las últimas versiones del libro de recetas.
Las instancias respaldadas por Amazon EBS continúan utilizando los libros de recetas personalizados que se han almacenado en el volumen raíz. Si los libros de recetas personalizados han cambiado desde que detuvo la instancia, debe actualizarlos manualmente después de que la instancia esté conectada. Para obtener más información, consulte [Actualización de libros de recetas personalizados](workingcookbook-installingcustom-enable-update.md).
**nota**
Puede que tarde unos minutos en volver a asociar una dirección IP elástica a una instancia reiniciada. Tenga en cuenta que el valor de **Elastic IP (IP elástica)** de la instancia representa los metadatos y simplemente indica que la dirección debería asociarse a la instancia. El valor de **Public IP (IP pública)** refleja el estado de la instancia y puede estar vacío inicialmente. Cuando la dirección IP elástica se asocia con la instancia, la dirección se asigna al valor **Public IP (IP pública)**, seguido de (EIP).
## Detener una instancia
**En la página de instancias**, haz clic en **detener** en la columna **Acciones** de la instancia, para avisar a OpsWorks Stacks de que debe ejecutar las recetas de cierre y cerrar la instancia. EC2
![\[acción de parar en la página Instances\]](http://docs.aws.amazon.com/es_es/opsworks/latest/userguide/images/stop_instance.png)
También puede cerrar todas las instancias de stack haciendo clic en **Stop All Instances (Detener todas las instancias)**.
Tras detener la instancia, OpsWorks Stacks realiza varias tareas:
1. Si la capa de la instancia tiene un balanceador de cargas de Elastic Load Balancing adjunto, OpsWorks Stacks anula el registro de la instancia.
Si la capa es compatible con la función de vaciado de la conexión del balanceador de carga, OpsWorks Stacks retrasa el disparo del evento Shutdown hasta que se haya completado el vaciado de la conexión. Para obtener más información, consulte [Capa Elastic Load Balancing](layers-elb.md).
1. OpsWorks Stacks desencadena un Shutdown evento que ejecuta las recetas de la instancia. Shutdown
1. Tras activar el Shutdown evento, OpsWorks Stacks espera un tiempo específico para que las Shutdown recetas terminen y, a continuación, hace lo siguiente:
+ Termina las instancias respaldadas por el almacén de instancias, que elimina todos los datos
+ Detiene las instancias respaldadas por Amazon EBS, lo que mantiene los datos en el volumen raíz
Para obtener más información sobre el almacenamiento de instancias, consulte [Almacenamiento](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Storage.html).
**nota**
El tiempo de espera de cierre predeterminado es de 120 segundos. Si su receta Shutdown necesita más tiempo, puede [editar la configuración de la capa](workinglayers-basics-edit.md) para cambiar el valor.
Puede monitorizar el proceso de cierre consultando la columna **Status (Estado)** de la instancia. A medida que el proceso de cierre avanza, se muestran los siguientes valores:
1. **terminar**: OpsWorks Stacks está finalizando la instancia de Amazon. EC2
1. **shutting\$1down**: OpsWorks Stacks está ejecutando las recetas de la capa. Shutdown
1. **terminada**: la EC2 instancia de Amazon está cancelada.
1. **stopped**: la instancia se ha detenido
## Reiniciar una instancia
En la página **Instances (Instancias)**, haga clic en el nombre de la instancia defectuosa para abrir la página de detalles y, a continuación, haga clic en **Reboot (Reiniciar)**.
![\[Botón Reboot en la página Instances\]](http://docs.aws.amazon.com/es_es/opsworks/latest/userguide/images/reboot_instance.png)
Este comando realiza un reinicio parcial de la EC2 instancia de Amazon asociada. No elimina los datos de la instancia, incluso de las instancias respaldadas por el almacén de instancias, ni dispara [eventos del ciclo de vida](workingcookbook-events.md).
**nota**
Para que las OpsWorks pilas reemplacen automáticamente las instancias fallidas, habilita la reparación automática. Para obtener más información, consulte [Uso de la recuperación automática](workinginstances-autohealing.md).
# Gestión de la carga con instancias basadas en tiempo y en carga
**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 existentes. 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](https://repost.aws/) o a través de Premium [AWS Support](https://aws.amazon.com/support).
A medida que el tráfico entrante varía, la pila puede tener demasiado pocas instancias para gestionar la carga cómodamente o tener más instancias de las necesarias. Puede ahorrar tiempo y dinero si utiliza instancias basadas en tiempo o en carga para aumentar o reducir automáticamente las instancias de una capa para que tenga siempre suficientes instancias para gestionar adecuadamente el tráfico entrante y no tener que pagar por una capacidad innecesaria. De este modo, no tiene que controlar las cargas del servidor o iniciar o finalizar las instancias manualmente. Además, las instancias basadas en tiempo y en carga distribuyen, escalan y compensan automáticamente las aplicaciones entre distintas zonas de disponibilidad dentro de una región, lo que ofrece redundancia geográfica y escalabilidad.
El escalado automático se basa en dos tipos de instancia, que se ajustan a las instancias online de la capa en función de diferentes criterios:
+ Instancias **Time-based (Basadas en tiempo)**
Permiten que una pila gestione cargas que siguen un patrón predecible incluyendo las instancias que se ejecutan solo en determinados momentos o en determinados días. Por ejemplo, puede iniciar algunas instancias después de las seis de la tarde para realizar tareas de copia de seguridad nocturnas o detener algunas instancias durante los fines de semana cuando el tráfico es menor.
+ Instancias **Load-based (Basadas en carga)**
Permiten que una pila gestione las cargas variables arrancando instancias adicionales cuando hay mucho tráfico y deteniendo instancias cuando hay poco tráfico, basándose en una de las distintas métricas de carga. Por ejemplo, puedes hacer que OpsWorks Stacks inicie instancias cuando la utilización media de la CPU supere el 80% y detenga las instancias cuando la carga media de la CPU caiga por debajo del 60%.
Para las pilas de Linux se admiten tanto las instancias basadas en tiempo como las basadas en carga, mientras para las pilas de Windows solo se admiten las instancias basadas en tiempo.
A diferencia de las instancias de funcionamiento ininterrumpido, que debe iniciar y detener manualmente, usted no inicia ni detiene las instancias basadas en tiempo o en carga. En su lugar, configuras las instancias y OpsWorks Stacks las inicia o detiene en función de su configuración. Por ejemplo, configuras las instancias basadas en el tiempo para que se inicien y se detengan según un cronograma específico. OpsWorks A continuación, Stacks inicia y detiene las instancias según esa configuración.
Una práctica habitual es utilizar los tres tipos de instancia conjuntamente, tal como se indica a continuación.
+ Un conjunto de instancias de funcionamiento ininterrumpido para gestionar la carga de base. Normalmente, usted solo arranca este tipo de instancias y deja que se ejecuten de forma continua.
+ Un conjunto de instancias basadas en el tiempo, que OpsWorks Stacks inicia y detiene para gestionar las variaciones de tráfico predecibles. Por ejemplo, si el tráfico es mayor durante el horario de trabajo, configuraría las instancias basadas en tiempo para que arranquen por la mañana y se apaguen por la noche.
+ Un conjunto de instancias basadas en la carga, que OpsWorks Stacks inicia y detiene para gestionar las variaciones impredecibles del tráfico. OpsWorks Stacks las inicia cuando la carga se acerca a la capacidad de las instancias de las pilas, las 24 horas del día, los 7 días de la semana y en función del tiempo, y las detiene cuando el tráfico vuelve a la normalidad.
Para obtener más información acerca de cómo utilizar estos tiempos de escalado, consulte [Optimización del número de servidores](best-practices-autoscale.md).
**nota**
Si has creado aplicaciones para la capa de las instancias o has creado libros de cocina personalizados, OpsWorks Stacks implementa automáticamente la última versión en las instancias basadas en el tiempo y en la carga cuando se inician por primera vez. Sin embargo, OpsWorks Stacks no utiliza necesariamente los libros de cocina más recientes para reiniciar las instancias sin conexión. Para obtener más información, consulte [Edición de aplicaciones](workingapps-editing.md) y [Actualización de libros de recetas personalizados](workingcookbook-installingcustom-enable-update.md).
**Topics**
+ [Uso del escalado automático basado en tiempo](workinginstances-autoscaling-timebased.md)
+ [Uso del escalado automático basado en carga](workinginstances-autoscaling-loadbased.md)
+ [Diferencia entre el escalado basado en carga y la recuperación automática](#workinginstances-autoscaling-differs)
# Uso del escalado automático basado en tiempo
**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 existentes. 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](https://repost.aws/) o a través de Premium [AWS Support](https://aws.amazon.com/support).
El escalado basado en el tiempo le permite controlar el número de instancias que una capa debe tener en línea en determinados momentos del día o días de la semana. Para ello, puede iniciar o detener las instancias según un cronograma específico. OpsWorks Stacks comprueba cada dos minutos e inicia o detiene las instancias según sea necesario. Deberá especificar la programación por separado para cada instancia, tal y como se indica a continuación:
+ Hora del día. Por ejemplo, puede ejecutar más instancias durante el día que por la noche.
+ Día de la semana. Por ejemplo, puede ejecutar más instancias entre semana que los fines de semana.
**nota**
No puede especificar fechas determinadas.
**Topics**
+ [Añadir una instancia basada en tiempo a una capa](#workinginstances-autoscaling-timebased-add)
+ [Configuración de una instancia basada en tiempo](#workinginstances-autoscaling-timebased-configure)
## Añadir una instancia basada en tiempo a una capa
Puede añadir una nueva instancia basada en tiempo a una capa o utilizar una instancia existente.
**Para añadir una nueva instancia basada en tiempo**
1. En la página **Instancias**, haga clic en **\$1 Instancia** para añadir una instancia. En la pestaña **Nuevo**, seleccione **Avanzado** y, a continuación, seleccione **Basado en el tiempo**.
![\[Opción de escalado basada en tiempo en la página Add instance\]](http://docs.aws.amazon.com/es_es/opsworks/latest/userguide/images/time_based_instances.png)
1. Configurar la instancia A continuación, haga clic en **Añadir instancia** para añadir la instancia a la capa.
**Para añadir una instancia basada en tiempo a una capa**
1. En la página **Instancias basadas en tiempo**, haga clic en **\$1 Instancia** si una capa ya dispone de una instancia basada en tiempo. De lo contrario, haga clic en **Añadir una instancia basada en tiempo**. A continuación, seleccione la pestaña **Existente**.
![\[Añadir una instancia basada en tiempo a una capa\]](http://docs.aws.amazon.com/es_es/opsworks/latest/userguide/images/time_based_instances_existing.png)
1. En la pestaña **Existente**, seleccione una instancia de la lista. La lista muestra únicamente instancias basadas en tiempo.
**nota**
Si cambia de opinión sobre el uso de una instancia existente, haga clic en la pestaña **Nueva** para crear una instancia nueva, tal y como se describe en el procedimiento anterior.
1. Haga clic en **Añadir instancia** para añadir la instancia a la capa.
## Configuración de una instancia basada en tiempo
Después de añadir una instancia basada en tiempo a una capa, debe configurar su programación de la siguiente manera.
**Para configurar una instancia basada en tiempo**
1. En el panel de navegación, haga clic en **Basada en tiempo** bajo **Instancias**.
1. Especifique los períodos online para cada instancia basada en tiempo haciendo clic en las casillas correspondientes debajo de la hora deseada.
+ Para utilizar la misma programación cada día, haga clic en la pestaña **Cada día** y, a continuación, especifique los períodos de tiempo online.
+ Para utilizar diferentes programaciones en diferentes días, haga clic en cada día y seleccione los períodos de tiempo correspondientes.
![\[Programación para el escalado basado en tiempo\]](http://docs.aws.amazon.com/es_es/opsworks/latest/userguide/images/time_based.png)
**nota**
Asegúrate de tener en cuenta el tiempo que se tarda en iniciar una instancia y de que OpsWorks Stacks compruebe solo cada pocos minutos si las instancias se deben iniciar o detener. Por ejemplo, si una instancia debe ejecutarse a la 1:00 UTC, iníciela a las 0:00 UTC. De lo contrario, es posible que OpsWorks Stacks no inicie la instancia hasta varios minutos después de la 1:00 UTC y que la instancia tarde varios minutos más en estar en línea.
Puede cambiar los períodos de tiempo en línea de una instancia en cualquier momento siguiendo los pasos anteriores. La próxima vez que OpsWorks Stacks lo compruebe, utilizará la nueva programación para determinar si debe iniciar o detener las instancias.
**nota**
También puede añadir una nueva instancia basada en tiempo a una capa obteniendo acceso a la página **Basada en tiempo** y haciendo clic en **Añadir una instancia basada en tiempo** (si todavía no ha añadido ninguna instancia basada en tiempo a la capa) o **\$1 Instancia** (si la capa ya tiene una o varias instancias basadas en tiempo). A continuación, configure la instancia tal y como se describe en los pasos anteriores.
# Uso del escalado automático basado en carga
**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](https://repost.aws/) o a través de Premium [AWS Support](https://aws.amazon.com/support).
Las instancias basadas en la carga te permiten iniciar o detener las instancias rápidamente en respuesta a los cambios en el tráfico entrante. OpsWorks Stacks usa CloudWatch los datos de [Amazon](https://aws.amazon.com/cloudwatch/) para calcular las siguientes métricas para cada capa, que representan valores promedio en todas las instancias de la capa:
+ CPU: el consumo medio de CPU, como el 80 %
+ Memoria: el consumo medio de memoria, como el 60 %
+ Carga: el trabajo computacional medio de un sistema en un minuto
Puede definir umbrales *de incremento* y *de reducción* para una o todas estas métricas. También puedes usar CloudWatch alarmas personalizadas como umbrales.
Cruzar un umbral dispara un *evento de escalado*. Puede determinar cómo responde OpsWorks Stacks a eventos de escalado especificando lo siguiente:
+ El número de instancias a iniciar o detener.
+ Cuánto tiempo deben esperar OpsWorks las pilas tras superar un umbral antes de iniciar o eliminar instancias. Por ejemplo, el uso de la CPU debe superar el umbral durante al menos 15 minutos. Este valor le permite pasar por alto las fluctuaciones de tráfico cortas.
+ Cuánto tiempo debe esperar OpsWorks Stacks después de iniciar o detener las instancias antes de volver a monitorizar las métricas. En general, querrá permitir suficiente tiempo para que las instancias iniciadas se conecten o para que las instancias detenidas se desconecten antes de evaluar si la capa sigue superando un umbral.
Cuando se produce un evento de escalado, OpsWorks Stacks inicia o detiene solo las instancias basadas en la carga. No inicia ni finaliza instancias de funcionamiento ininterrumpido o ni las basadas en tiempo.
**nota**
El escalado automático basado en carga no crea instancias nuevas y solo inicia y detiene aquellas instancias que haya creado. Por lo tanto, debe disponer de suficientes instancias basadas en carga de antemano para gestionar la máxima carga prevista.
**Para crear una instancia basada en carga**
1. En la página **Instancias**, haga clic en **\$1 Instancia** para añadir una instancia. Seleccione **Avanzado** y, a continuación, seleccione Basado en la **carga**.
![\[Opción de escalado basado en carga en la página Add instance\]](http://docs.aws.amazon.com/es_es/opsworks/latest/userguide/images/load_based_instances.png)
1. Elija la instancia y, a continuación, **Añadir instancia** para añadir otra instancia a la capa.
Repita este procedimiento hasta que se haya creado un número suficiente de instancias. Puede añadir o eliminar instancias más tarde, según sea necesario.
Después de añadir las instancias basada en carga a una capa, debe activar el escalado basado en carga y especificar su configuración. La configuración del escalado basado en carga es una propiedad de la capa, no de la instancia, que especifica cuándo deben iniciarse o detenerse sus instancias basadas en carga. Debe especificarse por separado para cada capa que utiliza instancias basadas en carga.
**Para activar y configurar el escalado automático basado en carga**
1. En el panel de navegación, bajo **Instancias**, haga clic en **Basada en carga** y, a continuación, elija **editar** para la capa correspondiente.
![\[acción de editar en la capa de la instancia\]](http://docs.aws.amazon.com/es_es/opsworks/latest/userguide/images/load_based.png)
1. Ajuste **Escalado automático basado en carga activado** en **Sí**. A continuación, establezca los parámetros del umbral y del escalado para definir cómo y cuándo añadir o eliminar instancias.
![\[Umbrales para el escalado basado en carga\]](http://docs.aws.amazon.com/es_es/opsworks/latest/userguide/images/load_based_config.png)
**Umbrales medios por capa**
Puede establecer umbrales de escalado en función de los siguientes valores, que son valores medios de todas las instancias de la capa.
+ **Average CPU**: el uso medio de la CPU de la capa, como porcentaje del total.
+ **Average memory**: el uso medio de la memoria de la capa, como porcentaje del total.
+ **Average load**: la carga media de la capa.
Para obtener más información sobre cómo se calcula la carga, consulte [Cargar (computing)](http://en.wikipedia.org/wiki/Load_(computing)).
Al cruzar un umbral, se produce un evento de escalado, que se amplía si se necesitan más instancias y se reduce si se necesitan menos instancias. OpsWorks A continuación, Stacks añade o elimina instancias en función de los parámetros de escalado.
**Alarmas personalizadas CloudWatch **
Puede utilizar hasta cinco CloudWatch alarmas personalizadas como umbrales de aumento o reducción de escala. Las alarmas deben estar en la misma región que la pila. Para obtener más información sobre cómo crear alarmas personalizadas, consulte [Creación de CloudWatch alarmas de Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/AlarmThatSendsEmail.html).
Para utilizar alarmas personalizadas, debe actualizar el rol de servicio para permitir `cloudwatch:DescribeAlarms`. Puedes hacer que OpsWorks Stacks actualice el rol por ti la primera vez que utilices esta función o puedes editar el rol manualmente. Para obtener más información, consulte [¿Permitir que OpsWorks Stacks actúe en tu nombre](opsworks-security-servicerole.md).
Cuando hay varias alarmas configuradas para la configuración basada en la carga, si una alarma está en el estado de alarma de métrica`INSUFFICIENT_DATA`, el escalado de instancias basado en la carga no puede producirse aunque haya otra alarma en el estado `ALARM`. El escalado automático solo puede continuar si todas las alarmas están en los estados `OK` o`ALARM`. Para obtener más información sobre el uso de CloudWatch las alarmas de Amazon, consulta [Uso de CloudWatch las alarmas de Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) en la *Guía del CloudWatch usuario de Amazon*.
**Parámetros de escalado**
Los siguientes parámetros controlan la forma en que OpsWorks Stacks gestiona los eventos de escalado.
+ **Start servers in batches of**: el número de instancias a añadir o eliminar cuando se produce un evento de escalado.
+ **Si se superan los umbrales**: cantidad de tiempo (en minutos) que la carga debe permanecer por encima de un umbral de escalado o por debajo de un umbral de escalado descendente antes de que OpsWorks Stacks desencadene un evento de escalado.
+ **Después de escalar, ignora las métricas**: cantidad de tiempo (en minutos) que OpsWorks Stacks debe ignorar las métricas y suprimir los eventos de escalado adicionales después de que se produzca un evento de escalado.
Por ejemplo, OpsWorks Stacks agrega nuevas instancias después de un evento de escalado, pero las instancias no comenzarán a reducir la carga hasta que se hayan iniciado y configurado. No tiene sentido plantear eventos de escalado adicionales hasta que las nuevas instancias estén online ni tampoco gestionar las solicitudes, lo que suele tardar unos minutos. Esta configuración le permite ordenar a OpsWorks Stacks que suprima los eventos de escalado durante suficiente tiempo para que las nuevas instancias tenga tiempo para conectarse.
También puede aumentar esta configuración para evitar oscilaciones bruscas en el escalado cuando los promedios de la capa como **CPU medio**, **Memoria media** o **Carga media** no concuerdan temporalmente.
Por ejemplo, si el uso de la CPU supera el límite y el uso de la memoria está a punto de reducirse, un evento de incremento de la instancia podría ir seguido inmediatamente por un evento de reducción de memoria. para evitar que ocurra esto, puede aumentar el número de minutos en la configuración de **Tras el escalado, ignorar las métricas**. En el ejemplo mencionado, se produciría el escalado de la CPU, pero no se produciría el evento de reducción de la memoria.
1. Para añadir más instancias basadas en carga, haga clic en **\$1 Instancia** para configurar los valores y, a continuación, haga clic en **Añadir instancia**. Repita esta acción hasta que haya suficientes instancias basadas en carga para gestionar la máxima carga prevista. A continuación, elija **Guardar**.
**nota**
También puede añadir una nueva instancia basada en carga a una capa obteniendo acceso a la página **Basado en carga** y haciendo clic en **Añadir una instancia basada en carga** (si todavía no ha añadido ninguna instancia basada en carga a la capa) o **\$1Instancia** (si la capa ya tiene una o varias instancias basadas en carga). A continuación, configure la instancia tal como se ha descrito anteriormente en esta sección.
**Para añadir una instancia basada en carga a una capa**
1. En el panel de navegación, haga clic en **Basado en carga** bajo **Instancias**.
1. Si ya ha activado el escalado automático basado en carga para una capa, haga clic en **\$1Instancia**. De lo contrario, haga clic en **Añadir una instancia basada en carga**. Seleccione la pestaña **Existente**.
![\[Añadir una instancia basada en carga a una capa\]](http://docs.aws.amazon.com/es_es/opsworks/latest/userguide/images/load_based_instances_existing.png)
1. En la pestaña **Existente**, seleccione una instancia. La lista muestra únicamente las instancias basadas en carga.
**nota**
Si cambia de opinión sobre el uso de una instancia existente, haga clic en la pestaña **Nueva** para crear una instancia nueva, tal y como se describe en el procedimiento anterior.
1. Haga clic en **Añadir instancia** para añadir la instancia a la capa.
Puede modificar la configuración de o desactivar el escalado automático basado en carga en cualquier momento.
**Para desactivar el escalado automático basado en carga**
1. En el panel de navegación, bajo **Instancias**, haga clic en **Basada en carga** y, a continuación, elija **editar** para la capa correspondiente.
1. Establezca **Escalado automático basado en carga activado** en **No**.
## Diferencia entre el escalado basado en carga y la recuperación automática
El escalado automático basado en carga utiliza métricas de carga que se calcula como media de todas las instancias en ejecución. Si las métricas se mantienen entre los umbrales especificados, OpsWorks Stacks no inicia ni detiene ninguna instancia. Con la reparación automática, por otro lado, OpsWorks Stacks inicia automáticamente una nueva instancia con la misma configuración cuando una instancia deja de responder. Es posible que la instancia no pueda responder debido a un problema de red o de la propia instancia.
Por ejemplo, suponga que su umbral de incremento de la CPU es del 80 % y, a continuación, una instancia deja de responder.
+ Si la reparación automática está deshabilitada y el resto de las instancias en ejecución pueden mantener el uso promedio de la CPU por debajo del 80%, OpsWorks Stacks no inicia una nueva instancia. Solo inicia una instancia de sustitución si el uso medio de la CPU entre las demás instancias supera el 80 %.
+ Si la reparación automática está habilitada, OpsWorks Stacks inicia una instancia de reemplazo independientemente de los umbrales de carga.