Déploie un monorepo Remix ! CI CD, Github Actions, Docker

00:00 La dernière vidéo, nous avons configuré ensemble le mono-repo pour qu'on puisse utiliser remix avec Next JS. Nous allons maintenant tout de suite déployer cette application en utilisant docker, un serveur VBS et les Gito Version. Et on va configurer tout ça en premier pour ne plus rencontrer de problèmes durant nos développements. Comme base de code, nous allons utiliser ce projet qui est dispo sur le repository remix tiret NSGSSJS tiret molo repos. On l'ouvre dans vscode et nous avons ceci.

00:29 On peut donc commencer par faire un NPM install pour installer toutes les dépendances. On va donc lancer la commande NPM install tiret tiret legacy peer deps comme ceci. Maintenant, nous allons créer une image docker de notre application. Pour ce faire, nous allons créer un premier fichier que nous allons appeler Docker Sile comme ceci et qui va contenir la configuration de notre image. Ensuite, nous allons créer un deuxième fichier qui va s'appeler point docker ignore qui va contenir une liste de fichiers qu'on souhaite ignorer et qui ne seront pas copiés dans notre image Docker.

01:01 Et ensuite, le troisième fichier qu'on va créer, ce sera un fichier docker tiret compose point yamal comme ceci. Et pour le moment, on va seulement l'utiliser en environnement de développement. Donc, on va le renommer et on va l'appeler docker tiret compose point dev point yml comme ceci. Commençons donc par le fichier docker fail. Si on se rend sur la documentation de turboripo, par exemple en tapant turboripo docker fail comme ceci, on peut voir qu'ils ont une documentation qui s'appelle deploying with docker.

01:28 Et on peut voir si on scrolle tout en bas qu'on a un exemple de dockerfile ici qui utilise la version dix-huit de Alpine et qui va installer plusieurs librairies, y compris turbo pour configurer le projet. Comme on utilise un turbo repos, on va avoir besoin de s'inspirer de cette configuration. Sauf qu'on s'inspire aussi du dockerfile de l'epic stack. Si on tape sur Google epic stack GitHub, ici, on retrouve le repository pour l'epic stack, qui est une stack remix qui a été mise en place par Kenty dad. Ce repository contient dans le dossier other ici, il contient un fichier docker fail dont nous allons également nous inspirer.

02:08 On va donc retourner dans notre fichier docker fail. On va donc maintenant copier la configuration docker comme ceci et on va l'analyser ensemble. On télécharge donc la version Node dix-huit tiret alpine qui est une image Docker qu'on va utiliser avec déjà Node. Js d'installer. Ensuite, on la rend compatible avec la plateforme AMD soixante-quatre.

02:26 On va donc lancer la commande APK update, qui est une sorte de mise à jour système qui va se passer à l'intérieur de notre image, puis nous allons créer un dossier app dans lequel on va commencer à construire notre application. Ensuite, on installe turbo repos en global parce qu'on va en avoir besoin et nous copions l'intégralité des fichiers qui sont présents dans le dossier slash app comme ceci. Donc si on regarde tous nos dossiers ici, on peut voir que le copy point point va copier tous ces dossiers-là et il va les mettre dans le dossier slash app. Mais ça ne va pas copier les fichiers qu'on a ignoré dans le fichier docker ignore. Ensuite, nous allons lancer la commande turbo prune tiret tiret docker.

03:05 Ce que ça va faire, c'est que ça va regarder tous nos packages et ça va supprimer chaque fichier qui n'est pas utilisé par notre backend. On peut voir si on se rend dans notre backend qu'il utilise les trois autres. Il utilise e s lint, le frontend et texte script. Donc le prône ne va pas supprimer grand chose. Mais si jamais vous rajoutez dans le futur d'autres librairies, elles seront supprimées.

03:27 Ensuite, après avoir fait ça, on fait un from et vous avez dû remarquer, mais on fait beaucoup de from ici. Il y a un premier from pour télécharger l'image au début et ensuite nous refaisons un from en ajoutant un layer, une sorte de calque à notre image de corps et nous refaisons un from encore ici et si on se rend tout en bas, on peut voir qu'on va faire un from une dernière fois. Alors pourquoi a-t-on besoin de faire des from au lieu de tout télécharger dans un seul endroit Eh bien, c'est pour optimiser le poids final de notre image Docker. C'est-à-dire qu'à la fin de notre image Docker, pour qu'elle soit beaucoup plus légère, on veut qu'il y ait seulement le code compilé et prêt à être lancé. On ne veut pas qu'il y ait toutes ces configurations TSconfig, ES Lint qui sont nécessaires en environnement de développement, mais qu'on n'utilise pas du tout en production.

04:12 Par contre, pour build l'application, donc pour build le code source de production, on en a besoin. Donc, ce qu'on fait, c'est qu'on télécharge toutes les librairies et ensuite on va faire un from, on va copier seulement les librairies de production. Dans le package json, vous pouvez voir ici que les réelles dépendances de production, il y en a seulement 6 pour l'attraper. Par contre, nous avons une dizaine, voire même une vingtaine de dépendances en environnement de développement. Dans notre docker, on va tout télécharger.

