Comment configurer Buildbot sur FreeBSD

Buildbot est un système de planification de travaux couramment utilisé aux fins de continuous integration (CI). CI est une pratique de développement logiciel qui consiste généralement à construire et à tester automatiquement votre logiciel régulièrement et à chaque changement. Bien qu’il soit couramment utilisé comme plate-forme CI, Buildbot peut également être utilisé pour toute tâche automatisée exécutée sur un ordinateur. La configuration d’exécution des tâches de Buildbot comprend quatre composants:

Buildbot fonctionne avec au moins un maître Buildbot qui exécute et vérifie toutes les configurations de construction et autres paramètres, et distribue les versions réelles à ses travailleurs. De plus, le maître offre un sous-composant d’interface utilisateur basé sur un navigateur qui, s’il est activé, est utilisé pour déclencher ou afficher les constructions et vérifier les rapports d’état et autres paramètres. Il existe également un ou plusieurs Buildbot workers qui se connectent au maître et reçoivent des commandes, notamment pour exécuter des générations.

Dans ce guide, vous utiliserez les jails FreeBSD pour installer et exécuter chaque composant Buildbot dans un environnement séparé et isolé. Buildbot utilisera ensuite le serveur Web Nginx et accédera à son interface Web à l’aide d’un navigateur Web sur votre ordinateur local. Après avoir terminé ce guide, vous aurez une configuration opérationnelle avec un exemple de construction de projet, prête à être étendue à votre propre CI ou à d’autres cas d’utilisation.

Avant de commencer ce guide, vous aurez besoin de:

Si vous souhaitez héberger l’interface Web Buildbot à l’aide du protocole HTTPS sécurisé, vous devez également disposer des éléments suivants:

Étant donné que Buildbot permet aux contributeurs externes d’exécuter du code sur votre système, il est recommandé d’isoler ses divers composants afin d’empêcher tout code arbitraire ou malveillant de prendre les ressources de votre serveur. Dans ce tutoriel, vous allez utiliser des jails FreeBSD.

Semblables à LXC, Docker et d’autres mécanismes de conteneur, les jails FreeBSD offrent une isolation légère du système hôte. Les processus exécutés dans une prison ne peuvent accéder qu’aux ressources auxquelles l’accès avait déjà été accordé à la prison; sinon, ils se comportent comme n’importe quel autre environnement FreeBSD. Les jails partagent le même noyau mais sont généralement exécutés sur un système de fichiers contenant une copie du système de base FreeBSD, qui peut être n’importe quelle version de FreeBSD compatible avec le noyau hôte. Pour la plupart des charges de travail, les différences de performances entre l’exécution d’une tâche sur l’hôte et dans une prison ne sont pas perceptibles.

Plusieurs progiciels externes existent pour aider à la création et à la gestion des jails FreeBSD. Etant donné qu’aucun d’eux n’est la norme de facto, nous utiliserons le mécanisme de configuration intégré du système d’exploitation, https://www.freebsd.org/cgi/man.cgi?query=jail.conf&sektion=5&n=1jj]].

Premièrement, nous voulons créer une interface réseau distincte pour les jails du système. Dans les jails, le noyau réécrit les connexions réseau sur la première adresse IPv4 / IPv6 attribuée au jail. Par exemple, si la première adresse IP attribuée est publique et qu’un service de la prison jalonne le message +127.0.0.1: 1234 +, le port + 1234 + sera accessible au public. La pratique https://www.freebsd.org/doc/handbook/jails-ezjail.html&recommended] consiste à disposer d’une interface réseau distincte pour les jails. Nous allons suivre cette recommandation de cloning l’interface de bouclage principale (+ lo0 +) dans une interface séparée (+ lo1 +). Nous utiliserons le réseau + 10.0.0.0 / 24 +, mais tout autre réseau ne se chevauchant pas fonctionnera également.

Commencez par configurer une interface clonée à créer au démarrage. Cette commande + sysrc + écrit une règle dans le fichier + / etc / rc.conf + mais ne crée pas l’interface elle-même:

Ensuite, créez l’interface réseau avec la commande suivante:

Vous pouvez vérifier l’état de l’interface et l’IP avec:

La sortie indique que l’interface existe, mais qu’aucune adresse IP n’est répertoriée et associée à celle-ci pour le moment. Son drapeau + LOOPBACK + signifie que cette interface est uniquement disponible localement et ne représente pas un périphérique matériel réel.

