Déployer une application web depuis GitHub : Python, Node, Go, Java ou site statique

Partir d’un exemple

La page « Déploiements » propose une application d’exemple, File uploads, en Node, Python, Go et Java, la même dans chaque langage pour les comparer : vous importez un fichier, il est stocké dans S3, et son emplacement est enregistré dans Postgres. Appuyez sur « Déployer cet exemple » : tout ce dont elle a besoin, une base de données et une pile cloud, est créé pour vous, puis l’application est mise en ligne, déjà reliée aux deux. Rien à configurer au préalable, aucune chaîne de connexion à copier. « Remplir le formulaire » sert dans l’autre cas : pour changer de dépôt ou de branche avant la mise en ligne.

L’exemple est visible avant même toute connexion : une personne qui hésite à donner son adresse e-mail peut d’abord voir une application tourner pour de bon. Rien n’est créé tant que personne n’a appuyé sur le bouton, si bien que cela n’entame le temps d’application de personne. Un élève qui possède déjà une base de données ou une pile cloud réutilise la sienne au lieu d’en recevoir une deuxième.

Le code est public et mérite d’être lu : il est court, et le README explique les trois points sur lesquels les élèves se trompent d’abord : adresser S3 par nom d’hôte plutôt que par chemin, créer son propre bucket, la pile cloud démarrant vide, et écrire le fichier dans S3 avant la ligne dans la base de données, pour qu’un échec ne laisse jamais sur la page un fichier impossible à ouvrir.

Si vous préférez ne pas le voir, appuyez sur « Masquer » sur sa ligne : il ne vous sera plus proposé.

Essayer sans compte

Personne n’a besoin d’un compte pour voir l’application fonctionner. Appuyer sur « Déployer », ou sur « Créer » dans l’onglet « Base de données » ou « Cloud », crée un compte temporaire dans ce navigateur et le connecte. Un invité a ses propres limites, qu’un administrateur système peut modifier : son compte est conservé 24 heures après sa dernière utilisation, chaque déploiement dure 30 minutes au maximum, et il peut faire 2 déploiements au total et avoir 1 base de données, avec une pile cloud en plus qui ne compte pas dans la limite des bases de données.

Un invité ne peut inviter personne à voir une application, car une invitation est un lien qu’envoie une personne nommée, ni déployer un dépôt privé, car un jeton stocké sur un compte que personne ne peut retrouver ne pourrait jamais être retiré. « Conserver ce compte » demande une adresse e-mail et un code, puis fait de ce même compte le leur, avec tout ce qu’il a déployé. Un invité auquel personne ne revient est supprimé avec ses applications, ses bases de données, ses fichiers et ses labs de conteneurs enregistrés.

Ce que l’élève renseigne

Un dépôt GitHub et une branche, le langage, une commande de build et une commande de démarrage. Le champ contient déjà de quoi déployer : le dernier dépôt de l’élève ou, pour qui n’a jamais déployé, l’un des nôtres pour le langage choisi (hello-flask, hello-node, hello-go, hello-spring ou hello-static), si bien que le premier essai fonctionne et que le deuxième est le leur. Changer de langage remplace un exemple par un autre sans jamais écraser ce que l’élève a saisi.

Un dépôt privé fonctionne aussi. Cochez « Ce dépôt est privé » sous le champ du dépôt et collez un jeton GitHub : un jeton d’accès personnel à granularité fine, limité à ce seul dépôt, en lecture seule et assorti d’une date d’expiration. Il est stocké chiffré, n’est plus jamais affiché à personne et sert uniquement à récupérer le code. Il n’est jamais transmis à l’application en cours d’exécution : rien de ce que l’élève déploie ne peut donc le lire, et la personne qui corrige le travail s’en sert pour construire l’application sans jamais le voir. Décochez la case pour le retirer.

Les réglages que l’application lit dans son environnement se saisissent dans le même formulaire, en lignes composées d’un nom et d’une valeur : 20 au plus, de 4 Ko chacune au plus. PORT et les noms propres à l’environnement d’exécution sont refusés. Ils sont stockés chiffrés et ne sont plus montrés à personne une fois enregistrés : la page affiche des puces, avec « Remplacer » et « Retirer ». Un rendu pointe vers le déploiement enregistré : la personne qui corrige déploie donc l’application avec les variables de l’élève et n’en voit que les noms. Une variable DATABASE_URL saisie à côté d’une base de données choisie dans le formulaire est refusée, avec une phrase qui indique laquelle retirer.

