AWS App Runner non è più aperto a nuovi clienti. 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 dicembre 2025 |
| PHP 8.1 \* | 31 dicembre 2025 |
| Ruby 3.1 \* | 1 dicembre 2025 |
| Vai 1 \* | 1 dicembre 2025 |
**\*** App Runner non rilascerà alcuna nuova versione in lingua per i runtime contrassegnati da un asterisco (\*). 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.
- ** Python – [Informazioni sul rilascio](service-source-code-python-releases.md) **
- ****Versioni di runtime**:** Python 3.11 (\!) / ****Processo di compilazione**:** Revisionato / ****Data di fine del supporto per App Runner**:**
- ****Versioni di runtime**:** Python 3.8 / ****Processo di compilazione**:** Originale / ****Data di fine del supporto per App Runner**:** 1 dicembre 2025
- ****Versioni di runtime**:** Python 3.7 / ****Processo di compilazione**:** Originale / ****Data di fine del supporto per App Runner**:** 1 dicembre 2025
- ** Node.js: [Informazioni sulla versione](service-source-code-nodejs-releases.md) **
- ****Versioni di runtime**:** Node.js 22 / ****Processo di compilazione**:** Revisionato / ****Data di fine del supporto per App Runner**:**
- ****Versioni di runtime**:** Node.js 18 / ****Processo di compilazione**:** Revisionato / ****Data di fine del supporto per App Runner**:** 1 dicembre 2025
- ****Versioni di runtime**:** Node.js 16 / ****Processo di compilazione**:** Originale / ****Data di fine del supporto per App Runner**:** 1 dicembre 2025
- ****Versioni di runtime**:** Node.js 14 / ****Processo di compilazione**:** Originale / ****Data di fine del supporto per App Runner**:** 1 dicembre 2025
- ****Versioni di runtime**:** Node.js 12 / ****Processo di compilazione**:** Originale / ****Data di fine del supporto per App Runner**:** 1 dicembre 2025
- ** Corretto — [Informazioni sul rilascio](service-source-code-java-releases.md) **
- ****Versioni di runtime**:** Corretto 11 / ****Processo di compilazione**:** Originale / ****Data di fine del supporto per App Runner**:**
- ****Versioni di runtime**:** Corretto 8 / ****Processo di compilazione**:** Originale / ****Data di fine del supporto per App Runner**:**
- ** .NET: [Informazioni sul rilascio](service-source-code-dotnet-releases.md) **
- ****Versioni di runtime**:** .NET 6\*
- ****Processo di compilazione**:** Originale
- ****Data di fine del supporto per App Runner**:** 1 dicembre 2025
- ** PHP: [Informazioni sul rilascio](service-source-code-php-releases.md) **
- ****Versioni di runtime**:** PHP 8.1 \*
- ****Processo di compilazione**:** Originale
- ****Data di fine del supporto per App Runner**:** 31 dicembre 2025
- ** Ruby: [Informazioni sul rilascio](service-source-code-ruby-releases.md) **
- ****Versioni di runtime**:** Ruby 3.1 \*
- ****Processo di compilazione**:** Originale
- ****Data di fine del supporto per App Runner**:** 1 dicembre 2025
- ** Go: [Informazioni sulla versione](service-source-code-go-releases.md) **
- ****Versioni di runtime**:** Vai 1 \*
- ****Processo di compilazione**:** Originale
- ****Data di fine del supporto per App Runner**:** 1 dicembre 2025
**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.