¿Qué son los servidores inmutables?

Hay algunas preguntas sobre servidores inmutables , como:

• ¿Cómo implementar el patrón de servidor inmutable sin perder la capacidad de hacer autopsias?
• ¿Qué papel juegan las herramientas de administración de configuración en la infraestructura inmutable?

Parece obvio que tiene que ver con los servidores (esa parte la obtengo). Y simplemente digiriendo la gramática de inmutable , creo que tiene algo que ver con "no es posible silenciar ". Si esa suposición es cercana, no tendría idea de qué es exactamente lo que no se puede silenciar (y dudo que tenga que ver con tarjetas de sonido o algo así ...).

Mis preguntas :

• ¿Qué es en realidad un "servidor inmutable" (en el contexto de DevOps)?
• ¿Por qué se usan?

La inmutabilidad es un término que se usa a menudo en los círculos informáticos, que generalmente se reduce a "no es posible cambiar después de la creación". Normalmente se usa en referencia al paralelismo, concurrencia y seguridad de subprocesos.

La discusión de ese tema es fascinante, pero generalmente se puede encontrar en otro lugar en Stack Overflow . Estoy resistiendo la necesidad de sumergirme aquí. El concepto clave es "no es posible cambiar después de la creación".

Imagínese si, en Amazon, implementa un servicio web convirtiéndolo en una Imagen de máquina (AMI, una instancia preconstruida que puede reaprovisionar repetidamente). Se conecta a una base de datos de back-end a través de credenciales que obtiene de un registro al inicio. Vuelca registros en una herramienta de registro como Splunk. Para el funcionamiento normal del día a día, no tiene ninguna razón para ingresar en este cuadro. Si necesita ampliar ese servicio, simplemente cree más instancias de esa AMI y ajuste un equilibrador de carga. Girarlo es simplemente la destrucción de instancias y equilibradores de carga.

Para la operación diaria, este cuadro no tiene ninguna razón para cambiar . Podemos disparar más fuera del AMI.

¿Qué sucede cuando necesita proporcionar un parche de seguridad a nivel de sistema operativo? Aquí es cuando tiene que tomar una decisión ... ¿hornea una nueva AMI con el parche instalado y vuelve a implementar todas las instancias en ejecución, o ssh en imágenes existentes y actualiza el parche? Hay un montón de gente que simplemente entra. Los partidarios de la 'arquitectura inmutable' me gritaron incluso por sugerir que tal cosa es posible.

Los inmutabilistas (si existe tal palabra) abogan por hornear la nueva ami. Abogan por eliminar toda razón para ssh en una máquina alguna vez. Abogan por que cualquier configuración específica de la máquina se produzca en el inicio de esa máquina extrayendo los detalles de configuración de un repositorio. Esta es la máxima expresión de 'ganado, no mascotas'.

La arquitectura inmutable se refiere específicamente a las configuraciones de la máquina que no tienen motivos para cambiar después de la creación de la imagen de la máquina . Si algo necesita cambiar, hornee una nueva imagen de instancia, apague la antigua, muestre la nueva.

Las tecnologías en la nube cambiaron la frontera entre el hardware y el software de modo que muchas operaciones técnicas que antes eran ciudadanos exclusivos del mundo del hardware también son sujetos del ámbito del software. Los entornos informáticos compartidos pueden ser tan antiguos como las propias computadoras ^1, pero las tecnologías en la nube podrían popularizarlos al ofrecer metáforas convenientes y familiares para interactuar con ellos: los usuarios de la nube reservan una instancia, una computadora completa o una mímica, mientras que los entornos informáticos compartidos más antiguos tienen todos los conjuntos posibles de limitaciones difíciles de manejar y "su programa debe cargarse en ese servidor FTP, se ejecutará en el entorno X (generalmente con una versión anterior de 10 años de cualquier software que quiera usar), durante un máximo de 60 minutos" podría sonar familiar para usuarios anteriores o reales de centros informáticos.

La consecuencia práctica de este cambio es que los procedimientos de implementación ahora pueden ser representados por artefactos de software. (Los procedimientos de implementación son las instrucciones que explican cómo configurar una infraestructura, con bases de datos, servidores web o lo que sea que pertenezca a esta infraestructura, junto con la red en la que se ejecutan). Diseñado con estas nuevas lentes, el mantenimiento manual de los servidores se parece bastante parcheo manual del código de producción, lo cual es solo en muy raras ocasiones algo deseable. El mantenimiento manual es susceptible de introducir discrepancias entre los sistemas que realmente se ejecutan en producción y el código que describe estos sistemas, lo que a su vez significa un comportamiento irreproducible y un análisis de errores imposible, corrección de errores doble y otras calamidades.

El patrón de servidor inmutable es solo la transposición para las operaciones en la nube del mantra anterior, según el cual debemos evitar el mantenimiento manual de los programas en ejecución. En lugar de configurar manualmente los servidores, el patrón de servidor inmutable recomienda automatizar esta configuración.

Implementación de sabores

Si bien la idea general del patrón de servidor inmutable es bastante clara, hay muchos matices de implementación. Por ejemplo, algunos enfoques sugieren no actualizar los servidores, sino reemplazar sistemáticamente los servidores. Esto se debe a que la actualización produce una situación en la que una implementación consiste en servidores que se han iniciado en varios momentos distintos y que han pasado por varios procesos de actualización distintos, lo que implica un conjunto no homogéneo de servidores y puede conducir a diferencias sutiles en la forma en que los servidores manejan sus trabajos. Un segundo punto de variación popular es la disciplina con respecto al acceso remoto a los servidores. A algunos les gusta deshabilitar el acceso administrativo completamente remoto a los servidores, para garantizar que el mantenimiento manual nunca ocurra.

