Virtualization has been around much of the history of computing from the introduction of virtual memory to virtualization at the operating system level and containers. The use of containers as a deployment tool has boomed since the release of Docker as free software in 2013. Docker includes a large set of tools ranging from building and executing containers on a single node to managing multiple containers in clusters. However, the distribution of deployment descriptors and of maintenance scripts is not properly addressed. This work introduces the mechanisms provided by Docker and describes a practice developed by the Bitlogic team for the deployment and management of the container lifecycle.

1. A Strategy for Container Lifecycle
Management
Federico Aguirre, Alfredo Edye, Edgardo Hames
September 6, 2017

2. Table of contents
1. Introducción
2. 12-Factor Apps
3. Bootstrap
4. Conclusión
1

3. Introducción

4. Reseña histórica
1956 • Memoria Virtual, Fritz-Rudolf Güntsch
1959 • Tiempo Compartido, John McCarthy
1964 • Hypervisor (14 VMs concurrentes), IBM
1979 • chroot, Unix
2000 • Virtualización OS, Virtuozzo
2000 • jails, FreeBSD
2004 • zones, Solaris
2008 • namespaces, Linux
2013 • Docker
2

5. Virtualización
3

6. Arquitectura de Docker
4

7. Compose & Swarm
5

8. 12-Factor Apps

9. Presentación
• Uso de formatos declarativos para configuraciones
6

10. Presentación
• Uso de formatos declarativos para configuraciones
• Existencia de un contrato claro entre las aplicaciones y el sistema
operativo para mayor portabilidad
6

11. Presentación
• Uso de formatos declarativos para configuraciones
• Existencia de un contrato claro entre las aplicaciones y el sistema
operativo para mayor portabilidad
• Simplificación de despliegue en plataformas cloud
6

12. Presentación
• Uso de formatos declarativos para configuraciones
• Existencia de un contrato claro entre las aplicaciones y el sistema
operativo para mayor portabilidad
• Simplificación de despliegue en plataformas cloud
• Integración continua para mayor agilidad
6

13. Presentación
• Uso de formatos declarativos para configuraciones
• Existencia de un contrato claro entre las aplicaciones y el sistema
operativo para mayor portabilidad
• Simplificación de despliegue en plataformas cloud
• Integración continua para mayor agilidad
• Escalabilidad sin cambios significativos en la arquitectura,
herramientas y prácticas de desarrollo
6

14. Procesos administrativos
El código de administración y despliegue debe
• entregarse junto con el de la aplicación para evitar inconsistencias
7

15. Procesos administrativos
El código de administración y despliegue debe
• entregarse junto con el de la aplicación para evitar inconsistencias
• ser autocontenido y no depender de la existencias de herramientas o
bibliotecas en el sistema
7

16. Problema
¿Cómo distribuimos los scripts de mantenimiento y sus configuraciones?
8

17. Bootstrap

18. Bootstrap
Un nuevo contenedor denominado Bootstrap encargado de
• distribución de scripts de mantenimiento y configuraciones
9

19. Bootstrap
Un nuevo contenedor denominado Bootstrap encargado de
• distribución de scripts de mantenimiento y configuraciones
• descarga de imágenes del sistema
9

20. Bootstrap
Un nuevo contenedor denominado Bootstrap encargado de
• distribución de scripts de mantenimiento y configuraciones
• descarga de imágenes del sistema
• gestión del ciclo de vida (inicio, detención, estado, etc)
9

21. Bootstrap
Un nuevo contenedor denominado Bootstrap encargado de
• distribución de scripts de mantenimiento y configuraciones
• descarga de imágenes del sistema
• gestión del ciclo de vida (inicio, detención, estado, etc)
• tareas de mantenimiento (upgrade, downgrade, migración, etc)
9

22. Uso
Para descargar las imágenes de los servicios
$ docker run --rm bootstrap pull
Para desplegar los contenedores
$ docker run --rm bootstrap up
Para detener los contenedores
$ docker run --rm bootstrap stop
10

23. Implementación (script)
#!/bin/bash
command=$1
case "$command" in
"pull")
docker-compose pull
;;
"up")
docker-compose up
;;
"stop")
# TODO: Pedir al usuario que confirme
docker-compose stop
;;
esac
11

24. Implementación (Dockerfile)
FROM docker/compose:1.12.0
COPY docker-compose.yml /opt/bitlogic
COPY startup.sh /opt/bitlogic
RUN chmod 755 /opt/bitlogic/startup.sh
ENTRYPOINT /opt/bitlogic/startup.sh
12

25. Ventajas
• Aplica a cualquier tipo de proyecto que use Docker
13

26. Ventajas
• Aplica a cualquier tipo de proyecto que use Docker
• Puede usarse con cualquier motor de integración y despliegue
continuos
13

27. Ventajas
• Aplica a cualquier tipo de proyecto que use Docker
• Puede usarse con cualquier motor de integración y despliegue
continuos
• Facilita el despliegue del producto en el entorno de desarrollo
13

28. Ventajas
• Aplica a cualquier tipo de proyecto que use Docker
• Puede usarse con cualquier motor de integración y despliegue
continuos
• Facilita el despliegue del producto en el entorno de desarrollo
• Permite desplegar remotamente usando la API TCP de Docker
13

29. Ventajas
• Aplica a cualquier tipo de proyecto que use Docker
• Puede usarse con cualquier motor de integración y despliegue
continuos
• Facilita el despliegue del producto en el entorno de desarrollo
• Permite desplegar remotamente usando la API TCP de Docker
• Garantiza la compatibilidad con cada versión del producto
13

30. Ventajas
• Aplica a cualquier tipo de proyecto que use Docker
• Puede usarse con cualquier motor de integración y despliegue
continuos
• Facilita el despliegue del producto en el entorno de desarrollo
• Permite desplegar remotamente usando la API TCP de Docker
• Garantiza la compatibilidad con cada versión del producto
• Es agnóstico de la plataforma subyacente (Swarm, Kubernetes, etc)
13

31. Comparación con Puppet, Chef, Salt, Ansible, etc
• Tiene un propósito muy específico
14

32. Comparación con Puppet, Chef, Salt, Ansible, etc
• Tiene un propósito muy específico
• No requiere agentes adicionales (solo Docker)
14

33. Comparación con Puppet, Chef, Salt, Ansible, etc
• Tiene un propósito muy específico
• No requiere agentes adicionales (solo Docker)
• Puede ser implementado por el equipo de desarrollo del producto
14

34. Conclusión

35. Resumen
• Los contenedores permiten consolidar la infraestructura.
15

36. Resumen
• Los contenedores permiten consolidar la infraestructura.
• Docker ha bajado la barrera de acceso a contenedores.
15

37. Resumen
• Los contenedores permiten consolidar la infraestructura.
• Docker ha bajado la barrera de acceso a contenedores.
• Bootstrap resuelve el problema de la distribución de configuraciones.
15

38. Resumen
• Los contenedores permiten consolidar la infraestructura.
• Docker ha bajado la barrera de acceso a contenedores.
• Bootstrap resuelve el problema de la distribución de configuraciones.
• Bootstrap permite unificar la interfaz de operación.
15

39. ¿Preguntas?
15