Pianificazione della costruzione

Prima di iniziare a costruire immagini con IBM Cloud® Code Engine, imparate a conoscere le diverse opzioni disponibili per la vostra costruzione.

Una compilazione, o compilazione dell'immagine, è un meccanismo che si può usare per creare un'immagine del contenitore dal codice sorgente. Code Engine supporta la compilazione da un file Docker e Cloud Native Buildpacks.

Se si dispone di un'immagine esistente in un registro di container e l'immagine è stata creata con un processore non basato su Intel, Code Engine non può eseguire l'immagine del container. Code Engine utilizza l'elaborazione basata su Intel. È possibile creare la propria immagine se si utilizza l'elaborazione Intel (processore x86 ). Potete anche scegliere di lasciare che sia Code Engine a gestire il processo di costruzione per voi.

Code Engine fornisce metodi di definizione delle risorse personalizzate (CRD). Per ulteriori informazioni, vedere Metodi CRD da sorgente a immagine.

Preparare la posizione di partenza

Per consentire a Code Engine di accedere al codice sorgente, è necessario renderlo disponibile in un repository Git o in una posizione accessibile sulla propria stazione di lavoro locale.

repository Git
Memorizzare il codice in un repository Git, ad esempio in GitHub o GitLab. Il codice può trovarsi al livello superiore del repository o in una sottodirectory. Se il repository dei sorgenti non è pubblico, è necessario aggiungere l'accesso a Code Engine.
Stazione di lavoro locale
Memorizzate il codice sulla vostra postazione di lavoro locale. Quando si invia una build che preleva il codice da una directory locale, il codice sorgente viene impacchettato in un file di archivio e caricato nell'istanza IBM Cloud Container Registry. L'immagine sorgente viene creata nello stesso spazio dei nomi dell'immagine di build. Si noti che si può puntare solo su IBM Cloud Container Registry per le build locali. È possibile scegliere di ignorare alcuni modelli di file all'interno del codice sorgente utilizzando il file .ceignore, che si comporta in modo simile al file .gitignore. Ad esempio, le voci di un file .ceignore per un'applicazione node.js potrebbero includere node_modules e .npm. Per altri modelli di file da ignorare, vedere il repository GitHub.gitignore.

Scegliere una strategia di costruzione

Code Engine può costruire l'immagine del contenitore utilizzando una delle seguenti strategie.

Dockerfile

Compilazione del file Docker che utilizza lo strumento BuildKit strumento. Per utilizzare questa strategia, aggiungere un file Docker al proprio repository sorgente. Questo file Docker descrive i passaggi necessari per creare un'immagine del contenitore dal repository di origine. Il file Docker potrebbe contenere dei passaggi che copiano i file statici dalle sorgenti nel contenitore che sarà ospitato da un servizio web, ad esempio. Potrebbe compilare il codice sorgente scritto nel linguaggio di vostra scelta e aggiungere il binario risultante all'immagine del vostro contenitore. Per ulteriori informazioni sulla compilazione dei file Docker, vedere Scrittura di un file Docker per Code Engine.

Quando si estrae un'immagine da Docker Hub per utilizzarla con le applicazioni o i lavori in Code Engine, tenere presente i limiti tariffari di Docker per gli utenti del piano gratuito (non autenticati). È possibile che si verifichino dei limiti di estrazione se si riceve un errore 429 che indica che si è raggiunto il limite della velocità di estrazione. Per aumentare i limiti tariffari, è possibile aggiornare il proprio account a un abbonamento Docker Pro o Team.

Cloud Native Buildpacks

Cloud Native Buildpack che utilizza Paketo per ispezionare il repository dei sorgenti e rilevare l'ambiente di runtime su cui si basa il codice e come viene costruita un'immagine del contenitore dai sorgenti. I buildpack fanno delle ipotesi sulla struttura delle directory dei repository dei sorgenti. Per ulteriori informazioni su come strutturare correttamente il repository dei sorgenti, consultare gli esempi forniti per il runtime.

File di esempio del runtime
Runtime Versione Esempi
Vai 1.24.12 Vai ai campioni.
Java 21.0.10 Java campioni.
Node.js 24.14.0 Node.js campioni.
PHP 8.1.28 Esempi di PHP.
Python 3.11.14 Python campioni.
Ruby 3.1.7 Ruby campioni.
.NET Core 9.0.311 (.NET Core SDK),
9.0.13 (.NET Core Runtime)
.NET Core campioni.

Le immagini create con Cloud Native Buildpacks non usano più il timestamp neutro di Jan, 1st 1980 come timestamp di creazione dell'immagine. Il timestamp della sorgente di input viene usato come timestamp di creazione dell'immagine; per esempio, il timestamp del commit di Git usato per la compilazione.

