Risoluzione dei problemi per Delivery Pipeline

I problemi generali legati all'utilizzo di Delivery Pipeline possono includere problemi relativi alla creazione di pipeline o alla configurazione dell'integrazione degli strumenti. In molti casi, puoi risolvere questi problemi seguendo pochi semplici passi.

Ho creato una toolchain e il servizio Delivery Pipeline non viene inizializzato. Perché l'inizializzazione della pipeline non viene completata?

Potresti dover configurare e salvare nuovamente l'integrazione dello strumento GitHub.

L'integrazione dello strumento GitHub all'interno della tua toolchain potrebbe essere configurata in modo errato e questo sta impedendo il completamento dell'inizializzazione della pipeline.

Si è verificato un problema di creazione eventi che ha causato il malfunzionamento dell'integrazione dello strumento GitHub.

Configura e salva nuovamente l'integrazione dello strumento GitHub:

  1. Dalla console IBM Cloud, fare clic sull'icona del menu Hamburger > Automazione piattaforma > Toolchains. Nella pagina Toolchains, fai clic sulla toolchain che hai creato per aprire la pagina di panoramica. In alternativa, nella pagina App Details nella tua applicazione, fai clic sul nome della toolchain.
  2. Nella pagina della panoramica della toolchain, sulla scheda Repository, individua l'integrazione dello strumento GitHub.
  3. Fare clic sul menu per accedere alle opzioni di configurazione, aggiornare le impostazioni e fare clic su Salva integrazione.
  4. Nella scheda Delivery pipelines, fai clic sull'integrazione dello strumento Delivery Pipeline per visualizzare la configurazione della pipeline.

Perché la pipeline non viene creata correttamente quando creo una toolchain dal template che sto scrivendo?

Alla tua pipeline potrebbero mancare risorse quali i lavori e le fasi a causa di un errore nella tua definizione pipeline.yaml.

Quando provo a creare una toolchain da un template che sto scrivendo, ricevo il seguente messaggio di errore nella pagina Pipeline.

This pipeline was created, but might be missing jobs, stages, or other resources. You can use this pipeline, or if you prefer, you can delete it and create another pipeline.

Di norma, questo problema è causato da un errore nella tua definizione pipeline.yaml.

Puoi utilizzare uno qualsiasi dei seguenti metodi per eseguire il debug di questo errore:

  • Utilizza l'interfaccia utente della pipeline per creare una pipeline di esempio che replica la pipeline che stai provando a creare con il tuo template. Accoda /yaml all'URL della pipeline per generare un file pipeline.yaml simile che puoi utilizzare per cercare le ovvie differenze. Ad esempio, https://cloud.ibm.com/devops/pipelines/<your pipeline id>/yaml?env_id=<your region>.

  • Utilizza il meccanismo di creazione della toolchain headless. Nella pagina Create a Toolchain, apri il programma di debug e valuta l'espressione window.Testflags = {nocreate: 1}. Quando fai clic su Create a Toolchain in questa modalità, la toolchain non viene creata. Invece, le informazioni che vengono passate all'API vengono restituite alla console dove puoi esaminarle.

Ho provato a eseguire una pipeline; perché sto ottenendo un errore relativo all'accesso al repository (repo) Git?

La pipeline utilizza un token di accesso per clonare il repository Git. Se questo token di accesso non è valido, il proprietario dell'integrazione Git non può accedere al repository Git.

Le integrazioni Git supportate includono le integrazioni degli strumenti GitHub, GitLab, Bitbucket o Git Repos and Issue Tracking.

Quando provo a eseguire una pipeline, ricevo il seguente messaggio di errore:

The access token for this git repository is no longer valid. Please reconfigure the git integration to ensure the integration owner has access to this repository.

Il token di accesso utilizzato dalla pipeline per clonare il repository Git non è più valido. Questo problema potrebbe verificarsi perché il token è stato invalidato. Il token di accesso potrebbe anche essere non valido se il proprietario dell'integrazione Git ha perso l'accesso al repository a causa di modifiche delle autorizzazioni.

