Gestiona Varias Cuentas de Heroku desde una misma Terminal

Las 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.

Popurrí de Jenkins

Cuando 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.

Cómo Configurar Registros NS de Mailgun en Namecheap

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.

BKT En Producción: Cloud-init

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.

BKT en Producción: AWS y Otros Servicios Usados

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:

• EC2: Elastic Cloud Computing
• S3: Simple Storage Service
• SES: Simple Email Service
• SNS: Simple Notification Service
• Code Deploy
• Lambda
• AMI: Application Machine Images
• IAM: Identity and Authorization Management
• ELB: Elastic Load Balancer
• RDS: Relational Database Service
• Cloudfront
• Auto Scaling

Entre los servicios y herramientas usados por fuera de AWS están:

• Sentry
• Papertrail
• Logentries
• Slack: para notificaciones de despliegues
• Jenkins
• Terraform
• Packer
• Skylight
• New Relic

AWS, siglas para lo que te imagines

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.

Servidores: ¿Mascotas o Ganado?

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.