Site is under maintenance mode. Please wait few min!
Saltar al contenido

Cómo crear un grupo de contenedores de muelle con Docker Swarm y DigitalOcean en Ubuntu 16.04

marzo 4, 2020

 

Introducción

En un servidor de infraestructura tradicional mutable, los servidores se actualizan continuamente y modificado en su lugar. Ingenieros y administradores que trabajan con este tipo de infraestructura puede SSH en sus servidores, o actualizar los paquetes de versiones anteriores de forma manual, archivos de configuración Tweak sobre una base de servidor-a-servidor, y desplegar nuevo código directamente en los servidores existentes. En otras palabras, estos servidores son mutables; se pueden cambiar después de que se crearon. Infraestructura compuesta de servidores mutables puede por sí mismo ser llamado mutable, tradicional, o artesanal (despectivamente).

Un infraestructura inmutable es otro paradigma de la infraestructura en la que los servidores no se modifican después de que se despliegan. Si algo necesita ser actualizado, fijos o modificados de ninguna manera, los nuevos servidores construidos a partir de una imagen común con los cambios apropiados se aprovisionan para reemplazar a los antiguos. Después de ser validados, que están disponibles para su uso y los viejos son retirados del servicio.

Los beneficios de una infraestructura inmutable incluyen una mayor consistencia y fiabilidad en su infraestructura y un proceso de implementación más simple, más predecible. Se mitiga o evita por completo los problemas que son comunes en las infraestructuras mutables, como servidores de deriva configuración y copo de nieve. Sin embargo, utilizando de manera eficiente a menudo incluye la automatización de despliegue global, servidor rápido aprovisionamiento en un entorno de computación en la nube y soluciones para el manejo de datos con estado o efímeros como troncos.

El resto de este artículo:

  • Explicar las diferencias conceptuales y prácticas entre la infraestructura mutable e inmutable
  • Describir las ventajas de utilizar una infraestructura inmutable y contextualizar las complicaciones
  • Dar una descripción de alto nivel de los detalles de implementación y componentes necesarios para una infraestructura inmutable diferencias

entre mutable e infraestructura inmutable

la diferencia fundamental entre la infraestructura mutable e inmutable es en su política central: los componentes de la antigua están diseñados para ser cambiado después de la implementación; los componentes de este último están diseñados para permanecer sin cambios y, finalmente, ser reemplazado. Este tutorial se centra en los componentes como servidores, pero hay otras maneras de implementar una infraestructura inmutable, al igual que con los contenedores, que se aplican los mismos conceptos de alto nivel.

entrar en más profundidad, existen dos diferencias prácticas y conceptuales entre las infraestructuras mutables e inmutables basadas en servidor.

Conceptualmente, los dos tipos de infraestructura varían mucho en su aproximación a cómo los servidores deben ser tratados (por ejemplo creado, mantenido, actualizado, destruido). Esto se ilustra comúnmente con una “animales domésticos frente a ganado” analogía.

En términos prácticos, la infraestructura mutable es un paradigma de la infraestructura mucho más antiguo que es anterior a las tecnologías básicas, como la virtualización y la computación en la nube, que hacen que las infraestructuras inmutables posible y práctico. Sabiendo esto la historia ayuda a contextualizar las diferencias conceptuales entre los dos y las implicaciones de utilizar uno u otro en la infraestructura de hoy en día.

las dos secciones siguientes hablará de estas diferencias con más detalle.

diferencias prácticas: Abrazando la nube

Antes de la virtualización y la computación en la nube se hizo posible y ampliamente disponible, infraestructura de servidores se centra alrededor de los servidores físicos. Estos servidores físicos eran caros y lentos para crear; la configuración inicial podría tardar días o semanas debido a el tiempo que tomó para ordenar el nuevo hardware, configurar la máquina y, a continuación, instalarlo en un colo u otro lugar similar. infraestructura

mutable tiene su origen aquí. Debido a que el costo de reemplazar un servidor era tan alta, que era más práctico para mantener el uso de los servidores que ejecutan habías durante tanto tiempo como sea posible con el menor tiempo de inactividad posible. Esto significaba que había una gran cantidad de cambios en el lugar para las implementaciones y actualizaciones periódicas, sino también para ad-hoc correcciones, ajustes y parches cuando algo salió mal. La consecuencia de cambios manuales frecuentes es que los servidores pueden llegar a ser difícil de reproducir, haciendo cada uno un componente único y frágil de la infraestructura general.

El advenimiento de la virtualización y bajo demanda / cloud computing representados un punto de inflexión en la arquitectura servidor. Los servidores virtuales son menos caros, incluso a escala, y que podrían ser creados y destruidos en cuestión de minutos en lugar de días o semanas. Esto hizo nuevos flujos de trabajo de implementación y técnicas de gestión de servidor posibles por primera vez, como el uso de las API de gestión de configuración o en la nube para provisión de nuevos servidores de forma rápida, mediante programación, y de forma automática. El costo de baja velocidad y de crear nuevos servidores virtuales es lo que hace que el principio de la inmutabilidad práctica. infraestructuras mutables