L’application doit écouter sur le port qui lui est attribué : c’est la seule vraie leçon de l’exercice, et celle que toute plateforme d’hébergement finit par enseigner à ses dépens.

Deux cases du même formulaire lui donnent davantage de ressources : une base de données personnelle, et une pile cloud comprenant un stockage d’objets, une table NoSQL et une file de messages. Les deux démarrent avec l’application et définissent leurs propres variables : un devoir peut ainsi demander une application qui enregistre ce que les utilisateurs importent, et pas seulement une page qui s’affiche.

Les langages pris en charge

On peut déployer Python, Node, Go, Java et des sites statiques en HTML, CSS et JavaScript, et rien d’autre : chaque langage est construit et exécuté dans un conteneur dédié, qui n’a accès qu’à son propre registre de paquets. Python tourne sous gunicorn, si bien que Flask et Django fonctionnent tous deux ; Node exécute ce que lance son script start ; Go et Java sont compilés depuis les sources, Java sous forme d’application Spring Boot ; un site statique est servi exactement tel qu’il se trouve dans le dépôt.

Pour chaque langage, le formulaire est prérempli avec l’un de nos dépôts d’exemple fonctionnels : un élève qui n’a jamais rien déployé dispose ainsi d’un point de départ.

Un site statique est le plus restreint : il n’installe rien, si bien que sa construction n’accède qu’à GitHub et à aucun autre hôte. Sa commande de build vérifie qu’il y a un index.html à la racine du dépôt, car des pages rangées dans docs/ ou dist/ se déploieraient sans erreur puis afficheraient une liste de fichiers. Pour servir un sous-dossier, ajoutez --directory suivi de son nom à la commande de démarrage au lieu de déplacer les pages.

Où elle tourne, et qui peut la voir

Chaque application reçoit sa propre URL sous learntools.dev : deux mots et un nombre, ou un nom que l’élève choisit et conserve, si bien qu’un lien indiqué sur son CV fonctionne encore lors de son prochain déploiement. Une adresse choisie lui reste réservée jusqu’à ce qu’il la supprime, et personne d’autre ne peut prendre une adresse déjà réservée.

Personne ne peut accéder à une application en devinant son adresse. L’élève invite jusqu’à 5 personnes par e-mail ; chacune suit un lien et confirme un code envoyé à cette même adresse : une invitation ne peut donc pas être transférée. L’élève, lui, accède à son application depuis sa page.

Le personnel peut arrêter une application. Un administrateur système peut arrêter n’importe quelle application, base de données ou pile cloud ; tout membre du personnel d’un établissement peut arrêter celle d’un élève de cet établissement, et pas seulement l’administrateur de l’établissement, car c’est l’enseignant qui reçoit les signalements. Auparavant, une application ne s’arrêtait qu’à l’expiration de ses propres limites de temps, ce qui ne suffit pas lorsqu’il faut la retirer immédiatement.

Arrêter une application ne fait que l’arrêter. Les données enregistrées et l’adresse sont conservées, et l’élève peut la redémarrer ; supprimer le travail de quelqu’un d’autre est une autre affaire, et personne n’en a le droit. Chaque arrêt effectué par une autre personne que le propriétaire est consigné, sur les pages « Déploiements », où l’élève lit la même entrée que le personnel, et dans le journal d’administration de l’établissement.

Combien de temps elle tourne

Une application fonctionne au moins une heure, puis continue tant qu’il reste de la place, jusqu’à 4 heures ; elle s’arrête au bout de 30 minutes sans que personne la consulte, et chaque compte dispose de 8 heures de temps d’application par jour.

C’est conçu pour apprendre et faire des démonstrations, pas pour héberger un service en production : assez longtemps pour montrer le résultat à un enseignant, le partager avec quelques personnes ou rendre un lien, et volontairement pas assez pour faire tourner un service.

Avant tout déploiement, la page indique le temps restant pour la journée ; pendant que l’application tourne, elle affiche les dernières lignes qu’elle a écrites ; et elle conserve son journal trois jours après l’arrêt, c’est-à-dire au moment où l’on a le plus besoin de le consulter.

