Introducción a contenedores

2/20
Recursos
Transcripción

¿Cuál es la evolución histórica de los contenedores?

Conocer la evolución de los contenedores no es solo revisar la historia de una tecnología, sino comprender cómo los sistemas han evolucionado para optimizar el uso de recursos, mejorar la aislación y extender la portabilidad. Esta evolución no solo revela mejoras tecnológicas, sino también soluciones claves para problemas antiguos en la administración de servidores y aplicaciones.

¿Cómo era la situación inicial de las máquinas compartidas?

En los inicios, los sistemas operativos compartían una infraestructura monolítica con múltiples aplicaciones corriendo en servidores físicos. Los administradores de sistemas, considerados unos verdaderos héroes de la informática, se encargaban de gestionar aplicaciones en estos nodos. Sin embargo, enfrentaban diversos desafíos, como:

  • Versionamiento y consistencia: Gestionar las dependencias y las librerías compartidas entre aplicaciones resultaba en caos.
  • Dependencias compartidas: Las aplicaciones requerían del kernel para funcionar, compartiendo librerías que podían generar conflictos.
  • Limitaciones de recursos: No había una forma sencilla de asignar recursos específicos a cada aplicación.

Estos problemas ocasionaron el famoso problema de "funciona en mi máquina", reflejando la poca confiabilidad y dificultad para replicar ambientes. Una solución temporal fue dedicar servidores a aplicaciones críticas, aunque resultaba en un uso ineficiente de recursos y tiempos de aprovisionamiento prolongados.

¿Qué papel jugó la virtualización en la evolución de esta tecnología?

La llegada de la virtualización revolucionó el panorama, ofreciendo una infraestructura más económica y flexible. Se introdujeron herramientas como Chef, Puppet y Ansible que ayudaron a gestionar eficientemente las máquinas virtuales, minimizando diferencias entre ambientes y favoreciendo aplicaciones inmutables. Ventajas notables incluyeron:

  • Inmutabilidad: Despliegue de nuevas aplicaciones implica crear una nueva máquina virtual, asegurando que los ambientes permanezcan controlados.
  • Aislamiento: Cada aplicación se ejecuta separadamente, mejorando estabilidad y seguridad.

Sin embargo, los desafíos persistieron debido al alto consumo de recursos, pues cada máquina virtual utilizaba su propio kernel, sobrecargando la infraestructura y alargando el tiempo de inicio de las máquinas.

¿Cómo surgieron los contenedores y qué beneficios aportan?

Inspirados por la necesidad de Google de mejorar la aislación y eficiencia de recursos, los contenedores emergieron como una solución superior. Fueron apoyados por tecnologías clave como Cgroups, namespaces y Change Root, ofreciendo múltiples beneficios:

  • Aislamiento mejorado: Separación y administración de recursos a nivel de contenedor.
  • Rendimiento y eficiencia: Inicio de contenedores en milisegundos y alta densidad de aplicaciones en un solo nodo.
  • Portabilidad: Consistencia desde desarrollo hasta producción, ejecutándose igual en diversos sistemas operativos.
  • Separación de responsabilidades: Mejora en la colaboración entre desarrollo (Dev) y operaciones (Ops).

Los contenedores también avivaron arquitecturas modernas como microservicios, permitiendo el desarrollo ágil y orquestación dinámica.

¿Cuál es el impacto actual de la contenerización en el desarrollo de software?

Hoy en día, la contenerización establece el estándar en la infraestructura moderna de software. Facilita la transición hacia metodologías DevOps, promueve una colaboración más estrecha entre equipos y optimiza el uso de recursos. Los contenedores permiten un desarrollo más dinámico y adaptable, lo que facilita a las empresas responder rápidamente a las demandas del mercado y a las necesidades de los usuarios. Para más detalles sobre herramientas y prácticas actuales, espera mi siguiente clase sobre Docker y su rol central en este entorno. ¡Te espero!

Aportes 7

Preguntas 0

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad?

🖥 Máquinas compartidas 💻 VMs/bare metal 📦 Contenedores
❌ Sin Aislamiento ✅ Aislamiento ✅ Aislamiento
❌ Librerías en común ✅ Sin librerías en común ✅ Sin librerías en común
❌ Alto acoplamiento entre apps y OS ❌ Caras e ineficientes ✅ Menos overhead
- ❌ Difíciles de mantener ✅ Menos dependencia del sistema operativo huésped

1. Máquinas Compartidas

Los administradores de sistemas tenian que conseguir ejecutar varios servidores físicos.