04:39 Ensuite, une fois qu'on a build l'image de prod, on va supprimer chaque fichier généré qui ne sera pas utilisé en production. Et c'est ce qu'on est déjà en train de faire à ce niveau-là. Donc du coup, on part sur une nouvelle base qu'on appelle installeur et on réinstalle leads C6, on refait une mise à jour système et on redéfinait une nouvelle fois notre dossier qui s'appelle slash app. Mais cette fois, au lieu de copier toute la base de code comme ici, donc nos quatre dossiers avec leur note module qui sont qui pèsent une tonne, va seulement copier le fichier Git ignore et l'équivalent du build de turbo repos. On peut voir ici que c'est un commentaire laissé par turbo repos qui va d'abord installer les dépendances qui changent moins souvent.

05:18 Par exemple, quand on va coller un nouveau featur dans notre backend ici, on va sûrement modifier un contrôleur. Donc notre backend, il est amené à changer tout le temps. Par contre, les librairies comme E s Lint et Typescript sont amenées à changer beaucoup moins souvent. On peut voir ici qu'on va copier seulement le dossier Git ignore et ensuite on va copier le fichier qui a été généré par turbo repos. Donc regardez ce qui se passe ici nous faisons un turbo prune de virgile bagend tiret tiret docker.

05:45 On va lancer cette commande dans le terminal tout de suite pour voir ce que ça me fait. Sur cette commande donc turbo prune arobase virgile slash backend tiret tiret docker ça va générer un prund mono repos pour virgile backend. Ça ajoute donc chacune des dépendances qui sont utilisées par Virgile backend dans un dossier qui s'appelle out ici. On peut voir qu'on a le full, la configuration totale et une copie de toutes les dépendances qu'on a besoin d'utiliser pour le backend. Et ça a du coup omis chacune des dépendances qu'on n'utilise pas dans le backend.

06:15 Mais ça ne marche pas pour notre exemple parce qu'on utilise absolument tout ce qu'on a configuré. D'ailleurs, il ne faut pas oublier de rajouter ce dossier dans notre fichier GitTener. Donc, on va le rajouter tout de suite. On va rajouter le dossier out comme ceci pour ne pas risquer de le versionner. Maintenant que c'est fait, on va continuer dans notre docker file.

06:32 On copie donc le contenu qu'on a généré avec turbo prune, puis nous faisons un mpm install pour installer toutes les dépendances, y compris les devs dependances. Et enfin, on copie tout le fichier qui a été prune par Turboripo. Donc tout le fichier, sauf les dépendances de notre projet qui ne sont pas utilisées par le backend. On copie également la configuration de turbo et ici, nous pouvons ajouter le cache. Et l'ajout du cache, c'est l'avantage de Turboripo parce qu'il ne va pas répéter les opérations qu'il a déjà faites.

07:02 Il va les mettre en cache pour accélérer le build et chaque étape jusque déploiement. Ensuite, nous ajoutons quelques variables d'environnement, par exemple la time zone et la variable d'environnement node n v qui sera donc en production de notre docker et nous ajoutons prisma, mais on peut commenter ces lignes pour l'instant parce qu'on ne l'a pas encore configuré. Puis nous faisons un NPMRN build. Ce NPMRN build, il est donc fait à la racine de notre application comme ceci. Ça va donc lancer la commande turbo build comme ceci.

07:31 Et après avoir fait un build avec toutes les dépendances, y compris les devs dependency, on va repartir sur une nouvelle base qui sera donc vierge avec aucun fichier dedans et on va encore une fois définir un dossier pour appeler app et à l'intérieur de ce dossier, on va seulement copier les fichiers dont on a besoin pour faire tourner la prod. Et ensuite pour les raisons de sécurité, on crée un nouvel utilisateur à l'intérieur du docker qui a les permissions minimum pour faire tourner notre application. Je pense même qu'on peut se de commenter ces deux lignes parce qu'on les a déjà défini plus haut. On peut voir qu'on copie le contenu d'un fichier qui s'appelle API, mais pour notre cas, ça va être le backend. Donc j'ai oublié de le copier coller ici, mais pour nous c'est le dossier backend.

08:13 Donc on commence par copier son package point json, puis son fichier dist et ses noles modules et on copie aussi à l'intérieur des noles modules la librairie Virgile slash fontaine qui sera donc notre application remix. Et on copie également la configuration Talecrypt et la configuration Easlin. Et enfin, en dernière ligne, nous allons lancer notre projet. Pour ce faire à la racine de notre projet nous allons créer un nouveau fichier qu'on va appeler start point f h et nous allons copier ces commandes là nous allons donc faire un cd dans le backend et lancer la commande NPM run start comme ceci. Comme on n'utilise pas encore Prisma, on a besoin de commenter cette ligne, sinon ça va déclencher un message d'erreur.

08:53 Maintenant qu'on a créé ce fichier, on peut le définir comme untree point de notre application. Le point d'entrée, ce sera le fichier start point s h. Mais nous avons quand même besoin de le copier depuis Builder. Donc là, en fait, on est dans Builder et on voit qu'on copie tous les fichiers de notre application. Donc tout ça, y compris notre fichier start point s h.

09:13 Mais ici dans notre dernière image, on copie fichier par fichier chaque fichier qu'on a besoin d'utiliser. Donc ce qu'on va faire, c'est qu'on va copier une dernière ligne comme ceci. Les permissions ne vont pas changer. Par contre le from, on va faire un from depuis pas l'installeur, mais depuis la base builder et la base dans laquelle on a tout copié. Donc on va mettre from builder et nous allons copier le app start point f h et on va le rajouter dans point slash app point start point sh comme ceci maintenant on va se rendre sur Google sur les pick stack parce que dans le dossier other on peut voir qu'on a aussi le docker ignore et on ne le connaît pas par coeur donc on va copier son contenu comme ceci et on va le rajouter ici dans le docker ignore.