Ensuite, ouvrez un nouveau fichier de configuration pour le jail master en utilisant votre éditeur préféré. Ici, nous allons utiliser + ee +:

Ajoutez ensuite le contenu suivant au fichier, ce qui configurera un jail maître nommé + buildbot-master +:

/etc/jail.buildbot-master.conf

Ce code attribue un nom d’hôte et une adresse IP fixes sur l’interface réseau jail, + 10.0.0.2 +, et spécifie le système de fichiers racine, + / usr / jails / buildbot-master +. Les valeurs + exec.start + et + exec.stop + utilisées ici déclarent que les services + start + et + stop + de la jail se comporteront comme des processus de démarrage et utiliseraient les scripts de démarrage et d’arrêt contenus dans le + / etc / + `répertoire. L’option `+ persist + permet à la prison de continuer à fonctionner même si tous ses processus sont terminés.

Pour en savoir plus sur les paramètres possibles de la prison principale, consultez la page de manuel jail(8).

Après avoir ajouté ce contenu, enregistrez et quittez l’éditeur. Si vous utilisez + ee +, faites-le en pressant + CTRL + C +, en tapant + exit + et en appuyant sur + ENTER +.

Le fichier de configuration du maître jail est distinct du fichier de configuration global du jail, + / etc / jail.conf +. Pour cette raison, vous devrez ajouter le nom de la prison principale à la liste des prisons connues:

Puis activez les jails listés dans + jail_list + pour qu’ils démarrent automatiquement au démarrage:

Si vous avez déjà des jails sur votre système configurés avec le fichier global + / etc / jail.conf + mais que vous n’avez pas encore utilisé + jail_list +, l’activation de ce paramètre signifie que seules les jails de + jail_list + seront automatiquement activées. -start et vous voudrez peut-être ajouter vos jails existants à la liste.

Ensuite, nous allons créer le répertoire racine du jail master et extraire le système FreeBSD.

Assurez-vous que le répertoire du système de fichiers racine de la prison existe. Si vous avez exécuté les commandes ZFS dans la note précédente, cela a déjà été fait et vous pouvez ignorer cette commande:

Ensuite, téléchargez une archive système de base FreeBSD 11.2. Nous installons d’abord les certificats racine pour faire confiance au serveur de téléchargement:

Cette commande vous invitera à approuver l’installation du package + ca_root_nss +. Faites-le en pressant + y + puis + ENTER +.

Ensuite, téléchargez l’archive:

Extrayez le contenu de ce fichier en tant que système de fichiers racine de la prison:

Ce guide décrit le processus d’installation d’un seul ouvrier (également contenu dans une prison) et vous le configurerez de la même manière que vous avez utilisé le maître, en réutilisant le système de base que vous venez de télécharger. Ouvrez un autre nouveau fichier de configuration pour le poste de travail à l’aide de la commande + ee +:

Ajoutez le contenu suivant à ce fichier:

/etc/jail.buildbot-worker0.conf

En regardant ces lignes, notez comment la prison de travail a un répertoire de nom d’hôte, d’IP et de système de fichiers racine différent de celui du maître. Enregistrez et fermez ce fichier.

Encore une fois, comme nous utilisons un fichier de configuration jail distinct à la place du fichier + / etc / jail.conf + global, ajoutez le nom à la liste des jails connus:

Extrayez le système de base FreeBSD 11.2 déjà téléchargé comme vous l’avez fait pour le maître:

À ce stade, les deux jails sont configurés et contiennent un système de base FreeBSD sur lequel aucun paquet supplémentaire n’est installé. Commençons les prisons:

Vérifiez si le démarrage a réussi en répertoriant tous les jails en cours d’exécution sur le système à l’aide de la commande suivante:

Cela retournera une sortie semblable au suivant qui montre les jails en cours d’exécution sur votre serveur:

Cela confirme que les jails fonctionnent comme prévu. À ce stade, toutefois, ils n’ont pas accès à Internet, ce qui signifie que vous ne pourrez pas installer les packages Buildbot qu’ils contiennent. Continuez à lire pour résoudre ce problème.

Bien que les prisons maîtresse et ouvrière fonctionnent, les deux sont fermées d’Internet. Il est nécessaire de les ouvrir à Internet, car ils doivent pouvoir installer des packages et communiquer entre eux.

