Retour aux vidéos

Comment héberger une application NestJS avec Github Actions, Docker et Caddy Server

Dans cette vidéo, nous allons héberger notre projet NestJS et Remix. Pour ce faire, nous avons besoin de configurer Docker avec Docker Compose et Docker Hub.

00:00 Dans cette vidéo, nous allons héberger ensemble deux projets JavaScript que nous venons de développer. C'est la cinquième et dernière partie de notre formation sur Nest JS. Tu trouveras le lien de la playlist complète dans la description. Je te recommande vraiment cette vidéo, elle est pleine de conseils. Nous allons commencer par configurer une image docker, puis nous allons configurer les actions sur GitHub qui vont pousser notre code mis à jour sur le serveur.

00:23 Nous allons ensuite configurer le serveur Caddy et les runners de GitHub et enfin, on va tester notre application en production. Il y aura quelques bugs et nous allons les débugger ensemble. C'est des erreurs typiques que je rencontre au quotidien et que tu as peut-être déjà rencontrées. Bon visionnage. On a donc nos deux bases de code en local et on va devoir les mettre sur un serveur et exécuter le code en continu.

00:45 On a donc notre base de code du front-end ici qui est le projet NSJS chat front, notre application Remix et nous avons aussi notre serveur qui est l'API NS le JS. Js. Et l'approche va être exactement pareille pour mettre en ligne ces deux projets. On va faire la même chose et nous allons d'abord le faire pour Nest. Js, puis ensuite, nous allons répéter l'opération pour Remix.

01:06 Pour ce faire, nous allons utiliser plusieurs technologies. La première, ça sera d'utiliser Docker créer une image de notre projet. À chaque changement de notre code, avant de le mettre en ligne, nous allons donc créer une image. On va donc faire un build avec Docker que nous allons envoyer au serveur. Le serveur va télécharger cette image et il va ensuite l'exécuter.

01:24 Et pour l'exécuter automatiquement, nous allons utiliser les GitHub actions ici, qui est une fonctionnalité entièrement gratuite de GitHub qui va nous permettre justement de construire notre image docker automatiquement à chaque mise à jour de notre code. Ça sera également GitHub qui va se charger d'envoyer cette image docker à notre serveur. Et bien sûr, nous parlons de serveur. Donc on va avoir besoin de commander un serveur qui va tourner en continu et qui va se charger d'exécuter notre code. Pour mieux comprendre quel serveur vous devez choisir, je vous conseille la vidéo qu'on avait créée sur la chaîne qui s'appelle comment héberger ses projets javascript sur un serveur VPS.

02:01 Ce qu'on va faire aujourd'hui, c'est exactement le même esprit, sauf que je vais utiliser un serveur que j'ai déjà commandé sur l'hébergeur Hostinger ici. On va donc commencer par le début et la première partie, c'est de créer une image docker. Nest JS, on va donc se rendre à la racine de notre projet Nest JS ici et nous allons créer un nouveau fichier qu'on va appeler dockerfile. Je vais ensuite copier le dockerfile que j'utilise en entreprise et on va le regarder ensemble comme vous voyez sur le dockerfile ici, on a un lien qui nous redirige vers un site, c'est un site que j'ai utilisé pour du docker fail pour l'utiliser avec Nest le g s et on peut voir qu'on peut retrouver le docker fail ici, sauf que j'ai utilisé la version un peu plus compliquée qui est optimisée pour la production. En gros, ce qu'on est en train de faire, c'est qu'on est en train de télécharger une image de node, node j s à la version vingt et on utilise la version alpine de cette image.

02:52 Puis ensuite, on configure la variable d'environnement node et n v et à partir de là, on va créer un dossier qu'on va appeler slash app. Et dans ce dossier, nous allons copier le package point json et le package lock point json. On copie toujours ces deux fichiers en premier pour ajouter du cache à notre de corfile. Ensuite, après avoir ajouté ces fichiers, nous allons ajouter donc tout le contenu de notre projet ici et nous allons exécuter la commande NPM install, ce qui va installer toutes les dépendances, sauf les dépendances de développement parce que nous sommes en environnement production. Comme nous souhaitons également télécharger les dépendances de développement parce qu'on en a besoin pour build l'application, on rajoute la commande tiret tiret include égale dev.

03:32 Ensuite, après avoir téléchargé toutes les dépendances, on va donc rajouter le dossier Prima qui est ici et nous allons lancer la commande NPX Prima générer, ce qui va générer les déclarations de type et le code source de notre Prima. Et ensuite, nous pouvons faire un build de notre application, donc de notre serveur Nest. Sauf que, comme on a téléchargé toutes les dépendances, y compris les dépendances de l'environnement de développement, on n'a pas envie de conserver tous ces fichiers en production. Parce que, comme son nom l'indique, les dépendances de développement, donc toutes celles-ci ne seront pas du tout utilisées en environnement de production. Elles ne seront pas utilisées.

04:09 C'est pour ça qu'on appelle ça des dépendances de l'environnement de développement. C'est pourquoi on repart notre base ici et nous copions ensuite tous les fichiers. Sauf qu'à la fin, on fait un prune et on omet toutes les dépendances de développement. C'est-à-dire que ça va conserver notre fichier non module et on va supprimer chaque fichier qui est en fait une dépendance de développement. Et enfin, après avoir fait ça, on repart de nouveau d'une base vierge et nous téléchargeons les librairies nécessaires, par exemple les fuseaux horaires français.

04:38 Cette ligne n'est pas nécessaire, mais j'en avais besoin dans mon application. Et enfin, nous créons un utilisateur qui s'appelle donc remix tiret API. Si vous voulez, on peut le renommer en SEGS et qui va finalement copier le package json, le fichier liste et donc le fichier compilé et les notes modules de production. Et enfin, ça va exécuter la commande start point s h. Il y a un fichier source qu'on n'a pas encore créé.

05:01 Nous allons donc le créer tout de suite. On va donc ajouter un nouveau fichier qu'on va appeler start point s h et nous allons copier ces trois lignes de code, c'est-à-dire en premier, on définit bien ce fichier comme utilisant le terminal s h et ensuite on définit les permissions et enfin on fait un prisma nigrade deploy, ce qui va donc déployer toute l'immigration Prima. Et enfin, on va lancer le MPM Rôle Start, ce qui va exécuter notre serveur en environnement de production. Maintenant qu'on a fait ça, on va pouvoir build cette image Docker. Mais d'abord, on va rajouter un dernier fichier qui s'appelle le docker ignore, comme ceci.

05:37 Au final, il s'appelle point docker ignore et c'est exactement pareil que le git ignore. Nous allons ignorer certains fichiers parce que ici, on peut voir qu'on a une commande qui va copier tous les fichiers dans notre image docker. Mais nous, on n'a pas envie par exemple de copier les notes modules ou le dist. Donc, il nous suffit de rajouter Dist et Node modules et en fait, tous les fichiers qu'on n'a pas envie de copier. Par exemple, le dossier test, je n'ai pas envie de le copier.

06:02 Le dossier docker ignore, je n'ai pas envie de le copier. Les points ENV et les points ENV. Exemple, on n'a pas envie de les copier. Tout ce qui est configuration s lint, logit ignore, le pre tiers arce, le dockerfile. Tout ça, au final, on n'en a pas besoin pour exécuter notre code.

06:18 On peut même ignorer leur ennemi et c'est à peu près bon maintenant. Maintenant, on va ouvrir un terminal et il faut bien sûr télécharger Docker si vous ne l'avez pas déjà fait. Pour télécharger Docker, vous allez sur Google et vous tapez Download Docker et on va sur le premier lien Docker desktop et ici, vous avez une option pour le télécharger pour votre système d'exploitation, donc pour Mac, Windows ou Linux. Je l'utilise sur Mac, donc là, c'est cette application-là, ça ressemble à ça. C'est exactement le même design sur les autres n'a aucune image qui est lancée et aucun conteneur qui est lancé.

06:53 Donc maintenant, ce qu'on peut faire, c'est qu'on peut dans notre terminal lancer la commande docker build tiret t et là nous allons nommer notre repository Docker qu'on n'a pas encore créé sur la plateforme et que nous allons appeler comme le nom du projet, neste j s tiret chat tiret API et nous allons le mettre dans Algo max qui est le nom de l'organisation que j'ai créée sur Docker. On va faire tout ça après. Là, on teste juste la commande et on a envie d'exécuter le build dans le dossier qui est présent. Ce que le corps va faire, c'est qu'il va détecter notre fichier de Corefile. Il va détecter le fichier docker ignore et il va exécuter une par une toutes les instructions de notre fichier instructions de notre fichier de Corefile comme ceci.

07:32 On va faire un test, on peut voir que ça build bien chaque étape de notre application. On est déjà à l'étape quatorze et bien sûr ce qu'il faut savoir c'est que comme on rajoute du cache, les builds consécutifs ne vont pas répéter les étapes ont déjà été faites. Par exemple, le premier build, c'est toujours le plus long parce qu'on télécharge les dépendances, le package json qui est ici. Mais si par exemple, je vais dans un fichier le main point t s et que ici, je rajoute un console log et que je refais un build, ça va refaire toutes les étapes depuis le début, sauf que ça va commencer à partir de l'étape quatorze, par exemple. C'est-à-dire que ça ne va pas réinstaller toutes les dépendances parce que le fichier package.

08:08 Json n'a pas été modifié. Bien sûr, dans le cas où j'installe ou que je désinstalle une librairie, dans ce cas-là, ça va reprendre plus haut, par exemple à l'étape neuf ou à l'étape où on installe toutes les librairies. Donc là, on est très bien, il n'y a pas eu d'erreur et ce qu'on va faire maintenant, c'est qu'on va exécuter cette image. On va donc lancer la commande docker run tiret d et on va nommer cette image. Mais ce que je vais faire, c'est que je vais copier la suggestion de mon terminal.

08:33 Ici, on va prendre l'image que nous avons créée, qu'on avait appelé algo max slash ns j s chat API et nous allons l'exécuter sur le port huit mille. Donc on va reverse proxy le port huit mille de l'image docker à notre port huit mille en local et nous allons appeler ce projet nets j s chat API. Donc on va taper la commande suivante et on va exécuter notre image docker. Et là on peut voir qu'on a une erreur, Il n'a pas réussi à trouver le fichier start point s h. Alors, qu'est-ce qui se passe Ce qu'on peut faire si on a l'application Docker, c'est qu'on va l'ouvrir ici et on voit qu'on a un conteneur qui est en train de cracher, donc qui n'arrive pas à se lancer.

