Blog

CICD via Gitlab

Je vous propose une série de trois articles concernant la CICD via Gitlab.

  • Pipeline-trigger, un outil pour les gouverner tous.
  • Remote gitlab-ci, moins y’en a mieux c’est.
  • Docker factory, l’usine à images !

Pourquoi ces trois articles ? Je pars d’un constat simple. Maintenir un CICD dans une entreprise qui évolue est très chronophage. Etre en phase avec les normes de sécurité, être assez modulaire pour prévoir les spécificités de chaque projet ou encore gérer les tokens et autres variables globales… peut vite devenir un cauchemar. Et je sais de quoi je parle.

Consultant DevOps pour une société dans le secteur de l’assurance, notre environnement de CICD est composé d’une trentaine de projets différents. Tout autant de gitlab-ci.yml à maintenir. Je vais donc vous exposer les solutions mises en place après les webinars et autres conférences docker/gitlab auxquels j’ai participé.

PIPELINE-TRIGGER

En tant que DevOps mon équipe a été amenée à mettre en place des outils permettant de faire des livraisons unitaires, service par service, et globales, tous les services d’un coup. Jusque-là, normal me direz-vous … Et pourtant la première difficulté était là. Comme je vous le disais dans l’intro, la société dans laquelle j’effectue ma mission possède une trentaine de projets dont certains sont dépendants les uns des autres.

Pour automatiser au maximum, nous avons créé un projet supplémentaire pour rajouter une couche d’abstraction au fait de devoir lancer des jobs sur chacun de projets.

Dans ce nouveau projet, des jobs vont venir faire un trigger sur les autres projets via des curl pour être en mesure lancer des pipelines à distance.

Imaginons un cas simple, vous avez deux projets A et B à déployer et chacun est indépendant l’un de l’autre. Dans ce cas précis, on crée un job pour chacun des deux projets qui va faire le déploiement, un gitlab-ci qui pourrait ressembler à ça :

 

Maintenant, imaginez que A ait besoin que B soit déployé (ou buildé, ou pushé sur Nexus… bref, X raisons d’avoir une dépendance). La ça devient compliqué.

Pourquoi ?

Parce que pour lancer le job `deploy_A` on a besoin que le job `deploy_B` soit FINI ! Le problème étant que curl ne permet pas ça, car curl renvoie un status_code=OK si le curl lui-même s’est bien passé, s’il a réussi à créer un pipeline distant, c’est tout, sans aucune considération de l’état du pipeline distant que ça a créé. Et là pas le choix que de faire des actions manuelles qui consistent à lancer le pipeline de B, attendre la fin puis lancer le pipeline de A. Dans cet exemple où il n’y a que 2 projets, l’impact est limité. Quoique cela peut vite devenir contraignant si les pipelines durent dans le temps (migrations de données ou autres…), mais dans le cadre d’une trentaine de projets, avec des dépendances croisées un peu partout ou du legacy, c’est l’enfer.

Heureusement on est vite tombé sur un outil open source qui nous a sauvé la mise et a grandement augmenté notre capacité de management de notre CICD.

Pipeline-trigger

Cet outil est un simple script python, vraiment très bien pensé qui a été créé pour répondre à la problématique précédemment expliquée. Je profite de ce billet pour remercier l’auteur du script qui a eu cette idée géniale.

Je ne vous expliquerai pas le code ici, je vous invite donc à le lire, en suivant le lien plus haut, pour une meilleure compréhension du fonctionnement de l’outil.

Voyons ce qui change avec cet outil pour nos deux jobs précédents :

On a changé l’image pour utiliser l’image officielle qui contient le script.

Mais le changement se fait surtout au niveau du curl, là où maintenant on a un nouveau mot clé, `trigger`.

  • Comme le script utilise l’api de gitlab il est nécessaire de lui fournir un `API_TOKEN` afin de s’authentifier.
  • Le user a besoin d’un `DEPLOY_TOKEN` propre à chaque projet, il faut aller dans les settings des projets pour pouvoir les créer.
  • Le `PROJECT_ID` propre à chaque projet
  • `–target-ref` la branch que l’on souhaite utiliser sur le projet distant pour créer le pipeline
  • `–env` permet d’envoyer une variable d’environnement au pipeline distant.

Quelle est l’utilité d’utiliser le pipeline-trigger, puisque de prime abord il a l’air de faire EXACTEMENT la même chose que curl?

