AWS App Runner dejará de estar abierto a nuevos clientes a partir del 30 de abril de 2026. Si quieres usar App Runner, regístrate antes de esa fecha. Los clientes existentes pueden seguir utilizando el servicio con normalidad. Para obtener más información, consulte [Cambio en la disponibilidad de AWS App Runner](https://docs.aws.amazon.com/apprunner/latest/dg/apprunner-availability-change.html). 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. # Servicio App Runner basado en código fuente Puede utilizarlos AWS App Runner para crear y gestionar servicios en función de dos tipos de fuente de servicio fundamentalmente diferentes: el *código fuente* y la imagen *fuente*. Independientemente del tipo de fuente, App Runner se encarga de iniciar, ejecutar, escalar y equilibrar la carga del servicio. Puedes usar la CI/CD capacidad de App Runner para realizar un seguimiento de los cambios en la imagen o el código fuente. Cuando App Runner descubre un cambio, compila automáticamente (para el código fuente) e implementa la nueva versión en tu servicio de App Runner. En este capítulo se analizan los servicios basados en el código fuente. Para obtener información sobre los servicios basados en una imagen fuente, consulte[Servicio App Runner basado en una imagen de origen](service-source-image.md). El código fuente es el código de aplicación que App Runner crea e implementa para usted. Dirige App Runner a un [directorio fuente](#service-source-code.source-directory) de un repositorio de código y eliges un tiempo de *ejecución* adecuado que corresponda a una versión de la plataforma de programación. App Runner crea una imagen basada en la imagen base del motor de ejecución y en el código de la aplicación. A continuación, inicia un servicio que ejecuta un contenedor en función de esta imagen. *App Runner proporciona cómodos tiempos de ejecución gestionados específicos de la plataforma.* Cada uno de estos tiempos de ejecución crea una imagen de contenedor a partir del código fuente y agrega dependencias de tiempo de ejecución del idioma a la imagen. No es necesario que proporciones instrucciones de configuración y compilación del contenedor, como un Dockerfile. Los subtemas de este capítulo tratan sobre las distintas plataformas compatibles con App Runner, es decir, *plataformas administradas* que proporcionan tiempos de ejecución gestionados para diferentes versiones y entornos de programación. **Topics** + [Proveedores de repositorios de código fuente](#service-source-code.providers) + [Directorio de fuentes](#service-source-code.source-directory) + [Plataformas gestionadas por App Runner](#service-source-code.managed-platforms) + [Fin del soporte para las versiones de tiempo de ejecución gestionado](#service-source-code.managed-platforms.eos) + [Versiones administradas en tiempo de ejecución y compilación de App Runner](#service-source-code.build-detail) + [Uso de la plataforma Python de](service-source-code-python.md) + [Uso de la plataforma Node.js de](service-source-code-nodejs.md) + [Uso de la plataforma Java](service-source-code-java.md) + [Uso de la plataforma .NET de](service-source-code-net6.md) + [Uso de la plataforma PHP de](service-source-code-php.md) + [Uso de la plataforma Ruby de](service-source-code-ruby.md) + [Uso de la plataforma Go de](service-source-code-go1.md) ## Proveedores de repositorios de código fuente App Runner despliega el código fuente leyéndolo desde un repositorio de código fuente. App Runner es compatible con dos proveedores de repositorios de código fuente: [GitHub](https://github.com/)y [Bitbucket](https://bitbucket.org/). ### Implementación desde tu proveedor de repositorios de código fuente Para implementar el código fuente en un servicio de App Runner desde un repositorio de código fuente, App Runner establece una conexión con él. Cuando utilizas la consola de App Runner para [crear un servicio](manage-create.md), proporcionas los detalles de la conexión y un directorio fuente para que App Runner despliegue tu código fuente. **Connections** Los detalles de conexión se proporcionan como parte del procedimiento de creación del servicio. Cuando utilizas la API de App Runner o la AWS CLI, una conexión es un recurso independiente. En primer lugar, se crea la conexión mediante la acción [CreateConnection](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateConnection.html)de la API. A continuación, proporciona el ARN de la conexión durante la creación del servicio mediante la acción de la [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)API. **Directorio de origen** Al crear un servicio, también se proporciona un directorio de origen. De forma predeterminada, App Runner usa el directorio raíz del repositorio como directorio de origen. El directorio fuente es la ubicación del repositorio de código fuente que almacena el código fuente y los archivos de configuración de la aplicación. Los comandos build e start también se ejecutan desde el directorio fuente. Cuando utilizas la API de App Runner o la AWS CLI para crear o actualizar un servicio, proporcionas el directorio de origen en las acciones de la [UpdateService](https://docs.aws.amazon.com/apprunner/latest/api/API_UpdateService.html)API [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)y la API. Para obtener más información, consulte la sección [Directorio de fuentes](#service-source-code.source-directory) siguiente. Para obtener más información sobre la creación del servicio App Runner, consulte[Creación de un servicio App Runner](manage-create.md). Para obtener más información sobre las conexiones de App Runner, consulte[Administrar las conexiones de App Runner](manage-connections.md). ## Directorio de fuentes Al crear un servicio de App Runner, puedes proporcionar el directorio de origen, junto con el repositorio y la rama. Defina el valor del campo **Directorio fuente** en la ruta del directorio del repositorio que almacena el código fuente y los archivos de configuración de la aplicación. App Runner ejecuta los comandos de compilación e inicio desde la ruta del directorio de origen que proporciones. Introduzca el valor de la ruta del directorio de origen como absoluto desde el directorio del repositorio raíz. Si no especificas un valor, el valor predeterminado es el directorio de nivel superior del repositorio, también conocido como directorio raíz del repositorio. También tienes la opción de proporcionar diferentes rutas de directorio de origen además del directorio del repositorio de nivel superior. Esto admite una arquitectura de repositorio monorepo, lo que significa que el código fuente de varias aplicaciones se almacena en un repositorio. Para crear y dar soporte a varios servicios de App Runner desde un único monorepo, especifica diferentes directorios de origen al crear cada servicio. **nota** Si especificas el mismo directorio de origen para varios servicios de App Runner, ambos servicios se implementarán y funcionarán de forma individual. Si opta por utilizar un archivo de `apprunner.yaml` configuración para definir los parámetros del servicio, colóquelo en la carpeta del directorio de origen del repositorio. Si la opción de **activación del despliegue** está configurada como **Automático**, los cambios que realices en el directorio de origen activarán un despliegue automático. * Solo los cambios en la ruta del directorio de origen* activarán una implementación automática. Es importante entender cómo afecta la ubicación del directorio de origen al alcance de una implementación automática. Para obtener más información, consulte las *implementaciones automatizadas en[Métodos de implementación](manage-deploy.md#manage-deploy.methods).* **nota** Si tu servicio de App Runner utiliza los tiempos de ejecución gestionados por PHP y quieres designar un directorio fuente distinto del repositorio raíz predeterminado, es importante que utilices la versión de tiempo de ejecución de PHP correcta. Para obtener más información, consulte [Uso de la plataforma PHP de](service-source-code-php.md). ## Plataformas gestionadas por App Runner Las plataformas gestionadas de App Runner proporcionan tiempos de ejecución gestionados para varios entornos de programación. Cada tiempo de ejecución administrado facilita la creación y la ejecución de contenedores basados en una versión de un lenguaje de programación o entorno de ejecución. Cuando usas un tiempo de ejecución administrado, App Runner comienza con una imagen de tiempo de ejecución administrado. Esta imagen se basa en la [imagen de Docker de Amazon Linux](https://hub.docker.com/_/amazonlinux) y contiene un paquete de ejecución de idiomas, así como algunas herramientas y paquetes de dependencias populares. App Runner usa esta imagen de tiempo de ejecución administrado como imagen base y agrega el código de la aplicación para crear una imagen de Docker. A continuación, implementa esta imagen para ejecutar el servicio web en un contenedor. Usted especifica un tiempo de ejecución para su servicio de App Runner al [crear un servicio](manage-create.md) mediante la consola de App Runner o la operación de la [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)API. También puedes especificar un tiempo de ejecución como parte de tu código fuente. Usa la `runtime` palabra clave en un [archivo de configuración de App Runner](config-file.md) que incluyas en tu repositorio de código. La convención de nomenclatura de un tiempo de ejecución gestionado es*

*. App Runner actualiza el tiempo de ejecución del servicio a la versión más reciente en cada implementación o actualización del servicio. Si su aplicación requiere una versión específica de un tiempo de ejecución administrado, puede especificarla mediante la `runtime-version` palabra clave del [archivo de configuración de App Runner](config-file.md). Puedes bloquearla en cualquier nivel de versión, incluida una versión principal o secundaria. App Runner solo realiza actualizaciones de nivel inferior en el tiempo de ejecución de tu servicio. ## Fin del soporte para las versiones de tiempo de ejecución gestionado Cuando el proveedor oficial o la comunidad de un entorno de ejecución en un lenguaje gestionado declara oficialmente que una versión ha finalizado su ciclo de vida útil (EOL), App Runner declara el estado de la versión como *End of Support*. Si su servicio se ejecuta en una versión de tiempo de ejecución de lenguaje administrado que ha llegado al final de Support, se aplican las siguientes políticas y recomendaciones. **Fin del soporte para una versión de ejecución de idiomas:** + **Los servicios existentes** seguirán funcionando y atendiendo el tráfico incluso si utilizan un tiempo de ejecución que haya llegado al final del soporte. Sin embargo, se ejecutarán en tiempos de ejecución no compatibles y ya no recibirán actualizaciones, parches de seguridad ni soporte técnico. + Se siguen **permitiendo las actualizaciones de los servicios existentes** que utilizan tiempos de ejecución de End of Support, pero no recomendamos seguir utilizando los tiempos de ejecución de End of Support para un servicio. + No se pueden crear **nuevos servicios** utilizando los tiempos de ejecución que han alcanzado la fecha de fin de Support. **Acciones necesarias para las versiones de ejecución de idiomas con estado de End of Support:** + Si el servicio se **basa en una imagen original**, no es necesario que realices ninguna otra acción para ese servicio. + Si el servicio se **basa en el código fuente**, actualice la configuración del servicio para utilizar una versión de tiempo de ejecución compatible. Para ello, selecciona una versión de tiempo de ejecución compatible en la [consola de App Runner](https://console.aws.amazon.com/apprunner), actualiza el `runtime` campo del archivo de configuración [apprunner.yaml](config-file.md) o usa las operaciones [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)/[UpdateService](https://docs.aws.amazon.com/apprunner/latest/api/API_UpdateService.html)API o las herramientas IaC para configurar el parámetro. `runtime` Para obtener una lista de los tiempos de ejecución compatibles, consulta la página de *información sobre la versión* correspondiente a cualquier tiempo de ejecución específico de este capítulo. + Como alternativa, puedes cambiar a la opción de **fuente de imagen de contenedor** de App Runner. Para obtener más información, consulte [Servicio basado en imágenes](service-source-image.md). **nota** Si vas a pasar de Node.js 12, 14 o 16 a **Node.js 22**, o de Python 3.7 o 3.8 a **Python 3.11**, ten en cuenta que Node.js 22 y Python 3.11 utilizan un proceso de compilación revisado de App Runner que ofrece compilaciones más rápidas y eficientes. Para garantizar la compatibilidad antes de realizar la actualización, te recomendamos que consultes las [instrucciones sobre el proceso de compilación](#service-source-code.build-detail) de la siguiente sección. En las siguientes tablas, se enumeran las versiones de tiempo de ejecución gestionado por App Runner que tienen una fecha de fin de soporte designada. | **Versiones en ejecución** | **Fecha de fin de soporte de App Runner** | | --- | --- | | Tiempos de [ejecución compatibles con](service-source-code-python-releases.md) Python 3.8 | 1 de diciembre de 2025 | | Tiempos de [ejecución compatibles con](service-source-code-python-releases.md) Python 3.7 | 1 de diciembre de 2025 | | Node.js 1.8 Tiempos de [ejecución compatibles](service-source-code-nodejs-releases.md) | 1 de diciembre de 2025 | | Node.js 16 Tiempos de [ejecución compatibles](service-source-code-nodejs-releases.md) | 1 de diciembre de 2025 | | Node.js 1.4 Tiempos de [ejecución compatibles](service-source-code-nodejs-releases.md) | 1 de diciembre de 2025 | | Node.js 1.2 Tiempos de [ejecución compatibles](service-source-code-nodejs-releases.md) | 1 de diciembre de 2025 | | .NET 6 \$1 | 1 de diciembre de 2025 | | PHP 8.1 \$1 | 31 de diciembre de 2025 | | Ruby 3.1 \$1 | 1 de diciembre de 2025 | | Ve 1 \$1 | 1 de diciembre de 2025 | **\$1** App Runner no lanzará ninguna versión en ningún idioma nuevo para los tiempos de ejecución marcados con un asterisco (\$1). Estos tiempos de ejecución son los siguientes: .NET, PHP, Ruby y Go. Si tienes un servicio basado en código configurado para estos tiempos de ejecución, te recomendamos que realices una de las siguientes acciones: + Si corresponde, cambie la configuración del servicio a un entorno de ejecución gestionado compatible diferente. + Como alternativa, puedes crear una imagen de contenedor personalizada con la versión de tiempo de ejecución que prefieras e implementarla con la [Servicio basado en imágenes](service-source-image.md) opción de App Runner. Puede alojar su imagen en Amazon ECR. ## Versiones administradas en tiempo de ejecución y compilación de App Runner App Runner ofrece un proceso de compilación actualizado para las aplicaciones que se ejecutan en los tiempos de ejecución de las versiones principales más recientes. Este proceso de compilación revisado es más rápido y eficiente. También crea una imagen final con un tamaño más reducido que solo contiene el código fuente, los artefactos de compilación y los tiempos de ejecución necesarios para ejecutar la aplicación. Nos referimos al proceso de compilación más reciente como la *versión revisada de App Runner* y al proceso de compilación original como la *versión original de App Runner*. Para evitar cambios repentinos en las versiones anteriores de las plataformas de ejecución, App Runner solo aplica la compilación revisada a versiones de ejecución específicas, normalmente a las versiones principales recién publicadas. Hemos introducido un nuevo componente en el archivo de `apprunner.yaml` configuración para que la compilación revisada sea compatible con versiones anteriores para un caso de uso muy específico y, además, para ofrecer más flexibilidad a la hora de configurar la compilación de la aplicación. Este es el [`pre-run`](config-file-ref.md#config-file-ref.run)parámetro opcional. Explicamos cuándo usar este parámetro junto con otra información útil sobre las compilaciones en las secciones siguientes. En la siguiente tabla se indica qué versión de la compilación de App Runner se aplica a versiones específicas de tiempo de ejecución gestionado. Seguiremos actualizando este documento para manteneros informados sobre nuestros tiempos de ejecución actuales. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/apprunner/latest/dg/service-source-code.html) **nota** Algunos de los tiempos de ejecución listados incluyen una fecha **de fin de Support**. Para obtener más información, consulte [Fin del soporte para las versiones de tiempo de ejecución gestionado](#service-source-code.managed-platforms.eos). **importante** **Python 3.11**: tenemos recomendaciones específicas para la configuración de compilación de los servicios que utilizan el tiempo de ejecución gestionado de Python 3.11. Para obtener más información, consulte [Llamadas para versiones de tiempo de ejecución específicas](service-source-code-python.md#service-source-code-python.callouts) el tema de la *plataforma Python*. ### Más información sobre las compilaciones y la migración de App Runner Al migrar la aplicación a un entorno de ejecución más reciente que utilice la compilación revisada, es posible que tengas que modificar ligeramente la configuración de la compilación. Para dar contexto a las consideraciones de migración, primero describiremos los procesos de alto nivel tanto para la compilación original de App Runner como para la versión revisada. Seguiremos con una sección en la que se describen los atributos específicos de tu servicio que podrían requerir algunas actualizaciones de configuración. #### La versión original de App Runner El proceso de creación de la aplicación App Runner original aprovecha el AWS CodeBuild servicio. Los pasos iniciales se basan en imágenes seleccionadas por el CodeBuild servicio. Sigue un proceso de compilación de Docker que usa la imagen de tiempo de ejecución administrada de App Runner correspondiente como imagen base. Los pasos generales son los siguientes: 1. Ejecute `pre-build` los comandos en una imagen CodeBuild seleccionada. Los `pre-build` comandos son opcionales. Solo se pueden especificar en el archivo `apprunner.yaml` de configuración. 1. Ejecute los `build` comandos utilizando CodeBuild la misma imagen del paso anterior. Los `build` comandos son obligatorios. Se pueden especificar en la consola de App Runner, en la API de App Runner o en el archivo `apprunner.yaml` de configuración. 1. Ejecuta una compilación de Docker para generar una imagen basada en la imagen de tiempo de ejecución gestionada por App Runner para tu plataforma y versión de ejecución específicas. 1. Copia el `/app` directorio de la imagen que generamos en el **paso 2**. El destino es la imagen basada en la imagen de tiempo de ejecución gestionada por App Runner, que generamos en el **paso 3**. 1. Vuelva a ejecutar los `build` comandos en la imagen de tiempo de ejecución gestionada por App Runner generada. Volvemos a ejecutar los comandos de compilación para generar artefactos de compilación a partir del código fuente del `/app` directorio que copiamos en él en el **paso 4**. App Runner implementará esta imagen más adelante para ejecutar el servicio web en un contenedor. Los `build` comandos son obligatorios. Se pueden especificar en la consola de App Runner, en la API de App Runner o en el archivo `apprunner.yaml` de configuración. 1. Ejecute `post-build` los comandos de la CodeBuild imagen del **paso 2**. Los `post-build` comandos son opcionales. Solo se pueden especificar en el archivo `apprunner.yaml` de configuración. Una vez completada la compilación, App Runner implementa la imagen de tiempo de ejecución gestionada por App Runner generada en el **paso 5** para ejecutar el servicio web en un contenedor. #### La versión revisada de App Runner El proceso de creación revisado es más rápido y eficiente que el proceso de creación original descrito en la sección anterior. Elimina la duplicación de los comandos de compilación que se producía en la compilación de la versión anterior. También crea una imagen final con un tamaño más reducido que solo contiene el código fuente, los artefactos de compilación y los tiempos de ejecución necesarios para ejecutar la aplicación. Este proceso de compilación utiliza una compilación de varias etapas de Docker. Los pasos generales del proceso son los siguientes: 1. **Etapa de compilación**: inicia un proceso de compilación de docker que ejecute `pre-build` y `build` comanda sobre las imágenes de compilación de App Runner. 1. Copia el código fuente de la aplicación en el `/app` directorio. **nota** Este `/app` directorio se designa como directorio de trabajo en todas las etapas de la compilación de Docker. 1. Run Command `pre-build`. Los `pre-build` comandos son opcionales. Solo se pueden especificar en el archivo `apprunner.yaml` de configuración. 1. Ejecute los `build` comandos. Los `build` comandos son obligatorios. Se pueden especificar en la consola de App Runner, en la API de App Runner o en el archivo `apprunner.yaml` de configuración. 1. **Etapa de empaquetado**: genera la imagen final del contenedor del cliente, que también se basa en la imagen de ejecución de App Runner. 1. Copia el `/app` directorio de la **etapa de compilación** anterior a la nueva imagen de ejecución. Esto incluye el código fuente de la aplicación y los artefactos de compilación de la etapa anterior. 1. Ejecute los `pre-run` comandos. Si necesita modificar la imagen en tiempo de ejecución fuera del `/app` directorio mediante los `build` comandos, añada los mismos comandos o los necesarios a este segmento del archivo de `apprunner.yaml` configuración. Se trata de un parámetro nuevo que se introdujo para admitir la versión revisada de App Runner. Los `pre-run` comandos son opcionales. Solo se pueden especificar en el archivo `apprunner.yaml` de configuración. **Notas** Los `pre-run` comandos solo son compatibles con la versión revisada. No los añada al archivo de configuración si el servicio utiliza versiones en tiempo de ejecución que utilizan la compilación original. Si no necesita modificar nada fuera del `/app` directorio con los `build` comandos, no necesita `pre-run` especificarlos. 1. Etapa **posterior a la compilación**: esta etapa se reanuda desde la *etapa de compilación* y ejecuta `post-build` los comandos. 1. Ejecute los `post-build` comandos dentro del `/app` directorio. Los `post-build` comandos son opcionales. Solo se pueden especificar en el archivo `apprunner.yaml` de configuración. Una vez completada la compilación, App Runner implementa la imagen de ejecución para ejecutar el servicio web en un contenedor. **nota** `apprunner.yaml`Al configurar el proceso de compilación, no se deje engañar por las `env` entradas de la sección Ejecutar. Aunque el parámetro de `pre-run` comando, al que se hace referencia en el **paso 2 (b)**, reside en la sección Ejecutar, no utilices el `env` parámetro de la sección Ejecutar para configurar la compilación. Los `pre-run` comandos solo hacen referencia a las `env` variables definidas en la sección Compilación del archivo de configuración. Para obtener más información, consulte [Sección de ejecución](config-file-ref.md#config-file-ref.run) el *capítulo del archivo de configuración de App Runner*. #### Requisitos de servicio para tener en cuenta la migración Si el entorno de su aplicación tiene alguno de estos dos requisitos, tendrá que revisar la configuración de compilación añadiendo `pre-run` comandos. + Si necesitas modificar algo fuera del `/app` directorio con los `build` comandos. + Si necesita ejecutar los `build` comandos dos veces para crear el entorno requerido. Se trata de un requisito muy inusual. La gran mayoría de las versiones no lo harán. **Modificaciones fuera del `/app` directorio** + La [versión revisada de App Runner](#service-source-code.build-detail.v2) asume que la aplicación no tiene dependencias fuera del `/app` directorio. + Los comandos que proporciones con el `apprunner.yaml` archivo, la API de App Runner o la consola de App Runner deben generar artefactos de compilación en el `/app` directorio. + Puedes modificar los `post-build` comandos `pre-build``build`, y para asegurarte de que todos los artefactos de compilación estén en el `/app` directorio. + Si la aplicación requiere que la compilación modifique aún más la imagen generada para el servicio, fuera del `/app` directorio, puede usar los nuevos `pre-run` comandos del`apprunner.yaml`. Para obtener más información, consulte [Configuración de las opciones de servicio de App Runner mediante un archivo de configuración](config-file.md). **Ejecutar los `build` comandos dos veces** + La [versión original de App Runner](#service-source-code.build-detail.v1) ejecuta los `build` comandos dos veces, primero en el **paso 2** y luego nuevamente en el **paso 5**. La versión revisada de App Runner corrige esta redundancia y solo ejecuta los `build` comandos una vez. Si tu aplicación requiere que los `build` comandos se ejecuten dos veces, algo inusual, en la versión revisada de App Runner se ofrece la opción de especificar y volver a ejecutar los mismos comandos mediante el `pre-run` parámetro. Al hacerlo, se conserva el mismo comportamiento de compilación doble. # Uso de la plataforma Python de **importante** App Runner dejará de ser compatible con **Python 3.7** y **Python 3.8** el 1 de diciembre de 2025. Para obtener recomendaciones y más información, consulte[Fin del soporte para las versiones de tiempo de ejecución gestionado](service-source-code.md#service-source-code.managed-platforms.eos). La plataforma AWS App Runner Python proporciona tiempos de ejecución gestionados. Cada tiempo de ejecución facilita la creación y ejecución de contenedores con aplicaciones web basadas en una versión de Python. Cuando utilizas un entorno de ejecución de Python, App Runner comienza con una imagen de tiempo de ejecución de Python gestionada. Esta imagen se basa en la [imagen de Docker de Amazon Linux](https://hub.docker.com/_/amazonlinux) y contiene el paquete de tiempo de ejecución de una versión de Python y algunas herramientas y paquetes de dependencias populares. App Runner usa esta imagen de tiempo de ejecución administrado como imagen base y agrega el código de la aplicación para crear una imagen de Docker. A continuación, implementa esta imagen para ejecutar el servicio web en un contenedor. Usted especifica un tiempo de ejecución para su servicio de App Runner al [crear un servicio](manage-create.md) mediante la consola de App Runner o la operación de la [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)API. También puedes especificar un tiempo de ejecución como parte de tu código fuente. Usa la `runtime` palabra clave en un [archivo de configuración de App Runner](config-file.md) que incluyas en tu repositorio de código. La convención de nomenclatura de un tiempo de ejecución gestionado es*

*. Para obtener nombres y versiones de tiempo de ejecución de Python válidos, consulte[Información sobre la versión del motor de ejecución de Python](service-source-code-python-releases.md). App Runner actualiza el tiempo de ejecución del servicio a la versión más reciente en cada implementación o actualización del servicio. Si su aplicación requiere una versión específica de un tiempo de ejecución administrado, puede especificarla mediante la `runtime-version` palabra clave del [archivo de configuración de App Runner](config-file.md). Puedes bloquearla en cualquier nivel de versión, incluida una versión principal o secundaria. App Runner solo realiza actualizaciones de nivel inferior en el tiempo de ejecución de tu servicio. Sintaxis de versión para tiempos de ejecución de Python: `major[.minor[.patch]]` Por ejemplo: `3.8.5` Los siguientes ejemplos muestran el bloqueo de versiones: + `3.8`— Bloquee las versiones principales y secundarias. App Runner actualiza solo las versiones con parches. + `3.8.5`— Bloquear una versión de parche específica. App Runner no actualiza tu versión de ejecución. **Topics** + [Configuración del tiempo de ejecución de Python](#service-source-code-python.config) + [Llamadas para versiones de tiempo de ejecución específicas](#service-source-code-python.callouts) + [Ejemplos de tiempo de ejecución de Python](#service-source-code-python.examples) + [Información sobre la versión del motor de ejecución de Python](service-source-code-python-releases.md) ## Configuración del tiempo de ejecución de Python Al elegir un tiempo de ejecución administrado, también debe configurar, como mínimo, los comandos de compilación y ejecución. Los configuras al [crear](manage-create.md) o [actualizar](manage-configure.md) tu servicio App Runner. Puede hacerlo mediante uno de los siguientes métodos: + **Mediante la consola de App Runner**: especifique los comandos en la sección **Configurar compilación** del proceso de creación o en la pestaña de configuración. + **Uso de la API de App Runner**: llame a la operación [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)o [UpdateService](https://docs.aws.amazon.com/apprunner/latest/api/API_UpdateService.html)API. Especifique los comandos mediante los `StartCommand` miembros `BuildCommand` y del tipo de [CodeConfigurationValues](https://docs.aws.amazon.com/apprunner/latest/api/API_CodeConfigurationValues.html)datos. + **Uso de un [archivo de configuración](config-file.md)**: especifique uno o más comandos de compilación en un máximo de tres fases de compilación y un solo comando de ejecución que sirva para iniciar la aplicación. Hay opciones de configuración opcionales adicionales. Proporcionar un archivo de configuración es opcional. Al crear un servicio de App Runner mediante la consola o la API, debe especificar si App Runner obtiene los ajustes de configuración directamente al crearlos o de un archivo de configuración. ## Llamadas para versiones de tiempo de ejecución específicas **nota** App Runner ahora ejecuta un proceso de compilación actualizado para aplicaciones basado en las siguientes versiones de tiempo de ejecución: Python 3.11, Node.js 22 y Node.js 18. Si tu aplicación se ejecuta en alguna de estas versiones en tiempo de ejecución, consulta [Versiones administradas en tiempo de ejecución y compilación de App Runner](service-source-code.md#service-source-code.build-detail) para obtener más información sobre el proceso de compilación revisado. Las aplicaciones que utilizan todas las demás versiones en tiempo de ejecución no se ven afectadas y siguen utilizando el proceso de compilación original. ### Python 3.11 (versión revisada de App Runner) Usa la siguiente configuración en *apprunner.yaml para* el tiempo de ejecución administrado de Python 3.11. + Establece la clave de la sección superior en `runtime` `python311` **Example** ``` runtime: python311 ``` + Use el `pip3` en lugar de `pip` para instalar las dependencias. + Utilice el `python3` intérprete en lugar de. `python` + Ejecute el `pip3` instalador como un `pre-run` comando. Python instala las dependencias fuera del `/app` directorio. Dado que App Runner ejecuta la versión revisada de App Runner para Python 3.11, se perderá todo lo que se instale fuera del `/app` directorio mediante los comandos de la sección Compilación del `apprunner.yaml` archivo. Para obtener más información, consulte [La versión revisada de App Runner](service-source-code.md#service-source-code.build-detail.v2). **Example** ``` run: runtime-version: 3.11 pre-run: - pip3 install pipenv - pipenv install - python3 copy-global-files.py command: pipenv run gunicorn django_apprunner.wsgi --log-file - ``` Para obtener más información, consulte también el [ejemplo de un archivo de configuración extendido para Python 3.11](#service-source-code-python.examples.extended-v2) más adelante en este tema. ## Ejemplos de tiempo de ejecución de Python Los siguientes ejemplos muestran los archivos de configuración de App Runner para crear y ejecutar un servicio de Python. El último ejemplo es el código fuente de una aplicación Python completa que se puede implementar en un servicio de tiempo de ejecución de Python. **nota** La versión en tiempo de ejecución que se utiliza en estos ejemplos es *3.7.7* y*3.11*. Puede sustituirla por la versión que desee utilizar. Para ver la última versión de tiempo de ejecución de Python compatible, consulte[Información sobre la versión del motor de ejecución de Python](service-source-code-python-releases.md). ### Archivo de configuración mínimo de Python En este ejemplo se muestra un archivo de configuración mínimo que puede utilizar con un entorno de ejecución gestionado por Python. Para ver las suposiciones que App Runner hace con un archivo de configuración mínimo, consulte[Ejemplos de archivos de configuración](config-file-examples.md#config-file-examples.managed). Python 3.11 usa los `python3` comandos `pip3` y. Para obtener más información, consulte el [ejemplo de un archivo de configuración extendido para Python 3.11](#service-source-code-python.examples.extended-v2) más adelante en este tema. **Example apprunner.yaml** ``` version: 1.0 runtime: python3 build: commands: build: - pip install pipenv - pipenv install run: command: python app.py ``` ### Archivo de configuración de Python extendido Este ejemplo muestra el uso de todas las claves de configuración con un entorno de ejecución gestionado por Python. **nota** La versión de tiempo de ejecución que se utiliza en estos ejemplos es*3.7.7*. Puede sustituirla por la versión que desee utilizar. Para ver la última versión de tiempo de ejecución de Python compatible, consulte[Información sobre la versión del motor de ejecución de Python](service-source-code-python-releases.md). Python 3.11 usa los `python3` comandos `pip3` y. Para obtener más información, consulte el ejemplo de un archivo de configuración extendido para Python 3.11 más adelante en este tema. **Example apprunner.yaml** ``` version: 1.0 runtime: python3 build: commands: pre-build: - wget -c https://s3.amazonaws.com/amzn-s3-demo-bucket/test-lib.tar.gz -O - | tar -xz build: - pip install pipenv - pipenv install post-build: - python manage.py test env: - name: DJANGO_SETTINGS_MODULE value: "django_apprunner.settings" - name: MY_VAR_EXAMPLE value: "example" run: runtime-version: 3.7.7 command: pipenv run gunicorn django_apprunner.wsgi --log-file - network: port: 8000 env: MY_APP_PORT env: - name: MY_VAR_EXAMPLE value: "example" secrets: - name: my-secret value-from: "arn:aws:secretsmanager:us-east-1:123456789012:secret:testingstackAppRunnerConstr-kJFXde2ULKbT-S7t8xR:username::" - name: my-parameter value-from: "arn:aws:ssm:us-east-1:123456789012:parameter/parameter-name" - name: my-parameter-only-name value-from: "parameter-name" ``` ### Archivo de configuración de Python extendido: Python 3.11 (usa una compilación revisada) En este ejemplo se muestra el uso de todas las claves de configuración con un entorno de ejecución gestionado por Python 3.11 en. `apprunner.yaml` En este ejemplo se incluye una `pre-run` sección, ya que esta versión de Python usa la versión revisada de App Runner. El `pre-run` parámetro solo es compatible con la versión revisada de App Runner. No insertes este parámetro en el archivo de configuración si la aplicación usa versiones en tiempo de ejecución compatibles con la compilación original de App Runner. Para obtener más información, consulte [Versiones administradas en tiempo de ejecución y compilación de App Runner](service-source-code.md#service-source-code.build-detail). **nota** La versión en tiempo de ejecución que se usa en estos ejemplos es*3.11*. Puede sustituirla por la versión que desee utilizar. Para ver la última versión de tiempo de ejecución de Python compatible, consulte[Información sobre la versión del motor de ejecución de Python](service-source-code-python-releases.md). **Example apprunner.yaml** ``` version: 1.0 runtime: python311 build: commands: pre-build: - wget -c https://s3.amazonaws.com/amzn-s3-demo-bucket/test-lib.tar.gz -O - | tar -xz build: - pip3 install pipenv - pipenv install post-build: - python3 manage.py test env: - name: DJANGO_SETTINGS_MODULE value: "django_apprunner.settings" - name: MY_VAR_EXAMPLE value: "example" run: runtime-version: 3.11 pre-run: - pip3 install pipenv - pipenv install - python3 copy-global-files.py command: pipenv run gunicorn django_apprunner.wsgi --log-file - network: port: 8000 env: MY_APP_PORT env: - name: MY_VAR_EXAMPLE value: "example" secrets: - name: my-secret value-from: "arn:aws:secretsmanager:us-east-1:123456789012:secret:testingstackAppRunnerConstr-kJFXde2ULKbT-S7t8xR:username::" - name: my-parameter value-from: "arn:aws:ssm:us-east-1:123456789012:parameter/parameter-name" - name: my-parameter-only-name value-from: "parameter-name" ``` ### Fuente completa de la aplicación Python En este ejemplo, se muestra el código fuente de una aplicación de Python completa que se puede implementar en un servicio de tiempo de ejecución de Python. **Example requirements.txt** ``` pyramid==2.0 ``` **Example server.py** ``` from wsgiref.simple_server import make_server from pyramid.config import Configurator from pyramid.response import Response import os def hello_world(request): name = os.environ.get('NAME') if name == None or len(name) == 0: name = "world" message = "Hello, " + name + "!\n" return Response(message) if __name__ == '__main__': port = int(os.environ.get("PORT")) with Configurator() as config: config.add_route('hello', '/') config.add_view(hello_world, route_name='hello') app = config.make_wsgi_app() server = make_server('0.0.0.0', port, app) server.serve_forever() ``` **Example apprunner.yaml** ``` version: 1.0 runtime: python3 build: commands: build: - pip install -r requirements.txt run: command: python server.py ``` # Información sobre la versión del motor de ejecución de Python **importante** App Runner dejará de ser compatible con **Python 3.7** y **Python 3.8** el 1 de diciembre de 2025. Para obtener recomendaciones y más información, consulte[Fin del soporte para las versiones de tiempo de ejecución gestionado](service-source-code.md#service-source-code.managed-platforms.eos). En este tema se enumeran todos los detalles de las versiones de tiempo de ejecución de Python compatibles con App Runner. **Versiones de tiempo de ejecución compatibles: versión revisada de App Runner** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/apprunner/latest/dg/service-source-code-python-releases.html) **Notas** **Python 3.11**: tenemos recomendaciones específicas para la configuración de compilación de los servicios que utilizan el tiempo de ejecución gestionado de Python 3.11. Para obtener más información, consulte [Llamadas para versiones de tiempo de ejecución específicas](service-source-code-python.md#service-source-code-python.callouts) el tema de la *plataforma Python*. App Runner proporciona un proceso de compilación revisado para los principales tiempos de ejecución específicos que se publicaron más recientemente. Por este motivo, verás referencias a la *versión revisada de App Runner y a* la versión *original de App Runner* en determinadas secciones de este documento. Para obtener más información, consulte [Versiones administradas en tiempo de ejecución y compilación de App Runner](service-source-code.md#service-source-code.build-detail). **Versiones de ejecución compatibles: versión original de App Runner** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/apprunner/latest/dg/service-source-code-python-releases.html) **nota** App Runner proporciona un proceso de compilación revisado para los principales tiempos de ejecución específicos que se publicaron más recientemente. Por este motivo, verás referencias a la *versión revisada de App Runner y a* la versión *original de App Runner* en determinadas secciones de este documento. Para obtener más información, consulte [Versiones administradas en tiempo de ejecución y compilación de App Runner](service-source-code.md#service-source-code.build-detail). # Uso de la plataforma Node.js de **importante** App Runner dejará de ser compatible con **Node.js 12**, **Node.js 14**, **Node.js 16** y **Node.js 18** el 1 de diciembre de 2025. Para obtener recomendaciones y más información, consulte[Fin del soporte para las versiones de tiempo de ejecución gestionado](service-source-code.md#service-source-code.managed-platforms.eos). La plataforma AWS App Runner Node.js proporciona tiempos de ejecución gestionados. Cada tiempo de ejecución facilita la creación y ejecución de contenedores con aplicaciones web basadas en una versión de Node.js. Cuando usas un entorno de ejecución de Node.js, App Runner comienza con una imagen de tiempo de ejecución de Node.js administrada. Esta imagen se basa en la [imagen de Docker de Amazon Linux](https://hub.docker.com/_/amazonlinux) y contiene el paquete de tiempo de ejecución de una versión de Node.js y algunas herramientas. App Runner usa esta imagen de tiempo de ejecución administrada como imagen base y agrega el código de la aplicación para crear una imagen de Docker. A continuación, implementa esta imagen para ejecutar el servicio web en un contenedor. Usted especifica un tiempo de ejecución para su servicio de App Runner al [crear un servicio](manage-create.md) mediante la consola de App Runner o la operación de la [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)API. También puedes especificar un tiempo de ejecución como parte de tu código fuente. Usa la `runtime` palabra clave en un [archivo de configuración de App Runner](config-file.md) que incluyas en tu repositorio de código. La convención de nomenclatura de un tiempo de ejecución gestionado es*

*. Para obtener nombres y versiones de tiempo de ejecución de Node.js válidos, consulte[Información de versión en tiempo de ejecución de Node.js](service-source-code-nodejs-releases.md). App Runner actualiza el tiempo de ejecución del servicio a la versión más reciente en cada implementación o actualización del servicio. Si su aplicación requiere una versión específica de un tiempo de ejecución administrado, puede especificarla mediante la `runtime-version` palabra clave del [archivo de configuración de App Runner](config-file.md). Puedes bloquearla en cualquier nivel de versión, incluida una versión principal o secundaria. App Runner solo realiza actualizaciones de nivel inferior en el tiempo de ejecución de tu servicio. Sintaxis de versión para los tiempos de ejecución de Node.js: `major[.minor[.patch]]` Por ejemplo: `22.14.0` Los siguientes ejemplos muestran el bloqueo de versiones: + `22.14`— Bloquee las versiones principales y secundarias. App Runner actualiza solo las versiones con parches. + `22.14.0`— Bloquear una versión de parche específica. App Runner no actualiza tu versión en tiempo de ejecución. **Topics** + [Configuración de tiempo de ejecución de Node.js](#service-source-code-nodejs.config) + [Llamadas para versiones de ejecución específicas](#service-source-code-nodejs.callouts) + [Ejemplos de tiempo de ejecución de Node.js](#service-source-code-nodejs.examples) + [Información de versión en tiempo de ejecución de Node.js](service-source-code-nodejs-releases.md) ## Configuración de tiempo de ejecución de Node.js Al elegir un tiempo de ejecución administrado, también debe configurar, como mínimo, los comandos de compilación y ejecución. Los configuras al [crear](manage-create.md) o [actualizar](manage-configure.md) tu servicio App Runner. Puede hacerlo mediante uno de los siguientes métodos: + **Mediante la consola de App Runner**: especifique los comandos en la sección **Configurar compilación** del proceso de creación o en la pestaña de configuración. + **Uso de la API de App Runner**: llame a la operación [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)o [UpdateService](https://docs.aws.amazon.com/apprunner/latest/api/API_UpdateService.html)API. Especifique los comandos mediante los `StartCommand` miembros `BuildCommand` y del tipo de [CodeConfigurationValues](https://docs.aws.amazon.com/apprunner/latest/api/API_CodeConfigurationValues.html)datos. + **Uso de un [archivo de configuración](config-file.md)**: especifique uno o más comandos de compilación en un máximo de tres fases de compilación y un solo comando de ejecución que sirva para iniciar la aplicación. Hay opciones de configuración opcionales adicionales. El suministro de un archivo de configuración es opcional. Al crear un servicio de App Runner mediante la consola o la API, debe especificar si App Runner obtiene los ajustes de configuración directamente al crearlos o de un archivo de configuración. En el caso específico de los tiempos de ejecución de Node.js, también puedes configurar la compilación y el tiempo de ejecución mediante un archivo JSON cuyo nombre aparece `package.json` en la raíz del repositorio de origen. Con este archivo, puedes configurar la versión del motor Node.js, los paquetes de dependencias y varios comandos (aplicaciones de línea de comandos). Los administradores de paquetes como npm o yarn interpretan este archivo como entrada para sus comandos. Por ejemplo: + **npm install**instala los paquetes definidos por el `devDependencies` nodo `dependencies` and en. `package.json` + **npm start**o **npm run start** ejecuta el comando definido por el `scripts/start` nodo en`package.json`. A continuación se muestra un ejemplo de un archivo `package.json`. ### package.json ``` { "name": "node-js-getting-started", "version": "0.3.0", "description": "A sample Node.js app using Express 4", "engines": { "node": "22.14.0" }, "scripts": { "start": "node index.js", "test": "node test.js" }, "dependencies": { "cool-ascii-faces": "^1.3.4", "ejs": "^2.5.6", "express": "^4.15.2" }, "devDependencies": { "got": "^11.3.0", "tape": "^4.7.0" } } ``` Para obtener más información`package.json`, consulte [Crear un archivo package.json en el sitio web](https://docs.npmjs.com/creating-a-package-json-file) de *npm Docs.* **Consejos** Si tu `package.json` archivo define un **start** comando, puedes usarlo como un **run** comando en el archivo de configuración de App Runner, como se muestra en el siguiente ejemplo. **Example** package.json ``` { "scripts": { "start": "node index.js" } } ``` apprunner.yaml ``` run: command: npm start ``` Cuando ejecutas **npm install** en tu entorno de desarrollo, npm crea el archivo. `package-lock.json` Este archivo contiene una instantánea de las versiones del paquete que npm acaba de instalar. A partir de entonces, cuando npm instala dependencias, usa exactamente estas versiones. Si instalas yarn, se crea un archivo. `yarn.lock` Guarde estos archivos en su repositorio de código fuente para asegurarse de que su aplicación esté instalada con las versiones de las dependencias que desarrolló y con las que la probó. También puedes usar un archivo de configuración de App Runner para configurar la versión y el comando start de Node.js. Al hacer esto, estas definiciones anulan las que figuran en`package.json`. Un conflicto entre la `node` versión original `package.json` y el `runtime-version` valor del archivo de configuración de App Runner provoca un error en la fase de compilación de App Runner. ## Llamadas para versiones de ejecución específicas ### Node.js 22 y Node.js 18 (versión revisada de App Runner) App Runner ahora ejecuta un proceso de compilación actualizado para aplicaciones basado en las siguientes versiones de tiempo de ejecución: Python 3.11, Node.js 22 y Node.js 18. Si tu aplicación se ejecuta en alguna de estas versiones en tiempo de ejecución, consulta [Versiones administradas en tiempo de ejecución y compilación de App Runner](service-source-code.md#service-source-code.build-detail) para obtener más información sobre el proceso de compilación revisado. Las aplicaciones que utilizan todas las demás versiones en tiempo de ejecución no se ven afectadas y siguen utilizando el proceso de compilación original. ## Ejemplos de tiempo de ejecución de Node.js Los siguientes ejemplos muestran los archivos de configuración de App Runner para crear y ejecutar un servicio Node.js. **nota** La versión en tiempo de ejecución que se usa en estos ejemplos es*22.14.0*. Puede sustituirla por la versión que desee utilizar. Para ver la última versión de tiempo de ejecución de Node.js compatible, consulte[Información de versión en tiempo de ejecución de Node.js](service-source-code-nodejs-releases.md). ### Fichero de configuración mínimo de Node.js En este ejemplo, se muestra un archivo de configuración mínimo que puede utilizar con un entorno de ejecución gestionado por Node.js. Para ver las suposiciones que App Runner hace con un archivo de configuración mínimo, consulte[Ejemplos de archivos de configuración](config-file-examples.md#config-file-examples.managed). **Example apprunner.yaml** ``` version: 1.0 runtime: nodejs22 build: commands: build: - npm install --production run: command: node app.js ``` ### Archivo de configuración extendido de Node.js En este ejemplo, se muestra el uso de todas las claves de configuración con un entorno de ejecución gestionado por Node.js. **nota** La versión de tiempo de ejecución que se utiliza en estos ejemplos es*22.14.0*. Puede sustituirla por la versión que desee utilizar. Para ver la última versión de tiempo de ejecución de Node.js compatible, consulte[Información de versión en tiempo de ejecución de Node.js](service-source-code-nodejs-releases.md). **Example apprunner.yaml** ``` version: 1.0 runtime: nodejs22 build: commands: pre-build: - npm install --only=dev - node test.js build: - npm install --production post-build: - node node_modules/ejs/postinstall.js env: - name: MY_VAR_EXAMPLE value: "example" run: runtime-version: 22.14.0 command: node app.js network: port: 8000 env: APP_PORT env: - name: MY_VAR_EXAMPLE value: "example" ``` ### Archivo de configuración extendido de Node.js: Node.js 22 (usa una versión revisada) En este ejemplo se muestra el uso de todas las claves de configuración con un tiempo de ejecución gestionado por Node.js en`apprunner.yaml`. En este ejemplo se incluye una `pre-run` sección, ya que esta versión de Node.js usa la versión revisada de App Runner. El `pre-run` parámetro solo es compatible con la versión revisada de App Runner. No insertes este parámetro en el archivo de configuración si la aplicación usa versiones en tiempo de ejecución compatibles con la compilación original de App Runner. Para obtener más información, consulte [Versiones administradas en tiempo de ejecución y compilación de App Runner](service-source-code.md#service-source-code.build-detail). **nota** La versión en tiempo de ejecución que se usa en estos ejemplos es*22.14.0*. Puede sustituirla por la versión que desee utilizar. Para ver la última versión de tiempo de ejecución de Node.js compatible, consulte[Información de versión en tiempo de ejecución de Node.js](service-source-code-nodejs-releases.md). **Example apprunner.yaml** ``` version: 1.0 runtime: nodejs22 build: commands: pre-build: - npm install --only=dev - node test.js build: - npm install --production post-build: - node node_modules/ejs/postinstall.js env: - name: MY_VAR_EXAMPLE value: "example" run: runtime-version: 22.14.0 pre-run: - node copy-global-files.js command: node app.js network: port: 8000 env: APP_PORT env: - name: MY_VAR_EXAMPLE value: "example" ``` ### Aplicación Node.js con Grunt En este ejemplo se muestra cómo configurar una aplicación Node.js desarrollada con Grunt. [Grunt](https://gruntjs.com/) es un ejecutor de JavaScript tareas de línea de comandos. Ejecuta tareas repetitivas y gestiona la automatización de los procesos para reducir los errores humanos. Los complementos de Grunt y Grunt se instalan y administran mediante npm. Para configurar Grunt, debe incluir el `Gruntfile.js` archivo en la raíz de su repositorio de código fuente. **Example package.json** ``` { "scripts": { "build": "grunt uglify", "start": "node app.js" }, "devDependencies": { "grunt": "~0.4.5", "grunt-contrib-jshint": "~0.10.0", "grunt-contrib-nodeunit": "~0.4.1", "grunt-contrib-uglify": "~0.5.0" }, "dependencies": { "express": "^4.15.2" }, } ``` **Example Gruntfile.js** ``` module.exports = function(grunt) { // Project configuration. grunt.initConfig({ pkg: grunt.file.readJSON('package.json'), uglify: { options: { banner: '/*! <%= pkg.name %> <%= grunt.template.today("yyyy-mm-dd") %> */\n' }, build: { src: 'src/<%= pkg.name %>.js', dest: 'build/<%= pkg.name %>.min.js' } } }); // Load the plugin that provides the "uglify" task. grunt.loadNpmTasks('grunt-contrib-uglify'); // Default task(s). grunt.registerTask('default', ['uglify']); }; ``` **Example apprunner.yaml** La versión en tiempo de ejecución que se utiliza en estos ejemplos es. *22.14.0* Puede sustituirla por la versión que desee utilizar. Para ver la última versión de tiempo de ejecución de Node.js compatible, consulte[Información de versión en tiempo de ejecución de Node.js](service-source-code-nodejs-releases.md). ``` version: 1.0 runtime: nodejs22 build: commands: pre-build: - npm install grunt grunt-cli - npm install --only=dev - npm run build build: - npm install --production run: runtime-version: 22.14.0 command: node app.js network: port: 8000 env: APP_PORT ``` # Información de versión en tiempo de ejecución de Node.js **importante** App Runner dejará de ser compatible con **Node.js 12**, **Node.js 14**, **Node.js 16** y **Node.js 18** el 1 de diciembre de 2025. Para obtener recomendaciones y más información, consulte[Fin del soporte para las versiones de tiempo de ejecución gestionado](service-source-code.md#service-source-code.managed-platforms.eos). **nota** La política de obsolescencia estándar de App Runner consiste en dejar obsoleto un entorno de ejecución cuando algún componente importante del mismo llegue al final del soporte a largo plazo de la comunidad (LTS) y las actualizaciones de seguridad ya no estén disponibles. En algunos casos, App Runner puede retrasar la obsolescencia de un tiempo de ejecución durante un período limitado, más allá de la end-of-support fecha de la versión lingüística compatible con el tiempo de ejecución. Un ejemplo de este tipo de casos podría ser ampliar la compatibilidad con un entorno de ejecución para que los clientes tengan tiempo de migrar. En este tema se enumeran todos los detalles de las versiones en tiempo de ejecución de Node.js compatibles con App Runner. **Versiones en tiempo de ejecución compatibles: versión revisada de App Runner** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/apprunner/latest/dg/service-source-code-nodejs-releases.html) **nota** App Runner proporciona un proceso de compilación revisado para los principales tiempos de ejecución específicos que se publicaron más recientemente. Por este motivo, verás referencias a la *versión revisada de App Runner y a* la versión *original de App Runner* en determinadas secciones de este documento. Para obtener más información, consulte [Versiones administradas en tiempo de ejecución y compilación de App Runner](service-source-code.md#service-source-code.build-detail). **Versiones de ejecución compatibles: versión revisada de App Runner** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/apprunner/latest/dg/service-source-code-nodejs-releases.html) **Versiones de ejecución compatibles: versión original de App Runner** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/apprunner/latest/dg/service-source-code-nodejs-releases.html) # Uso de la plataforma Java La plataforma AWS App Runner Java proporciona tiempos de ejecución gestionados. Cada tiempo de ejecución facilita la creación y ejecución de contenedores con aplicaciones web basadas en una versión de Java. Cuando usas un entorno de ejecución de Java, App Runner comienza con una imagen de tiempo de ejecución de Java gestionada. Esta imagen se basa en la [imagen de Docker de Amazon Linux](https://hub.docker.com/_/amazonlinux) y contiene el paquete de tiempo de ejecución de una versión de Java y algunas herramientas. App Runner usa esta imagen de tiempo de ejecución administrada como imagen base y agrega el código de la aplicación para crear una imagen de Docker. A continuación, implementa esta imagen para ejecutar el servicio web en un contenedor. Usted especifica un tiempo de ejecución para su servicio de App Runner al [crear un servicio](manage-create.md) mediante la consola de App Runner o la operación de la [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)API. También puedes especificar un tiempo de ejecución como parte de tu código fuente. Usa la `runtime` palabra clave en un [archivo de configuración de App Runner](config-file.md) que incluyas en tu repositorio de código. La convención de nomenclatura de un tiempo de ejecución gestionado es*

*. En este momento, todos los tiempos de ejecución de Java compatibles se basan en Amazon Corretto. Para ver los nombres y las versiones de los tiempos de ejecución de Java válidos, consulte. [Información sobre la versión de Java Runtime](service-source-code-java-releases.md) App Runner actualiza el tiempo de ejecución del servicio a la versión más reciente en cada implementación o actualización del servicio. Si su aplicación requiere una versión específica de un tiempo de ejecución administrado, puede especificarla mediante la `runtime-version` palabra clave del [archivo de configuración de App Runner](config-file.md). Puedes bloquearla en cualquier nivel de versión, incluida una versión principal o secundaria. App Runner solo realiza actualizaciones de nivel inferior en el tiempo de ejecución de tu servicio. Sintaxis de la versión para los tiempos de ejecución de Amazon Corretto: | **Tiempo de ejecución** | **Sintaxis** | **Ejemplo** | | --- | --- | --- | | corretto11 | `11.0[.openjdk-update[.openjdk-build[.corretto-specific-revision]]]` | `11.0.13.08.1` | | corretto8 | `8[.openjdk-update[.openjdk-build[.corretto-specific-revision]]]` | `8.312.07.1` | Los siguientes ejemplos muestran el bloqueo de versiones: + `11.0.13`— Bloquee la versión de actualización de Open JDK. App Runner actualiza solo las versiones de nivel inferior de Open JDK y Amazon Corretto. + `11.0.13.08.1`— Bloquear una versión específica. App Runner no actualiza tu versión en tiempo de ejecución. **Topics** + [Configuración del tiempo de ejecución de Java](#service-source-code-java.config) + [Ejemplos de entornos de ejecución de Java](#service-source-code-java.examples) + [Información sobre la versión de Java Runtime](service-source-code-java-releases.md) ## Configuración del tiempo de ejecución de Java Al elegir un tiempo de ejecución gestionado, también debe configurar, como mínimo, los comandos de compilación y ejecución. Los configuras al [crear](manage-create.md) o [actualizar](manage-configure.md) tu servicio App Runner. Puede hacerlo mediante uno de los siguientes métodos: + **Mediante la consola de App Runner**: especifique los comandos en la sección **Configurar compilación** del proceso de creación o en la pestaña de configuración. + **Uso de la API de App Runner**: llame a la operación [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)o [UpdateService](https://docs.aws.amazon.com/apprunner/latest/api/API_UpdateService.html)API. Especifique los comandos mediante los `StartCommand` miembros `BuildCommand` y del tipo de [CodeConfigurationValues](https://docs.aws.amazon.com/apprunner/latest/api/API_CodeConfigurationValues.html)datos. + **Uso de un [archivo de configuración](config-file.md)**: especifique uno o más comandos de compilación en un máximo de tres fases de compilación y un solo comando de ejecución que sirva para iniciar la aplicación. Hay opciones de configuración opcionales adicionales. Proporcionar un archivo de configuración es opcional. Al crear un servicio de App Runner mediante la consola o la API, debe especificar si App Runner obtiene los ajustes de configuración directamente al crearlos o de un archivo de configuración. ## Ejemplos de entornos de ejecución de Java Los siguientes ejemplos muestran los archivos de configuración de App Runner para crear y ejecutar un servicio Java. El último ejemplo es el código fuente de una aplicación Java completa que puede implementar en un servicio de tiempo de ejecución de Corretto 11. **nota** La versión en tiempo de ejecución que se utiliza en estos ejemplos es*11.0.13.08.1*. Puede sustituirla por la versión que desee utilizar. Para ver la última versión de ejecución de Java compatible, consulte[Información sobre la versión de Java Runtime](service-source-code-java-releases.md). ### Archivo de configuración Minimal Corretto 11 Este ejemplo muestra un archivo de configuración mínimo que puede utilizar con un entorno de ejecución gestionado por Corretto 11. Para ver las suposiciones que App Runner hace con un archivo de configuración mínimo, consulte. **Example apprunner.yaml** ``` version: 1.0 runtime: corretto11 build: commands: build: - mvn clean package run: command: java -Xms256m -jar target/MyApp-1.0-SNAPSHOT.jar . ``` ### Archivo de configuración de Corretto 11 extendido Este ejemplo muestra cómo puede utilizar todas las claves de configuración con un tiempo de ejecución gestionado por Corretto 11. **nota** La versión en tiempo de ejecución que se utiliza en estos ejemplos es*11.0.13.08.1*. Puede sustituirla por la versión que desee utilizar. Para ver la última versión de ejecución de Java compatible, consulte[Información sobre la versión de Java Runtime](service-source-code-java-releases.md). **Example apprunner.yaml** ``` version: 1.0 runtime: corretto11 build: commands: pre-build: - yum install some-package - scripts/prebuild.sh build: - mvn clean package post-build: - mvn clean test env: - name: M2 value: "/usr/local/apache-maven/bin" - name: M2_HOME value: "/usr/local/apache-maven/bin" run: runtime-version: 11.0.13.08.1 command: java -Xms256m -jar target/MyApp-1.0-SNAPSHOT.jar . network: port: 8000 env: APP_PORT env: - name: MY_VAR_EXAMPLE value: "example" ``` ### Fuente completa de la aplicación Corretto 11 Este ejemplo muestra el código fuente de una aplicación Java completa que puede implementar en un servicio de tiempo de ejecución de Corretto 11. **Example src/main/java/com/HelloWorld/HelloWorld.java** ``` package com.HelloWorld; import org.springframework.web.bind.annotation.RequestMapping; import org.springframework.web.bind.annotation.RestController; @RestController public class HelloWorld { @RequestMapping("/") public String index(){ String s = "Hello World"; return s; } } ``` **Example src/main/java/com/HelloWorld/Main.java** ``` package com.HelloWorld; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; @SpringBootApplication public class Main { public static void main(String[] args) { SpringApplication.run(Main.class, args); } } ``` **Example aprunner.yaml** ``` version: 1.0 runtime: corretto11 build: commands: build: - mvn clean package run: command: java -Xms256m -jar target/HelloWorldJavaApp-1.0-SNAPSHOT.jar . network: port: 8080 ``` **Example pom.xml** ``` 4.0.0 org.springframework.boot spring-boot-starter-parent 2.3.1.RELEASE com.HelloWorld HelloWorldJavaApp 1.0-SNAPSHOT 11 org.springframework.boot spring-boot-starter-data-rest org.springframework.boot spring-boot-starter-test test org.junit.vintage junit-vintage-engine org.springframework.boot spring-boot-maven-plugin org.apache.maven.plugins maven-compiler-plugin 3.8.0 11 ``` # Información sobre la versión de Java Runtime En este tema se enumeran todos los detalles de las versiones de ejecución de Java compatibles con App Runner. **Versiones de tiempo de ejecución compatibles: versión original de App Runner** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/apprunner/latest/dg/service-source-code-java-releases.html) **nota** App Runner proporciona un proceso de compilación revisado para los principales tiempos de ejecución específicos que se publicaron más recientemente. Por este motivo, verás referencias a la *versión revisada de App Runner y a* la versión *original de App Runner* en determinadas secciones de este documento. Para obtener más información, consulte [Versiones administradas en tiempo de ejecución y compilación de App Runner](service-source-code.md#service-source-code.build-detail). # Uso de la plataforma .NET de **importante** App Runner dejará de ser compatible con **.NET 6** el 1 de diciembre de 2025. Para obtener recomendaciones y más información, consulte[Fin del soporte para las versiones de tiempo de ejecución gestionado](service-source-code.md#service-source-code.managed-platforms.eos). La AWS App Runner plataforma.NET proporciona tiempos de ejecución gestionados. Cada tiempo de ejecución facilita la creación y ejecución de contenedores con aplicaciones web basadas en una versión.NET. Cuando usas un entorno de ejecución de.NET, App Runner comienza con una imagen de tiempo de ejecución de.NET gestionada. Esta imagen se basa en la [imagen de Docker de Amazon Linux](https://hub.docker.com/_/amazonlinux) y contiene el paquete de tiempo de ejecución de una versión de.NET y algunas herramientas y paquetes de dependencias populares. App Runner usa esta imagen de tiempo de ejecución administrado como imagen base y agrega el código de la aplicación para crear una imagen de Docker. A continuación, implementa esta imagen para ejecutar el servicio web en un contenedor. Usted especifica un tiempo de ejecución para su servicio de App Runner al [crear un servicio](manage-create.md) mediante la consola de App Runner o la operación de la [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)API. También puedes especificar un tiempo de ejecución como parte de tu código fuente. Usa la `runtime` palabra clave en un [archivo de configuración de App Runner](config-file.md) que incluyas en tu repositorio de código. La convención de nomenclatura de un tiempo de ejecución gestionado es*

*. Para obtener nombres y versiones de tiempo de ejecución de .NET válidos, consulte[Información sobre la versión de.NET Runtime](service-source-code-dotnet-releases.md). App Runner actualiza el tiempo de ejecución del servicio a la versión más reciente en cada implementación o actualización del servicio. Si su aplicación requiere una versión específica de un tiempo de ejecución administrado, puede especificarla mediante la `runtime-version` palabra clave del [archivo de configuración de App Runner](config-file.md). Puedes bloquearla en cualquier nivel de versión, incluida una versión principal o secundaria. App Runner solo realiza actualizaciones de nivel inferior en el tiempo de ejecución de tu servicio. Sintaxis de versión para los tiempos de ejecución de.NET: `major[.minor[.patch]]` Por ejemplo: `6.0.9` Los siguientes ejemplos muestran el bloqueo de versiones: + `6.0`— Bloquee las versiones principales y secundarias. App Runner actualiza solo las versiones con parches. + `6.0.9`— Bloquear una versión de parche específica. App Runner no actualiza tu versión en tiempo de ejecución. **Topics** + [Configuración de tiempo de ejecución de.NET](#service-source-code-net6.config) + [Ejemplos de tiempo de ejecución de.NET](#service-source-code-net6.examples) + [Información sobre la versión de.NET Runtime](service-source-code-dotnet-releases.md) ## Configuración de tiempo de ejecución de.NET Al elegir un tiempo de ejecución administrado, también debe configurar, como mínimo, los comandos de compilación y ejecución. Los configuras al [crear](manage-create.md) o [actualizar](manage-configure.md) tu servicio App Runner. Puede hacerlo mediante uno de los siguientes métodos: + **Mediante la consola de App Runner**: especifique los comandos en la sección **Configurar compilación** del proceso de creación o en la pestaña de configuración. + **Uso de la API de App Runner**: llame a la operación [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)o [UpdateService](https://docs.aws.amazon.com/apprunner/latest/api/API_UpdateService.html)API. Especifique los comandos mediante los `StartCommand` miembros `BuildCommand` y del tipo de [CodeConfigurationValues](https://docs.aws.amazon.com/apprunner/latest/api/API_CodeConfigurationValues.html)datos. + **Uso de un [archivo de configuración](config-file.md)**: especifique uno o más comandos de compilación en un máximo de tres fases de compilación y un solo comando de ejecución que sirva para iniciar la aplicación. Hay opciones de configuración opcionales adicionales. Proporcionar un archivo de configuración es opcional. Al crear un servicio de App Runner mediante la consola o la API, debe especificar si App Runner obtiene los ajustes de configuración directamente al crearlos o de un archivo de configuración. ## Ejemplos de tiempo de ejecución de.NET Los siguientes ejemplos muestran los archivos de configuración de App Runner para crear y ejecutar un servicio.NET. El último ejemplo es el código fuente de una aplicación.NET completa que se puede implementar en un servicio de ejecución de.NET. **nota** La versión en tiempo de ejecución que se utiliza en estos ejemplos es*6.0.9*. Puede sustituirla por la versión que desee utilizar. Para ver la última versión de tiempo de ejecución de .NET compatible, consulte[Información sobre la versión de.NET Runtime](service-source-code-dotnet-releases.md). ### Archivo de configuración de .NET mínimo En este ejemplo se muestra un archivo de configuración mínimo que se puede utilizar con un entorno de ejecución gestionado por .NET. Para ver las suposiciones que App Runner hace con un archivo de configuración mínimo, consulte[Ejemplos de archivos de configuración](config-file-examples.md#config-file-examples.managed). **Example apprunner.yaml** ``` version: 1.0 runtime: dotnet6 build: commands: build: - dotnet publish -c Release -o out run: command: dotnet out/HelloWorldDotNetApp.dll ``` ### Archivo de configuración de.NET extendido En este ejemplo se muestra el uso de todas las claves de configuración en un entorno de ejecución gestionado por .NET. **nota** La versión de tiempo de ejecución que se utiliza en estos ejemplos es*6.0.9*. Puede sustituirla por la versión que desee utilizar. Para ver la última versión de tiempo de ejecución de .NET compatible, consulte[Información sobre la versión de.NET Runtime](service-source-code-dotnet-releases.md). **Example apprunner.yaml** ``` version: 1.0 runtime: dotnet6 build: commands: pre-build: - scripts/prebuild.sh build: - dotnet publish -c Release -o out post-build: - scripts/postbuild.sh env: - name: MY_VAR_EXAMPLE value: "example" run: runtime-version: 6.0.9 command: dotnet out/HelloWorldDotNetApp.dll network: port: 5000 env: APP_PORT env: - name: ASPNETCORE_URLS value: "http://*:5000" ``` ### Fuente completa de la aplicación.NET En este ejemplo se muestra el código fuente de una aplicación.NET completa que se puede implementar en un servicio de tiempo de ejecución de.NET. **nota** Ejecute el siguiente comando para crear una aplicación web sencilla de.NET 6: ` dotnet new web --name HelloWorldDotNetApp -f net6.0` `apprunner.yaml`Añádala a la aplicación web .NET 6 creada. **Example HelloWorldDotNetApp** ``` version: 1.0 runtime: dotnet6 build: commands: build: - dotnet publish -c Release -o out run: command: dotnet out/HelloWorldDotNetApp.dll network: port: 5000 env: APP_PORT env: - name: ASPNETCORE_URLS value: "http://*:5000" ``` # Información sobre la versión de.NET Runtime **importante** App Runner dejará de ser compatible con **.NET 6** el 1 de diciembre de 2025. Para obtener recomendaciones y más información, consulte[Fin del soporte para las versiones de tiempo de ejecución gestionado](service-source-code.md#service-source-code.managed-platforms.eos). En este tema se enumeran todos los detalles de las versiones en tiempo de ejecución de.NET compatibles con App Runner. **Versiones en tiempo de ejecución compatibles: versión original de App Runner** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/apprunner/latest/dg/service-source-code-dotnet-releases.html) **nota** App Runner proporciona un proceso de compilación revisado para los principales tiempos de ejecución específicos que se publicaron más recientemente. Por este motivo, verás referencias a la *versión revisada de App Runner y a* la versión *original de App Runner* en determinadas secciones de este documento. Para obtener más información, consulte [Versiones administradas en tiempo de ejecución y compilación de App Runner](service-source-code.md#service-source-code.build-detail). # Uso de la plataforma PHP de **importante** App Runner dejará de ser compatible con **PHP 8.1** el 31 de diciembre de 2025. Para obtener recomendaciones y más información, consulte[Fin del soporte para las versiones de tiempo de ejecución gestionado](service-source-code.md#service-source-code.managed-platforms.eos). La plataforma AWS App Runner PHP proporciona tiempos de ejecución gestionados. Puede usar cada tiempo de ejecución para crear y ejecutar contenedores con aplicaciones web basadas en una versión de PHP. Cuando utilizas un entorno de ejecución de PHP, App Runner comienza con una imagen de tiempo de ejecución de PHP gestionada. Esta imagen se basa en la [imagen de Docker de Amazon Linux](https://hub.docker.com/_/amazonlinux) y contiene el paquete de tiempo de ejecución de una versión de PHP y algunas herramientas. App Runner usa esta imagen de tiempo de ejecución administrada como imagen base y agrega el código de la aplicación para crear una imagen de Docker. A continuación, implementa esta imagen para ejecutar el servicio web en un contenedor. Usted especifica un tiempo de ejecución para su servicio de App Runner al [crear un servicio](manage-create.md) mediante la consola de App Runner o la operación de la [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)API. También puedes especificar un tiempo de ejecución como parte de tu código fuente. Usa la `runtime` palabra clave en un [archivo de configuración de App Runner](config-file.md) que incluyas en tu repositorio de código. La convención de nomenclatura de un tiempo de ejecución gestionado es*

*. Para obtener nombres y versiones de tiempo de ejecución de PHP válidos, consulte[Información sobre la versión de PHP Runtime](service-source-code-php-releases.md). App Runner actualiza el tiempo de ejecución del servicio a la versión más reciente en cada implementación o actualización del servicio. Si su aplicación requiere una versión específica de un tiempo de ejecución administrado, puede especificarla mediante la `runtime-version` palabra clave del [archivo de configuración de App Runner](config-file.md). Puedes bloquearla en cualquier nivel de versión, incluida una versión principal o secundaria. App Runner solo realiza actualizaciones de nivel inferior en el tiempo de ejecución del servicio. Sintaxis de la versión para los tiempos de ejecución de PHP: `major[.minor[.patch]]` Por ejemplo: `8.1.10` Los siguientes son ejemplos de bloqueo de versiones: + `8.1`— Bloquee las versiones principales y secundarias. App Runner actualiza solo las versiones con parches. + `8.1.10`— Bloquear una versión de parche específica. App Runner no actualiza tu versión de ejecución. **importante** Si quieres especificar el [directorio fuente](service-source-code.md#service-source-code.source-directory) del repositorio de código para tu servicio de App Runner en una ubicación distinta del directorio raíz del repositorio predeterminado, la versión de ejecución gestionada por PHP debe ser PHP `8.1.22` o posterior. Las versiones de tiempo de ejecución de PHP anteriores a solo `8.1.22` pueden usar el directorio fuente raíz predeterminado. **Topics** + [Configuración del tiempo de ejecución de PHP](#service-source-code-php.config) + [Compatibilidad](#service-source-code-php.compatibility) + [Ejemplos de tiempos de ejecución de PHP](#service-source-code-php.examples) + [Información sobre la versión de PHP Runtime](service-source-code-php-releases.md) ## Configuración del tiempo de ejecución de PHP Al elegir un tiempo de ejecución gestionado, también debe configurar, como mínimo, los comandos de compilación y ejecución. Los configuras al [crear](manage-create.md) o [actualizar](manage-configure.md) tu servicio App Runner. Puede hacerlo mediante uno de los siguientes métodos: + **Mediante la consola de App Runner**: especifique los comandos en la sección **Configurar compilación** del proceso de creación o en la pestaña de configuración. + **Uso de la API de App Runner**: llame a la operación [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)o [UpdateService](https://docs.aws.amazon.com/apprunner/latest/api/API_UpdateService.html)API. Especifique los comandos mediante los `StartCommand` miembros `BuildCommand` y del tipo de [CodeConfigurationValues](https://docs.aws.amazon.com/apprunner/latest/api/API_CodeConfigurationValues.html)datos. + **Uso de un [archivo de configuración](config-file.md)**: especifique uno o más comandos de compilación en un máximo de tres fases de compilación y un solo comando de ejecución que sirva para iniciar la aplicación. Hay opciones de configuración opcionales adicionales. Proporcionar un archivo de configuración es opcional. Al crear un servicio de App Runner mediante la consola o la API, debe especificar si App Runner obtiene los ajustes de configuración directamente al crearlos o de un archivo de configuración. ## Compatibilidad Puedes ejecutar tus servicios de App Runner en la plataforma PHP mediante uno de los siguientes servidores web: + Apache HTTP Server + NGINX Apache HTTP Servery NGINX son compatibles con PHP-FPM. Puede iniciar *Apache HTTP Server*y *NGINX*mediante una de las siguientes opciones: + [Supervisord](http://supervisord.org/introduction.html#supervisor-components/): para obtener más información sobre la ejecución de un *supervisord*, consulte [Ejecutar](http://supervisord.org/running.html#running-supervisord) supervisord. + Script de inicio Para ver ejemplos sobre cómo configurar el servicio App Runner con la plataforma PHP mediante el *servidor HTTP Apache* o *NGINX, consulte*. [Fuente completa de la aplicación PHP](#service-source-code-php.examples.end2end) ### Estructura de archivos `index.php`Debe estar instalado en la `public` carpeta del `root` directorio del servidor web. **nota** Se recomienda almacenar los `supervisord.conf` archivos `startup.sh` o en el directorio raíz del servidor web. Asegúrese de que el `start` comando apunte a la ubicación en la que están almacenados `supervisord.conf` los archivos `startup.sh` o. A continuación se muestra un ejemplo de la estructura de archivos que está utilizando *supervisord*. ``` / ├─ public/ │ ├─ index.php ├─ apprunner.yaml ├─ supervisord.conf ``` El siguiente es un ejemplo de la estructura de archivos si utiliza un *script de inicio*. ``` / ├─ public/ │ ├─ index.php ├─ apprunner.yaml ├─ startup.sh ``` Se recomienda almacenar estas estructuras de archivos en el [directorio fuente](service-source-code.md#service-source-code.source-directory) del repositorio de código designado para el servicio App Runner. ``` // ├─ public/ │ ├─ index.php ├─ apprunner.yaml ├─ startup.sh ``` **importante** Si quieres especificar el [directorio fuente](service-source-code.md#service-source-code.source-directory) del repositorio de código para tu servicio de App Runner en una ubicación que no sea el directorio raíz del repositorio predeterminado, tu versión de tiempo de ejecución gestionado por PHP debe ser PHP `8.1.22` o posterior. Las versiones de tiempo de ejecución de PHP anteriores a solo `8.1.22` pueden usar el directorio fuente raíz predeterminado. App Runner actualiza el tiempo de ejecución de tu servicio a la última versión en cada implementación o actualización del servicio. Su servicio utilizará los tiempos de ejecución más recientes de forma predeterminada, a menos que haya especificado el bloqueo de versiones con la `runtime-version` palabra clave del [archivo de configuración de App Runner](config-file.md). ## Ejemplos de tiempos de ejecución de PHP Los siguientes son ejemplos de archivos de configuración de App Runner que se utilizan para crear y ejecutar un servicio PHP. ### Archivo de configuración PHP mínimo El siguiente ejemplo es un archivo de configuración mínimo que puede utilizar con un entorno de ejecución gestionado por PHP. Para obtener más información sobre un archivo de configuración mínima, consulte[Ejemplos de archivos de configuración](config-file-examples.md#config-file-examples.managed). **Example apprunner.yaml** ``` version: 1.0 runtime: php81 build: commands: build: - echo example build command for PHP run: command: ./startup.sh ``` ### Archivo de configuración PHP extendido El siguiente ejemplo utiliza todas las claves de configuración con un tiempo de ejecución gestionado por PHP. **nota** La versión en tiempo de ejecución que se utiliza en estos ejemplos es*8.1.10*. Puede sustituirla por la versión que desee utilizar. Para ver la última versión de ejecución de PHP compatible, consulte[Información sobre la versión de PHP Runtime](service-source-code-php-releases.md). **Example apprunner.yaml** ``` version: 1.0 runtime: php81 build: commands: pre-build: - scripts/prebuild.sh build: - echo example build command for PHP post-build: - scripts/postbuild.sh env: - name: MY_VAR_EXAMPLE value: "example" run: runtime-version: 8.1.10 command: ./startup.sh network: port: 5000 env: APP_PORT env: - name: MY_VAR_EXAMPLE value: "example" ``` ### Fuente completa de la aplicación PHP Los siguientes ejemplos son del código fuente de una aplicación PHP que puede usar para implementar en un servicio de tiempo de ejecución de PHP usando *Apache HTTP Server*o *NGINX*. En estos ejemplos se supone que se utiliza la estructura de archivos predeterminada. #### Ejecutar la plataforma PHP con Apache HTTP Server el uso supervisord **Example Estructura de archivos** + El `supervisord.conf` archivo se puede almacenar en cualquier parte del repositorio. Asegúrese de que el `start` comando apunta al lugar donde está almacenado el `supervisord.conf` archivo. + `index.php`Debe estar instalado en la `public` carpeta situada debajo del `root` directorio. ``` / ├─ public/ │ ├─ index.php ├─ apprunner.yaml ├─ supervisord.conf ``` **Example supervisord.conf** ``` [supervisord] nodaemon=true [program:httpd] command=httpd -DFOREGROUND autostart=true autorestart=true stdout_logfile=/dev/stdout stdout_logfile_maxbytes=0 stderr_logfile=/dev/stderr stderr_logfile_maxbytes=0 [program:php-fpm] command=php-fpm -F autostart=true autorestart=true stdout_logfile=/dev/stdout stdout_logfile_maxbytes=0 stderr_logfile=/dev/stderr stderr_logfile_maxbytes=0 ``` **Example apprunner.yaml** ``` version: 1.0 runtime: php81 build: commands: build: - PYTHON=python2 amazon-linux-extras install epel - yum -y install supervisor run: command: supervisord network: port: 8080 env: APP_PORT ``` **Example index.php** ``` First PHP App "); ?> ``` #### Ejecutar la plataforma PHP con Apache HTTP Server el uso startup script **Example Estructura de archivos** + El `startup.sh` archivo se puede almacenar en cualquier parte del repositorio. Asegúrese de que el `start` comando apunta al lugar donde está almacenado el `startup.sh` archivo. + `index.php`Debe estar instalado en la `public` carpeta situada debajo del `root` directorio. ``` / ├─ public/ │ ├─ index.php ├─ apprunner.yaml ├─ startup.sh ``` **Example startup.sh** ``` #!/bin/bash set -o monitor trap exit SIGCHLD # Start apache httpd -DFOREGROUND & # Start php-fpm php-fpm -F & wait ``` **nota** Asegúrate de guardar el `startup.sh` archivo como ejecutable antes de enviarlo a un repositorio de Git. Se usa `chmod +x startup.sh` para establecer el permiso de ejecución en `startup.sh` el archivo. Si no guarda el `startup.sh` archivo como ejecutable, `chmod +x startup.sh` introdúzcalo como `build` comando en el `apprunner.yaml` archivo. **Example apprunner.yaml** ``` version: 1.0 runtime: php81 build: commands: build: - echo example build command for PHP run: command: ./startup.sh network: port: 8080 env: APP_PORT ``` **Example index.php** ``` First PHP App "); ?> ``` #### Ejecutar la plataforma PHP con NGINX el uso supervisord **Example Estructura de archivos** + El `supervisord.conf` archivo se puede almacenar en cualquier parte del repositorio. Asegúrese de que el `start` comando apunta al lugar donde está almacenado el `supervisord.conf` archivo. + `index.php`Debe estar instalado en la `public` carpeta situada debajo del `root` directorio. ``` / ├─ public/ │ ├─ index.php ├─ apprunner.yaml ├─ supervisord.conf ``` **Example supervisord.conf** ``` [supervisord] nodaemon=true [program:nginx] command=nginx -g "daemon off;" autostart=true autorestart=true stdout_logfile=/dev/stdout stdout_logfile_maxbytes=0 stderr_logfile=/dev/stderr stderr_logfile_maxbytes=0 [program:php-fpm] command=php-fpm -F autostart=true autorestart=true stdout_logfile=/dev/stdout stdout_logfile_maxbytes=0 stderr_logfile=/dev/stderr stderr_logfile_maxbytes=0 ``` **Example apprunner.yaml** ``` version: 1.0 runtime: php81 build: commands: build: - PYTHON=python2 amazon-linux-extras install epel - yum -y install supervisor run: command: supervisord network: port: 8080 env: APP_PORT ``` **Example index.php** ``` First PHP App "); ?> ``` #### Ejecutar la plataforma PHP con NGINX el uso startup script **Example Estructura de archivos** + El `startup.sh` archivo se puede almacenar en cualquier parte del repositorio. Asegúrese de que el `start` comando apunta al lugar donde está almacenado el `startup.sh` archivo. + `index.php`Debe estar instalado en la `public` carpeta situada debajo del `root` directorio. ``` / ├─ public/ │ ├─ index.php ├─ apprunner.yaml ├─ startup.sh ``` **Example startup.sh** ``` #!/bin/bash set -o monitor trap exit SIGCHLD # Start nginx nginx -g 'daemon off;' & # Start php-fpm php-fpm -F & wait ``` **nota** Asegúrate de guardar el `startup.sh` archivo como ejecutable antes de enviarlo a un repositorio de Git. Se usa `chmod +x startup.sh` para establecer el permiso de ejecución en `startup.sh` el archivo. Si no guarda el `startup.sh` archivo como ejecutable, `chmod +x startup.sh` introdúzcalo como `build` comando en el `apprunner.yaml` archivo. **Example apprunner.yaml** ``` version: 1.0 runtime: php81 build: commands: build: - echo example build command for PHP run: command: ./startup.sh network: port: 8080 env: APP_PORT ``` **Example index.php** ``` First PHP App "); ?> ``` # Información sobre la versión de PHP Runtime **importante** App Runner dejará de ser compatible con **PHP 8.1** el 31 de diciembre de 2025. Para obtener recomendaciones y más información, consulte[Fin del soporte para las versiones de tiempo de ejecución gestionado](service-source-code.md#service-source-code.managed-platforms.eos). En este tema se enumeran todos los detalles de las versiones de PHP en tiempo de ejecución compatibles con App Runner. **Versiones de tiempo de ejecución compatibles: versión original de App Runner** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/apprunner/latest/dg/service-source-code-php-releases.html) **nota** App Runner proporciona un proceso de compilación revisado para los principales tiempos de ejecución específicos que se publicaron más recientemente. Por este motivo, verás referencias a la *versión revisada de App Runner y a* la versión *original de App Runner* en determinadas secciones de este documento. Para obtener más información, consulte [Versiones administradas en tiempo de ejecución y compilación de App Runner](service-source-code.md#service-source-code.build-detail). # Uso de la plataforma Ruby de **importante** App Runner dejará de ser compatible con **Ruby 3.1** el 1 de diciembre de 2025. Para obtener recomendaciones y más información, consulte[Fin del soporte para las versiones de tiempo de ejecución gestionado](service-source-code.md#service-source-code.managed-platforms.eos). La plataforma AWS App Runner Ruby proporciona tiempos de ejecución gestionados. Cada tiempo de ejecución facilita la creación y ejecución de contenedores con aplicaciones web basadas en una versión de Ruby. Cuando usas un entorno de ejecución de Ruby, App Runner comienza con una imagen de tiempo de ejecución de Ruby gestionada. Esta imagen se basa en la [imagen de Docker de Amazon Linux](https://hub.docker.com/_/amazonlinux) y contiene el paquete de tiempo de ejecución de una versión de Ruby y algunas herramientas. App Runner usa esta imagen de tiempo de ejecución administrada como imagen base y agrega el código de la aplicación para crear una imagen de Docker. A continuación, implementa esta imagen para ejecutar el servicio web en un contenedor. Usted especifica un tiempo de ejecución para su servicio de App Runner al [crear un servicio](manage-create.md) mediante la consola de App Runner o la operación de la [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)API. También puedes especificar un tiempo de ejecución como parte de tu código fuente. Usa la `runtime` palabra clave en un [archivo de configuración de App Runner](config-file.md) que incluyas en tu repositorio de código. La convención de nomenclatura de un tiempo de ejecución gestionado es*

*. Para ver los nombres y las versiones de los tiempos de ejecución de Ruby válidos, consulte[Información sobre la versión de Ruby Runtime](service-source-code-ruby-releases.md). App Runner actualiza el tiempo de ejecución del servicio a la versión más reciente en cada implementación o actualización del servicio. Si su aplicación requiere una versión específica de un tiempo de ejecución administrado, puede especificarla mediante la `runtime-version` palabra clave del [archivo de configuración de App Runner](config-file.md). Puedes bloquearla en cualquier nivel de versión, incluida una versión principal o secundaria. App Runner solo realiza actualizaciones de nivel inferior en el tiempo de ejecución de tu servicio. Sintaxis de la versión para los tiempos de ejecución de Ruby: `major[.minor[.patch]]` Por ejemplo: `3.1.2` Los siguientes ejemplos muestran el bloqueo de versiones: + `3.1`— Bloquee las versiones principales y secundarias. App Runner actualiza solo las versiones con parches. + `3.1.2`— Bloquear una versión de parche específica. App Runner no actualiza tu versión en tiempo de ejecución. **Topics** + [Configuración del tiempo de ejecución de Ru](#service-source-code-ruby.config) + [Ejemplos de ejecución de Ruby](#service-source-code-ruby.examples) + [Información sobre la versión de Ruby Runtime](service-source-code-ruby-releases.md) ## Configuración del tiempo de ejecución de Ru Al elegir un tiempo de ejecución administrado, también debe configurar, como mínimo, los comandos de compilación y ejecución. Los configuras al [crear](manage-create.md) o [actualizar](manage-configure.md) tu servicio App Runner. Puede hacerlo mediante uno de los siguientes métodos: + **Mediante la consola de App Runner**: especifique los comandos en la sección **Configurar compilación** del proceso de creación o en la pestaña de configuración. + **Uso de la API de App Runner**: llame a la operación [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)o [UpdateService](https://docs.aws.amazon.com/apprunner/latest/api/API_UpdateService.html)API. Especifique los comandos mediante los `StartCommand` miembros `BuildCommand` y del tipo de [CodeConfigurationValues](https://docs.aws.amazon.com/apprunner/latest/api/API_CodeConfigurationValues.html)datos. + **Uso de un [archivo de configuración](config-file.md)**: especifique uno o más comandos de compilación en un máximo de tres fases de compilación y un solo comando de ejecución que sirva para iniciar la aplicación. Hay opciones de configuración opcionales adicionales. Proporcionar un archivo de configuración es opcional. Al crear un servicio de App Runner mediante la consola o la API, debe especificar si App Runner obtiene los ajustes de configuración directamente al crearlos o de un archivo de configuración. ## Ejemplos de ejecución de Ruby Los siguientes ejemplos muestran los archivos de configuración de App Runner para crear y ejecutar un servicio de Ruby. ### Archivo de configuración mínimo de Ruby En este ejemplo, se muestra un archivo de configuración mínimo que puede utilizar con un entorno de ejecución gestionado por Ruby. Para ver las suposiciones que App Runner hace con un archivo de configuración mínimo, consulte[Ejemplos de archivos de configuración](config-file-examples.md#config-file-examples.managed). **Example apprunner.yaml** ``` version: 1.0 runtime: ruby31 build: commands: build: - bundle install run: command: bundle exec rackup --host 0.0.0.0 -p 8080 ``` ### Archivo de configuración de Ruby extendido Este ejemplo muestra el uso de todas las claves de configuración con un entorno de ejecución gestionado por Ruby. **nota** La versión de tiempo de ejecución que se utiliza en estos ejemplos es*3.1.2*. Puede sustituirla por la versión que desee utilizar. Para ver la última versión de tiempo de ejecución de Ruby compatible, consulte[Información sobre la versión de Ruby Runtime](service-source-code-ruby-releases.md). **Example apprunner.yaml** ``` version: 1.0 runtime: ruby31 build: commands: pre-build: - scripts/prebuild.sh build: - bundle install post-build: - scripts/postbuild.sh env: - name: MY_VAR_EXAMPLE value: "example" run: runtime-version: 3.1.2 command: bundle exec rackup --host 0.0.0.0 -p 4567 network: port: 4567 env: APP_PORT env: - name: MY_VAR_EXAMPLE value: "example" ``` ### Fuente completa de la aplicación Ruby Estos ejemplos muestran el código fuente de una aplicación de Ruby completa que se puede implementar en un servicio de tiempo de ejecución de Ruby. **Example servidor.rb** ``` # server.rb require 'sinatra' get '/' do 'Hello World!' end ``` **Example config.ru** ``` # config.ru require './server' run Sinatra::Application ``` **Example Archivo Gemfile** ``` # Gemfile source 'https://rubygems.org (https://rubygems.org/)' gem 'sinatra' gem 'puma' ``` **Example apprunner.yaml** ``` version: 1.0 runtime: ruby31 build: commands: build: - bundle install run: command: bundle exec rackup --host 0.0.0.0 -p 4567 network: port: 4567 env: APP_PORT ``` # Información sobre la versión de Ruby Runtime **importante** App Runner dejará de ser compatible con **Ruby 3.1** el 1 de diciembre de 2025. Para obtener recomendaciones y más información, consulte[Fin del soporte para las versiones de tiempo de ejecución gestionado](service-source-code.md#service-source-code.managed-platforms.eos). En este tema se enumeran todos los detalles de las versiones de Ruby en tiempo de ejecución compatibles con App Runner. **Versiones de tiempo de ejecución compatibles: versión original de App Runner** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/apprunner/latest/dg/service-source-code-ruby-releases.html) **nota** App Runner proporciona un proceso de compilación revisado para los principales tiempos de ejecución específicos que se publicaron más recientemente. Por este motivo, verás referencias a la *versión revisada de App Runner y a* la versión *original de App Runner* en determinadas secciones de este documento. Para obtener más información, consulte [Versiones administradas en tiempo de ejecución y compilación de App Runner](service-source-code.md#service-source-code.build-detail). # Uso de la plataforma Go de **importante** App Runner dejará de ser compatible con **Go 1.18** el 1 de diciembre de 2025. Para obtener recomendaciones y más información, consulte[Fin del soporte para las versiones de tiempo de ejecución gestionado](service-source-code.md#service-source-code.managed-platforms.eos). La plataforma AWS App Runner Go proporciona tiempos de ejecución gestionados. Cada tiempo de ejecución facilita la creación y ejecución de contenedores con aplicaciones web basadas en una versión de Go. Cuando utilizas un motor de ejecución de Go, App Runner comienza con una imagen de tiempo de ejecución de Go gestionada. Esta imagen se basa en la [imagen de Docker de Amazon Linux](https://hub.docker.com/_/amazonlinux) y contiene el paquete de tiempo de ejecución de una versión de Go y algunas herramientas. App Runner usa esta imagen de tiempo de ejecución administrada como imagen base y agrega el código de la aplicación para crear una imagen de Docker. A continuación, implementa esta imagen para ejecutar el servicio web en un contenedor. Usted especifica un tiempo de ejecución para su servicio de App Runner al [crear un servicio](manage-create.md) mediante la consola de App Runner o la operación de la [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)API. También puedes especificar un tiempo de ejecución como parte de tu código fuente. Usa la `runtime` palabra clave en un [archivo de configuración de App Runner](config-file.md) que incluyas en tu repositorio de código. La convención de nomenclatura de un tiempo de ejecución gestionado es*

*. Para ver los nombres y las versiones de los tiempos de ejecución de Go válidos, consulte[Información sobre la versión de Go Runtime](service-source-code-go-releases.md). App Runner actualiza el tiempo de ejecución del servicio a la versión más reciente en cada implementación o actualización del servicio. Si su aplicación requiere una versión específica de un tiempo de ejecución administrado, puede especificarla mediante la `runtime-version` palabra clave del [archivo de configuración de App Runner](config-file.md). Puedes bloquearla en cualquier nivel de versión, incluida una versión principal o secundaria. App Runner solo realiza actualizaciones de nivel inferior en el tiempo de ejecución de tu servicio. Sintaxis de versión para los tiempos de ejecución de Go: `major[.minor[.patch]]` Por ejemplo: `1.18.7` Los siguientes ejemplos muestran el bloqueo de versiones: + `1.18`— Bloquee las versiones principales y secundarias. App Runner actualiza solo las versiones con parches. + `1.18.7`— Bloquear una versión de parche específica. App Runner no actualiza tu versión de ejecución. **Topics** + [Configuración de tiempo de ejecución de Go](#service-source-code-go1.config) + [Ejemplos de tiempo de ejecución de Go](#service-source-code-go1.examples) + [Información sobre la versión de Go Runtime](service-source-code-go-releases.md) ## Configuración de tiempo de ejecución de Go Al elegir un tiempo de ejecución gestionado, también debe configurar, como mínimo, los comandos de compilación y ejecución. Los configuras al [crear](manage-create.md) o [actualizar](manage-configure.md) tu servicio App Runner. Puede hacerlo mediante uno de los siguientes métodos: + **Mediante la consola de App Runner**: especifique los comandos en la sección **Configurar compilación** del proceso de creación o en la pestaña de configuración. + **Uso de la API de App Runner**: llame a la operación [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)o [UpdateService](https://docs.aws.amazon.com/apprunner/latest/api/API_UpdateService.html)API. Especifique los comandos mediante los `StartCommand` miembros `BuildCommand` y del tipo de [CodeConfigurationValues](https://docs.aws.amazon.com/apprunner/latest/api/API_CodeConfigurationValues.html)datos. + **Uso de un [archivo de configuración](config-file.md)**: especifique uno o más comandos de compilación en un máximo de tres fases de compilación y un solo comando de ejecución que sirva para iniciar la aplicación. Hay opciones de configuración opcionales adicionales. Proporcionar un archivo de configuración es opcional. Al crear un servicio de App Runner mediante la consola o la API, debe especificar si App Runner obtiene los ajustes de configuración directamente al crearlos o de un archivo de configuración. ## Ejemplos de tiempo de ejecución de Go Los siguientes ejemplos muestran los archivos de configuración de App Runner para crear y ejecutar un servicio Go. ### Archivo de configuración mínimo de Go En este ejemplo, se muestra un archivo de configuración mínimo que puede utilizar con un entorno de ejecución gestionado por Go. Para ver las suposiciones que App Runner hace con un archivo de configuración mínimo, consulte[Ejemplos de archivos de configuración](config-file-examples.md#config-file-examples.managed). **Example apprunner.yaml** ``` version: 1.0 runtime: go1 build: commands: build: - go build main.go run: command: ./main ``` ### Archivo de configuración Go extendido En este ejemplo, se muestra el uso de todas las claves de configuración con un entorno de ejecución gestionado por Go. **nota** La versión en tiempo de ejecución que se utiliza en estos ejemplos es*1.18.7*. Puede sustituirla por la versión que desee utilizar. Para ver la última versión de tiempo de ejecución de Go compatible, consulte[Información sobre la versión de Go Runtime](service-source-code-go-releases.md). **Example apprunner.yaml** ``` version: 1.0 runtime: go1 build: commands: pre-build: - scripts/prebuild.sh build: - go build main.go post-build: - scripts/postbuild.sh env: - name: MY_VAR_EXAMPLE value: "example" run: runtime-version: 1.18.7 command: ./main network: port: 3000 env: APP_PORT env: - name: MY_VAR_EXAMPLE value: "example" ``` ### Fuente completa de la aplicación Go En estos ejemplos se muestra el código fuente de una aplicación Go completa que se puede implementar en un servicio de tiempo de ejecución de Go. **Example main.go** ``` package main import ( "fmt" "net/http" ) func main() { http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) { fmt.Fprint(w, "

Welcome to App Runner

") }) fmt.Println("Starting the server on :3000...") http.ListenAndServe(":3000", nil) } ``` **Example apprunner.yaml** ``` version: 1.0 runtime: go1 build: commands: build: - go build main.go run: command: ./main network: port: 3000 env: APP_PORT ``` # Información sobre la versión de Go Runtime **importante** App Runner dejará de ser compatible con **Go 1.18** el 1 de diciembre de 2025. Para obtener recomendaciones y más información, consulte[Fin del soporte para las versiones de tiempo de ejecución gestionado](service-source-code.md#service-source-code.managed-platforms.eos). En este tema se enumeran todos los detalles de las versiones de tiempo de ejecución de Go compatibles con App Runner. **Versiones de tiempo de ejecución compatibles: versión original de App Runner** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/apprunner/latest/dg/service-source-code-go-releases.html) **nota** App Runner proporciona un proceso de compilación revisado para los principales tiempos de ejecución específicos que se publicaron más recientemente. Por este motivo, verás referencias a la *versión revisada de App Runner y a* la versión *original de App Runner* en determinadas secciones de este documento. Para obtener más información, consulte [Versiones administradas en tiempo de ejecución y compilación de App Runner](service-source-code.md#service-source-code.build-detail).