Solução de problemas AWS CodeBuild - AWS CodeBuild
Artefatos de referência de compilações Apache Maven do repositório erradoComandos de compilação executados como raiz por padrãoAs compilações podem falhar quando nomes de arquivos têm caracteres que não sejam do inglês.As compilações podem falhar ao obter parâmetros do Amazon EC2 Parameter StoreNão é possível acessar o filtro da ramificação de acesso no console do CodeBuild Não é possível visualizar o êxito ou a falha de compilação Status de compilação não comunicado ao provedor de origemNão é possível localizar e selecionar a imagem de base da plataforma Windows Server Core 2019. Comandos anteriores em arquivos buildspec não são reconhecidos por comandos posterioresErro: "acesso negado" ao tentar fazer download do cacheErro: "BUILD_CONTAINER_UNABLE_TO_PULL_IMAGE" ao usar uma imagem de compilação personalizada Erro: “O contêiner de compilação foi encontrado inativo antes de concluir a compilação. O contêiner de compilação morreu porque estava sem memória ou a imagem do Docker não é suportada. ErrorCode: 500" Erro: “Cannot connect to the Docker daemon (Não é possível conectar-se ao daemon do Docker)” ao executar uma compilaçãoErro: "não CodeBuild está autorizado a executar: sts:AssumeRole" ao criar ou atualizar um projeto de compilação Erro: “Erro ao chamar GetBucketAcl: ou o proprietário do bucket mudou ou a função de serviço não tem mais permissão para chamar s3:GetBucketAcl” Erro: "Failed to upload artifacts: Invalid arn (Falha ao fazer upload de artefatos: arn inválido)” ao executar uma compilaçãoErro: "falha do clone do Git: não é possível acessar 'your-repository-URL': problema de certificado SSL: certificado autoassinado"Erro: "The bucket you are attempting to access must be addressed using the specified endpoint (O bucket que você está tentando acessar deve ser endereçado usando o endpoint especificado)" ao executar uma compilaçãoErro: "This build image requires selecting at least one runtime version" (Esta imagem de compilação requer a seleção de pelo menos um tempo de execução)Erro: "QUEUED: INSUFFICIENT_SUBNET" quando ocorre uma falha em uma compilação em uma fila de compilaçãoErro: “Não foi possível baixar o cache: RequestError: Falha na solicitação de envio causada por: x509: Falha ao carregar raízes do sistema e nenhuma raiz fornecida”Erro: “Não foi possível baixar o certificado do S3. AccessDenied”Erro: "não foi possível localizar as credenciais" RequestError erro de tempo limite ao executar CodeBuild em um servidor proxyO bourne shell (sh) deve existir em imagens de compilaçãoAviso: "ignorando a instalação de tempos de execução. A seleção de versão de tempo de execução não é compatível com esta imagem de compilação” ao executar uma compilaçãoErro: “Não foi possível verificar a JobWorker identidade”Falha ao iniciar a compilaçãoAcessando GitHub metadados em compilações armazenadas em cache localmenteAccessDenied: O proprietário do bucket do grupo de relatórios não corresponde ao proprietário do bucket do S3...

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Solução de problemas AWS CodeBuild

Use as informações neste tópico para ajudá-lo a identificar, diagnosticar e resolver problemas. Para saber como registrar e monitorar CodeBuild compilações para solucionar problemas, consulte. Registro e monitoramento

Tópicos

Artefatos de referência de compilações Apache Maven do repositório errado

Problema: quando você usa o Maven com um ambiente AWS CodeBuild de compilação Java fornecido, o Maven extrai dependências de compilação e plug-in do repositório central seguro do Maven em https://repo1.maven.org/maven2. Isso ocorre mesmo quando o arquivo pom.xml do seu projeto de build declara explicitamente outros locais de uso.

Possível causa: os ambientes CodeBuild de compilação Java fornecidos incluem um arquivo chamado settings.xml que está pré-instalado no diretório do /root/.m2 ambiente de compilação. Esse arquivo settings.xml contém as seguintes declarações, que instruem o Maven para sempre chamar as dependências de plugin e build do repositório central seguro Maven em https://repo1.maven.org/maven2.

<settings> <activeProfiles> <activeProfile>securecentral</activeProfile> </activeProfiles> <profiles> <profile> <id>securecentral</id> <repositories> <repository> <id>central</id> <url>https://repo1.maven.org/maven2</url> <releases> <enabled>true</enabled> </releases> </repository> </repositories> <pluginRepositories> <pluginRepository> <id>central</id> <url>https://repo1.maven.org/maven2</url> <releases> <enabled>true</enabled> </releases> </pluginRepository> </pluginRepositories> </profile> </profiles> </settings>

