Faça deploy de PHP na Nodion

Faça deploy de PHP passo a passo

1. Adicione o composer.json e faça commit do composer.lock A Nodion deteta PHP pelo composer.json. Um repositório que só tem um index.php não é detetado; se ainda não tiver um composer.json, basta um pequeno como este. O build executa composer install --no-dev --optimize-autoloader, por isso tudo aquilo de que a aplicação precisa em tempo de execução deve estar em require, e não em require-dev. Faça commit do composer.lock para que o build instale as versões que testou. composer.json

   {
     "require": {
       "php": "8.4.*"
     }
   }

2. Coloque os ficheiros públicos em public/ O FrankenPHP usa public/ como document root. Se não existir, a Nodion usa web/ e, se nenhum dos dois existir, a raiz do repositório. Coloque o index.php e os seus assets em public/ e mantenha vendor/, a configuração e o código-fonte ao lado, para que só sejam servidos os ficheiros destinados à web.

   composer.json
   composer.lock
   src/
   public/
     index.php

3. Escolha o servidor web O FrankenPHP é a opção por omissão e não precisa de configuração. Para usar php-fpm atrás de nginx ou Apache httpd, adicione BP_PHP_SERVER com o valor nginx ou apache no separador Environment e assinale Build. O Apache também lê os seus ficheiros .htaccess. Qualquer outro valor faz falhar o build.
4. Crie a aplicação e associe uma base de dados No dashboard, crie uma aplicação a partir do seu repositório GitHub, GitLab, Bitbucket ou Gitea, escolha o branch e a região EU Central e mantenha a estratégia de build em Buildpacks. Depois, crie uma base de dados MySQL ou PostgreSQL na mesma região e associe-a no separador Environment: a aplicação recebe DATABASE_URL no deploy seguinte, apenas em tempo de execução. Marque as palavras-passe e as chaves de API como secretas.
5. Execute as migrações em cada deploy Uma linha release: num Procfile é executada uma vez por build, depois do build e antes de a nova versão arrancar. Se falhar, o deploy é interrompido e a versão em execução continua online. Mantenha a ferramenta de migrações, por exemplo Doctrine Migrations ou Phinx, em require. Procfile

   release: vendor/bin/doctrine-migrations migrate --no-interaction

A ter em conta

• Defina uma versão fixa do PHPA Nodion lê primeiro .php-version e depois require.php no composer.json; sem nenhum dos dois, obtém PHP 8.3. Um intervalo escolhe a versão compatível mais recente, por isso "^8.2" dá PHP 8.5. Para ficar numa só linha de versões, escreva 8.3 em .php-version ou exija "8.3.*".
• SymfonyA Nodion reconhece o Symfony por bin/console em conjunto com symfony.lock, executa bin/console cache:warmup --env=prod durante o build e define APP_ENV=prod e APP_DEBUG=0 em tempo de execução. Adicione também APP_ENV=prod com a opção Build, para que os scripts do Composer executados durante a instalação não usem dev do seu .env. A Nodion não executa asset-map:compile; se usar o AssetMapper, adicione-o aos auto-scripts no composer.json. Para builds com Encore ou Vite, use um Dockerfile.
• WorkersPara um worker de filas, adicione ao Procfile uma linha como worker: php bin/worker.php juntamente com uma linha web: explícita, porque sem ela a primeira entrada do Procfile que não seja release: passa a ser o comando por omissão. O log do build mostra o comando de arranque por omissão; para o FrankenPHP, funciona web: frankenphp php-server --listen :$PORT --root public/. Depois, adicione no separador Processes um processo chamado worker sem porta.
• Caminho do health checkO tráfego passa para uma nova release assim que / responde com 2xx ou 3xx. Se / responder 401 ou 404, defina nas definições da aplicação um caminho de health check que devolva 200.

O que a Nodion gere por si

• Deploys sem downtime Faça push para o seu branch e a Nodion cria uma nova release. O tráfego só muda quando as novas instâncias passam no health check; se uma release falhar, a que está em execução mantém-se. Em vez disso, as aplicações com um volume local são reiniciadas, porque o disco pertence a uma única instância.
• Bases de dados junto à aplicação PostgreSQL, pgvector, MySQL, Valkey e ClickHouse geridos, na mesma região. As bases de dados associadas chegam como DATABASE_URL, REDIS_URL ou CLICKHOUSE_URL.
• Pré-visualizações por pull request Ative as pré-visualizações e cada pull request do seu repositório passa a ter uma aplicação própria, com URL próprio e bases de dados novas e vazias, criada automática ou manualmente. Os forks e os pull requests de bots são ignorados.
• Workers, cron jobs e escalabilidade Execute workers como processos adicionais da mesma aplicação, agende tarefas no separador Cron e escale cada processo até 16 instâncias.
• Etapa de release Com buildpacks, uma linha release: do Procfile é executada a cada novo build. As aplicações com Dockerfile, bem como os redeploys ou rollbacks para uma imagem anterior, usam um comando de release definido na própria aplicação, que também tem prioridade sobre a linha do Procfile. Nos sites estáticos, a etapa de release é executada numa imagem que contém apenas os ficheiros gerados pelo build.
• Logs e métricas Logs de build, release e runtime, além de métricas de CPU, memória, disco e rede de cada instância, no dashboard.
• Domínios e HTTPS Um hostname atribuído por omissão com HTTPS desde o primeiro deploy; os seus próprios domínios recebem certificados automaticamente.

Para saber mais

• Dockerfile vs buildpacks: qual deve escolher? Ambos transformam o seu código numa imagem de contentor. A diferença está em quem escreve os passos do build, e isso determina o controlo, a manutenção e as atualizações de segurança.
• Cloud Native Buildpacks: o que são e como funcionam Os buildpacks transformam o seu código-fonte numa imagem de contentor sem Dockerfile. O que são e como funcionam.

PHP na Nodion: perguntas e respostas