tradicionales desarrollados originalmente cuando el uso de servidores físicos dictó lo que era posible en su gestión, y continuó desarrollando la tecnología ha mejorado con el tiempo. El paradigma de la modificación de los servidores después de la implementación sigue siendo común en la infraestructura de hoy en día. Por el contrario, las infraestructuras inmutables fueron diseñados desde el principio que depender de tecnologías basadas en la virtualización para el aprovisionamiento rápido de los componentes de la arquitectura, al igual que los servidores virtuales de computación en la nube.

diferencias conceptuales: Animales vs ganado, los copos de nieve vs Fénix

El cambio conceptual fundamental que el Cloud Computing avanzada fue que los servidores podrían considerarse desechable. Es prohibitivamente poco práctico considerar desechar y reemplazar los servidores físicos, pero con los servidores virtuales, que no sólo es posible sino fácil y eficiente para hacerlo.

Los servidores en infraestructuras tradicionales eran mutables sistemas insustituibles, únicos que tenían que mantenerse en funcionamiento en todo momento. De esta manera, eran como animales domésticos: uno de una clase, inimitable, y tendían a mano. La pérdida de uno podría ser devastador. Los servidores en infraestructuras inmutables, por otro lado, son desechables y fácil de replicar o escala con herramientas automatizadas. De esta manera, son como el ganado: uno de muchos en un rebaño en el que ningún individuo es único o indispensables.

Para citar a Randy Bias, que aplicó por primera vez a las mascotas contra el ganado analogía con el Cloud Computing:

En la vieja manera de hacer las cosas, en que tratamos a nuestros servidores como animales domésticos, por ejemplo Bob el servidor de correo. Si Bob se cae, es manos a la obra. El CEO no puede llegar a su correo electrónico y es el fin del mundo. En la nueva forma, los servidores están numeradas, como ganado en un rebaño. Por ejemplo, www001 a www100. Cuando un servidor se cae, se toma la parte de atrás, disparo, y se sustituye en la línea.

Otra forma similar de ilustrar las implicaciones de la diferencia entre cómo los servidores se tratan es con los conceptos de servidores y servidores de copo de nieve phoenix. servidores

copo de nieve son similares a las mascotas. Son servidores que son administrados por la mano, se actualiza con frecuencia y ajustado en su lugar, lo que lleva a un ambiente único. servidores de Phoenix son similares a los bovinos. Son servidores que siempre se construyen a partir de cero y son fáciles de recrear (o “resurgir de las cenizas”) a través de procedimientos automatizados. infraestructuras

inmutables se hacen casi en su totalidad de ganado o servidores de Phoenix, mientras que las infraestructuras mutables permiten a algunos (o muchos) animales domésticos o copo de nieve de servidores. La siguiente sección discute las implicaciones de ambos. Ventajas

de Infraestructura Inmutable

Para comprender las ventajas de las infraestructuras inmutables, es necesario contextualizar las desventajas de las infraestructuras mutables. Servidores

en infraestructuras mutables pueden sufrir cambios de configuración, que es cuando indocumentado, improvisada cambios hacen que las configuraciones de servidores para convertirse en cada vez más divergentes entre sí y de la configuración revisado, aprobado, y originalmente desplegado. Estos copo de nieve cada vez más como servidores son difíciles de reproducir y sustituir, haciendo las cosas como escalar y recuperarse de problemas difíciles. Incluso replicar cuestiones a depurarlos convierte en un reto debido a la dificultad de crear un entorno de ensayo que coincida con el entorno de producción.

La importancia o necesidad de configuraciones diferentes de un servidor se convierte en claro después de muchas modificaciones manuales, por lo que la actualización o cambiar cualquiera de ellas pueden tener efectos secundarios no deseados. Incluso en el mejor de los casos, hacer cambios en un sistema existente no se garantiza que el trabajo, lo que significa que se basan en los despliegues de este modo el riesgo de no o poner el servidor en un estado desconocido.

Con esto en mente, los principales beneficios de la utilización de una infraestructura inmutables son la simplicidad de implementación, fiabilidad y consistencia, todo lo cual en última instancia a minimizar o eliminar la cantidad de puntos de dolor comunes y puntos de fallo.

estado del servidor bien conocidos y menos fallas de implementación

todas las implementaciones en una infraestructura inmutables son ejecutadas por el aprovisionamiento de nuevos servidores basados ​​en una imagen validado y bajo control de versiones. Como resultado, estos despliegues no dependen del estado anterior de un servidor, y por lo tanto no puede fallar – o sólo parcialmente completa – a causa de ella.

