¿Por qué son importantes los contenedores?

Completado

En esta unidad, acompañaremos al equipo de Tailspin mientras analizan algunas de las mejoras acuciantes que su proceso de DevOps requiere. En este escenario, el equipo usa Docker para incluir la aplicación web en un contenedor. Luego, actualiza la canalización de CI/CD para admitir dicha aplicación.

Han sido unas semanas difíciles

Las últimas semanas han sido complicadas en Tailspin. Por una serie de motivos, a los equipos les cuesta llegar a las fechas límite, y en toda la empresa planea la preocupación por la productividad. Andy se ha puesto en contacto con algunos miembros clave del equipo del sitio web de Space Game para recopilar reunir comentarios de cara a una próxima presentación ante el equipo directivo.

Andy: Gracias por venir. Soy consciente de que las últimas semanas han sido difíciles para todos, pero tengo buenas noticias. El equipo directivo se va a reunir mañana fuera de la oficina para oír propuestas sobre qué cambios podemos realizar para mejorar el rendimiento. Me han emplazado para que les presente un caso práctico sobre nuestros logros con DevOps, y afirman que están abiertos también a otras ideas que podamos tener. Podríamos aprovechar que estamos reunidos para hacer una lluvia de ideas. ¿Quién quiere empezar?

Todos miran a Amita, que últimamente ha estado bastante frustrada.

Amita: Empiezo yo. Como sabéis, yo me encargo de realizar pruebas para varios equipos, algo que puede llegar a ser bastante enrevesado porque cada equipo usa su propia pila de tecnología. Incluso cuando utilizan las mismas plataformas subyacentes, como .NET o Java, suelen usar versiones diferentes. A veces, me da la impresión de que dedico la mitad de la jornada simplemente a poner los entornos de prueba en un estado que me permita ejecutar el código que necesito probar. Cuando algo no funciona, me cuesta saber si existe un error en el código o si he configurado por error la versión 4.2.3 en lugar de la 4.3.2.

Andy escribe "Dificultades de control de versiones de dependencia en control de calidad" en la pizarra interactiva.

Tim: Me gustaría decir que el departamento de operaciones siente esa misma frustración. Hay algunos equipos con requisitos de versión únicos, por lo que tenemos que publicar sus aplicaciones en sus propias máquinas virtuales para evitar que esos requisitos de versión y de componente entren en conflicto con otras aplicaciones. Aparte de la sobrecarga que conlleva mantener este conjunto adicional de máquinas virtuales, también nos cuesta más que si esas aplicaciones pudieran ejecutarse en paralelo.

Andy escribe "Sobrecarga por resolver el aislamiento de aplicaciones con máquinas virtuales" en la pizarra interactiva.

Mara: Yo tengo algo que decir sobre la fase de desarrollo. Hace unas semanas, estuve trabajando en el sistema de actualización punto a punto y todo iba bien en mi equipo, pero cuando lo pasé a producción para implementarlo, no funcionaba. Se me pasó que había que abrir el puerto 315 como parte del servicio. Estuvimos un día entero intentando solucionar el problema hasta que nos dimos cuenta de lo que pasaba. En cuanto se lo trasladamos a producción, todo funcionó según lo previsto.

Andy escribe "Discrepancias de configuración entre fases de implementación" en la pizarra interactiva.

Andy: Creo que hemos empezado bien teniendo esta conversación. Dejadme que investigue estas cuestiones para ver lo que puedo hacer. Esto es lo que habéis planteado:

  • Desafíos del control de versiones de dependencia en el control de calidad
  • Sobrecarga por resolver el aislamiento de aplicaciones con máquinas virtuales
  • Discrepancias de configuración entre fases de implementación

Todo en un mismo sitio (un contenedor)

A la mañana siguiente, Andy convoca una reunión para presentar una nueva idea al equipo.

Andy: Ayer hablé con unos compañeros de las dificultades que estamos atravesando y me hicieron algunas sugerencias bastante interesantes. La que estoy deseando probar es Docker, que es una tecnología para empaquetar aplicaciones enteras como contenedores.

Amita: ¿Qué es un contenedor? ¿Como un archivo .zip?