Solução recomendada: Faça o seguinte:

  1. Adicione um arquivo settings.xml ao seu código-fonte.

  2. Nesse arquivo settings.xml, use o formato settings.xml precedente como guia para declarar os repositórios de onde deseja que o Maven chame as dependências de plugin e build.

  3. Na install fase do seu projeto de compilação, CodeBuild instrua a copiar seu settings.xml arquivo para o /root/.m2 diretório do ambiente de compilação. Por exemplo, considere o seguinte trecho de um arquivo buildspec.yml que demonstre esse comportamento.

    version 0.2 phases: install: commands: - cp ./settings.xml /root/.m2/settings.xml

Comandos de compilação executados como raiz por padrão

Problema: AWS CodeBuild executa seus comandos de compilação como usuário root. Isso acontecerá mesmo se o Dockerfile da imagem de compilação relacionado definir a instrução USER como um usuário diferente.

Causa: Por padrão, CodeBuild executa todos os comandos de compilação como usuário root.

Solução recomendada: nenhuma.

As compilações podem falhar quando nomes de arquivos têm caracteres que não sejam do inglês.

Problema: ao executar uma compilação que use arquivos com nomes que contenham caracteres que não sejam do inglês (por exemplo, caracteres chineses), a compilação falha.

Possível causa: ambientes de compilação fornecidos por AWS CodeBuild têm sua localidade padrão definida como. POSIX POSIXas configurações de localização são menos compatíveis com nomes CodeBuild de arquivos que não sejam dos EUA Caracteres em inglês e podem fazer com que compilações relacionadas falhem.

Solução recomendada: adicione os comandos a seguir à seção pre_build do arquivo buildspec. Esses comandos fazem com que o ambiente de compilação use UTF-8 em inglês dos EUA para suas configurações de localização, que é mais compatível com CodeBuild nomes de arquivo que não contêm nomes de arquivos que não sejam dos EUA Caracteres em inglês.

Para ambientes de compilação com base no Ubuntu:

pre_build: commands: - export LC_ALL="en_US.UTF-8" - locale-gen en_US en_US.UTF-8 - dpkg-reconfigure locales

Para ambientes de compilação com base no Amazon Linux:

pre_build: commands: - export LC_ALL="en_US.utf8"

As compilações podem falhar ao obter parâmetros do Amazon EC2 Parameter Store

Problema: quando uma compilação tenta obter o valor de um ou mais parâmetros armazenados no Amazon EC2 Parameter Store, ela falha na fase DOWNLOAD_SOURCE com o erro Parameter does not exist.

Causa possível: a função de serviço da qual o projeto de construção depende não tem permissão para chamar a ssm:GetParameters ação ou o projeto de construção usa uma função de serviço gerada AWS CodeBuild e que permite chamar a ssm:GetParameters ação, mas os parâmetros têm nomes que não começam com/CodeBuild/.

Soluções recomendadas:

  • Se a função de serviço não foi gerada por CodeBuild, atualize sua definição CodeBuild para permitir chamar a ssm:GetParameters ação. Por exemplo, a seguinte declaração de política permite chamar a ação ssm:GetParameters para obter parâmetros com nomes que comecem com /CodeBuild/:

    { "Version": "2012-10-17", "Statement": [ { "Action": "ssm:GetParameters", "Effect": "Allow", "Resource": "arn:aws:ssm:REGION_ID:ACCOUNT_ID:parameter/CodeBuild/*" } ] }
  • Se a função de serviço foi gerada por CodeBuild, atualize sua definição para permitir CodeBuild o acesso aos parâmetros no Amazon EC2 Parameter Store com nomes diferentes daqueles que começam com. /CodeBuild/ Por exemplo, a seguinte declaração de política permite chamar a ação ssm:GetParameters para obter parâmetros com o nome especificado:

    { "Version": "2012-10-17", "Statement": [ { "Action": "ssm:GetParameters", "Effect": "Allow", "Resource": "arn:aws:ssm:REGION_ID:ACCOUNT_ID:parameter/PARAMETER_NAME" } ] }

Não é possível acessar o filtro da ramificação de acesso no console do CodeBuild

Problema: a opção de filtro de ramificação não está disponível no console quando você cria ou atualiza um AWS CodeBuild projeto.

Possível causa: a opção de filtro da ramificação está suspensa. Ela foi substituída por grupos de filtros de webhook, que fornecem mais controle sobre os eventos de webhook que acionam uma nova compilação no CodeBuild.

