Comment configurer des pipelines d'intégration continue GitHub avec des runners auto-hébergés sur Ubuntu 22.04.

Introduction

Le génie logiciel est un domaine en évolution rapide et compétitif. Déployer vos produits plus rapidement auprès des utilisateurs vous donnera un avantage sur vos concurrents. Heureusement, les meilleures pratiques de l'industrie sont en place pour aider les entreprises à être sur un pied d'égalité.

L'intégration continue et le développement continu (CICD) est un exemple de stratégie qui s'appuie sur les meilleures pratiques de l'industrie pour donner aux entreprises un avantage dans ce domaine compétitif.

GitHub, un dépôt basé sur le web avec Git, un outil de contrôle de version, permet aux développeurs, ingénieurs et architectes logiciels de mettre en œuvre le CI/CD. Le développement continu (CD) est la pratique consistant à automatiser les builds, les tests et les déploiements. L'intégration continue (CI) permet à plusieurs personnes de collaborer sur le même projet et de vérifier que le code fonctionne sans se soucier des conflits de fusion.

Les GitHub Actions nous permettent d'écrire des étapes qui automatisent les builds, les tests et le déploiement.

Dans ce tutoriel, vous apprendrez à configurer l'intégration continue avec GitHub Actions. Nous commencerons par configurer un dépôt Git pour héberger notre code. Ensuite, nous configurerons un processus CI GitHub pour surveiller les modifications de notre code, lancer un runner CI pour exécuter les tests, compiler et déployer notre application sur un serveur Ubuntu 22.04 exécutant Nginx.

Prérequis

Pour suivre ce tutoriel, vous aurez besoin de ce qui suit :

• Un serveur exécutant Ubuntu 22.04. Vous pouvez suivre ce tutoriel pour la configuration initiale du serveur Ubuntu, ajouter un utilisateur non-root, et activer le pare-feu UFW d'Ubuntu.

• Vous aurez besoin de Node.js installé sur votre serveur, de préférence en version 14 ou supérieure. Nous avons un tutoriel sur comment installer Node.js on Ubuntu.

• Vous aurez besoin du logiciel serveur Nginx installé. Nous avons un guide sur Comment installer Nginx sur un serveur exécutant Ubuntu.

• Vous aurez besoin de Docker et de Docker Compose installés sur votre machine locale pour exécuter un environnement de développement isolé. Veuillez suivre notre tutoriel pour apprendre Comment installer et utiliser Docker dans le cloud.

Maintenant que nous avons tout ce dont nous avons besoin, commençons.

Étape 1. Clonage du dépôt du projet.

Nous allons baser ce tutoriel sur Reactjs, une bibliothèque Javascript déclarative pour créer des interfaces utilisateur. Si vous souhaitez configurer un nouveau projet à partir de zéro, vous pouvez utiliser cette ressource sur la configuration d'une application React. Pour des raisons de brièveté, nous utiliserons un clone de ce dépôt React.js que nous avons déjà configuré sur GitHub.

L’application que nous clonons est une simple application React avec react-router 6 et un test réalisé avec React Testing Library, qui nous donne des méthodes pour accéder au DOM.

Pour cloner le dépôt, cliquez sur le bouton vert et copiez l'URL.

Ouvrez le terminal dans votre espace de travail et exécutez la commande ci-dessous pour cloner l'application :

Une fois que vous avez cloné le dépôt, accédez au répertoire du projet :

Exécutez la commande docker-compose up pour compiler et lancer l'application :

Une fois le processus terminé, visitez http://localhost:3000

Vous devriez voir quelque chose de similaire à ceci :

Étape 2. Comprendre le fichier Node.js.yml.

Dans cette étape, nous définirons les directives du fichier YAML GitHub pour nous aider à comprendre ce qui se passe. Dans le dépôt, il y a un répertoire .github/workflows qui contient un node.js.yml fichier, qui contient les étapes de workflow que les runners GitHub suivent après que vous avez poussé des modifications dans votre dépôt de code sur GitHub. YAML syntax est utilisée pour écrire des workflows pour GitHub Actions. Les fichiers YAML se terminent par une extension yaml ou yml.

Ouvrez le node.js.yml fichier, il devrait ressembler à ceci :

Au moment de la rédaction de ce tutoriel, nous utilisions la version 16 de Node.js 16. Maintenant, comprenons le workflow GitHub Actions :

• name

name: cicd-tut

Le nom de votre workflow, ce nom sera affiché dans l’onglet Actions de votre dépôt.

