Realtime: Múltiples compilaciones

Creado en 19 may. 2020  ·  16Comentarios  ·  Fuente: supabase/realtime

Por el momento, solo ofrecemos esto como una imagen acoplable. Probablemente queremos que se construyan, la versión y los artefactos se almacenen como mínimo:

Ahora:

Próximo:

  • [x] Imagen digital del océano
  • [x] imagen de AWS

Recomendación:

  • Packer: usamos Packer en @supabase/postgres y nuestro servidor KPS. Sería bueno si podemos usar lo mismo para no tener que aprender nuevas herramientas.

Comentario más útil

@soedirgo acaba de hablar con paul, el primer paso aquí es simplemente automatizar la construcción y el lanzamiento de la aplicación en tiempo real como un binario

así que puede olvidarse de todas las cosas de VM y el océano digital por un momento (aunque probablemente este sea el siguiente paso)

Lo que necesitamos es que cada vez que alguien etiquete un lanzamiento , github cree la aplicación para cada entorno (para empezar, solo ubuntu y osx están bien) y cree un lanzamiento con los archivos binarios adjuntos (por ejemplo: https://github.com/ setvisible/DownZemAll/lanzamientos)

todo esto se puede lograr con acciones de github: https://github.com/features/actions

Si desea comenzar con la bifurcación de este repositorio y experimentar con su propia bifurcación, entonces podemos fusionar las acciones nuevamente en este repositorio cuando lo tenga en funcionamiento.

esta parece una buena plantilla para comenzar: https://github.com/actions/create-release

debe comenzar simplemente creando la aplicación en tiempo real en su propio sistema operativo para tener una idea de qué dependencias se requieren (mezclar, etc.) y luego aquí hay un ejemplo de cómo la aplicación en tiempo real está construida con ansible, por lo que puede copiar algunos de los pasos: https://github.com/supabase/kps/blob/master/ansible/tasks/setup-supabase.yml

Todos 16 comentarios

@kiwicopple , esta sería una imagen de Ubuntu con solo la aplicación en tiempo real instalada. ¿Expondría el puerto en tiempo real directamente? ¿O todavía querríamos kong con ruta única? (pensando en apikeys/limitación de velocidad, etc.)

@soedirgo acaba de hablar con paul, el primer paso aquí es simplemente automatizar la construcción y el lanzamiento de la aplicación en tiempo real como un binario

así que puede olvidarse de todas las cosas de VM y el océano digital por un momento (aunque probablemente este sea el siguiente paso)

Lo que necesitamos es que cada vez que alguien etiquete un lanzamiento , github cree la aplicación para cada entorno (para empezar, solo ubuntu y osx están bien) y cree un lanzamiento con los archivos binarios adjuntos (por ejemplo: https://github.com/ setvisible/DownZemAll/lanzamientos)

todo esto se puede lograr con acciones de github: https://github.com/features/actions

Si desea comenzar con la bifurcación de este repositorio y experimentar con su propia bifurcación, entonces podemos fusionar las acciones nuevamente en este repositorio cuando lo tenga en funcionamiento.

esta parece una buena plantilla para comenzar: https://github.com/actions/create-release

debe comenzar simplemente creando la aplicación en tiempo real en su propio sistema operativo para tener una idea de qué dependencias se requieren (mezclar, etc.) y luego aquí hay un ejemplo de cómo la aplicación en tiempo real está construida con ansible, por lo que puede copiar algunos de los pasos: https://github.com/supabase/kps/blob/master/ansible/tasks/setup-supabase.yml

también solo para mayor claridad, solo queremos construir el servidor en tiempo real por ahora, así que todo lo que se encuentra dentro de esta carpeta: https://github.com/supabase/realtime/tree/master/server

@soedirgo este ya está hecho, ¿verdad? no queda nada?

Aún así, trabajar en 3 y 4, debe hacerse hoy.

¡todo bien! tómate tu tiempo y avísame si te quedas atascado

Ack, está bien, esto es más difícil de lo que pensaba. (Y debería dejar de decir "hoy" o "esta semana")

Qué he hecho:

  • Cree a partir de una imagen base (por ahora, solo prueba en DO)
  • Deje que el usuario pase variables de usuario para DB_HOST , DB_PASSWORD , DB_PORT , etc. a ansible
  • Cree la aplicación Phoenix a través de ansible (dentro del generador, no en la imagen final)
  • Conéctese a una base de datos desde DB_HOST (nuevamente, dentro del constructor)
    Estoy usando un droplet supabase/postgres para esto, y solo puedo decir que "algo así funciona" porque en tiempo real dijo algo como "ninguna tabla llamada todos" cuando me conecté desde el ejemplo next.js.

Bloqueadores:

  • IIUC el binario en tiempo real necesita envars para funcionar. ¿Cómo se suele hacer esto? /etc/perfil? ¿Incrustar en un script de shell?
  • Necesito tiempo real para ejecutar en el inicio. Parece que tiene que ver con systemd, y en una nota relacionada, kps y postgres parecen usar segmentos de systemd en los que soy nuevo.
  • ¿El tiempo real suele estar en la misma máquina que la base de datos? Y si es así, ¿quizás queramos construir la imagen con una base supabase/postgres? (Probablemente para el siguiente paso)

Pregunta rápida: esta parte me llama la atención:

Cree la aplicación Phoenix a través de ansible (dentro del generador, no en la imagen final)

¿Significa esto que está creando la aplicación phoenix en la imagen DO? por ejemplo, ¿instalar elixir/mix, etc. y luego ejecutar una compilación?

Para esta pregunta:

¿El tiempo real suele estar en la misma máquina que la base de datos?

No, este es un servidor independiente, por lo que solo ejecutará realtime y se conectará a una base de datos separada especificada por env_vars

¿Significa esto que está creando la aplicación phoenix en la imagen DO? por ejemplo, ¿instalar elixir/mix, etc. y luego ejecutar una compilación?

Sí, podría obtener un binario de los lanzamientos, pero no estoy seguro de si eso causará problemas de incompatibilidad. (Principalmente estaba copiando cómo se hace con Docker)

¡Solo obtén el binario! Disminuir el área de la superficie. Probablemente sea mejor si cambiamos la ventana acoplable para que haga lo mismo, entonces podemos usar una imagen delgada

hola @soedirgo, esta es una muy buena introducción y hoja de trucos para systemctl, la herramienta que usamos para administrar systemd: https://www.linode.com/docs/quick-answers/linux-essentials/introduction-to-systemctl/

aquí está el archivo systemctl en tiempo real de KPS: https://github.com/supabase/kps/blob/master/ansible/files/supabase.service.j2

sobre la cuestión de env vars, el archivo anterior también muestra cómo puede especificar en qué archivo colocar los env vars, por lo que puede ser específico de la aplicación

sobre cómo pasarlos en tiempo de ejecución/aprovisionamiento usamos la configuración de la nube

desplácese hacia abajo y busque la directiva write_files , básicamente copiamos una cadena de variables env en /etc/supabase.env según el archivo .j2 anterior

Gotcha, ¡asimilará esos!

En esa nota, ¿qué tipo de endurecimiento debo usar? Solo como mínimo. Sé que Postgres usa UFW para bloquear todo menos 22 y 5432.

@dragarcia podría tener algunos aprendizajes aquí de los procesos de listado de AWS y DO: vi una cosa que decía: asegúrese de no usar valores predeterminados estandarizados para semillas/contraseñas seguras, etc.

Sí, permítanme documentar una lista de verificación para los mercados en los que estamos hasta ahora y compartirla aquí más adelante.

Impresionante, todo en un solo lugar. ¡Gracias!

¿Fue útil esta página
0 / 5 - 0 calificaciones

Temas relacionados

awalias picture awalias  ·  5Comentarios

awalias picture awalias  ·  6Comentarios

kiwicopple picture kiwicopple  ·  14Comentarios

kwakwaversal picture kwakwaversal  ·  6Comentarios

awalias picture awalias  ·  9Comentarios