La grosse différence est dans le fait que `trigger` ne se contente pas de créer un pipeline distant à l’instar de curl, il attend la réponse du pipeline, et fait échouer le job si jamais le pipeline distant échoue !

Grâce à cet outil on est capable d’automatiser complètement l’exemple vu précédemment. Pipeline-trigger permet aussi d’exécuter des jobs manuels de façon automatique, c’est toujours bon à savoir, alors n’hésitez pas à lire la doc pour en apprendre plus.

REMOTE GITLAB-CI

Maintenant que vous êtes en capacité de pouvoir tout contrôler à partir d’un point central, on va voir comment optimiser la maintenance et la modularisation de notre CICD.

Plus on a de projets et plus on a de gitlab-ci. Et à chaque modification il faut penser à répercuter la modification sur tous les gitlab-ci… Ça peut vite devenir dur à maintenir et encore plus à faire évoluer.

Donc l’article sera consacré à une fonctionnalité bien trop méconnue de gitlab, les includes.

Une fois de plus mon équipe s’est confrontée à la gestion de nos gitlab-ci. Avec notre trentaine de projets, à chaque modification sur un job il fallait faire une trentaine de MR aux techleads des projets pour que ce soit mergé, puis remonté jusqu’en master… bref, un enfer.

Alors on a fouillé la doc de gitlab en étant persuadé que les ingénieurs qui bossent chez gitlab avaient pensé à une solution. Et effectivement. On a trouvé les includes qui permettent d’importer un gitlab-ci d’un projet distant… de la vraie magie !

On a donc fait un projet d’abstraction exactement comme pour le pipeline-trigger, pour n’avoir qu’un seul endroit avec tous les gitlab-ci.

Du coup plutôt que d’avoir un gitlab de plusieurs centaines de lignes dans chaque projet, on les a tous remplacé par ça :

6 lignes !!! De cette façon la gestion était transparente pour les développeurs et on avait plus besoin de faire de MR vers leurs projets pour faire nos modifications, cela a permis de mettre une distanciation entre la partie purement développeur et purement DevOps.

Le fait est que nous avions toujours notre problème de duplication de code pour chaque projet.

Du coup on s’est dit qu’on allait appliquer le même principe à ce même projet contenant tous les gitlab-ci. On a donc éclaté tous les jobs de nos gitlab-ci et avons créé un gitlab-ci par job.

Oui, ça fait quelques fichiers… mais vous allez voir, le bénéfice en vaut largement la chandelle.

Rien que de faire ça a permis de supprimer l’intégralité du code dupliqué. Car pour chaque job identique, on a laissé le même gitlab-ci sans en créé un qui serait la copie parfaite du premier. Et donc au final ça ne faisait pas tant de fichiers que ça en plus.

Une fois tous ces nouveaux gitlab-ci on a modifié les gitlab-ci que nous avons exporté. Pour rappel dans notre projet on avait à la base ça :

Nous avons maintenant ça :

Sauf que nos gitlab-ci service-X.gitlab-ci.yml eux ont toujours leurs centaines de lignes.

Donc appliquons les includes… et maintenant ils ressemblent à ça :

Infiniment plus simple.

Une fois fini de mutualiser nos gitlab-ci on s’est rendu compte en fait que nous étions passé d’une trentaine de gitlab-ci à une demi-douzaine avec une vingtaine de jobs différents. Notre CICD était finalement moins complexe que nous ne le pensions. Et vous, comment est votre CICD ?

DOCKER FACTORY

Et voici le troisième article de la saga CICD.

Après avoir vu le management des pipelines, le management des gitlab-ci… nous avons cherché, une fois de plus, à vouloir mutualiser les autres ressources disséminées dans notre gitlab.

Le plus gros point que nous ayons relevé à ce moment-là, était les variables CICD, tous les tokens et autres variables nécessaires au fonctionnement du pipeline. Et ça sur notre trentaine de projets… c’était la galère dès qu’un token n’était plus valide, il fallait trouver lequel ne fonctionnait plus et tous les endroits où le changer.

Notre objectif était donc de supprimer toutes ces variables et de pouvoir les contrôler à un seul endroit à l’instar des triggers et des gitlab-ci.

Pour la troisième fois nous avons créé un projet pour faire une couche d’abstraction.

