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