Cuando se aprovisionan nuevos servidores, que puede ser probado antes de ser puesto en uso, reduciendo el proceso de implementación real de una sola actualización para que el nuevo servidor disponible, al igual que la actualización de un equilibrador de carga. En otras palabras, se convierten en los despliegues atómica: o bien se completan con éxito o nada cambia.

Esto hace que el despliegue mucho más fiable y también asegura que el estado de todos los servidores de la infraestructura siempre se conoce. Además, este proceso hace que sea fácil de implantar una distribución azul-verde o liberación continua, es decir, sin tiempo de inactividad. cambios en la configuración o copo de nieve servidores

No

Todos los cambios de configuración en una infraestructura inmutable se implementan mediante la comprobación de una imagen actualizada en el control de versiones con la documentación y el uso de un proceso de implantación automatizado y unificado para implementar servidores de reemplazo con esa imagen. Acceso Shell para los servidores es a veces totalmente restringido.

Esto evita configuraciones complicadas o difíciles de reproducir mediante la eliminación de los riesgos de los servidores de copo de nieve y cambios de configuración. Esto también evita situaciones en las que alguien tiene que modificar un servidor de producción mal entendido, que corre un alto riesgo de error y el tiempo de inactividad que causa o comportamiento no deseado.

entornos de ensayo consistente y fácil escalado horizontal

Debido a que todos los servidores utilizan el mismo proceso de creación, no hay casos extremos despliegue. Este desordenado previene o entornos de ensayo inconsistentes por lo que es trivial para duplicar el entorno de producción, y también simplifica la escala horizontal, permitiendo a la perfección que le permite añadir más servidores idénticos a su infraestructura.

simples de reversión y recuperación procesos

Uso de control de versiones para mantener la historia de la imagen también ayuda con el manejo de los problemas de producción. El mismo proceso que se utiliza para implementar nuevas imágenes también se puede utilizar para volver a rodar las versiones anteriores, la adición de la capacidad de recuperación adicional y reducir el tiempo de recuperación al manipular el tiempo de inactividad.

Inmutable infraestructura Implantación de infraestructuras detalles

Inmutable viene con algunos requisitos y los matices en sus detalles de implementación, especialmente en comparación con las infraestructuras tradicionales mutables.

Técnicamente es posible implementar una infraestructura independiente inmutable de cualquier automatización, herramientas, o principios de diseño de software haciendo la adhesión al principio fundamental de la inmutabilidad. Sin embargo, los componentes por debajo de (más o menos en orden de prioridad) se recomiendan para el sentido práctico a escala: Servidores

  • en un entorno de computación en la nube, u otro entorno virtualizado (como contenedores, aunque que cambia algunos otros requisitos a continuación). La clave aquí es haber casos aislados con el aprovisionamiento rápido de imágenes personalizadas, así como la gestión automatizada para la creación y la destrucción a través de una API o similar. automatización
  • completa de su canal de despliegue entera, idealmente incluyendo la validación de imagen después de la creación. La creación de esta automatización aumenta considerablemente el costo inicial de la implementación de esta infraestructura, pero es un costo por única vez, que se amortiza rápidamente.
  • Una arquitectura orientada a servicios, la separación de su infraestructura en unidades modulares, lógicamente discretos que se comunican a través de una red. Esto le permite aprovechar al máximo las ofertas de cloud computing, que son de manera similar orientada a servicios (por ejemplo, IaaS, PaaS). Un
  • sin estado, la capa de aplicación volátil que incluye servidores inmutables. Todo lo que aquí puede conseguir destruida y reconstruida rápidamente en cualquier momento (volátil) sin ninguna pérdida de datos (sin estado).
  • A persistente capa de datos que incluye: El registro centralizado con detalles adicionales acerca de la implementación de un servidor, como identificación de la imagen a través de una versión o Git comprometen SHA. Dado que los servidores son desechables (y con frecuencia dispuesto de) en esta infraestructura, almacenar registros y métricas externamente permite depurar incluso cuando el acceso está restringido shell o después de un servidor ha sido almacenes de datos destroyed.External para bases de datos y cualquier otro dato con estado o efímeras, como DBaaS / bases de datos en la nube y objeto o bloque de almacenamiento (ya sea nube-proporcionada o autogestionado). No se puede confiar en el almacenamiento local cuando los servidores son volátiles, por lo que necesita para almacenar esos datos en otro lugar.
  • centralizado de registro con datos adicionales sobre la implementación de un servidor, como identificación de la imagen a través de una versión o Git cometer SHA. Dado que los servidores son desechables (y con frecuencia desecharse) en esta infraestructura, almacenar registros y métricas externamente permite depurar incluso cuando el acceso está restringido shell o después de un servidor ha sido destruido. almacenes de datos
  • externas para bases de datos y cualquier otro dato con estado o efímeras, como DBaaS / bases de datos en la nube y objeto o almacenamiento de bloque (ya sea nube-proporcionada o autogestionado). No se puede confiar en el almacenamiento local cuando los servidores son volátiles, por lo que necesita para almacenar esos datos en otro lugar.
  • dedicación por parte de los equipos de ingeniería y operaciones para colaborar y comprometerse con el enfoque. Para toda la sencillez del producto final, hay una gran cantidad de partes móviles en una infraestructura inmutable, y no hay una sola persona sabrán todo. Además, algunos aspectos del trabajo dentro de esta infraestructura pueden ser nuevos o fuera de la zona de confort de las personas, como la depuración o haciendo tareas de una sola vez y sin acceso a una consola. Servidores