La versione di un runtime specifico per un buildpack di Paketo potrebbe differire da una regione all'altra per un breve periodo ogni volta che una versione aggiornata di un buildpack viene distribuita alle varie regioni di IBM Cloud.

Determinare le dimensioni dell'edificio

Code Engine classifica gli edifici in small, medium, large, xlarge e xxlarge. La dimensione della build definisce il modo in cui i core della CPU, la memoria e lo spazio su disco vengono assegnati alla build. Una struttura più piccola è meno costosa, ma in genere anche più lenta perché utilizza meno core della CPU. Inoltre, i requisiti di memoria e di disco della compilazione potrebbero far fallire la compilazione con una dimensione inferiore.

Valori delle dimensioni di costruzione.
Dimensione Dockerfile Pacchetti di build
small
  • CPU 0.5
  • Memoria 2 GB
  • Disco 2 GB
  • CPU 0.5
  • Memoria 2 GB
  • Disco 2 GB
medium
  • CPU 1
  • Memoria 4 GB
  • Disco 4 GB
  • CPU 1
  • Memoria 4 GB
  • Disco 4 GB
large
  • CPU 2
  • Memoria 8 GB
  • Disco 8 GB
  • CPU 2
  • Memoria 8 GB
  • Disco 8 GB
xlarge
  • CPU 4
  • Memoria 16 GB
  • Disco 16 GB
  • CPU 4
  • Memoria 16 GB
  • Disco 16 GB
xxlarge
  • CPU 12
  • Memoria 48 GB
  • Disco 48 GB
  • CPU 12
  • Memoria 48 GB
  • Disco 48 GB

Se siete incerti sulla taglia da scegliere, considerate di iniziare con small o medium. Se la creazione non riesce a causa della mancanza di memoria o di spazio su disco, o non è abbastanza veloce, passare a dimensioni maggiori.

Scegliere il registro dell'immagine del contenitore

Code Engine preleva il codice sorgente da un repository Git o da una cartella locale, lo costruisce e quindi invia (carica) l'immagine a un registro di immagini del contenitore.

Si possono usare repository per i sorgenti e registri per l'immagine del contenitore, pubblici o privati. Si può anche scegliere di specificare i dettagli del registro con un segreto di registro per l'output della compilazione, oppure si può scegliere che Code Engine si occupi di creare l'immagine per voi dal vostro sorgente e di memorizzare l'immagine in IBM Cloud Container Registry con accesso automatico.

Scegliere il metodo di costruzione

Nelle seguenti opzioni di compilazione, Code Engine preleva il codice sorgente da un repository Git o da una directory locale, costruisce l'immagine del contenitore e quindi esegue il push (caricamento) dell'immagine del contenitore in un registro. È possibile scegliere tra archivi e registri pubblici o privati. Se il registro è privato, specificare i dettagli del registro con un segreto di registro per l'output di compilazione con accesso fornito dall'utente. Oppure, potete scegliere che Code Engine crei un accesso per memorizzare l'immagine in IBM Cloud Container Registry per voi con accesso automatico.

Creare configurazioni di build

In questo scenario, Code Engine crea una configurazione per la propria build.

La creazione di una configurazione di build non crea un'immagine, ma crea la configurazione per creare un'immagine. È possibile creare un'immagine dalla configurazione eseguendo la compilazione. La configurazione della build non viene convalidata o usata per creare un'immagine finché non viene eseguita la build. La configurazione di build consente di eseguire più build successive di un'immagine, ad esempio quando vengono applicate modifiche al repository di origine.

Per ulteriori informazioni, consulta i seguenti argomenti.

Dopo aver creato la configurazione di build, è possibile eseguirla.

Creare l'immagine del contenitore con comandi di compilazione stand-alone

Per sapere come costruire l'immagine del contenitore con un singolo comando della CLI Code Engine e creare l'immagine del contenitore senza creare una configurazione di build riutilizzabile, vedere Costruzione di un'immagine del contenitore con comandi di build autonomi(CLI).

Costruire il codice e creare il carico di lavoro

Quando si crea un carico di lavoro dal codice sorgente locale, il codice sorgente viene racchiuso in un file di archivio e caricato in uno spazio dei nomi gestito all'interno dell'istanza IBM Cloud Container Registry del proprio account. Anche l'immagine viene memorizzata in questo stesso spazio dei nomi.

Per costruire il codice e creare il carico di lavoro con una sola operazione, vedere i seguenti argomenti.

repository Git
File locale

I prossimi passi per le costruzioni

Cercate altri esempi di codice? Consultate la repo Samples for IBM Cloud Code Engine GitHub.