Tes serveurs Debian chez OVHcloud marchent sur des œufs ?
Reprenons l’infogérance et la maîtrise de tes serveurs pour que tu te concentres enfin sur ton cœur de métier, avec confiance.
(et sans laisser ton business dépendre du hasard)
Plus de 25 ans d'expérience avec toujours la simplicité en priorité
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 ÉNORMES avec plusieurs équipes dédiées, et probablement une architecture à l’aide de micro-services dans des conteneurs Docker orchestrés par kubernetes.
Mais surtout…
Beaucoup plus courent après Docker et kubernetes qui sont complètement overkill pour leur besoin !
Ils ne maîtrisent absolument RIEN.
Ils ont succombé à la nouveauté sans comprendre les limites.
Mais à la moindre panne, il faudra des heures ou plus pour intervenir.
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.
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.
Avec une infrastructure solide, il n’y a plus automatiquement besoin d’une équipe dédiée pour veiller sur ton serveur à la bougie.
Et aussi plus de 25 ans à travailler avec le Logiciel Libre
Je travaille uniquement sur une distribution GNU/Linux basée sur Debian et entièrement chiffrée.
Quelle horreur de voir des soi-disant « Experts Linux » travaillant en réalité dans une machine virtuelle, elle-même gérée par un système vulnérable par nature.
Mon système (et celui de mes éventuels partenaires) démarre directement sus GNU/Linux et si j’ai besoin d’un système Windows, ce sera lui qui sera dans une machine virtuelle.
Je travaille depuis plus de 25 ans sur GNU/Linux et j’ai travaillé 10 ans au service de la Recherche française (Inria) pour gérer par exemple une forge logicielle et un cluster de calcul.
Slackware a été installé ma première distribution GNU/Linux, avec *une seule* disquette d’une capacité de 1,47 Mo. À l’époque, je n’avais pas internet depuis mon PC, je me servais donc de cette disquette pour télécharger Slackware à l’université. Je découpais les téléchargements en petit bout pour le faire rentrer sur la disquette et pouvoir les emmener un par un jusque chez moi. (« Oui, l’opération était un peu longue, oui j’ai beaucoup marché »).
Ton business va droit dans le mur 😱 ?
Tu sais que l’état actuel de tes serveurs Linux est sensible au moindre chaos imprévu.
Serais-tu capable de reconstituer un serveur en partant de rien ? (par exemple à la suite d’un incendie ou d’un effacement)
Es-tu vraiment certain de comprendre la configuration actuelle de tes serveurs ?
Une panne peut arriver n’importe quand et le temps d’intervention peut être rallongé s’il n’y a pas une bonne maîtrise.
As-tu l’esprit tranquille de savoir que tout peut s’arrêter du jour au lendemain ?
📜 Est-ce que tu gères tes serveurs à l’aide de mémos ?
Tu as des petites notes sur la configuration utilisée par tes serveurs.
Tu les as préparé au tout début, lors de l’installation initiale du serveur.
Mais avec le temps, tu as commencé à changer la configuration sur les serveurs en essayant, plus ou moins, de mettre à jour le mémo.
C’est là que ça commence à dériver, un mémo qui n’est déjà plus exact. Et au fil du temps, le mémo ne sera plus qu’un document périmé.
Au delà du problème d’obsolescence du mémo, réinstaller un serveur ou autre identique prend plus de temps et on n’est jamais certain de ne pas manquer une étape.
L’installation du serveur n’est plus maîtrisée.
🚧 Ton serveur de prod était-il en fait le serveur de dev ? (au tout départ)
Au départ, on commence par préparer un serveur afin de tester un service ou de chercher la bonne configuration (plus rapide que d’utiliser Puppet ou autre). Puis finalement, le serveur de dev se retrouve promu serveur de prod.
Et cette situation dure depuis longtemps (années ?), le système n’est peut-être plus à jour, une vieille Debian obsolète ?
Chaque moindre changement dans la configuration peut aboutir plus facilement à une panne.
📂 Penses-tu que la sauvegarde est une vraie sauvegarde ?
Et oui, le serveur de prod fonctionne mais il n’y a peut-être aucune sauvegarde incrémentale. (Un simple snapshot automatique n’est pas une vraie sauvegarde).
Parce qu’en plus de réussir à mettre en ligne un serveur de prod stable, mettre une sauvegarde est compliquée.
Parfois, un espace de sauvegarde est fourni par l’hébergeur mais ça ne sert à rien. Il faut pouvoir s’en servir réellement comme stockage de sauvegarde incrémentale.
La sauvegarde doit être distante ou avoir une archive de secours distante chez un hébergeur différent.
Là aussi, c’est une étape nécessaire et je suis conscient que ça devient prise de tête quand on ne sait pas s’y prendre, quel outil choisir,…
Tes services fonctionnent mais reposent sur du sable ?