Configura e salva nuovamente l'integrazione Git:

  1. Dalla console IBM Cloud, fare clic sull'icona del menu Hamburger > Automazione piattaforma > Toolchains. Nella pagina delle catene di strumenti, fare clic sulla catena di strumenti che contiene l'integrazione Git che si desidera aggiornare per aprire la relativa pagina di panoramica. In alternativa, nella pagina App Details nella tua applicazione, fai clic sul nome della toolchain.
  2. Nella pagina Panoramica della toolchain, nella scheda Repository, individua l'integrazione dello strumento Git.
  3. Fare clic sul menu per accedere alle opzioni di configurazione, selezionare l'account Git autorizzato per il proprietario dell'integrazione Git e fare clic su Salva integrazione.
  4. Esegui nuovamente la tua pipeline.

Ho provato a eseguire la distribuzione a Kubernetes utilizzando Delivery Pipeline, perché sto ottenendo un errore relativo a un oggetto non valido?

L'immagine di base della pipeline 1.0 include kubectl v1.14.2. Potresti ricevere un errore se il cluster Kubernetes a cui ti stai connettendo sta eseguendo una versione più recente di Kubernetes.

Quando provo ad eseguire la distribuzione a Kubernetes utilizzando la Delivery Pipeline, ricevo il seguente messaggio di errore:

error:SchemaeError(io.k8s.api.core.v1.SecretProjection): invalid object doesn't have additional properties

Di norma, questo problema si verifica quando la versione del comando kubectl nella tua immagine di base della pipeline non è compatibile con la versione di Kubernetes in esecuzione nel cluster.

Per risolvere il problema, puoi utilizzare uno dei seguenti metodi:

  • Utilizza una versione dell'immagine di base della pipeline più recente che, quando creata, includa la versione attualmente rilasciata dikubectl. Per informazioni su come specificare la versione dell'immagine più recente, vedi Specifica della versione dell'immagine.

  • Assicurati che il tuo lavoro della pipeline stia eseguendo la versione corretta di kubectl. Ad esempio, aggiungi le seguenti righe all'inizio del tuo lavoro della pipeline per eseguire kubectl v1.14.2:

  curl -LO https://storage.googleapis.com/kubernetes-release/release/v1.14.2/bin/linux/amd64/kubectl
  chmod +x ./kubectl
  sudo mv ./kubectl /usr/local/bin/kubectl

Se stai eseguendo kubectl v1.14.2 da un'immagine di base della pipeline 1.0, l'opzione sudo non è disponibile. Sostituisci la riga sudo con il seguente comando per aggiungere kubectl al tuo percorso:

   mkdir ~/.bin && export PATH=~/.bin:$PATH && mv ./kubectl ~/.bin/kubectl

Per ulteriori informazioni su come accedere alla versione esatta di kubectl richiesta, vedere Installazione e configurazione di kubectl.

Ho provato ad eseguire una pipeline, perché sto ricevendo un errore 403 da IBM Cloud Container Registry?

La IBM Cloud® Container Registry pipeline spinge e tira le immagini da e verso il IBM Cloud Container Registry. Il piano di servizio IBM Cloud Container Registry determina la quantità di spazio di archiviazione e di traffico che è possibile utilizzare per le immagini private.

Quando provo a eseguire una pipeline, ricevo il seguente messaggio di errore:

Failed to pull image "us.icr.io/sdl-ns/achilles:a100-p203-6-20190717161046-78fbc8a3a0fbc8571d887e57499642e0326e7035": rpc error: code = Unknown desc = failed to pull and unpack image "us.icr.io/sdl-ns/achilles:a100-p203-6-20190717161046-78fbc8a3a0fbc8571d887e57499642e0326e7035": failed to copy: httpReaderSeeker: failed open: unexpected status code https://us.icr.io/v2/sdl-ns/achilles/blobs/sha256:365b19774a508fd998bc636981cb9869a406786ad811e51937fa6fb089c86005: 403 Forbidden

Potresti aver superato i limiti della tua quota di traffico in entrata, il che impedisce il Docker recupero dell'immagine.

Esamina i tuoi limiti di quota e utilizzo per l'archiviazione e il pull delle immagini. Libera l'archiviazione utilizzata e modifica i piani di servizio o i limiti di quota per rimanere entro i limiti di quota specificati.

