Risoluzione per il limite di memoria durante la creazione

Per informazioni sulla risoluzione, consultare Creazione non riuscita quando viene superato il limite di memoria.

Risoluzione per un problema del registro del contenitore durante la compilazione

In questo scenario, non esiste un segreto di registro per accedere al registro del contenitore o il segreto non è corretto.

1. Determinare quale segreto viene utilizzato. Utilizzare il comando ibmcloud ce build get per visualizzare il segreto di registro utilizzato.

2. Determinare se esiste una chiave .dockerconfigjson. Utilizzare il comando ibmcloud ce secret get per il segreto di registro. Nota che i dati segreti sono codificati con base64 e non direttamente visibili; tuttavia, il segreto contiene credenziali. Nell'output del comando, controllare la sezione Data. Deve contenere una chiave denominata .dockerconfigjson. Se la chiave .dockerconfigjson non viene visualizzata, questo segreto non è adatto per l'autenticazione con un registro del contenitore e devi creare un segreto corretto e fare riferimento ad esso nella build. Per ulteriori informazioni, vedi Aggiunta dell'accesso a un registro del contenitore privato.

   Output di esempio

   $ ibmcloud code-engine secret get -n <REGISTRY_SECRET>
   Getting secret <REGISTRY_SECRET>...
   OK
   
   Name:        <REGISTRY_SECRET>
   ID:          <REGISTRY_SECRET_ID>
   Project:     <PROJECT_NAME>
   Project ID:  <PROJECT_NAMESPACE>
   Age:         8s
   Created:     2021-02-12T10:26:59-06:00
   
   Data:
   ---
   .dockerconfigjson: <BASE64_STRING>
   

3. Se la chiave .dockerconfigjson esiste, decodificare la chiave, che è una stringa codificata base64 utilizzando il seguente comando,

   echo "<BASE64_STRING>" | base64 -d
   {"auths":{"<REGISTRY>":{"username":"<USERNAME>","password":"<PASSWORD>","auth":"<AUTH>"}}}
   

   L'output di questo comando generalmente contiene una chiave <REGISTRY>.

4. Confermare le seguenti informazioni sulla chiave:

   a. Esaminare il valore <REGISTRY>. Questo valore deve corrispondere all'immagine della build.

   • Se il nome dell'immagine è IBM Cloud Container Registry, ad esempio us.icr.io/aNamespace/anImage, <REGISTRY> deve essere us.icr.io.

   • Se il nome immagine è docker.io/aNamespace/aRepository o /aNamespace/aRepository senza alcun nome host, la build utilizza Docker Hub. In questo caso, <REGISTRY> deve essere https://index.docker.io/v1/.

   b. Esaminare il valore <USERNAME>. Se il registro è un IBM Cloud Container Registry, è necessario utilizzare una chiave API per l'autenticazione. <USERNAME> deve essere iamapikey e la parola d'ordine deve essere una chiave API. Vedi Automating access to IBM Cloud Container Registry per i passi per creare la chiave API.

   c. Le credenziali devono essere convalidate. IBM Cloud® Identity and Access Management (IAM) consente di assegnare le autorizzazioni in modo dettagliato. Ad esempio, un ID servizio con accesso a uno spazio dei nomi IBM Cloud Container Registry e l'autorizzazione a eseguire il pull delle immagini potrebbe non essere consentita per il push delle immagini. Ma, questa autorizzazione è ciò che è necessario in questo caso.

5. Dopo aver determinato le modifiche necessarie, crea un segreto del registro del contenitore che utilizza i valori corretti. Utilizzare il comando ibmcloud ce secret create --format ; ad esempio,

   ibmcloud ce secret create --format registry --name <REGISTRY_SECRET> --server <REGISTRY_SERVER> --username <USERNAME> --password <PASSWORD>
   

6. Aggiornare la build in modo che faccia riferimento al nome del segreto di registro.

   a. Utilizzare il comando ibmcloud ce build update per aggiornare la configurazione di build in modo da utilizzare il nome del segreto di registro; ad esempio,

   ibmcloud ce build update --name <BUILD_NAME> --registry-secret <REGISTRY_SECRET>
   

   b. Utilizzare il comando ibmcloud ce buildrun submit per inoltrare una nuova esecuzione di build. Per il comando buildrun submit, è necessario specificare l'opzione --build per fornire il nome della configurazione della build. Facoltativamente, è possibile specificare l'opzione --name per fornire il nome per questa esecuzione di build. Se si specifica l'opzione --name, assicurarsi di utilizzare un nome di esecuzione build diverso da quello dell'esecuzione build non riuscita oppure assicurarsi di eliminare l'esecuzione build non riuscita utilizzando il comando ibmcloud ce buildrun delete. Ad esempio,

   ibmcloud ce buildrun submit --build <BUILD_NAME> --name <BUILDRUN_NAME>
   

