Déployez Elixir and Phoenix sur Nodion

Déployez Elixir and Phoenix étape par étape

1. Générez les fichiers de release Nodion construit votre app avec mix release. Dans un projet Phoenix, mix phx.gen.release ajoute ce qu'il faut pour cela : un module Release avec une fonction migrate et les scripts bin/server et bin/migrate. Commitez les fichiers générés.

   mix phx.gen.release

2. Lisez la config à l'exécution et écoutez en IPv4 Un projet créé avec mix phx.new contient déjà un config/runtime.exs qui lit PORT, SECRET_KEY_BASE, DATABASE_URL et PHX_HOST en production. Les instances d'app de Nodion utilisent IPv4 : définissez donc l'ip de l'endpoint sur {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. Compilez les assets sans Node.js Le build Elixir ne contient pas Node.js. Phoenix 1.7 et les versions suivantes utilisent les binaires autonomes d'esbuild et de Tailwind, et Nodion exécute votre alias assets.deploy pendant le build. Si votre pipeline d'assets appelle npm, passez à ces outils ou déployez avec un Dockerfile. mix.exs

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

4. Exécutez les migrations depuis la release Mix ne fait pas partie de l'image d'exécution : les migrations passent donc par la release, que Nodion construit dans /layers/nodion_elixir/release/release. Son script bin/migrate de l'étape 1 appelle Release.migrate. Une ligne release: dans un Procfile s'exécute une fois par build avant le démarrage de la nouvelle version ; si elle échoue, la version en cours reste en ligne. Procfile

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

5. Créez l'app, la base de données et les secrets Créez une application depuis votre dépôt GitHub, GitLab, Bitbucket ou Gitea dans la région EU Central et laissez la stratégie de build sur Buildpacks. Créez une base de données PostgreSQL dans la même région et rattachez-la dans l'onglet Environment : elle arrive sous la forme de DATABASE_URL au déploiement suivant. Ajoutez comme secret SECRET_KEY_BASE, généré avec mix phx.gen.secret, et définissez PHX_HOST sur le domaine qu'ouvrent vos utilisateurs. PORT est défini par Nodion.

Bon à savoir

• Fixez les versions d'Elixir et d'ErlangNodion lit elixir et erlang dans .tool-versions, et Elixir aussi dans .elixir-version. L'exigence elixir: de mix.exs est une plage et ne fixe aucune version. Sans version fixée, vous obtenez Elixir 1.20 sur OTP 28.
• Commande de démarrage et health checkNodion lance bin/<app> start depuis la release, avec le nom d'app tiré de mix.exs, et définit PHX_SERVER=true pour que l'endpoint serve du HTTP. Le trafic bascule dès que / renvoie un code 2xx ou 3xx ; si / exige une connexion, définissez un autre chemin de health check dans les paramètres de l'app.

Ce que Nodion gère pour vous

• Déploiements sans interruption Faites un push sur votre branche : Nodion construit une nouvelle release. Le trafic bascule lorsque les nouvelles instances réussissent leur health check ; si la release échoue, celle en cours reste active. Les apps avec un volume local redémarrent, car le disque appartient à une seule instance.
• Bases de données à côté de l'app PostgreSQL, pgvector, MySQL, Valkey et ClickHouse managés, dans la même région. Les bases de données rattachées arrivent sous forme de DATABASE_URL, REDIS_URL ou CLICKHOUSE_URL.
• Previews par pull request Activez les previews, et les pull requests de votre dépôt obtiennent leur propre app, avec sa propre URL et des bases de données neuves et vides, créées automatiquement ou à la main. Les pull requests issues de forks ou de bots sont ignorées.
• Workers, cron jobs et mise à l'échelle Exécutez les workers comme processus supplémentaires de la même app, planifiez des tâches dans l'onglet Cron et mettez chaque processus à l'échelle jusqu'à 16 instances.
• Étape de release Avec les buildpacks, une ligne release: du Procfile s'exécute à chaque nouveau build. Les apps Dockerfile, ainsi que les redéploiements ou les rollbacks vers une image antérieure, utilisent une commande de release définie sur l'app elle-même, qui prime aussi sur la ligne du Procfile. Sur les sites statiques, l'étape de release s'exécute dans une image qui ne contient que les fichiers générés par le build.
• Logs et métriques Logs de build, de release et d'exécution, ainsi que les métriques CPU, mémoire, disque et réseau de chaque instance, dans le dashboard.
• Domaines et HTTPS Un nom d'hôte par défaut avec HTTPS dès le premier déploiement, et des certificats automatiques pour vos propres domaines.

Pour aller plus loin

• Dockerfile vs buildpacks : lequel choisir ? Les deux transforment votre code en image de conteneur. La différence, c'est qui écrit les étapes du build, et cela détermine le contrôle, la maintenance et les mises à jour de sécurité.
• Les Cloud Native Buildpacks expliqués Les buildpacks transforment votre code source en image de conteneur sans Dockerfile. Ce qu'ils sont et comment ils fonctionnent.

Elixir and Phoenix sur Nodion : questions et réponses