09:09 Et du coup, il se relance à chaque fois. Sauf qu'il y a une erreur JavaScript. Mais ce qu'on a envie de faire ici, c'est de cliquer sur le conteneur et d'aller sur l'onglet Files pour voir ce qui s'est passé. Sauf que le problème, c'est que comme on n'arrive pas à exécuter l'image, eh bien, l'image ne reste pas suffisamment longtemps exécutée pour qu'on puisse inspecter les fichiers. Donc effectivement, ça crache.

09:29 Comme ça crache, on ne peut pas inspecter les fichiers, mais ce n'est pas grave. On va continuer avec notre implémentation du docker fail parce qu'il y a un dernier fichier que nous allons avoir besoin de créer. Effectivement, je n'ai pas envie d'exécuter deux commandes à chaque fois, c'est-à-dire le docker build, puis le docker run et taper dans mon terminal les commandes. Je préfère utiliser une seule commande qui fait les deux calculs et c'est pour ça que nous allons utiliser ce qu'on appelle docker compose. On peut chercher sur Google ce que c'est.

09:56 Docker compose, ça va nous permettre d'exécuter plusieurs, une ou plusieurs images docker et elles seront donc exécutées en même temps et elles pourront communiquer entre elles. Et c'est ce que nous allons utiliser. Pour ce faire, il nous suffit de créer un nouveau fichier qu'on va appeler docker tiret compose point yamaha. Sauf que nous, on va avoir plusieurs environnements potentiellement. On va avoir un environnement de production et on va avoir un environnement de dev.

10:19 Donc là, je vais rajouter un point dev dans le fichier parce qu'on va écrire le docker compose de l'environnement de développement en premier. Ensuite, pour la production, il nous suffira de copier coller ce fichier et juste de modifier une ligne du deux. Donc, on crée ce fichier docker compose ici et nous allons copier ce morceau de code. Donc, nous avons une ligne service parce qu'on peut définir un ou plusieurs services. Exemple, si tu voulais utiliser une base de données Redis ou alors un bucket S trois en local, tu pourrais ajouter un service Redis qui sera donc ensuite connecté à ton application.

10:51 Tu pourrais rajouter un bucket S trois, un bucket email pour envoyer les emails, et caetera. Mais dans notre cas, on va conserver un seul service et c'est le NesJS chat API en environnement de Dell. Ensuite, nous avons une déclaration environnement. C'est pour les variables d'environnement, par exemple la connexion à la base de données. Et ce qui nous intéresse ici, c'est le et c'est parce qu'on définit un contexte, on définit notre dockerfile et on indique à docker qu'on a envie qu'il fasse un build de notre fichier dockerfile.

11:20 Et enfin, nous avons le reverse proxy des ports. Notre application tournait sur le port huit mille, mais comme on va l'exécuter dans un docker, elle va tourner dans le docker sur le port huit mille et on a envie de pouvoir y accéder sur notre port huit mille à nous. Donc, on fait comme ça. Si on avait envie qu'elle tourne sur le port huit mille dans le docker et qu'on avait envie d'y accéder sur notre machine sur le port quatre mille, on mettrait ici port quatre mille et le port quatre mille de notre ordinateur serait relié au port huit mille du Docker. Bien sûr, si dans le Docker, on le relie sur le port huit mille, mais que notre application le lance sur le port deux-mille, ça ne va jamais marcher.

11:54 Il faut bien que notre application le lance sur le bon port qu'on est en train de définir ici. Donc maintenant qu'on a créé ce fichier, on peut lancer une commande qu'on appelle docker compose tiret s pour dire qu'on va exécuter un fichier spécifique ici et on peut voir que la commande met auto-compléter. On va donc utiliser la commande docker compose sur le fichier que nous venons de créer et on va faire un up et un tiret tiret build. Le tiret tiret build, il va tout simplement build notre image docker si ce n'est pas déjà fait. On peut voir ici que j'ai fait une petite faute dans le nom du fichier.

12:24 Alors les deux formats sont possibles. Là, il y a le format yml et le format yml. Mais pour ne pas avoir à retaper la commande dans le terminal, je vais utiliser le format yaml. Et maintenant, on peut exécuter cette commande de Core et comme vous voyez, ça exécute à peu près les mêmes étapes. Là, nous sommes sur l'étape installer l'application et encore une fois, l'application va crash parce qu'elle ne détecte pas notre fichier start point s h ou alors elle n'a pas les permissions pour l'exécuter.

12:49 Et ça, c'est une erreur que j'ai à chaque fois que je crée un nouveau projet. Donc, je vous conseille déjà de taper la commande shmod plus x start point s h dans votre terminal comme ceci et ensuite on va rajouter une ligne de notre docker fail pour être vraiment sûr qu'on possède bien ce fichier ici à la dernière étape dans le roller. Ce qu'on va faire, c'est qu'on va copier depuis installeur qui est la base qu'on avait définie ici dans lequel on a copié tous les fichiers et donc depuis installeur, nous allons copier le fichier start point s h comme ceci et on va l'appeler start point s h. Avec ces deux changements, je pense que le fichier va être détecté. On refait un effet, va lancer cette commande et comme vous voyez, on reprend les étapes, mais on ne les reprend pas depuis le début et on a malheureusement toujours la même erreur.

13:33 Donc dans ce genre de cas, on peut essayer de déboguer l'application. En fait, je pense que le fichier s h n'a pas été copié. Donc ici, ce qu'on peut faire, c'est qu'on peut le copier. S h se retrouve dans start point s h comme ceci. Et là, bien sûr, on doit réinstaller l'application tout simplement parce qu'on a rajouté une ligne de commande qui s'appelle start point s h juste avant l'installation des dépendances ici.

13:56 Donc, Decor a mis en cache toutes les étapes qui étaient exécutées avant, mais il ne met pas en cache les étapes à partir de celles qu'on vient de rajouter. Ce qui est logique parce que si on rajoute un fichier si on fait un petit changement, on va devoir tout recalculer, on va devoir refaire un build. Là, je n'arrive vraiment pas à déboguer. Je ne comprends pas quel est le problème. Donc en fait, ce qu'on va faire, c'est que je vais retourner sur la dernière étape ici et on va faire du débogage.

14:20 Ici, on lui donne l'instruction d'exécuter le fichier start point s h et il n'y arrive pas. Donc, je vais rajouter une instruction précédente et ça va être une commande de terminale qui ne peut pas échouer. On va donc laisser tourner notre terminal avec cette commande qui s'appelle conteneur eat running. Et ce que ça va faire, c'est que ça va laisser notre image, ça va la laisser active et pendant qu'elle est active, on va retourner sur l'application de Core Desktop ici et on va essayer de déboguer, on pourra enfin accéder au fichier pour comprendre ce qui ne va pas. Donc ce bug tombe bien au final, parce qu'on va apprendre quelque chose de nouveau.

14:53 Là, maintenant, j'ai commenté cette dernière commande et j'en ai rajouté une autre. Donc, on peut de nouveau exécuter notre docker compose ici et c'est ce qu'on va faire tout de suite. Et maintenant, on peut voir que là, on n'a pas eu d'erreur et on est à la dernière étape conteneur is running. Maintenant, on peut donc retourner sur l'application ici et on va supprimer la première image et nous allons cliquer sur la deuxième image ici et maintenant on clique ici et nous avons envie d'accéder au fichier. Donc on va se rendre dans files et là on peut vraiment voir tous les fichiers qui sont présents sur le disque dur de cette image.

15:25 On a donc le dossier app ici, le dossier dist, non module, pas que j'ai zam et nous avons notre fichier start point s h. Alors, c'est bizarre parce que l'application nous dit qu'il n'arrive pas à l'exécuter. Alors ici, ce qu'on peut faire, c'est qu'on peut open fil editor ou alors on peut clic droit sur le fichier et faire edit file et on peut voir que cette image est vraiment à jour. Donc le problème ne vient pas de l'image qui n'a pas été copiée. On va donc retourner dans notre terminal ici et on a envie une dernière fois de regarder ce qu'était le message d'erreur.

15:55 Au final, les réponses sur Google ne m'ont pas vidées. Par contre, j'ai eu la bonne idée de taper cette commande, donc la commande s h start moins s h et j'y vois un peu plus clair avec une erreur beaucoup plus parlante. Ici, ça n'arrive pas à faire un MPX prisma my y déploréa parce que ça ne trouve pas le fichier schéma point prisma dans le repository et j'ai déjà eu cette erreur sur un projet sur lequel je bossais il y a quelques jours. Et pour mieux comprendre d'où cette erreur vient, ce que j'aurais dû faire, c'est que j'aurais dû exécuter le fichier start point s h moi-même dans l'ordre et on verra que c'est cette commande-là qui pose problème. Et pourquoi elle pose problème Elle pose problème parce que Prizma n'arrive pas à se connecter à notre base de données et elle n'arrive pas à s'y connecter parce que cette base de données n'existe plus.

16:40 Depuis la dernière fois, PlanetScale est devenue payant. Au début de cette vidéo, c'était entièrement gratuit et maintenant, ça coûte minimum quarante dollars par mois. Donc, on va devoir utiliser une alternative. On va se rendre sur NéonTech et nous allons créer une nouvelle base de données pour ce projet. Sur NeonTech, on a droit à une base de données gratuite.

17:01 Bien sûr, ça va utiliser du PostgreS et pas du MySQL. Donc, on va devoir faire une petite modification. On va d'abord commencer par supprimer cette base de données là. Ici, bien sûr, il y a comment qu'il est Vous, vous devez sûrement ne pas l'avoir et je vais recréer l'application NSGS chat et on va l'appeler NSGS tiret chat et on va choisir en région l'Europe et nous allons créer le projet à partir de maintenant on va sélectionner prisma ici et on doit faire deux changements. Le premier changement, c'est changer le provider de notre fichier de configuration Prisma.

17:31 Donc dans le fichier schéma point Prisma ici, on avait sélectionné mysql et cette fois, on va sélectionner PostgreS et on va retirer cette ligne. Et enfin, on va devoir copier le point en vue ici avec ce secret. On va donc On va donc copier ce secret en entier et on va le rajouter dans notre point en vue. Je ne vous montre pas les lignes au-dessus, mais on avait déclaré en tout premier une base de données qui s'appelle Database UARL avec la d b, mais SUL et je vous demanderai maintenant de supprimer cette ligne, sinon ça va la détecter comme étant la base de données par défaut. Donc maintenant, on peut sauvegarder cette variable d'environnement et ce qu'on va faire, c'est qu'on va exécuter cette commande là, le NPX prisma migrate.

