Arte y Ciencia de un despliegue coordinado

En Tuenti hemos pasado de ser una red social a una telco 2.0 y esto cambia radicalmente la aproximación sobre el mantenimiento de nuestros sistemas. Donde antes centenas de servidores se disputaban enormes cargas de trabajo, ahora un número mucho menor debe lidiar con aplicaciones de VoIp, envío y recepción de SMS, pagos, recargas y un sin fin de trabajos que nada tienen que ver con conceptos como la "coherencia eventual". Describiremos como hemos diseñado un sistema de despliegue capaz de mantener nuestras aplicaciones en constante funcionamiento y evolución, de forma totalmente segura pero a la vez manteniendo la filosofía del auto-servicio. Este es una cuento sobre tomcat, jboss, kamailio y freeswitch y de como puppet, zookeeper, nexus y mcollective los coordinan, despliegan y configuran.

Transcript

1. Arte y ciencia de un
   despliegue coordinado.
   @jplana
   @TuentiEng
   

   View Slide

2. Conceptos básicos
   Artefacto:
   An artifact is one of many kinds of tangible by-products
   produced during the development of software.[1]
   [1] http://en.wikipedia.org/wiki/Artifact_(software_development)
   

   View Slide

3. Conceptos básicos
   Nodo/Host:
   A network host is a computer or other device
   connected to a computer network. A network host may offer
   information resources, services, and applications to users
   or other nodes on the network.[2]
   [2] http://en.wikipedia.org/wiki/Host_(network)
   

   View Slide

4. Conceptos básicos
   Granja/Cluster:
   A server farm or server cluster is a collection of
   computer servers usually maintained by an enterprise to
   accomplish server needs far beyond the capability of one
   machine.[3]
   [3] http://en.wikipedia.
   org/wiki/Server_farm
   

   View Slide

5. Conceptos básicos
   Despliegue:
   Software deployment is all of the activities that make a
   software system available for use.
   The general deployment process consists of several
   interrelated activities with possible transitions between
   them.[4]
   [
   4] http://en.wikipedia.org/wiki/Software_deployment
   

   View Slide

6. View Slide

7. La red social
   Image courtesy of Shutterstock.com
   

   View Slide

8. View Slide

9. View Slide

10. View Slide

11. Flow
    Image courtesy of Shutterstock.com
    

    View Slide

12. View Slide

13. View Slide

14. View Slide

15. Image courtesy of Shutterstock.com
    

    View Slide

16. View Slide

17. View Slide

18. View Slide

19. MVNE
    Image courtesy of Shutterstock.com
    

    View Slide

20. View Slide

21. View Slide

22. View Slide

23. Anatomía de un despliegue Java
    

    View Slide

24. Anatomía de un despliegue Java
    ● El origen de los artefactos.
    ● Interrupción del servicio.
    ● Alta disponibilidad y balanceo de carga.
    

    View Slide

25. Receta simple para un despliegue
    1. Deshabilitar el nodo en
    el balanceador.
    2. Esperar a que el nodo
    deje de servir
    peticiones.
    3. Matar el contenedor.
    4. Desplegar el artefacto.
    5. Habilitar el nodo en el
    balanceador.
    

    View Slide

26. Puppet & Puppi
    ● Conjunto de scripts creados dinámicamente por puppet
    (bash)
    ● Los módulos como Tomcat o Jboss tienen efecto
    directo sobre esta configuración.
    ● Proporciona comandos como
    ○ puppi deploy
    ○ puppi rollback
    ○ puppi check
    

    View Slide

27. Puppet & Puppi
    20-XXX-Run_Custom_PreDeploy_Script
    21-XXX-Get_Version
    25-XXX-Get_Maven_Files_WAR
    30-XXX-Backup_Existing_WAR
    31-XXX-Check_undeploy
    36-XXX-Disable_extra_services
    40-XXX-Deploy_Maven_WAR
    44-XXX-Enable_extra_services
    45-XXX-Check_deploy
    46-XXX-Run_Custom_PostDeploy_Script
    

    View Slide

28. Mcollective
    ● Ejecución de comandos
    arbitrarios.
    ● Grano fino de
    autorización.
    ● Gestionable por puppet
    integrado con puppetdb.
    

    View Slide

29. Receta mejorada para un despliegue
    1. Deshabilitar el nodo en el balanceador.
    2. Esperar a que el nodo deje de servir peticiones.
    3. Matar el contenedor.
    4. Desplegar el artefacto.
    5. Habilitar el nodo en el balanceador.
    6. Sí el nodo no comienza a servir peticiones ->
    INTERRUMPIR PROCESO
    7. El nodo comienza a servir peticiones. ->
    SELECCIONAR SIGUIENTE NODO. GOTO 1.
    

    View Slide

30. Versionado
    Premisas:
    1. Las versiones debe estar almacenadas
    fuera de los nodos.
    2. Debe ser un sistema redundante.
    3. Debe permitir una jerarquía de versiones
    

    View Slide

31. Jerarquía de versiones
    

    View Slide

32. Zookeeper
    

    View Slide

33. View Slide

34. Servicios de voz
    Image courtesy of Shutterstock.com
    

    View Slide

35. View Slide

36. Nueva aproximación
    Los nodos ya pueden, de forma
    “independiente”:
    1. Obtener los artefactos
    2. Reiniciar y preparar lo servicios locales
    3. Comprobar su estado interno y externo.
    

    View Slide

37. Nueva aproximación
    Para ser completamente independientes (de un
    coordinador), necesitan:
    1. Conocer el estado del resto de nodos.
    

    View Slide

38. View Slide

39. View Slide

40. View Slide

41. View Slide

42. View Slide

43. Generalización
    Image courtesy of Shutterstock.com
    

    View Slide

44. View Slide

45. View Slide

46. View Slide

47. View Slide

48. View Slide

49. View Slide

50. View Slide

51. ¿Preguntas?
    @jplana
    Images courtesy of Shutterstock.com
    

    View Slide