Falha no Processo de Implantação

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

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

Falha no processo de build
Tipo de falha de build desconhecida

Se o processo de implantação falhar imediatamente ou se o processo de build falhar, nenhum pod é criado e os registros de tempo de execução não existem, a causa mais comum é um comando start incorreto no processo da web (ou um ENTRYPOINT incorreto no Dockerfile, caso seu aplicativo for construído a partir de um Dockerfile).

Se o processo de implantação funciona por um minuto ou dois e depois falha, isso geralmente significa que as Pods foram criadas, mas algo deu errado, e o processo parou. Neste caso, você deve verificar os registros de tempo de execução do aplicativo para identificar qualquer mensagem de erro. As mensagens de erro podem ajudá-lo a identificar bugs no código do aplicativo para que você possa depurar o problema.

Se você não conseguir identificar o problema, por favor 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 foram movidos para o repositório do seu aplicativo.

Linguagem

Ao adicionar seu aplicativo e optar por usar Nixpacks ou Buildpacks para criar a imagem do contêiner do seu aplicativo, determinamos e configuramos automaticamente um contêiner para o seu aplicativo. Ao usar Nixpacks ou Buildpacks, se você não desejar a versão padrão ou mais recente da linguagem a ser usada, você deve definir a versão da linguagem nos arquivos do seu aplicativo. Para mais detalhes, consulte nossa documentação sobre especificação de uma versão de linguagem para Buildpacks ou especificação de uma versão de linguagem para Nixpacks.

Além disso, se você implantar um aplicativo em PHP ou Python com Nixpacks e a reversão falhar quando a imagem do contêiner estiver sendo construída, isso provavelmente se deve à falta de uma versão da linguagem no código do aplicativo, especialmente se a implantação funcionar com Buildpacks, mas não com Nixpacks. Verifique o seguinte para assegurar que a versão da linguagem esteja definida:

PHP

Se houver um arquivo composer.json no seu repositório, ele deve 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 para o processo da web inicia seu aplicativo. Se isso estiver incorreto, o aplicativo não será executado. Você pode verificar o comando em alguns lugares no MyKinsta:

Processos > Tempo de execução de Processos > Processo da web.
Ou Implantações > Histórico, selecione uma implantação para ver os detalhes e clique em Processo de implantação sob o progresso da implantação.

Processo de implantação bem-sucedido nos detalhes de implantação.

Falha no processo de implantação nos detalhes de implantação.

Caso o seu aplicativo usa um Dockerfile para configurar a imagem do seu contêiner, você deve especificar o ENTRYPOINT no Dockerfile para executar um contêiner. Para mais informações sobre como especificar o ENTRYPOINT do seu aplicativo, veja a referência do Dockerfile.

Para mais detalhes sobre qual comando usar baseado na linguagem do seu aplicativo, veja os exemplos fornecidos em nossa documentação do Comando Start de Aplicativos.

Caminho de build ou contexto do Dockerfile

Ao adicionar seu aplicativo, você escolhe entre configurar automaticamente a imagem do contêiner com um Nixpacks 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 como padrão para isso (.). Se você tiver um caminho de Build diferente, especifique aqui. Por exemplo, se o seu aplicativo precisar ser construído a partir de um subdiretório (por exemplo, app), insira o caminho do subdiretório no campo Caminho de build: app. Isso também é útil se você tiver um monorepo.
Contexto: Isso se aplica apenas aos arquivos Dockerfile. Este é o caminho no repositório ao qual precisamos ter acesso para que possamos construir o seu aplicativo. A maioria dos aplicativos é construída 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 construído a partir de um subdiretório (por exemplo, app), insira o caminho do subdiretório no campo Contexto: app.

Você pode visualizar e alterar o Caminho de build ou Contexto do Dockerfile nas Configurações do seu aplicativo.

Variáveis de ambiente

Variáveis de ambiente fornecem ao aplicativo informações externas para a execução do mesmo. Uma variável de ambiente incorreta pode impedir que o seu aplicativo seja executada. Você pode verificar suas variáveis de ambiente em Configurações > Variáveis de ambiente.

Confirme que as variáveis de ambiente corretas existem e contêm valores válidos. Há algumas coisas importantes a considerar ao criar e verificar variáveis de ambiente:

Cada chave deve ser única e só pode ser adicionada uma vez.
Parênteses podem causar falha no processo de build ou implantação, dependendo de quando estão disponíveis durante a implantação. Eles não podem ser usados em variáveis de ambiente.
Vírgulas não escapadas são interpretadas como delimitadores pelo processo de implantação, por isso não podem ser usadas em variáveis de ambiente. Se precisar usar uma vírgula no valor da sua variável de ambiente, você deve escapá-la com uma barra invertida (\).
Aspas duplas não escapadas 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 escapá-las com uma barra invertida (\).

Conexões internas e processo de build

Conexões internas estão disponíveis apenas durante a 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 dizendo que o banco de dados não está em execução, o que fará 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 a execução.

Existem algumas maneiras de contornar isso.

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ê tem um comando como prisma migrate no processo de build, mova esse comando para o comando start. Assim, o seu aplicativo só acessará o banco de dados durante a execução, e a build será bem-sucedida.

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

Porta

Para hospedagem de Aplicativos, somente as portas 80 e 443 estão abertas. Se o seu aplicativo expuser quaisquer portas, você deve usar a porta 8080.

Nome do Pacote Inválido

Um nome de pacote inválido no arquivo package.json pode causar um erro. Por exemplo, não use “js” ou “node” no nome. Para obter mais informações, consulte os detalhes do tratamento do package.json pelo npm na documentação do npm.

Soluções

Benefícios