18:10 Et là, on peut voir qu'on n'a plus d'erreur. Comme on n'a plus d'erreur, on va tout de suite essayer de réexécuter notre docker fail. On va donc lancer notre docker compose comme avant et là, on peut voir qu'on a toujours la même erreur. Et en fait, c'est encore une erreur d'inattention de ma part, c'est parce qu'on doit rajouter toutes les valeurs de notre fichier point in n v dans le fichier docker compose. Ici, on avait rajouté la valeur JWT secret et en fait on va rajouter le database URL, les variables d'environnement stripe.

18:38 Donc on va le faire tout de suite. Vous allez copier toutes les clés de votre fichier point yn v ici et on va les coller comme ceci. On avait donc une dizaine de variables d'environnement, le JWT secret, le port, l'API I qui de resend, du front end, d'a w s trois et le stripe comme ceci. Et ce que ça va faire, c'est qu'en exécutant cette commande en local, ça va lire nos variables d'environnement depuis notre fichier .Yannly. Maintenant, on peut réexécuter une dernière fois la commande docker Compose et ça devrait normalement marcher.

19:08 Bien sûr, ça ne marche pas. On a toujours la même erreur. C'est vraiment l'effet vidéo. Là, on peut voir que mettre à jour cette librairie n'a pas non plus fonctionné. Alors là, je suis vraiment bloqué, surtout que cette erreur, je l'ai déjà eu une fois au boulot et pareil, ça m'avait fait perdre une journée de taf.

19:23 Et là, en fait, le problème, franchement, je m'en veux de ne pas l'avoir compris plus tôt. Mais en fait, on n'a pas copié le dossier Prisma ici. On n'a pas copié à la dernière étape ici depuis installeur. On n'a pas copié le dossier Prisma et on aurait dû le copier. On aurait dû le copier en faisant Prisma comme ceci.

19:40 Et si on l'avait copié, peut être qu'on n'aurait pas eu tous ces problèmes. Au moins, on le saura pour la prochaine fois. Maintenant, on va repartir sur l'instruction en train point. En tout cas, pour configurer le front end, ça va être beaucoup plus simple. On n'a pas Prisma, c'est vraiment juste une application React, donc ça va être plus rapide et voilà.

19:57 Cette fois, on a donc une autre erreur, c'est Landrypoint qui ne fonctionne pas. Donc on a vraiment deux erreurs à chaque fois, c'est assez marrant. Alors est-ce que ça vient de Landrypoint ou ça vient encore de Prima Cette fois on va tester normalement, on a copié le dossier Prima, donc ça devrait retrouver le schéma et là on peut voir qu'on a cette erreur Nest not found et Nest en fait c'est la commande de Nest j s pour exécuter l'application ici. Dans notre commande start, on lance la commande Nest start. Sauf que Nest les amis, c'est ici, fine de développement et on peut voir tout de suite, on a un fichier compilé ici, on a donc et dedans on a main point g s.

20:37 Et en fait, ce qu'on aurait pu faire au lieu de faire Nest start, c'est de faire un node dist slash main comme ceci. Donc maintenant, j'ai modifié le package JSON. Donc au moment de re build l'application docker, ça va repasser toutes les étapes y compris l'installation mais au moins on progresse on a résolu l'erreur Prisma ok donc là on a réussi à faire tourner notre application avec cette commande en vrai on peut s'arrêter là C'est pas grave si on n'utilise pas entrypoint start point s h. Notre application tourne, elle est accessible sur le port huit mille. On va le tester tout de suite.

21:08 On va faire locelast huit mille. On va accéder à la route slash comme ceci. Et là, bien sûr, je vais oublier de changer. On peut y accéder sur le port quatre-mille et pas sur le port huit-mille. Ça, c'est une erreur qui vient de moi.

21:20 On peut voir qu'on a eu une petite erreur serveur à ce niveau-là et on retrouve l'erreur sur notre terminal ici. On n'arrive pas à se connecter au serveur. Ça, c'est parce qu'on n'a pas encore exécuté les migrations, mais une erreur à la fois. Donc là, ce qu'on va faire, c'est qu'on va remettre le port huit mille pour le reverse proxy et on va lancer une commande. Mais en fait, ici, on est passé à une base de données post-gress.

21:40 Avant on avait du MySQL et on n'avait pas besoin de migration. Sauf que là, on a besoin de migration. Donc on va faire un NPX prisma migrate dev tiret time et on va mettre comme nom de notre première migration init. Et maintenant ça a créé un fichier migration point SQL et un dossier migration qu'on retrouve ici. Et normalement, à partir de maintenant, on ne devrait plus avoir de problème.

22:02 On va donc relancer le docker compose, cette fois sur le port huit mille, cette fois avec notre dossier Prizma. Cette fois notre commande start point s h fonctionne et voilà, là notre application est lancée et si on se rend sur la route slash users, bien sûr sur le port huit mille comme ceci, là on a un tableau vide parce qu'il n'y a plus d'utilisateurs effectivement. On a entièrement changé de base de données. On est passé chez Neon maintenant. Et si on clique sur les tables ici, on retrouve nos chats, nos conversations, nos donations et nos utilisateurs.

22:31 Maintenant que c'est fait, là, on a terminé. On a terminé notre docker fail. On a terminé notre docker fail. Donc ce qu'on a envie de faire maintenant, c'est de configurer les GitHub actions pour déployer automatiquement notre application sur un serveur. Encore une fois, je vais m'inspirer de ce que j'utilise déjà sur mes projets personnels où je vais coller un fichier ici et on retrouve donc un dossier point GitHub qui est une convention de GitHub.

22:53 Donc, quand on mettra en ligne le code sur GitHub, il va détecter ce fichier, il va aller dans le dossier workflow et il va exécuter chaque fichier en point m l. Là, on a donc build point m l et le build point m l, ce qu'il va le faire, c'est qu'il va exécuter un docker build. Donc, il va tout simplement build notre docker fail qu'on vient de créer. Donc, ce qu'on faisait en local, docker build, cette fois, cette commande va être exécutée sur les serveurs de GitHub. Elle sera exécutée quand on va faire un push sur la branche main et sur la branche nommée dev.

23:23 Et pour ce faire, on va avoir besoin de deux identifiants, le docker hub user name et le docker hub token. Et ces identifiants, on les récupère en créant un compte sur le site qui s'appelle docker hub. C'est le site officiel de Docker et vous pouvez récupérer vos identifiants. Ici, le user name, c'est tout simplement votre nom de compte. Donc pour nous, ça sera Algomax et le token, vous pouvez le retrouver ici dans account settings et dans l'onglet security.

23:49 Ici, vous pouvez générer un nouveau token avec les permissions que vous voulez. Après avoir généré ce token, vous allez vous retrouver sur GitHub. Si vous avez créé un repository pour sauvegarder votre base de code, ici, je l'avais fait pour 9. Js chat API. Donc, je vais me rendre sur ce repository et je vais aller dans settings et je vais aller dans secret variables et dans action.

24:11 Et à cet endroit là, je vais ajouter des secrets qui seront donc protégés. C'est une sorte de volt et on va rajouter les valeurs de nos secrets. Donc on va rajouter le docker hub underscore token, le docker hub underscore username qui est donc algo max et finalement toutes les variables d'environnement qu'on a défini à cet endroit dans le docker qu'on pose. Donc, un par un, vous pouvez les récupérer depuis votre environnement local et on aura bien sûr des valeurs qui seront différentes pour l'environnement de test et l'environnement de production. Et dans ce cas là, vous pouvez renommer votre secret ici pour l'environnement de développement.

24:48 Moi, je l'appelle Staging par exemple, mais dans cette vidéo, on ne va pas créer deux environnements différents. On ne va utiliser qu'un seul environnement, c'est l'environnement de production pour que ça soit un peu plus simple. Sauf bien sûr pour Stripe, parce que pour Stripe, ils font bien la différence entre l'environnement de test et l'environnement de production. Alors pour Stripe, vous pouvez sauvegarder les deux, mais de toute manière, on va retourner tout à l'heure sur Stripe pour générer nos secrets de production. Voilà, là je viens d'ajouter tous les secrets de mon API et ce qu'on peut faire, c'est qu'on peut retourner dans le build ici et on peut voir qu'en fait on build donc l'image docker et ensuite on va l'héberger sur la plateforme docker qui s'appelle docker hub.

25:27 Et on peut voir qu'on l'héberge avec un tag assez spécial, c'est le tag qu'on avait déjà utilisé, c'est algo max slash neste j s tiret chat tiret API. Sauf que ce repository n'existe pas encore. Donc on va retourner sur docker hub ici, nous on va créer un repository qui porte le nom qu'on a défini à notre fichier ici. Donc neste j s tiret chat tiret API. Bien sûr, vous, c'est votre nom d'utilisateur qui sera avant le slash ici.

25:52 Moi, j'ai utilisé le namespace algo max et je vais appeler le projet ns g s tiret chat tiret API. Je vais ensuite créer son repository comme ceci et maintenant à chaque déploiement sur GitHub, l'environnement de dev et de main, ça va build une nouvelle image Docker. Sauf que cette commande build point yml est exécutée dans le fichier c I point m l qui est le deuxième fichier. Et c'est ce fichier en fait qui va exécuter toutes les actions qu'on lui aura données. Par exemple, si on retourne dans le fichier package point json, qu'on lui aura données.

26:21 Par exemple, si on retourne dans le fichier package point json, on peut voir qu'on avait des commandes comme le lint et le tape check et les tests et toutes ces commandes, on peut les exécuter au final à chaque mise à jour du code. Mais dans cette vidéo, on ne va pas le faire, on va juste faire un build et mettre en prod. Donc, on va avoir un seul job. Le build va donc appeler le fichier qu'on a créé, le build point yml et qui va donc hériter des secrets qu'on aurait défini sur GitHub. Et ensuite, après le build, on va exécuter l'action Diplori.

26:48 On peut voir que l'action de déploiement a besoin de du build. Donc avant d'exécuter l'action de déploiement, on va d'abord exécuter le build. Sauf que ce déploiement, on va l'exécuter pas sur les serveurs du GitHub, mais sur nos serveurs, notre serveur qu'on aura acheté chez Hostinger. C'est pourquoi on a rajouté la commande runs on sales tiret oced. Et enfin, on a les mêmes conditions ici, c'est-à-dire qu'on exécute le déploiement seulement en cas de push sur la branche main ou sur la branche dev.

