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. # Aplicaciones **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). Una *aplicación OpsWorks * Stacks representa el código que quieres ejecutar en un servidor de aplicaciones. El código propiamente dicho se encuentra en un repositorio como, por ejemplo, un archivo de Amazon S3; la aplicación contiene la información necesaria para implementar el código en las instancias de servidor de aplicaciones apropiadas. Cuando despliegas una aplicación, OpsWorks Stacks activa un evento de despliegue, que ejecuta las recetas de despliegue de cada capa. OpsWorks Stacks también instala los [atributos de configuración e implementación de la pila](workingcookbook-json.md) que contienen toda la información necesaria para implementar la aplicación, como el repositorio de la aplicación y los datos de conexión a la base de datos. Debe implementar recetas personalizadas que recuperan los datos de implementación de la aplicación a partir de los atributos de configuración e implementación de la pila y gestiona las tareas de implementación. **Topics** + [Agregar aplicaciones](workingapps-creating.md) + [Implementación de aplicaciones](workingapps-deploying.md) + [Edición de aplicaciones](workingapps-editing.md) + [Conexión de una aplicación a un servidor de base de datos](workingapps-connectdb.md) + [Uso de variables de entorno de](apps-environment-vars.md) + [Transferir datos a aplicaciones](apps-data.md) + [Uso de las claves SSH de repositorios Git](workingapps-deploykeys.md) + [Uso de dominios personalizados](workingapps-domains.md) + [Uso de SSL](workingsecurity-ssl.md) # Agregar aplicaciones **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 primer paso para implementar una aplicación en los servidores de aplicaciones consiste en agregar una aplicación a la pila. La app representa la aplicación y contiene una serie de metadatos, como el nombre y el tipo de la aplicación y la información necesaria para implementarla en las instancias del servidor, como la URL del repositorio. Para agregar una aplicación a una pila, debe disponer de permisos Manage. Para obtener más información, consulte [Administración de permisos de usuario](opsworks-security-users.md). **nota** El procedimiento de esta sección es aplicable a pilas de Chef 12 y más recientes. Para obtener más información sobre cómo añadir aplicaciones a las capas en las pilas de Chef 11, consulte [Paso 2.4: Crear e implementar una aplicación - Chef 11](gettingstarted-simple-app.md). **Para agregar una aplicación a una pila** 1. Coloque el código en el repositorio que prefiera: un archivo de Amazon S3, un repositorio Git, un repositorio Subversion o un archivo HTTP. Para obtener más información, consulte [Origen de las aplicaciones](#workingapps-creating-source). 1. Haga clic en **Apps (Aplicaciones)** en el panel de navegación. En la página **Apps (Aplicaciones)**, haga clic en **Add an app (Añadir una aplicación)** para su primera aplicación. Para aplicaciones posteriores, haga clic en **\$1App**. 1. Utilice la página **App New (Aplicación nueva)**para configurar la aplicación, tal y como se describe en la siguiente sección. ## Configuración de una aplicación La página **Add App (Añadir aplicación)** incluye las siguientes secciones: **Settings (Configuración)**, **Application source (Origen de la aplicación)**, **Data Sources (Fuentes de datos)**, **Environment Variables (Variables de entorno)**, **Add Domains (Añadir dominios)** y **SSL Settings (Configuración de SSL)**. **Topics** + [Configuración](#workingapps-creating-settings) + [Origen de las aplicaciones](#workingapps-creating-source) + [Orígenes de datos](#workingapps-creating-data) + [Variables de entorno](#workingapps-creating-environment) + [Configuración SSL y de dominio](#workingapps-creating-domain-ssl) ### Configuración **Name** El nombre de la aplicación, que se utiliza para representar la aplicación en la interfaz de usuario. OpsWorks Stacks también usa este nombre para generar un nombre abreviado para la aplicación que se usa internamente y para identificar la aplicación en los [atributos de configuración e implementación de la pila](workingcookbook-json.md). Una vez agregada la aplicación a la pila, podrá ver el nombre abreviado haciendo clic en **Apps (Aplicaciones)** en el panel de navegación y, a continuación, en el nombre de la aplicación para abrir la página de detalles. ****Document root (Raíz del documento)**** OpsWorks Stacks asigna la configuración **raíz del documento** al [`[:document_root]`](attributes-json-deploy.md#attributes-json-deploy-app-root)atributo de los atributos de la aplicación. `deploy` El valor predeterminado es `null`. Las recetas de implementación pueden obtener dicho valor de los atributos `deploy` mediante sintaxis de nodo de Chef estándar e implementar el código especificado en la ubicación adecuada en el servidor. Para obtener más información acerca de cómo implementar aplicaciones, consulte [Recetas de implementación](create-custom-deploy.md). ### Origen de las aplicaciones Puede implementar aplicaciones desde los siguientes tipos de repositorio: Git, agrupación Amazon S3, agrupación HTTP y otros. Todos los tipos de repositorio requieren que especifique el tipo y su URL. Los tipos de repositorio individuales tienen requisitos propios, como se explica a continuación. **nota** OpsWorks Stacks implementa automáticamente las aplicaciones desde los repositorios estándar a las capas de servidor integradas. Si utilizas el tipo de repositorio Otro, que es la única opción para las pilas de Windows, OpsWorks Stacks coloca la información del repositorio en los [`deploy`atributos](workingcookbook-json.md#workingcookbook-json-deploy) de la aplicación, pero debes implementar recetas personalizadas para gestionar las tareas de implementación. **Topics** + [Archivo HTTP](#w2ab1c14c57c13c11b8b8) + [Archivo de Amazon S3](#w2ab1c14c57c13c11b8c10) + [Repositorio Git](#w2ab1c14c57c13c11b8c12) + [Otros repositorios](#w2ab1c14c57c13c11b8c14) #### Archivo HTTP Para utilizar un servidor HTTP de acceso público como repositorio: 1. Cree un archivo comprimido (zip, gzip, bzip2, Java War o tarball) de la carpeta que contiene el código de la aplicación y los archivos asociados, si los hay. **nota** OpsWorks Stacks no admite archivos tar sin comprimir. 1. Cargue el archivo en el servidor. 1. Para especificar el repositorio en la consola, seleccione la opción de archivo HTTP como tipo de repositorio e introduzca la dirección URL. Si el archivo está protegido con contraseña, en **Origen de la aplicación**, especifique el nombre de usuario y la contraseña. #### Archivo de Amazon S3 Para usar un bucket de Amazon Simple Storage Service como repositorio: 1. Cree un bucket de Amazon S3 público o privado. Para obtener más información, consulte la [documentación de Amazon S3](https://aws.amazon.com/documentation/s3/). 1. Para que OpsWorks Stacks pueda acceder a los buckets privados, debes ser un usuario con al menos derechos de solo lectura en el bucket de Amazon S3 y necesitarás el ID de la clave de acceso y la clave de acceso secreta. Para obtener más información, consulte la [Documentación de AWS Identity and Access Management](https://docs.aws.amazon.com/iam/). 1. Coloque el código y los archivos asociados en una carpeta y guárdela en un archivo comprimido (zip, gzip, bzip2, Java War o tarball). **nota** OpsWorks Stacks no admite archivos tar sin comprimir. 1. Cargue el archivo de almacenamiento en el bucket de Amazon S3 y registre la dirección URL. 1. Para especificar el repositorio en la consola de OpsWorks Stacks, establece el **tipo de repositorio** en **S3 Archive** e introduce la URL del archivo. Si se trata de un archivo privado, también deberá proporcionar un ID de clave de acceso de AWS y una clave de acceso secreta cuya política otorgue permisos de acceso al bucket. Deje estos valores en blanco en el caso de archivos públicos. #### Repositorio Git Un repositorio de [Git](http://git-scm.com/) proporciona control de código fuente y control de versiones. OpsWorks Stacks es compatible con sitios de repositorios alojados públicamente, como [GitHub](https://github.com/)[Bitbucket](https://bitbucket.org), así como con servidores Git alojados de forma privada. Para las aplicaciones y submódulos Git, el formato utilizado para especificar la URL del repositorio en **Application Source (Origen de la aplicación)** depende de si el repositorio es público o privado: **Repositorio público** – Use protocolos de solo lectura HTTPS o Git. Por ejemplo, [Introducción a las pilas de Linux en Chef 11](gettingstarted.md) usa un GitHub repositorio público al que se puede acceder mediante cualquiera de los siguientes formatos de URL: + Git de solo lectura: **git://github.com/amazonwebservices/opsworks-demo-php-simple-app.git** + HTTPS: **https://github.com/amazonwebservices/opsworks-demo-php-simple-app.git** **Repositorio privado**: usa el read/write formato SSH que se muestra en estos ejemplos: + Repositorios de Github: **git@github.com:*project*/*repository***. + Repositorios en un servidor Git: ***user*@*server*:*project*/*repository*** Si se selecciona **Git** en **Source Control (Control de origen)** se muestran dos valores opcionales más: **Repository SSH key (Clave SSH del repositorio)** Debe especificar una clave SSH de implementación para obtener acceso a repositorios Git privados. Este campo requiere la clave privada; la clave pública se asignó a su repositorio Git. Con los submódulos Git, la clave especificada debe obtener acceso a esos submódulos. Para obtener más información, consulte [Uso de las claves SSH de repositorios Git](workingapps-deploykeys.md). La clave SSH de implementación no puede requerir una contraseña; OpsWorks Stacks no tiene forma de pasarla. **Branch/Revision** Si el repositorio tiene varias sucursales, OpsWorks Stacks descarga la rama maestra de forma predeterminada. Para especificar una rama en particular, ingresa el nombre de la rama, el SHA1 hash o el nombre de la etiqueta. Para especificar una confirmación concreta, introduzca el identificador completo de 40 dígitos hexadecimales de confirmación. #### Otros repositorios Si los repositorios estándar no valen según sus requisitos, use otros; por ejemplo, [Bazaar](http://bazaar.canonical.com/en/). Sin embargo, OpsWorks Stacks no implementa automáticamente las aplicaciones de dichos repositorios. Debe implementar recetas personalizadas que administren el proceso de implementación y asignarlas a los eventos Deploy adecuados de la capa. Si desea ver un ejemplo de cómo implementar recetas de implementación, consulte [Recetas de implementación](create-custom-deploy.md). ### Orígenes de datos En esta sección se adjunta una base de datos a la aplicación. Dispone de las opciones siguientes: + **RDS**: adjuntar una de las [capas del servicio Amazon RDS](workinglayers-db-rds.md) de la pila. + **Ninguno**: no adjuntar un servidor de bases de datos. Si selecciona **RDS**, debe especificar lo siguiente. **Instancia de base de datos** La lista incluye todas las capas de servicio de Amazon RDS. También puede seleccionar una de las siguientes opciones: (Obligatoria) Seleccione el servidor de base de datos que desea adjuntar a la aplicación. El contenido de la lista dependerá del origen de datos. + **RDS**: una lista de las capas del servicio Amazon RDS de la pila. **Nombre de base de datos** (Opcional) Especifique el nombre de la base de datos. + Capa Amazon RDS: Escriba el nombre de la base de datos especificado para la instancia de Amazon RDS. Puede verlo en la [consola de Amazon RDS](https://console.aws.amazon.com/rds/). [Cuando implementas una aplicación con una base de datos adjunta, OpsWorks Stacks agrega la conexión de la instancia de base de datos a los atributos de la aplicación. `deploy`](workingcookbook-json.md#workingcookbook-json-deploy) Puede escribir una receta personalizada para recuperar la información de los atributos `deploy` y colocarla en un archivo al que la aplicación obtenga acceso. Esta es la única opción para proporcionar información sobre la conexión de la base de datos a los tipos de aplicación Other. Para obtener más información acerca de cómo administrar las conexiones de bases de datos, consulte [Conexión a una base de datos](workingapps-connectdb.md). Para separar un servidor de base de datos de una aplicación, [cambie la configuración de la aplicación](workingapps-editing.md) y especifique otro servidor de base de datos o ningún servidor. ### Variables de entorno Puede especificar un conjunto de variables de entorno para cada aplicación, que serán específicas de la aplicación. Por ejemplo, si tiene dos aplicaciones, las variables de entorno definidas para la primera no están disponibles para la segunda y viceversa. También puede definir la misma variable de entorno para varias aplicaciones y asignarle un valor diferente para cada aplicación. **nota** No existe ningún límite específico sobre el número de variables de entorno. No obstante, el tamaño de la estructura de los datos asociados (que incluyen los nombres, valores y los valores de marca protegidos de las variables) no puede superar los 20 KB. Este límite debería dar cabida a la mayoría de los casos de uso, si no a todos ellos. Sobrepasarlo generará un error de servicio (consola) o una excepción (API) con el mensaje "Environment: is too large (maximum is 20 KB)". OpsWorks [Stacks almacena las variables como atributos en los atributos de la `deploy` aplicación.](workingcookbook-json.md#workingcookbook-json-deploy) Puede hacer que sus recetas personalizadas recuperen los valores con la sintaxis de nodo de Chef estándar. Para ver ejemplos de cómo obtener acceso a las variables de entorno de una aplicación, consulte [Uso de variables de entorno de](apps-environment-vars.md). **Key** El nombre de la variable. Puede contener un máximo de 64 letras en mayúsculas y minúsculas, números y guiones bajos (\$1), pero debe comenzar con una letra o un guion bajo. **Valor** El valor de la variable. Puede contener un máximo de 256 caracteres, imprimibles obligatoriamente. **Protected value** Si el valor está protegido. Esta configuración permite ocultar información confidencial, por ejemplo, las contraseñas. Si establece **Protected value (Valor protegido)** para una variable, después de crear la aplicación: + La página de detalles de la aplicación mostrará únicamente el nombre de la variable, no el valor. + Si tiene permiso para modificar la aplicación, puede hacer clic en **Update value (Actualizar valor)** para especificar un nuevo valor, pero no puede ver ni modificar el valor antiguo. **nota** Los registros de implementación de Chef a veces pueden incluir variables de entorno. Esto significa que las variables protegidas pueden mostrarse en la consola. Para evitar que las variables protegidas se muestren en la consola, le recomendamos que utilice buckets de Amazon S3 como almacenamiento para las variables protegidas que no desea que se muestren en la consola. En [Uso de un bucket de Amazon S3](gettingstarted.walkthrough.photoapp.md) de esta guía hay disponible un ejemplo de cómo utilizar un bucket de S3 para este fin. ### Configuración SSL y de dominio Para el tipo Otra aplicación, OpsWorks Stacks agrega la configuración a los atributos de `deploy` la aplicación. Sus recetas pueden recuperar los datos de los atributos y configurar el servidor como sea necesario. **Domain Settings** Esta sección tiene un campo **Add Domains (Añadir dominios)** opcional para especificar dominios. Para obtener más información, consulte [Uso de dominios personalizados](workingapps-domains.md). **SSL Settings** Esta sección tiene un alternador **SSL Support (Compatibilidad SSL)** que puede utilizar para habilitar o deshabilitar SSL. Si hace clic en **Yes (Sí)**, tendrá que proporcionar la información del certificado SSL. Para obtener más información, consulte [Uso de SSL](workingsecurity-ssl.md). # Implementación de aplicaciones **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 objetivo principal de la implementación es implementar código de aplicación y archivos relacionados en las instancias del servidor de aplicaciones. La operación de implementación la gestionan las recetas Deploy de cada instancia, que vienen determinadas por la capa de la instancia. Cuando inicias una instancia, una vez completadas las recetas de configuración, OpsWorks Stacks ejecuta automáticamente las recetas de implementación de la instancia. Sin embargo, al añadir o modificar una aplicación, deberá implementarla manualmente en las instancias online. Debe disponer de permisos Manage o Deploy para implementar una aplicación. Para obtener más información, consulte [Administración de permisos de usuario](opsworks-security-users.md). **Para implementar una aplicación** 1. En la página **Apps (Aplicaciones)**, haga clic en la acción **deploy (Implementar)** de la aplicación. ![\[Apps page showing SimplePHP app with deploy, edit, and delete action options.\]](http://docs.aws.amazon.com/es_es/opsworks/latest/userguide/images/apps_with_content.png) **nota** También puede implementar una aplicación haciendo clic en **Deployments (Implementaciones) **en el panel de navegación. En la página **Deployments & Commands (Implementaciones y comandos)**, haga clic en **Deploy an app (Implementar una aplicación)**. En este paso también puede elegir la aplicación que quiere implementar. 1. Especifique lo siguiente: + (Obligatorio) Configure **Command: (Comando:)** en **deploy (implementar)**, si no lo ha hecho ya. + (Opcional) Incluya un comentario. 1. Haz clic en **Avanzado >>** para especificar un JSON personalizado. OpsWorks Stacks añade un conjunto de [atributos de configuración y despliegue de la pila](workingcookbook-json.md) al objeto de nodo. Los atributos `deploy` contienen los detalles de la implementación. Las recetas Deploy pueden utilizar estos atributos para gestionar la instalación y la configuración. En Linux Stacks, puedes usar el campo JSON personalizado para [anular la configuración predeterminada de OpsWorks Stacks o transferir la configuración](workingcookbook-json-override.md) personalizada a tus recetas personalizadas. Para obtener más información acerca de cómo utilizar un JSON personalizado, consulte [Uso de un JSON personalizado](workingstacks-json.md). **nota** Si especifica un JSON personalizado aquí, se añade a los atributos de configuración y de implementación de la pila únicamente para esta implementación. Si desea añadir un JSON personalizado de forma permanente, debe [añadirlo a la pila](workingstacks-json.md). El JSON personalizado está limitado a 120 KB. Si necesita más capacidad, le recomendamos almacenar parte de los datos en Amazon S3. De este modo, sus recetas personalizadas podrán utilizar la CLI de AWS o el [AWS SDK para Ruby](https://aws.amazon.com/documentation/sdk-for-ruby/) para descargar los datos del bucket en la instancia. Para ver un ejemplo, consulta [Uso del SDK para Ruby](cookbooks-101-opsworks-s3.md). 1. En **Instances (Instancias)**, haga clic en **Advanced (Avanzado) >>** y especifique en qué instancias quiere ejecutar el comando de implementación. El comando de implementación dispara un evento Deploy, que ejecuta las recetas de implementación en las instancias seleccionadas. Las recetas de implementación para el servidor de aplicaciones asociado descargan el código y los archivos relacionados desde el repositorio y los instalan en la instancia, para que pueda seleccionar todas las instancias del servidor de aplicaciones asociadas. Sin embargo, es posible que otros tipos de instancia requieran algunos cambios de configuración para adaptarse a la nueva aplicación, por lo que también suele ser útil ejecutar recetas de implementación en dichas instancias. Estas recetas actualizan la configuración según sea necesario, pero no instalan los archivos de la aplicación. Para obtener más información acerca de las recetas, consulte [Cookbooks and Recipes](workingcookbook.md). 1. Haga clic en **Deploy (Implementar)** para ejecutar las recetas de implementación en las instancias especificadas, que se muestran en la página Implementación. Cuando se complete el proceso, OpsWorks Stacks marca la aplicación con una marca verde para indicar que se implementó correctamente. Si la implementación falla, OpsWorks Stacks marca la aplicación con una X roja. En ese caso, puedes ir a la página de **implementaciones** y examinar el registro de implementación para obtener más información. ![\[Deployment status page showing successful deployment of PHPTestApp with details.\]](http://docs.aws.amazon.com/es_es/opsworks/latest/userguide/images/deployed_app.png) **nota** Cuando implemente una actualización en una aplicación JSP, es posible que Tomcat no reconozca la actualización y, en su lugar, siga ejecutando la versión de la aplicación existente. Este caso puede producirse, por ejemplo, si implementa su aplicación como un archivo .zip que contiene únicamente una página JSP. Para asegurarse de que Tomcat ejecute la última versión implementada, el directorio raíz del proyecto debe incluir un directorio WEB-INF que contenga un archivo `web.xml`. Un archivo `web.xml` puede tener una gran variedad de contenidos, pero lo que sigue es suficiente para asegurarse de que Tomcat reconozca las actualizaciones y ejecute la versión de la aplicación implementada actualmente. No es necesario que cambie la versión en cada actualización. Tomcat reconoce la actualización incluso si la versión no ha cambiado. ``` appVersion 0.1 ``` ## Otros comandos de implementación La página **Deploy app (Implementar aplicación)** incluye otros comandos para la gestión de las aplicaciones y los servidores asociados. De los siguientes comandos, solo **Undeploy (Anular implementación)** está disponible para aplicaciones en stacks de Chef 12. **Undeploy** Dispara un [evento del ciclo de vida Undeploy](workingcookbook-events.md), que ejecuta las recetas de anulación de la implementación para eliminar todas las versiones de la aplicación de las instancias especificadas. **Reversión** Restaura la versión de la aplicación implementada anteriormente. Por ejemplo, si ha implementado la aplicación tres veces y, a continuación, ejecuta **Rollback (Restaurar)**, el servidor operará para la aplicación de la segunda implementación. Si ejecuta **Rollback (Restaurar)** de nuevo, el servidor operará para la aplicación de la primera implementación. De forma predeterminada, OpsWorks Stacks almacena las cinco implementaciones más recientes, lo que te permite revertir hasta cuatro versiones. Si supera el número de versiones almacenadas, el comando no funciona y deja la versión más antigua. Este comando no está disponible para las pilas de Chef 12. **Start Web Server** Ejecuta recetas que inician el servidor de aplicaciones en las instancias especificadas. Este comando no está disponible para las pilas de Chef 12. **Stop Web Server** Ejecuta recetas que detienen el servidor de aplicaciones en las instancias especificadas. Este comando no está disponible para las pilas de Chef 12. **Restart Web Server** Ejecuta recetas que reinician el servidor de aplicaciones en las instancias especificadas. Este comando no está disponible para las pilas de Chef 12. **importante** **Start Web Serve (Iniciar servidor web)**, **Stop Web Server (Detener servidor web)**, **Restart Web Server (Reiniciar servidor web)** y **Rollback (Restaurar)** son básicamente versiones personalizadas del [comando de stack Execute recipes](workingstacks-commands.md). Ejecutan un conjunto de recetas que lleva a cabo la tarea en las instancias especificadas. Estos comandos no disparan un evento del ciclo de vida, por lo que no puede conectarlos para ejecutar un código personalizado. Estos comandos funcionan solo para las [capas del servidor de aplicaciones](workinglayers-servers.md) integradas. En particular, estos comandos no modifican las capas personalizadas, incluso si admiten un servidor de aplicaciones. Para iniciar, detener o reiniciar servidores en una capa personalizada, debe implementar las recetas personalizadas para que realicen estas tareas y utilizar el [comando de pila Execute Recipes](workingstacks-commands.md) para ejecutarlas. Para obtener más información acerca de cómo implementar e instalar recetas personalizadas, consulte [Cookbooks and Recipes](workingcookbook.md). # Edición de aplicaciones **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). Puede modificar la configuración de una aplicación editándola. Por ejemplo, si estás listo para implementar una nueva versión, puedes editar la configuración de OpsWorks Stacks de la aplicación para usar la nueva rama del repositorio. Debe disponer de permisos Manage o Deploy para editar la configuración de una aplicación. Para obtener más información, consulte [Administración de permisos de usuario](opsworks-security-users.md). **Para editar una aplicación** 1. En la página **Apps (Aplicaciones)**, haga clic en el nombre de la aplicación para abrir la página de detalles. 1. Haga clic en **Edit (Editar)** para cambiar la configuración de la aplicación. + Si modificas el nombre de la aplicación, OpsWorks Stacks usará el nuevo nombre para identificar la aplicación en la consola. Cambiar el nombre no cambia el nombre abreviado que tiene asociado. El nombre abreviado se define al añadir la aplicación a la pila y no puede modificarse posteriormente. + Si ha especificado una variable de entorno protegida, no podrá ver ni editar el valor. Sin embargo, podrá especificar un valor nuevo haciendo clic en **Update value (Actualizar valor)**. 1. Haga clic en **Save (Guardar)** para guardar la nueva configuración y, a continuación, en **Deploy App (Implementar aplicación)** para implementar la aplicación. La edición de una aplicación cambia la configuración con OpsWorks Stacks, pero no afecta a las instancias de la pila. La primera vez que [implementa una aplicación](workingapps-deploying.md), las recetas Deploy descargan el código y los archivos relacionados con las instancias del servidor de aplicaciones, que, a continuación, ejecutan la copia local. Si modificas la aplicación en el repositorio o cambias cualquier otra configuración, debes implementar la aplicación para instalar las actualizaciones en las instancias del servidor de aplicaciones, de la siguiente manera. OpsWorks Stacks implementa automáticamente la versión actual de la aplicación en las nuevas instancias cuando se inician. Para las instancias existentes, sin embargo, la situación es diferente: + OpsWorks Stacks implementa automáticamente la versión actual de la aplicación en las nuevas instancias cuando se inician. + OpsWorks Stacks implementa automáticamente la última versión de la aplicación en las instancias sin conexión, incluidas las que se [basan en la carga y en el tiempo, cuando se reinician](workinginstances-autoscaling.md). + Debe implementar manualmente la aplicación actualizada en las instancias online. Para obtener más información acerca de cómo implementar aplicaciones, consulte [Implementación de aplicaciones](workingapps-deploying.md). # Conexión de una aplicación a un servidor de base de datos **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). Puede asociar un servidor de base de datos Amazon RDS con una aplicación al [crear la aplicación](workingapps-creating.md) o, posteriormente, al [editar la configuración de la aplicación](workingapps-editing.md). Entonces la aplicación podrá utilizar la información de conexión a la base de datos (nombre de usuario, contraseña, etc.) para establecer conexión con el servidor de base de datos. Cuando [implementas una aplicación](workingapps-deploying.md), OpsWorks Stacks proporciona esta información a las aplicaciones de dos maneras: + Para las pilas de Linux, OpsWorks Stacks crea un archivo en cada una de las instancias del servidor de aplicaciones integrado con los datos de conexión que la aplicación puede utilizar para establecer conexión con el servidor de base de datos. + OpsWorks Stacks incluye la información de conexión en los [atributos de configuración e implementación de la pila](workingcookbook-json.md) que están instalados en cada instancia. Puede implementar una receta personalizada para extraer la información de conexión de estos atributos y ponerla en un archivo en el formato que prefiera. Para obtener más información, consulte [Transferir datos a aplicaciones](apps-data.md). **importante** En las pilas de Linux, si quiere asociar una capa de servicio de Amazon RDS a su aplicación, debe añadir el paquete del controlador apropiado a la capa del servidor de aplicaciones asociado, tal y como se indica a continuación: Haga clic en **Layers (Capas)** en el panel de navegación y abra la pestaña **Recipes (Recetas)** del servidor de aplicaciones. Haga clic en **Edit (Editar)** y agregue el paquete del controlador apropiado a **OS Packages (Paquetes de SO)**. Por ejemplo, debe especificar `mysql` si la capa contiene instancias de Amazon Linux y `mysql-client` si la capa contiene instancias de Ubuntu. Guarde los cambios y vuelva a implementar la aplicación. ## Uso de una receta personalizada Puede implementar una receta personalizada que extrae los datos de conexión de datos de los [atributos `deploy`](workingcookbook-json.md#workingcookbook-json-deploy) y los guarda en un formulario que la aplicación puede leer, como un archivo YAML. Adjunte un servidor de base de datos a una aplicación cuando [cree la aplicación](workingapps-creating.md) o, más tarde, [editando la aplicación](workingapps-editing.md). Al implementar la aplicación, OpsWorks Stacks instala una [pila de atributos de configuración y despliegue](workingcookbook-json.md) en cada instancia que incluyen la información de conexión a la base de datos. De esta manera, la aplicación puede recuperar los atributos apropiados. Los detalles varían en función de si utiliza una pila de Linux o de Windows. ### Conexión a un servidor de base de datos para una pila de Linux En las pilas de Linux, el espacio de nombres de los [atributos de configuración e implementación de la pila](workingcookbook-json.md) `deploy` contiene un atributo para cada aplicación implementada, denominado según el nombre abreviado de la aplicación. Cuando adjuntas un servidor de base de datos a una aplicación, OpsWorks Stacks rellena el `[:database]` atributo de la aplicación con la información de conexión y lo instala en las instancias de la pila para cada implementación posterior. Los valores de los atributos o bien los genera OpsWorks Stacks o los proporciona el usuario. **nota** OpsWorks Stacks te permite adjuntar un servidor de base de datos a varias aplicaciones, pero cada aplicación solo puede tener un servidor de base de datos conectado. Si desea conectar una aplicación a más de un servidor de base de datos, adjunte uno de los servidores a la aplicación y utilice la información de los atributos `deploy` de la aplicación para establecer conexión con dicho servidor. Utilice el JSON personalizado para transferir la información de conexión de los demás servidores de bases de datos a la aplicación. Para obtener más información, consulte [Transferir datos a aplicaciones](apps-data.md). Una aplicación puede utilizar la información de conexión de los atributos `deploy` de la instancia para conectarse a una base de datos. Sin embargo, las aplicaciones no pueden tener un acceso directo a esta información, solo las recetas tienen dicho acceso a los atributos `deploy`. Puede solucionar este problema implementando una receta personalizada que extraiga la información de conexión de los atributos `deploy` y la ponga en un archivo que se pueda leer con la aplicación. # Uso de variables de entorno de **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** Las recomendaciones en este tema son para Chef 11.10 y versiones anteriores de Chef. Para recibir las variables de entorno en Chef 12 y en versiones más recientes, debe utilizar el contenedor de datos de la aplicación. Para obtener más información, consulte [AWS OpsWorks Data Bag Reference](https://docs.aws.amazon.com/opsworks/latest/userguide/data-bags.html) y [App Data Bag (aws\$1opsworks\$1app](https://docs.aws.amazon.com/opsworks/latest/userguide/data-bag-json-app.html)). [Cuando [especificas variables de entorno para una aplicación](workingapps-creating.md#workingapps-creating-environment), OpsWorks Stacks añade las definiciones de las variables a los atributos de la aplicación. `deploy`](workingcookbook-json.md#workingcookbook-json-deploy) Las capas personalizadas pueden utilizar una receta para recuperar el valor de la variable mediante la sintaxis de nodo estándar y almacenarlo en un formulario que sea accesible para las aplicaciones de la capa. Debe implementar una receta personalizada que obtiene los valores de la variable de entorno de los atributos `deploy` de la instancia. La receta puede almacenar los datos en la instancia en un formulario al que puede obtener acceso la aplicación, como un archivo YAML. Las definiciones de la variable de entorno de una aplicación se almacenan en los atributos `deploy` en las `environment_variables` de la aplicación. En el siguiente ejemplo se muestra la ubicación de estos atributos para una aplicación denominada `simplephpapp`, utilizando JSON para representar la estructura de los atributos. ``` { ... "ssh_users": { }, "deploy": { "simplephpapp": { "application": "simplephpapp", "application_type": "php", "environment_variables": { "USER_ID": "168424", "USER_KEY": "somepassword" }, ... } } ``` Una receta puede obtener valores de variable mediante el uso de la sintaxis de nodo estándar. En el siguiente ejemplo se muestra cómo obtener el valor `USER_ID` del último JSON y colocarlo en el registro de Chef. ``` Chef::Log.info("USER_ID: #{node[:deploy]['simplephpapp'][:environment_variables][:USER_ID]}") ``` Para obtener una descripción más detallada de cómo recuperar información del JSON de configuración e implementación de la pila y almacenarlo en la instancia, consulte [Transferir datos a aplicaciones](apps-data.md). # Transferir datos a aplicaciones **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). Suele ser útil transferir datos como pares clave-valor a una aplicación en el servidor. Para ello, utilice [JSON personalizado](workingstacks-json.md) para agregar los datos a la pila. OpsWorks Stacks añade los datos al objeto de nodo de cada instancia para cada evento del ciclo de vida. Tenga en cuenta que, aunque las recetas puedan obtener los datos JSON personalizados del objeto de nodo mediante atributos de Chef, las aplicaciones no pueden hacerlo. Un sistema para transferir datos de JSON personalizados a una o más aplicaciones es implementar una receta personalizada que extraiga los datos desde el objeto `node` y los escriba en un archivo que la aplicación pueda leer. El ejemplo en este tema muestra cómo escribir los datos a un archivo YAML, pero puede utilizar el mismo sistema básico para otros formatos, como JSON o XML. Para transferir datos clave-valor a las instancias de la pila, añada JSON personalizado como el siguiente a la pila. Para obtener más información acerca de cómo agregar JSON personalizado a una pila, consulte [Uso de un JSON personalizado](workingstacks-json.md). ``` { "my_app_data": { "app1": { "key1": "value1", "key2": "value2", "key3": "value3" }, "app2": { "key1": "value1", "key2": "value2", "key3": "value3" } } } ``` El ejemplo asume que tiene dos aplicaciones cuyos nombres abreviados son `app1` y `app2`, cada una de ellas con tres valores de datos. La receta que las acompaña asume que utiliza los nombres abreviados de las aplicaciones para identificar los datos asociados; los demás nombres son arbitrarios. Para obtener más información sobre los nombres abreviados de las aplicaciones, consulte [Configuración](workingapps-creating.md#workingapps-creating-settings). La receta en el siguiente ejemplo muestra cómo extraer los datos para cada aplicación desde los atributos `deploy` y colocarlos en un archivo `.yml`. La receta asume que el JSON personalizado tiene datos para cada aplicación. ``` node[:deploy].each do |app, deploy| file File.join(deploy[:deploy_to], 'shared', 'config', 'app_data.yml') do content YAML.dump(node[:my_app_data][app].to_hash) end end ``` Los atributos `deploy` contienen un atributo para cada aplicación con el nombre abreviado de la aplicación. Cada atributo de aplicación contiene un conjunto de atributos que representan distinta información sobre la aplicación. Este ejemplo utiliza el directorio de implementación de la aplicación, representado por el atributo `[:deploy][:app_short_name][:deploy_to]`. Para obtener más información sobre `[:deploy]`, consulte [Atributos deploy](attributes-json-deploy.md). Para cada aplicación en `deploy`, la receta hace lo siguiente: 1. Crea un archivo llamado `app_data.yml` en el subdirectorio `shared/config` del directorio `[:deploy_to]` de la aplicación. Para obtener más información sobre cómo OpsWorks Stacks instala las aplicaciones, consulta. [Recetas de implementación](create-custom-deploy.md) 1. Convierte los valores JSON personalizados de la aplicación a YAML y escribe datos con formato en `app_data.yml`. **Para transferir datos a una aplicación** 1. Añada una aplicación a la pila y anote su nombre abreviado. Para obtener más información, consulte [Agregar aplicaciones](workingapps-creating.md). 1. Añada JSON personalizado con los datos de la aplicación a los atributos `deploy`, tal y como se ha descrito anteriormente. Para obtener más información sobre cómo agregar JSON personalizado a una pila, consulte [Uso de un JSON personalizado](workingstacks-json.md). 1. Cree un libro de recetas y añádale una receta con código basado en el ejemplo anterior; modifíquelo según sea necesario según los nombres de atributo que utilizó en el JSON personalizado. Para obtener más información acerca de cómo crear libros de recetas y recetas, consulte [Cookbooks and Recipes](workingcookbook.md). Si ya tiene libros de recetas personalizados para esta pila, también puede añadir la receta a un libro de recetas existente o incluso añadir el código a una receta ya implementada. 1. Instale el libro de recetas en la pila. Para obtener más información, consulte [Instalación de libros de recetas personalizados](workingcookbook-installingcustom-enable.md). 1. Asigna la receta al evento de ciclo de vida de implementación de la capa de servidores de aplicaciones. OpsWorks Luego, Stacks ejecutará la receta en cada nueva instancia, una vez que se haya iniciado. Para obtener más información, consulte [Ejecución de recetas](workingcookbook-executing.md). 1. Implemente la aplicación, lo que también instala los atributos de configuración de la pila y de implementación que ahora contienen los datos. **nota** Si los archivos de datos deben existir antes de que se implemente la aplicación, también puede asignar la receta al evento Setup del ciclo de vida de la capa; esto sucede una vez, justo después de que la instancia termine de arrancar. Sin embargo, OpsWorks Stacks aún no habrá creado los directorios de despliegue, por lo que tu receta debería crear los directorios necesarios de forma explícita antes de crear el archivo de datos. El siguiente ejemplo crea de forma explícita el directorio `/shared/config` de la aplicación y, a continuación, crea un archivo de datos en dicho directorio. ``` node[:deploy].each do |app, deploy| directory "#{deploy[:deploy_to]}/shared/config" do owner "deploy" group "www-data" mode 0774 recursive true action :create end file File.join(deploy[:deploy_to], 'shared', 'config', 'app_data.yml') do content YAML.dump(node[:my_app_data][app].to_hash) end end ``` Para cargar los datos, puede utilizar algo como el siguiente código [Sinatra](http://www.sinatrarb.com/): ``` #!/usr/bin/env ruby # encoding: UTF-8 require 'sinatra' require 'yaml' get '/' do YAML.load(File.read(File.join('..', '..', 'shared', 'config', 'app_data.yml'))) End ``` Puede actualizar los valores de los datos de la aplicación en cualquier momento actualizando el JSON personalizado como se indica a continuación. **Para actualizar los datos de la aplicación** 1. Edite el JSON personalizado para actualizar los valores de los datos. 1. Vuelve a implementar la aplicación, lo que indica a OpsWorks Stacks que ejecute las recetas de Deploy en las instancias de la pila. Las recetas utilizarán los atributos actualizados de configuración de la pila y de implementación, por lo que la receta personalizada actualizará los archivos de datos con los valores actuales. # Uso de las claves SSH de repositorios Git **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). Una clave SSH de repositorio Git, a veces llamada clave SSH de implementación, es una clave SSH sin contraseña que proporciona acceso a un repositorio Git privado. Idealmente, no pertenece a ningún desarrollador específico. Su propósito es permitir que OpsWorks Stacks despliegue aplicaciones o libros de cocina de forma asíncrona desde un repositorio de Git sin requerir ninguna otra intervención por tu parte. A continuación se describe el procedimiento básico para crear una clave SSH de repositorio. Para obtener más información, consulte la documentación de su repositorio. Por ejemplo, en [Administrar las claves de despliegue](https://help.github.com/articles/managing-deploy-keys) se describe cómo crear una clave SSH de repositorio para un GitHub repositorio, y en [Deployment Keys en Bitbucket](http://blog.bitbucket.org/2012/06/20/deployment-keys/) se describe cómo crear una clave SSH de repositorio para un repositorio de Bitbucket. Tenga en cuenta que en parte de la documentación se describe cómo crear una clave en un servidor. En el OpsWorks caso de Stacks, simplemente sustituye «servidor» por «estación de trabajo» en las instrucciones. **Para crear una clave SSH de repositorio** 1. Cree un par de claves SSH de implementación para el repositorio Git en la estación de trabajo utilizando un programa como `ssh-keygen`. **importante** OpsWorks Stacks no admite contraseñas de claves SSH. 1. Asigne la clave pública al repositorio y almacene la clave privada en la estación de trabajo. 1. Introduzca la clave privada en el cuadro **Repository SSH Key (Clave SSH del repositorio)** cuando agregue una aplicación o especifique un repositorio de libros de recetas. Para obtener más información, consulte [Agregar aplicaciones](workingapps-creating.md). OpsWorks Stacks pasa la clave SSH del repositorio a cada instancia y, a continuación, las recetas integradas utilizan la clave para conectarse al repositorio y descargar el código. La clave se almacena en los [atributos `deploy`](workingcookbook-json.md) como [`node[:deploy]['appshortname'][:scm][:ssh_key]`](attributes-json-deploy.md#attributes-json-deploy-app-scm-key) y solo el usuario raíz puede obtener acceso a ella. # Uso de dominios personalizados **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). Si aloja un nombre de dominio en un tercero, puede asignar el nombre del dominio a una aplicación. El procedimiento básico es el siguiente: 1. Cree un subdominio en el registrador DNS y asígnelo a la dirección IP elástica del balanceador de carga o a la dirección IP pública del servidor de aplicaciones. 1. Actualice la configuración de su aplicación para que apunte al subdominio y vuelva a implementar la aplicación. **nota** Asegúrese de reenviar el nombre de dominio incompleto (como miaplicación1.ejemplo.com) a su nombre de dominio completo (como www.miaplicación1.ejemplo.com) para que ambos se asignen a la aplicación. Al configurar un dominio para una aplicación, dicho dominio se incluye como alias del servidor en el archivo de configuración del servidor. Si utiliza un balanceador de carga, este comprueba el nombre del dominio de la dirección URL cuando llegan las solicitudes y redirecciona el tráfico en función del dominio. **Para asignar un subdominio a una dirección IP** 1. Si utiliza un balanceador de carga, en la página **Instances (Instancias)**, haga clic en la instancia del balanceador de carga para abrir su página de detalles y obtener la **dirección IP** elástica de la instancia. De lo contrario, obtenga la dirección IP pública en la página de detalles de la instancia del servidor de aplicaciones. 1. Siga las instrucciones que le ha proporcionado el registrador DNS para crear y asignar el subdominio a la dirección IP del paso 1. **nota** Si la instancia del balanceador de carga termina en algún momento, se le asignará una nueva dirección IP elástica. Deberá actualizar la configuración del registrador DNS para realizar la asignación a la nueva dirección IP elástica. OpsWorks [Stacks simplemente añade la configuración del dominio a los atributos de la aplicación. `deploy`](workingcookbook-json.md#workingcookbook-json-deploy) Debe implementar una receta personalizada para recuperar la información del objeto de nodo y configurar el servidor adecuadamente. Para obtener más información, consulte [Cookbooks and Recipes](workingcookbook.md). # Ejecución de varias aplicaciones en el mismo servidor de aplicaciones **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** La información de este tema no se aplica a las aplicaciones Node.js. Si tiene varias aplicaciones del mismo tipo, a veces es más rentable ejecutarlas en las mismas instancias del servidor de aplicaciones. **Para ejecutar varias aplicaciones en el mismo servidor** 1. Añada una aplicación a la pila de cada aplicación. 1. Obtenga un subdominio independiente para cada aplicación y asigne los subdominios a la dirección IP del servidor de aplicaciones o balanceador de carga. 1. Edite la configuración de cada aplicación para especificar el subdominio apropiado. Para obtener más información acerca de cómo realizar estas tareas, consulte [Uso de dominios personalizados](workingapps-domains.md). **nota** Si sus servidores de aplicaciones ejecutan varias aplicaciones HTTP, puede utilizar Elastic Load Balancing para el balanceo de carga. Para varias aplicaciones HTTPS, debe terminar la conexión SSL en el balanceador de carga o crear una pila independiente para cada aplicación. Las solicitudes HTTPS están cifradas, lo que significa que si el usuario termina la conexión SSL en los servidores, el balanceador de carga no puede comprobar el nombre de dominio para determinar qué aplicación debe encargarse de la solicitud. # Uso de SSL **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). Para utilizar SSL con su aplicación, primero debe obtener un certificado de servidor digital de una entidad de certificación (CA). Para simplificar, en este tutorial se crea un certificado y se firma automáticamente. Los certificados autofirmados son útiles para fines de pruebas y aprendizaje, pero siempre se debe utilizar un certificado autofirmado por una entidad de certificación (CA) para pilas de producción. En este tutorial hará lo siguiente: 1. Instale y configure OpenSSL. 1. Crear un clave privada. 1. Crear una solicitud de firma de certificado. 1. Generar un certificado autofirmado. 1. Modificar la aplicación con la información del certificado. **importante** [Si su aplicación utiliza SSL, le recomendamos que lo desactive, si es posible SSLv3, en las capas del servidor de aplicaciones para corregir las vulnerabilidades descritas en el documento CVE-2014-3566.](https://cve.mitre.org/cgi-bin/cvename.cgi?name=cve-2014-3566) Si la pila incluye una capa Ganglia, debe desactivar SSL v3 también para dicha capa. Los detalles dependerán de la capa concreta; para obtener más información, consulte lo siguiente. [Java App Server OpsWorks Stacks Layer](layers-java.md) [El servidor de aplicaciones Node.js OpsWorks Stacks Layer](workinglayers-node.md) [PHP App Server OpsWorks Stacks Layer](workinglayers-php.md) [El servidor de aplicaciones Rails Stacks Layer OpsWorks](workinglayers-rails.md) [Capa de pilas de servidores web OpsWorks estáticos](workinglayers-static.md) [Capa Ganglia](workinglayers-ganglia.md) **Topics** + [Paso 1: Instalar y configurar OpenSSL](#w2ab1c14c57c29c15) + [Paso 2: Crear una clave privada](#w2ab1c14c57c29c17) + [Paso 3: Crear una solicitud de firma de certificado](#w2ab1c14c57c29c19) + [Paso 4: Enviar el CSR a una autoridad de certificación](#w2ab1c14c57c29c21) + [Paso 5: Modificar la aplicación](#w2ab1c14c57c29c23) ## Paso 1: Instalar y configurar OpenSSL Para crear y cargar certificados de servidor es necesaria una herramienta compatible con los protocolos SSL y TLS. OpenSSL es una herramienta de código abierto que proporciona las funciones criptográficas básicas necesarias para crear un token de RSA y firmarlo con su clave privada. En el procedimiento siguiente se supone que su equipo aún no tiene OpenSSL instalado. **Para instalar OpenSSL en Linux y Unix** 1. Vaya a [OpenSSL: Source, Tarballs](https://www.openssl.org/source/). 1. Descargue la versión más reciente. 1. Cree el paquete. **Para instalar OpenSSL en Windows** 1. Si Microsoft Visual C\$1\$1 2008 Redistributable Package todavía no está instalado en el sistema, descargue el [paquete.](https://www.microsoft.com/en-us/download/details.aspx?id=11895) 1. Ejecute el instalador y siga las instrucciones que proporciona el Asistente de instalación del paquete redistribuible de Microsoft Visual C\$1\$1 2008 para instalarlo. 1. Vaya a [OpenSSL: Binary Distributions](https://www.openssl.org/community/binaries.html), haga clic en la versión de los archivos binarios de OpenSSL adecuados para su entorno y guarde el instalador localmente. 1. Ejecute el instalador y siga las instrucciones del **OpenSSL Setup Wizard (Asistente de instalación de OpenSSL)** para instalar los archivos binarios. Cree una variable de entorno que señale al punto de instalación de OpenSSL abriendo un terminal o una ventana del sistema y utilizando las líneas de comandos siguientes. + En Linux y Unix ``` export OpenSSL_HOME=path_to_your_OpenSSL_installation ``` + En Windows ``` set OpenSSL_HOME=path_to_your_OpenSSL_installation ``` Añada la ruta de los archivos binarios de OpenSSL a la variable de ruta de su equipo abriendo un terminal o una ventana del sistema y utilizando las líneas de comandos siguientes. + En Linux y Unix ``` export PATH=$PATH:$OpenSSL_HOME/bin ``` + En Windows ``` set Path=OpenSSL_HOME\bin;%Path% ``` **nota** Los cambios que haga en las variables de entorno mediante estas líneas de comandos solo son válidas para la sesión de línea de comandos abierta. ## Paso 2: Crear una clave privada Necesita una clave privada única para crear la solicitud de firma del certificado (CSR). Cree la clave utilizando la línea de comandos siguiente: ``` openssl genrsa 2048 > privatekey.pem ``` ## Paso 3: Crear una solicitud de firma de certificado Una solicitud de firma del certificado (CSR) es un archivo que se envía a una entidad de certificación (CA) para solicitar un certificado digital de servidor. Cree la solicitud CSR utilizando la línea de comandos siguiente. ``` openssl req -new -key privatekey.pem -out csr.pem ``` El resultado del comando debería ser similar a lo siguiente: ``` You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ``` La tabla siguiente le puede ayudar a crear la solicitud de certificado. **Datos de la solicitud de certificado** | Name | Descripción | Ejemplo | | --- | --- | --- | | Country Name | La abreviatura ISO de dos letras del país. | US = Estados Unidos | | State or Province | Nombre del país o de la región donde se ubica su organización. Este nombre no se puede abreviar. | Washington | | Locality Name | Nombre de la ciudad donde se ubica su organización. | Seattle | | Organization Name | Nombre legal completo de su organización. No abrevie el nombre de la organización. | OrganizaciónX | | Unidad organizativa | Información adicional sobre la organización (opcional). | Marketing | | Common Name | Nombre completo de dominio de su CNAME. Recibirá una advertencia de comprobación del nombre de certificado si no se obtiene una coincidencia exacta. | www.example.com | | Email address | Dirección de correo electrónico del administrador del servidor | alguien@ejemplo.com | **nota** El campo Nombre común suele malinterpretarse y rellenarse incorrectamente. El nombre común es habitualmente el nombre del host más el nombre del dominio. Será algo como "www.ejemplo.com" o "ejemplo.com". Debe crear un CSR con el nombre común correcto. ## Paso 4: Enviar el CSR a una autoridad de certificación Para su uso en producción, obtendrá un certificado de servidor enviando el CSR a una autoridad de certificación (CA), lo cual puede requerir otras credenciales o pruebas de identidad. Si la solicitud se realiza correctamente, la CA devuelve el certificado de identidad firmado digitalmente y quizá un archivo de cadena de certificados. AWS no recomienda ninguna CA concreta. Para ver una lista parcial de las disponibles CAs, consulte [Autoridad de certificación: proveedores](https://en.wikipedia.org/wiki/Certificate_authority#Providers) en Wikipedia. También puede generar un certificado autofirmado que podrá usar con fines de prueba únicamente. En este ejemplo, utilice la línea de comandos siguiente para generar un certificado autofirmado. ``` openssl x509 -req -days 365 -in csr.pem -signkey privatekey.pem -out server.crt ``` El resultado tendrá un aspecto similar al siguiente: ``` Loading 'screen' into random state - done Signature ok subject=/C=us/ST=washington/L=seattle/O=corporationx/OU=marketing/CN=example.com/emailAddress=someone@example.com Getting Private key ``` ## Paso 5: Modificar la aplicación Después de generar el certificado y firmarlo, actualice la aplicación para habilitar SSL y proporcionar la información del certificado. En la página **Apps (Aplicaciones)**, elija una aplicación para abrir la página de detalles y, a continuación, haga clic en **Edit App (Editar aplicación)**. Para habilitar la compatibilidad con SSL, establezca **Enable SSL (Habilitar SSL)** en **Yes (Sí)**, lo cual muestra las siguientes opciones de configuración. **SSL Certificate (Certificado SSL)** Pegue el contenido del archivo del certificado de clave pública (.crt) en el cuadro. El certificado debería parecerse a lo siguiente: ``` -----BEGIN CERTIFICATE----- MIICuTCCAiICCQCtqFKItVQJpzANBgkqhkiG9w0BAQUFADCBoDELMAkGA1UEBhMC dXMxEzARBgNVBAgMCndhc2hpbmd0b24xEDAOBgNVBAcMB3NlYXR0bGUxDzANBgNV BAoMBmFtYXpvbjEWMBQGA1UECwwNRGV2IGFuZCBUb29sczEdMBsGA1UEAwwUc3Rl cGhhbmllYXBpZXJjZS5jb20xIjAgBgkqhkiG9w0BCQEWE3NhcGllcmNlQGFtYXpv ... -----END CERTIFICATE----- ``` Si utiliza Nginx y tiene un archivo de cadena de certificados, debe anexar el contenido al archivo de certificado de clave pública. Si está actualizando un certificado existente, haga lo siguiente: + Elija **Update SSL certificate (Actualizar certificado SSL)** para actualizar el certificado. + Si el certificado nuevo no coincide con la clave privada existente, elija **Update SSL certificate key (Actualizar clave del certificado SSL)**. + Si el certificado nuevo no coincide con la cadena de certificados existente, elija **Update SSL certificates (Actualizar certificados SSL)**. **SSL Certificate Key (Clave del certificado SSL)** Pegue el contenido del archivo de clave privada (archivo .pem) en el cuadro. Debería parecerse a lo siguiente: ``` ----BEGIN RSA PRIVATE KEY----- MIICXQIBAAKBgQC0CYklJY5r4vV2NHQYEpwtsLuMMBhylMrgBShKq+HHVLYQQCL6 +wGIiRq5qXqZlRXje3GM5Jvcm6q0R71MfRIl1FuzKyqDtneZaAIEYniZibHiUnmO /UNqpFDosw/6hY3ONk0fSBlU4ivD0Gjpf6J80jL3DJ4R23Ed0sdL4pRT3QIDAQAB AoGBAKmMfWrNRqYVtGKgnWB6Tji9QrKQLMXjmHeGg95mppdJELiXHhpMvrHtpIyK ... -----END RSA PRIVATE KEY----- ``` **SSL certificates of Certification Authorities (Certificados SSL de entidades de certificación)** Si tiene un archivo de cadena de certificados, pegue el contenido en el cuadro. Si utiliza Nginx, deje este cuadro en blanco. Si tiene un archivo de cadena de certificados, anéxelo al archivo de certificado de clave pública en **SSL Certificate (Certificado SSL)**. ![\[SSL Settings interface with options for SSL Soporte, Certificate, Key, and Certification Authorities.\]](http://docs.aws.amazon.com/es_es/opsworks/latest/userguide/images/app_ssl_settings.png) Después de hacer clic en **Save (Guardar)**, [vuelva a implementar la aplicación](workingapps-deploying.md) para actualizar las instancias online. Para las [capas de servidor de aplicaciones integradas](workingcookbook-json.md#workingcookbook-json-deploy), OpsWorks Stacks actualiza automáticamente la configuración del servidor. Una vez finalizada la implementación, puede verificar que la instalación de OpenSSL ha sido correcta del modo siguiente. **Para verificar una instalación de OpenSSL** 1. Vaya a la página **Instances (Instancias)**. 1. Ejecute la aplicación haciendo clic en la dirección IP de la instancia del servidor de aplicaciones o, si utiliza un balanceador de carga, en la dirección IP del balanceador de carga. 1. Cambie el prefijo de la dirección IP de **http://** a **https://** y actualice el explorador para verificar si la página se carga correctamente con SSL. Los usuarios que tienen las aplicaciones configuradas para ejecutarse en Mozilla Firefox reciben a veces el siguiente error de certificado: `SEC_ERROR_UNKNOWN_ISSUER`. Este error puede deberse a una funcionalidad de sustitución de certificados de los programas antivirus y antimalware de su organización, a algunos tipos de software de monitorización y filtrado del tráfico de red o a malware. Para obtener más información acerca de cómo solucionar este error, consulte el tema sobre [cómo solucionar los códigos de error de seguridad en sitios web seguros](https://support.mozilla.org/en-US/kb/error-codes-secure-websites?redirectlocale=en-US&redirectslug=troubleshoot-SEC_ERROR_UNKNOWN_ISSUER#w_monitoringfiltering-in-corporate-networks) en el sitio web de soporte técnico de Mozilla Firefox. Para todas las demás capas, incluidas las capas personalizadas, OpsWorks Stacks simplemente añade la configuración de SSL a los [atributos `deploy`](workingcookbook-json.md#workingcookbook-json-deploy) de la aplicación. Debe implementar una receta personalizada para recuperar la información del objeto de nodo y configurar el servidor adecuadamente.