Dans ces projets on a ajouté toutes les variables de tous les projets et on s’est dit, et bien comme on utilise des images docker dans notre CICD on va ajouter ces variables à nos images. On va donc faire nos propres images avec une surcouche sur les officielles que nous stockerons chez AWS.

Voilà comment on a fait :

  • Création d’un docker-compose (pourquoi compose et pas docker tout simple ? juste pour pouvoir utiliser le fichier .env)

  • Création d’un docker-compase.overrides

  • Création du .env

  • Mise en place du gitlab-ci

Ce qui donne cette architecture:

Et voilà avec ça vous avez votre propre usine à images avec toutes vos variables à l’intérieur.

Je tiens à préciser que ce moyen n’a vocation à être utilisé que pour des images utiles à la CICD, jamais pour des images destinées à aller en PROD, ce serait une énorme faille de sécurité.
Pensez aussi à mettre vos variable en protected/masked dans votre projet afin de tout de même faire les choses proprement.

Puisque qu’on aborde la sécurité, mon prochain article sera certainement sur Anchor un outil très utile pour la détection de failles de sécurité des images à destination de la PROD !

 

Les avantages d’une équipe full stack

Pourquoi est-il plus judicieux de se concentrer sur la création d’une équipe full stack et non pas sur le recrutement d’ingénieurs full stack ?

« Full stack » est devenu une expression à la mode.

Sur les réseaux sociaux professionnels, beaucoup de personnes se décrivent comme des ingénieurs ou des développeurs full stack. Sur les mêmes réseaux un certain nombre de recruteurs ou professionnels de l’IT publient des offres d’emploi afin de trouver ce genre de profils. En revenant sur ma propre expérience et en m’appuyant sur de nombreuses lectures, j’ai de plus en plus l’impression que le terme « full stack » n’était pas utilisé à bon escient et, qu’en plus, ce n’était pas nécessairement une bonne idée de rechercher des profils « full stack ».

Les vrai profils « full stack » sont presque introuvables

