¿Cuál es la mejor herramienta de orquestación de contenedores de Docker Linux, como CoreOS, Serf, Flynn, Maestro, Deis, DC / OS y Dokku? ¿Cuáles son los más maduros? ¿En cuál apostarías?

Varias compañías están utilizando Marathon (mesosphere / marathon, [que ayudé a cocrear]) + Mesos en producción, que también es compatible con Docker (más Tutorial para desarrolladores de Mesosphere Docker en segundo plano). Se ha demostrado que Mesos escala y potencia eficazmente toda la infraestructura de Twitter. Marathon es un marco para la orquestación, que también puede manejar docker. Está en uso, por ejemplo, en eBay (entrega de la solución CI de eBay con Apache Mesos – Parte I), Airbnb, etc.

Otra opción es ir con Kubernetes, que puede ejecutarse como un marco encima de Mesos (mesosfera / kubernetes-mesos). Kubernetes se desarrolló en Google como una capa de orquestación para contenedores. En combinación con Mesos, puede escalar. Tenga en cuenta que Kubernetes / Mesos todavía está en desarrollo temprano.

Otras herramientas:
* ianmiell / shutit (no sé acerca de ninguna implementación de producción)
* coreos / flota (no sé acerca de ninguna implementación de producción)

Entonces, los mencionados hasta ahora son increíbles en diferentes ejes. Depende del tipo de superpoderes que necesite para su propio caso de uso. Permítanme describir (desde mi punto de vista) las ventajas y desventajas de tres de ellos. Y para que revele mi afiliación pronto: trabajo para Apcera. Creamos una plataforma que creo que trae algo a la mesa que los demás no, más sobre eso a continuación:

En ningún orden particular:

1. Apache Mesos: (esta es la versión de código abierto que escuchas porque Twitter, Airbnb, Hubspot y Apple lo ejecutan. Hay una versión compatible comercialmente pero no conozco a nadie que la esté ejecutando, así que no puedo hablar con sus puntos fuertes) No es una herramienta de orquestación de contenedores per se (es más que eso), pero ahora admite Docker de forma nativa. Mesos comenzó como un tejido informático diseñado para permitirle “empaquetar” su centro de datos, es decir, ejecutar de manera óptima diferentes cargas de trabajo en el mismo conjunto de máquinas y aquí es donde realmente brilla. Puede ejecutar varios marcos simultáneamente (Marathon y Chronos son los más conocidos, pero algunas compañías como Hubspot (Singularity) y Apple (Jarvis) han sentido la necesidad de escribir las suyas). Como se ha mencionado, puedes ejecutar Kubernetes en Mesos, pero solo lo he visto cuando alguien ya tenía a Mesos en casa para algo como Hadoop y quería crear un prototipo de la idea de usar Kubernetes. Mesos tiende a funcionar mejor en un solo centro de datos o proveedor de nube a la vez. En el lado negativo, no tiene ningún aislamiento de forma nativa entre las cargas de trabajo desde la perspectiva de la red, por lo que si uno de sus contenedores se abre, los otros son vulnerables porque todos pueden verse de forma predeterminada.
2. Kubernetes – Érase una vez, en los días oscuros, antes de que alguien hubiera oído hablar de los contenedores y Docker ni siquiera era un resplandor en el ojo de dotCloud. Google decidió internamente ejecutar toda su infraestructura en lo que se conoció como contenedores. Para hacerlo, necesitaban un sistema para administrar sus cargas de trabajo. Y así nació Borg. Saltando un montón de historia (incluyendo Omega, que originalmente se suponía que era Borg 2.0 pero terminó siendo descartado para ese propósito), Google decidió comenzar una reescritura de Borg de fuente abierta y no precisa (se parece mucho a Borg, toma en algunas lecciones e ingenieros de Omega, pero omite algunos de los bits específicos de Google e incorpora componentes de otros proyectos de código abierto como Docker) llamados Kubernetes. Kurbernetes oscila en varios frentes. Incorpora mucha de la sabiduría luchada de Borg / Omega. Tiene algunas grandes abstracciones (es decir, las piezas que manipulas en Kubernetes como pods, servicios y etiquetas) que tienen mucho sentido para construir ciertas infraestructuras. Debido a que comenzó como una herramienta de administración de un solo clúster (Google ejecuta N clústeres borg, donde N es un gran número), funciona bien administrando un solo clúster en un único centro de datos / proveedor de la nube. Hay esfuerzos para federar clústeres (Ubernetes), pero todavía están en gran medida en las etapas de planificación, por lo que si desea clústeres en proveedores / centros de datos separados para disponibilidad / confiabilidad, debe girarlos de forma independiente. Kubernetes tiene problemas de aislamiento de red similares a los de Mesos (y de hecho, la creación de redes con Kubernetes es una de las cosas más difíciles de hacer funcionar correctamente). Kubernetes también muestra su linaje en una serie de decisiones de diseño donde puede ver que espera que haya tortugas competentes hasta el final.
3. Apcera Trusted Platform – Sí, prometí mencionar la opinión de mi compañía sobre esta pregunta y por qué nos molestamos en hacer la nuestra. Lo que traemos a la mesa es un sistema que tiene un motor de políticas en su núcleo. Esto es importante desde una perspectiva operativa porque realmente desea poder especificar quién puede ejecutar qué carga de trabajo desde el principio. Esto significa que un grupo de operaciones puede establecer una política para sus equipos de desarrollo dándoles acceso a los recursos que necesitan y esos equipos pueden hacer lo que necesitan sin un constante “¿Madre puedo?”. También puede controlar las cosas (porque nuestros contenedores están aislados de forma predeterminada, a diferencia de los anteriores) para que pueda hacer cumplir con seguridad “no permita que las cosas en mi entorno de desarrollo hablen con la producción” o al revés (que a veces puede ser aún más aterrador) de “no dejes que nada en producción dependa del entorno de desarrollo”. También llevamos esto al proceso de implementación para que pueda escribir una política sobre lo que está permitido ejecutar (“solo se puede usar la versión 1.7 de Java” o “no permita que ningún contenedor con CVE desagradables se implemente en producción”). Ah, y hacemos todo esto en múltiples nubes (on / off-prem, nubes públicas y privadas) y con más que solo contenedores. Aquí hay algunas cosas interesantes, te animo a que lo consultes en nuestro sitio web y descargues nuestra edición comunitaria si quieres jugar con él.