Au-delà de sa durée garantie, une application continue de tourner tant que personne d’autre n’a besoin de la place, et c’est la première arrêtée quand quelqu’un en a besoin : un déploiement qui arrive sur une machine pleine arrête l’application qui tourne depuis le plus longtemps, et seulement une application déjà au-delà de sa durée garantie. Un cinquième chiffre compte les builds plutôt que les minutes, 20 déploiements par jour par défaut, car un build coûte autant quelle que soit la durée de vie de l’application, et un élève qui redéploie à chaque commit est ce qui met une classe en file d’attente. Un administrateur système règle tous ces chiffres pour toute la plateforme et pour chaque établissement.

Il n’y a qu’une application à la fois. Tant que l’application en cours n’est pas arrêtée, le bouton « Déployer » est désactivé, et la page indique si elle est en attente, avec le nombre de personnes devant elle, en cours de construction, en ligne ou en cours d’arrêt. Une application qui s’arrête d’elle-même est signalée avec sa propre dernière sortie, à part de celle qui n’a pas pu être construite : personne n’est renvoyé vers un journal de build pour une erreur de son programme. Les dix dernières lignes affichées se rafraîchissent environ une fois par minute, le journal complet se télécharge, et les déploiements précédents forment un tableau : quand, dans quel langage, depuis quel dépôt, comment il s’est terminé et son journal.

Une base de données à côté de l’application

Dans « Déploiements », l’onglet « Base de données », à côté d’« Application », permet à un élève de créer jusqu’à trois bases de données personnelles, de 10 Mo chacune au maximum : PostgreSQL ou MySQL sous forme de serveur, ou SQLite sous forme de fichier. En sélectionner une dans le formulaire de déploiement démarre le serveur avec l’application et fait pointer DATABASE_URL vers lui : le code écrit pour SQLite sur un ordinateur portable lit ici la même variable. Un fichier SQLite est placé dans l’application et réenregistré à son arrêt.

Personne n’a à choisir de nom. Une base de données prend le nom de l’adresse de l’application de l’élève, suivi d’un mot qui indique de quel type de ressource il s’agit : une application sur sams-shop.learntools.dev reçoit une base de données nommée sams_shop_db et une pile cloud nommée sams-shop-cloud. Le nom d’une base de données est un nom SQL : les tirets de l’adresse deviennent des tirets bas, que tous les moteurs et tous les pilotes acceptent tels quels. Une pile cloud garde ses tirets, car son nom devient celui d’un bucket de stockage, qui ne peut pas contenir de tiret bas. Une deuxième base de données issue de la même adresse est numérotée, sams_shop_db_2 ; une adresse qui commence par un chiffre prend d’abord le mot, db_2048_game ; et un élève qui n’a encore rien déployé reçoit db_1 ou cloud-1. Le formulaire indique ce qu’il va créer avant que vous n’appuyiez sur le bouton.

Un serveur tourne exactement aussi longtemps que l’application ; ses données sont enregistrées à l’arrêt puis restaurées au démarrage. Seule une application déployée ici peut y accéder ; la page affiche les informations de connexion pour que l’élève comprenne ce que contient la variable. La personne qui corrige une application rendue reçoit avec elle la base de données de l’élève, données comprises, sans pouvoir modifier ce qui y est enregistré.

Chaque base de données propose « Démarrer », « Arrêter », « Télécharger » et « Supprimer ». Un serveur peut être démarré seul, et les données enregistrées se téléchargent sous forme de dump .sql, ou de fichier .sqlite pour SQLite, que l’application trouve dans /data, nommé d’après la base (/data/sams_shop_db.sqlite, par exemple), avec son chemin dans DATABASE_PATH. Un serveur en cours d’exécution a un bouton « Requête » qui ouvre les mêmes onglets Requête et Schéma que le bac à sable SQL, sur la vraie base de données et avec le propre rôle de l’élève ; l’onglet Schéma y est en lecture seule. La suppression est refusée tant que la base tourne ou qu’un déploiement rendu la désigne, et un déploiement non rendu la perd simplement et se déploie sans elle. À la limite de 10 Mo, un serveur passe en lecture seule et la page indique que les dernières modifications n’ont pas été enregistrées. Les identifiants sont générés, jamais choisis, et le mot de passe est scellé : la page affiche l’URL, l’hôte, la base et l’utilisateur, et le mot de passe sur demande.

