Se sabe bien que subir aplicaciones web a Heroku es sencillo. En muchos casos es solo cuestión de correr comandos en la terminal y con una que otra configuración solo con subir los cambios al repositorio basta.
Y si bien tenemos esa facilidad, hay cosas que Heroku deja de hacer por conveniencia, ahorro o que sé yo. Tal es el caso de la ejecución de migraciones cuando se despliegan aplicaciones Ruby on Rails en este servicio.
seguir leyendoCuando se trabaja con Heroku mandar cambios es bastante sencillo. Generalmente, consiste en ejecutar un comando de terminal:
$ git push heroku master
En todo caso, como Git promueve el uso de ramas cada que trabajamos en algo nuevo o cuando se quiere probar una idea, termina siendo contradictorio unir cambios en la rama master que no son fiables o definitivos.
SEGUIR LEYENDOCuando se trabaja en aplicaciones Ruby on Rails es muy frecuente ir agregando campos a las tablas o nuevas tablas cada tanto tiempo en las etapas iniciales de los proyectos.
A medida que se llega a un punto estable o con muchas características implementadas, se reduce la cantidad de migraciones a generar.
También ocurre que al estar en etapas tempranas nos sentimos con mayor libertad de destruir la base de datos para facilitar el añadir nuevos campos o porque hay mucha información inservible que complica correr migraciones nuevas.
SEGUIR LEYENDOLas aplicaciones web las podemos publicar normalmente en servidores web. Generalmente, un servidor Linux con algún sabor bien sea Ubuntu o CentOS.
Antes de poder empezar a usar la aplicación alojada en un servidor web, toca configurarlo con todo lo necesario para que el software se ejecute. En el caso de aplicaciones frontend(escritas en React o Angular) puede ser necesario instalar y configurar Nginx/Apache, NodeJS y uno podría darse por satisfecho.
Cuando nos vamos a otros frameworks, como el que escribo en este blog, Ruby on Rails, toca instalar más librerías y dependencias.
Con el tiempo uno se acostumbra y aprender a generar scripts que hagan estas configuraciones más rápido y con menores problemas. En todo caso, no deja de ser tedioso tener que mantener y actualizar dichos scripts o entornos en la nube.
sigue leyendoCuando empecé mi carrera como desarrollador web ya en el mundo real, sabía muy poco sobre todo lo que el proceso de crear software conlleva. Todo era nuevo. Lo único que sabía era HTML, CSS, algo de JavaScript y algo de PHP.
En esos primeros años aprendí demasiado. Conocí Git, Rails, RSpec, Capistrano, Bash, Drupal, Linode, etc, etc. Si bien descubrí nuevas herramientas y tecnologías, me faltaban procesos.
Leer más “Popurrí de Jenkins”Mailgun es un servicio que se puede usar para el envío masivo de correos desde software. Sea una app móvil, una app web o trabajos en segundo plano. Cuenta con una muy buena capa gratuita y para empezar a usarlo no es necesario registrarse con tarjeta de crédito(aunque más adelante pueda que sí tengas que).
Servicios similares a Mailgun son Sendgrid y Amazon Simple Email Service(o SES). No hay nada malo en usar alguna de las alternativas. Solo es cuestión de preferencia del momento.
En fin, resulta que para poder enviar correos a cualquier destinatario, normalmente, se debe validar un dominio en alguno de los servicios mencionados. Esta validación tiene como propósito(entre otros cuantos) impedir a spammers que se aprovechen del servicio para sus fechorias.
Sigue leyendoHeroku es una muy buena plataforma para montar aplicaciones casi que sin despeinarse. Su modo de operar es denominado PaaS, es decir, Plataforma como Servicio(en inglés Platform as a Service). Ser una PaaS quiere decir que al usuario le das lo más que se pueda desmenuzado y listo para usar.
A diferencia de AWS que es una IaaS(Infrastructure as a Service) en Heroku, generalmente, hacer despliegue de aplicaciones solo implica un comando y casi cero configuraciones.
Leer más “Heroku y Sentry, Habilitar metadata del Dyno”Retomando la serie empezada el año pasado, en esta ocasión compartiré un poco sobre una herramienta que conocí en este proyecto y la cual permite hacer muchísimas cosas al crear instancias de máquinas virtuales en la nube.
Leer más “BKT En Producción: Cloud-init”En este segundo artículo de la nueva serie que estaré publicando presentaré una serie de servicios y herramientas que se usaron para dejar el software del que esta serie trata funcionando en producción.
Toda la infraestructura se montó en AWS. Fue una combinación de servicios estándar y uno que era relativamente nuevo y en ese entonces aún se actualizaba constantemente.
Los servicios en cuestión son:
Entre los servicios y herramientas usados por fuera de AWS están:
Antes de iniciar en este proyecto, la primera vez que vi la consola de AWS me dio pánico. Eran demasiadas opciones y no sabía por donde empezar. Una semana antes de empezar este nuevo software tuve la oportunidad de hacer un curso de AWS(en Platzi, gracias, Yohan Graterol) en el cual pude aprender a usar los servicios básicos de esta plataforma: EC2(con todo lo que tiene) y RDS.
Se podría considerar a EC2 como un mini mounstro dentro de AWS ya que se compone de ELB, Auto Scaling, Elastic IP, Security groups, AMI y todo el tema de instancias en subasta y/o dedicadas.
Recuerdo, hace ya varios años, en una empresa pequeña en la cual trabajé un día mi jefe me encargó una tarea que me hizo coger gusto e interés en el mundo de operaciones o lo que suelen llamar DevOps.
Se me acerca un día miércoles o jueves y me dice:
Frank, el servidor dedicado nos cuesta X cantidad de dólares. Si el sábado logras migrar todos los sitios web que están ahí hospedados a servidores en Linode, te doy esa X cantidad a ti. Sino, toca pagar y en todo caso debes hacer la migración.
Ya venía trabajando algún tiempo con configuraciones en Linode por lo cual no había tanto desconocido pero la tarea pedía completarse en tiempo casi récord. Bueno, al final de la historia lo logré pero el resultado fue 20, aprox, servidores(más direcciones IP, más DNS, etc) que debía gestionar a diario.