• on

on est utilisé pour définir des événements. Les événements peuvent déclencher automatiquement un workflow ou être planifiés pour plus tard. Les événements peuvent être uniques ou multiples, vous pouvez également spécifier des exécutions de workflow pour des branches, des tags ou des fichiers spécifiques. Cela fonctionne comme un filtre.

Dans notre fichier YAML, nous définissons plusieurs événements automatiques, qui sont :

• Un événement push est déclenché lorsque du code est poussé vers un dépôt

• Un événement pull_request est déclenché lorsqu’une pull request est créée sur la branche principale.

Nous spécifions un nom de branche main afin de restreindre l’exécution du workflow à cette seule branche. Nous pouvons également spécifier des branches à ignorer en utilisant le drapeau ! suivi du nom de la branche.

• jobs

Un workflow est essentiellement composé d’un ou plusieurs jobs. Ces jobs s’exécutent successivement du premier au dernier.

Chaque job s’exécute dans un environnement de runner spécifié par runs-on. Vous pouvez choisir d’exécuter les jobs soit sur des runners GitHub désignés par ubuntu-latest soit sur un runner self-hosted désigné par self-hosted. Votre choix dépendra du nombre de jobs dont vous avez besoin. Avec les runners auto-hébergés, vous disposez de plus de flexibilité et de contrôle des ressources.

Dans notre prochaine étape, nous exécuterons d’abord nos jobs sur des runners GitHub, puis plus tard, nous configurerons un runner GitHub auto-hébergé sur notre propre serveur.

• strategy

La stratégie nous permet d’utiliser des variables dans une seule définition de job pour créer automatiquement plusieurs exécutions de job basées sur les combinaisons de variables.

Dans notre fichier YAML, nous avons une variable pour notre version de Node, mais si nous en ajoutons une autre pour la version 18 de Node, comme ceci : node-version: [16.x, 18.x], alors la stratégie de matrice créera 2 exécutions de job pour notre application React pour les versions 16 et 18 de Node.

• steps

Les étapes sont une séquence de tâches qui composent un job. Les étapes peuvent exécuter des commandes, configurer des tâches, exécuter des actions dans votre dépôt public ou des actions publiées dans un registre Docker.

Une étape a un nom. Bien qu’il soit facultatif, vous pouvez l’utiliser pour spécifier un moyen simple d’identifier le nom de votre étape qui s’affichera sur GitHub.

Dans une étape, vous pouvez sélectionner une action à exécuter dans votre travail, les actions sont réutilisables. Les versions de l’action sont spécifiées lors de la définition d’une action, ce qui est important car cela empêche votre workflow de se casser lorsque le propriétaire de l’action publie une mise à jour.

Dans l’extrait de code ci-dessus, checkout@v3 est un exemple d’action avec une version spécifiée 3. Cette action extrait votre dépôt afin que votre workflow puisse y accéder.

Certaines actions telles que actions/setup-node@v3 ci-dessus ont des entrées indiquées à l’aide du with mot-clé, les actions setup node nécessitent la version 16 de Node et la mise en cache de npm.

• run

Cette action exécute des programmes en ligne de commande à l’aide du shell du système d’exploitation.

Dans le fichier YAML ci-dessus, nous avons trois commandes, elles s’exécuteront toutes en utilisant le même shell dans l’environnement du runner.

• La première commande npm i installe toutes les dépendances requises par notre application React.

• La deuxième npm test, exécute le test que nous avons écrit. Le test s’attend à ce que le texte learn react soit affiché sur la page d’accueil.

• Enfin, npm run build crée un répertoire de build avec une version de production de notre application. Plus tard, nous utiliserons ce répertoire de build dans notre bloc de serveur Nginx.

Étape 3. Tester l’intégration continue (CI) GitHub avec les runners GitHub.

Dans cette étape, nous allons tester le processus d’intégration continue avec les runners GitHub. Commencez par ouvrir le fichier node.js.yml . Modifiez le type de runner sur lequel les actions s’exécuteront en ubuntu-latest. Le but est de tester si le workflow GitHub fonctionne parfaitement sur les runners GitHub avant de configurer nos propres runners auto-hébergés.

Créez un nouveau dépôt sur votre compte GitHub. Avant de continuer, retournez dans le répertoire de votre espace de travail et supprimez le répertoire .git , si vous ne le voyez pas, vérifiez vos fichiers cachés. Vous pouvez utiliser la commande suivante dans votre terminal pour supprimer le répertoire :

