Blog

Si les grandes structures (les fameux « grands comptes ») ont bien un avantage sur les petites startups, c’est l’absence de peur quant à leur avenir à court terme. Les fonds propres étant suffisants, tenter quelque chose et échouer passe simplement en « pertes et profits » et on passe à autre chose. Ce n’est pas le cas pour les petites boîtes. Ces dernières n’ont pas le luxe de rater puis recommencer ; bien souvent, un mauvais choix met en jeu la survie même de l’entreprise.

Habituellement, les tâches Ansible sont séquentielles et indépendantes entre elles. Cependant, il arrive parfois qu’on ait besoin de les regrouper, pour gérer les erreurs en une fois ou conditionner plusieurs tâches. C’est ce dernier cas qui va nous occuper aujourd’hui, car il y a une subtilité à connaître pour ne pas se laisser surprendre. Et le moins qu’on puisse dire, c’est qu’elle est drôlement piégeuse. Chez Ansible, toute tâche peut être conditionnée :

Il y a quelques années, alors que je présentais une pile conteneurisée sur laquelle je travaillais à un confrère, celui-ci m’a affirmé avec aplomb : « tu ne passeras jamais de Docker Compose à Kubernetes ». Bien sûr, ce qui est affirmé sans preuve peut être nié sans preuve1, mais cette phrase est révélatrice d’une réflexion insidieuse dans le monde informatique. Aussi, étudions-la de plus près pour révéler ce qui s’y cache.

De nombreuses questions traversent la conception d’une API : quel protocole ? avec quelle sécurité ? quelles sont les actions possibles, avec quelles informations et sur quelles ressources ? Chaque réponse doit être intégrée au code et dûment documentée pour aider le consommateur à savoir comment interagir avec l’applicatif. Ça ne paraît rien comme ça, mais cette documentation est un enjeu central : si l’on dit qu’une API est aussi bonne que sa documentation, c’est qu’elle est la condition du succès de l’API elle-même.

Comme gestionnaire de conteneurs, Portainer est un outil très pratique. En présentant une interface graphique agréable à l’œil, il permet à des équipes non techniques de consulter et d’influencer des piles logicielles conteneurisées. Pour les techniciens, ce genre d’outil garantit l’acceptabilité de la solution « conteneur » et, in fine, facilite l’adoption de la méthode DevOps. Mais son pilotage des cycles de vie des logiciels via GUI nous condamne-t-il à sacrifier la gestion via la ligne de commande ?

Arrivé à la fin des années 2000, le DevOps est l’un de ces termes qui ont explosé dans le marché de l’IT Web. Depuis, il semble avoir convaincu les entreprises, au point où une majorité en font ou pensent à en faire1. Dès lors, vu la foule d’offres d’emplois DevOps et l’explosion des salaires2, nous autres techniciens y pensons forcément : Comment prendre le train du changement ? Autrement dit, comment devenir DevOps ?

J’ignore si tous mes confrères et consœurs indépendantes font pareil, mais en tant qu’entrepreneur, je construis les choses doucement, en fonction de ma double contrainte « cadre temps / cadre argent ». En conséquence, même si je me fixe un cap, les événements n’apparaissant jamais de façon spectaculaire et il est difficile de les voir survenir. Pas le temps de s’arrêter, il y a toujours de nouvelles briques à ajouter à notre construction ; comme le disait Audiard : « Un intellectuel assis va moins loin qu’un con qui marche », alors je marche.

Passé la toute première connexion (et le potentiel TOFU), l’usage de SSH est lié à un utilisateur : c’est l’utilisateur qui cherche à se connecter pour faire ses opérations sur le serveur distant. Pour cette connexion, on connaît habituellement deux options : le mot de passe et la clé SSH, mais puisqu’un mot de passe ne sera jamais aussi sécurisé qu’une clé SSH, on favorise cette dernière. Mais même elle a des défauts notables.

Un serveur virtuel (ou vhost) est une fonctionnalité offerte par les logiciels de serveur Web permettant de répartir sur un seul serveur applicatif une ou plusieurs applications. C’est peu ou prou le socle d’un reverse proxy : offrir un point d’entrée unique pour protéger l’accès des vraies applications. La configuration d’un tel vhost n’oppose aucune difficulté, mais cette configuration ne suffit pas pour le routage. Comme le dit si bien la documentation d’Apache :

Dans l’illustration de l’article « À quoi joue la sécurisation d’un système d’information », quelque chose a dû vous surprendre : passé la deuxième colonne de classe de caractères, il est plus long de déchiffrer un mot de passe lorsqu’on descend d’un cran vers le bas plutôt que quand on avance d’un cran vers la droite. Autrement dit, il est plus sécurisant de rallonger notre mot de passe plutôt que de le rendre plus complexe.