Fai il deploy di Elixir and Phoenix su Nodion

Deploy di Elixir and Phoenix passo dopo passo

1. Genera i file della release Nodion fa la build della tua app con mix release. In un progetto Phoenix, mix phx.gen.release aggiunge ciò che ti serve: un modulo Release con una funzione migrate e gli script bin/server e bin/migrate. Fai il commit dei file generati.

   mix phx.gen.release

2. Leggi la configurazione a runtime e ascolta su IPv4 Un progetto creato con mix phx.new ha già un config/runtime.exs che in produzione legge PORT, SECRET_KEY_BASE, DATABASE_URL e PHX_HOST. Le istanze delle app su Nodion usano IPv4, quindi imposta l'ip dell'endpoint su {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. Fai la build degli asset senza Node.js La build Elixir non ha Node.js. Phoenix 1.7 e versioni successive usano i binari standalone di esbuild e Tailwind, e Nodion esegue il tuo alias assets.deploy durante la build. Se la tua pipeline degli asset chiama npm, passa a questi strumenti oppure fai il deploy con un Dockerfile. mix.exs

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

4. Esegui le migrazioni dalla release Mix non è nell'immagine di runtime, quindi le migrazioni girano tramite la release, che Nodion crea in /layers/nodion_elixir/release/release. Il suo script bin/migrate del passo 1 chiama Release.migrate. Una riga release: in un Procfile viene eseguita una volta per ogni build prima che parta la nuova versione; se fallisce, la versione in esecuzione resta online. Procfile

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

5. Crea l'app, il database e le variabili segrete Crea un'applicazione dal tuo repository GitHub, GitLab, Bitbucket o Gitea nella regione EU Central e lascia la strategia di build su Buildpacks. Crea un database PostgreSQL nella stessa regione e collegalo nella scheda Environment: arriva come DATABASE_URL al deploy successivo. Aggiungi SECRET_KEY_BASE come variabile segreta, generato con mix phx.gen.secret, e imposta PHX_HOST sul dominio che aprono i tuoi utenti. Nodion imposta PORT.

Da sapere

• Fissa le versioni di Elixir ed ErlangNodion legge elixir ed erlang da .tool-versions, Elixir anche da .elixir-version. Il requisito elixir: in mix.exs è un intervallo e non fissa nessuna versione. Se non fissi una versione, ottieni Elixir 1.20 su OTP 28.
• Comando di avvio e health checkNodion avvia bin/<app> start dalla release, con il nome dell'app preso da mix.exs, e imposta PHX_SERVER=true perché l'endpoint serva HTTP. Il traffico passa appena / risponde con 2xx o 3xx; se / richiede un login, imposta un altro percorso di health check nelle impostazioni dell'app.

Cosa gestisce Nodion per te

• Deploy senza downtime Fai push sul tuo branch e Nodion crea una nuova release. Il traffico passa alle nuove istanze solo quando superano l'health check; una release fallita lascia attiva quella in esecuzione. Le app con un volume locale invece si riavviano, perché il disco appartiene a una sola istanza.
• Database accanto all'app PostgreSQL, pgvector, MySQL, Valkey e ClickHouse gestiti, nella stessa regione. I database collegati arrivano come DATABASE_URL, REDIS_URL o CLICKHOUSE_URL.
• Anteprime per ogni pull request Attiva le anteprime: ogni pull request del tuo repository riceve un'app dedicata, con un proprio URL e database nuovi e vuoti, creata automaticamente o manualmente. Le pull request dai fork e quelle dei bot vengono ignorate.
• Worker, cron job e scalabilità Esegui i worker come processi aggiuntivi della stessa app, pianifica i job nella scheda Cron e scala ogni processo fino a 16 istanze.
• Fase di release Con i buildpack, la riga release: del Procfile viene eseguita a ogni nuova build. Le app con Dockerfile, così come i redeploy e i rollback a un'immagine precedente, usano un comando di release impostato sull'app stessa, che ha anche la precedenza sulla riga del Procfile. Nei siti statici, la fase di release gira in un'immagine che contiene solo i file generati dalla build.
• Log e metriche Nella dashboard trovi log di build, release e runtime, oltre alle metriche di CPU, memoria, disco e rete per ogni istanza.
• Domini e HTTPS Un hostname predefinito con HTTPS dal primo deploy; i tuoi domini ricevono i certificati in automatico.

Per approfondire

• Dockerfile vs buildpack: quale dovresti usare? Entrambi trasformano il tuo codice in un'immagine container. Cambia chi scrive i passaggi della build, e questo determina controllo, manutenzione e aggiornamenti di sicurezza.
• Cloud Native Buildpacks: cosa sono e come funzionano I buildpack trasformano il tuo codice sorgente in un'immagine container senza Dockerfile. Cosa sono e come funzionano.

Elixir and Phoenix su Nodion: domande e risposte