27:18 Et à cet endroit-là, on va devoir redéfinir les variables d'environnement de notre projet et tu apprendras bien sûr les valeurs qu'on a définies sur GitHub à cet endroit, donc secret point et le nom qu'on a défini sur GitHub et enfin, à ce moment-là, c'est là qu'on va faire une différence entre environnement de et environnement de production. Ici, on a si on est en environnement de dev, alors dans ce cas-là, on va utiliser les variables de l'environnement de dev, donc database, URL staging et si on est en prod, on va utiliser celle de prod et on va exécuter le fichier docker compose point dev en dev et le fichier docker compose point prod en prod. Sauf que nous, on va créer un seul environnement, ça sera l'environnement de production. Donc cette ligne, on peut la commenter et ici, on va bien utiliser le front-end URL et le database URL qu'on a défini. Sauf qu'on n'a pas besoin de le définir ici, on va le définir plus haut ici.

28:09 Bien sûr, si vous avez besoin de définir plusieurs environnements, alors dans ce cas-là, vous devez répéter cette opération autant de fois que nécessaire. On va faire une dernière chose, ici on va retourner donc plus haut à cet endroit-là et on définit les variables d'environnement qui sont communes à tous les environnements. Sauf que ça ne pose aucun problème pour nous vu qu'on n'a qu'un seul environnement, c'est la prod. Donc on aura un JWT secret, import et toutes les variables d'environnement qu'on a défini ici. Voilà, on les a toutes ajoutées sauf qu'on n'a pas encore créé les secrets et les webhooks de notre compte Stripe en production.

28:41 Ce n'est pas grave, on va le faire tout de suite après. D'abord, on a juste envie de mettre en ligne ce code en environnement de production, même si on n'a pas encore les secrets et normalement, ça devrait être bon. Ici, on peut voir qu'on est sur la branche main et ce qu'on va faire, c'est qu'on va faire un petit guide status. On peut voir qu'on a tous ces fichiers à versionner et on va le versionner tout de suite. On va faire un gitd point, un git commit, on va appeler mise en prod et enfin on va faire un push origine donc sur notre branche main et maintenant on va se rendre sur GitHub ici sur notre projet et on va cliquer sur action parce qu'on peut voir ici qu'il y a une nouvelle action qui a été effectuée parce qu'il a détecté tous les fichiers qu'on a rajouté.

29:18 Si on clique donc sur action, ici on peut voir qu'on a notre action et on va pouvoir voir le build et le déploiement sur notre serveur. Sauf qu'on a un petit problème, l'action de déploiement ne va pas marcher parce qu'on n'a pas encore défini notre serveur. Ici, l'action de déploiement s'appelle le diplôme, c'est un run zone self-oastead. Sauf qu'on n'a pas encore défini notre serveur au Stinger qu'on va utiliser. Par contre, ce n'est pas grave, on a déjà envie de voir si le build s'effectue sans problème.

29:47 Pour ce faire, on peut retourner sur docker hub. Ici, on peut rafraîchir la page et là, on peut voir qu'on a bien une branche qui est en train d'être push sur le tag qui s'appelle production. Et ça veut dire que si on retourne ici dans notre fichier build à cet endroit-là, on peut voir qu'on avait bien défini le tag production ici sur notre action de déploiement en production. Et ça marche du tonnerre, ça va build notre image. Là, si on retourne sur GitHub, on peut voir qu'après une minute vingt-six, l'image a été build.

30:14 Maintenant, bien sûr, l'action de déploiement ne va jamais fonctionner parce qu'on n'a pas encore configuré le serveur. Mais ce n'est pas grave, on va annuler le workflow. Si on veut, on peut retourner tout de suite après et on peut cliquer sur replay, ce qui va réexécuter cette action. Donc maintenant, on a envie de configurer le serveur Hostinger. On va se rendre sur Hostinger et à cet endroit normalement, vous cliquez sur accès SSSSH et vous vous connectez au mot de passe que vous avez défini.

30:39 Pour se connecter, on va donc copier l'adresse IP et le nom d'utilisateur. On va faire SSSH root arobase et l'adresse IP. Dans mon cas, je n'ai pas besoin de rentrer le mot de passe parce que je l'ai déjà rajouté sur le serveur. Je me suis déjà connecté une fois que j'ai configuré pour ne pas avoir à rerentrer le mot de passe et maintenant, une des étapes qu'on doit faire, c'est d'installer Docker sur le serveur. Mais dans mon cas, je l'ai déjà installé.

31:01 Alors pour vous, vous allez devoir faire docker install Ubuntu comme c'est fait et vous allez devoir installer docker sur Ubuntu. Il suffit de suivre toutes ces indications ici et d'installer entièrement docker. Bien sûr, vous retrouverez toutes ces informations dans la vidéo qu'on a faite qui s'appelle déploie ton projet javascript sur un serveur VPS. Donc on aura besoin de docker, de Kady serveur et sur ce serveur, on a déjà tout de configurer. Donc ce qu'on va faire, c'est qu'on a juste besoin de configurer le runner de GitHub pour qu'il puisse renvoyer en fait notre image docker sur le serveur.

31:33 Et pour ce faire, on se rend dans settings à cet endroit et on va cliquer sur action runners et on va créer un new self first tel runner à cet endroit-là et on va sélectionner Linux x soixante-quatre et nous allons suivre les instructions. Donc on va copier ce premier morceau de code, mais ce que j'ai envie, c'est d'appeler le dossier deployment comme ceci. On va faire un cd sur le dossier deployment et on va copier la deuxième commande girl ici, ce qui va télécharger l'exécutable va nous permettre de configurer le github runner. Maintenant que c'est fait, on passe à la commande suivante ici et ensuite on termine avec la dernière commande pour télécharger ce renard. Maintenant que c'est fait, on va retourner dans le fichier et on va passer à la configuration.

32:13 Ici, on va donc copier cette commande et on a une erreur qui dit must not run with sudo et cette erreur on l'a déjà eu dans la vidéo précédente en gros on peut pas exécuter ce code en tant qu'utilisateur sudo donc je vais me connecter avec l'utilisateur que j'ai créé qui s'appelle Virgile et je vais retourner dans deployment ici et en fait ce s'est passé c'est que tout ce que j'ai fait là je l'avais déjà fait une fois pour un autre projet. Donc comme j'avais déjà créé le dossier deployment ce que je vais faire c'est que je vais faire un m v pour copier le contenu du dossier deployment que j'avais créé initialement ou sinon ce qu'on peut faire, on peut faire encore plus simple, on va recopier toutes les commandes qu'on a déjà copié. On va faire un mk dire, neuf g s tiret chat tiret API et on va faire la même chose après pour l'application remix, on va céder dedans et dedans, on va retélécharger l'exécutable. On va le refaire une deuxième fois. On va déziper tout ça et maintenant, on peut de nouveau copier cette partie, donc configurer l'application avec cette commande.

33:09 Cette fois, on n'a pas l'erreur du sudo et je vais appuyer trois fois sur entrée et une dernière fois pour confirmer les changements. Maintenant normalement, ça a dû créer le runner. Donc si on se rend ici, déjà on peut copier la dernière étape même si on ne va pas l'utiliser. Mais si on actualise la page ici en fait, si on reclique sur runner, on peut voir qu'on a maintenant notre runner qui est Selfostd Linux x soixante-quatre. Sauf que maintenant, on a envie que ce runner soit connecté h vingt-quatre à GitHub et que dès que GitHub lui envoie l'information, il y a eu un nouveau commit sur la branche mail, le runner, il dise à GitHub, vas-y, envoie-moi l'image docker, je vais la télécharger.

33:43 Donc pour ce faire, on a plusieurs commandes qu'on peut exécuter. On peut exécuter le SVC point s h install pour installer le GitHub runner Et là, on a un autre message qui nous dit, on va exécuter cette commande en tant que sudo, on va le faire tout de suite, on va l'exécuter en tant que sudo. Maintenant, on vient de le faire, donc on vient d'installer et à présent, on peut faire un start. Et là, on a fait un start. Le statut est actif.

34:05 Ce que ça signifie, c'est que si on retourne maintenant sur GitHub, avant vous voyez statut offline, si j'actualise la page, maintenant on voit le statut avec un point vert, ce qui veut dire qu'il est à l'écoute des nouveaux événements. Donc, on peut retourner sur notre action à cet endroit-là, sur l'action mise en prod et ce qu'on va faire maintenant, c'est que moi, cliquez sur replay parce que maintenant, on a un runner qui va écouter les événements. Bien sûr, ça ne va pas réexécuter notre action de build comme elle a déjà été terminée et elle a fonctionné, ça va seulement exécuter l'action de déploiement. Et là, on peut voir que le runner, il a compris ce qui se passait et c'est en train de déployer notre application. Donc là, si on retourne côté serveur et qu'on fait un docker PS juste pour voir, on peut voir qu'on a deux projets qui tournent.

34:44 On a le projet Nefjs remix mono-ripo, on a le projet Joeas R, mais on n'a aucun projet qui tourne sur le port huit mille. Ça tombe bien parce que notre projet va tomber sur le port huit mille, sauf qu'on a une petite erreur. En fait, on a créé le fichier docker compose point dev, mais on n'a pas créé le fichier docker compose point prod. Et c'est pour une raison assez simple. Déjà, on va dupliquer ce fichier.

35:06 Le fichier de la prod, on n'a pas envie de refaire un build. En fait, on ne va pas refaire un build. On va à la place rajouter l'image qui est hébergée sur Docker hub. Et pour ce faire, on rajoute la clé image qui prendra comme valeur algo max slash neuf g s tiret chat tiret API double point production. Donc maintenant qu'on a créé ce nouveau fichier de configuration pour la production, ce qu'on peut faire, c'est qu'on peut de nouveau push sur la branche mail.

35:29 Donc on va refaire un github point, un githubit, adde docker compose hors prod et on va de nouveau push sur la branche main. Et pendant que c'est en train de mettre à jour notre deuxième action, ce qu'on va faire, c'est qu'on va se connecter sur stripe et on va récupérer les variables d'environnement pour la prod. Donc, on va faire un sign in sur notre compte et maintenant que c'est fait, on va cliquer sur développeurs ici et on va cliquer sur API keys et on a donc deux clés. On a la clé publique qui peut être partagée de tunnel. C'est une clé qui sera accessible côté client et on a la secret key.

