Implementación basada en contenedores
Actualmente existen una variedad de soluciones. Teniendo en cuenta que tenemos métodos de implementación de nube privada, nube de Amazon y máquina física, se utiliza Docker como base de la solución y, en base a esto, elegimos el contenedor adecuado. Al convertirse en la tarea principal, las soluciones comunes son:
Entre varias soluciones, damos prioridad a las herramientas oficiales. En términos generales, las herramientas oficiales y las herramientas nativas son las mismas. En términos generales, las herramientas proporcionadas por el gobierno están más integradas con sus propios servicios nativos y tienen una planificación a más largo plazo. Cuando las herramientas oficiales son insuficientes, pueden ayudar a las herramientas de terceros, por lo que inicialmente decidimos utilizar la herramienta nativa de Docker. Swarm Compose con la ayuda de Mesos se utiliza para ayudar en la implementación de todo el proyecto. Swarm es responsable de la asignación y programación de contenedores de pequeña escala de un determinado módulo funcional, y Mesos es responsable de la programación de recursos de contenedores de gran escala. en la capa más externa de todo el clúster, se puede decir que Mesos es el principal y Swarm es el complemento, porque Mesos es un marco de gestión de recursos relativamente maduro y también tiene un motor de programación muy adecuado. preliminar y puede hacerse cargo de más trabajo de programación a medida que pasa el tiempo.
Presentemos brevemente las herramientas nativas oficiales de Docker:
Hay muchos debates sobre las soluciones de red de Docker y Kubernetes, y las dos primeras son herramientas PAAS relativamente comunes. , como contenedor de herramientas de orquestación de servicios generales, puede tener muchas implementaciones específicas, Docker es solo una de ellas, y la solución Docker libnetwork es de nivel demasiado bajo y no es adecuada para la integración en Kubernetes o CoreOS como complemento general, por lo que ambos Para las soluciones de tipo CNI, para los usuarios, no nos importa mucho cuántos contenedores admite la herramienta. Solo necesitamos saber que contenedores como Docker pueden satisfacer las necesidades de la implementación actual del producto, por lo que todavía nos centramos en. Herramientas Docker. Aunque no son tan generales, resolverían nuestro problema actual de coordinación de servicios.
La herramienta oficial se ve muy bien y la solución es bastante elegante y simple. El problema es que no está lo suficientemente madura para la combinación de Comp Compose y Swarm. de contenedores en diferentes hosts, aún es necesario configurar manualmente la red de todo el clúster Swarm para una implementación de topología compleja o a gran escala. La carga de trabajo no es pequeña, por lo que utilizamos Mesos para la gestión de contenedores o recursos de primer nivel, y la implementación de contenedores de segundo nivel o de pequeña escala se puede implementar en enjambre.
Mesos, como plataforma senior de gestión de recursos, se ha utilizado ampliamente antes de la aparición de Docker. Básicamente, todos los marcos informáticos distribuidos maestro-esclavo admiten el uso de Mesos para la asignación y programación de recursos básicos, como hadoop, storm, spark, etc. Al mismo tiempo, el diseño de Mesos permite que las aplicaciones se ejecuten durante mucho tiempo, ya sea un trabajo por lotes, un trabajo de transmisión o un servicio de aplicación normal, puede acceder a Mesos para solicitar recursos e iniciar su propio contenedor. Los primeros Mesos solo admitían restricciones de recursos en forma de LXC. Después del surgimiento de Docker, Mesos también comenzó a admitir el uso directo de contenedores Docker para ejecutar marcos informáticos específicos. Se puede decir que los dos son competitivos y complementarios.
Se dice que es competencia porque las herramientas que vienen con Docker han podido reemplazar gradualmente algunos escenarios de aplicación de Mesos. Siempre que el motor Docker esté instalado en la máquina, todos los hosts se pueden administrar indiscriminadamente. Por ejemplo, Swarm puede establecerse. Un clúster de servicio simple y administrar el clúster en ejecución también se puede administrar de forma remota utilizando la máquina. Swarm está diseñado para reemplazar un backend de programación específico. Utiliza su propio programador de forma predeterminada y selecciona un host para iniciar el contenedor en función del descubrimiento de servicios. Se puede seleccionar Swarm como su backend de programación a través de la configuración. para que Swarm pueda usar Mesos para volverse más maduro y completo, para que Swarm pueda usar Mesos para ejecutarse. Swarm puede utilizar el mecanismo de programación más maduro y flexible de Mesos para gestionar contenedores. Sobre esta base, Compose puede ejecutar servicios de coordinación en clústeres de Mesos, lo que demuestra que el ecosistema que combina Mesos y Docker es relativamente armonioso en esta etapa.
De esta manera, nuestra solución final está básicamente determinada. Mesos se ejecuta en todos los servidores como la herramienta de programación o administración de recursos del clúster más básica. Spark y otros marcos informáticos ya no se implementan de forma independiente, sino que utilizan Mesos. El contenedor LXC inicial se usa para ejecutar, Swarm usa contenedores Docker para programar a través de Mesos y los archivos Compose se usan para iniciar integraciones adicionales. Los archivos de composición se utilizan para iniciar pilas de servicios más estrechamente acopladas, como los clústeres de Tachyon. Nuestros propios servicios de aplicaciones desarrollados y los clústeres de ACO también se ejecutan en Swarm como pilas de servicios Docker. Por lo tanto, nuestro clúster Mesos actualmente ejecuta los dos marcos informáticos Spark y Swarm, que son responsables de la implementación y la computación distribuida de nuestras aplicaciones y la coordinación de servicios y aplicaciones específicas se completan en Compose. Las aplicaciones complejas individuales requieren procesamiento manual de relaciones. se ejecuta en Mesos en forma de Docker.
Mesos puede agregar nuestras máquinas y usarlas como una sola, ya sea que nuestras aplicaciones o tareas informáticas distribuidas se envíen directamente a Mesos para su programación, reduce la división vertical de los servidores y elimina la necesidad de conceptos como este. Como el clúster Spark y el clúster Hadoop, los trabajos de Spark o Hadoop se realizan directamente en el esclavo Mesos. El esclavo Mesos asigna recursos y ejecuta su propio Ejecutor relacionado con el trabajo, y libera los recursos una vez completada la operación, como si Spark no existiera, por lo que desde una perspectiva superior, el marco Mesos es en realidad un programador más un proceso de procesamiento en tiempo de ejecución. Requiere frameworks como Spark o Storm. Para manejar su propia programación en modo independiente, solo necesita usar la API de Mesos para implementar su propio programador y un Ejecutor específico para iniciar y detener el proceso de procesamiento en tiempo de ejecución. Sin embargo, para nuestras propias aplicaciones, aún debe implementarse como. un Framework. Programador y Ejecutor correspondientes, pero sí, podemos usar programadores listos para usar como Marathon para alojar nuestras aplicaciones y reducir la carga de trabajo requerida para desarrollar el Framework. La ventaja de usar Mesos es que la utilización de recursos es más eficiente, por lo que además de Mesos, no necesitamos clústeres de larga duración. Incluso si hay servicios de larga duración, se ejecutarán en contenedores asignados por Mesos.
Framework = Scheduler Executor
La instalación de Mesos es un poco como un servicio. Aunque las imágenes de Docker pueden reducir la complejidad de la implementación de Mesos, hay dos capas de contenedores. el contenedor Docker Mesos se ejecuta en él, y la otra capa son las tareas de Mesos que se ejecutan en sus propios contenedores Docker.
Si algunas tareas de larga duración necesitan exponer puertos para interactuar con el mundo exterior, los puertos deben exponerse primero al contenedor de nivel esclavo de Mesos y luego a la máquina física más externa. Esto no solo aumenta la complejidad, sino que también afecta. pérdida de rendimiento. No se recomienda utilizar una capa de contenedores Docker para anidar. Con el sistema DCOS de Mesosphere, implementar Mesos en AWS es relativamente simple.
Mesos se ve perfecto, entonces, ¿por qué necesitamos contenedores Docker? No es suficiente usar directamente los contenedores compatibles con el kernel de Linux estándar LXC. En esta solución, esperamos que todas las aplicaciones o distribuciones en ejecución sean los ejecutores. Todas las tareas del marco informático se ejecutan en contenedores Docker. Esto también se debe a la característica principal de Docker. Un contenedor Docker es como un contenedor que contiene todas las dependencias o configuraciones necesarias para ejecutar servicios o tareas. Modificación flexible y, una vez empaquetado, se puede ejecutar en cualquier lugar sin preocuparse por el entorno externo. Por ejemplo, si usa LXC directamente para ejecutar la tarea Ejecutor de Spark, solo necesita proporcionar la dirección del paquete jar de Spark y la configuración relevante. se integrará en ExecutorInfo Se ejecuta en un contenedor Docker, pero es mucho más simple si usa un contenedor Docker. La información requerida para que se ejecute Spark's Executor está toda en una imagen de Docker. Solo necesita llamar al esclavo Mesos y solo necesita. llamar al cliente Docker para iniciar una imagen, que es suficiente para ejecutar un marco. Una determinada tarea, que se ejecuta en un contenedor Docker. Los diversos servicios que desarrollamos nosotros mismos también se organizan en imágenes y finalmente se ejecutan en contenedores Docker. Scheduler solo se basa en Marathon.