o-clock-dev / teleporter-compose Goto Github PK

We should prepare the vscode, add the plugin devcontainer if missing and use devcontainer in order to use teleporter-terminal.

Afin de pouvoir router proprement sans utiliser de path, il nous faut capturer le trafic par sous domaine dans Haproxy.

A tester dans un premier temps sur Caddy.

Actuellement les IPs de chaque container sont fixés manuellement. Ca n'est pas nécéssaire et on peut fonctionner via discovery/label ou simplement via hostname qui sont déjà définies dans le compose.
Ces hostnames remontent dans tous les CT, pas de soucis de configuration donc.

Si vpn.env n'est pas là, ou vide, il faut que les liens du bas ai un autre format, actuellement on veut pas de reddit/youtube.

Use SHA or inotify

presentation interne qui doit être déplacé ailleurs.

Go back and add docker requirement.

Since last week and add feature of multi promo, VPN rarelly works.

The VPN sometimes works but with a strange source port for the client : not the one specified.

for :

• pgsql
• mongodb

clement@fedora:~/work/repo/teleporter-compose$ tree -L 1 -d
.
├── backup
├── code
├── configs
├── containers-config
├── data
└── docs

data/configs/containers-config could be optimized

Thinking about a .docker folder everything related to building docker images, don't know yet for the rest

Il faut ajouter un cli mysql pour administrer la BDD mariadb.

Deux options :

• soit directement dans le container MariaDB, ce qui assure la compatibilité client/serveur, et l'authent locale.
• soit dans le terminal, avec un .my.cnf

Dans les deux cas une authentification préenregistrée avec un .my.cnf sera un gain de temps pour tout le monde.

• rename workflow with vpn-image-generate.yml.
• trigger only if code or Docker file has changed.
• add dispatch event
• add workflow to generate image template config.

Beaucoup de craintes circulent sur l'installation des pré-requis, à savoir Docker (Desktop) sur les trois plateformes. J'imagine principalement pour Windows qui doit être le gros du troupeau.

Nous avons déjà fait quelques passes sur les trois OS, c'est plutôt simple comme installation, un exe/dmg, etc.

Je propose alors qu'on en discute ici, qu'on reprenne le temps de valider les installations sur tous les OS et faire de la documentation.
Après ça, ou pendant, on pourra trouver des cobayes pour tester et affiner.

Je vais créer un channel slack pour regrouper une partie des équipes pour qu'on puisse avoir une bonne communication et travailler ensemble notamment sur ce genre de sujets ;)

Suggestions pour passer à une approche d'une branche main pour les releases et d'une branche develop pour notre travail de groupe, PR, et aussi la génération d'image en version developpement et non directement sur latest pour ne pas faire passer en "prod" une image pas testée.

• Branches :
  • main, protégée, uniquement sur PR et pas de force push
  • develop, protégée, PR aussi comme le fonctionnement actuel sur main.
• Commit :
  • Conventional commit, sera utile par la suite et bien sur nous apporte un standard commun
• Release :
  • Automatisée via release-please : très sympa, génère tout automatiquement après une PR de release, utilise aussi des labels, génere les releases notes, etc. Se base sur conventional commit
    • Totalement soumis à débat, c'est pas forcément le plus simple à mettre en place bien que dès qu'on maîtrise ça roue tout seul !
• Images Docker :
  • Build & push bien évidemment automatisés via workflow GHA
  • Différenciation entre develop et latest
  • Dès que la PR pour merger dans la branche principale et la release automatique alors la latest est simplement marquée sur la dernière image develop validée

N'hésitez pas à commenter et à ajouter d'autres idées !

A la fin, il est sympa, il nous souhaite bonne chance. :D

You should create a branch named docker-build to process our images build and push without requesting PR to main.

Then, PR to main will be used only when new images are ready, and compose files will be updated with the good sha1 tag in the same time.

C'est ici qu'apparaitra le détail du contenu du nouveau téléporteur au fur et à mesure de l'avancée du projet.

Ce qu'il est possible d'intégrer dans le nouveau format, et ce qui ne l'est pas et devra être installé à coté sur le poste.

Utilitaires

• VPN KO

• File Browser OK

• Terminal OK

• Vscode OK

• Live share KO

Bases de données

• Mysql OK
• MongoDB OK
• PostgreSQL OK
• Adminer OK
• PhpMyAdmin OK
• Mongo express OK
• PgAdmin4 OK

