Escalando equipos de desarrollo con Docker

Cómo almundo se apoyó en docker para pasar de ser una empresa de turismo con 5 desarrolladores y 1 server (en las mismas oficinas) sirviendo su site, a una empresa de tecnología con más de 100 devs y 900 servers en cloud.

Transcript

1. ESCALANDO EQUIPOS DE DESARROLLO CON DOCKER Franco Morinigo franco.morinigo@almundo.com @foobarfran
2. 2014 2015 2016 2017 • 1 server en las oficinas, sirviendo html desde php • 5 desarrolladores
3. DESARROLLAR TODO DESDE 0 Flights ∞ Fraud Screening Hotels Payments Cars Reservations Manager Geo Rewards
4. ESCALAR LAS APPS HORIZONTALMENTE
5. ESCALAR EL EQUIPO DE DESARROLLO
6. API /flights/itineraries /flights/reservations /flights/foo FRONTEND /home /flights /foo
7. • 20 apps • 50 servers • 20 developers • 2 sysadmins 2014 2015 2016 2017
8. DEVELOPERS • Codean nuevos features, fixes, etc. • Entregan un empaquetado dependiendo del lenguaje (jar, bundle de js, etc) SYSADMINS • Provisioning de cada vm dependiendo del lenguaje. • Scripts de deploy y startup de cada app dependiendo del lenguaje y muchas veces de cada app en particular.
9. DEVELOPERS PAINS • Cuello de botella en el equipo de sysadmin ya que tienen mucha responsabilidad. • Desarrolladores que solo conocen su código y no el stack real de su app. • Dificultad de innovar debido a que las recetas para cada lenguaje son compartidas por todos las apps y no es trivial hacer un cambio manteniendo retrocompatibilidad.
10. SYSADMINS PAINS • Ecosistema complejo de recetas para cumplir con las necesidades de todas las apps. • Dificultad de cambiar esas recetas puesto que muchas contienen "if FOO- APP then ..." que con el tiempo nadie sabe por qué están o por qué surgió esa necesidad. • Es imposible para el equipo de sysadmins mantener las últimas versiones y features de cada runtime environment para cada lenguaje ya que no es la tecnología con la que trabajan ellos la mayor parte de su tiempo. • Escalado horizontal de las apps de forma manual.
11. 2014 2015 2016 2017
12. ENTREGABLE STANDARD docker-compose.yml ENVS • environment (development | staging | production) • host ip • host hostname
13. STARTUP SCRIPT STANDARD wget $PARAM_DOCKER_COMPOSE_URI docker-compose pull docker-compose stop -t $PARAM_TIMEOUT docker-compose rm -f -v export ENVIRONMENT=$ENVIRONMENT docker-compose up -d docker system prune -a -f
14. JAVA WEB APP fooJavaWebApp
15. FRONT APP varnish nginx node /public
16. MEJORAS • Debugging remoto y conexión con JMX a la JVM. • Manejo de distintas versiones de los agentes como NewRelic por cada app. • Cada app empezó a manejar su versión de node, pm2, etc. • Apps que necesitan cosas específicas del sistema operativo como scrappers con PhantomJs. • Etc, etc.
17. CAMBIAR CONFIGS EN CALIENTE fooJavaWebApp wget /app/config --volumes-from
18. PROBAR NUEVAS HERRAMIENTAS Y PONERLAS EN PROD
19. MANEJO DE SECRETS metadataproxy fooApp IAM ROLE: api-instance IAM ROLE: api-secrets get and assume role IAM ROLE: api-secrets IAM ROLE: api-secrets aws kms 169.254.169.254 IP TABLES RULES
20. ENCAPSULAMIENTO DE APPS LEGACY fooPHPApp barRubyApp • --autorestart • Levantar la app localmente para bugfixing
21. ENCAPSULAMIENTO DE APPS TERCERIZADAS fooLandingPage
22. BUILDS # Buildtime Image FROM node:boron-alpine as build WORKDIR application COPY package.json package.json RUN npm i COPY . . RUN npm run build # Runtime Image FROM node:boron-alpine as build COPY --from=build application application EXPOSE 5000 CMD node application/dist/app.js
23. PROCESO DE ADOPCION • Imágenes base dependiendo de cada tecnología JVM params remote debugging jmx new relic config de pm2
24. PROCESO DE ADOPCION • Capacitaciones a los equipos dependiendo de su especialidad.
25. PROCESO DE ADOPCION • Retrocompatibilidad del flujo de CI. /flights/itineraries (PR) /flights/itineraries (ST) /flights/itineraries (DV)
26. 2014 2015 2016 2017 • 20 apps 100+ apps • 50 servers 900+ servers • 20 developers 100+ developers • 2 sysadmins 3 sysadmins
27. DEVELOPERS PAINS • Cuello de botella en el equipo de sysadmin ya que tienen mucha responsabilidad. • Desarrolladores que solo conocen su código y no el stack real de su app. • Dificultad de innovar debido a que las recetas para cada lenguaje son compartidas por todos las apps y no es trivial hacer un cambio manteniendo retrocompatibilidad.
28. SYSADMINS PAINS • Ecosistema complejo de recetas para cumplir con las necesidades de todas las apps. • Dificultad de cambiar esas recetas puesto que muchas contienen "if FOO- APP then ..." que con el tiempo nadie sabe por qué están o por qué surgió esa necesidad. • Es imposible para el equipo de sysadmins mantener las últimas versiones y features de cada runtime environment para cada lenguaje ya que no es la tecnología con la que trabajan ellos la mayor parte de su tiempo. • Escalado horizontal de las apps de forma manual.
29. LECCIONES APRENDIDAS Docker puede mejorar el proceso de desarrollo usándolo out of the box Excelente herramienta de desacople Posibilitador de innovación
30. • Orquestar containers en múltiples proveedores de cloud • Logging • Integration tests 2014 2015 2016 2017 2018
31. MUCHAS GRACIAS