Risoluzione per Dockerfile non trovata durante la build

Una build Docker richiede un Dockerfile che specifica come deve essere creata l'immagine contenitore. Se il repository di origine non contiene un file di questo tipo, devi fornire questo file o considerare i pacchetti di build come una strategia di build. Per ulteriori informazioni, vedi Pianificazione della tua build.

1. Se il Dockerfile esiste, ma ha un nome diverso o non si trova nella directory root, è necessario specificare ulteriori impostazioni nella build.

   • Se il Dockerfile non si trova nella directory root del repository di origine, è necessario specificare l'argomento --context-dir e fornire il percorso alla directory che contiene il Dockerfile.
   • Se il Dockerfile ha un nome diverso da Dockerfile, devi specificare l'argomento --dockerfile e fornire il nome del tuo Dockerfile.

2. Aggiornare la build per utilizzare le opzioni --context-dir o --dockerfile come necessario.

   a. Utilizzare il comando ibmcloud ce build update per aggiornare la configurazione di build in modo da utilizzare le opzioni --context-dir o --dockerfile in base alle esigenze; ad esempio,

   ibmcloud ce build update --name <BUILD_NAME> [--context-dir <CONTEXT_DIR>] [--dockerfile <DOCKERFILE_NAME>]
   

   b. Utilizzare il comando ibmcloud ce buildrun submit per inoltrare una nuova esecuzione di build. Per il comando buildrun submit, è necessario specificare l'opzione --build per fornire il nome della configurazione della build. Facoltativamente, è possibile specificare l'opzione --name per fornire il nome per questa esecuzione di build. Se si specifica l'opzione --name, assicurarsi di utilizzare un nome di esecuzione build diverso da quello dell'esecuzione build non riuscita oppure assicurarsi di eliminare l'esecuzione build non riuscita utilizzando il comando ibmcloud ce buildrun delete. Ad esempio,

   ibmcloud ce buildrun submit --build <BUILD_NAME> --name <BUILDRUN_NAME>
   

Risoluzione per il limite di quota IBM Cloud Container Registry raggiunto durante la creazione

IBM Cloud Container Registry ha due piani di servizio, un piano gratuito e uno standard. Per il piano gratuito, IBM Cloud Container Registry applica limiti rigorosi, specialmente sulla dimensione dell'immagine che può essere memorizzata in totale (500 MB). Per il piano standard, è possibile configurare le quote. Per ulteriori informazioni, vedi Informazioni su IBM Cloud Container Registry.

1. Esegui una delle seguenti azioni:

   • Elimina le immagini inutilizzate dallo spazio dei nomi IBM Cloud Container Registry per aumentare lo spazio disponibile.
   • Eseguire l'upgrade dal piano gratuito al piano standard.
   • Aumentare le quote dello spazio dei nomi IBM Cloud Container Registry.

   L'immagine URL è inclusa nel messaggio di errore per aiutare a identificare lo spazio dei nomi IBM Cloud Container Registry interessato. Lo spazio dei nomi può trovarsi in un account IBM Cloud diverso dal progetto IBM Cloud Code Engine.

2. Dopo aver completato le azioni correttive, utilizzare il comando ibmcloud ce buildrun submit per inoltrare una nuova esecuzione di build. Per il comando buildrun submit, è necessario specificare l'opzione --build per fornire il nome della configurazione della build. Facoltativamente, è possibile specificare l'opzione --name per fornire il nome per questa esecuzione di build. Se si specifica l'opzione --name, assicurarsi di utilizzare un nome di esecuzione build diverso da quello dell'esecuzione build non riuscita oppure assicurarsi di eliminare l'esecuzione build non riuscita utilizzando il comando ibmcloud ce buildrun delete. Ad esempio,

   ibmcloud ce buildrun submit --build <BUILD_NAME> --name <BUILDRUN_NAME>
   

Risoluzione per l'origine build non specificata correttamente

Il motivo tipico per cui si verifica questo errore è che l'origine build non si trova nella directory root del repository Git, ma in una directory child. Se l'origine di build non risiede nella directory root, specificare l'ubicazione nella build.

1. Utilizzare il comando di ibmcloud ce build update per aggiornare la configurazione di build in modo da utilizzare l'opzione --context-dir per specificare il percorso dell'origine nel repository Git ; ad esempio,

   ibmcloud ce build update --name <BUILD_NAME> --context-dir <CONTEXT_DIR>
   