Solução recomendada: para migrar um filtro de ramificação criado antes da introdução dos filtros de webhook, crie um grupo de filtro de webhook com um filtro HEAD_REF com a expressão regular ^refs/heads/branchName$. Por exemplo, se sua expressão regular do filtro de ramificação era ^branchName$, então a expressão regular que você colocar no filtro HEAD_REF será ^refs/heads/branchName$. Para ter mais informações, consulte Filtrar eventos de webhook do Bitbucket e Filtrar eventos de GitHub webhook (console).

Não é possível visualizar o êxito ou a falha de compilação

Problema: você não consegue ver o êxito ou a falha de uma nova tentativa de compilação.

Possível causa: a opção para informar o status da compilação não está habilitada.

Soluções recomendadas: ative o status de criação do relatório ao criar ou atualizar um CodeBuild projeto. Essa opção instrui o CodeBuild a informar o status quando você acionar uma compilação. Para obter mais informações, consulte reportBuildStatus na Referência de APIs do AWS CodeBuild .

Status de compilação não comunicado ao provedor de origem

Problema: depois de permitir o relatório do status da compilação para um provedor de origem, como GitHub o Bitbucket, o status da compilação não é atualizado.

Possível causa: o usuário associado ao provedor de origem não tem acesso de gravação ao repositório.

Soluções recomendadas: para poder comunicar o status da compilação ao provedor de origem, o usuário associado ao provedor de origem deve ter acesso de gravação ao repositório. Se o usuário não tiver acesso de gravação, o status de compilação não poderá ser atualizado. Para ter mais informações, consulte Acesso do provedor de origem.

Não é possível localizar e selecionar a imagem de base da plataforma Windows Server Core 2019.

Problema: não é possível localizar nem selecionar a imagem de base da plataforma Windows Server Core 2019.

Possível causa: você está usando uma AWS região que não suporta essa imagem.

Soluções recomendadas: use uma das seguintes regiões da AWS com a qual a imagem base da plataforma Windows Server Core 2019 é compatível:

  • Leste dos EUA (Norte da Virgínia)

  • Leste dos EUA (Ohio)

  • Oeste dos EUA (Oregon)

  • Europa (Irlanda)

Comandos anteriores em arquivos buildspec não são reconhecidos por comandos posteriores

Problema: Os resultados de um ou mais comandos em seu arquivo buildspec não são reconhecidos por comandos posteriores no mesmo arquivo buildspec. Por exemplo, um comando pode definir uma variável de ambiente local, mas um comando executado posteriormente falha em obter o valor da variável de ambiente local.

Possível causa: no arquivo buildspec versão 0.1, o AWS CodeBuild executa cada comando em uma instância à parte do shell padrão no ambiente de compilação. Isso significa que cada comando é executado isoladamente em relação aos outros comandos. Por padrão, então, você não pode executar um comando que dependa do estado de quaisquer comandos anteriores.

Soluções recomendadas: recomendamos usar a especificação de compilação versão 0.2, que resolve o problema. Se você precisa usar o buildspec versão 0.1, recomendamos que use o operador de encadeamento de comandos do shell (por exemplo, && no Linux) para combinar vários comandos em um só. Ou inclua no código-fonte um script de shell que contenha vários comandos e, em seguida, chame o script de shell de um único comando no arquivo buildspec. Para ter mais informações, consulte Shells e comandos em ambientes de compilação e Variáveis de ambiente em ambientes de compilação.

Erro: "acesso negado" ao tentar fazer download do cache

Problema: ao tentar fazer download do cache em um projeto de compilação que tenha cache habilitado, você recebe um erro Access denied.

Causas possíveis:

  • Você acabou de configurar o armazenamento em cache como parte do projeto de compilação.

  • O cache foi invalidado recentemente por meio da API InvalidateProjectCache.

  • A função de serviço que está sendo usada por CodeBuild não tem s3:GetObject s3:PutObject permissões para o bucket do S3 que contém o cache.

Solução recomendada: para uso pela primeira vez, é normal ver isso logo depois da atualização da configuração do cache. Caso esse erro persista, é necessário verificar se a função de serviço tem permissões s3:GetObject e s3:PutObject para o bucket do S3 que está mantendo o cache. Para obter mais informações, consulte Specifying S3 permissions no Guia do desenvolvedor do Amazon S3.

Erro: "BUILD_CONTAINER_UNABLE_TO_PULL_IMAGE" ao usar uma imagem de compilação personalizada

