Documentação do Oracle Cloud Infrastructure

Diagnosticando e Solucionando Problemas do DevOps

Use informações de diagnóstico e solução de problemas para identificar e tratar problemas comuns que podem ocorrer ao trabalhar com o serviço DevOps.

Implantando Aplicativos no OKE

A etapa Aplicar manifesto do Kubernetes falha por causa de vários erros.

Erro de autorização:

Talvez o cluster não exista ou estejam ausentes o grupo dinâmico e a política para fornecer o acesso do recurso de pipeline a outros recursos do OCI (Oracle Cloud Infrastructure) no compartimento.

Verifique se existem recursos do OCI relevantes e se um grupo dinâmico foi criado para o recurso de pipeline de implantação do OCI DevOps com uma política para permitir que esse grupo dinâmico acesse os recursos relevantes do OCI.

Por exemplo, crie um grupo dinâmico para o pipeline de implantação. Você pode nomear o grupo dinâmico como DeployDynamicGroup e substituir compartmentOCID pelo OCID do seu compartimento: All {resource.type = 'devopsdeploypipeline', resource.compartment.id = 'compartmentOCID'}

Crie uma política do serviço IAM para permitir que o grupo dinâmico acesse todos os recursos: Allow dynamic-group DeployDynamicGroup to manage all-resources in compartment <compartment_name>

Consulte Políticas do Serviço IAM do DevOps.

Campo de protocolo ausente:

A seguinte mensagem de erro pode ser exibida: 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 }

O manifesto do Kubernetes deve ter um campo de protocolo sempre que a porta do contêiner é definida.

Esse problema é um bug existente na Aplicação do Servidor Kubernetes para a versão do cluster abaixo de 1.20. Para obter mais informações, consulte os problemas 130 e 92332.

Adicione o campo de protocolo em que a porta do contêiner estiver definida.

Timeout de soquete:

A mensagem de erro pode ser, io.kubernetes.client.openapi.ApiException: java.net.SocketTimeoutException: connect timed out

Este erro poderá ocorrer se o ponto final público do Kubernetes não estiver acessível ou conectável.

O Ponto Final da API do Kubernetes deve ser um endereço conectável válido. Para um ponto final de IP público válido, verifique a configuração de rede do cluster. Consulte exemplos.

Falha no status da implantação por causa de timeout:

Isso poderá ocorrer se o tempo de implantação do Kubernetes exceder o prazo de andamento.

Por padrão, o prazo de andamento do Kubernetes é de 600 segundos. Consulte Segundos do Prazo de Andamento.

Se o rollout dos pods da implantação K8s não for feito com sucesso dentro do prazo, essa mensagem de erro será mostrada nos logs de implantação. Para obter mais informações, consulte Falha na Implantação.

Verifique os logs desses pods no cluster.

Falha de Auditoria de Vulnerabilidade

A etapa VulnerabilityAudit falha no estágio de Build Gerenciado.

Falha ou configuração de arquivo pom.xml inválida nos arquivos pom.xml de processamento JAR (arquivo compactado Java) do cliente:

O JAR do cliente Maven do serviço ADM (Application Dependency Management) não cria a BOM (Lista de Materiais) (payload para a criação da etapa VulnerabilityAudit) por causa de configuração inválida ou falha do arquivo pom.xml nos arquivos pom.xml de processamento JAR do cliente.

  1. Corrija e valide o arquivo pom.xml.
  2. Abra uma solicitação de serviço.

Timeout ou falha na etapa VulnerabilityAudit:

A etapa VulnerabilityAudit é criada, mas nunca atinge um status final bem-sucedido por causa de timeout ou falha na etapa VulnerabilityAudit.

Abra uma solicitação de serviço para falha.

Erro de validação:

Poderá ocorrer um erro de validação se um knowledgeBaseId ou vulnerabilityCompartmentId incorreto for informado no arquivo de especificação do build.

Verifique os valores fornecidos no arquivo build spec.

Políticas do serviço IAM não definidas:

A etapa VulnerabilityAudit poderá falhar se nenhuma política for definida para permitir que o pipeline de build acesse os recursos do serviço ADM.

Defina políticas para acessar os recursos do serviço ADM.

Erro no servidor:

Pode ocorrer um erro de serviço em decorrência de interrupção intermitente.

Abra uma solicitação de serviço.

Configurando uma Conexão Privada

A execução do build falha de forma consistente em várias etapas.

Falha na execução do build na etapa 'Provisionar Acesso Privado':

Talvez a mensagem de erro seja: falha na configuração do acesso privado em decorrência de subnetId ou nsgId não autenticado ou não encontrado.

