¿Cómo implementar el patrón de servidor inmutable sin perder la capacidad de hacer autopsias?

El patrón de servidor inmutable es una disciplina de implementación que favorece la reproducibilidad de las implementaciones. Se caracteriza por el hecho de que " un servidor que una vez implementado, nunca se modifica, simplemente se reemplaza con una nueva instancia actualizada " y la implementación de esta disciplina requiere una automatización de la implementación del servidor. Esta automatización tiene numerosas ventajas operativas, una de las más importantes es permitir el reemplazo rápido y confiable de instancias con fallas en una infraestructura. Esta automatización también implica que la implementación del servidor se describe mediante artefactos de software versionados y está sujeta a mejoras iterativas.

Un aspecto popular de las implementaciones de esta disciplina es la eliminación de los métodos de acceso remoto al servidor una vez que se ha lanzado (especialmente la eliminación del acceso SSH). Eliminar el acceso remoto es una manera fácil de garantizar que la configuración del servidor coincida con la configuración preparada por la automatización de la implementación.

Sin embargo, cuando se investigan las causas de una falla de software en una autopsia , confiar en un monitoreo estructurado no siempre es suficiente y podría ser necesario el acceso remoto a la máquina. Es una situación práctica común que la supervisión del servidor no cubre todas las fuentes de fallas, o que la supervisión puede verse afectada por la falla del servidor en sí, lo que probablemente sería el caso si el servidor se queda sin memoria o alcanza su límite de proceso.

¿Cómo implementar el patrón de servidor inmutable sin perder la capacidad de hacer autopsias?

En primer lugar, eliminar ssh en un servidor inmutable no garantiza que no habrá cambios, es más, ya que no debería haber necesidad de cambiar algo para reducir la superficie de ataque eliminando un canal de acceso remoto.

Una forma de mantener una especie de autopsia es la centralización de registros. Hay una gran cantidad de métodos para lograrlo, ELK stack, Splunk, syslog ...

Otra forma más cruda de mantener un post mortem para un servidor inmutable es tener un script en el proceso de apagado (un servidor inmutable que falla sería el apagado y uno nuevo gira para reemplazarlo) para reunir un volcado del núcleo del programa, un volcado de memoria y enviarlos a un sistema remoto para su análisis junto con la mayoría de los registros.

La principal ventaja de esta solución es que solo obtiene información del sistema que falla en el momento del problema, lo que permite recopilar información más grande que obtenerla periódicamente.

Es difícil ser más específico sobre cómo lograr esto, cada distribución tiene alguna forma de obtener cosas y no tengo un ejemplo genérico.

El hecho de que no tenga acceso SSH no significa que no haya forma de acceder a la máquina. Lo más probable es que lo esté ejecutando en algún operador de la nube, donde también puede hacer lo siguiente:

• tomar una foto de la máquina. Simplemente puede tomar una instantánea de la caja antes de destruirla, para un análisis posterior.
• acceder a la máquina a través de la consola. Probablemente necesitará tener la contraseña de root para esto, pero algunos proveedores de la nube pueden inyectar una contraseña de root aleatoria para acceder a la consola en cualquier momento.

Estos son esencialmente acceso "físico" a su máquina, y estarán disponibles incluso si elimina otros tipos de acceso. Sin embargo, también podría limitar estas interfaces.

Aparte de esto, como dijo @Tensibai, lo mejor que puede hacer es configurar el registro y la supervisión adecuados, por lo que cada vez que tenga que hacer una autopsia, hay suficientes datos disponibles para hacerlo.