Andy: No exactamente. Es más bien una especie de máquina virtual diseñada para ejecutarse directamente en el sistema operativo host. Al compilar el proyecto, la salida es un contenedor que incluye el software y sus dependencias. Pero no es un sistema virtualizado completo, de modo que puede ponerse en marcha en menos de un segundo.

Tim: ¿Cómo se controla la seguridad y el aislamiento?

Andy: El sistema operativo host se encarga de la seguridad y el aislamiento. Cuando el contenedor se ejecuta en un proceso del host, se aísla de los demás procesos dentro del mismo equipo host. Este aislamiento permite que el contenedor cargue la versión de los componentes que necesite, independientemente de lo que hagan otros contenedores. Esto se traduce también en que se pueden ejecutar varios contenedores fácilmente a la vez en el mismo host.

Amita: Eso está genial para el entorno de producción pero, ¿soluciona las dificultades que tenemos que afrontar en las fases previas de la canalización?

Andy: Totalmente. En lugar de enviar el código fuente o un conjunto de archivos binarios, todo el contenedor se convierte en el artefacto. Es decir, cuando Mara desarrolla, sus sesiones de depuración se ejecutan localmente en el contenedor hospedado en su equipo. Cuando Amita realiza pruebas, lo hace en una copia del mismo contenedor, que ya incluye todas las versiones necesarias de las dependencias. Cuando Tim administra el entorno de producción, los contenedores que supervisa son copias independientes de los mismos contenedores que Mara ha desarrollado y que Amita ha comprobado.

Mara: ¿Es difícil desarrollar una aplicación de contenedor? ¿Hay que hacer cambios importantes en el código ya existente?

Andy: Los contenedores son más bien una tecnología de empaquetado e implementación. No afectan al software fundamental que estamos escribiendo. Simplemente podemos indicar a nuestras herramientas que generen un contenedor de Docker al final de la compilación. Después, al depurar, la aplicación se ejecuta desde ese contenedor local, en vez de en el servidor web local. De hecho, herramientas como Visual Studio permiten cambiar entre entornos de depuración como Docker y IIS Express para poder disponer de la flexibilidad que necesitamos. Sin ir más lejos, anoche bifurqué nuestro proyecto de sitio web y lo he convertido para que se compile como un contenedor de Docker, así probamos el proceso. Y solo tuve que agregar una configuración de contenedor básica, no cambié absolutamente nada del código existente.

Mara: Eso es fantástico. Seguro que hasta podemos actualizar la canalización de versión en Azure Pipelines con tu bifurcación para compilar e implementar la versión de Docker.

Andy: Me lo has quitado de la boca.

¿Qué es Docker?

Docker es una tecnología que automatiza el empaquetado y la implementación de contenedores portátiles y autosuficientes. Los contenedores de Docker se pueden ejecutar en cualquier lugar donde se encuentre un host de Docker, ya sea en una máquina de desarrollo, en el servidor de un departamento, en un centro de datos empresarial o en la nube. Azure proporciona varias maneras de ejecutar aplicaciones basadas en contenedores, como App Service o como parte de clústeres administrados mediante tecnologías de orquestación como Kubernetes.

El equipo de Tailspin ha seleccionado contenedores de Docker en este escenario porque cumplen todo lo que necesitan:

  • Desafíos del control de versiones de dependencia en el control de calidad: las aplicaciones se empaquetan como contenedores que proporcionan las versiones correctas de sus dependencias.

  • Sobrecarga por resolver el aislamiento de aplicaciones con máquinas virtuales: se pueden ejecutar muchos contenedores aislados en un mismo host, lo que reporta ventajas frente a las máquinas virtuales, como un tiempo de inicio más rápido o unos recursos más eficaces.

  • Discrepancias de configuración entre fases de DevOps: los contenedores vienen con manifiestos que automatizan los requisitos de configuración, como qué puertos deben exponerse.

El uso de contenedores de Docker puede ser un paso clave hacia una arquitectura de microservicios. Lo hablaremos con detalle más adelante.

Comprobación de conocimientos

1.

¿Cuál de las siguientes opciones no es un buen motivo para usar Docker?

2.

¿En qué se parecen los contenedores y las máquinas virtuales?

3.

¿Qué nivel de sobrecarga conlleva migrar una aplicación de .NET Core existente para que use un contenedor de Docker?