Problema: durante a tentativa de executar uma compilação que use uma imagem de compilação personalizada, a compilação falha com o erro BUILD_CONTAINER_UNABLE_TO_PULL_IMAGE.

Possível causa: o tamanho descompactado geral da imagem de compilação é maior que o espaço em disco disponível do tipo de computação do ambiente de compilação. Para verificar o tamanho da imagem da compilação, use o Docker para executar o comando docker images REPOSITORY:TAG. Para obter uma lista de espaço em disco disponível por tipo de computação, consulte Modos e tipos de computação do ambiente de compilação.

Solução recomendada: use um tipo de computação maior com mais espaço em disco disponível ou reduza o tamanho da imagem de compilação personalizada.

Possível causa: AWS CodeBuild não tem permissão para extrair a imagem de compilação do seu Amazon Elastic Container Registry (Amazon ECR).

Solução recomendada: atualize as permissões em seu repositório no Amazon ECR para que CodeBuild você possa inserir sua imagem de compilação personalizada no ambiente de compilação. Para obter mais informações, consulte Exemplo do Amazon ECR.

Possível causa: a imagem do Amazon ECR que você solicitou não está disponível na AWS região que sua AWS conta está usando.

Solução recomendada: use uma imagem do Amazon ECR que esteja na mesma AWS região que a que sua AWS conta está usando.

Possível causa: você está usando um registro privado em uma VPC que não tem acesso público à Internet. CodeBuild não é possível extrair uma imagem de um endereço IP privado em uma VPC. Para ter mais informações, consulte Registro privado com AWS Secrets Manager amostra para CodeBuild.

Solução recomendada: se você usar um registro privado em uma VPC, verifique se a VPC tem acesso público à internet.

Possível causa: se a mensagem de erro contiver “toomanyrequests“ e a imagem for obtida do Docker Hub, esse erro significa que o limite de extração do Docker Hub foi atingido.

Solução recomendada: use um registro privado do Docker Hub ou obtenha a imagem do Amazon ECR. Para obter mais informações sobre como usar um registro privado, consulte Registro privado com AWS Secrets Manager amostra para CodeBuild. Para obter mais informações sobre como usar o Amazon ECR, consulte Amostra do Amazon ECR para CodeBuild .

Erro: “O contêiner de compilação foi encontrado inativo antes de concluir a compilação. O contêiner de compilação morreu porque estava sem memória ou a imagem do Docker não é suportada. ErrorCode: 500"

Problema: quando você tenta usar um contêiner Microsoft Windows ou Linux no AWS CodeBuild, esse erro ocorre durante a fase de PROVISIONAMENTO.

Causas possíveis:

  • A versão do sistema operacional do contêiner não é suportada pelo CodeBuild.

  • HTTP_PROXY, HTTPS_PROXY ou ambos são especificados no contêiner.

Soluções recomendadas:

  • Para o Microsoft Windows, use um contêiner do Windows com uma versão de SO do contêiner microsoft/windowsservercore:10.0.x (por exemplo, microsoft/windowsservercore:10.0.14393.2125).

  • Para o Linux, desmarque as configurações HTTPS_PROXY e HTTP_PROXY em sua imagem do Docker ou especifique a configuração da VPC no projeto de compilação.

Erro: “Cannot connect to the Docker daemon (Não é possível conectar-se ao daemon do Docker)” ao executar uma compilação

Problema: sua compilação falha e você recebe um erro semelhante a Cannot connect to the Docker daemon at unix:/var/run/docker.sock. Is the docker daemon running? no log da compilação.

Causa possível: sua compilação não está sendo executada no modo privilegiado.

Solução recomendada: para corrigir esse erro, você deve ativar o modo privilegiado e atualizar seu buildspec usando as instruções a seguir.

Para executar sua compilação no modo privilegiado, siga estas etapas:

  1. Abra o CodeBuild console em https://console.aws.amazon.com/codebuild/.

  2. No painel de navegação, escolha Criar projetos e, em seguida, escolha seu projeto de construção.

  3. Em Edit (Editar), escolha Environment (Ambiente).

  4. Escolha Additional configuration (Configuração adicional).

  5. Em Privilegiado, selecione Ativar este sinalizador se quiser criar imagens do Docker ou quiser que suas compilações tenham privilégios elevados. .

  6. Selecione Update environment (Atualizar ambiente).

  7. Selecione Start build (Iniciar compilação) para tentar novamente.

Você também precisará iniciar o daemon do Docker dentro do seu contêiner. A install fase do seu buildspec pode ser semelhante a esta.

