Beaucoup d’applications critiques ont recours à la très haute disponibilité alors même la base n’est pas solide et conçue de façon à rendre compliquée la maintenance.

De plus, cela induit automatiquement des infrastructures importantes avec plusieurs équipes dédiées qui doivent se relayer jour et nuit.

Comment réduire le risque de panne et limiter la probabilité d’une intervention ?

Et an cas de panne, est-ce qu’un mécanisme ne pourrait pas tenter de relancer automatiquement le service en attendant une analyse plus profonde du problème ?

De nos jours, beaucoup commencent par mettre en place leur environnement de production à l’aide de micro-services dans des conteneurs Docker orchestrés par kubernetes.

Mais pourquoi se compliquer la vie ?

Pour ne pas avoir à supporter et à communiquer avec un SysAdmin qui va essayer de cadrer l’environnement pour éviter les problèmes ensuite ? Ce besoin de mettre à l’écart le SysAdmin est à mon avis l’avantage caché tout en faisant croire que ça permet aux Ops de travailler avec les Devs. Par « travailler », je pense qu’ils veulent dire « travailler tranquillement sans le SysAdmin et inversement ».

Docker est une façon de déployer fonctionnelle et doit être utilisé que lorsque c’est bénéfique réellement.

Le travail sur un environnement de production avec Docker demande de déployer une énergie disproportionnée dans la plupart des cas pour les besoins de l’administration quotidienne. Son entretien demande de faire fonctionner toute une usine.

L’autre problème est que Docker donne trop de facilité de constituer de mauvais sous-système et fonctionne comme une boîte noire depuis le système hôte.

Un Dev n’aura pas la vision d’un SysAdmin et endosse, de fait, la casquette de SysAdmin dans son conteneur.

Le SysAdmin veut :

• mettre à jour le système simplement et relancer les services rapidement
• déployer ou faire évoluer la configuration des services sur plusieurs serveurs à l’aide d’un modèle qui va convenir au type d’application pour mutualiser le travail
• entrer rapidement dans le système pour voir ce qui se passe en cas de besoin
• intervenir sans se poser de question et ne pas se retrouver avec un système fait maison ou différent à chaque conteneur : avoir des environnements hétérogènes (et qui reposent sur des images de base qui sortent d’une source obscure et peu testée)
• suivre et maîtriser le système sur la durée

Je préfère donc garder la maîtrise de la configuration système à l’aide de Puppet et t’inviter à gérer l’évolution de ton application métier, le cas échéant, avec Ansible. C’est une excellente façon de faire travailler le SysAdmin et Dev ensemble pour de vrai. Je t’invite à lire la page Pourquoi utiliser Puppet ?

Avec de bonnes pratiques, il est possible d’atteindre un très bon taux de disponibilité avec une architecture simplifiée. Ce qui permet aussi une intervention plus rapide avec tout administrateur système.