36:01 Et celle-ci, je ne vais pas vous la montrer, mais je vais la copier et je vais retourner dans settings sur GitHub, toujours sur mon projet net JSAPI. Et ici, on peut voir que j'avais déjà créé les variables d'environnement pour stripe secret key staging et je vais rajouter la variable stripe underscore secret leur score key qui prendra donc comme valeur ma clé API stripe pour la prod et on va faire la même chose pour les webhook ici. Donc on a les webhooks et ce qu'on a envie de faire, c'est de rajouter un endpoint et on va le rajouter sur la branche qu'on va appeler et puis tiret chat point algo max point f r et je me souviens plus quels sont les événements qu'on avait utilisés. Donc, on va retourner sur notre base de code. Ici, on va aller sur le fichier stripe contrôleur et on va cliquer sur le service pour y accéder à la méthode Handle WebOox Et c'est à cet endroit qu'on va retrouver les web hooks.

36:48 Donc on avait payment intents succeded, on peut rajouter cet événement-là, sélectionner et ça a l'air d'être le seul événement qu'on utilise pour les donations. Donc on peut le rajouter et on peut créer cet endpoint et bien sûr, ça nous donne un signing secret ici. Et c'est celui-là qu'on va devoir révéler pour pareil autoriser l'appel venant de Stripe. Donc, on va cliquer sur Rebeal et pareil, je ne vais pas vous le montrer, mais je vais le copier ici et je vais le rajouter dans les GitHub actions. Donc, ça s'appelle stripe webhook secret et maintenant, je l'ai mis en place, je l'ai créé.

37:22 Donc, ce qu'on peut faire, c'est qu'on peut retourner dans l'onglet action et on peut regarder notre action ici. On peut voir qu'elle a réussi. L'étape de déploiement a duré douze secondes et on peut retourner sur le serveur, sur iTerm et on peut faire un docker ps à nouveau et on peut voir qu'on a notre application qui est en train de restart. Normalement si elle restart, ce n'est pas bon signe, ça veut dire qu'elle est en train de cracher, mais on va voir quand même ce qui se passe. En tout cas, la base de code a été téléchargée et ce qu'on peut faire, c'est qu'on peut inspecter cette image pour voir si on a eu des messages d'erreur.

37:51 Pour ce faire, on peut faire un docker log et le nom de notre application. On peut voir qu'elle s'appelle net j s tiret chat tiret API leurs scores dev. Et là, on peut voir qu'on a ce message d'erreur. En fait, c'est notre serveur web socket. J'avais oublié qu'on avait donc un serveur web socket qu'on utilise.

38:06 Mais en fait, l'erreur ne vient pas des web socket. En fait, l'erreur vient du port huit mille parce que par défaut, ça utilise le port huit mille comme on le retrouve dans notre fichier main point t s sauf qu'on n'a pas défini cette variable d'environnement dans le fichier de core compost point dev. Ici en fait, on l'a défini, oui sur notre fichier point yamal, on a également dû le définir à cet endroit-là, mais c'est au niveau de GitHub ici dans les réglages dans secret and variable que je ne l'ai pas défini. Je pensais que ça allait prendre la valeur par défaut qui est donc de huit-mille, mais apparemment on est obligé de le rajouter. Maintenant, on vient de rajouter une variable d'environnement, donc on ne va pas le voir, on repêche le code pour réexécuter cette action, on a tout simplement besoin de réexécuter l'action de déploiement ici, prendre deux secondes.

38:48 Donc, on va cliquer sur rearun signal job et ça devrait mettre à jour notre action de déploiement avec les nouvelles variables d'environnement, y compris celle de stripe qu'on vient de configurer. Voilà donc maintenant, c'est terminé. On va de nouveau sur le serveur et on va refaire un docker ps et cette fois, on peut voir que ça ne crache pas. On va faire un docker log et on peut voir qu'on n'a aucune erreur à ce niveau-là. Ça fonctionne très bien.

39:09 L'application n'a pas crash sauf qu'on ne peut pas y accéder parce qu'on n'a pas encore configuré le nom de domaine. Pour configurer le nom de domaine du coup, on a besoin d'utiliser un service qui nous permet de d'acheter un nom de domaine, de le louer. Donc moi j'utilise OVH ici et il me suffit d'aller dans domaine name, de cliquer sur alcomax point f r et je ne vais pas racheter un nom de domaine vu que je paye déjà pour le domaine algo max point f r, ce que je vais faire à la place, c'est que je vais aller dans dns zone ici et je vais créer un sous domaine que je vais appeler, ça sera un sous domaine, ça sera un a et je vais l'appeler chat algomax point f r comme ceci. Et en target, on va mettre l'adresse IP du serveur au Stinger et donc celle-ci comme ceci. Et on va faire la même chose pour l'API et ça prendrait comme valeur la valeur qu'on a définie dans stripe ici de notre webhook.

39:54 Donc, c'est celle-ci API tiret chat point legomax point f r. On peut donc copier API tiret chat et l'adresse IP sera la même parce qu'on va héberger le front et le back sur le même serveur. Maintenant que c'est fait, on peut rajouter ça et on a une configuration caddie à rajouter que le nom de domaine soit bien relié à notre fichier. On peut donc s'inspirer de ce qui a déjà été créé dans notre configuration caddie. Encore une fois, tout ça, je vous l'explique en détail dans la vidéo sur comment héberger un projet javascript.

40:23 Mais en gros, ce qu'on va faire, c'est qu'on va faire ça. Donc, on va éditer notre fichier et à l'intérieur on va rajouter le nom du projet, donc l'url plutôt qu'on a défini ici donc API tiret chat point algo max point f r et on va faire un reverse proxy sur localhost huit-mille qui est le port en local de notre application SJS et on va également prendre le chat algomax point f r qui sera donc l'url qu'on va attribuer au front et on va pareil faire un reverse proxy sur localhost trois mille soixante par exemple. Parce qu'effectivement, on a déjà des projets sur le port trois mille, donc on va utiliser le port trois mille soixante pour le front. Maintenant, on peut sauvegarder les changements et on a juste à faire un sudo system CTL restart caddie comme ceci. Ça prend un petit peu de temps et ça va restart la configuration de Caddy serveur avec les changements qu'on vient de lui apporter.

41:13 Et maintenant, on peut déjà faire un essai. On va essayer d'accéder à l'url chat tiret API point algo max point f r. Et là, on peut voir qu'on a cette petite erreur. Le site est inaccessible, mais ce qu'on peut faire déjà, c'est qu'on peut aller sur le site check tiret hosts point net et on peut coller le nom, l'url de notre site pour voir si cette url redirige bien à notre serveur Hostinger. Pour ce faire, on va le passer en http:www.s.com et là, on peut voir que ça ne le redirige pas sur l'url de Hostinger.

41:39 Donc, on va retourner sur OVH et on va voir ce qui s'est passé. On va taper chat tiret a payé et on peut voir que rien n'a encore été créé du côté de OVH. Alors, je ne comprends pas ce qui s'est passé. Apparemment, ça n'a pas été créé chez OVH. On va devoir répéter l'opération, on crée une nouvelle entrée A, on copie l'IP du serveur au Stinger.

41:56 Ça sera la target et on va appeler le projet chat tiret API, next. On va confirmer l'opération et on va faire la même chose. Donc, on va garder la même valeur et le même serveur. Sauf que cette fois, le projet va s'appeler chat. Ce sera le nom du sous domaine et le domaine, c'est algomax point f r.

42:12 Pareil, on va sauvegarder et là, on peut voir qu'en fait, je m'étais un peu pressé. En fait, les valeurs ont bien été créées. Alors, je ne comprends pas. La bonne URL, c'est API tiret chat, donc chat tiret API on va pouvoir supprimer cette entrée et on va faire pareil sur la première entrée chat algo max pour éviter les bugs. Là en fait, ça doit prendre un petit peu de temps, je ne sais pas ce qui se passe, mais on peut voir que pour le sous domaine chat point algo max point f r, ça a bien détecté notre nouvelle ISP.

42:37 On l'utilise bien Hostinger International, mais bizarrement, ce n'est pas le cas pour notre API, pour notre chat tiret API point algo max point f r. Alors en fait, j'ai sûrement dû faire une connerie. Peut-être qu'on n'a pas le droit de mettre des tirets sur le site. C'est vrai que je n'ai jamais vu un site avec des tirets dedans. Donc en fait, on va totalement changer.

42:55 Ici, on va l'appeler API chat en un mot et c'est cette url qu'on va renommer. Ici, on va modifier ce champ a et on va l'appeler API chat en un seul mot. Maintenant, on peut voir si on retourne sur chaque host que ça a bien détecté le changement. Donc API chat point algo max point f r, si on accède à cette url sur Google comme ceci, on a toujours cette erreur. Par contre, on sait que maintenant ça fonctionne et on va devoir aussi modifier notre configuration caddie.

43:23 Donc ici, on va retourner sur API tiret chat et on va enlever le tiret et on va de nouveau relancer notre configuration caddie. Et maintenant, si on actualise la page, normalement, ça devrait fonctionner. Une technique qu'on peut faire aussi, c'est d'ouvrir un onglet en navigation privée et d'accéder à l'URL au cas où il sera mis en cache. Et là, on peut voir que ça a marché. Je suis sur l'URL happy I chat point logomax point f r et on a une erreur neuf pièces.

43:48 Si on va sur slash users comme ceci, on peut voir qu'on a toujours notre tableau vide. Donc notre application. Js tourne avec succès sur le serveur. Maintenant qu'on a mis en place le backend, on va maintenant s'occuper du frontend. Si on retourne sur notre compte GitHub, le code se mettra en production à chaque fois qu'on fera un nouveau push sur la branche main.

44:07 On retourne donc maintenant dans notre projet frontend ici et nous allons recopier toutes les étapes. C'est-à-dire installer docker, installer les GitHub actions et configurer le runner sur le serveur. Mais si on se rend dans le fichier point ENV ici, on se rend compte qu'en fait, on aura besoin de set up, deux variables d'environnement, le back-end URL et le web socket URL qui est défini à cette URL. Cependant, le problème, c'est qu'on n'a pas ouvert les ports sur notre serveur. Regardez, si on retourne sur notre projet back and ici, dans le fichier de corecompose point prod, on peut voir qu'on n'expose qu'un seul port, le port huit mille.

44:43 Sauf que dans notre fichier app gateway point t s, ici, nous exposons également le port huit mille un qui est le port des web socket. Donc, ce qu'on a envie de faire au final, c'est également de l'exposer et on va l'exposer de cette manière en rajoutant cette ligne dans notre fichier de Core Compose. Bien sûr, nous allons également rajouter cette ligne dans l'autre fichier de Core Compose point dev. Mais ce n'est qu'une partie du travail parce que effectivement, on va devoir également ajouter un nom de domaine et on va également le déclarer sur Caddy Server. Donc, on va commencer par retourner sur OVH, sur les informations de notre nom de domaine.

