Realtime: Plusieurs versions

@kiwicopple ce serait une image Ubuntu avec juste l'application en temps réel installée - exposeriez-vous directement le port en temps réel ? Ou voudrions-nous toujours kong avec un seul itinéraire ? (en pensant aux apikeys/à la limitation de débit, etc.)

@soedirgo vient de parler à paul, la première étape ici consiste en fait à automatiser la création et la publication de l'application en temps réel en tant que binaire

donc peut oublier tous les trucs VM et l'océan numérique pendant un moment (bien que ce sera probablement la prochaine étape)

Ce dont nous avons besoin, c'est que chaque fois que quelqu'un marque une version , github crée l'application pour chaque environnement (pour commencer, ubuntu et osx suffisent), et crée une version avec les fichiers binaires joints (par exemple : https://github.com/ setvisible/DownZemAll/releases)

tout cela peut être réalisé avec des actions github : https://github.com/features/actions

Si vous voulez commencer par bifurquer ce référentiel et expérimenter sur votre propre bifurcation, nous pouvons alors fusionner les actions dans ce référentiel lorsque vous l'aurez mis en place et en cours d'exécution.

cela ressemble à un bon modèle pour commencer : https://github.com/actions/create-release

vous devriez commencer par simplement créer l'application en temps réel sur votre propre système d'exploitation pour avoir une idée des dépendances requises (mélange, etc.), puis voici un exemple de la façon dont l'application en temps réel est construite avec ansible, vous pourrez donc peut-être copier certaines des étapes : https://github.com/supabase/kps/blob/master/ansible/tasks/setup-supabase.yml

aussi juste pour plus de clarté, nous voulons seulement construire le serveur en temps réel pour l'instant, donc tout ce qui se trouve dans ce dossier : https://github.com/supabase/realtime/tree/master/server

@soedirgo celui-ci est terminé maintenant, n'est-ce pas ? il ne reste rien ?

Pourtant, travailler sur 3 et 4, devrait être fait aujourd'hui

tout bon! prends ton temps et dis moi si tu bloques

Ack, d'accord, c'est plus difficile que je ne le pensais. (Et je devrais arrêter de dire "aujourd'hui" ou "cette semaine")

Ce que j'ai fait:

• Construire à partir d'une image de base (tester uniquement sur DO pour l'instant)
• Laissez l'utilisateur passer des variables utilisateur pour DB_HOST , DB_PASSWORD , DB_PORT , etc. à ansible
• Créez l'application Phoenix via ansible (dans le générateur, pas l'image finale)
• Connectez-vous à une base de données à partir de DB_HOST (encore une fois, dans le constructeur)
  J'utilise un droplet supabase/postgres pour cela, et je peux seulement dire que "ça marche en quelque sorte" parce que le temps réel a dit quelque chose comme "pas de table nommée todos" quand je me suis connecté à partir de l'exemple next.js.

Bloqueurs :

• IIUC le binaire en temps réel a besoin d'envars pour fonctionner. Comment cela se fait-il généralement ? /etc/profil ? Intégrer dans un script shell ?
• J'ai besoin du temps réel pour fonctionner au démarrage. Cela semble avoir à voir avec systemd, et sur une note connexe, kps et postgres semblent utiliser des tranches systemd avec lesquelles je suis nouveau.
• Le temps réel est-il généralement sur la même machine que la base de données ? Et si oui, voulons-nous peut-être construire l'image avec une base supabase/postgres ? (Probablement pour la prochaine étape)

Petite question - cette partie me tient à cœur :

Créez l'application Phoenix via ansible (dans le générateur, pas l'image finale)

Cela signifie-t-il que vous construisez l'application Phoenix sur l'image DO ? par exemple - installer elixir/mix etc, puis exécuter une construction ?

Pour cette question :

Le temps réel est-il généralement sur la même machine que la base de données ?

Non - il s'agit d'un serveur autonome, il n'exécutera donc que realtime et se connectera à une base de données distincte spécifiée par env_vars

Cela signifie-t-il que vous construisez l'application Phoenix sur l'image DO ? par exemple - installer elixir/mix etc, puis exécuter une construction ?

Ouais, je pourrais juste obtenir un binaire à partir des versions, mais je ne sais pas si cela va causer des problèmes d'incompatibilité. (Copiait principalement comment c'était fait avec Docker)

Obtenez simplement le binaire! Diminuez la surface. Probablement mieux si nous changeons le docker pour faire la même chose - alors nous pouvons utiliser une image mince

hey @soedirgo c'est une très bonne introduction et feuille de triche pour systemctl - l'outil que nous utilisons pour gérer systemd : https://www.linode.com/docs/quick-answers/linux-essentials/introduction-to-systemctl/

voici le fichier systemctl en temps réel de KPS : https://github.com/supabase/kps/blob/master/ansible/files/supabase.service.j2

sur la question des env vars, le fichier ci-dessus montre également comment vous pouvez spécifier dans quel fichier mettre les env vars, donc peut être spécifique à l'application

sur la façon de les transmettre au moment de l'exécution/du provisionnement, nous utilisons la configuration cloud

faites défiler vers le bas et trouvez la directive write_files , nous copions simplement une chaîne de variables env dans /etc/supabase.env selon le fichier .j2 ci-dessus

Gotcha, va grok dans ceux-là!

Sur cette note, quel type de durcissement dois-je utiliser ? Juste comme un strict minimum. Je sais que postgres utilise UFW pour bloquer tout sauf 22 et 5432.

@dragarcia pourrait avoir quelques enseignements ici des processus de liste AWS et DO - j'ai vu une chose qui disait assurez-vous de ne pas utiliser les valeurs par défaut standardisées pour les graines/mots de passe sécurisés, etc.

Oui, permettez-moi de documenter une liste de contrôle pour les marchés dans lesquels nous nous trouvons jusqu'à présent et de la partager ici plus tard.

J'espère que cela t'aides!
https://github.com/supabase/home/issues/17

Génial, tout au même endroit. Merci!