Platica dada en MagmaRails 2012, aqui comparto mis experiencias de migrar aplicaciones rails de bare metal servers a custom cloud, de PaaS a bare metal servers y todas las combinaciones. Cualquier pregunta twitter: softr8

1. Migrando Rails Apps entre Cloud
y Bare Metal Servers
Edwin Cruz
Crowd Interactive, MagmaRails 2012

2. El diario de un CTO/Techy Co-founder

3. Dia 1
• Million dollar idea!
• Investigación de mercado (alguienmásya lo
hizo?)

4. Dia 2
• Compraunacaja de bebidasenergizantes
• Diseña el MVP

5. Dia 3
• Empieza a codificar la aplicacion

6. Dia 3-7
• Café
• Café
• Bebidaenergizante
• Café
• Dormir

7. Dia 7-10
• Se tienealgoestable
• Hora de buscar co-founder
– Inversionistas al parecer le creenmas a un grupo
de gente

8. Dia 1, Co-Founder
• Million dollar idea!
• Investigación de mercado

9. Dia 2
• Diseñasu MVP
• Hacemásinvestigacion
• Buscatechy co-founder

10. Dia 3
• Meetup

11. Dia 4
• Meetup

12. Dia 6
• Drinkup
– Lo encuentra!

13. Dia 7
• Empiezan a trabajar

14. Dia>10
• Tienen un productoestable
– MVP
We <3 ruby on rails

15. Primer Paso
• Hosting para la app
– Heroku
• $ herokuapps:createmillion_dollar_stage
• $ herokuapps:info | grep 'Git URL'
• $ git remote add heroku GIT_URL
• $ git push heroku master
• $ heroku run db:migrate
– Engine Yard
• Click, copy, paste, click
• ey deploy….. Deploy!

16. Como hacer un deployment?
• git push heroku master
• Click Deploy, ey deploy

17. Dia>20
• Usuariosreales
– Picos de latencia
• Primer outage
– Instanciaspequeñas
– Base de datoscompartida

18. Asique…
• Recap
– Ya no tienesjefesdiciendoquelasnuevastecnologias
no son lo suficientemente ‘estable’ parausarla
• Cutting edge technologies
– Muyprometedoras
– Pocadocumentación
– Developer felices

19. Sobrecarga de trabajo
• Contratación de nuevos developers
• Empiezadesarrollo de features en paralelo

20. Siguenllegandomásusuarios!
• Production database
• CDN
• Más app servers
• Pusher
• La million dollar idea estodo un exito!

21. Trabajando en conjunto
• Mas killer features
• Third party services
• Performance issues
• NewRelicProfesional
– Redisparasesiones
– Memcached fragment cache

22. Nuevas feature
• Share with your friends!
– Mastráfico
– Base de datos, el nuevocuello de botella
– Dobletea la capacidad!
• Actualizaciones en tiempo real
– Estanmatando los app servers!
– Migrar a app servers diseñadosparasoportar
forking

23. Nuevas features
• Background processing
– Resque al rescate!
• Phew, ya se teniaredis
– Mismosrecursos
• Mejoresestrategias de cache yexpiración
• Todobajo control.

24. Noticias del CEO
• Nuestraaplicacionva a ser promocionada en
un canal de television a nivelnacional!!
– OMG, a correr!
– Pronostico: 3x trafico del picomás alto a la vez
• Triplicar la capacidad?
• Click, click, click…. Listo
– Al final de més, “quequuueee, yestafactura?”
– En pocotiempoya se estanusandoesosrecursos

25. Noticias del CEO
• Necesitamos uptime de 99.997
– Deployment transparentes
– Mascapacidad
– Staging environments

26. Deuda de Ingenieria
• Muchos ‘add ons’
• Facturaciónva en aumento
• Ambientes de staging ‘iguales’ queproduccion
– QA
• Sincronizacion de datosdesdeproducción
– Base de datos
– Imagenes
– Usuarios, actualizar emails con ficticios
• Etc. == $$$$$$