Ho provato a compilare la mia app in un singolo lavoro di pipeline, perché non è riuscito?

Hai bisogno di 4 GB di memoria (non di archivio file) per creare la tua app in un singolo lavoro della pipeline.

Quando tenti di compilare la mia applicazione in un singolo lavoro della pipeline, il lavoro di creazione non riesce con un errore imprevisto.

La tua applicazione richiede più di 4 GB di memoria per la compilazione in un singolo lavoro della pipeline.

Per creare la tua app in un singolo lavoro della pipeline:

  1. Creare un IBM Cloud® Continuous Delivery Pipeline Private worker.
  2. Configurare il lavoro di build per utilizzare l'operatore privato.

Perché Delivery Pipeline non può comunicare attraverso un firewall?

La configurazione del tuo firewall impedisce a Delivery Pipeline di comunicare con ambienti che si trovano dietro un firewall.

Quando provo ad utilizzare Delivery Pipeline, non può comunicare attraverso il mio firewall.

Il tuo firewall deve essere configurato per consentire a Delivery Pipeline di comunicare con ambienti che si trovano dietro un firewall.

Puoi aggiornare la configurazione del tuo firewall per consentire a Delivery Pipeline di accedere alle risorse che si trovano dietro il firewall. Utilizza l'elenco CIS di autorizzazioni e gli intervalli di sottoreti specifici per la tua regione.

Perché ho ricevuto una notifica che i riferimenti del repository sono corretti nei miei trigger o definizioni della pipeline?

Hai modificato, aggiunto o rimosso le integrazioni del repository dalla tua toolchain, il che ha fatto sì che i riferimenti alle integrazioni archiviati nei trigger o nelle definizioni della pipeline diventassero non validi.

Quando modifico, aggiungo o rimuovo le integrazioni del repository dalla mia toolchain, le icone di avvertenza e gli errori di convalida vengono visualizzati nella configurazione della mia pipeline.

In alcuni scenari, quando modifichi, aggiungi o rimuovi le integrazioni del repository dalla tua toolchain, i riferimenti a tali integrazioni archiviate nei trigger della pipeline o nelle definizioni potrebbero diventare non validi.

Se un'integrazione del repository corrispondente si trova nella toolchain, la pipeline tenta di aggiornare automaticamente questi riferimenti per correggere i riferimenti di integrazione non validi. Viene visualizzata una notifica nell'interfaccia utente con uno dei seguenti messaggi:

  • Repository reference fixed in the following triggers: [list of triggers]
  • Repository reference fixed in the following definitions: [list of definitions]

Se viene visualizzata una di queste notifiche, ma non vengono visualizzati errori o avvertenze nella configurazione, non sono richieste ulteriori azioni. Se le avvertenze o gli errori vengono ancora visualizzati, potrebbe essere necessario aggiornare o creare nuovamente il trigger o la definizione.

Perché la mia pipeline va in timeout quando cerca di connettersi agli endpoint privati IBM Cloud Object Storage?

Quando si esegue una pipeline, le richieste al IBM Cloud Object Storage che utilizzano un endpoint privato vanno in timeout senza risposta. Questo timeout può causare il fallimento della pipeline.

IBM Cloud Object Storage Gli endpoint privati non sono accessibili da tutti i tipi IBM Cloud di cluster. Gli endpoint IBM Cloud Object Storage privati non sono accessibili dai worker privati che girano su cluster all'interno di una rete privata virtuale IBM Cloud® Virtual Private Cloud (VPC).

Sostituisci tutti s3.private.*IBM Cloud Object Storage gli endpoint con s3.direct.* endpoint. s3.direct.* Gli endpoint sono endpoint diretti che comunicano con IBM Cloud Object Storage da qualsiasi tipo IBM Cloud di cluster.

Perché la mia pipeline ha esito negativo con un errore relativo alle proprietà protette?

PipelineRuns restituisce un errore quando una delle proprietà di sicurezza nella pipeline non viene risolta all'inizio dell'esecuzione della pipeline.

