Resolução para limite de memória durante a construção

Veja A construção falha quando o limite de memória é excedido para obter informações de resolução.

Resolução para um problema de registro de contêiner durante a construção

Nesse cenário, não existe um segredo de registro para acessar o registro do contêiner ou o segredo não está correto.

1. Determine qual segredo foi usado. Use o comando ibmcloud ce build get para exibir o segredo do registro que é usado.

2. Determine se existe uma chave .dockerconfigjson. Use o comando ibmcloud ce secret get para o segredo de registro. Observe que os dados do segredo são codificados em Base64 e não são diretamente visíveis; no entanto, o segredo contém credenciais. Na saída de comando, verifique a seção Data. Ele deve conter uma chave que é chamada .dockerconfigjson. Se a chave .dockerconfigjson não for exibida, esse segredo não será adequado para autenticação com um registro de contêiner e será necessário criar um segredo correto e referenciá-lo na construção. Para obter mais informações, consulte Incluindo acesso em um registro de contêiner privado.

   Saída de exemplo

   $ 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 a chave .dockerconfigjson existir, então, decodifique a chave, que é uma sequência codificada em Base64 usando o comando a seguir,

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

   A saída deste comando geralmente contém uma chave <REGISTRY>.

4. Confirme as informações a seguir sobre a chave:

   a. Veja o valor <REGISTRY>. Esse valor deve corresponder à imagem da construção.

   • Se o nome da imagem estiver em IBM Cloud Container Registry, por exemplo us.icr.io/aNamespace/anImage, o <REGISTRY> deverá ser us.icr.io.

   • Se o nome da imagem for docker.io/aNamespace/aRepository ou /aNamespace/aRepository sem nenhum nome de host, a construção estará usando o Docker Hub. Neste caso, o <REGISTRY> deve ser https://index.docker.io/v1/.

   b. Veja o valor <USERNAME>. Se o registro for um IBM Cloud Container Registry, uma chave de API deverá ser usada para autenticação. O <USERNAME> precisa ser iamapikey e a senha precisa ser uma chave de API. Consulte Automatizando o acesso ao IBM Cloud Container Registry para obter as etapas para criar a chave de API.

   c. As credenciais precisam ser validadas. O IBM Cloud® Identity and Access Management (IAM) possibilita que permissões sejam atribuídas de forma detalhada. Por exemplo, um ID de serviço com acesso a um namespace do IBM Cloud Container Registry e a permissão para extrair imagens pode não ter permissão para enviar as imagens por push. Mas essa é a permissão necessária nesse caso.

5. Após você determinar as mudanças que são necessárias, crie um segredo de registro de contêiner que use valores corrigidos. Use o comando ibmcloud ce secret create --format ; por exemplo,

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

6. Atualize a construção para referenciar o nome do seu segredo de registro.

   a. Use o comando ibmcloud ce build update para atualizar a configuração de construção para usar o nome de seu segredo de registro; por exemplo,

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

   b. Use o comando ibmcloud ce buildrun submit para enviar uma nova execução de compilação. Para o comando buildrun submit, deve-se especificar a opção --build para fornecer o nome de sua configuração de construção. Opcionalmente, é possível especificar a opção --name para fornecer o nome para esta execução de compilação. Se você especificar a opção --name, certifique-se de usar uma execução de compilação diferente da execução de compilação com falha ou assegure-se de excluir a execução de compilação com falha usando o comando ibmcloud ce buildrun delete. Por exemplo,

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

Resolução para o Dockerfile não localizado durante a construção

Uma construção do Docker precisa de um Dockerfile que especifique como a imagem de contêiner deve ser construída. Se o repositório de origem não contiver tal arquivo, então, será necessário fornecer esse arquivo ou considerar buildpacks como uma estratégia de construção. Para obter mais informações, consulte Planejando a sua construção.