45:18 Ici, on va regarder tous les champs a et on a donc API chat point algo max point f r. Et nous allons rajouter une entrée, un champ a que nous allons appeler API chat, mais on va rajouter w s juste avant le API chat comme ceci. Et bien sûr, comme target, on va prendre la même IP. Donc ça va être WSAPI chat point algo max point f r qui redirige a cette IP. Maintenant, on va juste copier ce nom de domaine.

45:42 On va retourner sur le serveur et nous allons modifier à nouveau le fichier et c slash kdi slash kdifile. Et c'est à cet endroit qu'on va rajouter une nouvelle entrée, c'est-à-dire w s happy chat en algo max point f r et on va faire un reverse proxy sur le localost huit mille un comme ceci. Et maintenant, on va enregistrer. Maintenant, nous devons à nouveau retourner sur notre API pour mettre à jour nos changements, c'est-à-dire ouvrir le port dans le docker compose. Pour ce faire, on va tout simplement faire un git add plus et un git commit avec comme message add web socket portse et on va sur main.

46:18 Maintenant que c'est fait, on va pouvoir commencer à configurer ces fichiers pour notre frontend. Donc on va commencer par docker. On retourne sur notre API et nous allons copier tous ces fichiers, c'est-à-dire le docker Sale, les fichiers docker compose et le fichier docker ignore comme ceci. On les copie et maintenant on se rend dans notre front-end et on va tous les coller. Maintenant que c'est fait, on va modifier le fichier dockerfile.

46:40 On va laisser les dix premières lignes telles quelles. Ces lignes-là vont rester les mêmes. Au final, la seule chose que nous allons changer, c'est retirer les lignes de Prima vu qu'on ne l'utilise pas côté front. Et ensuite, on va retirer cette ligne-là également. Et notre build génère un fichier qu'on va appeler build et non pas dist comme ceci et ça devrait être bon.

47:00 Mais on va tester tout de suite avec Docker. D'abord, je retourne encore une fois sur le dossier a payé et je vais copier le fichier start point s h parce qu'on va utiliser la même logique. On copie donc le fichier start point s h et on retire cette instruction qui fait appel à notre service Prima. Et maintenant, on va kill notre terminal et nous allons lancer la commande shmod plus x start point f h et maintenant, on va modifier les deux fichiers de Core Compose parce que parce que nous avons défini dedans le nom du service. Ici, ça va être FGS tiret chat tiret front end slash dev et nous avons que deux variables d'environnement.

47:35 Nous avons un front end url et un web socket url et nous allons retirer toutes ces variables d'environnement puisqu'on en a plus que deux. Nous avons un back end url et un web socket url. Ici, comme nom de conteneur, on va mettre exactement le même, c'est-à-dire celui-là et nous allons seulement exposer le port trois-mille qui est le port par défaut de Linux. Maintenant, on va faire la même chose sur le docker composé de prod, c'est-à-dire qu'on va copier les deux variables d'environnement comme ceci et on va nommer le projet frontend underscore production. Ici aussi frontend underscore production et l'image va s'appeler NFGS tiret chat tiret frontend.

48:12 Et bien sûr, le port passera toujours le port trois mille. Maintenant, on va tout de suite vérifier que ça fonctionne bien. On va donc taper la commande de core compose tiret f de core compose point def point yamal up tiret tiret build. Et maintenant, on va regarder si ça marche bien. Normalement, ça devrait fonctionner du premier coup.

48:30 Et voilà, ça a bien fonctionné. Nous sommes sur le port trois mille. Si on clique sur le projet, on peut voir, on retrouve bien notre projet remix sur le port trois mille, sauf qu'on n'a pas le style. C'est un peu bizarre, non Alors, on va enquêter ensemble pour voir ce qui se passe. Si on retourne dans le fichier dockerfile, j'ai l'impression qu'on a oublié d'ajouter le dossier public ici.

48:50 Donc, nous allons tout de suite l'ajouter. Ça vient peut-être de là. On va rajouter le fichier public. C'est la dernière étape. Donc normalement, on ne va pas attendre longtemps et nous allons relancer le conteneur Docker.

49:01 Là, je vais d'abord kill le terminal pour arrêter l'instance en cours et je vais la relancer tout de suite. Et là, on peut voir que ça va tout de suite relancer. Alors, on va voir si on a un peu plus de chance. On utilise la page et là, nous avons le style. Ok, c'est mieux comme ça.

49:14 Donc, maintenant, on peut fermer cette fenêtre et nous pouvons passer à la suite. La suite c'est les GitHub actions. On retourne donc dans le fichier de notre a I et nous allons copier le dossier point GitHub ici. Et maintenant, on va le coller dans le projet frontend. Ça va être à peu près la même chose, qu'on va modifier quelques trucs.

49:31 Dans le fichier build, on va bien sûr modifier le tag de notre projet. Ça va être nefs j s tiret chat tiret frontend comme ceci. Et dans le fichier c I point yamal, nous allons modifier les variables d'environnement. Ici, on va donc rajouter deux secrets, le backend url et le web socket url comme ceci. Et bien sûr, à cet endroit là, nous devons également modifier le nom de l'image docker, c'est-à-dire qu'on va l'appeler front-end et nous allons également l'appeler front-end dans le commentaire, on ne sait jamais.

50:01 Maintenant que c'est fait, on va retourner sur GitHub et on va retourner sur le repository du front-end. Personnellement, je l'ai appelé comme ceci. Et ce que je vais faire, c'est que je vais aller dans les settings ici et je vais aller dans les secrets variables et je vais rajouter dans les actions de secrets. Le premier secret sera le back-end url et cette variable, c'est tout simplement l'API chat point algo max point f r. Donc je retourne sur GitHub et je colle https double point slash slash api chat point algo max point f r.

50:33 On sauvegarde et pour le deuxième secret, c'est le web socket underscore url. Et ça va être exactement le même lien, sauf qu'on ajoute w s au début. Effectivement, on n'a pas besoin de rajouter WSS. On peut utiliser les web socket en https comme ceci. Maintenant, on rafraîchit la page, on sauvegarde cette valeur et on peut maintenant passer à la suite.

50:53 La suite, ça va être de reconfigurer le runner GitHub pour ce repository. Pour ce faire, on se rend dans action et on clique sur runner et on va répéter l'opération. Donc new self hostile runner, ça sera sur le même serveur, donc on va sélectionner Linux et nous allons copier cette marche à suivre. Sauf que nous, on va être un peu plus malin. On va se rendre à la racine et on va faire un l s tiret l et on peut voir qu'on avait créé un dossier qui s'appelle deployments et si on s'est dit dans le dossier deployments et qu'on refait un l s tiret l, on peut voir que c'est à cet endroit qu'on avait téléchargé la base de code de notre premier runner pour l'API.

51:28 Donc ce qu'on va faire, c'est qu'on va faire un cd double point et nous allons renommer ce fichier deployments en fichier net j s tiret chat tiret API. Pourquoi je le renomme Tout simplement pour savoir dans quel fichier se trouve la logique de quel repository. Et maintenant, je vais faire un m k dire du dossier deployment et dans ce dossier, je vais faire un m v du dossier NSJS tiret chat tiret API pour le déplacer dans le fichier deployment comme ceci. Maintenant si on fait un cd dans deployment et qu'on fait un l s tiret l, on retrouve le dossier ns j s chat API et c'est dans ce dossier que je vais créer un autre dossier qu'on va appeler ns j s net j s tiret chat tiret frontend ou plutôt front comme ceci. Maintenant qu'on a créé ce nouveau dossier, nous allons céder dedans net j s chat tiret front et c'est à l'intérieur que nous allons réinstaller cet exécutable.

52:17 Une fois installé, on exécute le reste des instructions et on va déziper ce fichier. Et maintenant, on peut passer à la suite. On va configurer le runner GitHub comme ceci. On appuie trois fois sur Entrée. On attend un peu et on va encore appuyer sur Entrée.

52:31 Et maintenant, on lance la commande sudo FVC point f h install pour installer le runner qui va ensuite tourner en tâche de fond. Et après l'install, on va faire un sudo point slash FVC point f start. Et maintenant, notre runner est actif en tâche de fond. Pour vérifier, on retourne sur GitHub et on retourne sur runner ici et on peut voir qu'il est au statut. Donc c'est bon, la prochaine fois qu'on va poche du code sur notre branche main, le code sera détecté.

52:57 Donc maintenant, on va retourner dans VS Code, dans notre projet front-end, ici, on va tout clear et nous allons faire notre commit. On va donc faire un github point, un github commit add github actions et on va faire un push sur la branche main. Sauf que si on retourne sur le serveur et qu'on affiche le contenu de notre fichier qualifile, on peut voir ici qu'on fait un reverse proxy sur localast trois mille soixante, ce qui signifie que notre projet est accessible sur le port trois mille soixante. Sauf que ce n'est pas le cas. Dans le fichier de quoi qu'on pose en prod, ici, on peut voir qu'on redirige le port du conteneur trois mille vers notre port trois mille.

53:34 Sauf que ici, on s'est trompé. Effectivement, sur le serveur, ça sera le port trois mille soixante parce que le port trois mille est déjà utilisé par notre projet. Donc, je modifie cette erreur, mais avant de push le code, on va aller dans les actions GitHub pour voir si c'est la seule erreur que nous avons. Ici, on peut voir que l'action a échoué et si on se rend dans le Docker Build, en fait le problème, c'est qu'on a tout simplement oublié de configurer déjà les identifiants Docker et ensuite on n'a pas créé notre repository, NSJS, chat net. Donc on va le faire tout de suite.

54:04 On va se rendre dans repositories. Ici, nous allons créer un nouveau repository qu'on a appelé du coup, net j s tiret chat tiret frontend. On va copier ce nom, net j s chat frontend et on va le créer comme ceci. Et maintenant, on doit retourner sur GitHub et rajouter les deux dernières actions qu'on avait déjà ajoutées dans l'API, mais cette fois, on les ajoute dans le front. Donc, on va se rendre dans secret and variable et nous allons cliquer sur action et nous allons rajouter le docker hub user name et donc égal à algo max et le docker hub underscore token.

54:36 Maintenant que c'est fait, on ne devrait plus avoir de problème. Alors on va se rendre dans notre fontaine et nous allons faire un github point pour ajouter notre changement sur le port trois mille soixante, change docker on pose port et nous allons à nouveau push ce code sur la branche main. Maintenant que c'est fait, il nous suffit de retourner sur GitHub pour voir si l'action se lance bien. On clique dessus et là, on peut voir qu'elle est en train d'être exécutée. Notre action est maintenant terminée sur la prod, donc on va essayer de s'y connecter.

