Migrando Rails Apps entre Cloud y Bare Metal Servers
Descargar como PPTX, PDF0 recomendaciones561 vistas
El documento narra la experiencia de migrar una aplicación de Ruby on Rails desde servidores físicos a una nube privada, destacando el proceso de desarrollo, implementación y los desafíos enfrentados. A lo largo de la migración, se abordaron problemas de rendimiento, replicación de datos y optimización de servidores, culminando en una exitosa transición con un uso efectivo de nuevas tecnologías. A pesar de algunos inconvenientes, la migración resultó en un aumento significativo de capacidad y lecciones valiosas para futuros despliegues.
![Dejandorastros – Rails side
• Reemplazar Rails Logger
– Una sola linea, se hace ‘grepable’
• Enmascarardatossensitivos
– Rails.config.filter_parameters+=
[:card_number, :cvv]](https://image.slidesharecdn.com/migracioncloudbaremetalservers-120607161236-phpapp01/85/Migrando-Rails-Apps-entre-Cloud-y-Bare-Metal-Servers-34-320.jpg)
![Capistrano
$ capify .
[add] writing './Capfile'
[add] making directory './config'
[add] writing './config/deploy.rb'
[done] capified!](https://image.slidesharecdn.com/migracioncloudbaremetalservers-120607161236-phpapp01/85/Migrando-Rails-Apps-entre-Cloud-y-Bare-Metal-Servers-37-320.jpg)
Migrando Rails Apps entre Cloud y Bare Metal Servers
- 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
- 32. haproxy
- 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!
- 41. Capistrano(deploy.rb) current_path current_release shared_path
- 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
Notas del editor
- #2: Soy el principal software engineer en Cowd Interactive, teoricamentetodopasasobre mi
- #3: Antes que nada quieroplaticarunapequeñaplatica de comouna startup podriaircreciendodesde la nada hastatenermuchos, muchosusuarios
- #4: Se teoicurre la million dolar idea, va a revolucionar el mundo, va a pegar….
- #5: Unacaja de bebidasenergizantes, yempiezaas a diseñar el mvp
- #6: Ya no tienesjefesquetediganquelastecnologias no son establestodavia, que no son compatibles, etc, etc, etcEmpizas a meter cutting edge technologies
- #10: A la par, vas a buscar a tu co founder
- #13: Con cervezastodo se entiende, en un ambientemas relax todos se entienden
- #15: Se tiene un produdctoestable, porsupuesto, comousaron ruby on rails, se lo aventaron super rapido!
- #18: Primer outage, codigo no estabaoptimizadoy los procesos se matabandespues de ciertotiempoportantoprocesamiento
- #19: Carece de buenadocumentacionY a dondenosllevatodoesto,
- #21: Actualizaciones en tiempo real
- #23: Migrar app servers de mono proceso a forkeado con multiples workers y se ahorramuchamemoria
- #26: No se va a tolerarmas los outages
- #28: Como configurarnuevosservidoresparaagregarlos
- #29: En frenteservidor web, recibelaspeticionesyasapor https o normal
- #31: Se hanpreguntadocomoponen la pagina de mantenimiento, sin reiniciar el web server ?
- #33: Balanceador de packetes HTTP/TCP de alto rendimiento