1. Se o Dockerfile existir, mas tiver um nome diferente ou não estiver no diretório-raiz, as configurações adicionais precisarão ser especificadas na construção.

   • Se o Dockerfile não estiver no diretório-raiz do repositório de origem, o argumento --context-dir deverá ser especificado e o caminho para o diretório que contém o Dockerfile deverá ser fornecido.
   • Se o Dockerfile for nomeado com algo diferente de Dockerfile, o argumento --dockerfile deverá ser especificado e o nome do seu Dockerfile deverá ser fornecido.

2. Atualize a construção para usar as opções --context-dir ou --dockerfile, conforme necessário.

   a. Use o comando ibmcloud ce build update para atualizar a configuração de construção para usar as opções --context-dir ou --dockerfile conforme necessário, por exemplo,

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

   b. Use o comando ibmcloud ce buildrun submit para enviar uma nova execução de compilação. Para o comando buildrun submit, deve-se especificar a opção --build para fornecer o nome de sua configuração de construção. Opcionalmente, é possível especificar a opção --name para fornecer o nome para esta execução de compilação. Se você especificar a opção --name, certifique-se de usar uma execução de compilação diferente da execução de compilação com falha ou assegure-se de excluir a execução de compilação com falha usando o comando ibmcloud ce buildrun delete. Por exemplo,

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

A resolução para o limite de cota do IBM Cloud Container Registry é atingida durante a compilação

O IBM Cloud Container Registry tem dois planos de serviços, um plano grátis e um plano padrão. Para o plano grátis, o IBM Cloud Container Registry aplica limites rígidos, especialmente no tamanho da imagem, que pode ser armazenado no total (500 MB). Para o plano padrão, é possível configurar as cotas. Para obter mais informações, consulte Sobre o IBM Cloud Container Registry.

1. Execute uma das ações a seguir:

   • Exclua as imagens não usadas do namespace do IBM Cloud Container Registry para aumentar o espaço disponível.
   • Faça upgrade do plano grátis para o plano padrão.
   • Aumente as cotas do namespace do IBM Cloud Container Registry.

   A URL da imagem é incluída na mensagem de erro para ajudar a identificar qual namespace do IBM Cloud Container Registry é afetado. O namespace pode estar em uma conta diferente da IBM Cloud do que seu projeto do IBM Cloud Code Engine.

2. Após você concluir as ações corretivas, use o comando ibmcloud ce buildrun submit para enviar uma nova execução de construção. Para o comando buildrun submit, deve-se especificar a opção --build para fornecer o nome de sua configuração de construção. Opcionalmente, é possível especificar a opção --name para fornecer o nome para esta execução de compilação. Se você especificar a opção --name, certifique-se de usar uma execução de compilação diferente da execução de compilação com falha ou assegure-se de excluir a execução de compilação com falha usando o comando ibmcloud ce buildrun delete. Por exemplo,

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

Resolução para origem de construção não especificada corretamente

A razão típica para esse erro ocorrer é que a origem de construção não está localizada no diretório-raiz do repositório Git, mas em um diretório-filho. Se a origem de construção não residir no diretório-raiz, especifique o local na construção.

1. Use o comando ibmcloud ce build update para atualizar a configuração de construção para usar a opção --context-dir para especificar o caminho para a origem no repositório Git, por exemplo,

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

2. Use o comando ibmcloud ce buildrun submit para enviar uma nova execução de compilação. Para o comando buildrun submit, deve-se especificar a opção --build para fornecer o nome de sua configuração de construção. Opcionalmente, é possível especificar a opção --name para fornecer o nome para esta execução de compilação. Se você especificar a opção --name, certifique-se de usar uma execução de compilação diferente da execução de compilação com falha ou assegure-se de excluir a execução de compilação com falha usando o comando ibmcloud ce buildrun delete. Por exemplo,

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

Resolução para um problema devido aos limites de taxa do hub do Docker

Quando você extrair uma imagem do Docker Hub para usar com aplicativos ou trabalhos em Code Engine, esteja ciente dos limites de taxa do Docker para usuários de planos gratuitos (não autenticados). É possível que ocorram limites de extração se você receber um erro 429, o que indica que você atingiu seu limite de taxa de extração. Se você receber esse erro, tente uma das soluções a seguir:

