Infrastructure as Code: Docker en todos lados.

Infrastructure as Code: Docker en todos lados.

http://pyvideo.org/pycon-ar-2016/infraestrucura-como-codigo-docker-en-todos-lados.html

PyconAR 2016 - Bahia Blanca

Infraestrucura como código. Docker en todos lados por Nicolás Demarchi (GiLgAmEzH)

Audience level: Intermedia

Descripción

Un ejemplo de "Infraestructura as code". Docker desde el desarrollo a producción usando gitlab y Rancher.

Resumen

Qué significa "Infraestructure as code". Por qué todo Sysadmin debe convertirse en programador y transformar toda su infraestructura en un entorno inmutable y reconstruible. En la charla además de plantear estas ideas voy a mostrar un caso de uso de cómo utilizar containers desde desarrollo a producción usando Docker, gitlab y Rancher.

E738f295c823e5ab0a39b63d286254ff?s=128

Nicolás Demarchi

November 26, 2016
Tweet

Transcript

  1. Infrastructure as code. Docker en todos lados Nicolás Demarchi @gilgamezh

    This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.
  2. Conocimientos previos (No excluyentes)

  3. https://www.docker.com/what-docker

  4. docker-compose (Downsizing the DC Ricardo Kirkner PyConAr 2015) version: '2'

    services: web: build: . ports: - "5000:5000" volumes: - .:/code - logvolume01:/var/log links: - redis redis: image: redis volumes: logvolume01: {}
  5. https://about.gitlab.com/ Omnibus GitLab https://docs.gitlab.com/omnibus/README.html • Repositorio de código • Issue

    tracker • Wiki • CI/CD (ejemplo en esta charla) • Docker registry. (ejemplo en esta charla)
  6. Un ejemplo común de una aplicación web. App server 1

    F r o n t e n d C a c h e DDBB Cache Cache Cache Load Balancer Load Balancer App server 2 App server N File server DDBB Cache Full Text Search Monitoreo Backups! Metricas/ instrumentacion Logs centralizados
  7. ¿Cómo mantenemos una infraestructura como esta? • Instalación manual •

    Cambios de configuración manuales. • Deploy complejo de automatizar. • Ambientes no reproducibles • Todo es muy caro (en tiempo y esfuerzo) • Hacer cambios asusta. • Servidores mutables. • Servidores únicos. • Perros verdes • Snowflakes https://www.flickr.com/photos/chaoticmind75/12718370273
  8. ¿Cómo mantenemos una infraestructura como esta? • Hay que mantener

    documentación de cada ambiente. • Es muy complejo transmitir el conocimiento • Existen los "indispensables" • Los procedimientos son desconocidos. • Proceso huérfanos. • Es complejo realizar actualizaciones/parches de librerías o Sistema Operativo.
  9. Infrastructure as code

  10. Infrastructure as Code (IaC) is the process of managing and

    provisioning computing infrastructure (processes, bare-metal servers, virtual servers, etc.) and their configuration through machine-processable definition files, rather than physical hardware configuration or the use of interactive configuration tools. (Wikipedia)
  11. Una máquina de clonar perros verdes. (O copos de nieve.)

  12. Ya es un concepto impuesto

  13. Ya es un concepto impuesto • #DevOps, #ChatOps, #HugOps •

    Ansible, salt, chef, puppet, fabric, etc. • Cloudformation, Azure Resource Templates, Terraform • CI/CD debe incluir la infraestructura. • Measure Anything, Measure Everything.
  14. El sysadmin/DevOp/Developer que se automatiza a sí mismo no existe

    Pero sí existen los que duermen.
  15. Tomarlo como una cultura Una manera de hacer las cosas

    para que nuestro trabajo y nuestra vida (en el trabajo) sean mejores.
  16. Inmutable y Reconstruible

  17. Inmutable: Una vez generado no cambia. Reproducible: Tenemos la receta

    el código y la máquina para reproducir nuestra infraestructura
  18. Norton Ghost y DeepFreeze en 2016 • Una vez dispuesta

    (deploy) la infraestructura es inmutable, sólo se puede cambiar la receta. • Nuevo roll out incluye librerías, configuraciones, OS. • Nuevo roll out == nuevo server. • Rollback es trivial. (excepto por los datos) • Nos permite reproducir nuestra infraestructura y generar tantos ambientes como necesitemos. • En el código está documentado y detallado el qué y el cómo. • Escalar es más simple. • Obliga al equipo a ser colaborativo. “Cómo se hace” es un acervo de todos. • ¡Peer Reviews de las configuraciones! • Destruir y generar nuestra infraestructura constantemente nos da seguridad y agilidad.
  19. No Silver Bullet This is merely a (biased and subjective)

    selection of items...
  20. ¡Ejemplo!

  21. http://docs.rancher.com

  22. None
  23. sudo docker run -e CATTLE_AGENT_IP="192.168.43.212" -d --privileged \ -v /var/run/docker.sock:/var/run/docker.sock

    \ -v /var/lib/rancher:/var/lib/rancher rancher/agent:v1.0.2 \ http://trantor:8080/v1/scripts/E7255C640610D4C38BB6:1480078800000:Xpf8XZyWBWzzP Zk4sNgeIfmVKo56e6a63a62aadc303cda545f558a713930baf4dfe2c4ed086ecd678f1d07de30
  24. None
  25. None
  26. None
  27. None
  28. None
  29. None
  30. Docker-compose / rancher-compose

  31. https://about.gitlab.com/gitlab-ci/

  32. Gitlab runner / continuous integration • Instalación utilizando Docker. •

    (Necesita privilegios para crear otros containers. ) • Se configura con .gitlab-ci.yml en el root del repo.
  33. None
  34. None
  35. Ejemplo de Pipeline

  36. rancher-compose

  37. Resumen de CI/CD • Merge request → Ejecuta los tests

    y hace build de imágenes y las publica con un tag del branch. • Merge a master → Publica nueva imagen como "latest" • Se crea un tag → Crea imágenes con tag a la versión. Permite realizar deploy manual. • "Click en deploy" → Rancher hace pull de las imágenes y instancia nuevos containers con la nueva imagen. • "Confirmar deploy" → Los containers de la versión anterior se mantienen para poder realizar un rollback rápido. Al confirmar se eliminan.
  38. ¿Preguntas?

  39. Thanks to __lucio__ and Guy Doulberg

  40. Gracias! Nicolás Demarchi @gilgamezh This work is licensed under a

    Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.