Tout d’abord, il faut définir ce qu’est un profil « full stack » : c’est une personne qui cumule des compétences et de l’expérience sur l’ensemble des technologies IT. Des réseaux, au fonctionnement des infrastructures en passant par toutes les couches des applications jusqu’aux multiples outils qui relient tout cela. (Il en existe une très bonne définition dans l’article « Full Stack Teams, not engineers » publié en 2019 par IT Revolution : https://itrevolution.com/book/full-stack-teams-not-engineers/).

En résumé, c’est une personne avec un CV si complet et riche qu’il sera presque impossible de la trouver. Cet état de fait est vérifié pour les vrais profils full stack et non pas « juste » les développeurs front & back (les bons devs front & Back sont déjà des profils difficiles à trouver soit dit en passant). Et même si les écosystèmes Cloud & DevOps ont grandement facilité la maitrise full stack pour tout le monde, ce genre de profil reste presque impossible à trouver, en clair, ce sont des « licornes » ou des « moutons à 5 pattes » !

Les licornes et les moutons à 5 pattes sont rares !

J’ai lu de nombreuses offres d’emploi en ligne ou reçu des demandes de commerciaux ou bien même de clients qui étaient à la recherche de tels profils et ma réaction est toujours la même : « Comment allons-nous trouver une personne maîtrisant autant de compétences ?! ». Ces demandes de profils me font sourire et je rentre systématiquement en contact avec la personne qui a un tel besoin afin d’en savoir un peu plus. Il faut amener ces demandeurs de profils « full stack » à spécifier leur besoin et comprendre où est la réelle problématique. Souvent, lors des discussions, nous pouvons mettre en lumière d’autres possibilités comme la mise en place d’une équipe ou d’une dispositif plus pertinent.

En effet, les défis en matière de recrutement et de ressources humaines dans le monde IT sont déjà si immenses qu’il n’est pas nécessaire d’ajouter de la complexité dans la recherche des personnes adéquates aux besoins des projets !

Et si vous ne me croyez pas, allez lire l’enquête annuelle de LinkedIn sur les tendances du recrutement (Rapport sur les emplois émergents en 2020 https://business.linkedin.com/talent-solutions/emerging-jobs-report#select-country/two-zero-two-zero).

Que ce soit en France ou aux USA, les postes les plus recherchés se trouvent dans l’IT et, en France, même les postes de recruteurs IT sont très demandés !

Ne créez pas un SPOF (Single Point Of Failure)

Si, finalement, vous parvenez à trouver quelques-uns de ces rares profils et que vous les intégrez dans vos équipes, vous avez peut-être construit un « SPOF » humain….

J’insiste, pour être clair, avoir des personnes dans vos équipes qui maîtrisent l’ensemble des outils techniques de votre SI est un plus car ils sont des piliers de votre modèle opérationnel. Mais, ceci étant dit, ils peuvent devenir un SPOF à l’intérieur de votre équipe plus rapidement que vous ne le pensez.

Ces profils, ces piliers de vos équipes sont l’équivalent de SPOF structurels dans un bâtiment. C’est identique dans les équipes avec de telles licornes, ce sont des points de faiblesse bien connus et cela pour plusieurs raisons. Par exemple :

  • Ce sont des humains donc ils peuvent tomber malade …. Et même s’ils montrent un grand professionnalisme et une profonde implication dans les projets, il se peut qu’ils ne puissent pas répondre aux appels et que vos équipes restent bloquées sans possibilité d’avancer sans leur aide.
  • Ces moutons à 5 pattes sont des trésors à chérir car ces profils sont massivement chassés par les recruteurs. Ils reçoivent quotidiennement des offres très attrayantes et il faut être certain d’avoir le nécessaire pour les garder chez vous dans un contexte marché hyper compétitif (projets, technologies et package salariaux motivants sont de mise).
  • En tant que piliers d’équipe, ils sont sollicités par tout le monde, sur toutes les questions techniques possibles. Ils sont donc constamment confrontés à de multiples sujets différents et peuvent avoir une surcharge de travail. Dans ce cadre, ils sont plus propices au burn-out et donc vous retombez dans le problème 1 cité ci-dessus.

Il apparaît donc clairement qu’en mettant autant de responsabilités sur le dos de ces profils, vous prenez le risque de créer un SPOF au sein de votre organisation.

Evidemment, il existe des cas de figure où vous avez besoin d’un tel profil et de ses connaissances ; afin de démarrer un projet d’envergure par exemple ou pour un audit très spécifique. Mais vous devrez trouver une stratégie rapidement afin de construire un modèle opérationnel plus fiable.

Nous avons besoin de gens pour former une équipe full stack

L’alternative la plus simple et naturelle à ce modèle tentant est de créer des équipes full stack afin de ne plus reposer sur une seule et même personne. C’est l’équipe au complet avec l’ensemble de ses compétences qui couvre tous les aspects de votre stack IT.

Afin d’arriver à une équipe efficiente, voici quelques points très importants à prendre en compte selon mon expérience professionnelle (il n’y a pas d’ordre spécifique) :

  • Identifier les différentes briques de votre stack technique afin de les répartir intelligemment aux différents membres de l’équipe et définir les responsabilités de chacun. Il faut tout de même faire attention à ne pas créer de silos ! Dans ce contexte, être responsable signifie a) être responsable de l’activité à mener (MCO, Design, Build, Run, Dev, …) et surtout b) responsable du partage des informations et des connaissances à l’ensemble de l’équipe.
  • Dans la suite de ce premier point, simplifier et réduire le plus possible votre stack technique en vous appuyant sur les technologies Cloud avec des services comme le PaaS, la conteneurisation, … (En mode Cloud public ou On premise mais il faut simplifier la stack !)
  • Instaurer un modèle d’apprentissage continu qui permet de partager les connaissances avec tous les membres de l’équipe en place. Il existe différentes solutions comme le travail en binôme, des ateliers hebdomadaires où chacun explique ses tâches et missions, des sessions de formation des compétences spécifiques, les « learning dojos » …
  • Equilibrer votre stratégie de recrutement : selon moi, les soft skills sont aussi essentielles que les compétences techniques. Il est important de se concentrer sur la personne qui va rejoindre l’équipe dans sa globalité. Par exemple, lorsque je recrute, je fais particulièrement attention à l’ouverture d’esprit et la curiosité du candidat au-delà de ses connaissances spécifiques. Il est primordial que le futur membre de l’équipe s’intègre et s’intéresse aux métiers des autres. Dans ce cadre, un expert full stack qui ne serait pas capable de parler, de partager, de donner des feedbacks… bref qui ne saurait pas échanger avec une équipe ; ne serait pas retenu lors du processus de recrutement malgré ses compétences techniques.

