Risoluzione dei problemi DevOps

Utilizzare le informazioni di risoluzione dei problemi per identificare e risolvere i problemi comuni che possono verificarsi durante l'utilizzo del servizio DevOps.

Distribuzione applicazioni in OKE

Il passo Applica manifest Kubernetes non riesce a causa di vari errori.

Errore di autorizzazione:

Il cluster potrebbe non esistere o manca un gruppo dinamico e un criterio per fornire l'accesso alla risorsa pipeline ad altre risorse Oracle Cloud Infrastructure (OCI) nel compartimento.

Controllare se esistono risorse OCI rilevanti e se viene creato un gruppo dinamico per la risorsa pipeline di distribuzione DevOps OCI insieme a un criterio per consentire a questo gruppo dinamico di accedere alle risorse OCI pertinenti.

Ad esempio, creare un gruppo dinamico per la pipeline di distribuzione. È possibile assegnare al gruppo dinamico il nome DeployDynamicGroup e sostituire compartmentOCID con l'OCID del compartimento: All {resource.type = 'devopsdeploypipeline', resource.compartment.id = 'compartmentOCID'}

Creare un criterio IAM per consentire al gruppo dinamico di accedere a tutte le risorse: Allow dynamic-group DeployDynamicGroup to manage all-resources in compartment <compartment_name>

Vedere DevOps Criteri IAM.

Campo del protocollo mancante:

