Site Reliability Engineer

Bueno, ha llegado el día en el que publico un resumen (muy básico y que seguramente iré actualizando) de lo que entiendo es un SRE y sus funciones básicas. Allá vamos.

¿Qué es un SRE?

Hay muchas definiciones de lo que es un SRE, pero me quedo con ésta de Microsoft:

Site Reliability Engineering is an engineering discipline devoted to helping an organization achieve the appropriate level of reliability in their systems, services, and products.

Y que complemento con esta frase sacada del libro de SRE de Google:

In general, an SRE team is responsible for the availability, latency, performance, efficiency, change management, monitoring, emergency response, and capacity planning of their service(s).

Hago especial hincapié en lo de conseguir los niveles de fiabilidad apropiados. El 100% de uptime no es el objetivo de un SRE. En realidad, una caída del servicio no se ve ya como algo «malo» si no que es una oportunidad para que los desarrolladores y los SREs mejoren los sistemas.

Continuar leyendo «Site Reliability Engineer»

EBS/RDS Snapshots

¿Cómo funcionan los EBS snapshots?

Los snapshots de EBS son incrementales (excepto el primero que hagas sobre un volumen EBS); únicamente incluyen los bloques modificados desde el último snapshot. Cada snapshot contiene la información necesaria para hacer un restore completo de tus datos hasta el momento de hacer el snapshot, es decir, contiene referencias a los snapshot anteriores, lo que permite realizar un full restore (hasta el momento de hacer el snapshot) a partir de ese determinado snapshot.

[Fuente]

¿Se puede eliminar un snapshot EBS de forma segura?

Cuando eliminas un snapshot, solamente se eliminan los datos únicos de ese snapshot. Es importante recalcar que aunque el snapshot se elimine, los datos referenciados por otros snapshots se mantendrán. A la práctica ésto significa que si no necesitas poder hacer restores desde las fechas/horas específicas en las que se realizaron los diferentes snapshots, puedes eliminarlos todos excepto el último, que aun así podrás realizar un restore completo.

[Fuente]

Continuar leyendo «EBS/RDS Snapshots»

Un primer vistazo a Puppet


Bueno, hoy traigo un popurrí de conceptos sobre Puppet que espero sirvan para tener una primera idea de algunas de sus características y opciones. Si eres un master of puppets, éste no es tu post.

Puppet es una de las herramientas de gestión centralizada de servidores (y workstations) más conocidas. En su página web, ofrecen varios videos gratuitos que explican con más detalle qué es y cómo funciona.

Bolt y Puppet Tasks

Bolt: standalone, opensource agentless task runner para ejecutar ad-hoc imperative tasks en entornos pequeños.

$gem install bolt

Puppet tasks: para resolver tareas que no encajan bien en el modelo tradicional puppet. Las Puppet Tasks son una forma simple y rápida de actualizar paquetes al instante, reiniciar servicios o ejecutar cualquier otro tipo de acción similar en tus nodos.

# Ejecuto un comando en dos nodos (boron2 y boron5)
$bolt command run "netstat -an | grep 'tcp.*LISTEN'" -n boron2,boron5

# Pongo mis comandos en un script en cualquier lenguaje que entiendan mis nodos. 
# Este script se copiará a los nodos, en un dir temp, lo ejecutará, devolverá 
# el output y después lo eliminará
$bolt script run myscript.sh -n boron-2,boron-5

Continuar leyendo «Un primer vistazo a Puppet»

Usa diferentes versiones de terraform con tfenv

Cuando trabajas en grandes entornos gestionados con terraform, es muy probable que tengas que trabajar a su vez con diferentes versiones de terraform, según requieran cada unos de los proyectos.

En lugar de descargar las diferentes versiones que necesitemos, renombrando los ejecutables, moviéndolos a algún directorio dentro del PATH y jugando con enlaces simbólicos, podemos símplemente usar el maravilloso tfenv.

Descarga e instalación

Para empezar a usar tfenv, lo único que necesitaremos será clonar el repositorio (por ejemplo en nuestra home) y crear un enlace simbólico para que tfenv esté disponible en el PATH.

[adri@adri ~]$ git clone https://github.com/kamatama41/tfenv.git ~/.tfenv
Cloning into '/home/adri/.tfenv'...
remote: Counting objects: 716, done.
remote: Total 716 (delta 0), reused 0 (delta 0), pack-reused 716
Receiving objects: 100% (716/716), 102.65 KiB | 0 bytes/s, done.
Resolving deltas: 100% (449/449), done.
Checking connectivity... done.

[adri@adri ~]$ sudo ln -s ~/.tfenv/bin/* /usr/local/bin

Continuar leyendo «Usa diferentes versiones de terraform con tfenv»

Integración Continua vs Continuous Delivery vs Continuous Deployment

delivery

Bueno, lo primero es lo primero: este post no es la verdad absoluta, así que si vienes en busca de iluminación, espero que esta entrada sirva como punto de partida, pero te recomendaría leer todo lo posible sobre este tema, empezando por consultar los enlaces del final del post.

Por mi parte, con esta entrada he querido resumir los conceptos principales de cada una de estas prácticas, para intentar aclarar(me) con las diferencias entre ellas.

Integración Continua

Los equipos de desarrollo de software que trabajan en un mismo proyecto, suelen encontrarse a menudo con los siguientes problemas:

  • Merge conflicts: dos programadores modifican el mismo fichero o incluso la misma línea, lo cual da lugar a conflictos que deben resolverse y que pueden llegar a ser un quebradero de cabeza.
  • Compile conflicts: si por ejemplo un programador usa el método foo() y alguien elimina ese método, ésto no dará problemas al hacer el merge, pero a nivel de compilación dará error porqué no encontrará ese método.
  • Test conflicts: un ejemplo de test conflict sería cuando tu código depende de otro que ha cambiado (y ahora funciona diferente), lo cual haría que tu código no esté funcionando como esperabas y por tanto tu código no pase los tests.

La integración continua es una práctica de desarrollo de software que pretende minimizar este tipo de conflictos, permitiendo a las desarrolladores desarrollar, en lugar de perder su tiempo solucionando conflictos. La idea básica es que los desarrolladores commiteen los cambios muy frecuentemente (al menos una vez al día) para que en caso de conflicto se puedan solucionar de forma más rápida y sencilla, pues el propio programador tendrá el código que acaba de commitear “fresco” en su cabeza, y además no tendrá que preocuparse de investigar grandes cantidades de código, pues al commitear muy frecuentemente sabe que ha cambiado poco código desde su anterior commit.

La integración contínua, pues, consiste en automatizar los tests y los builds de tu software muy frecuentemente. A no ser que seas el único desarrollador en un proyecto, no hay razón por la que no quieras usar integración continua.

Continuar leyendo «Integración Continua vs Continuous Delivery vs Continuous Deployment»