Pour conclure

Il s’agit ici de mon propre retour d’expérience et de mon avis personnel sur cette envolée des recherches de profils « full stack ». Mais je pense sincèrement qu’il vaut mieux créer des équipes équilibrées que tout faire reposer sur de rares collaborateurs qui maîtriseraient l’ensemble de votre stack IT. Pour moi, le maître mot dans notre contexte technologiquement bouillonnant est vraiment de privilégier l’ouverture d’esprit et le partage de connaissance pour construire des équipes et des organisations apprenantes en permanence !

Le DevOps à succès

Un rapport récent de la compagnie Puppet [ 2019 State of DevOps Report ] analyse les retours d’expériences de transition vers le DevOps pour en tirer les facteurs à succès parmi les pratiques fondamentales et les étapes spécifiques de transformation.

Le rapport met en exergue que ces activités mesurables sont mises en place dans la plupart des transformations à succès et moins dans des entreprises qui n’ont pas ou peu adopté ces méthodes. L’automatisation, la culture et le partage renforceraient notablement l’attraction DevOps. Il est à souligner que ces pratiques sont présentes dans le modèle CAMS datant de 2010 comme des lignes directrices (CAMS pour « Culture, Automation, Measurement and Sharing »).

En fonction de la culture et des pratiques existantes déjà en place dans les entreprises, les chemins vers le concept du DevOps sont multiples. En sondant un panel d’entreprises à différents niveaux de maturité, l’étude montre que les meilleures évolutions s’accompagnent de cinq pratiques que l’on peut considérer comme des fondamentaux qui accélèrent l’adoption DevOps :

  • Une supervision assurée par l’équipe qui opère un produit applicatif ou plateforme (Sur le modèle du « you build it, you run it! »),
  • Des équipes qui contribuent à l’amélioration globale de la démarche via le partage de leurs choix d’outils et/ou de pratiques,
  • Des configurations produits qui sont gérées avec un outil d’automatisation,
  • La réutilisation des patterns de déploiement,
  • La réutilisation des patterns de tests.

Il est facile de constater que la discipline transverse à chaque pratique est le partage :

  1. Superviser soi même permet de communiquer sur l’état de l’application en production et de diffuser une vision qualité du système et du service. Cela active la culture du partage.
  2. Permettre aux équipes de participer à l’amélioration des pratiques amène d’autres façons de travailler ensemble, une communication différente et instaure progressivement une culture du partage autour de leurs contributions.
  3. Enfin, créer des patterns de tests ou de déploiement implique une collaboration plus large, un échange global adopté progressivement.

Quelles plus-values apportent ces pratiques ?

Lorsque l’équipe est capable d’opérer sa plateforme, de définir ses performances, ses indicateurs et ses alertes, elle est plus efficace grâce à la connaissance du produit et réduit les protocoles liés au support. Dans les transformations à succès, les équipes supervisent et définissent des indicateurs tels que les temps de réponse, la consommation en ressources, le prix global, le nombre de commandes réussies,  le nombre de fois qu’une fonctionnalité est utilisée sur un canal…

Réutiliser les routines de tests et déploiement c’est standardiser ce que l’on peut récupérer sur un projet (outils, code, processus). Le pivot entre Dev et Ops est difficile à appréhender et l’utilisation de patterns communs faciliterait l’adoption et la compréhension. Mais le gap de fonctionnement entre ces deux activités est important et c’est là l’un des challenges du DevOps.

A l’image des patterns de déploiements, la réutilisation de patterns de tests est plus difficile en fonction des technologies, du type de tests, de l’activité des équipes…

Une piste pour y parvenir est d’appliquer des processus dans sa propre équipe et de les réutiliser sur un scope plus large. Un cas concret serait de vouloir adopter une démarche TDD (Test Driven Development) pour les Dev et les Ops -car le TDD s’applique à l’IaC (Infrastructure As Code)-, cependant les langages qu’ils utilisent sont très différents (ex. Java en Dev et Ansible en Ops).

