Servizio App Runner basato su codice sorgente - AWS App Runner
Fornitori di repository di codice sorgenteDirectory dei sorgentiPiattaforme gestite da App RunnerVersioni di runtime gestite e build di App Runner

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 funzionalità CI/CD 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, vedereServizio App Runner basato su un'immagine sorgente.

Il codice sorgente è il codice applicativo che App Runner crea e distribuisce per te. Indirizzi App Runner a una directory sorgente 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.

Argomenti

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

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, 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 CreateConnectionAPI. Quindi, fornisci l'ARN della connessione durante la creazione del servizio utilizzando l'azione CreateServiceAPI.

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 CreateServicee UpdateServiceAPI. Per ulteriori informazioni, consultare la sezione seguente Directory dei sorgenti.

Per ulteriori informazioni sulla creazione del servizio App Runner, consulta. Creazione di un servizio App Runner Per ulteriori informazioni sulle connessioni App Runner, vedere. Gestione delle connessioni App Runner

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

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 .

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 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 utilizzando la console App Runner o l'CreateServiceoperazione API. Puoi anche specificare un runtime come parte del codice sorgente. Usa la runtime parola chiave in un file di configurazione di App Runner che includi nel tuo repository di codice. La convenzione di denominazione di un runtime gestito è. <language-name><major-version>

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. È possibile utilizzare qualsiasi livello di versione, inclusa una versione principale o secondaria. App Runner effettua solo aggiornamenti di livello inferiore al runtime del servizio.

Versioni di runtime gestite e build di App Runner

App Runner ora offre un processo di compilazione aggiornato per le tue applicazioni. Attualmente richiama la nuova build per i servizi eseguiti su runtime gestiti Python 3.11 e Node.js 18, rilasciati l'ultima volta il 29 dicembre 2023. 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. 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.

Platform (Piattaforma) Build originale Costruzione rivista

Python – Informazioni sul rilascio

  • Python 3.8

  • Python 3.7

  • Python 3.11 (!)

Node.js: Informazioni sulla versione

  • Node.js 16

  • Node.js 14

  • Node.js 12

  • Node.js 18

Corretto — Informazioni sul rilascio

  • Corretto 11

  • Corretto 8

.NET: Informazioni sul rilascio

  • .NET 6

PHP: Informazioni sul rilascio

  • PHP 8.1

Ruby: Informazioni sul rilascio

  • Ruby 3.1

Go: Informazioni sulla versione

  • Go 1
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 specificheargomento 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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.

    2. Tramite i comandi pre-build.

      I pre-build comandi sono opzionali. Possono essere specificati solo nel file apprunner.yaml di configurazione.

    3. 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.

  2. Fase di imballaggio: 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.

    2. 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.

  3. 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 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 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-buildbuild, 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.

Esecuzione dei build comandi due volte

  • La build originale di App Runner 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 compilazione.