Pour résoudre ce problème, copiez la configuration du résolveur DNS de l’hôte dans les deux jails:

Ensuite, acheminez le trafic Internet sortant de la prison. Pour ce faire, utilisez IPFW - le pare-feu intégré de FreeBSD - pour configurer des règles de réseau NAT (traduction d’adresses réseau). Une fois cette étape terminée, le trafic sortant du réseau de jail sera traduit en adresse IP publique de votre hôte.

Si vous avez suivi le tutoriel Let Encrypt, le pare-feu sera déjà configuré pour permettre l’accès à votre serveur Web. Dans ce cas, certaines des étapes ci-dessous seront redondantes, mais il n’ya aucun mal à les exécuter à nouveau.

Incluez les règles de pare-feu + workstation + prédéfinies dans votre fichier + rc.conf + avec la commande suivante. Les règles + workstation + protègent le serveur, mais autorisent toujours les services de base, tels que l’envoi d’une requête ping à l’hôte ou le protocole de configuration d’hôte dynamique:

Ensuite, autorisez l’accès aux ports du serveur Web du monde extérieur. La commande suivante autorise le trafic sur le port + 22 +, pour SSH; le port + 80 +, permettant à Buildbot d’être servi sur HTTP; et le port + 443 +, permettant à Buildbot d’être servi sur HTTPS. Si vous avez sécurisé votre serveur avec Let’s Encrypt, ces trois ports sont nécessaires, mais si vous ne l’avez pas planifié, vous pouvez exclure le port + 443 +:

Autorisez l’accès depuis n’importe quelle adresse IP aux ports spécifiés dans la directive + firewall_myservices +:

Configurez le pare-feu pour qu’il démarre au démarrage:

