Cette semaine, Julien Fricou, Data Engineer chez Saagie, a pu interroger Alain Hélaïli, Principal Solutions Engineer chez GitHub, sur l’utilisation de la plateforme. La CI/CD GitHub n’aura plus de secret pour vous !
Comment créer un workflow (fichier yaml, éditeur graphique) ?
Avec GitHub Actions, nous avons décidé que la philosophie serait de faire du “pipeline as code” (workflow as code). C’est un éditeur de texte, donc un fichier yaml, avec plusieurs possibilités d’édition :
- Via l’interface graphique de GitHub
- Via d’autres éditeurs de texte comme Visual Studio Code
Nous avons pris le parti du “as code”, avec une création textuelle, et une visualisation des exécutions.
L’utilisation de fichiers de définition de build n’est pas nouvelle. On retrouve ce principe dans la plupart des outils de CI (pour Continuous Integration) du marché, tel que Jenkins avec les fichiers Groovy, GitLab CI, Travis CI, Circle CI. On parle alors de « Pipeline as Code», terme alors issu de la pratique du DevOps. L’intérêt étant de pouvoir stocker et versionner le fichier (souvent .yaml) définissant notre pipeline directement.
Est-il possible de “convertir” une chaîne CI/CD d’un autre outil ( jenkins par exemple) en workflow github ? Sinon, quelles seraient les bonnes pratiques de migration ?
L’aspect conversion est un sujet en phase de maturation, cette fonctionnalité n’est pas encore implémentée. Le problème, dans l’industrie de la CI, c’est que tout le monde a des concepts particuliers. Je pense que nous n’arriverons jamais à faire une intégration complètement transparente d’un workflow de Jenkins vers GitHub par exemple. Il y a quasiment systématiquement une partie à faire manuellement, tout simplement parce qu’il ne s’agit pas uniquement d’une syntaxe, mais de tout un écosystème à migrer. Certains plugins existent ou pas selon les outils, et n’ont pas forcément les mêmes fonctionnalités. L’objectif est donc de réduire au maximum cette partie manuelle, mais nous n’arriverons probablement pas à l’éliminer totalement.
Le constat aujourd’hui est que nos clients préfèrent conserver leurs pipelines à l’identique parce qu’il y a une parfaite compatibilité entre GitHub et Jenkins ou un autre outil. Lorsqu’ils doivent créer un nouveau pipeline ou faire un refactoring, ils en profitent pour passer sur GitHub Actions.
Comment déclencher des actions à partir d’événements externes ?
Tout va dépendre de ce qu’est un événement externe. Chez GitHub, nous considérons l’externalité différemment d’autres outils. Nous avons beaucoup plus d’événements internes que sur d’autres solutions de CI. Dans GitHub Actions, nous avons décidé de ne pas juste réagir à des événements de type push de code ou triggers externes. Nous considérons que n’importe quel événement peut déclencher des pipelines. Par exemple, si une issue est créée ou un nouveau membre ajouté sur un projet, cela déclenche un pipeline.
Toutefois, quatre méthodes permettent de déclencher des actions :
- Les APIs : nous avons des API destinées à écouter des ordres. Par exemple, nous avons à notre disposition une API de déploiement qui a été conçue comme un middleware permettant de demander à GitHub de déclencher un workflow de déploiement. C’est donc GitHub qui va transmettre ce message de déploiement aux applications qui écoutent ce message. GitHub Actions, ce n’est rien d’autre qu’un moyen d’écouter ces ordres, un moyen de déclencher un pipeline.
- Repository de dispatch : il s’agit d’un événement qu’on envoie sur le repository. Cet événement existe depuis longtemps, il était possible de s’y abonner via des webhooks, mais il est désormais traité automatiquement dans GitHub Actions.
- Workflow dispatch : il permet de faire un déclenchement manuel d’un pipeline spécifique.
- Crontab : cette fonctionnalité permet de programmer à l’avance l'exécution d’un pipeline.
Comment monitorer les actions ? Temps d’exécution, nombre d’exécutions… ?
Dans l’interface graphique de GitHub, il est tout à fait possible de visualiser les temps d’exécution. Il suffit d’aller dans l’onglet “paramètres” de l’organisation, puis dans la page “Billing” pour y trouver l’agrégation de tous les temps consommés par les GitHub Actions (en minutes). C’est également à cet endroit qu’il est possible d’exporter un rapport d’utilisation avec un détail par repository.
Par ailleurs, toutes ces données sont également accessibles par API : les utilisateurs peuvent créer leurs propres tableaux de suivi, workflow par workflow. Tout cela est faisable sur Rest ou GraphQL, APIs permettant de récupérer toutes ces informations.
Pourquoi choisir l’hébergement sur GitHub plutôt qu’un hébergement interne ?
Aujourd’hui, nous ne sommes pas obligés de choisir. En effet, l’offre GitHub Enterprise repose sur 2 piliers :
- GitHub Enterprise Cloud (SaaS) : Single Sign-On (SSO), support entreprise, logs d’audit.
- GitHub Enterprise Server : soit public cloud provider, soit serveurs physiques
Les utilisateurs peuvent désormais choisir d’aller sur l’un, sur l’autre ou les deux selon les projets, sans notion de coût supplémentaire.
Ceux qui sont encore sur des hébergements internes ont généralement des contraintes sur la localisation de la donnée, de data centers, etc. C’est aussi souvent parce que l’IT n’est pas encore prêt pour un déploiement cloud. Il ne faut également pas oublier l’inertie de la culture “on prem”, dont on ne sait pas encore où elle va mener.
En revanche, l’avantage du SaaS est de se soustraire à la gestion d’une infrastructure et cela permet de gagner un temps non négligeable. Cette option permet aussi d’avoir accès aux nouvelles features plus rapidement que sur des serveurs physiques.
Avec le covid, certaines entreprises se sont rendu compte qu’elles n’étaient pas suffisamment bien équipées pour que les développeurs puissent faire du code à distance. Depuis quelques mois, on assiste donc à un changement des pratiques : beaucoup d’entreprises, avant réfractaires au cloud, se sont tournées vers le SaaS car ce n’était plus possible autrement.
Quelles sont les bonnes pratiques de sécurité pour le build et la publication d’images Docker privées ?
Si j’ouvre le débat au-delà de Docker, nous avons beaucoup travaillé sur la notion de sécurisation des dépendances (par exemple image Docker ou librairie Javascript) avec notre outil Dependabot. S’il y a des vulnérabilités dans les versions, Dependabot recommande de passer sur des versions plus récentes qui proposent une remédiation de la faille. Il est toutefois indispensable de rester attentif à l’origine des dépendances – d’où elles proviennent, comment elles ont été créées – et de mettre en place les outils qui permettent de suivre les vulnérabilités et pouvoir les mettre à jour très rapidement.
Dependabot peut également surveiller systématiquement les technologies utilisées dans les projets et envoyer des push encourageant les utilisateurs à passer à la version plus récente. De cette manière, nous sommes en mesure d’être proactifs, et limiter la dette technique des utilisateurs sur le long terme.
Enfin, sur GitHub, nous avons depuis quelque temps la notion de registry, appelée GitHub Packages, où un registry Docker est disponible et nous sommes actuellement en train de passer sur un Container registry afin d’intégrer la norme Open Container Initiative (OCI) qui standardise plus d’aspect de la gestion d’un container. Il sera bien entendu toujours possible de stocker des éléments de manière publique ou privée.
Comment gérer les versions des librairies/soft utilisées par les runners (nouvelle version de gradle, changement d’environnement Python…) ?
C’est un grand sujet ! Avec GitHub Actions, nous essayons d’apporter un système hybride d’usage, mode cloud ou on premise, de stratégie, et Virtual Machine (VM) ou Container.
Si on se base sur le cas le plus simple, c’est à dire en mode cloud, et que nous souhaitons exécuter un pipeline sur un agent fourni par GitHub, alors nous serons directement sur des VM et il sera plus simple de configurer des VM plutôt que d’installer des logiciels. En effet, les VM que nous mettons à disposition sont déjà chargées de logiciels adaptés à Ubuntu, Windows ou Mac. Ainsi, plutôt qu’installer Java par exemple, une action permet de donner l’ordre de configurer une version spécifique de Java. Si la version demandée est compatible avec celle pré-installée, rien ne se passe. Le temps de mise en place de l’environnement d’exécution est bien plus rapide de cette manière, ce qui permettra d’optimiser le temps de feedback des développeurs, à condition que l’environnement proposé par GitHub soit adapté aux besoins des utilisateurs.
Dans le cas où les utilisateurs ont des besoins plus précis de manière ponctuelle, nous procédons alors à des installations, mais cela requiert des temps de téléchargement et d’installation pour chaque exécution.
En revanche, dans le cas où les besoins spécifiques sont plus fréquents, il est plus pertinent de créer un container avec une pré-installation de tous les logiciels nécessaires pour exécuter les pipelines. Dans cette situation, un temps de téléchargement du container sera requis, mais il ne sera plus nécessaire de charger et installer ces logiciels à chaque exécution, il n’y aura donc plus de temps de mise en place de l’intégralité de l’environnement.
Enfin, la troisième option serait d’avoir des agents on prem, hébergés sur n’importe quel environnement. Il est à ce moment-là nécessaire de connaître la capacité d’absorption de variétés d’environnements de l’agent, afin de connaître le nombre d’agents à héberger. Ce sont des problématiques plus difficiles à gérer au quotidien.
D’expérience, il est coutume de standardiser les outils utilisés. Certains de nos clients ont déployé des agents sur des clusters Kubernetes, ce qui leur a permis de créer des groupes d’agents labellisés. Cette notion de label va permettre de déterminer quels types d’agents sont nécessaires pour exécuter les pipelines.
Pourquoi utiliser les workflows de GitHub plutôt qu’un outil externe comme Jenkins, Travis, etc? Quels sont les avantages et inconvénients?
Le principal avantage d’utiliser GitHub Actions quand on est déjà utilisateur aguerri de GitHub, c’est qu’il n’y a pas d’intégration à faire. Deuxièmement, la possibilité de choisir entre un déploiement Cloud ou on prem permet une agilité accrue. Enfin, nous proposons désormais l’accès à des ressources Mac pour les développements iOS, ce qui permet également de gagner un temps précieux.
Traditionnellement, avec beaucoup des solutions de CI existantes, utiliser les workflows implique un niveau de complexité non négligeable. De fait, créer un pipeline revient à créer beaucoup de codes shell ou de manipuler beaucoup d’images Docker, ce qui peut parfois être difficile à débugger. Avec GitHub actions, si j’ai besoin d’utiliser Docker, je vais directement prendre l’action GitHub qui a été créée, lui donner les bons paramètres, et c’est Docker qui met à disposition des actions préconfigurées permettant ainsi d’écrire très peu de code in fine. Aujourd’hui, l’ensemble de l’écosystème (Azure, AWS, Sonarqube) met à disposition ce type d’actions, ce qui incite les développeurs à ne faire que de la configuration quasiment et rédiger très peu de code.
Les utilisateurs peuvent également créer leurs propres actions pour enrichir leurs pipelines. Pour ce faire, il y a deux méthodes.
- Soit en fournissant un container Docker
- Soit en créant une action en Javascript car l’environnement node est déjà présent.
En ce qui concerne les inconvénients, dans le cas où les utilisateurs ont déjà un existant Jenkins ou Travis, il faut réapprendre les actions. Il peut donc potentiellement y avoir un problème de courbe d’apprentissage.
Par ailleurs, GitHub Actions n’a que 18 mois d’existence. Nous avons donc encore besoin de porter une réflexion sur certaines fonctionnalités. Ce que l’on peut retenir, c’est que GitHub Actions n’a pas encore le même niveau d’industrialisation que Jenkins par exemple, mais il n’en a pas non plus la complexité. Nous espérons apporter un certain nombre d’améliorations, notamment sur la partie industrialisation, dans les prochains mois !
Dans le futur, serait-il possible d’avoir des templates “complet” de workflow pour certains types de projet?
Dans une organisation GitHub, il est possible d’accéder à un repository (nommé .github) dans lequel sont stockés des templates (template d’issue, template de settings, template de pipelines…) à disposition de l’ensemble de l’organisation. Ainsi, lorsqu’on crée un nouveau pipeline, les templates adéquats seront automatiquement proposés aux utilisateurs. Il s’agit d’une première étape.
Nous réfléchissons maintenant à la notion de fragment de pipelines, avec les librairies de fragments de pipelines qui pourront vivre indépendamment les uns des autres. Il est également possible d’avoir des pipelines qui en appellent d’autres via un événement de type “repository dispatch”.
Peut-on ou pourra-t-on tester les workflows en local afin de diminuer la boucle de feedback?
J’aimerais bien que nous allions plus loin sur ce sujet, mais nous ne l’avons pas encore adressé.. Il existe cependant un projet opensource (https://github.com/nektos/act) qui permet de tester un workflow en local, ce qui aide bien notamment pour débugger une action, et de tester ses outputs. Nous aimerions bien évidemment aller encore plus loin, c’est pourquoi nous avons mis au point une roadmap disponible sur notre site, permettant à nos utilisateurs d’avoir de la visibilité sur les prochaines features.
Après 15 années dans l’industrie du logiciel, Alain rejoint GitHub en 2015 en tant que Solutions Engineer. Il se consacre à renforcer les relations entre développeurs et équipes opérationnelles, et aide les entreprises à comprendre comment construire de meilleurs logiciels, plus rapidement. Fervent défenseur de l’Open Source, Alain a une vision très intéressante sur la manière dont les entreprises utilisent GitHub pour collaborer sur du code et créer des choses incroyables chaque jour.