Le pipeline che non possono recuperare un valore segreto da un archivio di segreti o da Secrets Manager, Key Protect, o HashiCorp Vault, falliscono con un messaggio di errore che indica quali proprietà non possono essere risolte. Gli errori di risoluzione possono verificarsi anche se le proprietà non vengono utilizzate direttamente nell'esecuzione attivata. Ad esempio, gli errori di risoluzione potrebbero verificarsi se il percorso del segreto nell'archivio non è più valido, se l'archivio dei segreti non è più accessibile o se si verificano problemi di autorizzazione.

Se le pipeline contengono proprietà sicure che attualmente non si risolvono, aggiornare queste proprietà in modo che facciano riferimento a segreti validi e recuperabili che si trovano in Secrets Manager, Key Protect, o HashiCorp Vault.

Assicurati che la tua pipeline specifichi solo quelle proprietà sicure richieste per il corretto completamento di un PipelineRun attivato come proprietà del trigger della pipeline, invece che come proprietà dell'ambiente a livello di pipeline. Utilizzare le proprietà dell'ambiente a livello di pipeline solo quando richiesto.

Perché la mia pipeline riporta un errore durante il recupero della definizione della pipeline?

Nella Delivery Pipeline pagina viene visualizzato un errore relativo al recupero della definizione della pipeline. In alternativa, l'errore compare quando si tenta di attivare un PipelineRun.

Ci sono una serie di motivi per cui un errore può verificarsi durante il richiamo della definizione per una pipeline. Ad esempio, se la definizione è definita in un repository di grandi dimensioni, la richiesta di recupero della definizione può andare in time out a causa di un ritardo nella clonazione del repository di grandi dimensioni prima di costruire la definizione. Un altro esempio è quando un input di definizione è indirizzato a un ramo o a un percorso che non esiste più nel repository.

Tentare di risolvere il problema utilizzando una delle seguenti opzioni:

  • Ricaricare la pagina per avviare una nuova richiesta di richiamo della definizione. Se l'operazione ha esito negativo ripetutamente, continuare con le seguenti opzioni.
  • Convalidare che tutti i rami e i percorsi di riferimento negli input di definizione corrispondano alle risorse che esistono nel repository.
  • Ridurre la dimensione del repository contenente la definizione Tekton. Rimuovi i file non necessari dal repository e aggiorna il tuo .gitignore per escludere il caricamento di eventuali file non necessari.
  • Includi solo i file minimi necessari della tua definizione di pipeline -- non indirizzare l'intero repository. Spostare tutti i file relativi alle definizioni Tekton in una sottocartella del proprio repository, quindi modificare l'input delle definizioni nelle impostazioni di Delivery Pipeline per indirizzare il percorso alla sottocartella. Questa opzione riduce il tempo necessario per clonare i file di definizione dal repository.
  • Per le definizioni Tekton di grandi dimensioni, considerare la possibilità di suddividere la definizione in più cartelle o in più repository. Quindi, aggiornare gli input di definizione nella Delivery Pipeline per indirizzare le cartelle o i repo necessari.

Il limite di dimensione della definizione della pipeline calcolata è 1 MB. Se riscontri degli errori quando salvi o esegui la tua pipeline, potresti dover ridurre la dimensione della definizione della tua pipeline o suddividerla in più pipeline.

Perché la mia pipeline non riesce a connettersi a un cluster Red Hat OpenShift on IBM Cloud ?

Le pipeline che tentano un oc login non possono accedere al cluster di destinazione che esegue Red Hat OpenShift on IBM Cloud la versione 4.13 e successive.

Il problema è causato da una modifica introdotta nella versione 4.13 di Red Hat OpenShift on IBM Cloud.

Per risolvere il problema, utilizzare il seguente processo:

ibmcloud login --apikey "${IBMCLOUD_API_KEY}" -r "${REGION}" -g "${RESOURCE_GROUP}"
ibmcloud oc cluster config --cluster "${CLUSTER_NAME}" --endpoint private --admin
kubectl config current-context
oc version
oc get pods -A  # To verify connection

Perché la mia pipeline fallisce quando eseguo un comando Git clone?

Le pipeline Tekton che utilizzano il task di comando 'git-clone-repo potrebbero fallire con la visualizzazione del seguente errore:

Clone was not successful. Code 128 - Retrying shortly...
fatal: destination path '.' already exists and is not an empty directory.