Maintenant, vous pouvez ajouter tous vos fichiers de projet avec git add, faire un commit et les pousser dans votre dépôt. Si vous êtes bloqué, utilisez ce guide pour connecter votre dossier de projet au dépôt GitHub que vous avez créé ci-dessus.

Lorsque vous avez terminé, cliquez sur l’onglet Code de votre dépôt, et vous verrez un petit point orange à côté du nombre total de commits. Lorsque vous cliquez dessus, vous verrez une fenêtre modale similaire à celle ci-dessous, indiquant que votre workflow a été mis en file d’attente :

Maintenant, cliquez sur le lien Détails de la modale ou allez sur l’onglet Actions , vous verrez chaque étape du workflow node.js.yml exécutée par les runners GitHub :

En cas de succès, cliquez sur l’onglet Actions , il devrait ressembler à ceci :

Et c’est tout, le petit point orange sur notre onglet Code devrait maintenant être une coche verte. Le runner GitHub a construit notre application avec succès.

Maintenant, allons plus loin et modifions l’environnement de build pour utiliser des runners auto-hébergés GitHub dans notre propre infrastructure de serveur Ubuntu.

Étape 4. Configuration du workflow GitHub pour utiliser un runner auto-hébergé.

Avant d’installer le runner auto-hébergé sur notre serveur, retournons dans notre espace de travail et modifions le fichier de workflow node.js.yml  pour qu’il s’exécute sur des runners auto-hébergés GitHub.

À ce stade, lorsque vous validerez les modifications, le travail sera mis en file d’attente car aucun runner auto-hébergé n’a été défini.

Sur votre dépôt, cliquez sur l’onglet Settings , dans la barre latérale gauche, cliquez sur Actions, puis cliquez sur Runners:

Cliquez sur New self-hosted runner, et sélectionnez Linux comme système d’exploitation.

Vous verrez des instructions vous montrant comment télécharger le runner et l’installer sur votre serveur.

Étape 5. Installation et configuration d’un runner auto-hébergé GitHub sur notre serveur.

Dans cette étape, nous allons configurer un runner GitHub auto-hébergé. Un runner auto-hébergé est un système qui peut déployer et gérer l'exécution de jobs à partir de GitHub Actions sur le site web de GitHub. L'un des avantages du runner auto-hébergé par rapport au runner hébergé par GitHub est sa flexibilité. Il offre plus de contrôle sur le système d'exploitation, le matériel et d'autres outils qui peuvent être personnalisés pour répondre aux besoins de votre application.

Les runners auto-hébergés peuvent être ajoutés à différents niveaux tels que :

• Les runners au niveau du dépôt, ceux-ci sont dédiés à un seul dépôt.

• Les runners au niveau de l'organisation, ceux-ci peuvent traiter des jobs pour plusieurs dépôts dans une organisation.

• Le niveau entreprise, qui peut être attribué à plusieurs organisations.

Pour continuer, connectez-vous à votre serveur via ssh :

Allez dans votre répertoire personnel avec la commande :

Ensuite, créez un répertoire appelé action-runners et accédez-y :

Ensuite, téléchargez la dernière version du package du runner :

Ensuite, extrayez le package téléchargé avec la commande :

De retour sur votre dépôt, dans l'onglet Settings, dans le panneau latéral gauche, cliquez sur Actions, puis sur Runners, tout comme nous l'avons fait à l' Étape 4.

Vous verrez une commande listée qui inclut un jeton reliant votre runner auto-hébergé à votre dépôt GitHub. Tout en restant dans le répertoire où vous avez extrait le code du runner GitHub, utilisez la commande listée pour lier votre runner, par exemple :

L'authentification devrait réussir :

Appuyez sur Entrée pour le groupe de runners par défaut.

Ensuite, saisissez un nom pour votre runner, par exemple, my-runner, puis appuyez sur Entrée.

Appuyez sur Entrée pour ignorer l'ajout d'étiquettes supplémentaires, vous devriez voir le message de réussite dans la capture d'écran ci-dessous :

Saisissez le nom de votre répertoire de travail, par exemple, react-cicd, cela devrait réussir avec le texte settings saved.

Enfin, exécutez ./run.sh, cela devrait afficher Connected to Github:

Mais cela ne s'exécute pas en arrière-plan, si nous tapons ctrl+c dans notre terminal, le runner sera arrêté, nous devons le remplacer par le service .svc.sh pour maintenir le runner actif en tant que service afin de pouvoir continuer à interagir avec lui.