09:55 Mais ce fichier docker ignore fonctionne seulement pour la configuration front end. Donc ce qu'on va faire c'est qu'on va le rajouter mais seulement pour le front end. Maintenant ce qui nous intéresse c'est aussi de rajouter une configuration docker ignore pour le back end. Donc on va taper sur Google docker net. Js comme ceci et on peut voir qu'on a un article de blog dont je me suis beaucoup inspiré qui s'appelle tomray point dev et si on fait une recherche sur docker ignore on peut voir qu'il existe bien une configuration docker ignore qu'on va utiliser.

10:23 Donc, on se rend dans le backend et nous allons créer un fichier qu'on va appeler point docker ignore comme ceci et nous allons copier son contenu. Maintenant que c'est fait, on va faire un build de notre application Docker. Pour utiliser Docker, vous avez besoin de télécharger le client. Donc sur Google, vous devez taper Download Docker et aller sur le premier lien comme ceci personnellement j'utilise un Mac avec l'Apple Sheep donc j'ai téléchargé ce fichier là et ça va installer client là. On va donc ouvrir le client docker qui ressemble à ça.

10:53 On a donc des conteneurs, des images, des volumes et des builds. Et ce qu'on va commencer par faire, c'est build l'image docker. Donc maintenant que c'est ouvert, on peut commencer à lancer la commande docker. On va lancer la commande docker build comme ceci en ajoutant tirette virgile ou le nom de votre application slash mono repos et ensuite on doit définir le point d'entrée et le point d'entrée c'est point pour utiliser tous les fichiers de notre projet. On peut donc maintenant lancer cette commande et elle va s'exécuter étape par étape et on peut voir qu'on a déjà une erreur qui a été exécutée.

11:27 Effectivement, c'est le untree point start s h n'a pas fonctionné. Alors on vient de créer un script de terminale et souvent, il faut utiliser la commande shmod plus x pour nous attribuer les permissions d'exécuter ce script. On va voir si le problème vient de là. On va maintenant relancer la commande docker build tiret t, comme ceci, et on peut voir qu'on a une autre erreur. Et en fait l'erreur, elle vient de notre dernière ligne qu'on a très mal copié.

11:52 En fait, ici regardez, je fais un from build sauf que la base qu'on a créée ne s'appelait pas build, elle s'appelait builder comme ceci. Donc en fait, tout simplement fait une faute d'inattention. Donc maintenant, je rectifie mon erreur, on va faire un clear de notre terminal et nous allons lancer la commande docker build, ce qui va commencer par télécharger cette image docker, puis ça va exécuter chaque étape une par une. On peut voir qu'on est déjà à l'étape dix-sept, donc ça avance très très vite et on peut voir qu'on a une erreur au niveau du build ici. On a donc lancé la commande NPM run build comme ceci, mais il n'a pas trouvé la librairie turbo et c'est compréhensible.

12:28 En effet, si on se rend dans le package point json, ici, on peut voir qu'on a téléchargé aucune librairie. En fait, on utilise la version turbo qui est globale sur notre ordinateur. Mais dans l'image docker, on n'a pas téléchargé turbo. On va donc faire un NPM install tiret d de la librairie turbo pour la télécharger à la racine de notre application et on peut voir qu'elle a été rajoutée en tant que dev dependency ici. Maintenant que c'est fait, nous allons réexécuter la commande docker build et comme ça a mis toutes les étapes précédentes en cache, ça sera beaucoup plus rapide de retourner à cette étape.

13:02 On est maintenant à l'étape du mpm run build et on voit qu'elle fonctionne très très bien. Ça a fait un rimraf de dist et c'est en train de build notre application. Et maintenant, on a terminé sans erreur supplémentaire. C'est une excellente nouvelle. Maintenant qu'on a configuré notre docker file, nous allons l'utiliser dans le fichier docker tiret compose.

13:21 Pour ce faire, je vais copier cette configuration ici et ce que ça fait, c'est que ça déclare un service qui s'appelle monoripo dev qui prend en argument une variable d'environnement qui s'appelle node underscore in v et ça va nommer l'image net g s premix mono repos. Et ce que ce docker compose fait, c'est que ça va exécuter la commande build en utilisant comme contexte le point et en utilisant comme docker file notre docker fail. Ça vous rappelle peut-être quelque chose C'est exactement ce qu'on a fait dans le terminal ici avec un docker build. On rajoute donc un tag virgin Mollyo et on rajoute ensuite le contexte dans notre cas le point et après avoir build l'image docker, ça va l'exécuter. Donc ça va partir du point d'entrée ici qui est le start point s h et ça va exécuter notre back end net.

14:06 Js. Ça va l'exécuter sur le port trois mille et ça va la restart en cas d'erreur. Ensuite, nous définissons l'image ici, mais on n'en a pas besoin pour ce fichier-là parce qu'on souhaite build cette image en environnement de développement. Par contre, nous allons maintenant dupliquer ce fichier docker compose point dev et nous allons le renommer en point prod comme ceci. Et pour le docker compose point prod, on peut déjà renommer chacun de nos champs ici pour les différencier, mais en production, on ne va pas build l'image directement, on va la télécharger depuis le repository docker hub de cette manière.

