Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

DevOps+[Chef/Docker]

1,288 views

Published on

Introduce la filosofía DevOps y presenta Docker y Chef como dos herramientas de gran ayuda

Published in: Technology

DevOps+[Chef/Docker]

  1. 1. DevOps+ [Chef/Docker] por Lic. Christian Rodriguez car@info.unlp.edu.ar @car_unlp Junio de 2014 Jornadas de actualización Tecnológica - SD
  2. 2. Temas ● Objetivo ● Los problemas en la organización ● Algunas soluciones ● DevOps ● Productos ● Conclusiones
  3. 3. Objetivo Plantear la realidad contemporánea de nuestra organización, a partir de problemas y soluciones que han surgido espontáneamente y derivaron en la aplicación de la metodología DevOps
  4. 4. Los problemas en la Organización ● Los problemas pueden analizarse desde: – La perspectiva del desarrollo – La perspectiva de TI – La perspectiva de la puesta en producción
  5. 5. La perspectiva de Desarrollo
  6. 6. Problemas en desarrollo ● Cerca de 100 aplicativos: 70 de los cuales tienen actividad constante ● Versiones diferente de productos todas las semanas ● Por día se realizan 5 deploys aproximados – Por errores en producción – Por nuevas funcionalidades ● Ambientes de trabajo: – Desarrollo – Pruebas – Producción
  7. 7. Problemas en desarrollo ● Ambientes complejos – SSO – APIs – Balanceo y Caching
  8. 8. Problemas en desarrollo ● Conseguir datos de producción – Dumps de bases de datos – Código en producción
  9. 9. La perspectiva de TI
  10. 10. Los problemas de TI ● Desarrollo no es el único cliente ● Se cumplen varias tareas complejas de administración ● Nuevos productos que requieren conocimientos de arquitecturas emergentes: NodeJS, Erlang, Redis, APIs, MongoDB, etc – No todo es xAMP, Exim/Postfix, iptables ● Compromiso de seguridad por el hosting de aplicativos de terceros ● Vencimientos SSL
  11. 11. La perspectiva de producción
  12. 12. Los problemas en producción ● Procedimientos para el deploy de nuevas aplicaciones ● Procedimientos para la actualización de aplicaciones ● Aplicar parches a bases de datos productivas de gran volumen ● Notificación a usuarios de aplicaciones sobre los cambios a aplicar ● Monitoreo y backup de servicios ● Vencimiento de contratos y SLA
  13. 13. Soluciones parciales
  14. 14. Soluciones ● Virtualización ● Matriz de aplicaciones por seguridad y criticidad ● Controles de seguridad por aplicación – Cada aplicación WEB corre con usuario diferente – Firewall por cada aplicación o servicio ● Análisis de nuevos productos como nginx, openvz, varnish, haproxy, etc.
  15. 15. Virtualización ● Simplificaciones – Backups – Gestión de TI – Migraciones en caliente – Aprovechamiento de recursos – Instalaciones basadas en templates ● Complicaciones – Mantenimiento de virtuales – Estado contractual de todas las VMs en mi dominio – Sin una solución de storage no se aprovechan muchas ventajas
  16. 16. Matriz de aplicaciones ● Relevamiento de aplicaciones por vulnerabilidades y criticidad de los datos servidos ● A partir del análisis surgen nuevas inquietudes – Apache + ITK – PHP FPM – No todas nuestras soluciones son xAMP – Contenedores linux: OpenVZ / LXC
  17. 17. Algunos problemas ● Nuevos productos emergentes requieren investigación sobre configuraciones y puesta a punto en producción ● Escasez de recursos en nuevas tendencias: – Servidores Ruby: unicorn, puma, Apache mod rails / passenger – Caching: varnish – Balanceo: nginx / ha-proxy – Nuevos servicios: Bases NO-SQL, AMQP, etc
  18. 18. DevOps Una nueva tendencia orientada a obtener una relación colaborativa de trabajo entre las áreas de desarrollo y TI
  19. 19. Objetivos ● Mejorar los tiempos de respuesta ● Cumplir con las fases del proyecto según lo planificado ● Mejorar el ciclo de vida ● Versionado de ambientes ● Exigir confiabilidad, estabilidad, resilencia y seguridad en el ambiente de operaciones ● Desarrolladores que piensen como administradores, y administradores que piensen como desarrolladores
  20. 20. Ciclo de vida Se define ciclo de vida al tiempo promedio que toma desde que un nuevo requerimiento es aprobado, el área de desarrollo lo implementa y el pase definitivo a producción
  21. 21. Versionado de ambientes ● El personal de TI debe lidiar con múltiples configuraciones e instalación de actualizaciones. Estos cambios implican una nueva versión de ese ambiente. La única forma de realizarlo a tiempo, en forma documentada y minimizando errores a través de scripts ● Surge Infrastructure as Code ● Los scripts generan nuevos entornos virtuales que deben versionarse como código tradicional
  22. 22. Orígenes de DevOps ● Velocity Conference ● Infraestructure as code ● Agile infrastructure ● Agile system administration
  23. 23. Docker
  24. 24. Qué es? ● Basado en LXC ● Simplifica el deployment de aplicaciones en contenedores ● Se compone de: – Docker engine: soporte de herramientas provistas por docker para el desktop, con las cuales podemos correr, crear y administrar contenedores – Docker Hub: repositorio de imágenes
  25. 25. Filosofía Docker ● Gestión de imagenes: se pueden descargar del hub docker, y una vez locales usarlas para iniciar contenedores ● Gestión de contenedores a partir de imágenes ● En cualquier momento, se puede versionar un contenedor creando una nueva imagen
  26. 26. Ejemplos de docker docker search xxx docker pull <­t TAG> image  docker run ­i ­t image <CMD> docker ps [­a] docker diff <CONTAINER­ID> docker commit
  27. 27. Un ejemplo de uso real ● Desarrollo de aplicaciones PHP < 5.4 ● Simulación de instalación de ambientes ● A futuro: – Deploy completo del ambiente de testing – Tests al vuelo: from scratch
  28. 28. Chef
  29. 29. Qué es? ● Permite gestionar la infraestructura como código alcanzando – Versionado – Testearla – Replicarla
  30. 30. Cómo trabaja? ● Con libros de cocina y recetas ● Se programa en Ruby ● Requiere de una arquitectura de servicios: – Servidor Chef – Máquinas a aprovisionar – Máquinas del administrador ● Para probar se combina fácilemente con vagrant – Vagrant es un gestor de VMs (por defecto Vbox) – Se integra muy bien con AWS
  31. 31. Veamos unas recetas simples ● Recetas para: – Choique: CMS desarrollado por UNLP ● URL: https://github.com/Desarrollo-CeSPI/choique_cookbook – Kimkelen: sistema de gestión de alumnos de UNLP ● URL: https://github.com/Desarrollo-CeSPI/kimkelen_cookbook ● Usaremos vagrant para probar – Debemos instalar el plugin vagrant-berkshelf ● Al descargar, en el directorio correr: vagrant up
  32. 32. Lo mismo con AWS/Docker ● Analizamos las otras configuraciones en los repositorios anteriores – Iniciamos una instancia de la aplicación en AWS ● Requiere los plugins: – vagrant-aws – vagrant-omnibus
  33. 33. Un ejemplo real con chef ● Instalar un choique en la infraestructura de testing de UNLP – Crear un usuario con el que corre PHP con Apache mod ITK – Configurar proxy reverso frente al equipo anterior – Editar la configuración de DNS ● Dos dominios: uno para el frontend, y otro para el backend – Deployar la aplicación por un usuario de desarrollo
  34. 34. Conclusiones ● Adoptando este modelo se reducen tiempos de liberación de aplicaciones desarrolladas utilizando metodologías ágiles ● Integración y sincronización de tareas entre TI y desarrollo ● Revisión acerca de la segregación de funciones tradicional definida en marcos de referencia, buenas prácticas y estándares
  35. 35. Referencias ● DevOps: – http://itrevolution.com/ – DevOps por New Relic – http://devopsweekly.com/ ● Docker: http://www.docker.com/ ● Chef: http://www.getchef.com/ – http://chrodriguez.github.io/capacitacion_chef/

×