Episodio #3
Contenedores para las enchiladas
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.
¿Qué es un runtime de containers?
Antes de comenzar, es importante saber, qué 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 siguientes 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…
INFORMACIÓN DE ESTE CAPÍTULO
¿Sólo existe Docker? ¿Qué otras opciones tenemos?
A pasado 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 más 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,
Echenle un ojo acá y vean 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/