phases: install: commands: - nohup /usr/local/bin/dockerd --host=unix:///var/run/docker.sock --host=tcp://127.0.0.1:2375 --storage-driver=overlay2 & - timeout 15 sh -c "until docker info; do echo .; sleep 1; done"

Para obter mais informações sobre o driver de armazenamento OverlayFS mencionado no arquivo buildspec, consulte Usar o driver de armazenamento OverlayFS no site do Docker.

nota

Caso o sistema operacional base seja o Alpine Linux, no arquivo buildspec.yml adicione o argumento -t em timeout:

- timeout -t 15 sh -c "until docker info; do echo .; sleep 1; done"

Para saber mais sobre como criar e executar uma imagem do Docker usando AWS CodeBuild, consulteDocker em amostra de imagem personalizada para CodeBuild .

Erro: "não CodeBuild está autorizado a executar: sts:AssumeRole" ao criar ou atualizar um projeto de compilação

Problema: ao tentar criar ou atualizar um projeto de compilação, você recebe o erro Code:InvalidInputException, Message:CodeBuild is not authorized to perform: sts:AssumeRole on arn:aws:iam::account-ID:role/service-role-name.

Causas possíveis:

  • O AWS Security Token Service (AWS STS) foi desativado para a AWS região em que você está tentando criar ou atualizar o projeto de compilação.

  • A função AWS CodeBuild de serviço associada ao projeto de compilação não existe ou não tem permissões suficientes para confiar CodeBuild.

Soluções recomendadas:

  • Certifique-se de que AWS STS está ativado para a AWS região em que você está tentando criar ou atualizar o projeto de compilação. Para obter mais informações, consulte Ativação e desativação AWS STS em uma AWS região no Guia do usuário do IAM.

  • Verifique se a função CodeBuild de serviço de destino existe em sua AWS conta. Se você não estiver usando o console, certifique-se de que não soletrou erradamente o Amazon Resource Name (ARN) da função de serviço quando criou ou atualizou o projeto de build.

  • Certifique-se de que a função CodeBuild de serviço de destino tenha permissões suficientes para confiar CodeBuild. Para obter mais informações, consulte a declaração de políticas de relacionamento de confiança em Criar um perfil de serviço do CodeBuild.

Erro: “Erro ao chamar GetBucketAcl: ou o proprietário do bucket mudou ou a função de serviço não tem mais permissão para chamar s3:GetBucketAcl”

Problema: ao executar uma compilação, você recebe um erro sobre a mudança de propriedade de um bucket do S3 e as permissões GetBucketAcl.

Possível causa: você adicionou as permissões s3:GetBucketAcl e s3:GetBucketLocation ao perfil do IAM. Essa permissões protegem o bucket do S3 de seu projeto e garantem que só você pode acessá-lo. Depois de adicionar essas permissões, o proprietário do bucket do S3 foi alterado.

Solução recomendada: verifique se você é proprietário do bucket do S3 e adicione permissões ao perfil do IAM novamente. Para ter mais informações, consulte Acesso seguro aos buckets do S3.

Erro: "Failed to upload artifacts: Invalid arn (Falha ao fazer upload de artefatos: arn inválido)” ao executar uma compilação

Problema: ao executar uma compilação, a fase UPLOAD_ARTIFACTS de compilação falha com o erro Failed to upload artifacts: Invalid arn.

Possível causa: seu bucket de saída do S3 (o bucket onde AWS CodeBuild armazena a saída da compilação) está em uma AWS região diferente do projeto de CodeBuild compilação.

Solução recomendada: atualize as configurações do projeto de compilação para apontar para um bucket de saída que esteja na mesma AWS região do projeto de compilação.

Erro: "falha do clone do Git: não é possível acessar 'your-repository-URL': problema de certificado SSL: certificado autoassinado"

Problema: ao tentar executar um projeto de compilação, a compilação falha com esse erro.

Possível causa: seu repositório de origem tem um certificado autoassinado, mas você não optou por instalar o certificado a partir de seu bucket do S3 como parte do projeto de compilação.

Soluções recomendadas:

  • Edite o projeto. Em Certificate, escolha Install certificate from S3. Em Bucket of certificate, selecione o bucket do S3 onde o certificado SSL está armazenado. Em Object key of certificate (Chave do objeto do certificado), insira o nome da chave do objeto do S3.

  • Edite o projeto. Selecione SSL inseguro para ignorar os avisos de SSL ao se conectar ao seu repositório de projetos do GitHub Enterprise Server.

    nota

    Recomendamos usar Insecure SSL somente para teste. Ele não deve ser usado em um ambiente de produção.

