Betabeers Madrid · 2014

dockerize.it

German Del Zotto · Betabeers Madrid, septiembre de 2014 · 29 min · youtube.com/watch?v=Tz0rGp0uMBs

Transcripción automática con Whisper. Puede tener errores, sobre todo en nombres propios y términos técnicos.

Capítulos

= cuánto merece la pena el capítulo si solo quieres las ideas (de 0 a 3 contenedores). Haz clic en una tarjeta para saltar.

Resumen

German Del Zotto presenta dockerize.it en Betabeers Madrid, en septiembre de 2014. Es el primer producto propio de su compañía de desarrollo, y Docker acababa de cerrar una ronda de unos 40 millones 0:24. La primera mitad explica Docker a un público que en parte no lo había usado. La segunda cuenta qué problemas aparecen después del tutorial y cómo está construido dockerize.it por dentro.

Docker se explica comparándolo con una máquina virtual. Un container comparte el kernel del host y tiene su propio sistema de ficheros, su red, su memoria y su CPU asignada, así que no hay un sistema operativo invitado que arrancar 3:03. Un container nuevo arranca en menos de un segundo y no hay que mover cientos de megas de disco por cada entorno 5:01.

Para developers, los casos son probar software sin ensuciar la máquina (instalar Elasticsearch, que pide Java), acabar con el «en mi máquina funciona», depurar un proyecto viejo cuyos paquetes ya no están, y desplegar exactamente la imagen que se probó 5:30. De Puppet dice que, a los siete meses, a él nunca le reproduce la misma máquina 7:23. Para startups, la ventaja es depender solo de que el servidor tenga Docker. Si AWS sale caro, lo mismo corre en DigitalOcean, y en una máquina de 2 o 3 GB de RAM caben muchas aplicaciones de 200 MB 10:01.

Después recorre el ecosistema. El servidor solo corre en Linux (en Mac o Windows hay una máquina virtual debajo), se controla con el cliente, la API REST o los SDKs, y ya aparecían los primeros containers as a service y las imágenes de CoreOS en DigitalOcean. Las imágenes salen de un Dockerfile o de un commit hecho a mano, y se guardan en el Hub o en un registry privado sobre S3 11:56.

Los problemas del «día 2 después del tutorial 0» ocupan el tramo más útil 17:07. Dónde quedan los logs de un container que muere en segundos, cómo monitorizar si cada container ejecuta un único proceso, IPs que cambian en cada arranque, entrar por SSH a algo que en teoría no se toca. Y los datos, que se pierden con el container si no se usan volúmenes 18:59.

dockerize.it ataca esos temas: promover containers entre entornos, centralizar logs, túneles SSH entre servidores, orquestar deploys y monitorizar en remoto. Se instala lanzando un container con un comando estándar de Docker, y ese agente es open source porque nadie va a ejecutar en su datacenter algo que manda información sin saber qué hace 20:24. La aplicación también corre en containers, con HAProxy delante, la web en Rails, una API por WebSockets para los agentes, microservicios en Ruby, Resque, MySQL, Redis y RabbitMQ 22:25. Las peticiones web responden enseguida y el resultado llega después, porque el servidor del cliente puede tardar lo que quiera en contestar 24:59.

En las preguntas, alguien plantea que en desarrollo se usan versiones reducidas de lo que hay en producción, como un Mongo sin sharding. La respuesta tiene dos partes. La aplicación debería ver un endpoint y no saber si hay sharding detrás, y con Docker levantar cinco Mongos pequeños en la propia máquina es fácil 27:06.

Mapa de conocimiento

dockerize.itDocker en 2014: qué resuelve, qué problemas trae y un producto para gestionarlo
Conexiones: Comparte el kernel → arranque en menos de un segundo y muchas apps en 2-3 GB · «En mi máquina funciona» ↔ la pregunta del Mongo con sharding · Problemas del día 2 → la lista de lo que resuelve dockerize.it · dockerize.it se despliega con containers en un servidor Docker gestionado por dockerize.it.