Voy a parar aquí porque puedo hablar sobre esto por un tiempo. Lo único que quiero decir que estas tres herramientas tienen en común es que las personas detrás de ellas son súper inteligentes y súper amables, así que no dude en saltar a cualquiera de estas comunidades y hacer preguntas. Todos estamos felices de que estés interesado.

– dNb

Divulgación: trabajo en Google en Kubernetes.

Kubernetes acaba de llegar a 1.0, tiene ~ 9k + estrellas GH y más de 400 colaboradores (a partir de esta publicación). También se ejecuta en todas partes (AWS, GCP, Azure, en Mesosphere, bare metal), se puede alojar (en GKE) y tiene importantes colaboradores externos (CoreOS, RedHat).

Puede comenzar a ejecutar en Kubernetes con un solo comando, por ejemplo:

Ejecutar kubectl nginx –image = nginx –replicas = 5

También se basa en la forma en que ejecutamos contenedores internamente (aunque eso puede ser negativo :)).

Depende de cómo defina la “mejor herramienta de orquestación”.

Me centraré en dos tecnologías: Kubernetes y Docker Swarm.

Kubernetes usa franela, tiene su propio balanceador de carga, usa etcd, usa una CLI, API y configuraciones que no son las mismas que el motor Docker. Por lo tanto, tiene un costo, especialmente porque es difícil de instalar y configurar. También pasará más tiempo aprendiendo al respecto, ya que su filosofía es diferente de Docker. Pero una vez que todo está configurado, Kubernetes es una muy buena tecnología con muchas características.

Docker Swarm , es fácil de instalar y usar, y ahora está integrado en Docker. Tiene su propio descubrimiento de servicio y la misma CLI que Docker y se puede integrar fácilmente con Docker en el entorno de producción.

Esta es una publicación que publiqué sobre el enjambre incorporado (Docker 1.12): MicroServicios desde el desarrollo hasta la producción usando Docker, Docker Compose y Docker Swarm

Cada tecnología viene con sus ventajas y desventajas, no existe una absoluta, pero todo depende de sus necesidades y del uso de Docker en la producción.

Estoy de acuerdo con lo que dijo David N. Blank-Edelman y me gustaría agregar algunos:

1. Después de haber probado todas estas herramientas, debe elegir la herramienta que se adapte a todos sus casos de uso y asegurarse de que no sea una exageración, ya que la mayoría de las herramientas tienen una curva de aprendizaje asociada y la mayoría de ellas no son interoperables .

