Blog

Nombre de problèmes traversent la vie de votre startup : un mauvais choix technique ou opérationnel qui plombe la boîte, un bug qui résiste à l’étude, une mauvaise configuration qui vide une base de données ou un crash d’un prestataire¹. Certains seront de votre fait, d’autres seront subis. Mais quand la boîte a fait faillite, à quoi bon faire la distinction ?

Alors que pouvez-vous faire pour que ça ne mette pas en danger la startup ? Comment vous industrialiser pour atténuer les conséquences des mauvais événements qui arriveront tôt ou tard ?

L’accord de niveau de service (ou SLA pour Service Level Agreement) cadre juridiquement la qualité du service que notre entreprise fournit et par voie de conséquence ce que le client est en droit d’exiger en cas de défaillance. Il apparaît dans le contrat quand l’entreprise atteint un tel niveau de qualité technique, organisationnelle et métier qu’elle est en mesure de garantir cela à ses clients. Mais l’officialisation de cette valeur n’est-elle pas un cul-de-sac où l’entreprise finit emprisonnée dans ses propres contraintes ?

À l’instar de son grand frère Apache, le routage du serveur web Nginx s’appuie sur le mécanisme de serveurs virtuels (ou vhosts) afin de gérer plusieurs services / sites à partir d’une même application. On sera tous d’accord, c’est bien pratique. Seulement il arrive que Nginx se comporte bizarrement : parfois, c’est le vhost redwatch.io qui répond à la requête pour… foobar.com. Oui, tu as bien lu. Alors bug, mauvaise configuration ou piège ? Je t’explique tout.

S’il y a bien une question qui revient quand j’explique ce qu’est le DevOps, c’est « ok, mais comment on fait ? ». Parce qu’effectivement, il n’y a pas de bible qu’on suivrait à la lettre, pas de guide ni de méthode ; d’une certaine façon, c’est cela qui constitue le terreau nourricier de la mécompréhension, voire du détournement du terme. Cet article vise donc à proposer une méthode d’initiation du mouvement DevOps, en partant du modèle productiviste habituel.

Fils spirituel du bien connu top, htop est ergonomiquement plus abouti : il y a de la couleur, il est possible de scroller, la présentation est moins austère et l’outil possède tout un tas d’options facilement accessibles. Un outil bien utile pour tout sysadmin. Mais un mystère réside : sur certains systèmes on peut observer dans l’en-tête un « ! » après le nombre de jours de l’uptime. Que peut bien signifier cette information et qu’est-ce que ça dit de nos pratiques ?

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. Inutile de dire que c’est une drôle de pression sur les responsables. Alors, comment une entreprise peut réussir ?

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 preuve¹, 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. Or, la documentation a toujours été le parent pauvre de l’informatique. En format texte, elle est éminemment imparfaite : comme les techniciens trouvent ça ennuyeux et superflu, elle a un vrai risque d’être décorrélée de l’API elle-même… réduisant son intérêt à zéro.

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 ?