27. Deployment desde cero
• Rails stack
– Web server
– Balancer/proxy
– App servers
– Database server
– Fulltext search engine
– Cache
– Deployment scripts
– Bootstrapingnuevosservidores

28. Arquitectura
nginx
haproxy
Unicorn Unicorn Unicorn
fork fork fork
fork fork fork
fork fork fork
db

29. Antes que nada
• Quees un gem
• Quees bundler
• Nuestro amigo el Gemfile
• Capistrano
• Chef
• RVM
• Rbenv

30. Web Server

31. Dejandorastros - Nginx

32. haproxy

33. Deployments transparentes

34. Dejandorastros – Rails side
• Reemplazar Rails Logger
– Una sola linea, se hace ‘grepable’
• Enmascarardatossensitivos
– Rails.config.filter_parameters+=
[:card_number, :cvv]

35. Problemascomúnes
• RepositoriosPrivados
– Crearcuentacompartiday registrar llaves de los
servidores
• Firewalls
– bundle pack
• Gems paradesarrollo con
dependenciasespeciales
– bundle install –without development test

36. Capistrano
• Herramientaparahacer de
maneraconsistente, repetitivaygarantizada, de
ployments de aplicaciones.
• Scripts (recipes)
– Ejecutan commandos de maneraremota via ssh

37. Capistrano
$ capify .
[add] writing './Capfile'
[add] making directory './config'
[add] writing './config/deploy.rb'
[done] capified!

38. Capistrano(deploy.rb)

39. Capistano(deploy.rb)

40. Capistrano
(deploy.rb)

41. Capistrano(deploy.rb)
current_path
current_release
shared_path

42. Capistrano(recipes)

43. Capistrano
• Como desarrollarfacilmente?
– Vagrant
– Chef-solo

44. Vagrant

45. Migrando una app de servidores
físicos a una nube privada con ~15
mins de downtime

46. EventosPrincipales
• 8 Meses antes
– Se empezó a experimentar con Joyent smart
machines
– Complian con los SLA(Service Level
Agreement)internos
• No eraninstanciasvirtuales
• Son delimitadasporzonas
• No son ambientesvirtuales
• Rentaera mensualfijay no porusage
• SmartOS(solaris)

47. EventosPrincipales
• 6 Mesesantes
– Environments de demo se instalaron
• Todo en una sola instancia
– Nginx, mysql, RoR app
– JoyentproveiaPercona Smart Machines
• Joyenttrabajo con Perconaparacompilar lo
masoptimizado los binarios
• La aplicacion se migró a percona 5.1 de mysql 5.0.56

48. EventosPrincipales
• 4 Meses antes
– Ambiente de Staging en Joyent
• Se diseñoparadespues ser promovidocomo elnuevo
cluster de produccion
• 2 clusters
– 1 balanceador
– 8 app servers
• Percona smart machine
– 1 Master
– 2 replicas
– Se compro un nuevodominio

49. EventosPrincipales
• 3 meses antes
• Los Sysadmins se empezaron a quedarcalvos
– El ataque de ImageMagick!!!
– Se usabangemasespecificasparalinux
• Leianmac addresses, en zonas, no se tieneacceso a
lasmac address desde un solaris
• UUID generator estabaroto, lassesionescolisionaban

50. EventosPrincipales
• 2 Meses antes
– Incertidumbrepor el rendimiento
• Se hizo un stress performance muydetallado
• Httperf, ab, loadrunner
• Se optimizaronconfiguraciones
– HAProxy, queue time yestrategia de balanceo, last connection
vs round robin
– Nginx, se recompiloparausarotrodirectorio temporal
– MySQL, innodb buffer size al 70% de
memoriayarchivoportabla

51. EventosPrincipales
• 1.5 meses antes
– Si! Si lo hacemos…. ( comprandomisboletos a San
Francisco, uno con el viaje normal yotro con
regreso al diasiguiente )
– Trabajoexaustivo con
capistrano, debiasoportarhacer deployment a dos
ambientes

