Risoluzione dei problemi per DevSecOps
Utilizzate questi suggerimenti per risolvere i problemi che potreste incontrare quando utilizzate DevSecOps.
Metodi di risoluzione dei problemi generali
-
Ricarica la pagina nel caso in cui l'IU sia lenta o i log non riescano a caricarsi.
-
Controllare le interruzioni nella pagina di stato
-
Eseguire nuovamente la pipeline.
Attivazione manuale della promozione
Problemi dell'ambiente IBM
L'esecuzione della pipeline è lenta a causa della limitazione della velocità di Git
L'esecuzione della pipeline sembra più lenta, l'esecuzione e il completamento della pipeline richiedono più tempo.
Inoltre, la seguente voce si trova in vari punti dei registri:
Unable to use this tool because the git API rate limit is exceeded. Please try again in <n> minutes.
Le pipeline utilizzano internamente le richieste API di Git (impostare gli stati di Git, creare/aggiornare problemi,...). C'è un limite di velocità Git di
Per superare questo problema di limitazione della velocità Git:
- Migrare dal deposito prove Git al deposito prove COS (noto anche come solo COS). Consultare la sezione corrispondente nella documentazione IBM Cloud.
- Utilizza token Git diversi per le pipeline e/o i trigger.
Il passo di controllo del registro dell'attività inserita nel contenitore ha esito negativo con errore
Il registro IBM Cloud offre una quota limitata, il push di troppe immagini può essere superato.
- Andare alle immagini ed eliminare le immagini non richieste.
- Eseguire nuovamente la pipeline.
Puoi controllare i tuoi limiti di quota e il tuo utilizzo utilizzando il seguente comando:
ibmcloud cr quota
I log non vengono visualizzati per il passo
Questo è un problema con l'ambiente Tekton.
Prova a ricaricare la pagina. Scarica i log utilizzando il pulsante di download.
Problemi di modelli e pipeline
L'attività è stata annullata perché non è possibile accedere all'immagine di base
Controllare se le credenziali artifactory sono corrette. Un nuovo token artifactory può essere creato qui. Puoi creare un segreto manualmente eseguendo:
kubectl create secret docker-registry mysecret \
--dry-run \
--docker-server=<artifactory-server-domain> \
--docker-username=<username> \
--docker-password=<artifactory token> \
--docker-email=<email> \
-o yaml
Produce qualcosa di simile al seguente:
apiVersion: v1
data:
.dockerconfigjson: <your secret>
kind: Secret
metadata:
creationTimestamp: null
name: regcred
type: kubernetes.io/dockerconfigjson
Nelle proprietà della pipeline, aggiornare il parametro artifactory-dockerconfigjson con il valore .dockerconfigjson .
Per ulteriori informazioni, consulta la documentazione kubectl sulla creazione di un segreto(: external).
Pipeline non riuscita in anticipo
Quando una pipeline ha esito negativo, viene visualizzato il seguente messaggio:
Pipeline could not run, resource failed to apply - Kind: "Secret", Name: "pipeline-pull-secret" ResourceError
In questo caso, l'errore si è verificato nella pipeline perché non è stato avviato. Pertanto, non sono disponibili registri.
Il dockerconfig.json segreto, che estrae le immagini Docker da IBM Container Registry utilizzato da questa pipeline non è corretto.
Questo segreto potrebbe non essere corretto oppure la chiave API associata a questo segreto viene ruotata o revocata.
Genera un nuovo dockerconfig.json quindi utilizza questo nuovo valore segreto nella tua pipeline (come parametro della pipeline o memorizzato in Secrets Manager ).
Per generare un nuovo dockerconfig.json, eseguire il seguente comando:
kubectl create secret docker-registry my-registry-secret \
-o json \
--dry-run=client \
--docker-server=icr.io \
--docker-username=iamapikey \
--docker-email=john-doe@ibm.com \
--docker-password=<apikey> \
| jq -r '.data[".dockerconfigjson"]'
Dove <apikey> è la tua chiave API Cloud IBM Cloud o una chiave API ID servizio.
La pipeline non può eseguire il pull delle immagini da più repository artistici
La pipeline è riuscita a estrarre le immagini da un repository ma non da un altro.
La pipeline non è riuscita perché è configurata per eseguire il pull delle immagini da un singolo repository.
Creare manualmente un nuovo segreto dockerconfigjson per supportare l'autenticazione rispetto a più repository.
Per supportare l'autenticazione per il pull delle immagini da più repository in Artifactory, genera un nuovo dockerconfigjson e aggiungi una proprietà di ambiente di tipo segreto artifactory-dockerconfigjson a una
o più pipeline.
Il seguente script è un esempio per generare un dockerconfigjson artifactory che fornisce i dettagli di autenticazione per due diversi repository artistici. Questo è uno script personalizzabile.
Prerequisiti
I comandi kubectl e jq deve essere installati.
Passi
-
Aprire un editor di testo che salva il file in LF (Line Feed) caratteri di fine riga.
-
Creare un file e copiare il contenuto del seguente script:
dockerconfig_1=$(kubectl create secret docker-registry my-registry-secret \ --output json \ --dry-run=client \ --docker-server="<artifactory_repo_host>" \ --docker-username="<email>" \ --docker-email="<email>" \ --docker-password="<artifactory_token>" \ | jq -r '.data[".dockerconfigjson"]') dockerconfig_2=$(kubectl create secret docker-registry my-registry-secret \ --output json \ --dry-run=client \ --docker-server="<second_repo_host>" \ --docker-username="<email>" \ --docker-email="<email>" \ --docker-password="<second_artifactory_token>" \ | jq -r '.data[".dockerconfigjson"]') echo $dockerconfig_1 | base64 -d > first_secret.json echo $dockerconfig_2 | base64 -d > second_secret.json new_dockerconfig=$(jq -s '.[0] * .[1]' first_secret.json second_secret.json | base64 -w0) echo ${new_dockerconfig} > final_dockerconfig.txt -
Sostituire i valori segnaposto con i dati di autenticazione effettivi:
- Sostituire
<artifactory_repo_host>con il collegamento al primo repository. - Sostituire
<artifactory_token>con il token di autenticazione per il primo repository. - Sostituire
<email>con l'email associata all'autenticazione. - Sostituire
<second_repo_host>con il link al secondo repository. - Sostituire
<second_artifactory_token>con il token di autenticazione per il secondo repository.
- Sostituire
-
Salva il file.
-
Accertarsi che il file sia salvato in una directory con autorizzazioni di scrittura.
-
Esegui lo script.
-
Aggiungere il contenuto di
final_dockerconfig.txtcome un segreto nelle proprietà dell'ambiente della pipeline perartifactory-dockerconfigjson. Se si utilizza Secrets Manager o Key Protect, salvare il contenuto di questo file utilizzando le tecniche appropriate.
La compilazione di CRA o Docker fallisce a causa di file di sottomodulo mancanti
Quando una fase della pipeline, come la compilazione di CRA o di Docker, fallisce, si può vedere un messaggio di errore simile a questo:
failed to calculate checksum of ref moby::...: failed to walk /var/lib/docker/tmp/buildkit-mount.../common-dev-assets/module-assets/ci: lstat ... no such file or directory
Questo errore si verifica perché il repository contiene sottomoduli Git, ma le pipeline non clonano i sottomoduli per impostazione predefinita. Ogni fase della pipeline viene eseguita nel proprio contenitore ed esegue un nuovo checkout del repository, quindi i contenuti dei sottomoduli sono assenti, a meno che non siano esplicitamente inizializzati.
Per risolvere questo problema, è necessario assicurarsi che il sottomodulo Git sia inizializzato in ogni fase che lo richiede. Per CRA in particolare, è possibile aggiungere l'inizializzazione del sottomodulo allo script CRA personalizzato.
Ad esempio, aggiornare lo script per includere:
git submodule update --init --recursive
Questo garantisce che il sottomodulo sia disponibile prima dell'esecuzione del processo di compilazione di CRA.
Problemi di firma immagine
Se la tua attività di firma dell'immagine non riesce, consulta la documentazione sulla firma dell'immagine per verificare che la chiave di firma sia stata generata e memorizzata correttamente.
Problemi relativi alla fase di scansione dinamica non definiti nella configurazione della pipeline
L'esecuzione della pipeline CI ha esito negativo con errore.
L'errore si verifica quando la configurazione della pipeline CI non contiene una definizione di attività per eseguire la scansione dinamica. Aggiungi il seguente frammento in .pipeline-config.yaml e personalizza il passo in base
alla tua applicazione.
dynamic-scan:
dind: true
abort_on_failure: false
image: icr.io/continuous-delivery/pipeline/pipeline-base-image:2.12@sha256:ff4053b0bca784d6d105fee1d008cfb20db206011453071e86b69ca3fde706a4
script: |
#!/usr/bin/env bash
echo "Please insert script to invoke/execute dynamic scan tool like OWASP ZAP on the built and deployed application."
Per ulteriori informazioni sulle fasi, consultare Script personalizzati.
Ottenere il supporto
- Puoi controllare Stack Overflow per vedere se altri utenti hanno riscontrato lo stesso problema. Quando si utilizza il forum per porre una domanda, taggare la domanda con "ibm-cloud" e "DevSecOps" in modo che venga vista dai team di sviluppo di IBM Cloud.
- IBM Cloud IBM l'assistente IA di , basato sull' watsonx di , è progettato per aiutarti a imparare a lavorare in IBM Cloud e a creare soluzioni con il catalogo di offerte disponibile. Vedere Ottenere aiuto dall'assistente IA.
- Se non si riesce a risolvere il problema, è possibile aprire un caso di assistenza. Per informazioni sull'apertura di un caso di assistenza o sulla gravità dei casi e sui tempi di risposta, vedere Lavorare con i casi di assistenza o Escalation dei casi di assistenza.