2. Otro criterio importante que la gente suele pasar por alto es la extensibilidad y el futuro de la herramienta. Por ejemplo, puede elegir una herramienta, implementar su pila usando eso y quedará obsoleto en un año y no funciona bien / admite las últimas características de Docker. Considere factores como la participación de la comunidad, el conjunto de características, el diseño, etc. al elegir una herramienta.

3. Elija una herramienta que sea genérica: no estoy en contra de las herramientas creadas por compañías específicas como OneOps, Centurion, Helios, etc., pero prefiero elegir algo genérico como Mesos, Kubernetes, CoreOS, etc.

En cuanto a las herramientas, respondo por CoreOS, Mesos, Kubernetes como las he usado en el pasado y Kubernetes es mi elección del lote, ya que es suficiente con todos los criterios antes mencionados.

Este es mi favorito, porque es mío 🙂
Documentos:
Implementaciones complejas de Docker simplificadas
Github
ianmiell / shutit
En resumen, su propósito es permitir compilaciones complejas pero repetibles enraizadas en el paradigma de la línea de comandos. Cada módulo tiene un ciclo de vida y se puede conectar con otros módulos como lego, pero aún permite la gestión de dependencia y los ciclos de prueba, etc. Lo usamos ampliamente en nuestra empresa (OpenBet) pero es de código abierto.

Trabajo en ReactiveOps donde nos especializamos en DevOps-as-a-Service. Nuestro fundador, Matt Rogish lo expresa mejor:

Kubernetes es el futuro

“Kubernetes es un marco fenomenal de próxima generación que puede ejecutar cualquier carga de trabajo. Proporciona un excelente DUX, la tasa de innovación se está acelerando y tiene el compromiso de Google detrás, por lo que no va a ninguna parte. Con Kubernetes, nuestros clientes pueden tener su propio Heroku ejecutándose en su propia nube de Google, AWS o entorno local. Incluso pueden implementar sus propias aplicaciones en él sin nuestra ayuda.

Kubernetes incluye muchas decisiones arquitectónicas inteligentes que facilitan la estructuración de aplicaciones dentro de la contenedorización. Y muchas cosas permanecen bajo su control. Por ejemplo, puede decidir cómo configurar, mantener y monitorear diferentes grupos de Kubernetes, así como cómo integrar esos grupos en el resto de su infraestructura basada en la nube.

Es una solución elegante, estructurada y del mundo real para la contenedorización a escala que resuelve desafíos clave que otras tecnologías no abordan. Cuenta con más de 1.6 millones de líneas de código por más de 1,000 contribuyentes “.

Espero que esto haya sido útil. Si desea obtener más información sobre Kubernetes, puede leer la publicación completa del blog: La décima regla de la infraestructura basada en la nube

Divulgación: trabajo en Morpheus

Creo que Morpheus es la mejor opción porque no está restringido a los contenedores Docker.

Morpheus es ideal para orquestar Docker, pero también puede orquestar máquinas virtuales y administrar toda su nube híbrida.

Descubrimos que la mayoría de las compañías establecidas están tratando de pasar a los contenedores, pero aún tienen un montón de máquinas virtuales e infraestructura heredada.

Morpheus está ganando terreno rápidamente, y recientemente hemos abordado algunos clientes más grandes, incluidos Hightail y Ulta Beauty.

Puede obtener más información aquí: Morfeo | Gestión y organización de aplicaciones en la nube para nubes híbridas

Aquí está el nuestro: newrelic / centurion. Es un motor de despliegue para imágenes acoplables en un registro, modelado a partir de Capistrano. Usamos Quay como nuestra fuente de repositorio de imágenes, y los desarrolladores crean sus imágenes en sus computadoras portátiles o en AWS.

El motor de programación más prometedor se parece a la mesosfera / deimos. Centurion, como Capistrano, solo admite una lista estática de servidores acoplables para ejecutar una imagen, mientras que Mesos permitiría la programación de contenedores en el centro de datos.

¿Por qué las grandes empresas tecnológicas se trasladan a contenedores?

Visite cualquier conferencia relacionada con el desarrollo de software y la tecnología hoy y seguramente escuchará sobre los contenedores. Hace solo unos años, las grandes compañías estaban discutiendo las cosas increíbles que las máquinas virtuales podían hacer. Hace poco más de un año comenzaron a hablar de contenedores. Y hoy, todos se preguntan qué son los contenedores y por qué estas compañías se obsesionan tanto con ellos. Si no ha escuchado el término contenedor, debe haber escuchado sobre Docker.

