¿Qué son los servidores inmutables?


23

Hay algunas preguntas sobre servidores inmutables , como:

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?

44
no es posible mutar
Evgeny

3
@Evgeny: ggggggggggggrrrrrrrrrrrrrrrr, estaba cerca, pero estaba completamente equivocado con mi conjetura muda (por favor, no te rías de mí ...).
Pierre.Vriens


Lamento ser tan directo, pero ¿fue una simple búsqueda en Internet definir "inmutable" tan onerosa? Me parece que la pregunta es más grande que eso, pero buscar el significado de la palabra en lugar de adivinar podría haberle dado una ventaja decente.
Adrian

@Adrian no hay problema en ser contundente (porque sufro ESL, tendría que buscarlo en Google para obtener realmente el significado exacto de contundente). Sin embargo, me pregunto si su son conscientes de esta pregunta meta.SA ? Aparte de eso, preferiría aprender de los expertos de DevOps, en lugar de las alternativas similares a Wikipedia.
Pierre.Vriens

Respuestas:


19

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.


"apaga lo viejo, trae lo nuevo". O si su arquitectura lo permite, abra el nuevo, ajuste el balanceador de carga, apague el viejo. De esa manera, puede hacerlo en cualquier momento que desee, incluso en medio de la hora pico. :)
Tim Malone

Inmutabilidad si de la programación funcional (1960), ahora se está dando cuenta de que no solo reduce los errores (algo que a menudo no le importa), sino que también ayuda con la concurrencia.
ctrl-alt-delor

Realmente estaría interesado en cualquier adición a esta fantástica respuesta sobre cómo los agentes de monitoreo o el software adicional que podría ser difícil de incorporar al original podrían entrar en juego aquí. Por ejemplo, el software de monitoreo APM que tiene que detectar su nuevo entorno de máquina después de la creación y cambiar los parámetros. Estoy explorando SSM y la automatización para implementar esto en AWS, pero he encontrado muy poco para discutir lo inmutable con AMI / imágenes cuando se trata de agentes adicionales que podrían instalarse más adelante.
SheldonH

10

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.


1 Si no contamos las mesas de telar automático u órganos de rodillos como computadoras.


1
Wow, otra explicación interesante, merci! Ahora realmente me estoy metiendo en problemas para decidir qué respuesta marcar como aceptada (paciencia con eso, por favor, y sepan que solo puedo marcar 1 como máximo, aunque en este momento no estoy decidida en absoluto por cuál). .).
Pierre.Vriens

1
Avec plaisir! - Creo que es una buena idea esperar varios días para aceptar una respuesta, esto aumenta las posibilidades de que los usuarios escriban más respuestas.
Michael Le Barbier Grünewald

9

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.


Hm, interesante ... Necesito algo de tiempo para digerir más esto ... ¿Conoces el dicho como "1 respuesta a una pregunta desencadena 10 nuevas preguntas?" ...
Pierre.Vriens

1
Esa práctica de "retroceder" rápidamente a menudo se denomina "Despliegue Azul / Verde" (también rojo / negro, depende de quién haga la llamada).
Evgeny

@Evgeny y, lo peor de todo, también podría llamarse implementaciones A / B, línea borrosa con experimentos A / B. (e incluso peor, cuando este tipo de despliegue, versión múltiple de la misma aplicación, está en vivo para hacer experimentos A / B en lugar de banderas de características)
Tensibai

Siempre me dijeron que las implementaciones azules / verdes eran para la implementación de una actualización de una aplicación existente, NO para el servidor en sí. @Evgeny
Turtle

Sí. Puede intercambiar servidores, contenedores, aplicaciones y otras cosas y aún así llamarlo Azul / Verde . Creo que eso merece sus propias preguntas y respuestas aquí. Solo quería señalar que la forma en que explicaste la reversión en tu respuesta a menudo se llama B / G.
Evgeny

6

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.


Explicación interesante, tal vez quieras mutarlo un poco, si puedes, y si tiene sentido, elaborar algo que creo que está relacionado de alguna manera, es decir, "vaciar" un sistema. Lo que creo es que dejas (más o menos) que alguien "juegue" con algo, y les adviertes por adelantado que (por ejemplo) todas las noches hay algún tipo de restablecimiento a un estado inicial. Parece que la entrada para tal reinicio es ... euh ... lo que iba a decir ... correcto: una cosa tan inmutable que se puede usar para ello.
Pierre.Vriens

2
Ejecutar un servicio que devuelve el servidor a un estado conocido (como Chef / Puppet / Ansible / etc ...), solo significa que no está utilizando un servidor inmutable. en.wikipedia.org/wiki/Promise_theory es genial, pero martinfowler.com/bliki/ImmutableServer.html es aún mejor.
Evgeny

Me estás tomando el pelo, creo, o es más bien "desafiarme" (para tratar de descubrir el límite de preguntas diarias). ¿No hay también en alguna parte una regla SE que diga "solo puedes hacer 50 preguntas en 30 días"?
Pierre.Vriens

0

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.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.