‫Una de las grandes promesas de los contenedores es que podemos implementar fácilmente nuestras aplicaciones como si fuera un servicio de plataforma, ya
‫sabes, como Heroku o algo así. Podemos hacer eso en cualquier hardware, ya sea en nuestro hardware,
‫es un proveedor de la nube, ya sea virtual o físico. Con Docker, nuestras aplicaciones pueden ejecutarse de la misma manera
‫si son Amazon, Azure, Digital Ocean, Linode, Rackspace, Google Cloud o lo que sea. Sin todas esas características de plataforma, ¿cómo
‫implementamos y mantenemos fácilmente nuestras docenas, o cientos, o incluso miles de contenedores
‫en muchos servidores o instancias? O nodos o gotitas o lo que sea.
‫Eso trae a colación algunos problemas realmente nuevos que anteriormente no eran problemas para las organizaciones pequeñas.
‫se escalan a miles y miles de nodos, y decenas de miles de nodos, y tienen muchos ingenieros.
‫Todos sabemos acerca de Netflix y grandes organizaciones como esa que
‫Pero, si solo tienes un par de personas en tu equipo, o si solo eres un desarrollador en solitario, ¿cómo tomas tus
‫contenedores y los escalas y lidias con todo su ciclo de vida? Desde implementarlos hasta iniciarlos,
‫reiniciarlos, recrearlos, eliminarlos y actualizarlos y todo eso.
‫Comenzamos a hacer preguntas sobre cómo exactamente hace Docker o incluso si hace eso.
‫Algunas de las preguntas que nos hacemos son cosas como, ¿cómo escalar? ¿Cómo escalamos? ¿Cómo nos aseguramos de
‫que nuestros contenedores se reinicien si fallan?
‫¿Cómo reemplazamos esos contenedores cuando realmente tenemos una actualización para ellos? los servidores de la agrupación para incorporar nuevos.
‫Esto es algo que se llama implementar en verde azul hoy en día, lo que significa que
‫no tiene tiempo de inactividad y quita Terminas teniendo siempre algo disponible para
‫que nunca estés realmente deprimido cuando actualizas. ¿Cómo sabemos si tenemos docenas de nodos o incluso solo
‫tres nodos donde comenzamos esos contenedores? ¿En qué nodo está nuestro contenedor? ¿Cómo hablamos a través de esos
‫diferentes nodos o servidores con nuestra red dentro de los contenedores?
‫Cuando se trata de seguridad, ¿cómo podemos estar seguros de que nuestros contenedores solo se están ejecutando en las
‫máquinas en las que pretendíamos que se ejecutaran?
‫¿cómo almacenamos la información privada que necesitamos para nuestros contenedores, como secretos o contraseñas?
‫Ahora que estamos cambiando las cosas y desplegándolas dinámicamente sobre la marcha,
‫Esto nos lleva a una gran evolución en el alcance de lo que Docker intenta resolver.
‫Cuando las personas me hablan y piensan que Docker es solo un contenedor de tiempo de
‫carga, es cuando realmente menciono Swarm Mode, que es una nueva característica en 2016 que reúne años de comprensión de
‫las necesidades de los contenedores y cómo ejecutarlos en vivo. en producción.
‫es una solución de clúster de servidores que reúne diferentes sistemas operativos o hosts, o nodos, o
‫lo que usted quiera
‫llamarlos, en una única unidad manejable en la que puede orquestar el ciclo de vida de sus contenedores.
‫Por lo tanto, en esencia, Swarm Para que quede claro, no estamos hablando de Swarm, que voy
‫a llamar Swarm Classic, que era un componente adicional de Docker antes de 1. 12 salió. Realmente era un contenedor que se ejecutaría dentro
‫de Docker, que realmente solo tomó
‫los comandos de ejecución de Docker y los repitió en varios servidores.
‫Resolvió algunos problemas, pero no fue realmente a la escala que necesitábamos para resolver realmente el 80% de los casos
‫de cómo va a ejecutar sus contenedores.
‫dockercon 2016, Docker anunció
‫Swarm Kit, que era un conjunto de bibliotecas o un conjunto de herramientas relacionadas con un montón de nuevas características de Swarm.
‫En el verano de 2016, en
‫Luego se metieron bien en el servidor Docker. En todo este curso, en realidad tiene las funciones
‫disponibles para usted en la CLI y en su servidor.
‫Ahora finalmente podemos bucear en ellos.
‫En enero de 2017, 1. 13 salieron, y por supuesto porque Swarm
‫Mode era nuevo en 2016, continuarán haciéndolo mejor en los próximos años.
‫En enero, agregaron características adicionales llamadas Stacks and Secrets, así como otras bonificaciones
‫de las que hablaremos más adelante. Es importante tener en cuenta que Swarm no está realmente habilitado de fábrica.
‫De hecho, en su máquina, no podría usar estos comandos enumerados aquí en este momento. Eso en realidad le daría un
‫error porque Swarm tiene que estar habilitado.
‫Ese era uno de los objetivos del diseño era que ninguno de los códigos
‫Swarm afectaría al daemon Docker existente, y que todas las herramientas y sistemas que ya estaban
‫confiando en Docker, o tal vez tenían su propia orquestación sobre Docker, continuará funcionando y no
‫será
‫interferido por Swarm ahora que forma parte de Docker. cuadros azules que se ven en la parte superior son lo que llamamos Nodos
‫de Administrador, y en realidad tienen una base de datos local en ellos conocida como la Base de Datos de Raft.
‫Algunos conceptos realmente básicos antes de que comencemos a bucear, es que estos
‫Almacena su configuración y les brinda toda la información que necesitan para ser la autoridad
‫dentro de un enjambre.
‫Entonces, lo que tenemos aquí son tres administradores diferentes que se han agregado al enjambre,
‫y todos guardan una copia de esa base de datos y encriptan su tráfico para garantizar la integridad y garantizar la confianza
‫de que son capaces de administrar este enjambre de forma segura. .
‫Debajo, en el verde, tenemos notas de trabajadores. Ahora puedes ver en el concepto de
‫Swarm, ahora tenemos gerentes y trabajadores.
‫Cada uno de estos sería una máquina virtual, o un host físico, ejecutando una distribución de Linux
‫o servidor de Windows.
‫Esto muestra cómo se están comunicando en realidad sobre lo que llamamos el plano de control, que
‫es cómo se envían las órdenes alrededor del enjambre, participando en las acciones. En una vista un poco más complicada, tenemos esta base
‫de datos de consenso de Raft que mencioné, que se replica nuevamente entre todos los nodos.
‫Emiten órdenes a los trabajadores.
‫Los gerentes mismos también pueden ser trabajadores. Por supuesto, puede degradar y promover a los
‫trabajadores y gerentes en los dos roles diferentes.
‫Cuando piense en un gerente, generalmente piense en un trabajador con permisos para controlar el enjambre.
‫Una vez más, los únicos requisitos para cada uno de estos servidores es
‫que estén ejecutando el mismo Docker que ya está utilizando. Con este concepto de enjambre, y estos gerentes, ahora tenemos nuevos conceptos
‫de cómo se ven nuestros contenedores.
‫Entonces, con el comando Docker run, solo pudimos implementar realmente un contenedor.
‫Simplemente crearía un contenedor.
‫Siempre estaba en la máquina con la que hablaba la CLI de Docker.
‫Esa suele ser su máquina local, o tal vez un servidor en el que están conectados. sobre cómo escalar o escalar.
‫El comando de ejecución Docker no tenía conceptos
‫Entonces necesitábamos nuevos comandos para lidiar con eso.
‫De ahí viene el comando del servicio Docker. En un enjambre, reemplaza el
‫comando Ejecutar Docker, y nos permite agregar características adicionales a nuestro contenedor cuando lo ejecutamos,
‫como las réplicas para decirnos cuántas de esas desea ejecutar.
‫Esas son conocidas como tareas.
‫Un solo servicio puede tener múltiples tareas, y cada una de esas tareas lanzará un contenedor.
‫de servicio de Docker Create para hacer girar un servicio de Nginx usando la imagen de Nginx como lo hemos hecho varias veces anteriormente.
‫En este ejemplo, hemos creado un servicio usando la función
‫Pero le hemos dicho que nos gustaría tres réplicas.
‫Por lo tanto, utilizará los nodos de administrador para decidir dónde ubicarlos en el enjambre. Por defecto, trata de
‫extenderlos.
‫Cada nodo obtendría su propia copia del contenedor Nginx hasta las tres réplicas que le
‫dijimos que necesitábamos.
‫Esta es una comprensión rápida y básica de cómo los gerentes trabajan y lo que están haciendo en segundo plano.
‫Todas estas características son nuevas.
‫No es simplemente tomar su comando y ejecutarlo en una API como lo haríamos con un comando
‫de ejecución de Docker.
‫En realidad, hay una API Swarm totalmente nueva que tiene una serie de servicios en segundo plano, como el programador y el despachador,
‫y el asignador y el orquestador, que ayudan a tomar decisiones sobre lo que los trabajadores deberían
‫estar ejecutando en un momento dado.
‫Entonces los trabajadores informan constantemente a los gerentes y les piden un nuevo trabajo.
‫Los gerentes constantemente reparten nuevos trabajos y evalúan lo que les ha dicho que hagan en contra de
‫lo que realmente están haciendo.
‫Luego, si hay alguna reconciliación, harán esos cambios, como por ejemplo, quizás le hayan
‫indicado que desarrolle tres tareas más en ese servicio.
‫Entonces el orquestador se dará cuenta de eso y luego emitirá órdenes a los trabajadores, y así sucesivamente.
‫Con este modo de enjambre, en realidad obtenemos un conjunto de capacidades repleto de funciones que nos permiten utilizar las habilidades existentes
‫de Docker que tenemos para desplegar nuestros contenedores en Internet de manera confiable, y resolver una gran
‫cantidad de problemas. problemas que tendríamos una vez que vayamos
‫a la producción.