Serveurs web

• Caddy

Cette issue aura pour but de voir étapes par étapes le bon process pour la mise en place du nouveau téléporteur sur chaque plateforme

Ce post sera édité au fur et a mesure de l'avancée du projet pour un résultat final a transformer sur Stonly.

Windows

Installation de Docker

Ignorer cette partie la pour l'instant et attaquer au 8

1. Lancer un invite de commande en mode administrateur
2. Saisir : wsl -install
3. Redémarrer le PC
4. Un terminal Ubuntu s'ouvre au lancement, créer un user et un mot de passe
5. sudo apt update
6. sudo apt upgrade
7. Fermer le terminal

8. Télécharger Docker et lancer l'installer :
9. Tout laisser coché par défaut et lancer l'installation
10. Redémarrer le PC
11. patcher Docker sur la derniere version ( en bas a droite de la fenêtre il proposera de la télécharger et l'installer)
12. redemarrer le PC

Mise en place du Téléporteur

1. Lancer Docker
2. Télécharger l'archive teleporteur-compose-x.x.zip
3. Extraire l'archive
4. désactiver tout antivirus temporairement
5. Lancer Start Teleporter - Windows.bat
6. Smart Screen peut apparaitre, cliquer sur Informations complémentaires et Exécuter quand même
7. Lors du build une fenêtre d'autorisation de réseau public et privé apparait, cliquer sur autoriser.
8. Le build est terminé des que [ls.io-init] done. apparait dans les lignes de commandes
9. Ne surtout pas fermer la fenêtre d'invite de commande à la fin de l'installation
10. Lancer le navigateur internet et taper dans la barre d'adresse localhost

MacOS

Installation de Docker

8. Télécharger Docker et lancer l'installer :
9. Tout laisser coché par défaut et lancer l'installation
10. patcher Docker sur la derniere version ( en bas a droite de la fenêtre il proposera de la télécharger et l'installer)

Mise en place du Téléporteur

1. Lancer Docker
2. Télécharger l'archive teleporteur-compose-x.x.zip
3. Extraire l'archive
4. désactiver tout antivirus temporairement
5. Ouvrir un terminal
6. se déplacer dans le dossier de téléchargement avec cd ~/downloads/teleporteur-compose-x.x (remplacer x.x par la version actuelle téléchargée)
7. autoriser le lancement de script avec chmod +x start-teleporter.sh
8. lancer le script avec sh start-teleporter.sh

Linux (ubuntu)

1. Lancer un terminal
2. executer sudo usermod -aG kvm $USER
3. in progress...

terminal should be available directly in the vscode running in the student poste.

Nous avions un port fixe, mais pour permettre une utilisation simultannée de plusieurs teleporter-compose, on va finallement le rendre dynamique.

We need to update the README.md with that new core/app/edu compose thing.
Also need to add teleporter-backup and check if some stuff changed around here.

Actuellement notre image VPN est un peu grosse (docker, wireguard + tools réseau) alors qu'elle est un élément critique. On va la simplifier en partant à priori d'une Alpine qui s'y prête mieux avec son orientation réseau et un simple wireguard.

En continuera à la builder pour l'entrypoint.

• Spray the joy
• Open discord server

UX test with student show it's better to automatic start every services in the docker compose.

After the initial setup, student will have to only start Docker Desktop every Day (nothink to do with Docker engine).

We should test if vscode liveshare can be activated on the web version.

Neko website

Description

Welcome to Neko, a self-hosted virtual browser that runs in Docker and uses WebRTC technology. Neko is a powerful tool that allows you to run a fully-functional browser in a virtual environment, giving you the ability to access the internet securely and privately from anywhere. With Neko, you can browse the web, run applications, and perform other tasks just as you would on a regular browser, all within a secure and isolated environment. Whether you are a developer looking to test web applications, a privacy-conscious user seeking a secure browsing experience, or simply someone who wants to take advantage of the convenience and flexibility of a virtual browser, Neko is the perfect solution.

In addition to its security and privacy features, Neko offers the ability for multiple users to access it simultaneously. This makes it an ideal solution for teams or organizations that need to share access to a browser, as well as for individuals who want to use multiple devices to access the same virtual environment. With Neko, you can easily and securely share access to a browser with others, without having to worry about maintaining separate configurations or settings. Whether you need to collaborate on a project, access shared resources, or simply want to share access to a browser with friends or family, Neko makes it easy to do so.

Neko is also a great tool for hosting watch parties and interactive presentations. With its virtual browser capabilities, Neko allows you to host watch parties and presentations that are accessible from anywhere, without the need for in-person gatherings. This makes it easy to stay connected with friends and colleagues, even when you are unable to meet in person. With Neko, you can easily host a watch party or give an interactive presentation, whether it's for leisure or work. Simply invite your guests to join the virtual environment, and you can share the screen and interact with them in real-time.

Features

Features

• Text Chat (With basic markdown support, discord flavor)
• Admin users (Kick, Ban & Force Give/Release Controls, Lock room)
• Clipboard synchronization (on supported browsers)
• Emote overlay
• Ignore user (chat and emotes)
• Persistent settings
• Automatic Login with custom url args. (add ?usr=&pwd= to the url.)
• Broadcasting room content using RTMP (to e.g. twitch or youtube...)
• Bidirectional file transfer (if enabled)

Images preview

This kind of application could help us resolve the need of sharing screen (for support) as seen in this issue #57

this image has been remove, we should use Oclock depot

Il faut bien builder et faire valider les images docker, puis les tester localement.

Il faut reload le proxy haproxy lorsque le template à été changé, ça peut se faire en envoyant un signal au processus haproxy, peut être un truc à l'intérieur de haproxy qui automatise le reload, à avoir.
Il faut trouver aussi un moyen de lancer régulièrement teleporter-templating-config.

vscode n'a pas les droits en écriture.

L'exécution du processus node est pour l'instant mal définie, je pense à quelque chose comme ça :

• il nous faut deux services, un de back et un de front, chacun son container.
• utiliser le terminal et teleport teleporteur-node pour lancer le process -> le shell est un peu pourri à voir ...
• il faut utiliser un routage par vhost pour l'accessibilité distante, peut être deux services un node-front.prenom-nom.localhost et node-back.prenom-nom.localhost.
• on proxifie ces deux services dans haproxy sans check (pour éviter les effets up and down), vers le port 3000 de chaque container.

Que ce soit OSS ou FOSS on peut déjà réfléchir à l'ouverture du code.

Réflexion à savoir sur :

• LICENCE
  • aGPL3, pour combler le loophole dans GPL pour l'utilisation du soft en SaaS (autorise la non publication du code modifié)
• CONTRIBUTING et autres pour le travail avec la communauté, en équipe
• Passage à l'Anglais, langue de référence (au moins, ça n'empêche pas de mettre en français aussi en dessous)
• Unbranding : passer en variable d'environnement tout ce qui permet de brander, enlever tout ce qui est spécifique à O'clock (exemple: logo dans homepage)
• Ouverture du code : nouveau repo et suppression de l'historique des commits qui pourrait en donner trop sur l'interne O'Clock. Moins chronophage de partir sur une codebase propre sans historique. Le projet étant encore assez récent le manque d'info dans l'historique ne se fera pas trop sentir.
• Workflow : génération de release, depandabot, scan du code et utilisation des SARIF, etc.

Autre ?

Edit:

ToDo list:

• License
• Contributing
• Unbranding
• Code opening : cleaning
• Workflow

Some containers can wait up to 10 secondes before being killed by SIGKILL (SIGTERM didn't stop them before).

Check documentation : https://docs.docker.com/compose/compose-file/05-services/#stop_grace_period

• Réécrire le README pour parler du projet sans l'orienter à 100% O'clock
• Ecrire de la documentation

Default port 80 is in conflict with an eventual already installed http aplication. So Application will not start and cause a bad experience to users.

We should bind by default another port like 1337, and redirect eventually port 80 to 1337 if port 80 is free in a second time.

Un besoin important de la part de l'équipe péda est la possibilité de visualiser l'écran de l'apprenant :

• l'accompagnement de certains apprenants en difficulté nécessite un contrôle visuel
• le teleporter compose permet d'utiliser les fonctionnalité du navigateur, et donc webrtc, et donc la possibilité d'un partage d'écran.
• un lien vers Chrome remote Desktop peut déjà rassurer les foules : https://remotedesktop.google.com/?pli=1
• A voir comment améliorer l'intégration de chrome remote pour faciliter la prise en main.
• Eventuellement un autre produit équivalent (rustdesk etc).

YAML semble indiquer de pas re-indenter sur un liste avec tiret -, cependant dans tous les exemples de compose sur le dépôt fait par docker mais aussi dans la documentation il y'a une indentation (pas de 2).

Comme on a commencé la modification sur un compose et pas l'autre, il faut faire le choix et mettre tout le dépôt à la même enseigne.

Je propose de garder la méthode antérieure et reprendre celle de Docker.

L'idée est d'ajouter les nombreuses commandes utilises, ajouter aussi des alias pour faciliter la vie des étudiants.

On a déjà l'issue sur le cli mysql : #15

Le but est donc de s'amuser avec le terminal et de remonter ici ce qu'on peut ou doit rajouter ;)

ToDo:

• #15
• Rajouter un MOTD sympatôche
• Quelques commandes en plus : welcome & backup
• etc

Il reste quelques images buildées localement qu'il faut automatiser :

• ./containers-config/filebrowser
• ./containers-config/terminal
• ./context: ./containers-config/phpmyadmin

Il faut différencier nos deux fichiers compose selon leur criticité et donc ceux qui les modifieront :

• une partie core avec avec tous les containers associés au fonctionnement vital du teleporteur compose (vpn, haproxy, homepage, terminal, filebrowser, templateconfig, autoheal).
• une partie app avec un fichier qui pourra être modifié/adapté selon les besoins et les évolutions pédagogiques (caddyserver, adminer, phpmyadmin, mongo-express, vscode-server, node, php, node, postgreSQL, MariaDB, MongoDB).

For every container, i guess.

Dans les bookmarks (homepage) la liste des étudiants est fixe pour les besoins de la présentation. Il faut à terme la générer dynamiquement.
On devrait pouvoir récupérer les prénom et nom depuis l'API du VPN et donc leurs hostnames/IP puis générer cette liste de bookmarks.
Je ne sais pas trop où l'insérer mais puisqu'on a un ct de templating ça pourrait aller la dedans (et injecter cette liste dans homepage)

Actuellement les data de MySQL sont stockées dans un mount bind.

Il n'y a pas besoin d'accéder directement à ces fichiers sur le poste hôte, il serait plus intéressant de les mettre dans un volume pour assurer une persistance et un fonctionnement plus propre et OS independant.

Faire un custom pour le 503 quand un TP n'est pas en ligne pour afficher quelque chose de plus propre.

Actuellement vpn.env est nécéssaire pour lancer le TP, il y est - vide - dans la code base pour permettre le lancement sans encombre au premier git clone

Cependant pour travailler c'est désagréable, il faut bien veiller à ne pas pousser son vpn.env quand on commit. Il faut aussi faire un copy sur un fichier déjà présent, etc.

Il faudrait que le vpn.env ne soit pas obligatoire pour lancer le compose.

Solution initiale : https://docs.docker.com/compose/environment-variables/set-environment-variables/

env_file:
  - path: ./default.env
    required: true # default
  - path: ./override.env
    required: false

Sensé marche dans la définition d'un service mais au niveau du compose (via l'include) docker compose explose (yep il pète, même pas un error ou warning, il pète).
A voir si c'est un bug ou une feature.

🇫🇷
Les bases de données doivent pourvoir être sauvegardées, il faut trouver un mécanisme de backup/restauration.

Les backups doivent être stockés dans un mount bind sur le poste apprenant, avec une rétention d'une semaine.

Pourquoi pas un stockage cloud par la suite.

Edit@Translation:

🇬🇧

Databases must be able to be backed up, and a backup/restore mechanism must be found.

Backups should be stored in a mount bind on the learner workstation, with a retention period of one week.

Why not store them in the cloud afterwards?

PostgreSQL is not ready for use : server seems to be running, cli not, and pgadmin disapear from configuration.

Some students needs it.

L'image actuelle est sous Ubuntu, et sur un repo hors organisation, il faut une image plus légère, idéalement sous Alpine et la rapatrier sur le Repo de l'orga Oclock

As we saw in issue #63, we've experienced a certain regression.

Let's think about the gradual introduction of tests. Integration, regression, unit or functional, we'll see here.

We shoud avoid using the latest tag to push an image, every build should be associated to a unique version number or tag.

After that, compose files should refer a specific tag and not the latest tag.