‫Actualizaciones de servicio Probablemente siempre ha asumido que hay alguna forma de actualizar sus servicios,
‫aunque todavía no nos hayamos enfocado en eso.
‫Hablemos de ello porque las actualizaciones tienen un montón de cosas bajo las sábanas. La funcionalidad de actualización de Swarm se centra en
‫un patrón de actualización progresiva para sus réplicas. Lo que significa que si tiene un servicio con más
‫de una réplica y, con suerte, lo hará, se transferirá a ellos de forma predeterminada, uno
‫a la vez, actualizando cada contenedor reemplazándolo con la nueva configuración que está poniendo en
‫la actualización. mando.
‫evitan el tiempo de inactividad en las actualizaciones, pero no voy a decir que esto previene el tiempo de inactividad.
‫Mucha gente dirá que los orquestadores
‫Voy a decir que limita el tiempo de inactividad. Porque la prevención del tiempo de inactividad en cualquier sistema es tarea de prueba.
‫Realmente necesitas comenzar a probar cómo haces tus actualizaciones y determinar, ¿impacta a mis usuarios?
‫¿La actualización de una base de datos afecta mi aplicación web? Probablemente sí.
‫Cada aplicación para la que tiene un servicio se actualizará e impactará de manera diferente las otras cosas
‫a su alrededor.
‫Ese no es el trabajo de un orquestador.
‫fácil.
‫Un orquestador no puede determinar si este es un protocolo de base de datos, y este es un protocolo de aplicación
‫REST que es
‫Entonces esas van a ser cosas diferentes y complicadas con las que debes lidiar.
‫En el caso de las actualizaciones de servicios, si solo se trata de una API REST o de una interfaz web que
‫no está funcionando como los sockets web o las encuestas largas, si es algo muy simple como eso o un sitio
‫web estático, es probable que tenga una actualización sencilla y no será un problema esos siempre serán un desafío
‫Pero otros servicios como bases de datos o almacenamiento persistente o cualquier cosa que requiera una conexión persistente. sin importar lo que estés tratando de actualizar. Así que prueba temprano y prueba a menudo.
‫Como dije antes, esto definitivamente reemplazará los contenedores en la mayoría de las actualizaciones. implementará y cambiará cada contenedor por uno totalmente nuevo.
‫A menos que esté actualizando una etiqueta
‫u otros metadatos con el servicio, se
‫Solo prepárate para eso. Tiene muchas opciones. De hecho, el último que conté, había
‫al menos 77 opciones para el comando de actualización. Pero casi todo lo que quieres hacer puede
‫ser ajustado.
‫Muchas de las opciones en el comando de actualización son en realidad crear opciones que simplemente
‫tienen una -rm y una -add al final de ellas. Porque si se trata de una
‫opción que puede usarse para múltiples valores, digamos un puerto para publicar o una variable de entorno, puede usar muchos de ellos.
‫¿Derecha?
‫Por lo tanto, debe poder decirle al comando de actualización cuáles quiere agregar y cuáles eliminar.
‫Veremos eso en un minuto.
‫Esto también incluye opciones de reversión y verificación de estado.
‫Debería mirar las opciones para esos y ver si sus valores predeterminados
‫no son ideales para su aplicación y probar diferentes configuraciones para ver si hace una actualización más fácil para usted y su sistema.
‫También verá que tenemos opciones de escala y retrotracción aquí que ahora son sus propios comandos.
‫convirtiendo en ciudadanos de primera clase en la línea de comando.
‫Solían ser opciones que tenía que especificar con --rollback o --scale,
‫pero mucha gente las ha usado con tanta frecuencia que Docker las está
‫Podrían estar agregando más de esos en el futuro.
‫Por último, antes de llegar a algunos
‫ejemplos, si está haciendo stacks, una implementación de la pila en la misma pila es una actualización.
‫De hecho, no hay una opción separada para las actualizaciones de la pila.
‫Simplemente haces una implementación de pila con el mismo archivo que se ha editado.
‫Luego, funcionará con los comandos de servicio y las redes, y cualquier otra cosa que haga. si son necesarios algunos cambios, se apliquen.
‫Trabajará con ellos para asegurarse de que
‫Veamos algunos ejemplos rápidos y luego llegaremos a la línea de comando.
‫Este es probablemente el ejemplo más común que usará, que
‫es cambiar la imagen de un servicio.
‫Cada vez que actualice su aplicación y construya una nueva imagen, tendrá que hacer un comando de actualización del servicio, con el nombre de la imagen, y luego
‫el nombre del servicio.
‫Entonces, en este caso, tal vez tenía mi aplicación con una etiqueta de 1. 2. 0.
‫Y en este caso ahora estoy aplicando un 1. 2. imagen diferente a la que tengo funcionando en mi servicio, y las actualizaremos.
‫1 imagen, y el servicio
‫determinará, ah sí, esa es una En este próximo, mostramos cómo puedes hacer
‫varias cosas a la vez dentro de un único comando de actualización.
‫Puede agregar una variable de entorno con env-add, y luego puede eliminar
‫un puerto con la publicación -rm.
‫También podríamos agregar y eliminar variables de entorno y publicar puertos en el mismo comando de actualización
‫tanto como queramos. En este último, esto
‫muestra cómo podemos usar estos nuevos comandos de escala y retrotracción en múltiples servicios al mismo tiempo. de usarlos sobre el comando de actualización es que pueden aplicarse a múltiples servicios.
‫Cuál es una de las ventajas
‫En este caso, en realidad voy a cambiar el
‫número de réplicas de la web y los servicios API al mismo tiempo.
‫Como dije hace un rato, en las actualizaciones de Swarm, no tienes un comando de implementación diferente.
‫Es la misma implementación de
‫la pila acoplable, con el archivo que ha editado, y su trabajo es trabajar con todas las
‫otras partes de la API para determinar si se necesitan cambios y luego desplegarlos con una actualización del servicio.
‫Todo bien. Comencemos por crear realmente un servicio para poder manipularlo con algunos comandos de actualización.
‫docker service create -p 8088 80 nombre web, y usaremos Nginx, y vamos a
‫especificar una versión como siempre debemos en producción.
‫Es bueno, ahora que en realidad tenemos en la última mitad de 2017, la opción de separación con nuestro servicio crear y actualizar comandos,
‫podemos ver que esto ocurra sincrónicamente en tiempo real.
‫Por lo tanto, esto será bueno para los comandos de actualización para ver cómo se implementan realmente las actualizaciones a través de la línea de comandos.
‫Todo bien. Ahora, si hacemos un servicio de acoplador ls, vemos que nuestro
‫servicio se está ejecutando y que tiene 1 de 1 réplicas, por lo que está bien.
‫Ahora escalemos nuestro servicio para que podamos tener más réplicas para trabajar. Web = 5.
‫escala de servicio del acoplador Y acabas de ver que uno de esos ya
‫estaba funcionando, y los otros 4 tenían que comenzar. Pasó bastante rápido en el mío porque ya tenía la imagen descargada, pero
‫la suya puede tomar unos minutos mientras están en estado pendiente
‫mientras la imagen se descarga en los otros nodos.
‫Todo bien.
‫Hagamos una actualización continua cambiando la imagen de ese Nginx.
‫Verás aquí que elegí una imagen anterior.
‫Ahora, a Docker no le importa qué es realmente la imagen.
‫Podría ser una aplicación completamente
‫diferente para todo lo que le importa. Simplemente sabe que en este servicio, lo estoy cambiando a una imagen diferente.
‫Recuerde, de forma predeterminada, va a ir de uno en uno.
‫En primer lugar, lo eliminará, creará uno
‫nuevo, y cuando esté listo y se vea saludable, comenzará en el siguiente. En el siguiente ejemplo, vamos
‫a cambiar el puerto publicado.
‫Pero no puedes cambiar un puerto.
‫En realidad, tiene que agregarlos y eliminarlos al mismo tiempo.
‫Entonces, en este caso, debido a que lo
‫publicamos por primera vez con un 8088, necesitamos hacer una actualización de servicio del docker publicitario rm 8088. No necesito especificar el valor. Solo necesito especificar la clave. Luego, publicaremos
‫el nuevo, 9090. Entonces el valor, que en este caso es 80. Verás que hará el mismo proceso de actualización
‫que antes.
‫El último ejemplo del que quiero hablar es una especie de consejo. Porque a menudo tendrás
‫un desafío con algo llamado reequilibrio. O si cambias la cantidad de nodos o si mueves muchas cosas, si tienes muchos contenedores
‫en tu enjambre, es posible que descubras que no están realmente igualados. son muy claros sobre cuántos contenedores están
‫funcionando y otros que tienen mucho.
‫Quizás tengas algunos nodos que Si tiene muchas cosas que cambiar, Swarm no
‫moverá las cosas para mantener todo equilibrado en términos de la cantidad de recursos utilizados.
‫Pero, lo que puede hacer es forzar una actualización de un servicio incluso sin cambiar nada en ese servicio.
‫Luego, volverá a ejecutar las tareas y, en ese caso, elegirá los nodos menos utilizados, lo que es una forma de reequilibrio.
‫Muchas veces en un enjambre más pequeño cuando muevo algo grande, o agrego un montón de nodos,
‫de repente tengo un montón de servidores vacíos sin hacer nada y tengo que trabajar en ellos.
‫Entonces, lo que haré es tomar uno o dos de mis servicios, y haré una actualización del servicio del acoplador: fuerza,
‫y en este caso se implementará y reemplazará por completo las tareas.
‫Por supuesto, utilizará el horario predeterminado de búsqueda de nodos con el
‫menor número de contenedores y el menor número de recursos utilizados.
‫Es una especie de truco para sortear una cantidad desigual de trabajo en sus nodos.
‫Recuerde limpiar eliminando el servicio que creamos en esta conferencia.
‫