14:40 On va donc télécharger l'image NSGS tiret remix tiret mono repos sur le tag prod comme ceci et nous allons l'exécuter sur le port trois mille. Mais avant de le faire, on va se connecter à notre compte docker hub. Donc on va taper sur Google docker hub comme ceci et nous allons nous connecter. Une fois connecté, nous allons créer un nouveau repository que nous allons appeler NSGS tiret remix tiret monoripo comme ceci et nous allons copier la description de notre GitHub, c'est-à-dire remix app withness js adapteur. Cette image sera donc publique, on va maintenant la créer comme ceci et nous allons à chaque mise en prod push sur cette image.

15:19 Maintenant, nous avons envie que à chaque fois qu'on va mettre à jour notre application, ça effectue automatiquement un build notre image docker et ça la mette en prod. Pour ce faire, nous allons devoir utiliser les GitHub actions. Les GitHub actions, c'est un feature de GitHub qui nous permet de mettre en production automatiquement et de faire des tests automatiquement sur les serveurs de GitHub à chaque nouveau push. Donc, on se rend à la racine de notre projet ici et nous allons créer un nouveau fichier que nous allons appeler point github slash workflows slash ci point YML comme ceci et donc ça crée un dossier point github qui va contenir un dossier workflow qui va contenir un fichier qui s'appelle c I point yamal et c'est à l'intérieur de ce fichier c I point yamal qu'on va configurer chacune de nos actions GitHub. Donc je vais copier cette configuration-là et on peut voir que cette action s'appelle deploy et cette action possède des jobs.

16:16 Et chacun de ces jobs, c'est une étape de validation que l'action va effectuer en parallèle. Par exemple, nous allons commencer par faire un Lint. Donc on va utiliser Eas Lint pour s'assurer qu'il n'y ait aucune erreur e s lint avant chaque mise en prod. Pour ce faire, on va utiliser le cache de turbo repos, ce qui nous permet de ne pas répéter les opérations qui ont déjà été calculées. Ensuite, après avoir défini ces variables d'environnement, on va faire un check-out, donc on va télécharger le code source de notre application avec une profondeur de deux parce qu'on est dans un molorito, c'est-à-dire que ça va regarder chacun de nos dossiers.

16:51 Et ensuite, on va setup l'environnement de notre JS avec la version 20. On va ensuite installer les dépendances, on va build l'application nous allons lancer la commande MPM run lint. Pour la deuxième action qui s'appelle check check, c'est exactement pareil. On va définir les mêmes variables d'environnement, le check-out, on va set upnode, on va installer, on va faire un run build, tout est pareil sauf que nous allons ensuite lancer la commande NPM run tape check. Il faut savoir que ces deux commandes vont s'exécuter en parallèle et également en parallèle de ces deux commandes, nous allons faire un build de notre image docker et nous déclarons l'étape du build dans un autre fichier que nous appelons build point gamel.

17:32 Et ensuite, une fois que ces trois étapes ont réussi, nous allons déclencher la dernière action qui s'appelle deploy, qui a donc besoin que les trois étapes aient réussi et cette fois, nous allons la run pas sur les serveurs de GitHub mais en self hosted donc nous allons la run sur un VPS que nous allons configurer et c'est un petit peu le même esprit. On va donc définir les mêmes variables d'environnement puis on va récupérer le code source de notre application et enfin on va se connecter à docker hub comme ceci. On se connecte à docker hub pour télécharger l'image que nous venons de build. Donc varkoff slash nes g s tiret remix tiret monorito sur le tag les tests et sur le tag de production mais à l'heure actuelle nous n'avons pas encore mis en place un environnement de staging donc comme nous ne l'avons pas encore mis en place on peut commenter cette étape comme ceci et nous pouvons dupliquer cette ligne là qui indique qu'on exécute cette action seulement en prod et en staging et on la commente pour dire qu'on exécute cette action seulement en prod comme ceci. En production, ça signifie qu'on exécute sur la branche main.

18:40 Maintenant que c'est fait, il nous manque un dernier fichier à configurer, c'est le build point yml. Donc, on va le créer tout de suite dans le workflow. Ici, nous allons créer un nouveau fichier que nous allons appeler build point yml et il va contenir une configuration similaire. On déclare donc une nouvelle action qu'on appelle build and push docker image et on peut voir qu'on va faire un build de notre application en environnement s'il y a des poches sur la branche main et sur la branche dev. Mais pour le moment, on n'a qu'un seul environnement et c'est l'environnement de production.

19:12 Ce qu'on va faire, c'est qu'on va commenter cette ligne et nous allons la dupliquer et nous allons dire qu'on ne fait un build seulement sur la branche main comme ceci et ensuite au niveau des étapes, ici nous avons exactement la même logique si nous sommes sur la branche main on va exécuter ce code là sinon on va exécuter ce code là donc nous allons commenter cette deuxième étape parce que pour le moment on n'a pas encore d'environnement de staging et enfin nous allons push une nouvelle image sur docker hub avec le tag varkoff slash nefs j s tiret remix tiret monoripo et le tag sera production. Attention à ne pas faire d'erreur ici. Dans le copier coller, je conserve le tag production et dans le fichier f I point m l, le tag s'appelait ici prod. Donc ce que je vais faire, c'est que je vais tout simplement utiliser le tag prod à la place et dans le fichier docker compose point prod point m l, nous allons également utiliser le tag prod ici. Maintenant si on fait un contrôle f, on peut voir qu'on utilise le tag prod dans le build, la c I et le docker compose.

20:16 Et si on met prod comme ceci, on retrouve aucune déclaration. On a donc évité une nouvelle erreur. Avant de mettre tout ça en ligne, on va quand même s'assurer que notre image docker fonctionne. Pour ce faire, nous allons lancer la commande docker compose tiret f et nous allons exécuter ce fichier là, donc docker compose point dev. Je vais copier le nom de ce fichier et le coller dans le terminal comme ceci pour dire à docker qu'on va utiliser le fichier docker compose dev.

