Falha na Implantação

Ao implantar o seu aplicativo, você pode encontrar um erro durante a fase de criação ou implantação que cause falha na implantação. Este artigo explica como solucionar erros específicos de implantação; se o problema persistir após seguir essas etapas, consulte nossas etapas gerais de solução de problemas.

Processo de build falhou – Nenhum grupo de buildpack passou na detecção

Ao implantar um aplicativo, se houver um problema na detecção do buildpack do seu aplicativo durante o processo de build, você poderá ver o seguinte erro nos Detalhes da implantação.

Build process failed
Unknown build fail type

Clique no erro em Detalhes da implantação para ver o registro do processo de build e procure erros semelhantes a:

===> DETECTING
ERROR: No buildpack groups passed detection.
ERROR: Please check that you are running against the correct path.
ERROR: failed to detect: no buildpacks participating
ERROR: failed to build: executing lifecycle: failed with status code: 20

Esses erros ocorrem quando não há informações suficientes para detectar corretamente o tipo de aplicativo. Isso geralmente é causado por um dos seguintes motivos:

• O repositório Git não contém todos os arquivos necessários para o aplicativo.
• Algo no código ou nas configurações faz com que um buildpack incorreto seja selecionado.
• O caminho de build está incorreto.

Repositório Git

Verifique seu repositório para garantir que todos os arquivos corretos tenham sido enviados ao repositório para o seu aplicativo.

Buildpack

Se você escolher Configurar imagem do contêiner automaticamente ao adicionar o aplicativo, usaremos um buildpack para determinar e configurar automaticamente um contêiner para o aplicativo. Se o seu aplicativo exigir um buildpack adicional, você poderá adicionar outros buildpacks em Configurações do seu aplicativo.

Ao usar buildpacks, você também deve garantir que a versão correta da linguagem esteja nos arquivos do seu aplicativo. Para obter mais detalhes, consulte nossa documentação sobre como especificar uma versão de linguagem para Nixpacks ou Buildpacks.

Caminho de build

O caminho de build indica onde no repositório estão os arquivos necessários para montar seu aplicativo. Geralmente, corresponde à raiz do repositório, eliminando a necessidade de especificar um caminho de build quando você adiciona seu aplicativo.

Caso seu aplicativo exija um caminho de build específico, é possível definir esse caminho no momento da adição do aplicativo ou modificá-lo mais tarde em Configurações (Configurações > Editar detalhes > Caminho de build). Por exemplo, se for necessário compilar seu aplicativo a partir de um subdiretório denominado app, você deve inserir /app no campo Caminho de build.

Falha no processo de build: Término antecipado do processo

Ao implantar um aplicativo, se houver um problema com o processo de build, você poderá ver o seguinte erro:

A falha no build ocorreu porque o processo foi encerrado antes do previsto. Isso geralmente indica que o sistema esgotou a memória disponível ou que o processo foi interrompido forçosamente com o comando kill -9.

Esse tipo de falha é comum quando a build machine não tem memória suficiente para suportar as necessidades do aplicativo.

Para resolver esse erro, aumente o tamanho da build machine do aplicativo. Vá para Processos, clique em Atualizar build, escolha uma build machine maior e clique em Atualizar build novamente para confirmar a alteração.

Falha na implantação

Ao implantar um aplicativo, se houver um problema com a implantação, você poderá ver um dos seguintes erros:

Seu aplicativo apresentou um erro de implantação. Verifique nossa documentação e, se você continuar a ter problemas, entre em contato com nossa equipe de suporte.

Falha no processo de build
Tipo de falha de build desconhecido

Se o processo de implantação falhar imediatamente ou se o processo de build falhar, nenhum pod for criado e não houver registros de tempo de execução, a causa mais frequente será um comando start incorreto no processo web (ou um ENTRYPOINT incorreto no Dockerfile se o aplicativo for compilado a partir de um Dockerfile).

Se o processo de implantação for executado por um ou dois minutos e depois falhar, isso geralmente significa que os pods foram criados, mas algo deu errado e o processo foi interrompido. Nesse caso, você deve verificar os registros de tempo de execução do aplicativo para identificar quaisquer mensagens de erro. As mensagens de erro podem ajudá-lo a identificar erros no código do aplicativo para que você possa depurar o problema.

Se você não conseguir identificar o problema, verifique o seguinte e, se o problema persistir, entre em contato com nossa equipe de suporte.

Repositório Git

Verifique seu repositório para garantir que todos os arquivos corretos tenham sido enviados para o repositório do seu aplicativo.

Linguagem

Quando você adiciona seu aplicativo e opta por usar Nixpacks ou Buildpacks para criar a imagem do contêiner do aplicativo, determinamos e configuramos automaticamente um contêiner para o seu aplicativo. Ao usar Nixpacks ou Buildpacks, se você não quiser que a versão padrão ou a versão mais recente disponível da linguagem seja usada, deverá definir a versão da linguagem nos arquivos do aplicativo. Para obter mais detalhes, consulte nossa documentação sobre a especificação de uma versão de linguagem para Buildpacks ou a especificação de uma versão de linguagem para Nixpacks.

Além disso, se você implantar um aplicativo PHP ou Python com Nixpacks e a implantação falhar quando a imagem do contêiner for criada, isso provavelmente se deve a uma versão de linguagem ausente no código do aplicativo, especialmente se a implantação funcionar com Buildpacks, mas não com Nixpacks. Verifique o seguinte para ter certeza de que a versão da linguagem está definida:

PHP

Se houver um arquivo composer.json em seu repositório, ele deverá conter a chave require com a versão do PHP, como a seguir:

{
  "require": {
    "php": "~8.1.0"
  }
}

Python

Para especificar sua versão do Python, inclua o seguinte no arquivo runtime.txt do seu aplicativo:

python-3.10.13

Comando Start ou ENTRYPOINT

O comando Start do processo web inicia o aplicativo. Se estiver incorreto, o aplicativo não será executado. Você pode verificar o comando em alguns lugares no MyKinsta:

• Processos > Processos de tempo de execução > Processo web.
• Ou Implantações > Histórico, selecione uma implantação para visualizar os detalhes e clique em Processo de implantação em Progresso da implantação.

Se o seu aplicativo usar um Dockerfile para configurar a imagem do contêiner, você deverá especificar o endereço ENTRYPOINT no Dockerfile para executar um contêiner. Para obter mais informações sobre como especificar o ENTRYPOINT do seu aplicativo, consulte a referência do Dockerfile.

Para obter mais detalhes sobre o comando a ser usado com base na linguagem do seu aplicativo, consulte os exemplos fornecidos em nossa documentação sobre o comando start do aplicativo.

Caminho de build ou contexto de Dockerfile

Ao adicionar o seu aplicativo, você pode optar por configurar a imagem do contêiner automaticamente com um Nixpack ou um Buildpack, ou usar um Dockerfile para configurar a imagem do contêiner.

• Caminho de build: Isso se aplica apenas a Nixpacks e Buildpacks. Este é o caminho no repositório para os arquivos necessários para construir o aplicativo. A maioria dos aplicativos é construída a partir da raiz do repositório, e o Caminho de build é definido por (.). Se você tem um caminho de build diferente, especifique-o aqui. Por exemplo, se o seu aplicativo precisa ser construído a partir de um subdiretório (por exemplo, app), insira o caminho desse subdiretório no campo Caminho de build: app. Isso também é útil se você tem um monorepo.
• Contexto: Isso se aplica somente a Dockerfiles. Esse é o caminho no repositório ao qual precisamos acessar para que possamos construir seu aplicativo. A maioria dos aplicativos é criada a partir da raiz do repositório, e você pode inserir a raiz do repositório (.) no campo Contexto. Se o seu aplicativo precisar ser criado a partir de um subdiretório (por exemplo, app), insira o caminho desse subdiretório no campo Contexto: app.

Você pode visualizar e alterar o caminho de build ou o contexto do Dockerfile nas configurações do aplicativo.

Variáveis de ambiente

Variáveis de ambiente fornecem informações ao seu aplicativo de fora da execução desse aplicativo. Uma variável de ambiente incorreta pode impedir a execução do seu aplicativo. Você pode verificar suas variáveis de ambiente em Configurações > Variáveis de ambiente.

Confirme se você tem as variáveis de ambiente corretas e se elas contêm valores válidos. Há alguns aspectos importantes que você deve ter em mente ao criar e verificar as variáveis de ambiente:

• Cada chave deve ser exclusiva, e uma chave só pode ser adicionada uma vez.
• Os parênteses podem causar falha no processo de build ou de implantação, dependendo de quando estiverem disponíveis durante a implantação. Eles não podem ser usados em variáveis de ambiente.
• Vírgulas não protegidas são interpretadas como delimitadores pelo processo de implantação, portanto não podem ser usadas em variáveis de ambiente. Se precisar usar uma vírgula no valor da variável de ambiente, você deve protegê-la com uma barra invertida (\).
• Aspas duplas não protegidas são ignoradas ou causarão falha no processo de implantação. Se precisar usar aspas duplas no valor da sua variável de ambiente, você deve protegê-las com uma barra invertida (\).

Conexões internas e o processo de build

As conexões internas estão disponíveis somente durante o tempo de execução; elas não estão disponíveis durante o processo de build.

Se o seu aplicativo tentar se conectar a um banco de dados usando uma conexão interna durante o processo de build, isso causará um erro que diz que o banco de dados não está em execução, o que faz com que a build falhe. Isso é esperado porque a conexão interna não está ativa durante a build; ela só pode ser usada durante o tempo de execução.

Há algumas maneiras de contornar esse problema.

Opção 1: Mova a lógica que se conecta ao banco de dados do comando de build do aplicativo para o comando start. Por exemplo: se você tiver um comando como prisma migrate no processo de build e mover esse comando para o comando start, seu aplicativo só acessará o banco de dados durante o tempo de execução e a build será bem-sucedida.

Opção 2: Adicione variáveis de ambiente separadas conforme necessário para a conexão com o banco de dados, uma disponível para o processo de build e a outra somente para o tempo de execução. As chaves podem ser as mesmas (por exemplo, DB_CONNECTION_URL), desde que uma esteja disponível somente durante o processo de build e a outra somente durante o tempo de execução. Use os detalhes da conexão externa do banco de dados (Bancos de dados > dbname > Informações > Conexões externas) para os valores de quaisquer variáveis a serem usadas no processo de build.

Porta

Para a hospedagem de aplicativos, somente as portas 80 e 443 estão abertas. Se o seu aplicativo expõe alguma porta, você deve usar 8080.

Nome de pacote inválido

Um nome de pacote inválido no package.json pode causar um erro. Por exemplo, você não deve usar “js” ou “node” no nome. Para obter mais detalhes, consulte os detalhes do manuseio do package.json do npm nos documentos do npm.