En el pasado cuando una organización compraba un nuevo servidor, solía instalar el sistema operativo y después instalar cada una de las diferentes aplicaciones que necesitaban, como un web server, una base de datos, el runtime de un lenguaje de programación, librerías, etc. Cada servidor tenía un propósito y se solían desperdiciar muchos recursos. Lo peor de todo es que las aplicaciones debían de ser desarrolladas para hardware y OS específicos, lo que afectaba la portabilidad y escalabilidad de las soluciones.
Luego llegó la virtualización, permitiendo correr múltiples servidores y sistemas operativos sobre el mismo hardware utilizando un hypervisor. Cada servidor cuenta con una imagen que empaqueta tus aplicaciones, dependencias y hasta el sistema operativo base. El problema es que cuando dos aplicaciones viven en la misma VM y comparten dependencias en común, las versiones de las dependencias pueden llegar a variar y romper la funcionalidad de otras aplicaciones. Esto forzó a que cada aplicación tuviera su propia VM y como desventaja terminamos con dos copias del kernel. Si en tu organización tienen cientos de VMs seguramente entiendes el dolor de actualizar tantas copias de un kernel, además del gasto adicional que esto representa.
Finalmente llegó el contenedor, que es una capa de abstracción adicional, esta vez virtualizando el OS. Los contenedores son altamente portables, pues puedes correr un contenedor en cualquier OS que tenga instalado el runtime del contenedor. El inicio y apagado de los contenedores es sumamente rápido, las imágenes de los contenedores son ligeras y esto resulta en mejor utilización de los recursos. Es un nivel adecuado de abstracción y es el siguiente paso en la evolución de administración de código.
Los contenedores también permiten que trabajemos con unidades de despliegue más pequeñas. Esto significa mayor agilidad operacional y menor riesgo al empujar nuevos cambios a tus aplicativos. Te recomiendo que veas este webinar que te enseñará cómo pasar de una arquitectura monolítica a microservicios.
¿Qué es Docker?
Docker es una tecnología que te permite construir, correr y monitorear contenedores. Los contenedores de Docker utilizan Containerd como runtime, hoy en día el estándar de la industria.
Los contenedores usan el concepto de un sistema de capas, similar a los sistemas de versionamiento de código, para reutilizar capas base o comunes entre contenedores. Cuando necesitas actualizar una imagen, únicamente tienes que descargar las diferencias desde la última revisión.
Las instrucciones que definen estas capas están descritas en un archivo base. En el caso de Docker, en un Dockerfile. Cada instrucción presente en este archivo, por lo general, representa una capa adicional para tu contenedor.
Existen repositorios para que guardes de manera segura y escalable las imágenes de tus aplicaciones. Esto te da control de regresar a una versión previa en caso de alguna falla o regresión de funcionalidad. Es muy común que las organizaciones tengan repositorios privados de imágenes en donde almacenan tanto las imágenes base que los aplicativos utilizan (previamente validadas) como las imágenes de cada aplicación desplegada. En la nube de Google puedes utilizar Container Registry.
Puedes desplegar un contenedor de Docker a cualquier host que tenga el runtime instalado, pero es muy común que a medida de que incrementa el número de contenedores a administrar, las organizaciones adopten orquestadores que les aligeren esta labor. El estándar en la industria es Kubernetes, creado por Google y donado como código libre a la CNCF hace unos años. Google continúa liderando el desarrollo de Kubernetes y ofrece una experiencia de entorno administrado, Google Kubernetes Engine, para que te enfoques en la creación de valor y no en la administración de Kubernetes.
En los siguientes módulos del curso aprenderás más sobre el proceso de construcción de los contenedores y de cómo Kubernetes es la base de opciones de cómputo híbrido y multi-nube.