20:44 Et enfin, nous allons rajouter le mot clé up tiret build pour qu'il puisse re build l'image docker s'il en a besoin on lance donc cette commande de terminale et on peut voir que ça va refaire un build de notre image Docker et on peut voir qu'on a eu une erreur au niveau de l'exécution. Il n'a pas trouvé le fichier start point s h. Et ça, il fallait s'y attendre. Si on se rend dans le dossier out qui avait été généré par Turboripo qu'on va dans le dossier full ici, on peut voir qu'on ne possède pas le script start point s h ici. Ça veut dire qu'il n'a pas été ajouté dans notre dockerfile.

21:19 Nous allons donc faire une tentative. On va d'abord commenter ces deux lignes et on va déplacer le script start point s h dans le dossier backend comme ceci et ensuite nous allons réexécuter la commande turbo prune arobase virgile slash backend tiret tiret docker comme ceci maintenant si on se rend dans le fichier backend ici on peut voir qu'il y a bien un fichier start point s h ce qui veut dire que le fichier a bien été copié donc on va à la place définir l'untripoing comme backend slash start point s h. Ce qui veut dire que ça va aller regarder dans le dossier backend et ça va exécuter le fichier start point s h à l'intérieur du work dear donc de notre dossier app. Maintenant relançons le docker compose et vérifions que ça fonctionne bien. On peut voir qu'on a toujours la même erreur.

22:07 Il ne trouve pas le fichier back end slash start point s h. Et le problème venait en fait de notre dernière commande ici. À la ligne soixante-trois, si on effectue une dernière copie de notre fichier depuis Builder et que nous copions notre script backend slash start point f h, en rajoutant cette ligne, on fixe notre bug. Maintenant, on peut lancer la commande de core compost tiret f de notre fichier et on peut voir que ça a bien exécuté notre backend. Ça fait donc un cd backend, puis un NPM roll start et enfin un node du fichier main point j s.

22:43 Et on peut tout de suite tester d'accéder au localast trois mille comme ceci et on peut voir que notre projet est bien en cours d'exécution. Maintenant que c'est fait, on peut pousser ce code en production afin de vérifier que notre c I est bien configuré. On va donc faire un add point et un git commit tiret m et on va mettre comme message add docker. Et enfin nous allons faire un git push origin main comme ceci. Ce que ça va faire c'est que ça va mettre à jour notre repository ici.

23:11 Si on retourne maintenant sur notre repository et qu'on clique dans action, on peut voir que notre intégration continue est en train de tourner. Et si on clique sur l'action qui est en cours ici GitHub a bien détecté notre fichier c I point yamal et il est en train d'exécuter e s lint, tape script et le build de notre image docker. Et l'action vient tout juste de terminer le build avec succès. On va donc retourner sur docker hub ici et nous allons cliquer sur notre repository nefs j s tiret remix tiret mono repos et on peut voir que le tag production a été mis à jour il y a une minute et il a également été il y a une minute. Sauf que nous rencontrons un petit problème au niveau de l'action de déploiement ici.

23:51 Si on clique dessus, on peut voir qu'il nous indique waiting for a runner to pick up this job. Ce qui signifie que GitHub attend d'avoir un signal pour déployer notre application. Effectivement, on ne l'a pas encore fait, mais on va devoir paramétrer le runner GitHub et ajouter la configuration à notre serveur VPS. Pour ce faire, je vais utiliser l'hébergeur Hostinger parce que je dispose déjà d'un VPS sur lequel j'ai envie de mettre ce projet. Je me connecte à mon compte et là je vois que je possède un VPS ici donc je vais cliquer dessus, je vais cliquer sur gérer et je vais copier cette adresse IP.

24:23 Maintenant, je vais ouvrir un terminal et je vais lancer la commande SSH root arobase et l'adresse IP de ce serveur VPS. En appuyant sur entrée, on peut voir qu'il m'a connecté à ce serveur VPS. Et c'est directement sur ce serveur que nous allons paramétrer notre action GitHub. Si vous voulez savoir comment héberger votre application JavaScript en production, j'ai fait une vidéo sur le sujet que je vous conseille de consulter. Pour paramétrer notre repository GitHub, on se rend donc sur GitHub ici et on va cliquer sur les options, donc settings de notre repository ici.

24:55 Et ensuite, nous allons cliquer sur action et sur runners. Et maintenant, nous allons ajouter un nouveau self-oasted runner en cliquant sur ce bouton et nous allons sélectionner notre système d'exploitation du serveur. Personnellement, c'est un Linux et on utilise l'architecture x soixante-quatre comme ceci. Donc, nous allons suivre la documentation commande par commande. On va d'abord copier cette première commande ici, sauf qu'on va renommer le fichier et nous allons l'appeler deployement comme ceci deployement.

25:24 Maintenant, à l'intérieur de notre dossier deployment, nous allons installer avec curl le dernier package qui va nous permettre d'installer notre runner. On copie donc cette commande avec curl, comme ceci, et une fois téléchargé, on peut passer à la commande suivante. Maintenant, on va faire un écho, qui est une validation voilà et maintenant nous allons exécuter le script de configuration. On colle donc cette commande là sauf qu'il nous donne un avertissement. Ils disent qu'on ne doit pas exécuter cette commande en tant que SIDO.