Potrebbe essere visualizzato il seguente messaggio di errore: io.kubernetes.client.openapi.ApiException: class V1Status { apiVersion: v1 code: 500 details: null kind: Status message: failed to create typed patch object: .spec.template.spec.containers[name=\"helloworld\"].ports: element 0: associative list with keys has an element that omits key field \"protocol\" metadata: class V1ListMeta { _continue: null remainingItemCount: null resourceVersion: null selfLink: null } reason: null status: Failure }

Il manifesto Kubernetes deve avere un campo di protocollo ovunque sia definita la porta contenitore.

Questo problema è un bug esistente sul lato server Kubernetes. Applica per la versione cluster inferiore alla 1.20. Per ulteriori informazioni, vedere i problemi 130 e 92332.

Aggiungere il campo di protocollo ovunque sia definita la porta contenitore.

Timeout socket:

Il messaggio di errore potrebbe essere io.kubernetes.client.openapi.ApiException: java.net.SocketTimeoutException: connect timed out

Questo errore può verificarsi se l'endpoint pubblico Kubernetes non è raggiungibile o collegabile.

L'endpoint API Kubernetes deve essere un indirizzo collegabile valido. Per un endpoint IP pubblico valido, è necessario controllare la configurazione di rete del cluster. Vedere esempi.

Lo stato della distribuzione non è riuscito a causa del timeout:

Ciò potrebbe verificarsi se il tempo di distribuzione di Kubernetes supera la scadenza di avanzamento.

Per impostazione predefinita, la scadenza per l'avanzamento di Kubernetes è di 600 secondi. Vedere Scadenza avanzamento in secondi.

Se i pod della distribuzione K8s non vengono distribuiti correttamente entro la scadenza, questo messaggio di errore viene visualizzato nei log della distribuzione. Per ulteriori informazioni, vedere Distribuzione non riuscita.

Controllare i log di questi pod nel cluster.

Errore di audit delle vulnerabilità

Il passo VulnerabilityAudit non riesce nella fase di build gestita.

Configurazione o errore del file pom.xml non valido nel file JAR del client che elabora i file pom.xml:

Il file JAR del client Maven ADM (Application Dependency Management) non è in grado di creare la distinta base (BOM) (payload per la creazione del passo VulnerabilityAudit) a causa di una configurazione di file pom.xml non valida o di un errore nel file pom.xml di elaborazione del file JAR del client.

  1. Correggere e convalidare il file pom.xml.
  2. Aprire una richiesta di servizio.

Timeout o errore nel passo VulnerabilityAudit:

Il passo VulnerabilityAudit viene creato ma non raggiunge mai lo stato finale riuscito a causa di un timeout o di un errore nel passo VulnerabilityAudit.

Aprire una richiesta di servizio per errore.

Errore di convalida:

È possibile che si verifichi un errore di convalida se nel file di specifica della build viene immesso un valore knowledgeBaseId o vulnerabilityCompartmentId errato.

Controllare i valori forniti nel file build spec.

Criteri IAM non definiti:

Il passo VulnerabilityAudit potrebbe non riuscire se non sono stati definiti criteri per consentire alla pipeline di build di accedere alle risorse ADM.

Definire i criteri per accedere alle risorse ADM.

Errore server:

È possibile che si sia verificato un errore del servizio a causa di un'indisponibilità intermittente.

Aprire una richiesta di servizio.

Configurazione della connessione privata

L'esecuzione della build non riesce in modo coerente in vari passi.

Esecuzione build non riuscita al passo 'Provisioning accesso privato':

Il messaggio di errore potrebbe essere: impostazione dell'accesso privato non riuscita a causa di subnetId o nsgId non autenticato o non trovato.

Ciò può verificarsi se i criteri IAM (Identity and Access Management) sono errati o se i valori per subnetId o nsgId forniti durante la configurazione non sono validi.

Una delle seguenti risoluzioni può essere considerata a seconda della causa dell'errore:

  1. Scrivere i criteri IAM corretti. Per esempi di criteri, vedere Genera criteri.
  2. Verificare che i valori subnetId e nsgId siano corretti.

L'esecuzione della build non riesce in modo coerente al passo 'Imposta ambiente software':

Il messaggio di errore potrebbe essere: impossibile recuperare il bundle di certificati dal servizio di certificati per l'origine build <source> e caBundleId <Oracle Cloud Identifier (OCID) del bundle di codici.

Ciò può verificarsi se l'impostazione dei criteri IAM per la pipeline di build per accedere al certificato non è corretta oppure se è stato configurato un valore caBundleId errato nella risorsa di connessione.

Una delle seguenti risoluzioni può essere considerata a seconda della causa dell'errore:

  1. Scrivere i criteri IAM corretti. Per esempi di criteri, vedere Genera criteri.
  2. Verificare caBundleId e correggerlo nella risorsa di connessione esterna.

Esecuzione build non riuscita in modo coerente nel passo 'Scarica origine':

Se l'URL è corretto e se il server del repository ha installato un certificato con firma automatica, controllare TLSVerifyConfiguration nella risorsa di connessione.

Un'altra causa potrebbe essere la configurazione di un server repository per il quale il certificato SSL non è noto.

Attenersi alla procedura indicata e configurare la verifica TLS (Transport Layer Security) nella risorsa di connessione esterna.

  1. Ottenere il certificato dell'autorità di certificazione (CA) utilizzando: echo -n | openssl s_client -connect <host>:<port> | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > ca.pem
  2. Caricare il certificato nella risorsa bundle CA.
  3. Durante la creazione della risorsa di connessione esterna, configurare TLSVerifyConfiguration selezionando la risorsa bundle CA creata.

Esecuzione build non riuscita in modo coerente al passo 'Scarica origine':

Il messaggio di errore potrebbe essere: impossibile accedere al repository <repo URL>/Connessione all'ID e al numero di porta <repo non riuscita>.

Ciò può verificarsi se l'URL del repository configurato in uno dei buildSource nel file buildStage non è raggiungibile dal programma di esecuzione della build.

Controllare se l'URL del repository configurato è corretto e configurare l'accesso privato se l'URL del repository è un IP privato.

L'esecuzione della build non riesce in modo coerente nel passo 'Imposta ambiente software' o 'Scarica origine' o 'Qualsiasi passo del cliente nel file delle specifiche della build':

Potrebbe essere visualizzato uno dei seguenti messaggi di errore:
  1. Errore interno. Si verifica durante un errore del passo setup_software_env.
  2. Impossibile accedere al repository. Si verifica durante l'errore di scaricamento dell'origine.
  3. Errore di rete nei log dei clienti.

Ciò potrebbe verificarsi se la rete VCN (Virtual Cloud Network) non è stata impostata correttamente.

Quando si configura l'accesso privato, il traffico in uscita della VM del motore di esecuzione build viene controllato dalla VCN. La risoluzione DNS (Domain Name System) interna delle reti VCN non è supportata per l'accesso privato. Utilizzare gli IP per comunicare con i servizi ospitati nella rete privata. Per la VCN (subnet) in cui si sta configurando l'accesso privato è necessario seguire i prerequisiti riportati di seguito.

  1. Nella VCN configurata è necessario disporre di un gateway di servizi/gateway NAT.
  2. È necessario aggiungere regole di instradamento per fornire l'accesso a tutti i servizi OCI tramite uno di questi gateway. Se il codice o i comandi sorgente nel file di specifica della build devono accedere a Internet, è necessario che esistano regole appropriate prima di eseguire la build. Ciò è necessario in quanto tutto il traffico in uscita dal motore di esecuzione build passa attraverso la rete.

L'esecuzione della build non riesce quando si eseguono i comandi del docker nella specifica della build dalla fase Build gestita con accesso privato:

Questo errore si verifica quando la fase Build gestita è configurata con accesso privato e si dispone di comandi docker nel file delle specifiche di build. Ad esempio, la build del docker non riesce con l'errore di risoluzione DNS o l'errore di timeout della connessione se il file docker contiene comandi che accedono a Internet. Analogamente, l'esecuzione del docker non riesce con l'errore di risoluzione DNS o l'errore di timeout della connessione quando si tenta di accedere a Internet dal contenitore.

Per risolvere il problema, utilizzare --network host nei comandi del docker per configurare la rete di container Docker in modo appropriato. Ad esempio:
docker build --network host -t hello-world:1.0
docker run --network host hello-world:1.0