Dans certains cas des pratiques ne conviennent qu’à l’un des deux, comme appliquer Scrum pour les développements et Kanban côté opérations. Certaines pratiques comme les tests en production sont plus dures à adopter (par habitude et mesure du risque entre autres). Des patterns s’y prêtent (blue/green/canary) et viennent réduire la complexité de la chaîne d’environnements et donc réduire le coût de fabrication, les temps de livraison, l’effort de maintien et d’évolution… Faire les tests en production n’est pas toujours possible mais cela peut apporter une culture du « run it » et permet de se focaliser sur des sujets à valeur ajoutée (comme le métier). C’est donc fondamental et applicable lorsque les processus sont établis, bénéfiques et maîtrisés.

Utiliser un outil de gestion de configuration est une constante dans les organisations mâtures.

Cette pratique s’est étendue maintenant à l’IaC.

C’est un incontournable qui permet l’automatisation, l’application de processus standards plus sécurisés, la création des alertes, des statistiques… en résumé : la maîtrise et la visibilité.

Cette pratique doit intervenir très tôt dans un projet, dès le début. C’est la clé qui permettra d’accélérer les livraisons et qui favorise la réutilisation de patterns de test ou de déploiement.

Mettre le DevOps en application

Quelques points à prendre en compte lors d’une transformation :

  • Commencer avec une ligne directrice qui pose les bases des futurs développements en cherchant une valeur immédiate.
  • Déterminer la maturité de l’organisation : cela détermine par quoi il faut commencer.
  • Quelles sont les priorités ? (Qu’est-ce qui est nécessaire ?).
  • Des fondamentaux tout de suite : patterns de déploiement, GCL, autonomie sur le monitoring et l’alerting.
  • Les priorités pour ces trois pratiques devraient naturellement se faire sentir. Les résultats sont souvent visibles après leur mise en place (premier palier), avant de pouvoir l’étendre à un périmètre plus large.
  • Après l’adoption : mettre en place les patterns de test et favoriser la contribution et la collaboration pour améliorer les pratiques dans les équipes.
  • Identifier comment fonctionnent les équipes et transformer de façon à obtenir une valeur immédiatement (souvent là où il y en a le plus besoin).
  • Établir et partager une base d’indicateurs. Le faire tôt c’est voir le point de départ et apprécier les évolutions (adopter l’amélioration continue et le feedback continu).
  • Partager les pratiques et processus.  L’automatisation aidera à améliorer l’agilité et à montrer la plus-value sur le produit. Valoriser les personnes favorisera la confiance et l’engagement.
  • Partager et déployer les réussites ! Une équipe a évolué et connaît les pratiques qui fonctionnent. Ici la culture va prendre toute son importance ou va se révéler, d’abord dans l’équipe puis à plus grande échelle.

Pour conclure, le meilleur chemin est celui qui part des pratiques existantes et qui montrera des résultats assez rapidement tout en apportant de la confiance aux managers et aux équipes qui doivent adopter des nouvelles solutions ou une nouvelle organisation. L’automatisation et la standardisation vous permettront de concentrer votre temps sur d’autres sujets qui contribuent au succès de la transformation et, bien entendu, à la qualité des produits mis en œuvre.

Les petits outils du DevOps

Dans une démarche DevOps, développeurs et opérationnels forment une même équipe et ont besoins d’outils. Sans parler des plateformes CI/CD qui sont au cœur de l’écosystème, un DevOps gère des tâches variées comme développer des scripts outils, développer un test en Python, rechercher un bug dans une API, faire un MVP de déploiement, créer un Docker pour générer une documentation… Avant de foncer tête baissée dans le projet, prenons le temps pour s’équiper d’utilitaires qui optimisent le travail au quotidien.

Optimiser son environnement de développement
Il est vrai que côté Ops, l’IDE… c’est vim ou vi ! Optimiser l’environnement de développement passe aussi par l’unification des outils entre les deux mondes. Autant il peut être intéressant pour les développeurs de connaître les utilitaires linux, les Ops découvriront des IDE qui disposent d’options et de plugins pour l’Infrastructure as a Service, le déploiement ou la visualisation de ressources Cloud avec, en général une prise en main intuitive.

Il sera aussi possible d’effectuer des « rechercher/remplacer », analyser des différences, bénéficier d’assistance à la saisie sur différents langages et frameworks (ex. Terraform, XLRelease, YAML, Markdown…), ainsi qu’obtenir une vue globale sur les erreurs et warnings, la vérification de syntaxes, etc. Ces actions peuvent représenter des lignes de commande fastidieuses en Shell maintenant que l’infrastructure as Code gagne en popularité. Un Visual Studio Code -ma préférence en Ops en ce moment-, ou Emacs, ou un dérivé d’IntelliJ ou encore Éclipse dans un contexte Java peuvent standardiser les besoins et méthodes en Dev et Ops en étant utiles pour les deux.