26:01 Et si je tape la commande comme ceci, on peut voir que je suis connecté en tant que root. Je n'ai jamais rencontré cette erreur jusqu'à présent, mais je crois qu'on va devoir créer un nouvel utilisateur tout de suite. Pour ce faire, je vais suivre cette documentation qui s'appelle users in linux et nous allons d'abord copier cette première commande qui s'appelle sudo user ad et nous allons appeler cet utilisateur Virgile comme ceci. Maintenant on va vérifier que l'utilisateur existe avec un sudo ID et le nom de notre utilisateur. Dans ce cas-là Virgile et on peut voir qu'il existe bien.

26:35 Maintenant, nous allons configurer son mot de passe. Donc, on va lancer la commande sudo pass w d et le nom de notre utilisateur. Dans ce cas-là, on appuie sur entrée comme ceci et nous allons définir un mot de passe. On va donc se connecter avec l'utilisateur que nous venons de créer et pour ce faire, nous allons entrer la commande s u tiret et le nom de l'utilisateur, donc dans mon cas Virgile et maintenant on peut voir qu'on est bien connecté en tant que cet utilisateur. Si je lance la commande who amai comme ceci, on peut voir que je suis connecté en tant que vergile.

27:06 Maintenant on n'a plus accès au dossier que nous venons de créer. Si on fait par exemple un l s, on peut voir qu'il n'y a rien dans ce dossier là. Donc ce qu'on va faire c'est que nous allons taper la commande exit comme ceci et nous allons faire un PWD pour voir où on se trouve et on se trouve dans le dossier slash route. Et si on fait un l s, on peut voir notre dossier qui s'appelle deployment. Maintenant, ce qu'on a envie de faire, c'est de déplacer ce dossier deployment et nous allons le déplacer en utilisant la commande m v et le nom de ce dossier, donc m v de deployment et nous allons le déplacer dans le dossier home slash vergile comme ceci.

27:40 Maintenant on appuie sur entrée et si on relance la commande ls on peut voir que le dossier a disparu. Maintenant, on peut de nouveau relancer la commande s u tiret vergile comme ceci et si on fait un l s tiret l a, on peut voir qu'on a plein de fichiers cachés y compris notre dossier deployment. Maintenant on se rend compte que le propriétaire du dossier n'est pas Virgile. J'ai fait une petite recherche sur Google ici et j'ai tapé Grand permission of folder to user in Linux et j'ai ensuite cliqué sur le premier lien, ce qui nous donne accès à cette commande-là qu'on va pouvoir tester. Une autre commande qu'on peut essayer, c'est le sudo shawn tiret r comme ceci et le nom de l'utilisateur qu'on aimerait utiliser.

28:20 Dans notre cas, ça sera Virgile. Donc je copie cette commande-là et je vais l'assigner à l'utilisateur Virgile et je vais mettre double point Virgile qui est égal aux deux permissions que nous retrouvons ici et nous allons maintenant définir comme nom de dossier deployment comme ceci. On appuie maintenant sur entrée et on va relancer la commande précédente, elle aspirait là et on peut voir que les permissions ont maintenant changé. C'est génial, on peut maintenant céder dans le dossier deployment comme c'est fait, on va refaire un l s et on va exécuter notre config. Donc, on retourne sur GitHub dans notre onglet et on peut copier cette commande config comme ceci.

28:55 On va faire un point config et maintenant, on n'a plus l'erreur de sudo. On peut donc accepter les choix par défaut en appuyant sur entrée trois fois et une dernière fois pour valider les options. Et maintenant, on va arrêter de suivre la documentation parce qu'il nous conseille d'utiliser la commande run point s h. Mais nous, nous sommes plus malins. Nous allons exécuter le fichier FVC.

29:16 Donc, nous allons faire un FVC comme ceci en ajoutant le mot clé install comme ceci et on peut voir qu'on a une autre indication. Cette commande-ci par contre elle doit être exécutée en tant qu'admin donc on ne va pas oublier de rajouter le sudo de SVC point s h install comme ceci et on peut voir que ça a bien installé le runner et à partir de maintenant, on va lancer une commande similaire, on va faire un sudo SVC point s h en exécutant la commande start comme ceci et on peut voir maintenant que notre service est actif. Si on retourne sur GitHub dans les runners, on va cliquer sur runners et on va actualiser la page, on retrouve maintenant notre serveur avec le statut actif. Et si on retourne même dans nos actions de repository, ici, on peut voir que la c I vient de se lancer et elle vient d'échouer en live ici. Pour la raison suivante, il n'a pas retrouvé l'exécutable docker.

30:02 Et ça, c'est vraiment drôle, ça signifie qu'on n'a pas installé docker sur notre VPS. On va donc le faire tout de suite. On va taper sur Google Docker install Linux comme ceci et nous allons cliquer sur le premier lien ici et nous allons ici à install using de APT directory, nous allons ensuite copier toutes ces commandes. On les copie et on peut les coller dans le terminal comme ceci et On va maintenant appuyer sur entrée. Ça va donc tout télécharger.

30:26 Maintenant, nous allons taper cette commande pour ajouter le repository comme source pour l'installation, comme ceci. Maintenant, nous allons taper cette grosse commande pour terminer l'installation. On appuie maintenant sur Entrée qui va télécharger l'équivalent de quatre-cents mégaoctets de données. Mais ne vous inquiétez pas, ce n'est pas sur votre connexion, c'est le serveur qui va se charger de télécharger tout ça. Et là, on a presque terminé l'installation.

