Beaucoup d’applications critiques ont recours à la très haute disponibilité pour ne jamais avoir 1 seconde de panne pour leur application, ce qui induit automatiquement des infrastructures importantes avec plusieurs équipes dédiées qui peuvent se relayer jour et nuit.

Mais est-ce que la base de l’infrastructure permet au moins de réduire le risque de panne ?

Est-ce qu’une panne pourrait se résorber d’elle-même en attendant une analyse plus profonde du problème ?

L’art de complexifier ce qui n’a pas besoin de l’être.

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 ?

Pour ne pas avoir à supporter et à communiquer avec un SysAdmin qui va essayer de cadrer l’environnement pour éviter les problèmes ensuite ? C’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. C’est comme sortir un plat surgelé et le réchauffer. Mais il faut vraiment que la construction de l’image soit absolument sans faille et reconstruite et redéployée à chaque fois qu’il faut changer un élément de l’image et tout relancer.

Docker donne trop de libertés aux Devs (nécessaire en phase de développement et pourquoi pas en début de production s’il n’y a pas de SysAdmin). Donc le conteneur peut contenir n’importe quoi et sera vu comme une boîte noire par le SysAdmin.

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
• 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

Il est possible d’utiliser Docker uniquement, de façon minimaliste si on se limite à des applications sous licence libre livrées telles quelles mais en ayant conscience qu’en cas de problème, ce sera sans doute plus complexe d’intervenir.

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 travaille le SysAdmin et Dev ensemble pour de vrai.

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.