Linux, le couteau suisse de l’automatisation ?
A l’ère de l’automatisation, tout faire au clic au travers des consoles voit vite ses limites. Pour deux raisons : la perte de contrôle du SI et les cas spécifiques si courants chez un grand compte. Connaître les outils d’automatisation et les utilitaires sous Linux peut s’avérer utile car on ne dispose pas toujours d’un outillage étoffé qui nous permet de ne plus se connecter aux machines sans maturité. Ainsi ssh, ls ou tree, sed, find, grep, top ou htop, df, du, lsblk, ip, man, etc s’avèrent très utiles presque au quotidien. Il est également utile de savoir que nous pouvons être efficaces avec seulement un terminal.

jq
Cet utilitaire linux permet de manipuler des fichiers au format JSON en ligne de commande autant en local que sur un pipeline CI/CD. Il permettra de lire, chercher, comparer, transformer les fichiers facilement. Il sera plus pratique pour démêler un gros pavé de 100 000 lignes en un bloc compact.
Découvrir : https://blog.madrzejewski.com/jq-traiter-parser-json-shell-cli/

sed
Parfois on fait ce que l’on peut, pas ce que l’on veut. sed est pratique lorsqu’il faut rechercher ou injecter des valeurs dans un fichier ou une variable (au moment d’un déploiement par exemple). Il pourra compléter un template, trouver des valeurs de paramètre par défaut et les changer. Il pourra aussi contrôler l’intégrité d’un fichier et détecter des modifications imprévues (oui, on peut faire de la sécurité pour pas cher !). Couplé à d’autres utilitaires comme cut, il pourra même supprimer du texte. Attention il faut toutefois l’utiliser avec précaution, les accès concurrents ou les erreurs d’expressions régulières peuvent vider un fichier.

curl
C’est un outil de transfert de fichier qui peut utiliser HTTP et HTTPS. Il peut tester un résultat de requête (couplé avec jq pour JSON et expect pour tester le résultat), vérifier une connexion SSL, une redirection 302, connaître un code HTTP de retour, tester une authentification, une communication entre deux machines, etc. En résumé, tout ce qui relève de la communication, du transfert et de la sécurité des API REST ou HTTP de manière globale. Et ce n’est que la partie visible de l’iceberg en vue de la liste de fonctionnalités qu’il supporte dans le domaine du transfert (svp,ssh…).

awk
Ou gawk, c’est un langage de traitement de fichiers très puissant. Il permet par exemple de créer des fichiers templates que l’on modifiera plus tard. Pour un DevOps c’est une alternative pour préparer des fichiers de configuration lors du chargement d’une application.
Découvrir : http://www.linux-france.org/~ohoarau/article/ohoarau/cours-unix-12.htm

Envsubts
Il permet de substituer dans un fichier en entrée des variables d’environnement du système. On obtient une sortie avec les variables du fichier remplacées par la valeur d’une variable en mémoire. C’est un moyen plus élégant que sed ou awk pour adresser des variables dans un template car les commandes sont moins verbeuses. Toutefois, il n’est pas possible de définir des valeurs par défaut.

Il existe également d’autres outils tels que :

OpenSSL
Un jour on vous demande de créer un certificat SSL pour une application ou de générer un pass pour une base de données à chaque déploiement et c’est le bug. Au lieu d’utiliser un site en ligne, OpenSSL peut s’en occuper sur n’importe quel ordinateur tant qu’il est installé. Il peut valider des certificats et générer des mots de passe selon certains critères.

