AWS App Runner non sarà più aperto a nuovi clienti a partire dal 30 aprile 2026. Se desideri utilizzare App Runner, registrati prima di tale data. I clienti esistenti possono continuare a utilizzare il servizio normalmente. Per ulteriori informazioni, consulta [AWS App Runner la pagina Modifica della disponibilità](https://docs.aws.amazon.com/apprunner/latest/dg/apprunner-availability-change.html).
Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Servizio App Runner basato su codice sorgente
*Puoi utilizzarli AWS App Runner per creare e gestire servizi basati su due tipi di fonti di servizio fondamentalmente diversi: codice sorgente e immagine *sorgente*.* Indipendentemente dal tipo di sorgente, App Runner si occupa dell'avvio, dell'esecuzione, della scalabilità e del bilanciamento del carico del servizio. Puoi utilizzare la CI/CD funzionalità di App Runner per tenere traccia delle modifiche all'immagine o al codice sorgente. Quando App Runner rileva una modifica, crea automaticamente (per il codice sorgente) e distribuisce la nuova versione nel servizio App Runner.
Questo capitolo descrive i servizi basati sul codice sorgente. Per informazioni sui servizi basati su un'immagine sorgente, vedere[Servizio App Runner basato su un'immagine sorgente](service-source-image.md).
Il codice sorgente è il codice applicativo che App Runner crea e distribuisce per te. Indirizzi App Runner a una [directory sorgente](#service-source-code.source-directory) in un repository di codice e scegli un *runtime* adatto che corrisponda a una versione della piattaforma di programmazione. App Runner crea un'immagine basata sull'immagine di base del runtime e del codice dell'applicazione. Quindi avvia un servizio che esegue un contenitore basato su questa immagine.
*App Runner offre comodi runtime gestiti specifici della piattaforma.* Ciascuno di questi runtime crea un'immagine del contenitore a partire dal codice sorgente e aggiunge dipendenze di runtime del linguaggio all'immagine. Non è necessario fornire istruzioni di configurazione del contenitore e di compilazione come un Dockerfile.
I sottoargomenti di questo capitolo illustrano le varie piattaforme supportate da App Runner, *piattaforme gestite* che forniscono runtime gestiti per diversi ambienti e versioni di programmazione.
**Topics**
+ [Fornitori di repository di codice sorgente](#service-source-code.providers)
+ [Directory dei sorgenti](#service-source-code.source-directory)
+ [Piattaforme gestite da App Runner](#service-source-code.managed-platforms)
+ [Fine del supporto per le versioni di runtime gestite](#service-source-code.managed-platforms.eos)
+ [Versioni di runtime gestite e build di App Runner](#service-source-code.build-detail)
+ [Utilizzo della piattaforma Python di](service-source-code-python.md)
+ [Utilizzo della piattaforma Node.js di](service-source-code-nodejs.md)
+ [Utilizzo della piattaforma Java](service-source-code-java.md)
+ [Utilizzo della piattaforma .NET di](service-source-code-net6.md)
+ [Utilizzo della piattaforma PHP di](service-source-code-php.md)
+ [Utilizzo della piattaforma Ruby di](service-source-code-ruby.md)
+ [Utilizzo della piattaforma Go di](service-source-code-go1.md)
## Fornitori di repository di codice sorgente
App Runner distribuisce il codice sorgente leggendolo da un repository di codice sorgente. [App Runner supporta due provider di repository di codice sorgente: e Bitbucket. [GitHub](https://github.com/)](https://bitbucket.org/)
### Distribuzione dal tuo provider di repository di codice sorgente
Per distribuire il codice sorgente su un servizio App Runner da un repository di codice sorgente, App Runner stabilisce una connessione ad esso. Quando si utilizza la console App Runner per [creare un servizio](manage-create.md), si forniscono i dettagli di connessione e una directory sorgente per App Runner per distribuire il codice sorgente.
**Connessioni**
I dettagli di connessione vengono forniti come parte della procedura di creazione del servizio. Quando si utilizza l'API App Runner o AWS CLI, una connessione è una risorsa separata. Innanzitutto, crei la connessione utilizzando l'azione [CreateConnection](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateConnection.html)API. Quindi, fornisci l'ARN della connessione durante la creazione del servizio utilizzando l'azione [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)API.
**Directory di origine**
Quando si crea un servizio, si fornisce anche una directory dei sorgenti. Per impostazione predefinita, App Runner utilizza la directory principale del repository come directory di origine. La directory dei sorgenti è la posizione nel repository del codice sorgente che memorizza il codice sorgente e i file di configurazione dell'applicazione. I comandi build e start vengono eseguiti anche dalla directory dei sorgenti. Quando utilizzi l'API App Runner o AWS CLI per creare o aggiornare un servizio, fornisci la directory di origine nelle azioni [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)e [UpdateService](https://docs.aws.amazon.com/apprunner/latest/api/API_UpdateService.html)API. Per ulteriori informazioni, consultare la sezione seguente [Directory dei sorgenti](#service-source-code.source-directory).
Per ulteriori informazioni sulla creazione del servizio App Runner, consulta. [Creazione di un servizio App Runner](manage-create.md) Per ulteriori informazioni sulle connessioni App Runner, vedere. [Gestione delle connessioni App Runner](manage-connections.md)
## Directory dei sorgenti
Quando crei un servizio App Runner puoi fornire la directory dei sorgenti, insieme al repository e al ramo. Imposta il valore del campo **Directory di origine sul percorso della directory** del repository che memorizza il codice sorgente e i file di configurazione dell'applicazione. App Runner esegue i comandi di build e start dal percorso della directory di origine fornito dall'utente.
Immettete il valore assoluto per il percorso della directory di origine dalla directory principale del repository. Se non specificate un valore, il valore predefinito è la directory di primo livello del repository, nota anche come directory principale del repository.
È inoltre possibile fornire diversi percorsi di directory di origine oltre alla directory del repository di primo livello. Ciò supporta un'architettura di repository monorepo, il che significa che il codice sorgente per più applicazioni è archiviato in un unico repository. Per creare e supportare più servizi App Runner da un singolo monorepo, specifica diverse directory di origine quando crei ciascun servizio.
**Nota**
Se si specifica la stessa directory di origine per più servizi App Runner, entrambi i servizi verranno distribuiti e funzioneranno singolarmente.
Se scegli di utilizzare un file di `apprunner.yaml` configurazione per definire i parametri del servizio, inseriscilo nella cartella della directory di origine del repository.
Se l'opzione **Deployment trigger** è impostata su **Automatico**, le modifiche effettuate nella directory di origine attiveranno una distribuzione automatica. * Solo le modifiche nel percorso della directory di origine* attiveranno una distribuzione automatica. È importante capire in che modo la posizione della directory di origine influisce sull'ambito di una distribuzione automatica. Per ulteriori informazioni, consulta le *distribuzioni automatizzate in*. [Metodi di distribuzione](manage-deploy.md#manage-deploy.methods)
**Nota**
Se il servizio App Runner utilizza i runtime gestiti da PHP e desideri designare una directory di origine diversa dall'archivio principale predefinito, è importante utilizzare la versione di runtime PHP corretta. Per ulteriori informazioni, consulta [Utilizzo della piattaforma PHP di](service-source-code-php.md).
## Piattaforme gestite da App Runner
Le piattaforme gestite di App Runner forniscono runtime gestiti per vari ambienti di programmazione. Ogni runtime gestito semplifica la creazione e l'esecuzione di contenitori basati su una versione di un linguaggio di programmazione o di un ambiente di runtime. Quando si utilizza un runtime gestito, App Runner inizia con un'immagine di runtime gestita. Questa immagine è basata sull'[immagine Docker di Amazon Linux](https://hub.docker.com/_/amazonlinux) e contiene un pacchetto Language Runtime oltre ad alcuni strumenti e pacchetti di dipendenze popolari. App Runner utilizza questa immagine di runtime gestita come immagine di base e aggiunge il codice dell'applicazione per creare un'immagine Docker. Quindi distribuisce questa immagine per eseguire il servizio Web in un contenitore.
Si specifica un runtime per il servizio App Runner quando si [crea un servizio](manage-create.md) utilizzando la console App Runner o l'[CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)operazione API. Puoi anche specificare un runtime come parte del codice sorgente. Usa la `runtime` parola chiave in un [file di configurazione di App Runner](config-file.md) che includi nel tuo repository di codice. La convenzione di denominazione di un runtime gestito è. **
App Runner aggiorna il runtime del servizio alla versione più recente a ogni distribuzione o aggiornamento del servizio. Se l'applicazione richiede una versione specifica di un runtime gestito, è possibile specificarla utilizzando la `runtime-version` parola chiave nel file di [configurazione di App Runner](config-file.md). È possibile utilizzare qualsiasi livello di versione, inclusa una versione principale o secondaria. App Runner effettua solo aggiornamenti di livello inferiore al runtime del servizio.
## Fine del supporto per le versioni di runtime gestite
*Quando il provider o la community ufficiale di un runtime linguistico gestito dichiara ufficialmente che una versione è End of Life (EOL), App Runner segue dichiarando che lo stato della versione è End of Support.* Se il servizio è in esecuzione su una versione di runtime in linguaggio gestito che ha raggiunto la fine del supporto, si applicano le politiche e i consigli seguenti.
**Fine del supporto per una versione di runtime del linguaggio:**
+ **I servizi esistenti** continueranno a funzionare e a servire il traffico anche se utilizzano un runtime che ha raggiunto la fine del supporto. Tuttavia, verranno eseguiti su runtime non supportati che non ricevono più aggiornamenti, patch di sicurezza o supporto tecnico.
+ **Gli aggiornamenti ai servizi esistenti** che utilizzano i runtime End of Support sono ancora consentiti, ma non è consigliabile continuare a utilizzare i runtime End of Support per un servizio.
+ Non è possibile creare **nuovi servizi** utilizzando i runtime che hanno raggiunto la data di fine del supporto.
**Azioni richieste per le versioni di runtime in lingua con stato End of Support:**
+ Se il servizio è **basato su un'immagine sorgente**, non sono necessarie ulteriori azioni da parte dell'utente per tale servizio.
+ Se il servizio è **basato sul codice sorgente**, aggiorna la configurazione del servizio per utilizzare una versione di runtime supportata. A tale scopo, seleziona una versione di runtime supportata nella [console App Runner](https://console.aws.amazon.com/apprunner), aggiorna il `runtime` campo nel file di configurazione [apprunner.yaml](config-file.md) o utilizza le operazioni [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 gli strumenti IaC per impostare il parametro. `runtime` Per un elenco dei runtime supportati, consulta la pagina delle *informazioni sulla versione* per ogni runtime specifico in questo capitolo.
+ In alternativa, puoi passare all'opzione di **origine dell'immagine del contenitore** di App Runner. Per ulteriori dettagli, consultare [Servizio basato su immagini](service-source-image.md).
**Nota**
Se stai passando da Node.js 12, 14 o 16 a **Node.js 22** o da Python 3.7 o 3.8 a Python 3.11, tieni presente che Node.js 22 e **Python** 3.11 utilizzano un processo di compilazione di App Runner rivisto che offre build più veloci ed efficienti. [Per garantire la compatibilità prima dell'aggiornamento, ti consigliamo di consultare la guida al processo di compilazione nella sezione successiva.](#service-source-code.build-detail)
Nelle tabelle seguenti sono elencate le versioni di runtime gestite da App Runner con una data di fine supporto designata.
| **Versioni di runtime** | **Data di fine del supporto per App Runner** |
| --- | --- |
| [Python 3.8 Runtime supportati](service-source-code-python-releases.md) | 1 dicembre 2025 |
| [Python 3.7 Runtime supportati](service-source-code-python-releases.md) | 1 dicembre 2025 |
| Node.js 18 [Runtime supportati](service-source-code-nodejs-releases.md) | 1 dicembre 2025 |
| Node.js 16 [Runtime supportati](service-source-code-nodejs-releases.md) | 1 dicembre 2025 |
| Node.js 14 [Runtime supportati](service-source-code-nodejs-releases.md) | 1 dicembre 2025 |
| Node.js 12 [Runtime supportati](service-source-code-nodejs-releases.md) | 1 dicembre 2025 |
| .NET 6 \$1 | 1 dicembre 2025 |
| PHP 8.1 \$1 | 31 dicembre 2025 |
| Ruby 3.1 \$1 | 1 dicembre 2025 |
| Vai 1 \$1 | 1 dicembre 2025 |
**\$1** App Runner non rilascerà alcuna nuova versione in lingua per i runtime contrassegnati da un asterisco (\$1). Questi runtime sono i seguenti: .NET, PHP, Ruby e Go. Se disponi di un servizio basato su codice configurato per questi runtime, ti consigliamo una delle seguenti azioni:
+ Se applicabile, passa la configurazione del servizio a un altro runtime gestito supportato.
+ In alternativa, crea un'immagine del contenitore personalizzata con la tua versione di runtime preferita e distribuiscila utilizzando l'opzione di [Servizio basato su immagini](service-source-image.md) App Runner. Puoi ospitare la tua immagine in Amazon ECR.
## Versioni di runtime gestite e build di App Runner
App Runner offre un processo di compilazione aggiornato per le applicazioni eseguite sui runtime delle versioni principali più recenti. Questo processo di compilazione rivisto è più veloce ed efficiente. Inoltre, crea un'immagine finale con un ingombro ridotto che contiene solo il codice sorgente, gli artefatti di build e i runtime necessari per eseguire l'applicazione.
*Ci riferiamo al processo di compilazione più recente come build di *App Runner rivista e al processo di compilazione originale come build* originale di App Runner.* Per evitare di interrompere le modifiche alle versioni precedenti delle piattaforme di runtime, App Runner applica la build rivista solo a versioni di runtime specifiche, in genere versioni principali appena rilasciate.
Abbiamo introdotto un nuovo componente nel file di `apprunner.yaml` configurazione per rendere la build rivista retrocompatibile per un caso d'uso molto specifico e per fornire anche una maggiore flessibilità nella configurazione della build dell'applicazione. Questo è il parametro opzionale [`pre-run`](config-file-ref.md#config-file-ref.run). Nelle sezioni seguenti spieghiamo quando utilizzare questo parametro insieme ad altre informazioni utili sulle build.
La tabella seguente indica quale versione della build di App Runner si applica a specifiche versioni di runtime gestito. Continueremo ad aggiornare questo documento per tenerti informato sui nostri runtime attuali.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/apprunner/latest/dg/service-source-code.html)
**Nota**
Alcuni dei runtime elencati includono una data **di fine del supporto**. Per ulteriori informazioni, consulta [Fine del supporto per le versioni di runtime gestite](#service-source-code.managed-platforms.eos).
**Importante**
**Python 3.11** — Abbiamo raccomandazioni specifiche per la configurazione di build dei servizi che utilizzano il runtime gestito di Python 3.11. Per ulteriori informazioni, consultate l'[Callout per versioni di runtime specifiche](service-source-code-python.md#service-source-code-python.callouts)argomento relativo alla *piattaforma Python*.
### Ulteriori informazioni sulle build e sulla migrazione di App Runner
Quando esegui la migrazione dell'applicazione a un runtime più recente che utilizza la build rivista, potrebbe essere necessario modificare leggermente la configurazione della build.
Per fornire un contesto alle considerazioni sulla migrazione, descriveremo innanzitutto i processi di alto livello sia per la build originale di App Runner che per la build rivista. Seguirà una sezione che descrive gli attributi specifici del servizio che potrebbero richiedere alcuni aggiornamenti della configurazione.
#### La build originale di App Runner
Il processo di creazione dell'applicazione App Runner originale sfrutta il servizio. AWS CodeBuild I passaggi iniziali si basano su immagini curate dal servizio. CodeBuild Segue un processo di compilazione di Docker che utilizza l'immagine di runtime gestita di App Runner applicabile come immagine di base.
I passaggi generali sono i seguenti:
1. Esegui `pre-build` i comandi in un' CodeBuildimmagine curata.
I `pre-build` comandi sono opzionali. Possono essere specificati solo nel file `apprunner.yaml` di configurazione.
1. Esegui i `build` CodeBuild comandi utilizzando la stessa immagine del passaggio precedente.
I `build` comandi sono obbligatori. Possono essere specificati nella console App Runner, nell'API App Runner o nel `apprunner.yaml` file di configurazione.
1. Esegui una build Docker per generare un'immagine basata sull'immagine di runtime gestita da App Runner per la tua piattaforma e versione di runtime specifiche.
1. Copia la `/app` directory dall'immagine che abbiamo generato nel **passaggio** 2. La destinazione è l'immagine basata sull'immagine di runtime gestita da App Runner, che abbiamo generato nel **passaggio 3**.
1. Esegui nuovamente i `build` comandi sull'immagine di runtime gestita da App Runner generata. **Eseguiamo nuovamente i comandi build per generare artefatti di compilazione dal codice sorgente nella `/app` directory che abbiamo copiato nella Fase 4.** Questa immagine verrà successivamente distribuita da App Runner per eseguire il servizio web in un contenitore.
I `build` comandi sono obbligatori. Possono essere specificati nella console App Runner, nell'API App Runner o nel `apprunner.yaml` file di configurazione.
1. Esegui `post-build` i comandi nell' CodeBuild immagine del **passaggio** 2.
I `post-build` comandi sono opzionali. Possono essere specificati solo nel file `apprunner.yaml` di configurazione.
Una volta completata la build, App Runner distribuisce l'immagine di runtime gestita da App Runner generata dalla **Fase 5** per eseguire il servizio Web in un contenitore.
#### La build di App Runner rivista
Il processo di compilazione rivisto è più veloce ed efficiente rispetto al processo di compilazione originale descritto nella sezione precedente. Elimina la duplicazione dei comandi di compilazione che si verifica nella build della versione precedente. Crea inoltre un'immagine finale con un ingombro ridotto che contiene solo il codice sorgente, gli artefatti di build e i runtime necessari per eseguire l'applicazione.
Questo processo di compilazione utilizza una build Docker in più fasi. Le fasi generali del processo sono le seguenti:
1. **Fase di compilazione**: avvia un processo di compilazione docker che esegue `pre-build` e `build` comandi sulle immagini di build di App Runner.
1. Copia il codice sorgente dell'applicazione nella directory. `/app`
**Nota**
Questa `/app` directory è designata come directory di lavoro in ogni fase della build di Docker.
1. Tramite i comandi `pre-build`.
I `pre-build` comandi sono opzionali. Possono essere specificati solo nel file `apprunner.yaml` di configurazione.
1. Esegui i `build` comandi.
I `build` comandi sono obbligatori. Possono essere specificati nella console App Runner, nell'API App Runner o nel `apprunner.yaml` file di configurazione.
1. **Fase di confezionamento**: genera l'immagine del contenitore del cliente finale, anch'essa basata sull'immagine di esecuzione di App Runner.
1. Copia la `/app` directory dalla **fase di compilazione** precedente alla nuova immagine Run. Ciò include il codice sorgente dell'applicazione e gli elementi di compilazione della fase precedente.
1. Esegui i comandi. `pre-run` Se è necessario modificare l'immagine di runtime all'esterno della `/app` directory utilizzando i `build` comandi, aggiungete gli stessi comandi o quelli necessari a questo segmento del file di `apprunner.yaml` configurazione.
Questo è un nuovo parametro che è stato introdotto per supportare la versione rivista di App Runner.
I `pre-run` comandi sono opzionali. Possono essere specificati solo nel file `apprunner.yaml` di configurazione.
**Note**
I `pre-run` comandi sono supportati solo dalla build rivista. Non aggiungeteli al file di configurazione se il servizio utilizza versioni di runtime che utilizzano la build originale.
Se non è necessario modificare nulla all'esterno della `/app` directory con i `build` comandi, non è necessario specificare `pre-run` i comandi.
1. **Fase successiva alla compilazione**: questa fase riprende dalla fase di *compilazione ed esegue i comandi*. `post-build`
1. Esegui i `post-build` comandi all'interno della directory. `/app`
I `post-build` comandi sono opzionali. Possono essere specificati solo nel file `apprunner.yaml` di configurazione.
Al termine della build, App Runner distribuisce quindi l'immagine Run per eseguire il servizio Web in un contenitore.
**Nota**
Non fatevi ingannare dalle `env` voci nella sezione Esegui di `apprunner.yaml` quando configuri il processo di compilazione. Anche se il parametro `pre-run` command, a cui si fa riferimento nel **passaggio 2 (b)**, si trova nella sezione Esegui, non utilizzare il `env` parametro nella sezione Run per configurare la build. I `pre-run` comandi fanno riferimento solo alle `env` variabili definite nella sezione Build del file di configurazione. Per ulteriori informazioni, consultate il [Sezione Esegui](config-file-ref.md#config-file-ref.run) *capitolo sul file di configurazione di App Runner*.
#### Considerazione dei requisiti di servizio per la migrazione
Se il tuo ambiente applicativo presenta uno di questi due requisiti, dovrai rivedere la configurazione della build aggiungendo `pre-run` comandi.
+ Se è necessario modificare qualcosa al di fuori della `/app` directory con i `build` comandi.
+ Se è necessario eseguire i `build` comandi due volte per creare l'ambiente richiesto. Si tratta di un requisito molto insolito. La stragrande maggioranza delle build non lo farà.
**Modifiche al di fuori della directory `/app`**
+ La [build rivista di App Runner](#service-source-code.build-detail.v2) presuppone che l'applicazione non abbia dipendenze al di fuori della directory. `/app`
+ I comandi forniti con il `apprunner.yaml` file, l'API App Runner o la console App Runner devono generare artefatti di build nella directory. `/app`
+ È possibile modificare i `post-build` comandi `pre-build``build`, e per garantire che tutti gli artefatti di build siano presenti nella directory. `/app`
+ Se l'applicazione richiede la build per modificare ulteriormente l'immagine generata per il servizio, al di fuori della `/app` directory, è possibile utilizzare i nuovi `pre-run` comandi in. `apprunner.yaml` Per ulteriori informazioni, consulta [Impostazione delle opzioni del servizio App Runner utilizzando un file di configurazione](config-file.md).
**Esecuzione dei `build` comandi due volte**
+ La [build originale di App Runner](#service-source-code.build-detail.v1) esegue i `build` comandi due volte, prima nel **passaggio 2**, poi di nuovo nel **passaggio 5**. La build rivista di App Runner pone rimedio a questa ridondanza ed esegue i comandi solo una volta. `build` Se l'applicazione dovesse richiedere un'esecuzione insolita dei `build` comandi due volte, la build aggiornata di App Runner offre la possibilità di specificare ed eseguire nuovamente gli stessi comandi utilizzando il parametro. `pre-run` In questo modo si mantiene lo stesso comportamento di doppia build.
# Utilizzo della piattaforma Python di
**Importante**
App Runner terminerà il supporto per **Python 3.7 **e Python**** 3.8 il 1° dicembre 2025. Per consigli e ulteriori informazioni, consulta. [Fine del supporto per le versioni di runtime gestite](service-source-code.md#service-source-code.managed-platforms.eos)
La piattaforma AWS App Runner Python fornisce runtime gestiti. Ogni runtime semplifica la creazione e l'esecuzione di contenitori con applicazioni Web basate su una versione Python. Quando si utilizza un runtime Python, App Runner inizia con un'immagine di runtime Python gestita. Questa immagine è basata sull'[immagine Docker di Amazon Linux](https://hub.docker.com/_/amazonlinux) e contiene il pacchetto runtime per una versione di Python e alcuni strumenti e pacchetti di dipendenze popolari. App Runner utilizza questa immagine di runtime gestita come immagine di base e aggiunge il codice dell'applicazione per creare un'immagine Docker. Quindi distribuisce questa immagine per eseguire il servizio Web in un contenitore.
Si specifica un runtime per il servizio App Runner quando si [crea un servizio](manage-create.md) utilizzando la console App Runner o l'[CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)operazione API. Puoi anche specificare un runtime come parte del codice sorgente. Usa la `runtime` parola chiave in un [file di configurazione di App Runner](config-file.md) che includi nel tuo repository di codice. La convenzione di denominazione di un runtime gestito è. **
Per i nomi e le versioni di runtime Python validi, vedere. [Informazioni sul rilascio del runtime di Python](service-source-code-python-releases.md)
App Runner aggiorna il runtime del servizio alla versione più recente a ogni distribuzione o aggiornamento del servizio. Se l'applicazione richiede una versione specifica di un runtime gestito, è possibile specificarla utilizzando la `runtime-version` parola chiave nel file di [configurazione di App Runner](config-file.md). È possibile utilizzare qualsiasi livello di versione, inclusa una versione principale o secondaria. App Runner effettua solo aggiornamenti di livello inferiore al runtime del servizio.
Sintassi della versione per i runtime di Python: `major[.minor[.patch]]`
Ad esempio: `3.8.5`
Gli esempi seguenti mostrano il blocco della versione:
+ `3.8`— Blocca le versioni principali e secondarie. App Runner aggiorna solo le versioni patch.
+ `3.8.5`— Blocca a una versione di patch specifica. App Runner non aggiorna la versione di runtime.
**Topics**
+ [Configurazione del runtime di Python](#service-source-code-python.config)
+ [Callout per versioni di runtime specifiche](#service-source-code-python.callouts)
+ [Esempi di runtime in Python](#service-source-code-python.examples)
+ [Informazioni sul rilascio del runtime di Python](service-source-code-python-releases.md)
## Configurazione del runtime di Python
Quando scegli un runtime gestito, devi anche configurare, come minimo, creare ed eseguire comandi. Li configuri durante la [creazione](manage-create.md) o [l'aggiornamento del](manage-configure.md) servizio App Runner. Puoi farlo utilizzando uno dei seguenti metodi:
+ **Utilizzo della console App Runner**: specifica i comandi nella sezione **Configure build** del processo di creazione o della scheda di configurazione.
+ **Utilizzo dell'API App Runner**: richiama l'operazione [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)or [UpdateService](https://docs.aws.amazon.com/apprunner/latest/api/API_UpdateService.html)API. Specificate i comandi utilizzando i `StartCommand` membri `BuildCommand` e del tipo di [CodeConfigurationValues](https://docs.aws.amazon.com/apprunner/latest/api/API_CodeConfigurationValues.html)dati.
+ **Utilizzo di un [file di configurazione](config-file.md)**: specifica uno o più comandi di compilazione in un massimo di tre fasi di compilazione e un singolo comando di esecuzione che serve per avviare l'applicazione. Sono disponibili impostazioni di configurazione opzionali aggiuntive.
Fornire un file di configurazione è facoltativo. Quando crei un servizio App Runner utilizzando la console o l'API, specifichi se App Runner ottiene le impostazioni di configurazione direttamente al momento della creazione o da un file di configurazione.
## Callout per versioni di runtime specifiche
**Nota**
App Runner ora esegue un processo di compilazione aggiornato per le applicazioni basate sulle seguenti versioni di runtime: Python 3.11, Node.js 22 e Node.js 18. Se l'applicazione viene eseguita su una di queste versioni di runtime, consulta [Versioni di runtime gestite e build di App Runner](service-source-code.md#service-source-code.build-detail) per ulteriori informazioni sul processo di compilazione rivisto. Le applicazioni che utilizzano tutte le altre versioni di runtime non sono interessate e continuano a utilizzare il processo di compilazione originale.
### Python 3.11 (build App Runner rivista)
Usa le seguenti impostazioni in *apprunner.yaml* per il runtime Python 3.11 gestito.
+ Imposta la chiave nella sezione Top su `runtime` `python311`
**Example**
```
runtime: python311
```
+ Usa `pip3` invece di `pip` per installare le dipendenze.
+ Usa l'`python3`interprete invece di. `python`
+ Esegui il `pip3` programma di installazione come comando. `pre-run` Python installa le dipendenze all'esterno della directory. `/app` Poiché App Runner esegue la build aggiornata di App Runner per Python 3.11, tutto ciò che è installato all'esterno della `/app` directory tramite i comandi nella sezione Build del file andrà perso. `apprunner.yaml` Per ulteriori informazioni, consulta [La build di App Runner rivista](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 -
```
Per ulteriori informazioni, vedi anche l'[esempio di un file di configurazione esteso per Python 3.11](#service-source-code-python.examples.extended-v2) più avanti in questo argomento.
## Esempi di runtime in Python
Gli esempi seguenti mostrano i file di configurazione di App Runner per la creazione e l'esecuzione di un servizio Python. L'ultimo esempio è il codice sorgente per un'applicazione Python completa che puoi distribuire su un servizio di runtime Python.
**Nota**
La versione di runtime utilizzata in questi esempi è and. *3.7.7* *3.11* Puoi sostituirla con una versione che desideri utilizzare. Per l'ultima versione di runtime di Python supportata, vedere. [Informazioni sul rilascio del runtime di Python](service-source-code-python-releases.md)
### File di configurazione Python minimo
Questo esempio mostra un file di configurazione minimo che puoi usare con un runtime gestito da Python. Per le ipotesi che App Runner fa con un file di configurazione minimo, vedi. [Esempi di file di configurazione](config-file-examples.md#config-file-examples.managed)
Python 3.11 utilizza i comandi and. `pip3` `python3` Per ulteriori informazioni, vedete l'[esempio di un file di configurazione esteso per Python 3.11](#service-source-code-python.examples.extended-v2) più avanti in questo argomento.
**Example apprunner.yaml**
```
version: 1.0
runtime: python3
build:
commands:
build:
- pip install pipenv
- pipenv install
run:
command: python app.py
```
### File di configurazione Python esteso
Questo esempio mostra l'uso di tutte le chiavi di configurazione con un runtime gestito da Python.
**Nota**
La versione di runtime utilizzata in questi esempi è*3.7.7*. Puoi sostituirla con una versione che desideri utilizzare. Per l'ultima versione di runtime di Python supportata, vedere. [Informazioni sul rilascio del runtime di Python](service-source-code-python-releases.md)
Python 3.11 utilizza i comandi and. `pip3` `python3` Per ulteriori informazioni, vedete l'esempio di un file di configurazione esteso per Python 3.11 più avanti in questo argomento.
**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"
```
### File di configurazione Python esteso — Python 3.11 (utilizza la build rivista)
Questo esempio mostra l'uso di tutte le chiavi di configurazione con un runtime gestito da Python 3.11 in. `apprunner.yaml` Questo esempio include una `pre-run` sezione, poiché questa versione di Python utilizza la build di App Runner rivista.
Il `pre-run` parametro è supportato solo dalla build aggiornata di App Runner. Non inserire questo parametro nel file di configurazione se l'applicazione utilizza versioni di runtime supportate dalla build originale di App Runner. Per ulteriori informazioni, consulta [Versioni di runtime gestite e build di App Runner](service-source-code.md#service-source-code.build-detail).
**Nota**
La versione di runtime utilizzata in questi esempi è*3.11*. Puoi sostituirla con una versione che desideri utilizzare. Per l'ultima versione di runtime di Python supportata, vedere. [Informazioni sul rilascio del runtime di 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"
```
### Sorgente completo dell'applicazione Python
Questo esempio mostra il codice sorgente per un'applicazione Python completa che puoi distribuire su un servizio di runtime 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
```
# Informazioni sul rilascio del runtime di Python
**Importante**
App Runner terminerà il supporto per **Python 3.7 **e Python**** 3.8 il 1° dicembre 2025. Per consigli e ulteriori informazioni, consulta. [Fine del supporto per le versioni di runtime gestite](service-source-code.md#service-source-code.managed-platforms.eos)
Questo argomento elenca i dettagli completi per le versioni di runtime di Python supportate da App Runner.
**Versioni di runtime supportate: build di App Runner rivista**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/apprunner/latest/dg/service-source-code-python-releases.html)
**Note**
**Python 3.11** — Abbiamo raccomandazioni specifiche per la configurazione di build dei servizi che utilizzano il runtime gestito di Python 3.11. Per ulteriori informazioni, consultate l'[Callout per versioni di runtime specifiche](service-source-code-python.md#service-source-code-python.callouts)argomento relativo alla *piattaforma Python*.
App Runner fornisce un processo di compilazione rivisto per i principali runtime specifici che sono stati rilasciati più di recente. Per questo motivo, in alcune sezioni di questo documento vedrai riferimenti alla build di *App Runner rivista e alla build* *originale di App Runner*. Per ulteriori informazioni, consulta [Versioni di runtime gestite e build di App Runner](service-source-code.md#service-source-code.build-detail).
**Versioni di runtime supportate: build originale di App Runner**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/apprunner/latest/dg/service-source-code-python-releases.html)
**Nota**
App Runner fornisce un processo di compilazione rivisto per i principali runtime specifici che sono stati rilasciati più di recente. Per questo motivo, in alcune sezioni di questo documento vedrai riferimenti alla build di *App Runner rivista e alla build* *originale di App Runner*. Per ulteriori informazioni, consulta [Versioni di runtime gestite e build di App Runner](service-source-code.md#service-source-code.build-detail).
# Utilizzo della piattaforma Node.js di
**Importante**
App Runner interromperà il supporto per **Node.js 12**, **Node.js 14**, **Node.js 16** e **Node.js 18** il 1° dicembre 2025. Per consigli e ulteriori informazioni, consulta. [Fine del supporto per le versioni di runtime gestite](service-source-code.md#service-source-code.managed-platforms.eos)
La piattaforma AWS App Runner Node.js fornisce runtime gestiti. Ogni runtime semplifica la creazione e l'esecuzione di contenitori con applicazioni Web basate su una versione Node.js. Quando si utilizza un runtime Node.js, App Runner si avvia con un'immagine di runtime Node.js gestita. Questa immagine è basata sull'[immagine Docker di Amazon Linux](https://hub.docker.com/_/amazonlinux) e contiene il pacchetto di runtime per una versione di Node.js e alcuni strumenti. App Runner utilizza questa immagine di runtime gestita come immagine di base e aggiunge il codice dell'applicazione per creare un'immagine Docker. Quindi distribuisce questa immagine per eseguire il servizio Web in un contenitore.
Si specifica un runtime per il servizio App Runner quando si [crea un servizio](manage-create.md) utilizzando la console App Runner o l'[CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)operazione API. Puoi anche specificare un runtime come parte del codice sorgente. Usa la `runtime` parola chiave in un [file di configurazione di App Runner](config-file.md) che includi nel tuo repository di codice. La convenzione di denominazione di un runtime gestito è. **
Per i nomi e le versioni di runtime di Node.js validi, vedere[Informazioni sulla versione di runtime di Node.js](service-source-code-nodejs-releases.md).
App Runner aggiorna il runtime del servizio alla versione più recente a ogni distribuzione o aggiornamento del servizio. Se l'applicazione richiede una versione specifica di un runtime gestito, è possibile specificarla utilizzando la `runtime-version` parola chiave nel file di [configurazione di App Runner](config-file.md). È possibile utilizzare qualsiasi livello di versione, inclusa una versione principale o secondaria. App Runner effettua solo aggiornamenti di livello inferiore al runtime del servizio.
Sintassi della versione per i runtime di Node.js: `major[.minor[.patch]]`
Ad esempio: `22.14.0`
Gli esempi seguenti mostrano il blocco della versione:
+ `22.14`— Blocca le versioni principali e secondarie. App Runner aggiorna solo le versioni patch.
+ `22.14.0`— Blocca a una versione di patch specifica. App Runner non aggiorna la versione di runtime.
**Topics**
+ [Configurazione del runtime di Node.js](#service-source-code-nodejs.config)
+ [Callout per versioni di runtime specifiche](#service-source-code-nodejs.callouts)
+ [Esempi di runtime di Node.js](#service-source-code-nodejs.examples)
+ [Informazioni sulla versione di runtime di Node.js](service-source-code-nodejs-releases.md)
## Configurazione del runtime di Node.js
Quando scegli un runtime gestito, devi anche configurare, come minimo, creare ed eseguire comandi. Li configuri durante la [creazione](manage-create.md) o [l'aggiornamento del](manage-configure.md) servizio App Runner. Puoi farlo utilizzando uno dei seguenti metodi:
+ **Utilizzo della console App Runner**: specifica i comandi nella sezione **Configure build** del processo di creazione o della scheda di configurazione.
+ **Utilizzo dell'API App Runner**: richiama l'operazione [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)or [UpdateService](https://docs.aws.amazon.com/apprunner/latest/api/API_UpdateService.html)API. Specificate i comandi utilizzando i `StartCommand` membri `BuildCommand` e del tipo di [CodeConfigurationValues](https://docs.aws.amazon.com/apprunner/latest/api/API_CodeConfigurationValues.html)dati.
+ **Utilizzo di un [file di configurazione](config-file.md)**: specifica uno o più comandi di compilazione in un massimo di tre fasi di compilazione e un singolo comando di esecuzione che serve per avviare l'applicazione. Sono disponibili impostazioni di configurazione opzionali aggiuntive.
Fornire un file di configurazione è facoltativo. Quando crei un servizio App Runner utilizzando la console o l'API, specifichi se App Runner ottiene le impostazioni di configurazione direttamente al momento della creazione o da un file di configurazione.
In particolare, con i runtime di Node.js, puoi anche configurare la build e il runtime utilizzando un file JSON denominato `package.json` nella radice del tuo repository di origine. Utilizzando questo file, è possibile configurare la versione del motore Node.js, i pacchetti di dipendenze e vari comandi (applicazioni a riga di comando). I gestori di pacchetti come npm o yarn interpretano questo file come input per i loro comandi.
Esempio:
+ **npm install**installa i pacchetti definiti dal nodo `dependencies` and `devDependencies` in. `package.json`
+ **npm start**o **npm run start** esegue il comando definito dal `scripts/start` nodo in`package.json`.
Di seguito è riportato un esempio del file `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"
}
}
```
*Per ulteriori informazioni su`package.json`, vedere [Creazione di un file package.json](https://docs.npmjs.com/creating-a-package-json-file) sul sito Web di npm Docs.*
**Suggerimenti**
Se il `package.json` file definisce un **start** comando, è possibile utilizzarlo come comando nel file di configurazione di App Runner, come illustrato nell'esempio **run** seguente.
**Example**
package.json
```
{
"scripts": {
"start": "node index.js"
}
}
```
apprunner.yaml
```
run:
command: npm start
```
Quando esegui **npm install** nel tuo ambiente di sviluppo, npm crea il file. `package-lock.json` Questo file contiene un'istantanea delle versioni del pacchetto appena installate da npm. Successivamente, quando npm installa le dipendenze, utilizza queste versioni esatte. Se installi yarn, crea un file. `yarn.lock` Salva questi file nel tuo repository del codice sorgente per assicurarti che l'applicazione sia installata con le versioni delle dipendenze che hai sviluppato e con cui l'hai testata.
È inoltre possibile utilizzare un file di configurazione di App Runner per configurare la versione di Node.js e il comando start. Quando si esegue questa operazione, queste definizioni sostituiscono quelle incluse. `package.json` Un conflitto tra la `node` versione in `package.json` e il `runtime-version` valore nel file di configurazione di App Runner causa il fallimento della fase di compilazione di App Runner.
## Callout per versioni di runtime specifiche
### Node.js 22 e Node.js 18 (build App Runner rivista)
App Runner ora esegue un processo di compilazione aggiornato per le applicazioni basate sulle seguenti versioni di runtime: Python 3.11, Node.js 22 e Node.js 18. Se l'applicazione viene eseguita su una di queste versioni di runtime, consulta [Versioni di runtime gestite e build di App Runner](service-source-code.md#service-source-code.build-detail) per ulteriori informazioni sul processo di compilazione rivisto. Le applicazioni che utilizzano tutte le altre versioni di runtime non sono interessate e continuano a utilizzare il processo di compilazione originale.
## Esempi di runtime di Node.js
Gli esempi seguenti mostrano i file di configurazione di App Runner per la creazione e l'esecuzione di un servizio Node.js.
**Nota**
La versione di runtime utilizzata in questi esempi è*22.14.0*. Puoi sostituirla con una versione che desideri utilizzare. Per l'ultima versione di runtime supportata di Node.js, vedere[Informazioni sulla versione di runtime di Node.js](service-source-code-nodejs-releases.md).
### File di configurazione minimo Node.js
Questo esempio mostra un file di configurazione minimo che è possibile utilizzare con un runtime gestito da Node.js. Per le ipotesi che App Runner fa con un file di configurazione minimo, vedi. [Esempi di file di configurazione](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
```
### File di configurazione Node.js esteso
Questo esempio mostra l'uso di tutte le chiavi di configurazione con un runtime gestito da Node.js.
**Nota**
La versione di runtime utilizzata in questi esempi è*22.14.0*. Puoi sostituirla con una versione che desideri utilizzare. Per l'ultima versione di runtime supportata di Node.js, vedere[Informazioni sulla versione di runtime di 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"
```
### File di configurazione Node.js esteso — Node.js 22 (utilizza la build rivista)
Questo esempio mostra l'uso di tutte le chiavi di configurazione con un runtime gestito da Node.js in. `apprunner.yaml` Questo esempio include una `pre-run` sezione, poiché questa versione di Node.js utilizza la build aggiornata di App Runner.
Il `pre-run` parametro è supportato solo dalla build aggiornata di App Runner. Non inserire questo parametro nel file di configurazione se l'applicazione utilizza versioni di runtime supportate dalla build originale di App Runner. Per ulteriori informazioni, consulta [Versioni di runtime gestite e build di App Runner](service-source-code.md#service-source-code.build-detail).
**Nota**
La versione di runtime utilizzata in questi esempi è*22.14.0*. Puoi sostituirla con una versione che desideri utilizzare. Per l'ultima versione di runtime supportata di Node.js, vedere[Informazioni sulla versione di runtime di 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"
```
### App Node.js con Grunt
Questo esempio mostra come configurare un'applicazione Node.js sviluppata con Grunt. [Grunt](https://gruntjs.com/) è un JavaScript task runner da riga di comando. Esegue attività ripetitive e gestisce l'automazione dei processi per ridurre l'errore umano. I plugin Grunt e Grunt vengono installati e gestiti utilizzando npm. Si configura Grunt includendo il `Gruntfile.js` file nella radice del repository di origine.
**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 versione di runtime utilizzata in questi esempi è. *22.14.0* Puoi sostituirla con una versione che desideri utilizzare. Per l'ultima versione di runtime supportata di Node.js, vedere[Informazioni sulla versione di runtime di 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
```
# Informazioni sulla versione di runtime di Node.js
**Importante**
App Runner interromperà il supporto per **Node.js 12**, **Node.js 14**, **Node.js 16** e **Node.js 18** il 1° dicembre 2025. Per consigli e ulteriori informazioni, consulta. [Fine del supporto per le versioni di runtime gestite](service-source-code.md#service-source-code.managed-platforms.eos)
**Nota**
La politica di deprecazione standard di App Runner prevede di rendere obsoleto un runtime quando uno dei componenti principali del runtime raggiunge la fine del supporto a lungo termine della community (LTS) e gli aggiornamenti di sicurezza non sono più disponibili. In alcuni casi, App Runner può ritardare l'obsolescenza di un runtime per un periodo limitato, oltre la data della versione linguistica supportata dal runtime. end-of-support Un esempio di questo caso potrebbe essere l'estensione del supporto per un runtime per consentire ai clienti il tempo necessario per la migrazione.
Questo argomento elenca i dettagli completi per le versioni di runtime di Node.js supportate da App Runner.
**Versioni di runtime supportate: build di App Runner rivista**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/apprunner/latest/dg/service-source-code-nodejs-releases.html)
**Nota**
App Runner fornisce un processo di compilazione rivisto per i principali runtime specifici che sono stati rilasciati più di recente. Per questo motivo, in alcune sezioni di questo documento vedrai riferimenti alla build di *App Runner rivista e alla build* *originale di App Runner*. Per ulteriori informazioni, consulta [Versioni di runtime gestite e build di App Runner](service-source-code.md#service-source-code.build-detail).
**Versioni di runtime supportate: build di App Runner rivista**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/apprunner/latest/dg/service-source-code-nodejs-releases.html)
**Versioni di runtime supportate: build originale di App Runner**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/apprunner/latest/dg/service-source-code-nodejs-releases.html)
# Utilizzo della piattaforma Java
La piattaforma AWS App Runner Java fornisce runtime gestiti. Ogni runtime semplifica la creazione e l'esecuzione di contenitori con applicazioni Web basate su una versione Java. Quando si utilizza un runtime Java, App Runner inizia con un'immagine di runtime Java gestita. Questa immagine è basata sull'[immagine Docker di Amazon Linux](https://hub.docker.com/_/amazonlinux) e contiene il pacchetto di runtime per una versione di Java e alcuni strumenti. App Runner utilizza questa immagine di runtime gestita come immagine di base e aggiunge il codice dell'applicazione per creare un'immagine Docker. Quindi distribuisce questa immagine per eseguire il servizio Web in un contenitore.
Si specifica un runtime per il servizio App Runner quando si [crea un servizio](manage-create.md) utilizzando la console App Runner o l'[CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)operazione API. Puoi anche specificare un runtime come parte del codice sorgente. Usa la `runtime` parola chiave in un [file di configurazione di App Runner](config-file.md) che includi nel tuo repository di codice. La convenzione di denominazione di un runtime gestito è. **
Al momento, tutti i runtime Java supportati sono basati su Amazon Corretto. Per nomi e versioni di runtime Java validi, consulta[Informazioni sulla release di Java Runtime](service-source-code-java-releases.md).
App Runner aggiorna il runtime del servizio alla versione più recente a ogni distribuzione o aggiornamento del servizio. Se l'applicazione richiede una versione specifica di un runtime gestito, è possibile specificarla utilizzando la `runtime-version` parola chiave nel file di [configurazione di App Runner](config-file.md). È possibile utilizzare qualsiasi livello di versione, inclusa una versione principale o secondaria. App Runner effettua solo aggiornamenti di livello inferiore al runtime del servizio.
Sintassi della versione per i runtime di Amazon Corretto:
| **Runtime** | **Sintassi** | **Esempio** |
| --- | --- | --- |
| 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` |
Gli esempi seguenti mostrano il blocco della versione:
+ `11.0.13`— Blocca la versione di aggiornamento di Open JDK. App Runner aggiorna solo le build di livello inferiore di Open JDK e Amazon Corretto.
+ `11.0.13.08.1`— Blocca a una versione specifica. App Runner non aggiorna la tua versione di runtime.
**Topics**
+ [Configurazione del runtime Java](#service-source-code-java.config)
+ [Esempi di runtime Java](#service-source-code-java.examples)
+ [Informazioni sulla release di Java Runtime](service-source-code-java-releases.md)
## Configurazione del runtime Java
Quando scegli un runtime gestito, devi anche configurare, come minimo, creare ed eseguire comandi. Li configuri durante la [creazione](manage-create.md) o [l'aggiornamento del](manage-configure.md) servizio App Runner. Puoi farlo utilizzando uno dei seguenti metodi:
+ **Utilizzo della console App Runner**: specifica i comandi nella sezione **Configure build** del processo di creazione o della scheda di configurazione.
+ **Utilizzo dell'API App Runner**: richiama l'operazione [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)or [UpdateService](https://docs.aws.amazon.com/apprunner/latest/api/API_UpdateService.html)API. Specificate i comandi utilizzando i `StartCommand` membri `BuildCommand` e del tipo di [CodeConfigurationValues](https://docs.aws.amazon.com/apprunner/latest/api/API_CodeConfigurationValues.html)dati.
+ **Utilizzo di un [file di configurazione](config-file.md)**: specifica uno o più comandi di compilazione in un massimo di tre fasi di compilazione e un singolo comando di esecuzione che serve per avviare l'applicazione. Sono disponibili impostazioni di configurazione opzionali aggiuntive.
Fornire un file di configurazione è facoltativo. Quando crei un servizio App Runner utilizzando la console o l'API, specifichi se App Runner ottiene le impostazioni di configurazione direttamente al momento della creazione o da un file di configurazione.
## Esempi di runtime Java
Gli esempi seguenti mostrano i file di configurazione di App Runner per la creazione e l'esecuzione di un servizio Java. L'ultimo esempio è il codice sorgente di un'applicazione Java completa che è possibile distribuire su un servizio di runtime Corretto 11.
**Nota**
La versione di runtime utilizzata in questi esempi è*11.0.13.08.1*. Puoi sostituirla con una versione che desideri utilizzare. Per l'ultima versione di runtime Java supportata, vedere[Informazioni sulla release di Java Runtime](service-source-code-java-releases.md).
### File di configurazione Minimal Corretto 11
Questo esempio mostra un file di configurazione minimo che è possibile utilizzare con un runtime gestito di Corretto 11. Per le ipotesi che App Runner fa con un file di configurazione minimo, vedi.
**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 .
```
### File di configurazione Corretto 11 esteso
Questo esempio mostra come utilizzare tutte le chiavi di configurazione con un runtime gestito di Corretto 11.
**Nota**
La versione di runtime utilizzata in questi esempi è*11.0.13.08.1*. Puoi sostituirla con una versione che desideri utilizzare. Per l'ultima versione di runtime Java supportata, vedere[Informazioni sulla release di 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"
```
### Sorgente completo dell'applicazione Corretto 11
Questo esempio mostra il codice sorgente di un'applicazione Java completa che è possibile distribuire su un servizio di runtime 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 apprunner.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
```
# Informazioni sulla release di Java Runtime
Questo argomento elenca i dettagli completi per le versioni di runtime Java supportate da App Runner.
**Versioni di runtime supportate: build originale di App Runner**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/apprunner/latest/dg/service-source-code-java-releases.html)
**Nota**
App Runner fornisce un processo di compilazione rivisto per i principali runtime specifici che sono stati rilasciati più di recente. Per questo motivo, in alcune sezioni di questo documento vedrai riferimenti alla build di *App Runner rivista e alla build* *originale di App Runner*. Per ulteriori informazioni, consulta [Versioni di runtime gestite e build di App Runner](service-source-code.md#service-source-code.build-detail).
# Utilizzo della piattaforma .NET di
**Importante**
App Runner interromperà il supporto **per.NET 6** il 1° dicembre 2025. Per consigli e ulteriori informazioni, consulta. [Fine del supporto per le versioni di runtime gestite](service-source-code.md#service-source-code.managed-platforms.eos)
La piattaforma AWS App Runner .NET fornisce runtime gestiti. Ogni runtime semplifica la creazione e l'esecuzione di contenitori con applicazioni Web basate su una versione.NET. Quando si utilizza un runtime .NET, App Runner si avvia con un'immagine di runtime .NET gestita. Questa immagine è basata sull'[immagine Docker di Amazon Linux](https://hub.docker.com/_/amazonlinux) e contiene il pacchetto di runtime per una versione di.NET e alcuni strumenti e pacchetti di dipendenze popolari. App Runner utilizza questa immagine di runtime gestita come immagine di base e aggiunge il codice dell'applicazione per creare un'immagine Docker. Quindi distribuisce questa immagine per eseguire il servizio Web in un contenitore.
Si specifica un runtime per il servizio App Runner quando si [crea un servizio](manage-create.md) utilizzando la console App Runner o l'[CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)operazione API. Puoi anche specificare un runtime come parte del codice sorgente. Usa la `runtime` parola chiave in un [file di configurazione di App Runner](config-file.md) che includi nel tuo repository di codice. La convenzione di denominazione di un runtime gestito è. **
Per i nomi e le versioni di runtime di.NET validi, vedere[Informazioni sulla release del runtime di.NET](service-source-code-dotnet-releases.md).
App Runner aggiorna il runtime del servizio alla versione più recente a ogni distribuzione o aggiornamento del servizio. Se l'applicazione richiede una versione specifica di un runtime gestito, è possibile specificarla utilizzando la `runtime-version` parola chiave nel file di [configurazione di App Runner](config-file.md). È possibile utilizzare qualsiasi livello di versione, inclusa una versione principale o secondaria. App Runner effettua solo aggiornamenti di livello inferiore al runtime del servizio.
Sintassi della versione per i runtime.NET: `major[.minor[.patch]]`
Ad esempio: `6.0.9`
Gli esempi seguenti mostrano il blocco della versione:
+ `6.0`— Blocca le versioni principali e secondarie. App Runner aggiorna solo le versioni patch.
+ `6.0.9`— Blocca a una versione di patch specifica. App Runner non aggiorna la versione di runtime.
**Topics**
+ [Configurazione del runtime di.NET](#service-source-code-net6.config)
+ [Esempi di runtime di.NET](#service-source-code-net6.examples)
+ [Informazioni sulla release del runtime di.NET](service-source-code-dotnet-releases.md)
## Configurazione del runtime di.NET
Quando scegli un runtime gestito, devi anche configurare, come minimo, creare ed eseguire comandi. Li configuri durante la [creazione](manage-create.md) o [l'aggiornamento del](manage-configure.md) servizio App Runner. Puoi farlo utilizzando uno dei seguenti metodi:
+ **Utilizzo della console App Runner**: specifica i comandi nella sezione **Configure build** del processo di creazione o della scheda di configurazione.
+ **Utilizzo dell'API App Runner**: richiama l'operazione [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)or [UpdateService](https://docs.aws.amazon.com/apprunner/latest/api/API_UpdateService.html)API. Specificate i comandi utilizzando i `StartCommand` membri `BuildCommand` e del tipo di [CodeConfigurationValues](https://docs.aws.amazon.com/apprunner/latest/api/API_CodeConfigurationValues.html)dati.
+ **Utilizzo di un [file di configurazione](config-file.md)**: specifica uno o più comandi di compilazione in un massimo di tre fasi di compilazione e un singolo comando di esecuzione che serve per avviare l'applicazione. Sono disponibili impostazioni di configurazione opzionali aggiuntive.
Fornire un file di configurazione è facoltativo. Quando crei un servizio App Runner utilizzando la console o l'API, specifichi se App Runner ottiene le impostazioni di configurazione direttamente al momento della creazione o da un file di configurazione.
## Esempi di runtime di.NET
Gli esempi seguenti mostrano i file di configurazione di App Runner per la creazione e l'esecuzione di un servizio.NET. L'ultimo esempio è il codice sorgente di un'applicazione.NET completa che è possibile distribuire su un servizio di runtime.
**Nota**
La versione di runtime utilizzata in questi esempi è*6.0.9*. Puoi sostituirla con una versione che desideri utilizzare. Per la versione di runtime di.NET più recente supportata, vedi[Informazioni sulla release del runtime di.NET](service-source-code-dotnet-releases.md).
### File di configurazione.NET minimo
Questo esempio mostra un file di configurazione minimo che è possibile utilizzare con un runtime gestito.NET. Per le ipotesi che App Runner fa con un file di configurazione minimo, vedi. [Esempi di file di configurazione](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
```
### File di configurazione.NET esteso
Questo esempio mostra l'uso di tutte le chiavi di configurazione con un runtime gestito.NET.
**Nota**
La versione di runtime utilizzata in questi esempi è*6.0.9*. Puoi sostituirla con una versione che desideri utilizzare. Per la versione di runtime di.NET più recente supportata, vedi[Informazioni sulla release del runtime di.NET](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"
```
### Fonte completa dell'applicazione.NET
Questo esempio mostra il codice sorgente di un'applicazione.NET completa che è possibile distribuire su un servizio di runtime.
**Nota**
Esegui il comando seguente per creare una semplice app web.NET 6: ` dotnet new web --name HelloWorldDotNetApp -f net6.0`
Aggiungi il `apprunner.yaml` all'app web.NET 6 creata.
**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"
```
# Informazioni sulla release del runtime di.NET
**Importante**
App Runner interromperà il supporto **per.NET 6** il 1° dicembre 2025. Per consigli e ulteriori informazioni, consulta. [Fine del supporto per le versioni di runtime gestite](service-source-code.md#service-source-code.managed-platforms.eos)
Questo argomento elenca i dettagli completi per le versioni di runtime di.NET supportate da App Runner.
**Versioni di runtime supportate: build originale di App Runner**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/apprunner/latest/dg/service-source-code-dotnet-releases.html)
**Nota**
App Runner fornisce un processo di compilazione rivisto per i principali runtime specifici che sono stati rilasciati più di recente. Per questo motivo, in alcune sezioni di questo documento vedrai riferimenti alla build di *App Runner rivista e alla build* *originale di App Runner*. Per ulteriori informazioni, consulta [Versioni di runtime gestite e build di App Runner](service-source-code.md#service-source-code.build-detail).
# Utilizzo della piattaforma PHP di
**Importante**
App Runner terminerà il supporto per **PHP 8.1** il 31 dicembre 2025. Per consigli e ulteriori informazioni, consulta. [Fine del supporto per le versioni di runtime gestite](service-source-code.md#service-source-code.managed-platforms.eos)
La piattaforma AWS App Runner PHP fornisce runtime gestiti. Puoi utilizzare ogni runtime per creare ed eseguire contenitori con applicazioni Web basate su una versione PHP. Quando si utilizza un runtime PHP, App Runner inizia con un'immagine di runtime PHP gestita. Questa immagine è basata sull'[immagine Docker di Amazon Linux](https://hub.docker.com/_/amazonlinux) e contiene il pacchetto di runtime per una versione di PHP e alcuni strumenti. App Runner utilizza questa immagine di runtime gestita come immagine di base e aggiunge il codice dell'applicazione per creare un'immagine Docker. Quindi distribuisce questa immagine per eseguire il servizio Web in un contenitore.
Si specifica un runtime per il servizio App Runner quando si [crea un servizio](manage-create.md) utilizzando la console App Runner o l'[CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)operazione API. Puoi anche specificare un runtime come parte del codice sorgente. Usa la `runtime` parola chiave in un [file di configurazione di App Runner](config-file.md) che includi nel tuo repository di codice. La convenzione di denominazione di un runtime gestito è. **
Per i nomi e le versioni di runtime PHP validi, vedere. [Informazioni sul rilascio del runtime PHP](service-source-code-php-releases.md)
App Runner aggiorna il runtime del servizio alla versione più recente a ogni distribuzione o aggiornamento del servizio. Se l'applicazione richiede una versione specifica di un runtime gestito, è possibile specificarla utilizzando la `runtime-version` parola chiave nel file di [configurazione di App Runner](config-file.md). È possibile utilizzare qualsiasi livello di versione, inclusa una versione principale o secondaria. App Runner effettua solo aggiornamenti di livello inferiore al runtime del servizio.
Sintassi della versione per i runtime PHP: `major[.minor[.patch]]`
Ad esempio: `8.1.10`
Di seguito sono riportati alcuni esempi di blocco delle versioni:
+ `8.1`— Blocca le versioni principali e secondarie. App Runner aggiorna solo le versioni patch.
+ `8.1.10`— Blocca a una versione di patch specifica. App Runner non aggiorna la tua versione di runtime.
**Importante**
Se desideri specificare la [directory sorgente](service-source-code.md#service-source-code.source-directory) del repository di codice per il tuo servizio App Runner in una posizione diversa dalla directory principale del repository predefinita, la versione del runtime gestito da PHP deve essere PHP o successiva. `8.1.22` Le versioni di runtime PHP precedenti `8.1.22` possono utilizzare solo la directory principale dei sorgenti predefinita.
**Topics**
+ [Configurazione del runtime PHP](#service-source-code-php.config)
+ [Compatibilità](#service-source-code-php.compatibility)
+ [Esempi di runtime PHP](#service-source-code-php.examples)
+ [Informazioni sul rilascio del runtime PHP](service-source-code-php-releases.md)
## Configurazione del runtime PHP
Quando scegli un runtime gestito, devi anche configurare, come minimo, creare ed eseguire comandi. Li configuri durante la [creazione](manage-create.md) o [l'aggiornamento del](manage-configure.md) servizio App Runner. Puoi farlo utilizzando uno dei seguenti metodi:
+ **Utilizzo della console App Runner**: specifica i comandi nella sezione **Configure build** del processo di creazione o della scheda di configurazione.
+ **Utilizzo dell'API App Runner**: richiama l'operazione [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)or [UpdateService](https://docs.aws.amazon.com/apprunner/latest/api/API_UpdateService.html)API. Specificate i comandi utilizzando i `StartCommand` membri `BuildCommand` e del tipo di [CodeConfigurationValues](https://docs.aws.amazon.com/apprunner/latest/api/API_CodeConfigurationValues.html)dati.
+ **Utilizzo di un [file di configurazione](config-file.md)**: specifica uno o più comandi di compilazione in un massimo di tre fasi di compilazione e un singolo comando di esecuzione che serve per avviare l'applicazione. Sono disponibili impostazioni di configurazione opzionali aggiuntive.
Fornire un file di configurazione è facoltativo. Quando crei un servizio App Runner utilizzando la console o l'API, specifichi se App Runner ottiene le impostazioni di configurazione direttamente al momento della creazione o da un file di configurazione.
## Compatibilità
È possibile eseguire i servizi App Runner sulla piattaforma PHP utilizzando uno dei seguenti server Web:
+ Apache HTTP Server
+ NGINX
Apache HTTP Servere NGINX sono compatibili con PHP-FPM. È possibile avviare *Apache HTTP Server*e *NGINX*utilizzando uno dei seguenti:
+ [Supervisord](http://supervisord.org/introduction.html#supervisor-components/): per ulteriori informazioni sull'esecuzione di un *supervisord*, vedere [Running supervisord](http://supervisord.org/running.html#running-supervisord).
+ Script di avvio
Per esempi su come configurare il servizio App Runner con la piattaforma PHP utilizzando *Apache HTTP Server* o *NGINX*, vedi. [Fonte completa dell'applicazione PHP](#service-source-code-php.examples.end2end)
### Struttura dei file
`index.php`Deve essere installato nella `public` cartella sotto la `root` directory del server web.
**Nota**
Si consiglia di archiviare `supervisord.conf` i file `startup.sh` or nella directory principale del server Web. Assicuratevi che il `start` comando punti alla posizione in cui sono archiviati `supervisord.conf` i file `startup.sh` or.
Di seguito è riportato un esempio della struttura del file, se si utilizza *supervisord*.
```
/
├─ public/
│ ├─ index.php
├─ apprunner.yaml
├─ supervisord.conf
```
Di seguito è riportato un esempio della struttura del file se si utilizza *uno script di avvio*.
```
/
├─ public/
│ ├─ index.php
├─ apprunner.yaml
├─ startup.sh
```
Si consiglia di archiviare queste strutture di file nella [directory dei sorgenti](service-source-code.md#service-source-code.source-directory) del repository di codice designata per il servizio App Runner.
```
//
├─ public/
│ ├─ index.php
├─ apprunner.yaml
├─ startup.sh
```
**Importante**
Se desideri specificare la [directory sorgente del repository di codice per il servizio App Runner in una posizione diversa dalla directory](service-source-code.md#service-source-code.source-directory) principale del repository predefinita, la versione del runtime gestito da PHP deve essere PHP o successiva. `8.1.22` Le versioni di runtime PHP precedenti `8.1.22` possono utilizzare solo la directory principale dei sorgenti predefinita.
App Runner aggiorna il runtime del servizio alla versione più recente a ogni distribuzione o aggiornamento del servizio. Il servizio utilizzerà i runtime più recenti per impostazione predefinita, a meno che non sia stato specificato il blocco della versione utilizzando la `runtime-version` parola chiave nel file di configurazione di [App Runner](config-file.md).
## Esempi di runtime PHP
Di seguito sono riportati alcuni esempi di file di configurazione di App Runner utilizzati per creare ed eseguire un servizio PHP.
### File di configurazione PHP minimo
L'esempio seguente è un file di configurazione minimo che è possibile utilizzare con un runtime gestito da PHP. Per ulteriori informazioni su un file di configurazione minimo, vedere[Esempi di file di configurazione](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
```
### File di configurazione PHP esteso
L'esempio seguente utilizza tutte le chiavi di configurazione con un runtime gestito da PHP.
**Nota**
La versione di runtime utilizzata in questi esempi è*8.1.10*. Puoi sostituirla con una versione che desideri utilizzare. Per l'ultima versione di runtime PHP supportata, vedi[Informazioni sul rilascio del runtime PHP](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"
```
### Fonte completa dell'applicazione PHP
I seguenti esempi sono del codice sorgente di un'applicazione PHP che è possibile utilizzare per la distribuzione su un servizio di runtime PHP utilizzando o. *Apache HTTP Server*NGINX** Questi esempi presuppongono che si utilizzi la struttura di file predefinita.
#### Esecuzione della piattaforma PHP con utilizzo Apache HTTP Server supervisord
**Example Struttura dei file**
+ Il `supervisord.conf` file può essere archiviato ovunque nel repository. Assicurati che il `start` comando punti alla posizione in cui è archiviato il `supervisord.conf` file.
+ `index.php`Deve essere installato nella `public` cartella sotto la `root` directory.
```
/
├─ 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
");
?>
```
#### Esecuzione della piattaforma PHP con utilizzo Apache HTTP Server startup script
**Example Struttura dei file**
+ Il `startup.sh` file può essere archiviato ovunque nel repository. Assicurati che il `start` comando punti alla posizione in cui è archiviato il `startup.sh` file.
+ `index.php`Deve essere installato nella `public` cartella sotto la `root` directory.
```
/
├─ 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**
Assicurati di salvare il `startup.sh` file come eseguibile prima di salvarlo in un repository Git. Utilizzalo `chmod +x startup.sh` per impostare l'autorizzazione di esecuzione sul tuo `startup.sh` file.
Se non salvate il `startup.sh` file come eseguibile, `chmod +x startup.sh` immettetelo come `build` comando nel `apprunner.yaml` file.
**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
");
?>
```
#### Esecuzione della piattaforma PHP con utilizzo NGINX supervisord
**Example Struttura dei file**
+ Il `supervisord.conf` file può essere archiviato ovunque nel repository. Assicurati che il `start` comando punti alla posizione in cui è archiviato il `supervisord.conf` file.
+ `index.php`Deve essere installato nella `public` cartella sotto la `root` directory.
```
/
├─ 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
");
?>
```
#### Esecuzione della piattaforma PHP con utilizzo NGINX startup script
**Example Struttura dei file**
+ Il `startup.sh` file può essere archiviato ovunque nel repository. Assicurati che il `start` comando punti alla posizione in cui è archiviato il `startup.sh` file.
+ `index.php`Deve essere installato nella `public` cartella sotto la `root` directory.
```
/
├─ 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**
Assicurati di salvare il `startup.sh` file come eseguibile prima di salvarlo in un repository Git. Utilizzalo `chmod +x startup.sh` per impostare l'autorizzazione di esecuzione sul tuo `startup.sh` file.
Se non salvate il `startup.sh` file come eseguibile, `chmod +x startup.sh` immettetelo come `build` comando nel `apprunner.yaml` file.
**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
");
?>
```
# Informazioni sul rilascio del runtime PHP
**Importante**
App Runner terminerà il supporto per **PHP 8.1** il 31 dicembre 2025. Per consigli e ulteriori informazioni, consulta. [Fine del supporto per le versioni di runtime gestite](service-source-code.md#service-source-code.managed-platforms.eos)
Questo argomento elenca i dettagli completi per le versioni di runtime PHP supportate da App Runner.
**Versioni di runtime supportate: build originale di App Runner**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/apprunner/latest/dg/service-source-code-php-releases.html)
**Nota**
App Runner fornisce un processo di compilazione rivisto per i principali runtime specifici che sono stati rilasciati più di recente. Per questo motivo, in alcune sezioni di questo documento vedrai riferimenti alla build di *App Runner rivista e alla build* *originale di App Runner*. Per ulteriori informazioni, consulta [Versioni di runtime gestite e build di App Runner](service-source-code.md#service-source-code.build-detail).
# Utilizzo della piattaforma Ruby di
**Importante**
App Runner interromperà il supporto per **Ruby 3.1** il 1° dicembre 2025. Per consigli e ulteriori informazioni, consulta. [Fine del supporto per le versioni di runtime gestite](service-source-code.md#service-source-code.managed-platforms.eos)
La piattaforma AWS App Runner Ruby fornisce runtime gestiti. Ogni runtime semplifica la creazione e l'esecuzione di contenitori con applicazioni Web basate su una versione di Ruby. Quando si utilizza un runtime Ruby, App Runner si avvia con un'immagine di runtime Ruby gestita. Questa immagine è basata sull'[immagine Docker di Amazon Linux](https://hub.docker.com/_/amazonlinux) e contiene il pacchetto di runtime per una versione di Ruby e alcuni strumenti. App Runner utilizza questa immagine di runtime gestita come immagine di base e aggiunge il codice dell'applicazione per creare un'immagine Docker. Quindi distribuisce questa immagine per eseguire il servizio Web in un contenitore.
Si specifica un runtime per il servizio App Runner quando si [crea un servizio](manage-create.md) utilizzando la console App Runner o l'[CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)operazione API. Puoi anche specificare un runtime come parte del codice sorgente. Usa la `runtime` parola chiave in un [file di configurazione di App Runner](config-file.md) che includi nel tuo repository di codice. La convenzione di denominazione di un runtime gestito è. **
Per i nomi e le versioni di runtime di Ruby validi, vedere. [Informazioni sul rilascio del runtime di Ruby](service-source-code-ruby-releases.md)
App Runner aggiorna il runtime del servizio alla versione più recente a ogni distribuzione o aggiornamento del servizio. Se l'applicazione richiede una versione specifica di un runtime gestito, è possibile specificarla utilizzando la `runtime-version` parola chiave nel file di [configurazione di App Runner](config-file.md). È possibile utilizzare qualsiasi livello di versione, inclusa una versione principale o secondaria. App Runner effettua solo aggiornamenti di livello inferiore al runtime del servizio.
Sintassi della versione per i runtime di Ruby: `major[.minor[.patch]]`
Ad esempio: `3.1.2`
I seguenti esempi mostrano il blocco della versione:
+ `3.1`— Blocca le versioni principali e secondarie. App Runner aggiorna solo le versioni patch.
+ `3.1.2`— Blocca a una versione di patch specifica. App Runner non aggiorna la versione di runtime.
**Topics**
+ [Configurazione del runtime di Ruby](#service-source-code-ruby.config)
+ [Esempi di runtime in Ruby](#service-source-code-ruby.examples)
+ [Informazioni sul rilascio del runtime di Ruby](service-source-code-ruby-releases.md)
## Configurazione del runtime di Ruby
Quando scegli un runtime gestito, devi anche configurare, come minimo, creare ed eseguire comandi. Li configuri durante la [creazione](manage-create.md) o [l'aggiornamento del](manage-configure.md) servizio App Runner. Puoi farlo utilizzando uno dei seguenti metodi:
+ **Utilizzo della console App Runner**: specifica i comandi nella sezione **Configure build** del processo di creazione o della scheda di configurazione.
+ **Utilizzo dell'API App Runner**: richiama l'operazione [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)or [UpdateService](https://docs.aws.amazon.com/apprunner/latest/api/API_UpdateService.html)API. Specificate i comandi utilizzando i `StartCommand` membri `BuildCommand` e del tipo di [CodeConfigurationValues](https://docs.aws.amazon.com/apprunner/latest/api/API_CodeConfigurationValues.html)dati.
+ **Utilizzo di un [file di configurazione](config-file.md)**: specifica uno o più comandi di compilazione in un massimo di tre fasi di compilazione e un singolo comando di esecuzione che serve per avviare l'applicazione. Sono disponibili impostazioni di configurazione opzionali aggiuntive.
Fornire un file di configurazione è facoltativo. Quando crei un servizio App Runner utilizzando la console o l'API, specifichi se App Runner ottiene le impostazioni di configurazione direttamente al momento della creazione o da un file di configurazione.
## Esempi di runtime in Ruby
Gli esempi seguenti mostrano i file di configurazione di App Runner per la creazione e l'esecuzione di un servizio Ruby.
### File di configurazione minimo di Ruby
Questo esempio mostra un file di configurazione minimo che puoi usare con un runtime gestito da Ruby. Per le ipotesi che App Runner fa con un file di configurazione minimo, vedi. [Esempi di file di configurazione](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
```
### File di configurazione Ruby esteso
Questo esempio mostra l'uso di tutte le chiavi di configurazione con un runtime gestito da Ruby.
**Nota**
La versione di runtime utilizzata in questi esempi è*3.1.2*. Puoi sostituirla con una versione che desideri utilizzare. Per l'ultima versione di runtime di Ruby supportata, vedi[Informazioni sul rilascio del runtime di Ruby](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"
```
### Fonte completa dell'applicazione Ruby
Questi esempi mostrano il codice sorgente di un'applicazione Ruby completa che è possibile distribuire su un servizio di runtime Ruby.
**Example server.rb**
```
# server.rb
require 'sinatra'
get '/' do
'Hello World!'
end
```
**Example config.ru**
```
# config.ru
require './server'
run Sinatra::Application
```
**Example 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
```
# Informazioni sul rilascio del runtime di Ruby
**Importante**
App Runner interromperà il supporto per **Ruby 3.1** il 1° dicembre 2025. Per consigli e ulteriori informazioni, consulta. [Fine del supporto per le versioni di runtime gestite](service-source-code.md#service-source-code.managed-platforms.eos)
Questo argomento elenca i dettagli completi per le versioni di runtime di Ruby supportate da App Runner.
**Versioni di runtime supportate: build originale di App Runner**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/apprunner/latest/dg/service-source-code-ruby-releases.html)
**Nota**
App Runner fornisce un processo di compilazione rivisto per i principali runtime specifici che sono stati rilasciati più di recente. Per questo motivo, in alcune sezioni di questo documento vedrai riferimenti alla build di *App Runner rivista e alla build* *originale di App Runner*. Per ulteriori informazioni, consulta [Versioni di runtime gestite e build di App Runner](service-source-code.md#service-source-code.build-detail).
# Utilizzo della piattaforma Go di
**Importante**
App Runner interromperà il supporto per **Go 1.18** il 1° dicembre 2025. Per consigli e ulteriori informazioni, consulta. [Fine del supporto per le versioni di runtime gestite](service-source-code.md#service-source-code.managed-platforms.eos)
La piattaforma AWS App Runner Go offre tempi di esecuzione gestiti. Ogni runtime semplifica la creazione e l'esecuzione di contenitori con applicazioni Web basate su una versione Go. Quando si utilizza un runtime Go, App Runner si avvia con un'immagine di runtime Go gestita. Questa immagine è basata sull'[immagine Docker di Amazon Linux](https://hub.docker.com/_/amazonlinux) e contiene il pacchetto di runtime per una versione di Go e alcuni strumenti. App Runner utilizza questa immagine di runtime gestita come immagine di base e aggiunge il codice dell'applicazione per creare un'immagine Docker. Quindi distribuisce questa immagine per eseguire il servizio Web in un contenitore.
Si specifica un runtime per il servizio App Runner quando si [crea un servizio](manage-create.md) utilizzando la console App Runner o l'[CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)operazione API. Puoi anche specificare un runtime come parte del codice sorgente. Usa la `runtime` parola chiave in un [file di configurazione di App Runner](config-file.md) che includi nel tuo repository di codice. La convenzione di denominazione di un runtime gestito è. **
Per i nomi e le versioni di runtime Go validi, vedi[Informazioni sulla versione di Go Runtime](service-source-code-go-releases.md).
App Runner aggiorna il runtime del servizio alla versione più recente a ogni distribuzione o aggiornamento del servizio. Se l'applicazione richiede una versione specifica di un runtime gestito, è possibile specificarla utilizzando la `runtime-version` parola chiave nel file di [configurazione di App Runner](config-file.md). È possibile utilizzare qualsiasi livello di versione, inclusa una versione principale o secondaria. App Runner effettua solo aggiornamenti di livello inferiore al runtime del servizio.
Sintassi della versione per i runtime Go: `major[.minor[.patch]]`
Ad esempio: `1.18.7`
I seguenti esempi mostrano il blocco della versione:
+ `1.18`— Blocca le versioni principali e secondarie. App Runner aggiorna solo le versioni patch.
+ `1.18.7`— Blocca a una versione di patch specifica. App Runner non aggiorna la tua versione di runtime.
**Topics**
+ [Configurazione Go runtime](#service-source-code-go1.config)
+ [Esempi di runtime Go](#service-source-code-go1.examples)
+ [Informazioni sulla versione di Go Runtime](service-source-code-go-releases.md)
## Configurazione Go runtime
Quando scegli un runtime gestito, devi anche configurare, come minimo, creare ed eseguire comandi. Li configuri durante la [creazione](manage-create.md) o [l'aggiornamento del](manage-configure.md) servizio App Runner. Puoi farlo utilizzando uno dei seguenti metodi:
+ **Utilizzo della console App Runner**: specifica i comandi nella sezione **Configure build** del processo di creazione o della scheda di configurazione.
+ **Utilizzo dell'API App Runner**: richiama l'operazione [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)or [UpdateService](https://docs.aws.amazon.com/apprunner/latest/api/API_UpdateService.html)API. Specificate i comandi utilizzando i `StartCommand` membri `BuildCommand` e del tipo di [CodeConfigurationValues](https://docs.aws.amazon.com/apprunner/latest/api/API_CodeConfigurationValues.html)dati.
+ **Utilizzo di un [file di configurazione](config-file.md)**: specifica uno o più comandi di compilazione in un massimo di tre fasi di compilazione e un singolo comando di esecuzione che serve per avviare l'applicazione. Sono disponibili impostazioni di configurazione opzionali aggiuntive.
Fornire un file di configurazione è facoltativo. Quando crei un servizio App Runner utilizzando la console o l'API, specifichi se App Runner ottiene le impostazioni di configurazione direttamente al momento della creazione o da un file di configurazione.
## Esempi di runtime Go
Gli esempi seguenti mostrano i file di configurazione di App Runner per la creazione e l'esecuzione di un servizio Go.
### File di configurazione Minimal Go
Questo esempio mostra un file di configurazione minimo che è possibile utilizzare con un runtime gestito da Go. Per le ipotesi che App Runner fa con un file di configurazione minimo, vedi. [Esempi di file di configurazione](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
```
### File di configurazione Extended Go
Questo esempio mostra l'uso di tutte le chiavi di configurazione con un runtime Go gestito.
**Nota**
La versione di runtime utilizzata in questi esempi è*1.18.7*. Puoi sostituirla con una versione che desideri utilizzare. Per l'ultima versione di runtime Go supportata, consulta[Informazioni sulla versione di 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"
```
### Fonte completa dell'applicazione Go
Questi esempi mostrano il codice sorgente di un'applicazione Go completa che puoi distribuire su un servizio di runtime 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
```
# Informazioni sulla versione di Go Runtime
**Importante**
App Runner interromperà il supporto per **Go 1.18** il 1° dicembre 2025. Per consigli e ulteriori informazioni, consulta. [Fine del supporto per le versioni di runtime gestite](service-source-code.md#service-source-code.managed-platforms.eos)
Questo argomento elenca i dettagli completi per le versioni di runtime Go supportate da App Runner.
**Versioni di runtime supportate: build originale di App Runner**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/apprunner/latest/dg/service-source-code-go-releases.html)
**Nota**
App Runner fornisce un processo di compilazione rivisto per i principali runtime specifici che sono stati rilasciati più di recente. Per questo motivo, in alcune sezioni di questo documento vedrai riferimenti alla build di *App Runner rivista e alla build* *originale di App Runner*. Per ulteriori informazioni, consulta [Versioni di runtime gestite e build di App Runner](service-source-code.md#service-source-code.build-detail).