Erro: "The bucket you are attempting to access must be addressed using the specified endpoint (O bucket que você está tentando acessar deve ser endereçado usando o endpoint especificado)" ao executar uma compilação

Problema: ao executar uma compilação, a fase DOWNLOAD_SOURCE de compilação falha com o erro The bucket you are attempting to access must be addressed using the specified endpoint. Please send all future requests to this endpoint.

Possível causa: seu código-fonte pré-criado é armazenado em um bucket do S3 e esse bucket está em uma AWS região diferente do projeto de AWS CodeBuild compilação.

Solução recomendada: atualize as configurações do projeto de compilação para apontar para um bucket que contenha o código-fonte preexistente. Certifique-se de que o bucket esteja na mesma AWS região do projeto de construção.

Erro: "This build image requires selecting at least one runtime version" (Esta imagem de compilação requer a seleção de pelo menos um tempo de execução)

Problema: ao executar uma compilação, a fase DOWNLOAD_SOURCE de compilação falha com o erro YAML_FILE_ERROR: This build image requires selecting at least one runtime version.

Possível causa: a compilação usa a versão 1.0 ou posterior da imagem padrão do Amazon Linux 2 (AL2) ou a versão 2.0 ou posterior da imagem padrão do Ubuntu, e um tempo de execução não foi especificado no arquivo buildspec.

Solução recomendada: se você usar a imagem aws/codebuild/standard:2.0 CodeBuild gerenciada, deverá especificar uma versão de tempo de execução na runtime-versions seção do arquivo buildspec. Por exemplo, você pode usar o seguinte arquivo buildspec para um projeto que usa PHP:

version: 0.2 phases: install: runtime-versions: php: 7.3 build: commands: - php --version artifacts: files: - README.md
nota

Se você especificar uma seção runtime-versions e usar uma imagem diferente do Ubuntu Standard Image 2.0 ou posterior, ou da imagem padrão do Amazon Linux 2 (AL2) 1.0 ou posterior, a compilação emitirá o aviso “Skipping install of runtimes. Runtime version selection is not supported by this build image”.

Para ter mais informações, consulte Specify runtime versions in the buildspec file.

Erro: "QUEUED: INSUFFICIENT_SUBNET" quando ocorre uma falha em uma compilação em uma fila de compilação

Problema: ocorreu uma falha em uma compilação em uma fila de compilação com um erro semelhante a QUEUED: INSUFFICIENT_SUBNET.

Causas possíveis: o bloco CIDR IPv4 especificado para sua VPC usa um endereço IP reservado. Os primeiros quatro endereços IP e o último endereço IP em cada bloco CIDR de sub-rede não estão disponíveis para você usar e não podem ser atribuídos a uma instância. Por exemplo, em uma sub-rede com bloco CIDR 10.0.0.0/24, os seguintes cinco endereços IP são reservados:

  • 10.0.0.0: endereço de rede.

  • 10.0.0.1: reservado por AWS para o roteador VPC.

  • 10.0.0.2: Reservado por AWS. O endereço IP do servidor DNS é sempre a base do intervalo da rede VPC mais dois; no entanto, também reservamos a base de cada intervalo de sub-rede mais dois. Para VPCs com vários blocos CIDR, o endereço IP de servidor de DNS está localizado no CIDR principal. Para ter mais informações, consulte Amazon DNS server no Manual do usuário da Amazon VPC.

  • 10.0.0.3: Reservado AWS por para uso futuro.

  • 10.0.0.255: Endereço de transmissão de rede. Não oferecemos suporte à transmissão em uma VPC. Este endereço está reservado.

Soluções recomendadas: verifique se a VPC usa um endereço IP reservado. Substitua o endereço IP reservado por um que não esteja reservado. Para obter mais informações, consulte Dimensionamento da VPC e da sub-rede no Guia do usuário da Amazon VPC.

Erro: “Não foi possível baixar o cache: RequestError: Falha na solicitação de envio causada por: x509: Falha ao carregar raízes do sistema e nenhuma raiz fornecida”

Problema: ao tentar executar um projeto de compilação, a compilação falha com esse erro.

Possível causa: você configurou o armazenamento em cache como parte do projeto de compilação e está usando uma imagem de docker mais antiga que inclui um certificado raiz expirado.

Solução recomendada: atualize a imagem do Docker que está sendo usada AWS CodeBuild no seu projeto. Para ter mais informações, consulte Imagens do Docker fornecidas por CodeBuild.

Erro: “Não foi possível baixar o certificado do S3. AccessDenied”