Il problema è causato da una modifica delle prestazioni dell'infrastruttura dei lavoratori degli oleodotti gestiti pubblicamente.

Per risolvere questo problema:

  • Individuare le definizioni di tekton in Impostazioni della pipeline e trovare la voce 'git in Percorso. Fare clic sul link del repository per aprirlo. Navigare fino a 'git/task-clone-repo.yaml e poi all'interno del file trovare il passo 'clone-repo. Consultare l'esempio del catalogo Tekton per il codice più recente come riferimento.
  • Aggiungere rm -rf "lost+found" alla definizione prima della chiamata a git clone. In questo modo si assicura che la directory da clonare sia vuota.
  • Eseguire nuovamente la pipeline.

Perché la mia pipeline non si avvia sui lavoratori gestiti quando viene eseguita da un account di prova?

Le pipeline classiche eseguite da un account di prova non si avviano a causa del seguente errore:

This type of account is not entitled to use managed workers. Private workers can be used instead or to gain access managed worker capability the account must be upgraded to a paid plan.

Questo comportamento è causato da una revisione delle autorizzazioni per gli account di prova.

Provare le opzioni seguenti per risolvere questo problema:

  • Eseguite le vostre pipeline utilizzando un worker privato in esecuzione sul vostro cluster.
  • Esegui l'upgrade del tuo account di prova a un account Pagamento a consumo con un piano Lite.

Perché la mia pipeline non si attiva per gli eventi di richiesta di pull dai repository biforcati?

Le pipeline, per impostazione predefinita, non rispondono agli eventi di richiesta di pull dai repository biforcati

Questo comportamento è stato progettato per evitare l'esecuzione involontaria di pipeline.

Per consentire l'esecuzione di pipeline su eventi provenienti da repository biforcati, procedere come segue:

  • Pipeline Tekton: Nella finestra di attivazione di Git, attivare il toggle Include pull request events from forks
  • Pipeline classiche: Nella scheda Input della configurazione dello stage, attivare la levetta 'Include pull request events from forks

Perché a volte vedo ExceededNodeResources negli eventi Pod per la mia pipeline?

A volte, quando un'attività richiede più tempo del previsto per avviarsi, nella vista degli eventi del pod dell'attività nella pagina pipelineRun dei dettagli possono essere visualizzati ExceededNodeResources messaggi con valore reason.

Questo accade comunemente se un'attività cerca di utilizzare un volume già montato su un nodo sovraccarico. Questo può accadere anche quando il cluster è sovraccarico e può richiedere tempo per portare un nuovo nodo durante un evento di autoscala del cluster.

Questi messaggi sono probabilmente normali messaggi operativi provenienti dal tuo Kubernetes cluster. In genere, per questo tipo di messaggi non è necessario l'intervento dell'utente. Si verificano sia quando si verifica un evento di autoscaling, che libera risorse da utilizzare, sia quando le risorse diventano disponibili successivamente. La pipeline procede quindi una volta che il pod è stato programmato. In sostanza, la pipeline attende che le risorse necessarie si rendano disponibili attraverso l'autoscaling o altri mezzi, permettendo al pod di essere distribuito e alla pipeline di continuare.

Perché ricevo errori di rete quando utilizzo un Docker o Podman un sidecar?

Quando eseguo una pipeline Tekton con un Docker sidecar Podman o, noto uno o più dei seguenti sintomi:

  • Timeout di connessione intermittenti
  • Le richieste/risposte di grandi dimensioni falliscono mentre quelle di piccole dimensioni hanno esito positivo
  • I servizi funzionano correttamente a livello locale ma non nel cluster
  • TLS fallimenti dell'handshake

C'è una discrepanza MTU tra il demone docker e la rete host. Il daemon DockerPodman interno crea una propria rete bridge con un MTU predefinito di 1500, ma l'interfaccia di rete del pod potrebbe supportare solo 1450 byte a causa dell'incapsulamento overlay. È proprio questo disallineamento che causa i malfunzionamenti della rete.

Aggiorna la definizione della pipeline per impostare esplicitamente il mtu valore per docker come segue:

  • Docker: com.docker.network.driver.mtu: 1400
  • Podman: podman network create --opt mtu=1400 o in alcuni casi impostare --network=host