Nota de la historia

Que yo sepa, el término "servidor inmutable" ha sido popularizado por Kief Morris, pero la idea en sí es mucho más antigua. En 1999, las cárceles de FreeBSD ya popularizaron la idea de automatizar completamente la configuración de los entornos informáticos desechables, así es como comencé a implementar el patrón de "servidor inmutable" muchos años antes de escuchar este nombre para describir esta técnica.

La inmutabilidad, bajo la apariencia de inmutabilidad física basada en CD-ROM, también ha sido una medida popular para fabricar sistemas informáticos confiables. Esto no debe confundirse con el patrón de servidor inmutable.

Los servidores inmutables son servidores en los que no se pueden realizar cambios (aparte de las actualizaciones y los parches de seguridad, idealmente). En lugar de cambiar el software en el servidor, coloca un nuevo servidor con el software deseado y luego termina el anterior.

Este concepto ayuda a garantizar que su servidor de prueba, desarrollo y control de calidad sean todos idénticos, lo cual es importante por múltiples razones fuera del alcance de esta pregunta. Otro beneficio de los servidores inmutables es la capacidad de revertir la aplicación a un servidor más antiguo. Por ejemplo, necesito cambiar K en el servidor de producción 1, así que pongo en cola el servidor 2 y cambio K. Ahora, después de 10 minutos, noto que K rompió algo con mi aplicación, en lugar de tener que arreglarlo de inmediato, lo que podría llevar horas y potencialmente causar tiempo de inactividad para mis clientes, redirijo el tráfico de regreso al servidor 1, mientras descubro lo que está mal con 2.

La mejor explicación se puede encontrar (como siempre) en el artículo de Martin Fowler sobre Servidores Inmutables .

Un servidor, ya sea hardware o un servidor virtual en la nube, generalmente tiene un sistema operativo y una aplicación ejecutándose en él.

A menudo, la aplicación y los componentes del sistema operativo requieren configuración y requieren que se apliquen cambios. Por ejemplo, parches de seguridad, implementación de nuevas versiones de la aplicación y cambios de configuración.

Cuando considera que cualquier cambio es una mutación en el estado del servidor, el término immutablecomienza a tener más sentido. Significa que no se permiten mutaciones en dicho servidor.

A menudo es el caso, cuando las personas están involucradas en cambiar el estado del servidor, ya sea un despliegue de una versión, un cambio de configuración o una ruta de seguridad. El resultado es un servidor que ya no funciona como se esperaba. Por ejemplo, la aplicación podría no ejecutarse ahora debido a una configuración incorrecta, etc.

Es por esto que se establece una práctica para crear servidores inmutables . Con los servidores inmutables , se crea una imagen de un servidor con todas las configuraciones, parches y versiones de aplicaciones incluidas. Luego, esa imagen del servidor se puede usar para crear servidores en varios entornos.

El primer entorno en el que se utiliza dicha imagen sería un entorno en el que la imagen pueda probarse para que funcione. Se detectan anomalías, y solo entonces dicha imagen puede promoverse a un entorno de producción para reemplazar los servidores allí con la nueva versión (que se sabe que funciona bien).

Una vez que el proceso de creación de imágenes y promoción de imágenes está automatizado, obtiene un proceso muy a prueba de fallas que involucra muy poco esfuerzo humano y muy pocas posibilidades de introducir fallas en su servicio.

A menudo, los servidores inmutables ni siquiera incluyen ninguna forma de "ingresarlos", como por ejemplo, falta el servidor ssh. En este caso, también es frecuente que toda la metrología de un servidor (métricas, registros) se envíe a sistemas externos, como una base de datos de métricas o un servicio de agregación de registros.

Con los contenedores (ver: Docker ) también hay un proceso para crear imágenes y luego generarlas en contenedores en ejecución. Con frecuencia, estos se reemplazan por nuevos contenedores basados ​​en imágenes actualizadas y nunca se mutan. Lo que significa que ningún humano entra en el contenedor para "arreglar algo" introduciendo un cambio.

Comencemos con lo inverso, ¿qué es un servidor mutable?

Tradicionalmente, una infraestructura de servidor mutable es aquella que se modifica y actualiza continuamente en su lugar. Puede asegurar shell en él, actualizar paquetes, configurarlo, instalar servicios e implementar un nuevo código en él. Esto es lo que lo hace mutable, puede mutarlo o modificarlo.

Una infraestructura inmutable es otro paradigma de infraestructura en el que los servidores nunca se modifican después de su implementación. Si algo necesita actualizarse, repararse o modificarse de alguna manera, los nuevos servidores construidos a partir de una imagen común con los cambios apropiados se aprovisionan para reemplazar los antiguos. Después de que se validan, se ponen en uso y los antiguos se retiran del servicio.

¿Por qué se usan? Los beneficios de una infraestructura inmutable son más consistencia y confiabilidad en su infraestructura y un proceso de implementación más simple y predecible y mitiga los problemas comunes del servidor en la infraestructura mutable, como el tiempo de inactividad del servidor o lo que sea.

Pero debe saber cómo aprovisionarlo de manera eficiente mediante automatizaciones integrales de implementación y un rápido aprovisionamiento del servidor.

Imagine que está extrayendo bitcoin, no desearía ningún tiempo de inactividad si su servidor fallara, necesitaría una copia de seguridad lo más rápido posible, por lo que se supone que una solución inmutable es la solución.