Despliega Elixir and Phoenix en Nodion

Despliega Elixir and Phoenix paso a paso

1. Genera los archivos de la release Nodion construye tu app con mix release. En un proyecto Phoenix, mix phx.gen.release añade lo que necesitas para ello: un módulo Release con una función migrate y los scripts bin/server y bin/migrate. Haz commit de los archivos generados.

   mix phx.gen.release

2. Lee la configuración en tiempo de ejecución y escucha en IPv4 Un proyecto creado con mix phx.new ya tiene un config/runtime.exs que en producción lee PORT, SECRET_KEY_BASE, DATABASE_URL y PHX_HOST. Las instancias de las apps en Nodion usan IPv4, así que define la ip del 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. Haz la build de los assets sin Node.js La build de Elixir no tiene Node.js. Phoenix 1.7 y versiones posteriores usan los binarios independientes de esbuild y Tailwind, y Nodion ejecuta tu alias assets.deploy durante la build. Si tu pipeline de assets llama a npm, pásate a estas herramientas o despliega con un Dockerfile. mix.exs

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

4. Ejecuta las migraciones desde la release Mix no está en la imagen de runtime, así que las migraciones se ejecutan a través de la release, que Nodion construye en /layers/nodion_elixir/release/release. Su script bin/migrate del paso 1 llama a Release.migrate. Una línea release: en un Procfile se ejecuta una vez por build antes de que arranque la nueva versión; si falla, la versión en ejecución sigue activa. Procfile

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

5. Crea la app, la base de datos y los secretos Crea una aplicación desde tu repositorio de GitHub, GitLab, Bitbucket o Gitea en la región EU Central y deja la estrategia de build en Buildpacks. Crea una base de datos PostgreSQL en la misma región y vincúlala en la pestaña Environment: la app recibe DATABASE_URL en el siguiente despliegue. Añade como variable secreta SECRET_KEY_BASE, generada con mix phx.gen.secret, y define PHX_HOST con el dominio que abren tus usuarios. PORT lo define Nodion.

A tener en cuenta

• Fija Elixir y ErlangNodion lee elixir y erlang de .tool-versions, y Elixir también de .elixir-version. El requisito elixir: de mix.exs es un rango y no fija nada. Si no fijas ninguna versión, obtienes Elixir 1.20 sobre OTP 28.
• Comando de arranque y health checkNodion arranca bin/<app> start desde la release, con el nombre de la app que figura en mix.exs, y define PHX_SERVER=true para que el endpoint sirva HTTP. El tráfico pasa a la nueva versión en cuanto / responde con 2xx o 3xx; si / requiere iniciar sesión, define otra ruta de health check en los ajustes de la app.

Lo que Nodion gestiona por ti

• Despliegues sin downtime Haz push a tu rama y Nodion construye una nueva release. El tráfico pasa a las nuevas instancias cuando superan el health check; si una release falla, la que está en marcha sigue activa. En cambio, las apps con un volumen local se reinician porque el disco pertenece a una sola instancia.
• Bases de datos junto a la app PostgreSQL, pgvector, MySQL, Valkey y ClickHouse gestionados en la misma región. Al vincular una base de datos, sus datos de conexión llegan como DATABASE_URL, REDIS_URL o CLICKHOUSE_URL.
• Previews por pull request Activa las previews: cada pull request de tu repositorio tendrá su propia app, con URL y bases de datos nuevas y vacías. Puedes crearla automáticamente o a mano. Se omiten las pull requests de forks y bots.
• Workers, cron jobs y escalado Ejecuta workers como procesos adicionales de la misma app, programa tareas en la pestaña Cron y escala cada proceso hasta 16 instancias.
• Paso de release Con buildpacks, una línea release: del Procfile se ejecuta con cada nueva build. Las apps con Dockerfile, así como los redeploys o rollbacks a una imagen anterior, usan un comando de release definido en la propia app, que además tiene prioridad sobre la línea del Procfile. En los sitios estáticos, el paso de release se ejecuta en una imagen que solo contiene los archivos generados por la build.
• Logs y métricas Logs de build, release y runtime, además de métricas de CPU, memoria, disco y red de cada instancia, en el dashboard.
• Dominios y HTTPS Un nombre de host predeterminado con HTTPS desde el primer despliegue; tus propios dominios reciben certificados automáticamente.

Para seguir leyendo

• Dockerfile vs buildpacks: ¿cuál deberías usar? Los dos convierten tu código en una imagen de contenedor. Lo que cambia es quién escribe los pasos de la build, y eso decide el control, el mantenimiento y las actualizaciones de seguridad.
• Cloud Native Buildpacks: qué son y cómo funcionan Los buildpacks convierten tu código fuente en una imagen de contenedor sin Dockerfile. Te explicamos qué son y cómo funcionan.

Elixir and Phoenix en Nodion: preguntas y respuestas