Existen Dependencias aplicativas como:

  • Kernel (requerido)
  • Otras dependencias (opcionales)
    • Runtimes del Lenguaje (Java, Node.js, etc.)
    • Modulos del Kernel
    • Herramientas del sistema
    • Librerías de sistema
    • Configuración

![[Dependencias aplicativas.png]]

La manera antigua: Instalar aplicaciones en el host

  • Múltiples aplicaciones por máquina
  • Dependencias compartidas
    Beneficios:
  • Ejecutables de tamaño pequeño
  • Menos uso de almacenamiento y memoria
  • Mayor utilización de recursos
    Problemas
  • Las dependencias se mezclaban unas con otras y con la máquina huésped
  • Una aplicación puede acaparar recursos, impactando a otras
  • Difícil de replicar y comúnmente existían diferencias
    entre ambientes (¡corre bien en desarrollo!)

La solución (temporal)

  • Dedicar máquinas huésped para las aplicaciones críticas
  • Empaquetar todas las dependencias con la aplicación
    Problemas
  • Dedicar máquinas huésped desperdiciaba recursos
  • Máquinas físicas toman tiempo en aprovisionar y configurar

2. VMs/bare metal

Se segmentaba una máquina en varias máquinas virtuales (Virtualización)

  • Permitir que el hardware físico sea compartido entre aplicaciones
    como máquinas virtuales (VMs)
  • Soluciones como Chef/Puppet/Ansible eran comúnmente utilizadas
    para administrar máquinas huésped y aplicativos
  • VMs inmutables daban despliegues y rollbacks predecibles
    Problemas
  • Recursos desperdiciados (mucho overhead)
  • Las VMs tardan mucho en iniciar

3. Contenedores

Mientras tanto en Google ños desarrolladores añadieron capacidades al kernel de Linux para soportar el aislamiento de procesos, poniendo las bases para la contenerización:

  • Grupos de control (cgroups) --límites de recursos.
  • Namespaces —aislamiento de procesos.
  • Change Root (chroot) — aislamiento del sistema de archivos (ya existía).

Esto permitió a las apps/procesos:

  • Correr con cpu y memoria asignada (específica)
  • Aislar de otros procesos
  • Proveer acceso limitado al sistema de archivos

La nueva manera es desplegar contenedores

  • Virtualización a nivel OS (namespaces, cgroups, …)

  • Aislado, entre otros procesos y el host

    • Lás imágenes de contenedor tienen su propio sistema de archivos, sus propios recursos y se ejecutan como su propio proceso
  • Rápido

  • Portable entre sistemas operativos y entre nubes

    • Siempre y cuando el kernel objetivo fuera el mismo que el de la máquina huésped
  • Ambientes consistentes entre desarrollo y producción

    • Creando imágenes inmutables durante el proceso de construcción, en lugar de durante el proceso de despliegue

Lo que me encanta de todos los cursos de GCP es que te cuentan como ha evolucionado la forma de hacer las cosas, pero aun hoy existen empresas que usan tecnología muuuuy vieja :C

Mi reflexión

El software no está listo cuando el código está funcionando en mi computadora.
.
Tampoco cuando se pasan las pruebas y alguien aprueba la revisión del código.
.
Ni cuando se termina un ciclo y se lo entrega al usuario.
.
Piensa que “Si funciona, no lo toques” pero:
.

¿Si algo funciona, no significa que necesariamente esta bien hecho?

.
Entregar un software, consiste en todo el trabajo que debe realizar para que el código esté disponible para un cliente, contemplando la ejecución del código en los servidores de producción.
.
La automatización es el acto de mejorar el XD (Experience Development) haciendo que el código sea resistente a interrupciones y resiliente a operaciones y fiable a entregas cintínuas,

El estándar actual para el despliegue de aplicaciones son los CONTENEDORES debido a la cantidad de beneficios que nos brindan con respecto a las dos anteriores. Sobretodo la PORTABILIDAD y la CONSISTENCIA que brinda a nuestras apps

Por si alguien más tiene la duda de que se refiere con overhead

El overhead en computación se refiere a los recursos adicionales que consume un sistema para llevar a cabo una tarea que no está directamente relacionada con la tarea en sí. Esto puede incluir el uso de memoria, tiempo de procesamiento y almacenamiento que no se utiliza para la ejecución efectiva de los programas. Por ejemplo, en la virtualización, cada máquina virtual tiene su propio sistema operativo y kernel, lo que genera una carga adicional en el sistema físico. En contraste, los contenedores tienen menos overhead al compartir el mismo kernel, lo que los hace más eficientes.

Siempre es bueno saber algo de historia!
Gracias!