en una nube de computación ambiente , u otro entorno virtualizado (como contenedores, sin embargo, que cambia algunos otros requisitos a continuación). La clave aquí es haber casos aislados con el aprovisionamiento rápido de imágenes personalizadas, así como la gestión automatizada para la creación y la destrucción a través de una API o similar. automatización

completa de toda su tubería despliegue , idealmente incluyendo la validación de imagen después de la creación. La creación de esta automatización aumenta considerablemente el costo inicial de la implementación de esta infraestructura, pero es un costo por única vez, que se amortiza rápidamente.

Un arquitectura orientada a servicios , la separación de su infraestructura en unidades modulares, lógicamente discretos que se comunican a través de una red. Esto le permite aprovechar al máximo las ofertas de cloud computing, que son de manera similar orientada a servicios (por ejemplo, IaaS, PaaS). sin estado

Un , la capa de aplicación volátil que incluye servidores inmutables. Todo lo que aquí puede conseguir destruida y reconstruida rápidamente en cualquier momento (volátil) sin ninguna pérdida de datos (sin estado).

A capa de datos persistente que incluye:

    tala

  • centralizada con detalles adicionales acerca de la implementación de un servidor, como identificación de la imagen a través de una versión o Git cometer SHA. Dado que los servidores son desechables (y con frecuencia desecharse) en esta infraestructura, almacenar registros y métricas externamente permite depurar incluso cuando el acceso está restringido shell o después de un servidor ha sido destruido. almacenes de datos
  • externas para bases de datos y cualquier otro dato con estado o efímeras, como DBaaS / bases de datos en la nube y objeto o almacenamiento de bloque (ya sea nube-proporcionada o autogestionado). No se puede confiar en el almacenamiento local cuando los servidores son volátiles, por lo que necesita para almacenar esos datos en otro lugar.

dedicación por parte de los equipos de ingeniería y operaciones para colaborar y comprometerse con el enfoque. Para toda la sencillez del producto final, hay una gran cantidad de partes móviles en una infraestructura inmutable, y no hay una sola persona sabrán todo. Además, algunos aspectos del trabajo dentro de esta infraestructura pueden ser nuevos o fuera de la zona de confort de las personas, como la depuración o haciendo tareas de una sola vez y sin acceso a una consola.

Hay muchas formas diferentes de implementar cada uno de estos componentes. La elección de uno depende en gran medida de la preferencia y la familiaridad personal, y cuánto de su infraestructura se quiere construir a sí mismo frente a confiar en un servicio de pago. herramientas

CI / CD pueden ser un buen punto de partida para la implementación de automatización de la tubería; Componer es una opción para una solución DBaaS; rsyslog y alces son opciones populares para el registro centralizado; de Netflix Caos Mono, que mata al azar servidores en su entorno de producción, es una verdadera prueba de fuego para su configuración final.

Conclusión

En este artículo se cubrió lo que la infraestructura es inmutable, las diferencias conceptuales y prácticas entre él y el formato antiguo infraestructura mutable, las ventajas de su uso, y detalles acerca de su aplicación.

saber si o cuando se debe considerar mudarse a una infraestructura inmutable puede ser difícil, y no hay nadie claramente definido de corte o inflexión punto. Una forma de comenzar es poner en práctica algunas de las prácticas de diseño recomendados en este artículo, al igual que la gestión de configuración, incluso si todavía está trabajando en un entorno de gran parte mutable. Esto hará una transición a la inmutabilidad fácil en el futuro.

Si usted tiene una infraestructura con la mayor parte de los componentes anteriores y usted se encuentra golpeando cuestiones de escala o sentimiento frustrado con la clunkiness de su proceso de despliegue, que puede ser un tiempo bueno para comenzar a evaluar cómo una inmutabilidad podría mejorar su infraestructura.

Puede aprender más de varias empresas (incluyendo Codeship, Chef, Koddi, y fuga) se ha escrito sobre sus implementaciones de infraestructura inmutable.