55:05 On va taper sur Google chat point algomax point f r. Là, on peut voir qu'on est bien connecté. Maintenant, on va s'inscrire pour voir si ça fonctionne bien. Je vais donc créer un compte Virgile arobase algo max point f r, un mot de passe ABFC un, deux, trois, s'inscrire et là, c'est plutôt bon signe. Ça m'a redirigé sur la page de connexion, sauf que je ne suis pas connecté.

55:26 Alors, on va essayer de se connecter tout de suite. Virgile at algomax point FRABC un deux trois, on se connecte et là on a une erreur. En fait, il n'arrive pas à se connecter au localost huit-mille slash, slash login. Alors, à quoi est-ce que c'est dû On va voir ça tout de suite. On retourne sur le serveur ici et nous allons inspecter les log des deux projets.

55:46 On va d'abord inspecter les log de notre API ici et là on peut voir qu'on a en fait une erreur au niveau de l'envoi de l'e-mail. On peut seulement envoyer des emails de test aux emails que nous possédons. Dans ce cas-là, virgin Boris arobase hotmail point f r. Donc j'ai l'impression que c'est ça qui a causé notre erreur. Alors ce qu'on peut faire, c'est qu'on peut ouvrir les logs et on peut rajouter l'instruction tiret f pour les laisser ouverts en tâche de fond comme ça.

56:09 Maintenant, on va refaire un essai, on va s'inscrire à nouveau. Cette fois en mettant le mail qui est autorisé par Resend et on va mettre comme mot de passe ABC un deux trois. Si on clique sur s'inscrire, on peut voir que maintenant ça charge bien, sauf que on n'est toujours pas connecté, c'est bizarre. Et ici, on peut voir qu'on a de nouveau la même erreur. Et ici, on peut voir qu'on a maintenant par contre une ID qui est console logée dans la console.

56:32 Alors qu'est-ce qui s'est passé Déjà, on va regarder, voir si on a reçu le mail. On peut voir ici que je viens de recevoir le mail de la part de Risem point dev. Le mail, c'est bonjour Virgile et bienvenue sur Nest JS chat. Nous sommes heureux de vous avoir parmi nous. Donc l'envoi de mail a bien fonctionné cette adresse email.

56:49 Donc cette erreur-là a été résolue. En fait, à quoi cette erreur est due Eh bien au service que nous utilisons pour envoyer les mails, c'est-à-dire resend point dev. Si on se rend donc sur resend point com et qu'on se connecte avec notre compte GitHub, ici, on peut voir que j'ai sûrement utilisé une API de test. Alors en vrai, je ne comprends pas trop le problème. Ce token n'a pas l'air d'être limité.

57:10 Ici, on peut voir qu'on a l'accès pour envoyer depuis tous les domaines, sauf que si on clique sur le domaine, il nous propose de rajouter notre domaine. Mais je pense que ce qu'ils veulent dire, c'est que si on ajoute notre domaine, on peut ensuite, on peut ensuite envoyer notre email à partir de notre propre nom de domaine. Par exemple, onboardin arobase algo max point f r. Mais là, ce n'est même pas ce que je voulais en fait. Que je voulais, c'est tout simplement envoyer un email à n'importe qui.

57:33 Alors ce qu'on peut faire, c'est qu'on peut copier ce message d'erreur pour débloquer un peu resend et cette erreur et on va voir à quoi cette erreur est liée. Alors voilà, ici, ils nous disent bien que pour autoriser tout envoi de mail, on a besoin d'ajouter un domaine que nous possédons. Effectivement, ils font ça pour ne pas dégrader la note de leur nom de domaine. Parce que si j'utilisais ce projet et que j'envoyais des mails à cent mille personnes et que je spammais leur boîte mail, ça dégraderait la note de leur domaine resend point dev. Et ça, ils veulent l'éviter.

58:02 Mais ce n'est pas grave pour le moment, on a une autre erreur qu'on a envie de corriger d'abord. On veut pouvoir se connecter sans problème. Donc cette fois, je vais faire une tentative de connexion. Je clique dessus et là, j'ai toujours cette erreur. Il est impossible pour moi de me connecter.

58:15 Alors à quoi c'est dû Est-ce qu'on a un message d'erreur dans la console On n'a pas de message d'erreur côté a p. Donc on va qu'il le terminal et nous allons faire la même commande, mais pour le frontend et sur la branche production. Et là, on peut voir qu'on a d'autres types d'erreurs ici. Ce qu'on va faire, c'est qu'on va de nouveau cliquer plein de fois sur se connecter et là on peut voir qu'on a ces erreurs là, c'est-à-dire des statues de sang. En fait, il n'y a rien qui pose problème dans la console.

58:39 On ne sait pas vraiment à quoi l'erreur est liée parce qu'on n'a aucune erreur que ça soit au niveau du front-end et du back-end. Donc, on va essayer d'inspecter la console ici, on a une erreur au niveau des web socket, mais je ne pense pas que le problème vienne de là. Mais on va quand même essayer de se connecter au web socket, ça m'intéresse. On va accéder à cette url et là, on peut voir en fait que ce site ne propose pas une collection sécurisée. Et en fait, cette erreur, elle vient du fait qu'on n'a pas relancé Caddy.

59:03 Donc, on va le relancer tout le site avec un sudo system CTL, restart de Caddy pour déjà corriger le problème web socket. Maintenant que c'est fait, on actualise la page et on a une erreur différente. Cette page n'existe pas. Cependant, si on retourne sur le site ici, on peut voir que l'erreur du socket io a disparu, je crois. Donc ce qu'on va faire, c'est qu'on va refaire une tentative de connexion, même si je ne pense pas que ce soit lié à ça.

59:26 Ici, en fait, on n'a pas vraiment la raison de notre erreur. Donc ce qu'on a envie de faire, c'est de voir si il connaît bien l'url du backend. Si on fait un docker inspect, net j s net JS direct frontend underscore production et qu'on fait un de backend ici, on peut voir que l'url est la bonne. C'est p I chat point algo max point f r. Mais est-ce que c'est le cas au niveau du code Si on retourne dans notre projet front-end ici et qu'on copie le lien locallast huit mille et qu'on le colle dans la recherche, ici on peut voir qu'effectivement on a oublié de changer cette valeur.

59:59 Ici on a fait une erreur de débutant, on a codé en dur la valeur de notre backend url. Ce qu'on va faire du coup, c'est qu'on va remplacer cette valeur par INV point backend underscore url comme ceci. En fait, c'est un process point INV et on va coller cette valeur partout où elle est utilisée. Ici aussi, on va la rajouter et on n'oublie pas de rajouter les backtics. On va également la rajouter dans le fichier for good password qu'il utilise trois fois.

60:26 Une première fois ici, une deuxième fois ici, on n'oublie pas les backtics et une troisième fois ici pour le reset du password. Et encore une fois, on n'oublie pas les backticks. Forcément, avec une erreur pareille, ça n'aurait jamais pu marcher. Donc ce qu'on va faire, c'est qu'on va commit ça. On va mettre fixd Back and URL coded et on va push cette nouvelle version qui je l'espère est maintenant corrigée.

60:49 Et maintenant on retourne sur GitHub pour voir la nouvelle action qui est en train de travailler. Voilà, on est maintenant à l'étape de déploiement dans la c I et on va bientôt avoir la réponse. Est-ce que le problème a été résolu La CAI est terminée, on va retourner sur l'application et on va retaper notre mot de passe et cette fois, on a réussi à se connecter. Ça marche du tonnerre. Donc maintenant, on va envoyer un message à un utilisateur.

61:14 Sauf que maintenant, on est en fait le seul utilisateur qui est présent sur cette plateforme. C'est bien dommage. Alors, on va tester, voir si tout fonctionne. On va d'abord choisir un avatar. On va utiliser par exemple cette image.

61:26 On clique sur modifier l'avatar et là, on peut voir qu'on la retrouve bien. Ça a bien marché, donc on est bien connecté à nos n s trois. Cette image est publique, je peux copier son lien et je peux la télécharger au format que je veux. Donc ça, c'est déjà cool. Maintenant, on va voir si ça fonctionne bien au niveau de stripe.

61:43 On va cliquer sur je confirme mon compte et là on a une erreur serveur au niveau de l'onboarding. Alors on a un problème, alors on a un problème avec stripe. Qu'est-ce qui s'est passé On va le voir tout de suite en inspectant les logs. Si on fait un docker log de notre backend, donc c'est épi underscore dev, ici, on peut voir qu'on a cette erreur. You must verified your identity to use connect, on create life connectd account.

62:08 On doit donc cliquer sur le Dashboard stripe et s'identifier pour pouvoir être autorisé et utiliser connect en prod. Et pour cela, il faut tout simplement ajouter notre carte d'identité sur le compte Stripe à cet endroit-là. Si je clique sur le lien, on peut voir qu'il me demande donc de vérifier mon identité avec Stripe. Pour cela, j'ai besoin de scanner une pièce d'identité ou alors prendre un selfie pour qu'il puisse me reconnaître. Si je clique sur continuer, on peut voir qu'il me demande de scanner un QR code.

62:34 Sauf qu'on ne va pas faire cette étape maintenant, on ne va pas tester si les paiements Stripe fonctionnent bien. Ça a l'air de marcher en tout cas parce qu'il a détecté qu'on est sur l'environnement de production et l'erreur ne vient pas dans stripe non configuré. Il faut juste rajouter nos documents d'identité. Donc ce qu'on va faire à la place, c'est qu'on va essayer de créer un deuxième compte même si Resend ne nous autorise pas à le faire. Donc pour ce faire, on va se déconnecter ici et on va retourner sur Néon point tech pour voir si on a bien deux comptes qui ont été créés.

63:01 On va donc dans table ici et nous allons dans user et on peut voir qu'on a bien deux comptes qui existent. On a quand même le compte virgin arobase ergomax point f r. Au final, il existe bien, c'est juste que ça ne nous a pas identifié. Donc ce qu'on va faire, qu'on va se connecter avec ce compte-là. Et comme on peut voir, ça fonctionne très bien, donc on va cliquer sur historique des conversations ici pour se rendre sur la page d'une conversation qu'il est possible de faire.