30:47 On va appuyer sur Tab, puis sur Entrée pour sélectionner les paramètres. Et maintenant, on devrait avoir Docker. Si on lance la commande Docker run Hello World, comme ceci, on va lancer Docker run Hello World, on peut voir qu'on n'a pas les permissions de Docker. Donc on va devoir faire une deuxième recherche Google, Docker add permission to user. Et nous allons cliquer sur le premier lien ici et nous allons suivre cette documentation.

31:10 Nous allons d'abord créer le groupe Docker, mais il a déjà été créé. Ensuite, nous allons exécuter la deuxième commande pour ajouter notre utilisateur dans le groupe Docker, comme ceci. Et maintenant, on devrait être autorisé à utiliser Docker. Si on exécute la commande Docker run et le world, ça ne va pas fonctionner, on n'a toujours pas les permissions. Cependant, si on fait un exit comme ceci pour se déconnecter du serveur, on va faire un PWD et on va voir qu'on est retourné en tant qu'administrateur et maintenant si on relance la commande s u tiret vergile, donc qu'on relance notre terminal, si maintenant on relance la commande docker run Hello World, on peut voir que ça nous a donné les droits.

31:46 En fait, on devait juste rafraîchir notre configuration de terminale. Maintenant que c'est fait, on a installé docker, donc on va retourner sur GitHub ici et nous allons réexécuter l'action qui a échoué. On peut donc cliquer ici sur ce logo et nous allons rear-un le job. On peut voir que l'action est en train de s'exécuter. On va donc regarder ce qui se passe pour s'assurer que tout fonctionne bien.

32:06 On fait d'abord le check-out pour récupérer les informations du repository, puis nous nous connectons avec Docker hub et là on peut voir qu'on a un problème de permission en production. C'est-à-dire que l'utilisateur de GitHub n'a pas réussi à exécuter la commande Docker. Le souci, c'est que le runner utilise l'utilisateur avec lequel on a téléchargé GitHub. Et dans notre cas, il est censé utiliser notre utilisateur Virgile. Donc, il devrait avoir les permissions d'exécuter notre code.

32:34 Si on veut en avoir le coeur net, on peut faire un l s tiret l et on peut voir qu'on a un dossier qui s'appelle deployments. Donc, nous allons faire un cd dans deployments. On va refaire un LSTL et cette fois, nous allons naviguer dans le dossier qui s'appelle underscore work comme ceci. On navigue dans underscore work et on peut refaire un l s comme ceci et on peut voir qu'on a un dossier prend le nom de notre repository GitHub. Donc, nous allons faire un CD à l'intérieur.

32:59 Et puis, nous allons refaire un LS pour voir qu'il y a un deuxième dossier qui prend le nom de notre repos GitHub, mais cette fois, il va contenir toute la logique de notre projet. On fait donc le cd et on refait un l s maintenant et on peut voir qu'on a tout le code source de notre application. Ce qu'on va faire maintenant, c'est qu'on va retourner sur vscode ici et nous allons ouvrir le fichier c I comme ceci et nous allons regarder notre action de déploiement et nous allons exécuter dans l'ordre ces trois instructions. On va donc d'abord faire un pool de l'image, nefs GSMX monory pot, comme ceci. Ce qui va télécharger l'image docker que nous avons.

33:33 Actuellement, ils ne m'ont pas demandé de me connecter parce que si on regarde bien sur Docker hub, on peut voir ici que l'image est publique. Ça veut dire que tout le monde, même vous pouvez la télécharger. Cependant, si elle avait été privée, on aurait eu besoin de nous connecter à notre compte Docker pour pouvoir la télécharger. Et c'est exactement ce qu'on fait dans notre action ici, avec les identifiants que nous avons configurés. Maintenant, nous allons copier la deuxième commande qui est le docker compose tiret f du fichier docker tiret compose point prod point yml.

34:02 On retourne donc côté serveur et si on refait un ls tiret l ici, on peut voir qu'on a bien le fichier docker tiret compose prod. Yaml. Donc ça devrait bien se passer. On colle donc la commande suivante comme ceci et nous allons retirer le tiret d comme ceci. On voit qu'on a une erreur du type le fichier n'existe pas et je pense que c'est une erreur d'inattention de notre part.

34:23 Effectivement, il y a deux formats de fichiers YAML. Il y a le point YAML et le point YAML. Donc, on va bien regarder dans VS Code. Ici, on peut voir qu'on exécute le fichier yaml yaml, mais nous avons nommé nos fichiers en Yml. Donc, on va devoir faire un fixe de ça.

34:43 On va renommer le bon fichier cette fois et nous allons ensuite dans le terminal faire git add point comme ceci et un git commit tiret m fix tapeo, puis nous allons push notre changement sur la branche main. On va cependant retourner dans notre terminal et corriger notre erreur pour voir si on arrive à exécuter cette image. On lance donc la commande comme ceci et on peut voir que l'image s'exécute très bien. Le projet s'exécute sans erreur, ça signifie qu'on n'a aucun problème à se faire à ce niveau-là. On peut donc arrêter l'exécution du projet en faisant un contrôle C et maintenant ce qu'on a envie de faire, c'est d'accéder à notre projet qui tourne via son nom de domaine.

35:18 Donc nous allons nous connecter à awf et nous allons accéder au service route cinquante-trois qui est le service sur lequel j'ai configuré mon nom de domaine. On va donc cliquer sur hosted zone comme ceci et nous voyons que nous avons un nom de domaine qui s'appelle varkoff. Point f r. Nous allons donc cliquer dessus et ici, on peut voir tous les sous domaines du projet varkov point f r. Ce qui nous intéresse ici, c'est de créer un sous domaine pour notre projet.

