Comment implémenter le modèle de serveur immuable sans perdre la possibilité de faire des post-mortems?

Le modèle de serveur immuable est une discipline de déploiement favorisant la reproductibilité des déploiements. Elle se caractérise par le fait qu '« un serveur qui, une fois déployé, n'est jamais modifié, est simplement remplacé par une nouvelle instance mise à jour » et la mise en œuvre de cette discipline nécessite une automatisation du déploiement du serveur. Cette automatisation présente de nombreux avantages opérationnels, l'un des plus importants étant de permettre le remplacement rapide et fiable des instances défaillantes dans une infrastructure. Cette automatisation implique également que le déploiement du serveur est décrit par des artefacts logiciels versionnés et fait l'objet d'améliorations itératives.

Un aspect populaire des implémentations de cette discipline est la suppression des méthodes d'accès à distance au serveur une fois qu'il a été lancé (en particulier la suppression de l'accès SSH). La suppression de l'accès à distance est un moyen simple de garantir que la configuration du serveur correspond à la configuration préparée par l'automatisation du déploiement.

Cependant, pour enquêter sur les causes d'une défaillance logicielle dans un post-mortem , s'appuyer sur une surveillance structurée n'est pas toujours suffisant et un accès à distance à la machine peut être nécessaire. Il est courant que la surveillance du serveur ne couvre pas toutes les sources de défaillance ou que la surveillance puisse être altérée par la défaillance du serveur elle-même, ce qui serait probablement le cas si le serveur manque de mémoire ou atteint sa limite de processus.

Comment implémenter le modèle de serveur immuable sans perdre la possibilité de faire des post-mortems?

Tout d'abord, la suppression de ssh sur un serveur immuable ne garantit pas qu'il n'y aura pas de changement, c'est plus qu'étant donné qu'il ne devrait pas être nécessaire de changer quelque chose, vous réduisez la surface d'attaque en supprimant un canal d'accès distant.

Une façon de conserver une sorte d'autopsie est la centralisation des journaux. Il existe une myriade de méthodes pour y parvenir, pile ELK, Splunk, syslog ...

Une autre façon plus grossière de conserver un post mortem pour un serveur immuable est d'avoir un script sur le processus d'arrêt (un serveur immuable en panne serait arrêté et un nouveau tourner pour le remplacer) pour rassembler un vidage de mémoire du programme, un vidage de la mémoire et les envoyer à un système distant pour analyse avec la plupart des journaux.

Le principal avantage de cette solution est que vous ne récupérez que les informations système défaillantes au moment du problème, ce qui permet de rassembler des informations plus volumineuses que de les obtenir périodiquement.

Il est difficile d'être plus précis sur la façon d'y parvenir, chaque distribution a un moyen d'obtenir des choses et je n'ai pas d'exemple générique.

Le fait que vous ne disposiez pas d'un accès SSH ne signifie pas qu'il n'y a aucun moyen d'accéder à la machine. Vous l'exécuterez probablement sur un opérateur de cloud, où vous pourrez également effectuer les opérations suivantes:

• prendre un instantané de la machine. Vous pouvez simplement prendre un instantané de la boîte avant de la détruire, pour une analyse ultérieure.
• accéder à la machine via la console. Vous aurez probablement besoin du mot de passe root pour cela, mais certains fournisseurs de cloud peuvent injecter un mot de passe root aléatoire pour accéder à la console à tout moment.

Il s'agit essentiellement d'un accès "physique" à votre machine, et sera disponible même si vous supprimez d'autres types d'accès. Vous pouvez également limiter ces interfaces.

En dehors de cela, comme @Tensibai l'a dit, la meilleure chose à faire est d'avoir une journalisation et une surveillance appropriées, donc chaque fois que vous devrez faire un post mortem, il y a suffisamment de données disponibles pour le faire.