Docker ha hecho posible que estas grandes empresas ejecuten sus aplicaciones en partes y en el entorno de la nube. Cuando una aplicación se divide en partes pequeñas y cada parte tiene su propia funcionalidad, el término utilizado para ello es microservicios. Los contenedores han hecho posible que los microservicios se ejecuten en el mismo servidor sin requerir sus propios sistemas operativos.

Esto simplifica aún más las cosas para las grandes empresas tecnológicas. Una gran empresa de tecnología como Microsoft ahora se ha unido a Docker, y ahora planea lanzar un sistema operativo de servidor separado para admitir los contenedores de Windows hechos por Docker.

http://www.mytechlogy.com/IT-blo …

Docker se creó para ser una parte autónoma y lista para implementar parte de una aplicación, incluido el middleware y la lógica empresarial (por ejemplo, una aplicación Spring con un contenedor Tomcat). Esto hace posible implementar rápidamente los componentes de la aplicación, sin embargo, una aplicación típica suele tener una arquitectura de varios niveles con dependencias de nivel entre ellos. Aquí es donde entra una buena herramienta de orquestación.
1) Para cronometrar la creación de los contenedores (es decir, crear los contenedores en el orden de las dependencias), y
2) Proporcionar configuraciones de contenedor y permitir la comunicación entre estos contenedores (es decir, pasar propiedades de tiempo de ejecución y tales entre contenedores).

El complemento Cloudify Docker le permite hacer esto bastante bien (FYI – Soy el líder de la comunidad en Cloudify). Escribiremos bastantes publicaciones de blog (Etiqueta: Docker) sobre esto muy pronto, así que estad atentos.

A partir de abril de 2017, Kubernetes siente que tomará la delantera. Aquí hay una encuesta muy reciente + algunas predicciones: Orquestaciones Docker comparadas: Kubernetes vs Amazon ECS vs Docker Cloud / Swarm / EE / Cloud (PARTE I)

Google lanzó recientemente Kubernetes. http: //googlecloudplatform.blogs …

Actualización (20/10/14): esta pregunta en SO tiene una lista completa (actualizada continuamente): http://stackoverflow.com/a/18287169

Actualización (11/05/14): Mapa mental del ecosistema Docker: http://www.mindmeister.com/38967 …

He probado Kubernetes y Mesos.

Ambos son excelentes para la gestión de orquestación de Docker.

Mesos parece un poco exagerado para

Por otro lado, Kubernetes admite de forma nativa Service Discovery para su aplicación Docker, por lo que no necesita instalar su propio descubrimiento de servicios. (Tengo que usar traefik para maratones mesos)

DCHQ proporciona el marco de composición de aplicaciones más avanzado para contener aplicaciones empresariales complejas y una funcionalidad completa de administración del ciclo de vida de la aplicación bajo una capa de gobierno que aplica controles de acceso granulares a través de recursos informáticos, plantillas de aplicaciones y contenedores en ejecución. Obtendrá acceso a un conjunto de plantillas de aplicaciones listas para usar para Java, Ruby, Python, PHP, WordPress y Mongo Clusters.

Puede registrarse para obtener una cuenta gratuita en htto: //dchq.io. Estamos ejecutando una prueba gratuita de 3 meses y puede obtener hasta 8 GB de memoria.

Descargo de responsabilidad : soy el fundador de DCHQ, una plataforma de gobierno, automatización de implementación y gestión del ciclo de vida para aplicaciones basadas en Docker.

Rancher es, con mucho, el más fácil de instalar y usar; tiene una excelente interfaz de usuario y todos sus servicios se proporcionan como contenedores Docker, por lo que la instalación de un clúster de múltiples hosts es extremadamente fácil. Por el contrario, el procedimiento de instalación de Mesos y Kubernetes es abrumador.

Asegúrese de consultar la excelente herramienta de orquestación DCHQ Cloud Application Platform con características muy útiles como su sistema de plantillas YML (basado en Docker compose) y el marco de plug-in que se integra con YML. Pruébalo y avísame si puedo ayudarte.

También hay opciones similares, pero están más involucradas para configurar y configurar.

Aclamaciones,
Barra

Ver este artículo le ayuda o no a usar Docker (Contenedores Linux – LXC) en pruebas de escalabilidad y rendimiento para productos NAS

Este artículo El mapa del ecosistema contenedor: desde la perspectiva de un ingeniero, es decir, la pila de pastel de capas trató de dar sentido al paisaje del ecosistema, espero que ayude.