• Aumentar limites de taxa.. É possível autenticar com o Docker Hub ou fazer upgrade de sua conta para uma assinatura Docker Pro ou Team, se necessário.

• Extraia a imagem construída do Docker Hub e publique a imagem em um registro diferente, como IBM Cloud® Container Registry. Em seguida, extraia a sua imagem do novo local. Code Engine suporta referenciar um único segredo. Se a imagem base para a sua construção do Dockerfile for extraída de um registro diferente daquele em que a imagem construída resultante é publicada e ambos os registros requerem autenticação, será possível usar kubectl para criar um segredo do Kubernetes do tipo kubernetes.io/dockerconfigjson que contenha credenciais para ambos os registros.. Para obter informações sobre como trabalhar com credenciais de acesso para ambos os registros, consulte a documentação do Kubernetes sobre extrair uma imagem de um repositório privado.

Resolução para origem de construção não suportada por buildpacks

Para verificar se o seu repositório de origem de construção é suportado em Code Engine, consulte Escolha uma estratégia de construção para tempos de execução suportados. Se o seu idioma estiver listado, verifique as amostras vinculadas e assegure-se de estruturar corretamente suas origens para que os buildpacks possam detectá-las e construí-las com sucesso. Se você não puder localizar um buildpack adequado para a sua origem, ou a maneira padronizada de como os buildpacks executam a construção não atender às suas necessidades, será possível especificar um Dockerfile, descrever a construção do contêiner manualmente no Dockerfile e, em seguida, alternar para usar a estratégia de construção dockerfile na configuração de construção.

Resolução para um problema com a construção do Docker

Se o problema de falha da etapa de construção e push não for com a memória, um segredo de registro de contêiner ou um Dockerfile, provavelmente será com a construção do Docker. O problema pode ser um erro no próprio Dockerfile, por exemplo, um erro de sintaxe, ou na correção da operação executada. O problema também pode estar no seu código-fonte, que pode falhar ao compilar, por exemplo, se o código Java® for incluído.

Se você tiver construído com sucesso o seu projeto localmente, mas o mesmo código-fonte não tiver sido integrado no Code Engine, você poderá ter arquivos disponíveis localmente que não estarão em seu repositório Git. Por exemplo, para projetos Node.js, é comum executar o comando npm install localmente para que as dependências do projeto sejam transferidas por download e colocadas no diretório node_modules dentro do diretório do projeto. É uma boa prática incluir o diretório node_modules no arquivo.gitignore para manter o repositório Git pequeno. Um erro comum é esquecer de também executar npm install (ou npm ci) no Dockerfile. Uma compilação Docker executada localmente pode acessar o diretório local node_modules se você copiar todo o projeto para o contêiner, por exemplo, usando o comando COPY . /app no Dockerfile. Mas, a construção do Code Engine é executada por meio de um repositório Git verificado recentemente e não pode acessar o diretório node_modules. Portanto, deve-se executar npm install (ou npm ci) no Dockerfile como parte da construção.

Uma boa prática é incluir diretórios como node_modules também em um arquivo.dockerignore para que a compilação Docker que você executa localmente se comporte da mesma forma que a compilação Code Engine.

Outro motivo para que um projeto seja construído com sucesso localmente, mas falhe como a construção do Code Engine, são as limitações de segurança. A exemplo de aplicativos e tarefas em lote, o Code Engine não permite operações arbitrárias do sistema dentro do cluster do Code Engine. De qualquer maneira, a maioria dessas operações do sistema não é relevante para as construções do Docker. No entanto, o Code Engine não permite abrir soquetes do servidor para portas privilegiadas. O intervalo é 0 to 1023. Por exemplo, se você construir um aplicativo da web e sua construção incluir uma etapa de teste que ativa um servidor de aplicativos da web, portas com números mais altos deverão ser usadas para esse servidor.