Nota: (Para afrontar estos apuntes de la Configuración de Servicios en el Modo-Swarm lo haré con los temas que a mi juicio son los que mas interés despiertan en principio (Como configura Puertos) , (Servicios y Red) , (Revertir-Servicios) , (Volumenes en los Servicios) , etc.
Publicar-Puertos
-. Al crear un Servicio-Swarm, se puede Publicar-Puertos de ese Servicio en Hosts fuera del Swarm de dos maneras:
- . Se puede confiar en la Malla-Enrutamiento . Cuando publica un Puerto de servicio, el Swarm hace que el Servicio sea accesible en el Puerto de destino en cada Nodo, independientemente de si hay una tarea para el Servicio ejecutándose en ese Nodo o no. Esto es menos complejo y es la opción correcta para muchos tipos de servicios.
- . Se puede publicar el Puerto de una tarea de Servicio directamente en el Nodo-Swarm donde se ejecuta ese servicio. Esto evita la Malla-Enrutamiento y proporciona la máxima flexibilidad, incluida la capacidad para que desarrolle su propio Marco-Enrutamiento. Es necesario realizar un seguimiento de dónde se ejecuta cada tarea y de Enrutar las solicitudes a las tareas y del equilibrio de carga entre los nodos.
Publica-Puertos con Malla-Enrutamiento
. Para Publicar los Puertos de un Servicio externamente al Swarm, use la ( –publish <PUBLISHED-PORT>:<SERVICE-PORT>) bandera. El Swarm hace que el Servicio sea accesible en el Puerto publicado en cada Nodo-Swarm . Si un host externo se conecta a ese Puerto en cualquier Nodo-Swarm, la Malla-Enrutamiento lo Enruta a una tarea. El host externo no necesita conocer las direcciones IP o los Puertos utilizados internamente de las tareas de Servicio para interactuar con el Servicio. Cuando un proceso se conecta a un Servicio, cualquier Nodo-Worker que ejecute una tarea de Servicio puede responder.
# docker service create –name my_web –replicas 3 –publish published=8080,target=80 nginx
-. Tres Tareas se ejecutan en hasta tres Nodos. No necesita saber qué Nodos están ejecutando las tareas; conectarse al puerto 8080 en cualquiera de los cinco Nodos lo conecta a una de las tres Nginx-Tareas. (En este ejemplo se aprecia perfectamente la diferencia entre Tareas y Servicios).
-. Puede probar esto usando curl. El siguiente ejemplo asume que localhost es el los Nodos-Manager. Si este no es el caso, o localhost no se resuelve en una dirección IP en su host, sustituya la dirección IP del host o el nombre de host que se pueda resolver.
La salida HTML está truncada:
# curl localhost:8080
Nota: Nginx es un servidor Web/proxy inverso ligero de alto rendimiento y un proxy para protocolos de correo electronico. El diagrama que expongo a continuación es una visualización del tema que nos ocupa
Publicar-Puertos en Nodo-Swarm
-. Es posible que el uso de la Malla-Enrutamiento no sea la opción correcta para su aplicación si necesita tomar decisiones de Enrutamiento según el estado de la aplicación o si necesita un control total del proceso para Enrutar las solicitudes a las Tareas de su Servicio. Para Publicar el Puerto de un Servicio directamente en el Nodo donde se está ejecutando, use la (mode=host) opción de la ( –publish) bandera.
-. Si publica los Puertos de un Servicio directamente en el Nodo-Swarm usando (mode=host) y también establece, (published=<PORT>) esto crea una limitación implícita de que solo puede ejecutar una tarea para ese servicio en un Nodo-Swarm determinado. Puede solucionar esto especificando (published) sin una definición de Puerto, lo que hace que Docker asigne un puerto aleatorio para cada tarea. Además, si usa (mode=hosty) no usa la ( –mode=global) bandera (docker service create), es difícil saber qué Nodos están ejecutando el Servicio para Enrutar el trabajo hacia ellos.
Nota: Recordemos que Nginx es un proxy inverso de código abierto, equilibrador de carga, caché HTTP y servidor web.
Recapitulemos: Si ejecutamos Nginx como Servicio utilizando la Malla-Enrutamiento, la conexión al Puerto Nginx en cualquier Nodo-Swarm, muestra la página web en un Nodo-Swarm aleatorio que ejecuta el Servicio.
-. Ejecutar Nginx como un Servicio en cada Nodo-Swarm y expone el Puerto-Nginx localmente en cada Nodo-Swarm:
# docker service create –mode global –publish mode=host,target=80,published=8080 –name=nginx nginx:latest
-. Podemos acceder al servidor Nginx en el Puerto 8080 de cada Nodo-Swarm. Si agrega un Nodo al Modo-Swarm, se inicia una Tarea-Nginx en él. No puede iniciar otro Servicio o Contenedor en ningún Nodo-Swarm que se vincule al Puerto 8080.
Nota: La creación de un Marco-Enrutamiento de la Capa-Aplicación para un Servicio de varios niveles es compleja y este tema se tratara en otro post.
Conectar-Servicio a Red-Overlay
Noata: Es interesante consultar el post referente a las Network-Overlay
-. Utilizar Redes-Overlay para conectar uno o más Servicios dentro del Modo-Swarm. Primero, creare una Red-Overlay en un Nodo-Administrador usando el (docker network create) comando con la ( –driver overlay) bandera (flag) .
- In: root@juan-Aspire-ES1-512:/# docker network create –driver overlay my-network
- Out: 4ezeuy3jj6c8j7r5wlhi1saga
Nota: Después de crear una Red-Overlay en Modo-Swarm, todos los Nodos-Administradores tienen acceso a la red
-. Creamos un Servicio y pasar la ( –network) bandera para adjuntar el Servicio a la Red-Overlay:
- In: root@juan-Aspire-ES1-512:/# docker service create –replicas 3 –network my-network –name my-web nginx
- Out: y9buy2renn9w7pn0vkt763hwl
- Out: overall progress: 3 out of 3 tasks
- Out: 1/3: running [==================================================>]
- Out: 2/3: running [==================================================>]
- Out: 3/3: running [==================================================>]
- Out: verify: Service converged
Nota: El Swarm se extiende (my-network) a cada Nodo que ejecuta el Servicio.
-. Conectar un Servicio existente a una Red-Overlay usando la ( –network-add).
# docker service update –network-add my-network my-web
-. Desconectar un Servicio en ejecución de una Red, usar ( –network-rm)
# docker service update –network-rm my-network my-web
Controlar-Escalar-Ubicacion de Servicos
-. Servicios-Swarm proporcionan algunas formas diferentes de controlar la Escala y la Ubicación de los Servicios en diferentes Nodos.
- .Especificar si el Servicio necesita ejecutar un numero específico de réplicas o debe ejecutarse globalmente en cada Nodo-Worker.
- .Configurar la CPU del Servicio o los requisitos de Memoria , y el Servicio solo se ejecuta en los
Nodos que pueden cumplir con esos requisitos.
.Las Restricciones de Ubicación le permiten configurar el Servicio para que se ejecute solo en Nodos con un conjunto de metadatos específico (arbitrario) y hacer que la implementación falle si no existen los
Nodos adecuados. Por ejemplo, puede especificar que su Servicio solo se ejecute en Nodos donde
(pci_compliant) se establezca una etiqueta arbitraria (true).
. Las preferencias de ubicación le permiten aplicar una etiqueta arbitraria con un rango de valores a cada Nodo y distribuir las Tareas de su Servicio entre esos Nodos mediante un (algoritmo). A diferencia de las Restricciones, las Preferencias de Ubicación son el mejor esfuerzo y un Servicio no deja de implementarse si ningún Nodo puede satisfacer la preferencia.
Servicios-Replicados o Globales
-. El Modo-Swarm tiene dos tipos de servicios: Replicados y Globales.
- .Para los Servicios-Replicados, especifique el número de tareas de réplica que el administrador de Swarm programará en los Nodos disponibles.
- .Para los Servicios-Globales, el programador coloca una tarea en cada Nodo disponible que cumpla con las restricciones de ubicación del Servicio y los requisitos de recursos .
. El tipo de servicio usando ( –mode) bandera (flag). Si no especifica un Modo, el Servicio-predeterminado es replicated. Para los Servicios-Replicados, especificar la cantidad de Tareas de réplica que desea comenzar a usar con la ( –replicas).
# docker service create –name my_web –replicas 3 nginx
-. Para un Servicio-Global con ( –mode global) a (docker service create). Cada vez que un nuevo Nodo está disponible, el planificador coloca una Tarea para el Servicio-Global en el nuevo Nodo. Ejemplo: un Servicio que se ejecute alpine en todos los Nodos del Swarm:
# docker service create –name myservice –mode global alpine
Servicios-Memoria-CPU
-. Para reservar una determinada cantidad de Memoria o número de CPU para un Servicio, los indicadores ( –reserve-memory) o ( –reserve-cpu). Si ningún Nodo disponible puede satisfacer el requisito el Servicio permanece en un estado pendiente hasta que un Nodo apropiado esté disponible para ejecutar sus tareas.
Servicios-Actualizacion
-. Cuando crea un Servicio, puede especificar un comportamiento de actualización continua sobre cómo el Modo-Swarm ejecuta (docker service update). También puede especificar indicadores como parte de la actualización, como argumentos para docker service update. La ( –update-delay) configura el tiempo de retraso entre las actualizaciones de una Tarea de Servicio o conjuntos de Tareas.
Nota: Esto es mas complejo y se sale de estos apuntes de todas formas pongo un ejemplo que ilustra el tema y la posibilidad de consultar la fuentes :
# docker service create –replicas 3 –name my_alpine –update-delay 10s alpine
Servicios-Version-Anterior
-. En caso de que la versión actualizada de un Servicio no funcione como se esperaba, es posible retroceder manualmente a la versión anterior del Servicio usando (docker service update) , ( –rollback). Esto revierte el Servicio a la configuración que estaba en su lugar antes del (docker service update) comando más reciente .
# docker service update –rollback –update-delay 0s
Servicios-Acceso-Volumenes
Recapitulemos: Para obtener el mejor rendimiento y portabilidad, debe evitar escribir datos importantes directamente en la capa de escritura de un contenedor, en su lugar de utilizar volúmenes de datos o enlaces de montaje. Este principio también se aplica a los servicios.
. Los Volúmenes de datos son el almacenamiento que existe independientemente de un contenedor. El ciclo de vida de los Volúmenes-Datos en los Servicios-Swarm es similar al de los contenedores. Los Volúmenes sobreviven a las Tareas y Servicios, por lo que su eliminación debe gestionarse por separado. Los Volúmenes se pueden crear antes de implementar un Servicio, o si no existen en un host en particular cuando se programa una tarea allí, se crean automáticamente de acuerdo con la especificación de Volumen-Servicio.
# docker service create –mount src=<VOLUME-NAME>,dst=<CONTAINER-PATH> –name myservice <IMAGE>
Recapitulemos:
Un resumen básico de Configuracion-Servicios (Puertos) , (Network) , (Escalado) , Volumenes), todos estos temas los tratare en profundidad y otros que se nos quedaron en el fondo del baúl.
Referencias: (Entorno-Moreluz)
Referencias: Documentación-Docker-Python