Elixir and Phoenix auf Nodion deployen

Elixir and Phoenix Schritt für Schritt deployen

1. Release-Dateien erzeugen Nodion baut deine App mit mix release. In einem Phoenix-Projekt ergänzt mix phx.gen.release, was du dafür brauchst: ein Release-Modul mit einer Funktion migrate und die Skripte bin/server und bin/migrate. Committe die erzeugten Dateien.

   mix phx.gen.release

2. Config zur Laufzeit lesen und auf IPv4 lauschen Ein Projekt aus mix phx.new hat schon eine config/runtime.exs, die in Production PORT, SECRET_KEY_BASE, DATABASE_URL und PHX_HOST liest. Die App-Instanzen von Nodion nutzen IPv4, setz also ip im Endpoint auf {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. Assets ohne Node.js bauen Im Elixir-Build gibt es kein Node.js. Phoenix 1.7 und neuer nutzen eigenständige esbuild- und Tailwind-Binaries, und Nodion führt deinen Alias assets.deploy im Build aus. Ruft deine Asset-Pipeline npm auf, stell sie auf diese Tools um oder deploye mit einem Dockerfile. mix.exs

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

4. Migrationen über das Release ausführen Mix ist nicht im Run-Image, Migrationen laufen deshalb über das Release, das Nodion nach /layers/nodion_elixir/release/release baut. Dessen Skript bin/migrate aus Schritt 1 ruft Release.migrate auf. Eine release:-Zeile in einer Procfile läuft bei jedem Build einmal, bevor die neue Version startet; scheitert sie, bleibt die laufende Version live. Procfile

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

5. App, Datenbank und Secrets anlegen Lege eine Application aus deinem GitHub-, GitLab-, Bitbucket- oder Gitea-Repository in der Region EU Central an und lass die Build-Strategie auf Buildpacks. Leg eine PostgreSQL-Datenbank in derselben Region an und hänge sie auf dem Tab Environment an: Sie kommt beim nächsten Deploy als DATABASE_URL an. Leg SECRET_KEY_BASE aus mix phx.gen.secret als Secret an und setz PHX_HOST auf die Domain, die deine Nutzer aufrufen. PORT setzt Nodion.

Gut zu wissen

• Elixir und Erlang pinnenNodion liest elixir und erlang aus der .tool-versions, Elixir auch aus .elixir-version. Die Anforderung elixir: in der mix.exs ist ein Bereich und pinnt nichts. Ohne Pin bekommst du Elixir 1.20 auf OTP 28.
• Startbefehl und Health CheckNodion startet bin/<app> start aus dem Release, mit dem App-Namen aus der mix.exs, und setzt PHX_SERVER=true, damit der Endpoint HTTP ausliefert. Der Traffic wechselt, sobald / mit 2xx oder 3xx antwortet; braucht / einen Login, trag in den App-Einstellungen einen anderen Health-Check-Pfad ein.

Was Nodion für dich betreibt

• Deploys ohne Downtime Push auf deinen Branch und Nodion baut ein neues Release. Der Traffic wechselt erst, wenn die neuen Instanzen ihren Health Check bestehen; ein fehlgeschlagenes Release lässt das laufende stehen. Apps mit lokalem Volume starten stattdessen neu, weil die Disk zu einer Instanz gehört.
• Datenbanken neben der App Managed PostgreSQL, pgvector, MySQL, Valkey und ClickHouse in derselben Region. Angehängte Datenbanken kommen als DATABASE_URL, REDIS_URL oder CLICKHOUSE_URL in die App.
• Previews pro Pull Request Schalte Previews ein, und Pull Requests aus deinem Repository bekommen eine eigene App mit eigener URL und frischen, leeren Datenbanken, automatisch oder per Hand angelegt. Forks und Bot-Pull-Requests werden übersprungen.
• Worker, Cron Jobs und Skalierung Worker laufen als weitere Prozesse derselben App, Jobs planst du auf dem Tab Cron, und jeden Prozess skalierst du auf bis zu 16 Instanzen.
• Release-Schritt Mit Buildpacks läuft eine release:-Zeile in der Procfile bei jedem neuen Build. Dockerfile-Apps sowie Redeploys und Rollbacks auf ein früheres Image nutzen einen Release Command, der an der App selbst gesetzt ist; er hat auch Vorrang vor der Procfile-Zeile. Bei statischen Sites läuft ein Release-Schritt in einem Image, das nur die gebauten Dateien enthält.
• Logs und Metriken Build-, Release- und Laufzeit-Logs sowie CPU-, Speicher-, Disk- und Netzwerk-Metriken für jede Instanz im Dashboard.
• Domains und HTTPS Ein Default-Hostname mit HTTPS ab dem ersten Deploy; deine eigenen Domains bekommen automatisch Zertifikate.

Weiterlesen

• Dockerfile vs Buildpacks: was solltest du nutzen? Beide machen aus deinem Code ein Container-Image. Der Unterschied ist, wer die Build-Schritte schreibt, und das entscheidet über Kontrolle, Wartung und Security-Updates.
• Cloud Native Buildpacks erklärt Buildpacks machen aus deinem Quellcode ein Container-Image ohne Dockerfile. Was sie sind und wie sie funktionieren.

Elixir and Phoenix auf Nodion: Fragen und Antworten