Problema: ao tentar executar um projeto de compilação, a compilação falha com esse erro.

Causas possíveis:

  • Você escolheu o bucket do S3 errado para o seu certificado.

  • Você digitou a chave de objeto errada para o seu certificado.

Soluções recomendadas:

  • Edite o projeto. Em Bucket of certificate, selecione o bucket do S3 onde o certificado SSL está armazenado.

  • Edite o projeto. Em Object key of certificate (Chave do objeto do certificado), insira o nome da chave do objeto do S3.

Erro: "não foi possível localizar as credenciais"

Problema: ao tentar executar AWS CLI, usar um AWS SDK ou chamar outro componente similar como parte de uma compilação, você recebe erros de compilação diretamente relacionados ao AWS CLI AWS SDK ou ao componente. Por exemplo, é possível obter um erro de compilação, como Unable to locate credentials.

Causas possíveis:

  • A versão do AWS CLI AWS SDK ou componente no ambiente de compilação é incompatível com o. AWS CodeBuild

  • Você está executando um contêiner do Docker em um ambiente de compilação que usa o Docker, e o contêiner não tem acesso às AWS credenciais por padrão.

Soluções recomendadas:

  • Certifique-se de que seu ambiente de compilação tenha a seguinte versão ou superior do AWS CLI AWS SDK ou componente.

    • AWS CLI: 1.10.47

    • AWS SDK para C++: 0.2.19

    • AWS SDK para Go: 1.2.5

    • AWS SDK para Java: 1.11.16

    • AWS SDK para JavaScript: 2.4.7

    • AWS SDK para PHP: 3.18.28

    • AWS SDK para Python (Boto3): 1.4.0

    • AWS SDK para Ruby: 2.3.22

    • Botocore: 1.4.37

    • CoreCLR: 3.2.6-beta

    • Node.js: 2.4.7

  • Se você precisar executar um contêiner Docker em um ambiente de compilação e o contêiner exigir AWS credenciais, você deverá passar as credenciais do ambiente de compilação para o contêiner. No arquivo buildspec, inclua um comando run do Docker como o seguinte. Este exemplo usa o comando aws s3 ls para listar seus buckets do S3 disponíveis. A -e opção passa pelas variáveis de ambiente necessárias para que seu contêiner acesse AWS as credenciais.

    docker run -e AWS_DEFAULT_REGION -e AWS_CONTAINER_CREDENTIALS_RELATIVE_URI your-image-tag aws s3 ls
  • Se você estiver criando uma imagem do Docker e a compilação exigir AWS credenciais (por exemplo, para baixar um arquivo do Amazon S3), você deverá passar as credenciais do ambiente de criação para o processo de criação do Docker da seguinte forma.

    1. No Dockerfile do código-fonte da imagem de Docker, especifique as instruções ARG a seguir.

      ARG AWS_DEFAULT_REGION ARG AWS_CONTAINER_CREDENTIALS_RELATIVE_URI
    2. No arquivo buildspec, inclua um comando build do Docker como o seguinte. As --build-arg opções definem as variáveis de ambiente necessárias para que seu processo de criação do Docker acesse as AWS credenciais.

      docker build --build-arg AWS_DEFAULT_REGION=$AWS_DEFAULT_REGION --build-arg AWS_CONTAINER_CREDENTIALS_RELATIVE_URI=$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI -t your-image-tag .

RequestError erro de tempo limite ao executar CodeBuild em um servidor proxy

Problema: você recebe um erro RequestError semelhante a um dos seguintes:

  • RequestError: send request failed caused by: Post https://logs.<your-region>.amazonaws.com/: dial tcp 52.46.158.105:443: i/o timeoutde CloudWatch Logs.

  • Error uploading artifacts: RequestError: send request failed caused by: Put https://your-bucket.s3.your-aws-region.amazonaws.com/*: dial tcp 52.219.96.208:443: connect: connection refused do Amazon S3.

Causas possíveis:

  • O ssl-bump não está configurado corretamente.

  • A política de segurança da sua organização não permite que você use ssl_bump.

  • Seu arquivo buildspec não tem configurações de proxy especificadas usando um elemento proxy.