Une seule session : l’application, une base de données, une pile cloud et un terminal

« Déploiements » est un seul élément de la barre, avec des onglets « Application », « Base de données » et « Cloud », et chaque onglet affiche en haut la même image de la session de l’élève : un réseau privé unique qui contient l’application, une base de données, une pile cloud et un terminal, chaque emplacement indiquant ce qu’il contient. Tout ce qui tourne joint le reste par des noms fixes, app, db et cloud, si bien que la configuration d’un tutoriel fonctionne telle quelle et qu’aucune URL n’est nécessaire.

« Ouvrir le terminal », dans n’importe lequel des onglets, démarre un shell à côté de la session, avec psql, mariadb, aws et curl déjà dirigés vers sa base de données, sa pile cloud et son application. Il y a un terminal par session, et il compte comme du temps de base de données. Son dossier personnel suit la session : ce qui dure, c’est ce que l’élève a mis dans la base de données ou dans le bucket.

Pour un travail évalué : rendre une application déployée

Un devoir écrit peut demander une application déployée au lieu d’un fichier. Vous rédigez la consigne comme d’habitude ; seule la forme du rendu change.

1. Créer le devoir. Sous « Ce qu’il faut rendre », choisissez une application déployée, puis le langage dans lequel les élèves doivent déployer.
2. L’élève déploie. La page de sa tâche affiche « Déployer votre application », qui ouvre la page de déploiement avec ce langage déjà sélectionné. Il déploie, vérifie que tout fonctionne, puis appuie sur « Rendre ».
3. Ce qui est rendu. Le déploiement complet : son nom, et chacune de ses applications avec le dépôt, la branche et les deux commandes utilisées pour la lancer. Un élève qui a un front-end et une API rend un seul travail, et non deux. Le rendu est rattaché à la tâche comme n’importe quel autre : il est noté, renvoyé et versionné de la même façon.
4. Le corriger en le lançant. Ouvrez son travail et appuyez sur « Déployer l’application ». La même application est remise en ligne à une adresse qui lui est propre, et relancer les rendus de toute une classe n’entame pas votre propre temps d’application quotidien. Si le déploiement comporte plusieurs applications, chacune est listée avec son propre lien, et elles démarrent l’une après l’autre.

Corriger un déploiement, et limites pour un concours

Un rendu n’a pas besoin d’être un déploiement qui fonctionne. Un élève dont le build ne passe pas peut quand même rendre son travail et l’expliquer dans la conversation ; ce qui est refusé, c’est un dépôt ou une branche que la page de déploiement refuserait elle-même, de sorte que ce qui est rendu est au moins quelque chose qui pourrait être construit.

La personne qui corrige n’a aucune limite quotidienne de temps d’application, et seulement pour le travail qu’elle corrige : lancer vingt-cinq rendus épuiserait l’allocation d’un élève dès les premiers, si bien que les minutes de la journée et la règle d’une seule application à la fois sont levées, et la page le dit. La durée maximale d’une session ne l’est pas, de sorte qu’une application oubliée finit toujours par s’arrêter, et un enseignant qui déploie une idée à lui est soumis aux limites ordinaires, comme tout le monde.

Une tâche peut fixer ses propres limites, ce à quoi servent un concours ou un examen. Son onglet de paramètres demande combien de déploiements elle autorise et combien de temps vit ensuite chaque application. Elles sont comptées dans le chronomètre propre à la tâche, si bien que celui qui commence tard a sa propre fenêtre, et elles s’appliquent à toute application que cet élève déploie pendant que le chronomètre tourne, pas seulement à celles qu’il dit destinées à la tâche. Une tâche ne peut que raccourcir ce que l’établissement autorise.

Questions fréquentes

Quels langages peut-on déployer ?

On peut déployer Python, Node, Go, Java et des sites statiques en HTML, CSS et JavaScript. L’élève peut modifier les commandes de build et de démarrage dans les limites de ce langage ; un dépôt écrit dans un autre langage ne pourra pas être construit.

Est-ce un service d’hébergement ?

Non. C’est conçu pour apprendre et faire des démonstrations, pas pour héberger un service en production : assez longtemps pour montrer le résultat à un enseignant, le partager avec quelques personnes ou rendre un lien, et volontairement pas assez pour faire tourner un service. Une application s’arrête d’elle-même, et l’élève la redéploie chaque fois qu’il en a de nouveau besoin, à la même adresse s’il en a choisi une.