Arrêtez le runner avec ctrl+c. Vous pouvez installer le service .svc.sh en exécutant la commande :

Une fois installé, démarrez le service avec la commande :

Cela devrait réussir, en affichant active (running).

Pour confirmer que le service svc.sh est opérationnel, exécutez la commande :

À ce stade, tout workflow qui aurait pu être mis en file d'attente en attendant un runner auto-hébergé devrait s'exécuter avec succès. Vous pouvez également modifier un fichier et tester. Par exemple, modifiez le fichier À propos.tsx, commitez et poussez les modifications, le runner auto-hébergé terminera le job avec succès.

Étape 6. Configuration du bloc de serveur Nginx

Dans cette étape, nous allons configurer un bloc de serveur dans Nginx pour afficher la version de build de notre application React. Nous avons un tutoriel sur la Configuration des blocs de serveur Nginx qui pourrait vous être utile.

Voici un exemple de bloc de serveur utilisé dans ce tutoriel :

Vous allez créer un fichier de configuration de bloc serveur Nginx dans le répertoire /etc/nginx/sites-available .

Ouvrez un fichier pour la configuration du bloc serveur de votre site avec l'éditeur nano en utilisant la commande :

Copiez le bloc serveur partagé ci-dessus, modifiez-le en fonction des chemins de vos répertoires, et collez-le dans le fichier ouvert. Lorsque vous avez terminé l'édition, appuyez sur ctrl+x puis appuyez sur y et Entrée pour enregistrer et quitter.

Une fois enregistré, créez un lien symbolique pour la configuration du bloc serveur react-cicd depuis /etc/nginx/sites-available vers /etc/nginx/sites-enabled en exécutant la commande :

Pour que les modifications prennent effet, vous devez redémarrer Nginx. Cependant, avant de pouvoir redémarrer le service Nginx, testez si les configurations Nginx sont valides en exécutant la commande :

Si la configuration est correcte, le test devrait réussir.

Remarquez la valeur de la directive server_name directive “ react.test ” dans le bloc serveur ? Vous ajouterez cette valeur dans votre fichier hosts sur votre machine locale. Cela vous permettra d'ouvrir l'application dans votre navigateur. Cette étape n'est nécessaire que pour les domaines virtuels utilisés dans les environnements de développement locaux. Si vous avez un nom de domaine enregistré lié à une IP publique de votre serveur, alors le nom de domaine devrait déjà être accessible dans votre navigateur.

Sur votre machine locale, ouvrez le fichier hosts avec la commande :

Dans le fichier hosts, ajoutez l'adresse IP de votre serveur, par exemple 127.0.0.1, suivie de votre nom de domaine virtuel.

Un exemple est présenté ci-dessous. Fermez ensuite le fichier et enregistrez :

De retour sur votre serveur, dans le répertoire /var/www , créez un nouveau répertoire, vous pouvez le nommer react-cicd en exécutant :

À ce stade, nous allons décommenter la dernière commande dans le fichier node.js.yml .

Cette commande copie le dossier de build de notre application React depuis l'emplacement où nous avons spécifié notre dossier de travail dans le répertoire actions-runner à l'étape précédente 5.

Et place le dossier public dans le répertoire /var/www/react-cicd .

Le bloc serveur peut maintenant accéder à notre application et l'afficher dans un navigateur.

Enfin, redémarrez le service Nginx avec la commande :

Maintenant, vous pouvez apporter une modification dans le fichier À propos.tsx , puis valider (commit) et pousser (push) vos modifications vers votre dépôt. Après un build réussi, vous verrez la version de build de votre application React à l'adresse http://react.test ou au nom de domaine que vous avez spécifié. Évitez de modifier l'élément href dans le fichier Home.tsx car cela pourrait faire échouer le test déjà écrit. L'onglet Actions de votre dépôt devrait également afficher le build du travail terminé.

Conclusion

L'intégration continue avec GitHub Actions présente de nombreux avantages, notamment une bonne expérience de développement, une aide aux tests continus, une collaboration plus facile au sein d'équipes plus importantes, un temps de développement raccourci, des sorties rapides de nouvelles fonctionnalités, des retours en temps réel et la satisfaction des clients, ce qui vous donne un avantage sur vos concurrents. Pour approfondir ces connaissances, vous pouvez également en apprendre davantage sur Configuration de pipelines d'intégration continue (CI) GitLab sur Ubuntu. et l'utilisation d'une instance GitLab auto-gérée pour héberger vos images Docker et exécuter des builds privés.

Bonne informatique !