Soluções recomendadas:

  • Certifique-se de que o ssl-bump está configurado corretamente. Se você usar o Squid para seu servidor de proxy, consulte Configurar o Squid como um servidor de proxy explícito.

  • Siga estas etapas para usar endpoints privados para Amazon S3 CloudWatch e Logs:

    1. Na tabela de roteamento da sua sub-rede privada, remova a regra que você adicionou para rotear o tráfego destinado à Internet para o seu servidor de proxy. Para obter informações, consulte Creating a subnet in your VPC no Guia do usuário da Amazon VPC.

    2. Crie um endpoint privado do Amazon S3 e um endpoint CloudWatch Logs e associe-os à sub-rede privada do seu Amazon VPC. Para obter informações, consulte VPC endpoint services no Guia do usuário da Amazon VPC.

    3. Confirme que Habilitar nome de DNS privado na Amazon VPC está selecionada. Para obter mais informações, consulte Criar um endpoint da interface no Guia do usuário da Amazon VPC.

  • Se você não usar o ssl-bump para um servidor de proxy explícito, adicione uma configuração de proxy ao arquivo buildspec usando um elemento proxy. Para ter mais informações, consulte Executar o CodeBuild em um servidor de proxy explícito e Sintaxe de buildspec.

    version: 0.2 proxy: upload-artifacts: yes logs: yes phases: build: commands:

O bourne shell (sh) deve existir em imagens de compilação

Problema: você está usando uma imagem de compilação que não é fornecida por AWS CodeBuild, e suas compilações falham com a mensagemBuild container found dead before completing the build.

Possível causa: o shell Bourne (sh) não está incluído na sua imagem de compilação. CodeBuild precisa sh executar comandos e scripts de construção.

Solução recomendada: se sh não estiver presente na imagem de compilação, não se esqueça de incluí-lo antes de iniciar qualquer outra compilação que use a imagem. (CodeBuild já inclui sh em suas imagens de construção.)

Aviso: "ignorando a instalação de tempos de execução. A seleção de versão de tempo de execução não é compatível com esta imagem de compilação” ao executar uma compilação

Problema: ao executar uma compilação, o log de compilação contém este aviso.

Possível causa: a compilação não usa a versão 1.0 ou posterior da imagem padrão do Amazon Linux 2 (AL2) ou a versão 2.0 ou posterior da imagem padrão do Ubuntu, e um runtime foi especificado em uma seção runtime-versions no arquivo buildspec.

Solução recomendada: certifique-se de que seu arquivo buildspec não contenha uma seção runtime-versions. A seção runtime-versions só será necessária se você usar a imagem padrão do Amazon Linux 2 (AL2) ou posterior ou a imagem padrão do Ubuntu versão 2.0 ou posterior.

Erro: “Não foi possível verificar a JobWorker identidade” ao abrir o CodeBuild console

Problema: Quando você abre o CodeBuild console, uma mensagem de erro “Não foi possível verificar a JobWorker identidade” é exibida.

Possível causa: o perfil do IAM usado para acesso ao console tem uma tag com jobId como chave. Essa chave de tag está reservada CodeBuild e causará esse erro se estiver presente.

Solução recomendada: altere todas as tags personalizadas do perfil do IAM que têm a chave jobId para ter uma chave diferente, como jobIdentifier.

Falha ao iniciar a compilação

Problema: ao iniciar uma compilação, você recebe uma mensagem de erro de falha ao iniciar a compilação.

Possível causa: o número de compilações simultâneas foi atingido.

Soluções recomendadas: espere até que outras compilações sejam concluídas ou aumente o limite de compilação simultânea para o projeto e inicie a compilação novamente. Para ter mais informações, consulte Configuração de projetos.

Acessando GitHub metadados em compilações armazenadas em cache localmente

Problema: em alguns casos, o diretório .git em uma compilação em cache é um arquivo de texto e não um diretório.

Possíveis causas: Quando o cache de origem local está habilitado para uma compilação, CodeBuild cria um gitlink para o diretório. .git Isso significa que o diretório é .git, na verdade, um arquivo de texto que contém o caminho para o diretório.

Soluções recomendadas: em todos os casos, use o comando a seguir para obter o diretório de metadados do Git. Esse comando funcionará independentemente do formato de .git:

git rev-parse --git-dir

AccessDenied: O proprietário do bucket do grupo de relatórios não corresponde ao proprietário do bucket do S3...

Problema: Ao fazer o upload de dados de teste para um bucket do Amazon S3 CodeBuild , não é possível gravar os dados de teste no bucket.

Causas possíveis:

  • A conta especificada para o proprietário do bucket do grupo de relatórios não corresponde ao proprietário do bucket do Amazon S3.

  • O perfil de serviço não tem acesso de gravação ao bucket.

Soluções recomendadas:

  • Altere o proprietário do bucket do grupo de relatórios para corresponder ao proprietário do bucket do Amazon S3.

  • Modifique o perfil de serviço para conceder acesso de gravação ao bucket do Amazon S3.