Ensuite, démarrez le pare-feu avec les règles de base. La commande + nohup + suivante évite l’interruption du démarrage du pare-feu et redirige également ` stderr + `et + + stdout + `vers un fichier journal temporaire. Ceci est important pour ne pas laisser les règles de pare-feu dans un état incohérent, ce qui pourrait rendre votre hôte distant inaccessible via SSH:

Si vous utilisez les shells + csh + ou + tcsh +, cette redirection entraînera une redirection de sortie + ambiguë. + Dans votre sortie. Si vous utilisez l’un de ces shells, lancez + sudo nohup service ipfw start> & / tmp / ipfw.log + à la place de démarrer + ipfw +:

À ce stade, le service de pare-feu démarrera et protégera l’hôte des connexions aux ports non sécurisés.

Ensuite, vous devez déterminer l’interface réseau de l’hôte qui se connecte à Internet. Trouvez ceci en exécutant:

Cette commande peut générer plusieurs interfaces différentes. Celui utilisé par l’hôte pour se connecter à Internet est celui qui inclut l’adresse IP publique de votre serveur. Pour illustrer notre propos, l’exemple de sortie suivant montre que + vtnet0 + est l’interface réseau utilisée par l’hôte:

Prenez note de cette interface, puis configurez son nom globalement:

Ouvrez le nouveau fichier de script de configuration du pare-feu:

Ajoutez ensuite le contenu suivant au fichier, définissant les règles de pare-feu pour IPFW:

/usr/local/etc/ipfw.rules

Voici ce que chaque partie du script fait:

Enregistrez le fichier et quittez l’éditeur.

Puisque nous voulons modifier les règles de base du pare-feu prédéfinies avec les règles définies dans le script + ipfw.rules +, nous devons pointer ce script dans le fichier + rc.conf +. La commande suivante va configurer le script pour qu’il s’exécute à chaque démarrage du pare-feu:

Cette configuration utilise la prise en charge NAT dans le noyau d’IPFW. Vous devez donc dire au système de charger le module de noyau correspondant au démarrage. De plus, chargez le module immédiatement sans nécessiter de redémarrage:

Redémarrez le pare-feu pour appliquer le script de règles de pare-feu étendues:

Encore une fois, si vous utilisez le shell + csh + ou un de ses dérivés (comme + tcsh +), exécutez + sudo nohup service ipfw restart> & / tmp / ipfw.lo + au lieu de la commande précédente pour redémarrer le pare-feu:

Vérifiez que les règles du pare-feu ont été chargées correctement:

Cette liste répertorie les règles du pare-feu, suivies d’un message de réussite:

Vous pouvez également afficher à tout moment les règles de pare-feu installées à l’aide de:

Avec toutes les règles de pare-feu en place, vos prisons peuvent désormais accéder à Internet. Vous pouvez vérifier en essayant de télécharger une page Web depuis une prison:

Avec cela, vous avez préparé avec succès les deux prisons à fonctionner comme un système d’exploitation normal, configuré un accès Internet pour chaque prisonnier et démarré les deux. Les deux étapes suivantes de ce didacticiel vous guideront à travers l’installation des composants maître et travailleur, puis leur exécution en tant que services.

Les composants de Buildbot sont divisés en plusieurs packages. Vous devez uniquement installer le package + py36-buildbot + pour exécuter le composant principal. Dans ce guide, nous expliquerons également comment installer le package d’interface Web + py36-buildbot-www +.

Puisque nous utilisons des jails pour segmenter les différents composants, commencez par ouvrir un shell * root * dans le master jail:

Veuillez noter que, dans ce guide, les blocs de commandes du shell sont marqués d’une couleur différente s’ils doivent être exécutés dans un shell jail. En outre, l’invite de commande indiquera le profil utilisateur de la jail (utilisateur * root * ou non privilégié * buildbot-master *) - sous lequel les commandes doivent être exécutées.

Installez les paquets:

Si vous n’avez pas encore installé ou utilisé le gestionnaire de paquets + pkg + dans cette prison, il vous demandera de confirmer que vous lui permettez de s’amorcer lui-même. Pour ce faire, appuyez sur + y + puis + ENTER +. Ensuite, approuvez l’installation des paquets Buildbot en entrant à nouveau «+ y +».

Ensuite, créez un utilisateur régulier et non privilégié pour exécuter le service principal. La commande suivante assignera un mot de passe aléatoire à cet utilisateur, mais vous n’avez pas besoin de vous en souvenir, car l’utilisateur * root * de l’hôte (en dehors de la prison) peut le changer ou devenir tout utilisateur de la prison sans mot de passe:

Ensuite, créez le répertoire principal dans lequel vous allez stocker la configuration:

Et donnez la propriété à l’utilisateur de service:

À partir de ce moment, toutes les configurations et modifications relatives au maître doivent être exécutées en tant qu’utilisateur non privilégié, car cela aidera à maintenir la cohérence de la propriété et des autorisations.

Basculez vers l’utilisateur non privilégié:

Ensuite, utilisez l’utilitaire + buildbot + intégré pour créer un répertoire et une structure de configuration dans le répertoire spécifié:

Contrairement à d’autres logiciels de CI, tels que Jenkins, le comportement de Buildbot est défini directement dans son fichier de configuration, interprété avec Python. Cela permet une gestion simplifiée des versions de votre configuration, tandis que l’utilisation d’un langage de script offre la liberté d’écrire des configurations de construction personnalisées et d’étendre les fonctionnalités existantes de Buildbot.

Le paquet Buildbot est fourni avec un exemple de fichier de configuration principal que vous pouvez utiliser comme modèle pour votre propre configuration. Copiez l’exemple de configuration et nommez-le + master.cfg +:

Ouvrez ensuite le fichier de configuration de base avec votre éditeur de texte préféré. Ici, nous allons utiliser + ee +:

Le fichier de configuration contient un mot de passe requis pour permettre aux utilisateurs de se connecter au maître. Remplacez la valeur par défaut + pass + par un mot de passe sécurisé de votre choix. De plus, le nom de notre travailleur sera + worker0 +, aussi remplacez + exemple-worker + par + worker0 + dans les sections + WORKERS + et + BUILDERS +.

Lorsque vous avez terminé, les parties du fichier que vous devez modifier ressemblent à ceci:

/var/buildbot-master/master.cfg

Enregistrez et fermez ce fichier, puis exécutez la commande + exit + pour revenir à l’utilisateur * root * de la prison:

Étant donné que l’exemple de configuration surveille le référentiel Git + git: // github.com / buildbot / hello-world.git + en tant que source de modification, vous devez également installer Git:

Avec cela, vous avez créé la structure et la configuration du répertoire principal, mais le service n’est pas encore en cours d’exécution. Pour exécuter Buildbot manuellement, vous pouvez exécuter la commande + buildbot start + à partir du répertoire principal, + / var / buildbot-master +. Cependant, cela ne prend pas en charge le démarrage au démarrage ou une autre configuration à l’échelle du système. Au lieu de cela, nous utiliserons rc scripts, la méthode standard de FreeBSD pour l’exécution des services. Plus précisément, nous le ferons à l’aide de l’utilitaire + service +.

Pour les besoins de ce didacticiel, nous souhaitons permettre au service de s’exécuter à chaque démarrage. Dans le cas des prisons, cela signifie l’événement de début de la prison. Utilisez la commande suivante pour définir l’emplacement du répertoire principal:

Puis spécifiez que le service doit être exécuté sous l’utilisateur * buildbot-master *:

Ensuite, activez le service pour qu’il s’exécute au démarrage de jail:

Au moment de la rédaction, le paquetage + py36-buildbot + a un bogue qui empêche le service de démarrer (voir ce rapport de bogue) . En attendant que cela soit corrigé, vous devrez patcher manuellement le script de démarrage en exécutant la commande suivante depuis votre jail + buildbot-master +:

Ensuite, démarrez le service:

Le service devrait commencer sans erreur. Vous pouvez vérifier le succès en consultant le contenu du fichier journal:

Pour revenir au shell de l’hôte, lancez + exit + depuis le shell jail:

Vous avez correctement configuré et démarré le service principal Buildbot. Le deuxième composant, le travailleur, est requis pour exécuter les générations. Vous allez installer un travailleur dans la section suivante dans une deuxième prison, puis configurer sa connexion au service principal.

Bien que le maître Buildbot soit en cours d’exécution, aucune construction ne peut avoir lieu, car au moins un agent doit être exécuté. Cette étape est similaire à la précédente en ce sens que nous allons d’abord installer une prison séparée, puis installer le service. Cette fois, cependant, le composant travailleur Buildbot se connectera au maître pour écouter les commandes et rendre compte des résultats.

Les instructions de cette étape sont presque identiques à celles de la configuration principale, à la différence que le composant de travail fait partie d’un autre package et que les seules modifications apportées à la configuration impliquent l’ajout de détails sur sa connexion au maître et certaines informations d’affichage sur le travailleur lui-même.

Assurez-vous que vous êtes dans le shell de l’hôte, pas dans une prison. Ouvrez ensuite un shell * root * dans la prison de travail:

N’oubliez pas que, dans ce guide, les blocs de commande sont marqués d’une couleur différente s’ils doivent être exécutés dans un shell jail et que les invites de commande indiqueront le profil utilisateur sous lequel les commandes doivent être exécutées.

Installez le package de travail Buildbot avec la commande suivante:

Lors de l’exécution de cette commande, elle vous demandera de confirmer si vous souhaitez amorcer l’utilitaire de gestion de paquets + pkg +. Faites-le en entrant + y +. Il vous demandera également de confirmer que vous approuvez l’installation des packages. Entrez donc + y + à nouveau lorsque vous y êtes invité.

Ensuite, créez un utilisateur régulier et non privilégié pour exécuter le service de travail:

Créez ensuite le répertoire de travail. Il s’agit de l’emplacement où seront stockés la configuration, les informations d’affichage et les répertoires de construction de l’ouvrier:

Donnez la propriété à l’utilisateur du service:

À partir de ce moment, toutes les configurations et tous les changements liés aux travailleurs doivent être exécutés en tant qu’utilisateur non privilégié. A cette fin, basculez vers l’utilisateur + buildbot-worker +:

Utilisez l’utilitaire + buildbot-worker + intégré pour créer un répertoire et une structure de configuration dans le répertoire + / var / buildbot-worker +. Spécifiez l’adresse IP de la prison maître - + 10.0.0.2 +, que nous avons choisie à l’étape précédente - pour que le travailleur puisse s’y connecter et remplacer + + pass + par le mot de passe que vous avez défini dans le fichier de configuration maître:

Pour terminer la configuration, renseignez quelques détails sur l’administrateur système et le but de l’utilisateur:

Ensuite, exécutez la commande + exit + pour revenir à l’utilisateur * root * de la prison:

Étant donné que l’exemple de configuration clone le référentiel Git + git: // github.com / buildbot / hello-world.git + pour générer l’exemple de projet, vous devez également installer Git dans cette prison. Notez que le maître Buildbot a également requis Git car les sources de changement s’exécutent sur le maître. De plus, le constructeur utilise un exécuteur de test appelé + trial + qui fait partie du paquetage + py27-twisted +, donc installez-le avec + git-lite +:

Le mécanisme intégré permettant d’exécuter un travailleur est + buildbot-worker start +, qui doit être exécuté à partir du répertoire de travail, + / var / buildbot-worker +. Cependant, cela ne prend pas en charge le démarrage au démarrage et ne garantit pas qu’il s’exécutera sous le bon utilisateur. Comme vous l’avez fait avec le maître, exploitez le script + rc + fourni en utilisant l’utilitaire + service +, pour gérer le service.

Utilisez les commandes suivantes pour définir le répertoire de travail, ainsi que l’utilisateur et le groupe sous lesquels le service doit être exécuté:

Ensuite, activez le service pour qu’il s’exécute au démarrage de jail:

Au moment de la rédaction de ce document, le paquetage + py36-buildbot-worker + a un bogue qui empêche le service de démarrer (voir ce rapport de bogue ). En attendant que cela soit corrigé, vous devrez patcher manuellement le script de démarrage en exécutant la commande suivante à partir de votre jail + buildbot-worker0 +:

Enfin, démarrez le composant worker:

Le service devrait commencer sans erreur. Vous pouvez vérifier qu’il a réussi en affichant les entrées les plus récentes dans le fichier journal:

Si le service a démarré avec succès, un message comme + Connected to 10.0.0.2:9989; le travailleur est prêt + `apparaîtra dans le fichier journal. Si vous avez oublié de spécifier un nouveau mot de passe plus tôt dans cette étape, le service ne parviendra pas à se connecter au maître. Dans ce cas, éditez le fichier `+ / var / buildbot-worker / buildbot.tac + puis exécutez + service buildbot-worker restart + pour rectifier ce problème.

Une fois le service démarré correctement, abandonnez-le vers le shell de l’hôte en exécutant la commande + exit + à partir du shell jail:

Avec cela, la deuxième prison a été configurée et vous avez tous les composants de base nécessaires pour utiliser Buildbot. Pour être facilement utilisable par vos utilisateurs, il est recommandé de configurer également l’interface utilisateur Web. Cela vous permettra de contrôler Buildbot et de voir les résultats de construction avec plus de commodité.

Buildbot comporte une interface utilisateur Web qui affiche les vues d’ensemble et les résultats, et vous permet de déclencher les générations manuellement si un planificateur «forcé» est configuré, comme c’est le cas dans l’exemple de configuration.

Votre configuration maître configure déjà le composant + www + pour servir HTTP sur le port + 8010 +. Dans un contexte de production, vous ne serviriez pas de HTTP non crypté ni n’ouvririez le port non standard + 8010 + à l’extérieur, car cela exposerait votre système à des vulnérabilités en matière de sécurité. En outre, l’interface Web peut être servie à partir de n’importe quel chemin d’URL, ce qui signifie qu’il n’est pas nécessaire qu’elle soit la seule application de votre domaine. Par exemple, vous pouvez servir des sorties ou des journaux de construction à vos utilisateurs. Nous allons donc servir l’interface utilisateur aux utilisateurs avec un serveur Web distinct - Nginx - afin de prendre en charge HTTPS, de protéger les ports internes et de pouvoir servir d’autres contenus parallèlement à l’interface Web Buildbot.

Ouvrez le fichier de configuration Nginx pour le modifier:

Ajoutez les blocs + location n surlignés suivants au sein du bloc` + serveur` existant du fichier:

/usr/local/etc/nginx/nginx.conf

Cette configuration transfère toutes les demandes situées sous le chemin d’URL + / buildbot / + à l’interface Web et active le support WebSocket, qui est utilisé par l’interface pour recevoir les mises à jour qu’elle affichera, telles que la sortie du journal d’une génération en cours d’exécution.

Enregistrez et fermez le fichier de configuration Nginx. Rechargez ensuite le service Nginx:

Ouvrez votre navigateur Web préféré sur votre ordinateur local et accédez à l’interface Web de Buildbot en accédant à l’URL suivante:

Sinon, si vous n’avez pas configuré de nom de domaine pour votre serveur, vous devrez plutôt entrer l’adresse IP publique de votre serveur, + http: /// buildbot / +.

Lorsque vous arrivez à l’interface, vous verrez un aperçu similaire à celui-ci:

image: https: //assets.digitalocean.com/articles/buildbot_freebsd/web_interface_overview_final.png [Vue d’ensemble de l’interface Web]

La page principale peut afficher un avertissement indiquant que l’URL de Buildbot est mal configurée. Cela se produit si le nom d’hôte fourni dans le fichier + nginx.conf + ne correspond pas à ce qui est répertorié dans la configuration principale de Buildbot. Etant donné que les e-mails de résultats de construction contiennent des liens vers l’interface Web Buildbot par défaut, le maître doit connaître l’URL correcte où il peut être atteint.

Notez que, dans nos exemples de configuration, nous n’avons pas configuré ce service de messagerie. Si vous souhaitez configurer cela, consultez documentation sur les rapporteurs de Buildbot pour plus d’informations:

Cela dit, pour résoudre l’avertissement et envoyer des courriels contenant le contenu correct, modifiez la configuration principale de Buildbot pour qu’elle pointe vers votre domaine.

Recherchez la ligne commençant par + c ['buildbotURL'] + et remplacez l’option par défaut par votre nom de domaine, suivi de + / buildbot / +:

/var/buildbot-master/master.cfg

Enregistrez et fermez le fichier. Ensuite, pour appliquer la nouvelle configuration, rechargez le service + buildbot +:

Actualisez l’interface Web Buildbot dans votre navigateur et l’avertissement disparaîtra.

Les serveurs d’intégration continue ont souvent d’autres objectifs que l’EC. Par exemple, un serveur CI peut servir des sorties de construction pour les packages FreeBSD ou les journaux via HTTPS. Il est donc recommandé de réserver le chemin d’URL + / buildbot / + pour l’interface Web. Cela vous permet d’héberger plus d’applications sous différents chemins. Pour le moment, nous allons créer une page d’accueil simple qui redirige vers l’interface Web. Vous pouvez ajouter plus de liens une fois que vous avez implémenté plusieurs cas d’utilisation pour le serveur Web.

Exécutez la commande suivante pour ouvrir un fichier d’index dans votre racine Web - en remplaçant ++ par votre propre domaine - pour créer une redirection automatique vers l’interface Web de Buildbot:

Remplacez tout contenu de fichier existant par les lignes suivantes:

/usr/local/www/nginx/index.html

Enregistrez et fermez ce fichier, puis entrez votre nom de domaine ou votre adresse IP dans la barre d’URL de votre navigateur. Il devrait automatiquement vous rediriger vers l’interface Buildbot.

L’installation de tous les composants de Buildbot, y compris son interface Web de contrôle et d’affichage, est terminée. Avec tout cela en place, exécutons une construction réelle comme spécifié dans l’exemple de configuration que nous avons configuré pour le maître.

Le constructeur dispose d’un planificateur «forcé» configuré par défaut, ce qui vous permet de déclencher votre première construction. Dans l’interface Web, cliquez sur * Builds *> * Builders *> * runtests *> * force *> * Start Build * et voyez comment la construction s’exécute. Si vous constatez des erreurs, vérifiez la connexion Internet du serveur et vérifiez si tous les packages dépendants ont été installés comme décrit précédemment.

image: https: //assets.digitalocean.com/articles/buildbot_freebsd/sample_build_success.png [Capture d’écran d’un exemple de réussite de la construction]

Vous pouvez trouver les artefacts de cette construction (et d’autres) en consultant le contenu du répertoire de construction:

Vous avez configuré avec succès un système CI polyvalent et fonctionnant de manière permanente et pouvez maintenant commencer à mettre en œuvre vos propres versions.

En complétant ce didacticiel, vous vous êtes exercé à créer des jails FreeBSD et à maîtriser les bases du framework d’automatisation Buildbot, pour une installation prête à l’emploi. Pour en savoir plus sur Buildbot et sa configuration, nous vous encourageons à lire la documentation officielle de Buildbot.

À partir de là, vous êtes libre d’implémenter vos propres pratiques d’intégration continue et d’automatisation. Afin de disposer d’une configuration sécurisée, stable et performante pour une utilisation en production, vous souhaiterez peut-être suivre les étapes de configuration facultatives suivantes: