Faça deploy de Elixir and Phoenix na Nodion

Faça deploy de Elixir and Phoenix passo a passo

1. Gere os ficheiros da release A Nodion faz o build da sua aplicação com mix release. Num projeto Phoenix, mix phx.gen.release adiciona o que é necessário para isso: um módulo Release com uma função migrate e os scripts bin/server e bin/migrate. Faça commit dos ficheiros gerados.

   mix phx.gen.release

2. Leia a configuração em tempo de execução e escute em IPv4 Um projeto criado com mix phx.new já tem um config/runtime.exs que, em produção, lê PORT, SECRET_KEY_BASE, DATABASE_URL e PHX_HOST. As instâncias das aplicações na Nodion usam IPv4, por isso defina o ip do endpoint como {0, 0, 0, 0}: config/runtime.exs

   config :my_app, MyAppWeb.Endpoint,
     url: [host: host, port: 443, scheme: "https"],
     http: [ip: {0, 0, 0, 0}, port: port],
     secret_key_base: secret_key_base

3. Faça o build dos assets sem Node.js O build de Elixir não tem Node.js. O Phoenix 1.7 e as versões posteriores usam os binários autónomos de esbuild e Tailwind, e a Nodion executa o seu alias assets.deploy durante o build. Se a sua pipeline de assets chamar o npm, passe para estas ferramentas ou faça deploy com um Dockerfile. mix.exs

   "assets.deploy": [
     "tailwind my_app --minify",
     "esbuild my_app --minify",
     "phx.digest"
   ]

4. Execute as migrações a partir da release O Mix não está na imagem de execução, por isso as migrações são executadas através da release, que a Nodion cria em /layers/nodion_elixir/release/release. O script bin/migrate dessa release, do passo 1, chama Release.migrate. Uma linha release: num Procfile é executada uma vez por build antes de a nova versão arrancar; se falhar, a versão em execução continua online. Procfile

   release: /layers/nodion_elixir/release/release/bin/migrate

5. Crie a aplicação, a base de dados e os segredos Crie uma aplicação a partir do seu repositório GitHub, GitLab, Bitbucket ou Gitea na região EU Central e mantenha a estratégia de build em Buildpacks. Crie uma base de dados PostgreSQL na mesma região e associe-a no separador Environment: chega como DATABASE_URL no deploy seguinte. Adicione como variável secreta SECRET_KEY_BASE, gerada com mix phx.gen.secret, e defina PHX_HOST com o domínio que os seus utilizadores abrem. A PORT é definida pela Nodion.

A ter em conta

• Defina versões fixas do Elixir e do ErlangA Nodion lê elixir e erlang de .tool-versions, e o Elixir também de .elixir-version. O requisito elixir: em mix.exs é um intervalo e não fixa nada. Sem versão fixada, obtém Elixir 1.20 sobre OTP 28.
• Comando de arranque e health checkA Nodion arranca bin/<app> start a partir da release, com o nome da aplicação indicado em mix.exs, e define PHX_SERVER=true para que o endpoint sirva HTTP. O tráfego passa para a nova versão assim que / responde com 2xx ou 3xx; se / exigir início de sessão, defina outro caminho de health check nas definições da aplicação.

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.

Elixir and Phoenix na Nodion: perguntas e respostas