63:25 Et on va avoir une conversation avec Virgile Hello Man, ici on va inspecter le code pour voir si les web socket fonctionnent. Et pour ce faire, on va ouvrir une deuxième fenêtre en navigation privée et nous allons copier l'url du site et on va ouvrir cette fenêtre ici. On peut voir que j'ai été redirigé sur la page d'accueil parce que je ne suis pas connecté. Donc, je vais me connecter avec Virgile et je vais de nouveau me rendre sur l'url de cette conversation et je vais tout simplement répondre waouh, new. Et là, on peut voir que le message est apparu automatiquement ici parce que les web sockets ont bien fonctionné.

63:58 Ça a très bien marché et on va même ouvrir la console pour voir à quel point ça marche bien. Test, test, test et c'est ici qu'on retrouve notre donnée mise à jour du coup. Si là j'envoie d'autres messages, test, test, test pour voir que la connexion reste ouverte et que je reçois des messages à l'infini. Maintenant bien sûr, pour envoyer de l'argent à vos utilisateurs, vous devez au préalable vérifier votre compte Stripe et fournir votre pièce d'identité. Et bien sûr, pour pouvoir envoyer des emails, vous devez d'abord ajouter un nom de domaine et on peut le faire ensemble tout de suite.

64:32 Ce qu'on va faire, c'est qu'on va d'abord choisir le nom de domaine qu'on souhaite utiliser, par exemple chat algomax point f r et on peut seulement choisir cette région malheureusement, donc on va l'ajouter. Et ensuite, une fois que c'est fait, on a besoin de rajouter des champs chez OVH pour l'url chat point algomax point f r. Donc pour ce faire, on va retourner sur OVH ici et on regarde, il nous demande de rajouter le champ m x avec cette valeur. Donc on retourne sur OVH et on va ajouter une entrée de type m x ici avec comme valeur cette valeur-là qu'ils nous ont fourni ici et avec comme nom send point chat ici. Donc on retourne sur OVH et on va rajouter le nom ici et ils veulent que ça soit en priorité dix comme ceci.

65:13 On va rajouter la priorité dix et on appuie sur NEXT et sur confirmer. Maintenant, on retourne sur resend et on va rafraîchir cette page pour voir s'il détecte déjà le changement. Maintenant, on va rajouter deux champs txt. Le premier, ça sera cette valeur. On retourne ici et on va ajouter un champ txt avec cette valeur à send point chat.

65:33 Alors pourquoi send point chat Déjà, c'est send point et notre nom de domaine, mais comme nous avons un sous domaine qui s'appelle chat, eh bien, ça va utiliser send point chat comme ceci. Maintenant, on va appuyer sur next et on va retourner une dernière fois sur Resend et on va copier la dernière clé TXT. Ici, on rajoute un champ TXT comme ceci avec comme valeur celle-ci et on peut maintenant sauvegarder cette valeur et on va retourner sur Resend. Et ce qui est cool, bien sûr, c'est qu'on peut rajouter avec Refsand plein d'options comme traquer les clics par exemple et traquer le taux d'ouverture. Bien sûr, pour ajouter encore plus de sécurité, on peut ajouter cette dernière option, le des marques en ajoutant cette valeur.

66:13 Encore une fois, c'est un TXT qu'on va devoir ajouter. On va se rendre sur OVH, on va ajouter un champ txt avec ça comme valeur et on va lui assigner cette valeur là comme ceci. Maintenant, on peut sauvegarder et ça devrait être bon. On n'a plus qu'à attendre que resend vérifie nos informations. Donc, on doit cliquer sur verifie DNS record comme ceci et on peut voir que les informations sont en attente et qu'elles viennent d'être vérifiées.

66:37 Ça a très bien fonctionné. Donc, je pense que maintenant, on doit mettre à jour notre code pour que ça envoie le mail depuis le bon domaine. On va retourner à cet endroit-là et je vais regarder si on peut modifier le domaine d'envoi. Est-ce qu'on peut changer le domaine au niveau de notre code C'est dans le from effet. Donc on va quand même le faire pour tester.

66:56 On va mettre Virgile et on va mettre Virgile arobase chat point algo max point f r. Maintenant qu'on a ajouté ce nom de domaine, ce qui nous reste à faire, c'est de versionner cette nouvelle version de notre API. Mais juste avant de le faire, on va quand même retourner dans le fichier de corps compost point prod et ici, on va changer cette faute de frappe parce qu'on a oublié de copier coller ici, de rajouter production, non pas dev parce que c'est bien la branche production à ce niveau-là. Maintenant que c'est rajouté, on peut commit change de resend domain et on peut push origin head. Maintenant, on va se rendre sur GitHub pour voir les avancements de notre action et on peut voir qu'on a peut-être une petite erreur parce qu'on a renommé le dossier de déploiement pour cette application.

67:37 Et donc du coup, j'ai l'impression que le runner GitHub, il ne fonctionne plus. Donc on va tout de suite le reconfigurer. On va faire un cd et on va retourner dans le dossier deployment et on va aller dans le dossier, et on va cette fois faire l'étape inverse, c'est-à-dire qu'on va désinstaller ce runner-là. On va donc faire un install plutôt que d'abord un stop, mais là en fait j'ai l'impression que j'ai fait une petite erreur. Si on se rend dans les dans les informations de notre projet GitHub, dans action et dans runner ici, on peut voir que le runner en fait il est offline, à dire qu'on l'a clairement carrément tué.

68:08 Donc, ce n'est pas grave, on va en recréer un nouveau. D'abord, on va supprimer ce dossier, on va faire un RMRF de nsjs-chat-chat-api et on va recréer ce dossier une dernière fois avec le runner. En fait, on a fait ça tout simplement pour s'organiser sur le serveur, qu'on ait un seul dossier avec tous nos déploiements pour que ça soit beaucoup plus simple de les retrouver. Donc, on va faire un m tabirs NSGS tiret chat api, on retourne dedans dans ce fichier et on va ajouter un runner pour la dernière fois en copiant chacune des étapes une par une comme ceci. On va copier la deuxième étape et enfin la troisième étape.

68:41 Et maintenant, on va configurer ce runner. Et après l'avoir configuré, GitHub recevra le signal ici dans notre action GitHub va recevoir le signal et il va terminer cette action. Donc, on appuie sur entrée et on peut voir qu'il a déjà trouvé un runner qui possède le même nom. Donc, en fait, on va appuyer sur Y pour remplacer le runner existant comme ceci. Et après avoir configuré, maintenant, on va refaire un SVC install comme ceci et un SVC start.

69:09 Et j'ai l'impression que ça fonctionnait. En fait, on n'a même pas eu besoin de lancer ses commandes parce que le runner existait déjà. Là, si on fait un sudo SVC point s h status, on peut voir que le runner, il est totalement décédé. Donc ce qu'on peut faire, c'est qu'on peut l'arrêter et même le désinstaller. Mais en fait, j'ai l'impression que ça ne marche vraiment pas et ça, c'est un petit problème.

69:29 Si on fait un status, ok, il n'est pas installé. Là, c'est bon. On va faire ce qu'on va le réinstaller et on va le relancer et maintenant ça a l'air d'être mieux. En fait, on a dû le désinstaller pour le réinstaller. C'était un petit peu bizarre.

69:42 Là, si on rafraîchit la page, on peut voir qu'il est maintenant actif. En fait, il n'est plus idle, il est actif parce que GitHub vient d'exécuter notre action de déploiement. Donc, ce qu'on va faire maintenant, c'est qu'on va supprimer chaque onglet qu'on a d'ouvert. On attend que le déploiement se termine et là, on a même eu une erreur au niveau du déploiement. Alors là, c'est vraiment marrant.

69:60 On a toutes les erreurs, c'est parfait. Et cette erreur-là, elle est liée en fait à l'image qu'on avait créée qui s'appelait API underscore dev et que nous avons renommé. Donc, pour réparer cette erreur, ce qu'on va faire, c'est qu'on va faire un docker système prune pour tout simplement supprimer les images docker qui ne sont plus utilisées, notamment celles de l'environnement de développement. Et ça nous demande donc de confirmer parce que ça va supprimer toutes les images et il n'y aura plus de notions de cache. En tout cas, ça va supprimer toutes les images qui ne sont pas actives.

70:31 Donc ne vous inquiétez pas, notre projet frontend est actif, donc ça ne va pas la supprimer et l'API qui est actuellement présente est active, donc ça ne va pas la supprimer. Ce qu'on peut faire, on peut appuyer sur oui et comme l'API est actuellement active, ça ne la supprime pas. On a quand même envie de la supprimer, donc on va lancer la commande docker stop et le nom de notre projet, comme ceci et nous sommes maintenant en train d'arrêter une image docker pour essentiellement la supprimer. Maintenant, on peut retaper la commande d'avant docker system prône comme ceci et on va confirmer et on peut voir que ça supprimer notre image docker. Maintenant que c'est fait, on peut retourner sur GitHub, sur notre action de déploiement et nous allons la réexécuter pour voir si ça résout le problème.

71:15 Et là, cette fois, l'action de déploiement a fonctionné. Donc on va retourner sur notre terminal et nous allons faire un docker log cette fois de l'image nfs g s chat tiret API underscore production. On en rajoute le tiret f. Et là on peut voir que ça fonctionne beaucoup mieux. Donc on va retourner sur notre application et nous allons créer un dernier compte pour voir si on reçoit bien les emails.

71:37 Le compte ça va donc être 5 gamer Council arobase gmail point f r. Bien sûr, on met ça dans l'adresse email et on va s'appeler epictète et le mot de passe, ce sera ABC un deux trois. Maintenant, on va s'inscrire et on peut voir que ça m'a bien connecté. Ça m'a connecté, donc le domaine a été confirmé par Rissend. Et si on regarde les emails que nous avons reçus, ici, on peut voir Virgile.

71:58 Bienvenue sur la plateforme et ça a été envoyé par Virgile arobase chat point algo max point f r. On peut donc le signaler comme non spam. Bonjour et bienvenue sur neuf j s chat. Nous sommes heureux de vous avoir parmi nous. Et voilà, nous avons terminé cette intégration de notre chat avec Nest JS et remix.

72:17 N'hésite pas à me dire dans les commentaires ce que tu as pensé de cette vidéo. Est-ce qu'elle t'a plu Est-ce que tu as appris quelque chose Et on se retrouve très bientôt pour une prochaine. À plus.

Vidéos similaires
On ajoute les fonctionnalités à notre app monorepo
RemixNestJS

On développe une app d'échanges de services

Dans cette vidéo, nous allons ajouter des fonctionnalités à notre app : - Création d'une proposition de service (tondre la pelouse) - Lister les services proposés - Faire appel au service (en faisant une offre au prestataire) - Proposer un prix - Pouvoir accepter ou refuser le prix - Éditer le profil utilisateur

Rejoins la

newsletter