35:45 On va donc cliquer sur le bouton create record comme ceci et nous allons sélectionner le record type a et nous allons appeler notre sous domaine coût de pouce comme ceci. Et comme valeur, nous allons indiquer l'adresse IP de notre serveur. On va donc retourner dans le terminal et nous allons faire un exit comme ceci. On va faire un PWD. On peut voir qu'on est toujours connecté au serveur en tant qu'admin.

36:07 Donc, nous allons réexécuter la commande exit comme ceci et on peut voir qu'on a été déconnecté du serveur quatre-vingt-cinq trente-et-un deux-cent-trente-neuf soixante-dix-sept. Ça tombe à pic, c'est cette adresse IP que je voulais copier. Je la colle maintenant dans AWS et je clique sur create records comme ceci. Maintenant qu'on a créé ce sous domaine, nous allons le copier et nous allons retourner sur le serveur. Pour ce faire, nous allons nous reconnecter en tant que route ou en tant que Virgile, c'est exactement pareil et nous allons maintenant accéder au dossier slash kdi qui est la configuration de notre serveur kdi.

36:40 Maintenant nous allons faire un sudo nano du kdi file et c'est on va taper notre mot de passe et on peut voir qu'on a plein de projets qui ont été configurés et ce que nous voulons faire, c'est un reverse proxy sur le port trois mille. Donc nous allons taper le nom de domaine comme ceci et nous allons ajouter l'instruction reverse tiret proxy localhost trois mille comme ceci. Maintenant, on va faire un contrôle x et on va appuyer sur y pour enregistrer le fichier, puis nous allons lancer la commande sudo system CTL restart caddie comme ceci. On appuie sur entrée et ça devrait être bon. Pour être sûr, on peut faire un sudo système CTL status de caddie et on peut voir que le service est actif.

37:19 Maintenant, on peut faire un contrôle C et on va retourner sur GitHub pour voir si notre action a réussi. On clique sur nos actions et on peut voir que notre fixe n'a pas fonctionné. Effectivement, l'action de déploiement a encore échoué. Cette fois encore, c'est un problème de permission. Donc nous allons taper cette commande-ci sur Google comme ceci et nous allons cliquer sur la réponse stack overflow en espérant que ça soit la bonne solution.

37:41 On a donc un fixe qui nous conseille de donner les permissions de l'exécutable docker à l'utilisateur que nous venons de créer. On va donc copier cette commande et on va retourner dans notre terminal connecté en tant que l'utilisateur que nous avons créé. On va donc faire un l s tiret l du dossier var slash run et on n'oublie pas le slash qui indique que nous voulons exécuter le l s à l'intérieur du dossier run comme ceci et on peut voir que ça nous a quand même corrigé et que ça a retiré le slash à la fin du run. Donc on va relancer la commande, on va rajouter un espace comme ça et maintenant on peut voir vraiment tous les fichiers qui sont présents dans ce dossier. On a notamment le fichier docker point sock qui utilise les permissions de l'utilisateur root.

38:25 C'est de là que vient le problème. Donc, nous allons taper cette commande stack overflow comme ceci, mais nous allons d'abord exécuter la première commande, on ne sait jamais. Donc, on va faire un sud docker ps comme ceci. On peut voir qu'il n'y a aucune image qui est exécutée. Donc, nous allons lancer la deuxième commande, celle-ci, voilà.

38:42 Maintenant, nous allons réexécuter le l s tiret l comme ceci et on peut voir cette fois que le docker point sock possède maintenant comme permission l'utilisateur Virgile et le groupe docker. Donc, nous allons retourner sur GitHub et nous allons réexécuter notre action de déploiement en espérant que cette fois, ça va marcher. Et on peut voir que l'action a réussi. Effectivement, ça a pris seulement douze secondes parce que ça n'a pas eu besoin de poole la nouvelle image docker. On l'avait poole manuellement sur la machine et du coup, ça n'a pas eu besoin de la télécharger pour l'exécuter.

39:12 Maintenant, si on retourne sur le serveur qu'on exécute la commande docker ps comme ceci, on peut voir que nous avons un projet qui tourne, qui s'appelle donc varcov slash nets remix mono repos et avec le tag production. Ce projet est exécuté depuis une minute et il tourne sur le port trois mille. Maintenant, la question, c'est est-ce qu'on peut déjà accéder à ce projet On va tenter en tapant l'URL coup de pouce point varkoff point f r comme ceci. Et on peut voir que le projet tourne avec succès. Maintenant, je vais rafraîchir la page plusieurs fois comme ceci et si on retourne côté serveur, on va maintenant regarder les logs de notre application.

39:48 Pour ce faire, nous devons faire un docker log tiret f pour dire qu'on veut suivre le projet et enfin le nom du projet donc c'est mono repos tiret prod. On appuie sur entrée comme ceci et on peut voir qu'on a les log en live de notre application. Par contre si j'actualise comme ceci, voir que les log n'apparaissent pas dans le terminal, mais l'application a l'air de bien fonctionner. On peut donc se déconnecter du serveur avec la commande exit et fermer notre terminal. Et voilà, on a maintenant terminé la configuration de ce Molo Repos.

40:20 On peut maintenant passer au développement de notre projet et on va commencer par installer Tailwind, CSS et créer nos composants d'interface. À bientôt.