52. EventosPrincipales
• 1 Mes antes
– Se configuró la replica mysql multi-site
• El slave en joyent se promoveriacomo el master el dia
del movimiento
• En promedio 17 minutosatras del master
– En vez de usar el cluster de stage
comoproducción, se contrataronunoslimpios, se
corrieronlasrecipies de chef ycapistrano
• ImageMagick again!!! grrrrrr

53. EventosPrincipales
• 2 Semanas antes
– Planeodetalladominutoporminuto lo quepasaria
• QA Pidio 2 hrs paravalidacion, wait what!???
– Miercoles 11pm empezariatodo

54. EventosPrincipales
• 1 Semana antes
– Se saco un respaldocompleto de producciony se cargo en
la replica en joyent
• Replicacion multi-site trabajandobien
– Reglas del nginx
• Reroute, entre clusters
• Down page, pagina de mantenimiento
• Redirect, redireccion multi-site
– DNS TTL al minimo
– Jueves 12 am pagina de mantenimiento…. pagina de que?
• No teniamospaginas de mantenimiento!!!! (alguiengritandole a los
diseñadores)

55. EventosPrincipales
• 2 dias antes (Lunes)
– Oh no!!! No teniamostareas de
capistranoparaactivarlasreglas del nginx
– Se puso la pagina de mantenimientoque los
diseñadoreshicieron
– Todobajo control, a descansar

56. EventosPrincipales
• 1 diaantes(Martes)
– SysadminsyDevOpsdescansando, dia off

57. EventosPrincipales
• El Dia de la migracion
– SysadminsyDevOpsllegando a la oficina ~5pm
– Ultimo dump de produccion se carga en la replica
• Oh ho!, la vpnextremadamentelenta, 8pm ydecia 14000
seconds behind master, shit!
• Se hizo un tunelsshpor la interface externa (viajandopor
internet), en 14 minutos se sincronizo
• Todolisto

58. EventosPrincipales
• Despues de 11pm
– Se empezotardepor la replica lenta
• Pagina de mantenimiento
• Esperarbackgrond jobs terminaran
• Apagartodos los app servers
• Esperar la replicaterminara de sincronizar master y se
promoviocomomaster
• Arrancar la aplicacion en joyent con el nuevo master
– Todoestonostomo 7 minutos!

59. EventosPrincipales
• Validando la aplicacion
– QA validopor un dominio especial
– 8minutosdespues, dio sign off
– Seactivaronlasredirecciones en nginx multi-site
– Se cambio el dns
– A rellenar la cafetera!
– 2 minutosdespues, callo la
primeraorden,Fiuuufff!!!!!

60. EventosPrincipales
• 3 hrs despues de la migracion
– ImageMagick issues!!
• Crap! Algunasimagenes se servianpor
PNG, eImageMagick no fuecompilado con soporte
PNG, a recompilartodos los clusters
– Se prendieronserviciosexternos
– Se levantootrareplicacionmuti-site de joyent a
rackspace
– Se arrancanaplicacionesinternas

61. EventosPrincipales
• 8am diasiguiente
– Ya se puedenir a dormir
– En el camino
• Riiiing! “El distribution center no recibeordenes!”
• Problemas de replicacion de dns, no se hizoreplicacion
multisite paraaplicacionesinternas, se harcodeo la
nueva IP en /etc/hosts, solved…
– A Dormir

62. Eventosprincipales
• Despues de la migracion
– Performance issues
• Base de datos 5x maslenta, nadiesabiaporque
– Servidormasgrande
– Filesystem mucho muytuneado
– Al final, despues de 2 semanas, se encontro el problema:
binarioscompilados con gcc 3.x, great! |-(
• Ruby poor performance, no tomabalas environment
variables del REE paratunear el garbage collector
• El directoriotmp se hizomasgrande

63. EventosPrincipales
• Al final:
– 20 ms mas lento que en rackspace
– 60% menos de facturacion
– Podemoscrecer on demand
– Sobrevivimosunaventa con un pico de 21k
rpm,350 clicks porsegundo!!!!

64. Tiempo para preguntas?
Gracias!
Edwin Cruz
@softr8