Questa pagina spiega come utilizzare Cloud Build per creare e testare applicazioni Node.js
, archiviare gli artefatti creati in un repository npm in Artifact Registry e generare informazioni sulla provenienza delle build.
Cloud Build ti consente di utilizzare qualsiasi immagine container disponibile pubblicamente
per eseguire le tue attività. L'immagine node
pubblica da Docker Hub è preinstallata con lo strumento npm
. Puoi configurare Cloud Build
per creare il tuo progetto Node.js
con questo strumento.
Prima di iniziare
Le istruzioni in questa pagina presuppongono che tu conosca Node.js
. Inoltre:
- Conosci npm.
- Tieni a portata di mano il tuo progetto
Node.js
, inclusi i filepackage.json
etest.js
. - Assicurati che il file
package.json
includa uno scriptstart
e unotest
. - Conosci come scrivere un file di configurazione di Cloud Build.
- Avere un repository npm in Artifact Registry. Se non ne hai uno, creane uno nuovo.
- Per eseguire i comandi
gcloud
in questa pagina, installa Google Cloud CLI.
Edificio con npm
Per eseguire le attività nell'immagine node
da Docker Hub, specifica l'URL immagine nel campo name
del file di configurazione di Cloud Build.
Cloud Build avvia il container specificato nel campo name
utilizzando il punto di ingresso predefinito dell'immagine. Per eseguire l'override del punto di ingresso predefinito e definire la modalità di esecuzione del passaggio di build quando viene richiamato, aggiungi un campo entrypoint
nel passaggio della build. L'immagine node
in Docker Hub è preinstallata con lo strumento npm
. Specifica gli strumenti nel campo entrypoint
per richiamarli come punto di ingresso del passaggio di build.
Nel seguente esempio di file di configurazione della build:
- Il campo
name
specifica che l'immaginenode
di Docker Hub viene utilizzata da Cloud Build per eseguire l'attività. Quando specifichi l'immaginenode
, puoi omettere la versione del nodo in modo che sia:latest
per impostazione predefinita, oppure specificare una versione del nodo per utilizzare una versione specifica. Ad esempio,name: node
utilizzerà la versione più recente del nodo ename: node:12
utilizzerànode:12
. Il campo
entrypoint
specifica che lo strumentonpm
viene utilizzato quando viene richiamata l'immaginenode
.steps: - name: 'node' entrypoint: 'npm'
Configurazione di Node.js
build in corso...
Nella directory principale del progetto, crea un file di configurazione denominato
cloudbuild.yaml
.Installa le dipendenze: prima di poter creare l'applicazione, devi assicurarti che tutte le dipendenze del progetto siano installate da
npm
. Puoi installare le dipendenze utilizzando il comandoinstall
all'interno del passaggio di buildnpm
. Il campoargs
di un passaggio di build prende un elenco di argomenti e li passa all'immagine a cui fa riferimento il campo del nome. Nel file di configurazione della build, aggiungiinstall
al campoargs
per richiamare il comandoinstall
:steps: - name: 'node' entrypoint: 'npm' args: ['install']
Aggiungi test: se hai definito uno script
test
inpackage.json
, puoi configurare Cloud Build per l'esecuzione dello script aggiungendotest
al campoargs
:steps: - name: 'node' entrypoint: 'npm' args: ['install'] - name: 'node' entrypoint: 'npm' args: ['test']
Esegui comandi personalizzati: se
package.json
contiene comandi personalizzati, puoi configurare Cloud Build per eseguirlo. Nel campoargs
, aggiungirun
come primo argomento seguito dal nome del comando personalizzato. Il seguente file di configurazione di compilazione contiene argomenti per eseguire un comando personalizzato chiamatobuild
:steps: - name: 'node' entrypoint: 'npm' args: ['install'] - name: 'node' entrypoint: 'npm' args: ['test'] - name: 'node' entrypoint: 'npm' args: ['run', 'build']
Carica su Artifact Registry:
Cloud Build genera Supply chain Levels for Software Artifacts (SLSA) per creare informazioni sulla provenienza dei pacchetti npm autonomi quando li carichi in Artifact Registry utilizzando il campo
npmPackages
nel file di configurazione di Cloud Build.Nel file di configurazione, aggiungi il campo
npmPackages
e specifica il tuo repository npm in Artifact Registry:artifacts: npmPackages: - repository: 'https://LOCATION-npm.pkg.dev/PROJECT-ID/REPOSITORY_NAME' packagePath: 'PACKAGE_PATH'
Sostituisci i seguenti valori:
- LOCATION: la località per il repository in Artifact Registry.
- PROJECT_ID: l'ID del progetto Google Cloud che contiene il repository Artifact Registry.
- REPOSITORY_NAME: il nome del repository npm in Artifact Registry.
- PACKAGE_PATH: il percorso della directory locale contenente il pacchetto npm da caricare in Artifact Registry. Ti
consigliamo di utilizzare un percorso assoluto. Il valore
PACKAGE_PATH
può essere.
per utilizzare la directory di lavoro corrente, ma il campo non può essere omesso o lasciato vuoto. Questa directory deve contenere un filepackage.json
.
(Facoltativo) Attiva la provenienza per le build a livello di regione
Se utilizzi una build a livello di regione, aggiungi il campo
requestedVerifyOption
inoptions
del file di configurazione della build. Imposta il valore suVERIFIED
per attivare la generazione dei metadati di provenienza. Se non aggiungirequestedVerifyOption: VERIFIED
, Cloud Build genera la provenienza solo per le build globali.options: requestedVerifyOption: VERIFIED
Avvia la build: manualmente o utilizzando i trigger di build.
Una volta completata la build, puoi visualizzare i dettagli del repository in Artifact Registry.
Per proteggere la catena di fornitura del software, puoi anche visualizzare i metadati di provenienza della build e convalidare la provenienza.
Esecuzione di test su più versioni di node
A volte è necessario assicurarsi che il progetto funzioni su più versioni di node
. Puoi creare e configurare i trigger di Cloud Build in modo che:
- Nel file di configurazione della build, specifica la versione
node
come variabile di sostituzione. - Crea un trigger per ogni versione di
node
rispetto alla quale vuoi creare l'applicazione. - In ciascuna delle impostazioni dell'attivatore, utilizza il campo del valore della variabile di sostituzione per
indicare la versione di
node
per l'attivatore.
I passaggi seguenti spiegano come specificare la versione node
utilizzando variabili di sostituzione specifiche del trigger:
Nella radice del repository, aggiungi un file di configurazione della build che specifica la versione
node
come variabile di sostituzione. Nel seguente file di configurazione della build di esempio,$_NODE_VERSION
è una variabile di sostituzione definita dall'utente:steps: - name: 'node:$_NODE_VERSION' entrypoint: 'npm' args: ['install'] - name: 'node:$_NODE_VERSION' entrypoint: 'npm' args: ['test']
Per ogni versione di
node
su cui vuoi eseguire la build, crea un trigger di build seguendo questi passaggi:Apri la pagina Attivatori nella console Google Cloud:
Seleziona il progetto dal menu a discesa del selettore di progetti nella parte superiore della pagina.
Fai clic su Apri.
Fai clic su Crea trigger.
Nella pagina Crea trigger, inserisci le seguenti impostazioni:
Inserisci un nome per l'attivatore.
Seleziona l'evento del repository per avviare il trigger.
Seleziona il repository che contiene il codice sorgente e il file di configurazione della build.
Specifica la regex per il nome del ramo o del tag che avvierà l'attivatore.
Configurazione: scegli il file di configurazione della build creato in precedenza.
In Variabili di sostituzione, fai clic su Aggiungi variabile.
- In Variabile, specifica la variabile di versione
node
utilizzata nel file di configurazione della build, mentre in Valore specifica la versione dinode
. Ad esempio,_NODE_VERSION
e12
.
- In Variabile, specifica la variabile di versione
Fai clic su Crea per salvare il trigger di build.
Puoi utilizzare questi trigger per creare il tuo codice sulla versione di node
specificata nel trigger.
Passaggi successivi
- Scopri come visualizzare i risultati della build.
- Scopri come salvaguardare le build.
- Scopri come creare immagini container.
- Scopri come creare applicazioni Go.
- Scopri come eseguire deployment blu/verde su Compute Engine.
- Scopri come risolvere gli errori di generazione.