2. Utilizzare il comando ibmcloud ce buildrun submit per inoltrare una nuova esecuzione di build. Per il comando buildrun submit, è necessario specificare l'opzione --build per fornire il nome della configurazione della build. Facoltativamente, è possibile specificare l'opzione --name per fornire il nome per questa esecuzione di build. Se si specifica l'opzione --name, assicurarsi di utilizzare un nome di esecuzione build diverso da quello dell'esecuzione build non riuscita oppure assicurarsi di eliminare l'esecuzione build non riuscita utilizzando il comando ibmcloud ce buildrun delete. Ad esempio,

   ibmcloud ce buildrun submit --build <BUILD_NAME> --name <BUILDRUN_NAME>
   

Risoluzione di un problema dovuto a limiti di frequenza hub Docker

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). Potresti riscontrare dei limiti di pull se ricevi un errore 429 che indica che hai raggiunto il tuo limite di frequenza di pull. Se si riceve questo errore, provare una delle seguenti soluzioni.

• Aumentare i limiti di velocità. Puoi autenticarti con Docker Hub o aggiornare il tuo account a una sottoscrizione Docker Pro o Team, se necessario.

• Esegui il pull dell'immagine generata da Docker Hub e pubblica l'immagine in un registro differente, come IBM Cloud® Container Registry. Quindi, estrai la tua immagine dalla nuova posizione. Code Engine supporta il riferimento a un singolo segreto. Se l'immagine di base per la tua build Dockerfile viene estratta da un registro diverso da quello in cui viene pubblicata l'immagine generata risultante ed entrambi i registri richiedono l'autenticazione, puoi utilizzare kubectl per creare un segreto Kubernetes di tipo kubernetes.io/dockerconfigjson che contiene credenziali per entrambi i registri. Per informazioni sull'utilizzo delle credenziali di accesso per entrambi i registri, vedi la documentazione di Kubernetes sul pull di un'immagine da un repository privato.

Risoluzione per l'origine di build non supportata dai pacchetti di build

Per controllare se il tuo repository di origini di build è supportato in Code Engine, vedi Scegli una strategia di build per i runtime supportati. Se la tua lingua è elencata, controlla gli esempi collegati e assicurati di strutturare correttamente le tue origini in modo che i pacchetti di build possano rilevarli e crearli correttamente. Se non riesci a trovare un pacchetto di build adatto per la tua origine o il modo standardizzato su come i pacchetti di build vengono eseguiti, la build non soddisfa le tue necessità, puoi specificare un Dockerfile, descrivere manualmente la build del contenitore nel Dockerfile e quindi passare all'utilizzo della strategia di build dockerfile nella configurazione della build.

Risoluzione di un problema con il build Docker

Se il problema di errore del passo di creazione e di push non è un problema con la memoria, un segreto del registro del contenitore o un Dockerfile, è probabile che il problema si verifichi con la build Docker. Il problema potrebbe essere un errore nel Dockerfile stesso, ad esempio, un errore di sintassi o la correttezza dell'operazione che esegue. Il problema può essere dovuto anche al codice sorgente, che potrebbe non essere compilato, ad esempio, se è incluso il codice Java®.

Se hai creato correttamente il tuo progetto localmente, ma lo stesso codice sorgente non viene creato in Code Engine, potresti avere dei file disponibili localmente che non si trovano nel tuo repository Git. Ad esempio, per progetti Node.js, è comune eseguire il comando npm install localmente in modo che le dipendenze del progetto vengano scaricate e inserite nella directory node_modules all'interno della directory del progetto. Si consiglia di includere la directory node_modules nel file .gitignore per mantenere piccolo il tuo repository Git. Un errore comune è dimenticare di eseguire anche npm install (o npm ci) nel Dockerfile. Una build Docker che esegui in locale può accedere alla directory node_modules locale, se copi l'intero progetto nel contenitore, ad esempio utilizzando il comando COPY . /app in Dockerfile. Ma, la build Code Engine viene eseguita dal repository Git appena estratto e non può accedere alla directory node_modules. Pertanto, devi eseguire npm install (o npm ci) nel Dockerfile come parte della build.

Una buona pratica è includere le directory come node_modules anche in un file .dockerignore in modo che la build Docker che esegui in locale si comporti come la build Code Engine.

Un altro motivo per cui un progetto deve essere creato correttamente localmente ma non riesce come build Code Engine sono le limitazioni di sicurezza. Come con le applicazioni e i lavori batch, Code Engine non consente operazioni di sistema arbitrarie nel cluster Code Engine. La maggior parte di queste operazioni di sistema non sono comunque rilevanti per le build Docker. Tuttavia, Code Engine non consente l'apertura dei socket server per le porte privilegiate. La gamma è 0 to 1023. Ad esempio, se si crea un'applicazione Web e la build include un passo di test che richiama un server delle applicazioni Web, è necessario utilizzare porte con numeri più elevati per questo server.