L’application peut-elle avoir une base de données ?

Oui : PostgreSQL ou MySQL sous forme de serveur qui tourne à côté de l’application, ou SQLite sous forme de fichier placé dans l’application, de 10 Mo chacune au maximum et dans la limite de trois par élève. Elles se créent dans l’onglet « Base de données » et se sélectionnent dans le formulaire de déploiement, qui définit DATABASE_URL. Un serveur tourne aussi longtemps que l’application et conserve ses données d’une exécution à l’autre. Il n’est accessible que depuis une application déployée ici, pas depuis un ordinateur portable.

Peut-on l’essayer sans compte ?

Oui. Appuyer sur « Déployer » crée un compte invité temporaire dans ce navigateur, avec ses propres limites, et « Conserver ce compte » en fait un vrai compte avec une adresse e-mail et un code, en gardant tout ce qu’il a déployé.

Une application peut-elle avoir des secrets, comme une clé d’API ?

Oui. Le formulaire de déploiement accepte jusqu’à 20 lignes nom et valeur, stockées chiffrées et plus jamais affichées une fois enregistrées. Elles parviennent à l’application en cours d’exécution sous forme de variables d’environnement, et un enseignant qui corrige le travail n’en voit que les noms.

L’élève a-t-il besoin d’un compte GitHub ?

Il lui faut un dépôt à indiquer, ce qui mérite d’être enseigné en soi : gestion de versions et déploiement relèvent de la même leçon. Le dépôt peut être public ou privé ; pour déployer un dépôt privé, il suffit de coller un jeton GitHub en lecture seule, stocké chiffré et montré à personne.

Les élèves peuvent-ils choisir l’adresse ?

Oui, au moment de créer l’application : c’est là qu’ils nomment leur travail et choisissent l’adresse à laquelle il répond, un nom qui leur est propre, en minuscules, chiffres et tirets, que personne d’autre ne détient et qui ne fait pas partie des mots réservés. Le formulaire de déploiement situé en dessous ne redemande ni l’un ni l’autre : la décision n’est prise qu’une fois. L’adresse leur reste réservée jusqu’à ce qu’ils la suppriment du tableau « Déploiements enregistrés », sous le formulaire, ce qui permet alors à quelqu’un d’autre de la prendre.

Un élève peut-il remettre la même application en ligne sans remplir à nouveau le formulaire ?

Oui. Chaque ligne du tableau « Déploiements enregistrés », sous le formulaire, propose « Redéployer », qui remet en ligne en un clic exactement le même dépôt, la même branche, les mêmes commandes et les mêmes variables, à la même adresse. « Utiliser » reste disponible pour l’autre cas : modifier quelque chose avant. Aucune confirmation n’est demandée, puisque « Arrêter » permet de revenir en arrière ; seul un avertissement s’affiche au préalable : un déploiement sans adresse propre est remis en ligne à une nouvelle adresse, et un ancien lien cesse donc de fonctionner. Un déploiement rendu pour un devoir peut être remis en ligne de cette façon, mais ne peut être modifié d’aucune autre : c’est exactement ce que signifie ici « lecture seule ».

Un établissement peut-il le désactiver ?

Pas le désactiver, mais le restreindre. Un administrateur système règle les cinq chiffres pour toute la plateforme et pour chaque établissement : la durée garantie d’une application, sa durée maximale, sa durée sans visite, le total quotidien et le nombre de déploiements par jour, chacun pouvant descendre jusqu’à quelques minutes ou à un seul déploiement.

Que se passe-t-il quand elle s’arrête ?

L’application disparaît et son journal est conservé trois jours. Une adresse choisie est conservée, si bien qu’un nouveau déploiement remet l’application au même lien ; ce n’est pas le cas d’une adresse aléatoire.

Un enseignant peut-il mettre hors ligne l’application d’un élève ?

Oui. Tout membre du personnel de l’établissement peut arrêter celle de l’un de ses élèves, et un administrateur système celle de n’importe qui : en cas de plainte concernant ce qu’un élève a mis en ligne, quelqu’un peut donc agir le jour même. L’application est arrêtée, mais rien n’est supprimé : les données et l’adresse sont conservées, et l’élève peut la redémarrer. Il voit qui l’a arrêtée et quand, sur la page même d’où il déploie.