Isso poderá ocorrer se as políticas do serviço IAM (Identity and Access Management) estiverem erradas ou se os valores para subnetId ou nsgId fornecidos durante a configuração forem inválidos.

Uma das seguintes resoluções pode ser considerada, dependendo da causa do erro:

  1. Grave as políticas de IAM corretas. Para obter exemplos de política, consulte políticas de build.
  2. Verifique se os valores subnetId e nsgId estão corretos.

A execução do build falha consistentemente na etapa 'Configurar Ambiente de Software':

A mensagem de erro pode ser: não é possível extrair o pacote de certificados do serviço de certificado para a origem de build <source> e para caBundleId <Oracle Cloud Identifier (OCID) do bundle de ca>.

Isso poderá ocorrer se houver algum erro na configuração da política do serviço IAM para o pipeline de build que tenta acessar o certificado ou se você tiver configurado um caBundleId errado no recurso de conexão.

Uma das seguintes resoluções pode ser considerada, dependendo da causa do erro:

  1. Grave as políticas de IAM corretas. Para obter exemplos de política, consulte políticas de build.
  2. Verifique o caBundleId e corrija-o no recurso de conexão externa.

A execução do build falha consistentemente na etapa 'Fazer Download da Origem':

Se o URL estiver correto e se o servidor de repositórios tiver instalado um certificado self-signed, verifique TLSVerifyConfiguration no recurso de conexão.

Outra causa pode ser por você ter configurado um servidor de repositório para o qual o certificado SSL não é conhecido.

Siga as etapas fornecidas e configure a verificação TLS (Transport Layer Security) no recurso de conexão externa:

  1. Obtenha o certificado da Autoridade de Certificação (CA) usando: echo -n | openssl s_client -connect <host>:<port> | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > ca.pem
  2. Faça upload do certificado para o recurso do pacote de CAs.
  3. Ao criar o recurso de conexão externa, configure TLSVerifyConfiguration selecionando o recurso do pacote de CAs (autoridades de certificação) criado.

A execução do build falha consistentemente na etapa 'Fazer Download da Origem':

Talvez possa ser exibida a seguinte mensagem de erro: não foi possível acessar o repositório <repo URL>/Falha ao estabelecer conexão com ID <repo e número de porta>.

Isso poderá ocorrer se o URL do repositório configurado em um dos buildSource no buildStage não estiver acessível pelo executor do build.

Verifique se o URL do repositório configurado está correto e configure o acesso privado se o URL do repositório for um IP privado.

A execução do build falha consistentemente na etapa 'Configurar Ambiente de Software' ou 'Fazer Download da Origem' ou 'qualquer etapa do cliente no arquivo de especificação do build':

Uma das seguintes mensagens de erro pode ser exibida:
  1. Erro interno. Ocorre durante a falha da etapa setup_software_env.
  2. Não é possível acessar o repositório. Ocorre durante falha na origem do download.
  3. Erro relacionado à rede nos logs do cliente.

Isso poderá ocorrer se você não tiver configurado corretamente a VCN (Rede Virtual na Nuvem).

Quando você configura o acesso privado, o tráfego de saída da VM do executor de build é controlado pela VCN. A resolução do DNS (Domain Name System) interno de VCNs não é suportada para acesso privado. Use IPs para se comunicar com serviços hospedados na rede privada. Os seguintes pré-requisitos devem ser seguidos para a VCN (sub-rede) na qual você está configurando o acesso privado:

  1. Você deve ter um gateway de serviço/gateway NAT na VCN configurada.
  2. É necessário adicionar regras de roteamento para fornecer acesso a todos os serviços do OCI por meio de um desses gateways. Se o código-fonte ou os comandos no arquivo de especificação de build precisarem de acesso à internet, deverão existir regras apropriadas antes de executar o build. Isso é necessário porque todo o tráfego de saída do executor de build passa pela rede.

A execução do build falha ao executar comandos do docker na especificação do build do estágio de Build Gerenciado com acesso privado:

Esse erro ocorre quando o estágio de Build Gerenciado é configurado com acesso privado e você tem comandos do docker no arquivo de especificação do build. Por exemplo, o build do docker falhará com erro de resolução de DNS ou erro de timeout de conexão se o arquivo do docker contiver comandos que acessam a internet. Da mesma forma, a execução do docker falha com erro de resolução de DNS ou erro de timeout de conexão ao tentar acessar a internet pelo contêiner.

Para resolver isso, use --network host nos comandos do docker para configurar a rede de contêiner do Docker adequadamente. Por exemplo, 
docker build --network host -t hello-world:1.0
docker run --network host hello-world:1.0