Proxy+
Parfois les environnements de production n’utilisent pas de proxy mais, en local sur le poste d’un développeur, il faut parfois passer au travers et le poste est configuré pour utiliser un proxy automatiquement avec un certificat personnel. Alors certains de vos programmes n’arrivent pas à s’authentifier (ex. Postman). Proxy+ propose un proxy local qui va capter vos requêtes et s’occuper du reste en redirigeant l’ensemble vers le proxy configuré tout en procédant à l’authentification. Il dispose de nombreuses autres options comme le debug pour analyser les requêtes en détail. Dans les logiciels, il faudra configurer le proxy vers proxy+ (http://localhost:3128) et le tour est joué.

Python
Il fait son retour en force. C’est un langage couteau-suisse qui peut à la fois porter une application web micro-service, implémenter des tests de bout en bout ou encore faire des scripts pour du big data et du machine learning.

Git batch
Ce n’est pas seulement un client GIT. En l’installant, vous disposez sous windows d’un environnement Linux… bash ! Une fois installé, des IDE comme Visual Studio Code pourront l’utiliser. Ainsi vous pouvez travailler avec les mêmes outils en local et sur les environnements des applications. D’autres exécutables peuvent apporter un environnement linux comme Cygwin, Msys2, Cmder…

Linter
En fonction du langage ou du format de fichier, les linters permettent de vérifier si le format est conforme à des règles de code ou tout simplement s’il est correctement édité. Par exemple, GitlabCI en propose un sur son écran de pipeline pour vérifier le fichier de configuration gitlab-ci.yaml. Un vrai gain de temps au lieu de lancer un pipeline et d’attendre qu’il plante.

Postman
En surface, Postman peut ressembler à un simple exécuteur de requêtes. C’est en réalité un IDE complet qui gère par projet de la documentation de test, des variables, des authentifications. Il existe aussi une version en ligne de commande pour exécuter les tests, ce qui permet de l’embarquer dans un conteneur et d’utiliser les mêmes fichiers de tests depuis un poste de développeur et depuis GItlabCI ou Jenkins (des campagnes de tests programmables sont disponibles en SaaS avec le compte associé).

DPL
L’idée c’est de déployer depuis GitlabCI ou TravisCI sur des packages de code sur un panel de providers avec le même outil.
Cela peut être intéressant pour éviter de manipuler plusieurs clients cli (aws, azure, heroku…) et de faciliter la compréhension des scripts.

Côté réseau en général le debug n’est pas très « user-friendly ». Sans dire que l’on rendra cette tâche facile et cool, on peut se familiariser avec quelques outils de diagnostics et de vérifications.

Un telnet permettra de vérifier si on atteint une autre machine sur un port donné (TCP uniquement).
netcat (ou nc) a de nombreuses fonctionnalités. Il dépannera pour connaître l’état d’un équipement mais il pourrait très bien servir à transférer des fichiers si vous ne pouvez rien utiliser/installer d’autre.
Dans les deux cas, vous pourrez vérifier si un service est bien démarré, si le système vous refuse l’accès à bas niveau, si les paquets sont rejetés ou si les flux sont bien ouverts et que le destinataire traite la demande.

dig
C’est un moyen simple de vérifier les DNS. Cela accélère le diagnostic lorsque l’on provisionne des zones hébergées comme route53. On peut détecter si une machine arrive à résoudre un domaine et que ce domaine est bien résolu par le ou les serveurs DNS souhaités.
Quelques exemples : https://waytolearnx.com/2019/05/7-exemples-avec-la-commande-dig-pour-interroger-dns.html
Utilisation : https://www.system-linux.eu/index.php?post/2009/04/23/La-commande-dig

tcpdump et netstat
Ces utilitaires réseaux permettront d’être tout terrain lors d’un état de crise déclaré. Tcpdump va permettre d’observer les paquets qui circulent sur le réseau d’une machine histoire de détecter des comportements anormaux ou savoir si deux machines peuvent se voir. Pour un diagnostic plus poussé, Netstat prend le relais pour donner du détail sur les composants réseaux et leur états (ports, connexions ouvertes, table de routage).

Cette liste n’est pas exhaustive. Elle est plutôt constituée des outils que j’ai découverts et utilisés Ils rendent plus autonome, plus efficace et sont pour la plupart bien documentés sur la toile. Chacun a de nombreuses fonctionnalités et ils peuvent être parfois complexes et verbeux mais utiliser leurs fonctions basiques est déjà un confort et un premier pas vers une démarche de constituer une boîte à outils qui correspondrait à la fois au Dev et au Ops.

Partagez vos expériences, quels outils utilisez-vous au quotidien ?

A suivre : Un exemple de provision de backend base de données en base :
https://12factor.net/config
http://steveadams.io/2016/08/18/Environment-Variable-Templates.html
https://docs.docker.com/app-template/working-with-template