Episodio #3: Contenedores para las enchiladas

Published: Jan 24, 2020 by

En este episodio nos damos un chapuzon en las tecnologias de contenedores, también rolamos unos tips sobre como tomar la decisión sobre si los necesitan y como elegir el runtime correcto.

Contenedores para las enchiladas.

¿Qué es un runtime de containers? Antes de comenzar, es importante saber, que es un container runtime, es lo que nos permitirá crear y administrar nuestros contenedores.

¿Por qué el más famoso fue Docker? Docker tuvo bastante éxito porque fue uno de los primero runtimes en estandarizar lo que tantas personas buscaban para containers y fueron las siguentes razones:

  • Un formato de imagen de contenedor
  • Un método para construir imágenes de contenedor (Dockerfile / docker build)
  • Una forma de administrar imágenes de contenedor (imágenes de Docker, Docker rm, etc.)
  • Una forma de gestionar instancias de contenedores (docker ps, docker rm, etc.)
  • Una forma de compartir imágenes de contenedor (docker push / pull)
  • Una forma de ejecutar contenedores (Docker Run)

En pocas palabras nos facilitaron la vida, pero…

¿Sólo existe Docker? ¿Qué otras opciones tenemos? A paso bastante tiempo y desde luego que tenemos nuevos runtimes.

Estás son algunas de las opciones que tenemos actualmente.

Linux Containers LXC es un runtime completamente Open Source, si requieres soporte, me parece que el único camino que tenemos es hacía Canonical. Los podemos ver habitualmente en las propuestas de Canonical con un stack que incluya ubuntu , esto para ambientes productivos.

Runc Runc, es de lo más básico que existe, es el producto de la Open Container Initiative y su objetivo es estandarizar la manera de ejecutar los contenedores, algunos de los participantes en estas estandarizaciones fueron Docker, Google y CoreOs (cuando existía), entonces su uso debe ser muy específico, por ejemplo, para partir con la construcción de nuestro propio runtime High-level.

lmctfy Esta es la propuesta de Google para contenerizar sus aplicaciones. Es un proyecto completamente Open Source por lo tanto el soporte corre por nuestra cuenta y es una buena opción para experimentar, quién sabe, podría salir algo genial.

cri-o Es uno de los runtimes que más ha crecido últimamente, ya que es uno de los runtimes preferidos de Kubernetes y por los tanto, de los vendors que tienen productos basados en kubernetes. ¿Por qué es de los favoritos? Porque no es too much, tiene lo necesario para correr aplicaciones contenerizadas, sin muchos recursos y se apegó a el crecimiento de kubernetes. containerd Un proyecto graduado de la Cloud Native Computing Fundation

Docker El mas famoso: Docker.com

rkt rkt es de coreOS podman Es la apuesta de RedHat para containers evidentemente, con soporte que es lo que le interesa a Red Hat primeramente y trae de la mano a Buildah, Podman se encarga de la administración de los containers y Buildah de la construcción, incluso tienen ya artículos de cómo migrar de Docker a estos nuevos amigos, https://developers.redhat.com/blog/2019/02/21/podman-and-buildah-for-docker-users/ podrían echarle un ojo y si es lo conveniente.

Runtimes

¿Qué es bajo nivel?

Es sólo el runtime, ejecución de el containers, así pelón, sin más. Sólo me interesa ejecutar mi container y poderlo parar.

¿Alto nivel?

Aquellas opciones que usan por ejemplo runc para correr los containers pero también implementaron administración de imágenes e incluso un api para la administración de sus ecosistema de containers.

Entonces podríamos decir que cri-o, containerd, podman y docker, son de alto nivel.

Y bueno, está muy padre la información y todo pero, ¿cómo sé si sólo necesito un runtime de containers? ¿Cómo sé si necesito herramientas de containers adicionales al runtime?

Bueno, es una importante pregunta.

Creo que hacerte estas preguntas podrían ayudarte. ¿Qué perfil tengo o tiene mi equipo? ¿Desarrollado? ¿Operador? ¿Administrador de clusters? Para qué quiero usar los containers, es decir ¿Para un proceso de desarrollo? ¿Laboratorio? ¿Puesta en producción de sistemas concurrentes? ¿Con cuantos recursos cuento? Dinero, tiempo, manos, etc.

Por ejemplo, si quieres usar containers para que tu equipo de desarrollo sea más ágil y puedan estandarizar una manera de correr aplicaciones, sería buen opción un runtime de alto nivel, que tenga un api y te permite administrar tus imágenes, por ejemplo Docker o containers o incluso cri-o.

Peroooo si este proceso incluye, una puesta en producción, ahí no sólo debes considerar a tu equipo si no a infraestructura, seguridad, etc.. ¿Por qué ¿Sobre qué sistema operativos vas a correr? ¿Qué opciones tienes para esos sistemas operativos y que sea compatible con todo tu equipo? ¿Necesitas soporte? Y ahí la brecha se puede cerrar por Docker, Podman, por decir algo.

Sin embargo, nada es imposible y siempre se pueden elaborar stacks complejos, como siempre, importa el tiempo y qué tan lejos tengas permitido llegar o te las ingenias para llegar.

Resumiendo los consejos.

Define tu necesidad ¿Por qué quieres usar containers? ¿Por qué necesitas containers?

  • Define si requieres un runtime de alto o bajo nivel
  • Considera tiempos
  • Costos
  • Soporte

Recuerden que los boletos para el primer DevOpsDays acá en nuestro México chulo ya están a la venta, no se pueden perder una experiencia como esta de un evento internacional, denle una checada aqui y su página de registro

Fue muy grato poder platicar sobre estos temas, le mandamos un abrazo al borre y esperamos tenerlo en otra ocasión en el podcast.

Referencias:

  • https://www.ianlewis.org/en/container-runtimes-part-1-introduction-container-r
  • https://medium.com/@alenkacz/whats-the-difference-between-runc-containerd-docker-3fc8f79d4d6e
  • https://kubernetes.io/docs/setup/production-environment/container-runtimes/
  • https://linuxcontainers.org
  • https://podman.io/getting-started/
  • https://www.opencontainers.org
  • https://opensource.google/projects/lmctfy
  • https://www.reddit.com/r/kubernetes/comments/9guswb/docker_vs_crio/
  • https://developers.redhat.com/blog/2019/02/21/podman-and-buildah-for-docker-users/