CircleCI : Des fonctionnalités au service du déploiement continu et automatisé
Cet article s’appuie sur un talk de Ruaraidh Jay Chalmers, devOps, donné à l’occasion d’un live Twitch.
Ruaraidh utilise CircleCI depuis plusieurs années, en tant qu’outil d’intégration et de déploiement continu. Il a donc eu l’occasion d’explorer ses fonctionnalités et de les voir évoluer. Il revient sur son expérience avec l’outil, les bonnes pratiques à appliquer, mais aussi sur les nouveautés et les possibilités qu’il offre.
Qu’est-ce que la CI/CD ?
Pour bien comprendre le rôle et l’utilisation de CircleCI, il est important de maîtriser les pratiques d’intégration continue (CI) et de déploiement continu (CD).
Les pipelines de CI/CD sont très corrélés au métier d’ingénieur devOps, notamment sur l’automatisation des tâches et des rôles.
L’intégration continue correspond à l’apport de changements réguliers et constants à une base de code. Et aussi à la mise en place de sécurités et d’outillages nécessaires pour protéger cette base de tout changement potentiellement dangereux.
Le déploiement continu correspond au déploiement continuel de ces changements, dans des cycles de livraisons courts et rapides.
Cela permet notamment de limiter les risques inhérents à de grosses livraisons peu régulières comportant de nombreuses fonctionnalités. Dans ces cas, il y a plus de chance qu’un élément soit problématique, comparé à des cycles de livraisons plus courts.
Apparentées aux méthodes agiles, ces approches vont de pair avec l’automatisation des process d’intégration et de déploiement via différents outils. Elles permettent une optimisation de la qualité de livraison et du temps de production et de résolution de bugs.
CircleCI par rapport à ses nombreux concurrents
Dans le domaine de la CI/CD, de nombreux outils se font concurrence : Jenkins, GitLab CI, Travis CI, …
CircleCI a été lancé fin 2011 et s’est progressivement démocratisé en termes d’utilisation, avant de décoller ces dernières années.
Alors que plusieurs outils concurrents ont perdu en popularité, CircleCI connaît un engouement constant depuis 2014. Et il est aujourd’hui l’outil préféré des développeurs de Ruby on Rails. Il est utilisé par de nombreuses structures, de start-ups à de grandes entreprises, qui souhaitent optimiser et automatiser leurs cycles de test et de développement.
Il se différencie notamment par :
- Une adaptation flexible à de nombreux environnements, comme Android, macOs, Linux, Windows, …
- Des pipelines hautement configurables.
- Des outils de visualisation et de débugage natifs.
Alors que débuguer un pipeline de CI/CD sur certains outils peut être assez complexe, CircleCI apporte un outillage par défaut qui permet de limiter ce type de problème. - Un temps d’exécution de conteneurs très rapide.
Les notions fondamentales de CircleCI
L’architecture de CircleCI
CircleCI comprend à la fois une version on-premise que l’on peut faire tourner sur des serveurs et une version saas/ cloud. Il y a quelques différences entre les deux versions, et l’article se concentre sur la version Saas hébergée sur le cloud.
Différentes entrées permettent de communiquer avec les API de CircleCI, via des appels API : console en ligne, repository (dépôt de code) et applications. Les outils de versioning comme Github, GitLab et Bitbucket sont en effet hautement intégrés.
L’API CircleCI utilise les différents objets pour orchestrer les tâches fournies, via des outils comme les workflows, le caching, les contexts et les artefacts.
Et ensuite on exécute sur divers environnements : Docker, Linux, Apple, GPU, ... Pour arriver au déploiement à travers ces environnements d’exécution.
Les projets
CircleCI est hautement intégré aux outils de versioning de code (VSC). Par exemple, un utilisateur de CircleCI représente un ‘viseur’, qui correspond à un utilisateur Github. D’ailleurs tout utilisateur qui a des droits de lecture et d’écriture sur un repository Github aura ces mêmes droits dans CircleCI. Cela permet de simplifier les interactions et de n’avoir qu’un seul compte. Il suffit alors de relier son compte d’utilisateur Github, mais aussi GitLab ou Bitbucket à son compte CircleCI. Et on a les mêmes accès sur les workflows CircleCI qu’on aurait sur les repository et les projets de code.
Finalement un projet CircleCI est tout simplement un repository de code Github, GitLab ou Bitbucket.
La configuration
CircleCI est un outil de configuration as code. On configure l’outil via un fichier de code écrit en YAML, ce qui permet d’avoir un point d’entrée unique. Le fichier .circleci/config.yml se trouve dans n’importe quel fichier que l’on veut déployer sur CircleCI. Il fait office de source de vérité dans sa base de code dans un contexte d’évolution constante avec l’intégration et le déploiement continu. On peut ensuite le modifier, intégrer, travailler et collaborer dessus avec tout l’outillage de versioning de code que l’on connaît en tant que développeur.
Tout fichier CircleCI commence aussi avec la spécification de la version utilisée. Il est important d’utiliser la version 2.1 pour avoir accès à toutes les nouvelles fonctionnalités.
Les executors et images
Chaque tâche exécutée dans CircleCI est exécutée dans un environnement unique. À l’instar des conteneurs Docker, au lieu de faire tourner nos tâches sur un serveur de déploiement, chaque tâche va être exécutée dans une bulle isolée et virtuelle. Ces environnements peuvent être soit un conteneur, soit une machine virtuelle, même si pour la performance on a tendance à préférer les conteneurs. Mais une des raisons principales de l’utilisation d’une machine virtuelle, est l’utilisation de Docker dans un environnement conteneurisé. Ce n’est pas une bonne pratique d’utiliser Docker dans un environnement dockeurisé d’un point de vue sécurité. Du coup on est obligé de créer un environnement parallèle qui permet d’avoir un environnement Docker.
Chaque executor contient l’outillage nécessaire à l’exécution de la tâche, puisque cet executor est fourni par une image. Et pour rappel une image est un package que l’on peut instancer de manière virtuelle dans un environnement de conteneurs. Donc on prend l’image, qui est une copie à un instant T d’un système, et on la déploie ensuite sur un conteneur.
Pour résumer on fournit une image à l’executor, qui nous permet de contrôler le point de départ et l’état initial de notre executor.
On peut spécifier plusieurs images à notre executor, et on peut aussi spécifier une image MySQL qui peut tourner en parallèle et permettre de faire des tests unitaires.
Les jobs et steps
Un job correspond à une tâche, ce que l’on cherche à faire. Et une tâche est composée de plusieurs étapes, steps, qui sont des commandes exécutées.
Un job représente donc à la fois une tâche et un regroupement de steps, qui sont des étapes d’exécution de commande.
Entre chaque job, chaque environnement d’exécution est unique. Dans la partie configuration, on nomme le job, on donne sa définition et celle de l’environnement d’exécution, dans lequel seront exécutées les commandes, souvent en Bash, mais aussi en Python ou autre.
On peut alors choisir de fournir systématiquement l’environnement de production, l’executor, dans chaque job, mais l’idée est plutôt de faire du DRY (Dont Repeat Yourself) et d’essayer de réutiliser un maximum de choses.
Les workflows
Comme les jobs sont des regroupements de steps, les workflows sont des regroupements de jobs. Et grâce aux workflows on peut faire des connexions logiques entre les jobs pour installer une chronologie.
Dans l’exemple ci-dessus, nous avons quatre tâches avec leurs temps d’exécution. Ces tâches sont exécutées en parallèle et finissent par une tâche qui les regroupe. C’est ce qu’on appelle un workflow.
Les workflows peuvent exécuter des tâches de façon :
- concurrente — en simultané,
- séquentielle — les unes après les autres,
- planifiée — via une chaîne de caractères CRON qui permet de définir à quelle fréquence le workflow va s’exécuter de manière automatique,
- manuelle — en faisant appel à l’API.
Les fonctionnalités avancées
Les orbs
Il s’agit de configuration réutilisable. C’est-à-dire que l’on peut créer un orb, pousser de la configuration CircleCI dans cet orb et cela agit ensuite comme une librairie distante de CircleCI utilisable dans tous nos projets. Cela permet d’avoir une centralisation de la configuration, ce qui peut être pratique si on travaille sur plusieurs projets ou à plusieurs sur un même projet.
Nos workflows, jobs, steps peuvent ainsi être centralisés dans un même orb.
Il faut aller alors appeler l’orb, avec le mot-clé ‘orb’ pour ensuite pouvoir appeler les jobs présents dans cet orb.
Grâce à cette flexibilité, CircleCI permet de faire de la configuration dynamique. En effet, dans une tâche, il est possible de gérer de la configuration dynamique en passant par des orbs, via des appels API.
Les runners
Il s’agit d’images qui peuvent tourner sur un environnement fermé et isolé afin de ne pas devoir autoriser une connexion entrante de CircleCI.
Il est du coup possible de communiquer avec CircleCI uniquement avec une connexion sortante. Le runner communique avec le serveur et pousse le job sur l’environnement isolé.
Cela peut être très pratique d’exécuter à partir du runner sur des environnements orchestrés comme Kubernetes. Mais aussi pour des projets qui ne peuvent pas être sur le cloud, comme des projets militaires ou bancaires.
Les outils de visualisation
Un gros travail de CircleCI a été fait sur la partie ‘insights’. Il s’agit d’une partie de CircleCI qui permet d’avoir plus d’observabilité sur ses workflows, ses tests, ... Pour chaque worflow et chaque branche sur laquelle il est exécuté, on retrouve : la consommation de crédit (donc du coût) de chaque workflow, le temps total d’utilisation (qui est en lien avec les crédits consommés), le nombre d’exécution et le pourcentage de succès ou d’erreur.
Sur des worfklows en production, cela permet d’identifier rapidement de potentiels problèmes.
Pour le débuguage, le portail permet d’ailleurs de retrouver les tâches qui ont un statut ‘fail’ et de les relancer. Il est aussi possible de les relancer avec SSH, ce qui peut être pratique pour débuguer, en se connectant sur le conteneur de l’environnement avec un accès SHell.
Les crédits apparents sur l’outil de visualisation correspondent au modèle de facturation de CircleCI. Ils ont récemment revu leur offre, pour passer d’un système limitatif à un modèle basé sur la consommation. Il y a une limite en dur de concurrence avec une offre gratuite, qui permet d’exécuter un certain nombre de jobs en parallèle. Et au lieu de payer au nombre de jobs concurrents, on paye à la consommation.
Il y a aussi une facturation sur le stockage, pour persister de la donnée avec un système de cache. L’idée du cache est de persister de la donnée entre les exécutions du workflow, ce qui peut être utile pour les résultats de tests unitaires.
Point d’attention si vous souhaitez réaliser des économies : en divisant les ressources par deux par exemple, on peut aussi doubler le temps d’exécution, ce qui revient finalement au même coût. Il faut donc être vigilant sur ces paramétrages. Mais c’est justement l’avantage du portail insights qui permet de suivre ces données !
Pour aller plus loin
Ruaraidh (aux côtés de Julien — SRE et Paul-Henry également devOps) a aussi partagé la vision de son métier et de l’approche devOps dans un autre article.
Ils évoquent chacun leur parcours et leurs outils de prédilection, ainsi que la perception de leur métier et de son évolution.
Nous publions régulièrement des articles sur des sujets de développement produit web et mobile, data et analytics, sécurité, cloud, hyperautomatisation et digital workplace.
Suivez-nous pour être notifié des prochains articles et réaliser votre veille professionnelle.
Retrouvez aussi nos publications et notre actualité via notre newsletter, ainsi que nos différents réseaux sociaux : LinkedIn, Twitter, Youtube, Twitch et Instagram
Vous souhaitez en savoir plus ? Consultez notre site web et nos offres d’emploi.
