Desde septiembre comencé a medir la velocidad de conexion de mi enlace a internet y he publicado algunos resultados en twitter. Cada vez que publíco algo, me preguntan con qué mido o cual es la metodología que estoy ocupando.

Para no tener que estar repitiendo lo mismo cada vez, en este post voy a detallar el proceso que uso para obtener y procesar las mediciones.

¿Cómo mido mi velocidad de descarga?

Lo más importante es asegurarse que las condiciones de la conexión no cambien por "factores ambientales", por esto no es recomendable usar wifi para realizar las mediciones. Otro punto importante es medir la velocidad de descarga nacional, que es la que los ISP aseguran.

En mi caso, tengo un computador con linux conectado por cable a la red y que está encendido todo el dia. En este computador dejé programada una tarea, mediante un cron que corre cada media hora y descarga un archivo de 10MB

*/30 * * * * wget -O /dev/null http://nacional.grupogtd.com/archivos/10MB.bin 2>&1 | grep '\([0-9,]\+ [KM]B/s\)' >> test-velocidad.txt

Este comando genera un archivo con el siguiente formato

2015-12-17 05:00:04 (3,35 MB/s) - ‘/dev/null’ saved [10485760/10485760]
2015-12-17 05:30:04 (3,99 MB/s) - ‘/dev/null’ saved [10485760/10485760]
2015-12-17 06:00:07 (2,81 MB/s) - ‘/dev/null’ saved [10485760/10485760]
2015-12-17 06:30:05 (3,07 MB/s) - ‘/dev/null’ saved [10485760/10485760]
2015-12-17 07:00:03 (4,76 MB/s) - ‘/dev/null’ saved [10485760/10485760]
2015-12-17 07:30:04 (4,39 MB/s) - ‘/dev/null’ saved [10485760/10485760]
2015-12-17 08:00:10 (1,01 MB/s) - ‘/dev/null’ saved [10485760/10485760]
2015-12-17 08:30:04 (4,04 MB/s) - ‘/dev/null’ saved [10485760/10485760]
2015-12-17 09:00:11 (1,04 MB/s) - ‘/dev/null’ saved [10485760/10485760]
2015-12-17 09:30:04 (3,32 MB/s) - ‘/dev/null’ saved [10485760/10485760]

El formato de este archivo no es muy facil de procesar, por lo que lo transformo a CSV con este comando

awk '{gsub ("\\(","",$3); gsub(",",".",$3); gsub("\\)","",$4); print $1, $2 ",", $3 ",", $4}' test-velocidad.txt > test-velocidad.csv

El archivo resultante queda así

2015-12-17 05:00:04, 3.35, MB/s
2015-12-17 05:30:04, 3.99, MB/s
2015-12-17 06:00:07, 2.81, MB/s
2015-12-17 06:30:05, 3.07, MB/s
2015-12-17 07:00:03, 4.76, MB/s
2015-12-17 07:30:04, 4.39, MB/s
2015-12-17 08:00:10, 1.01, MB/s
2015-12-17 08:30:04, 4.04, MB/s
2015-12-17 09:00:11, 1.04, MB/s
2015-12-17 09:30:04, 3.32, MB/s

Este formato puede ser llevado fácilmente a excel o libreoffice para poder tabularlo o graficarlo. Para estos fines yo utilizo R, que es un lenguage de programación estadística que me permite obtener datos estadísticos básicos, generar gráficos y hacer modelos de predicción con los datos obtenidos.

Conclusiones

En este gráfico se puede ver como se ha comportado la velocidad de descarga durante el tiempo. Cada punto del gráfico representa una descarga del archivo.

Como se puede ver, mi velocidad de descarga en Septiembre era pésima, mejorando notoriamente en Octubre. Otra cosa que se puede visualizar es que a fines de noviembre, la velocidad de descarga nuevamente ha disminuido.

Una de las principales ventajas de GIT con respecto a otros controladores de versiones como SVN, es la preponderancia que da GIT a los procesos de branch y merge dentro de la herramienta.

Esta capacidad de GIT para crear ramas, permite elaborar nuevas formas de desarrollo, que antes no eran posibles,

Uno de los workflows más populares entre los desarrolladores es el Feature Branch, consistente en desarrollar nueva funcionalidad dentro de su propia rama y una vez terminado el desarrollo, ejecutar un merge con la rama principal.

Brancheo por ambiente

En el caso de integración y deploy continuo, podemos utilizar esta capacidad, a fin de aprovechar al máximo las capacidades de GIT a la hora de deployar nuevas versiones de la aplicación a los distintos ambientes.

Para esto, se utiliza principalmente el modelo Gitflow, el cual trabaja con ramas permanentes por ambiente, dejando para producción la rama master.

En este workflow, la corrección de errores se hace mediante feature branches, los que se añaden simultáneamente a las ramas master y de ambientes de desarrollo y staging (QA) y las nuevas funcionalidades, se desarrollan en una rama derivada de la rama de desarrollo.

Con este tipo de estructuras de repositorio, podemos generar trabajos de integración y deploy automáticos ante un nuevo commit en cada una de las ramas de ambientes.

Ansible es una herramienta de configuration management, que es parte de lo que se denomina "Infraestructura como Código". Esta herramienta permite definir una plantilla de configuración deseada, o playbook, y aplicarla en todos los servidores que queramos.

La gracia principal que tienen los Playbooks de Ansible es que están escritos en YAML, es decir, un archivo de texto plano, que es muy fácil de versionar. Estos archivos se ven así:

- hosts: all
  remote_user: root
  tasks:
  - name: Instala dependencias
    apt: name=python-pip state=present
    apt: name=python-virtualenv state=present
    apt: name=python-dev state=presenit
    apt: name=postgresql state=present
    apt: name=nginx state=present
    apt: name=git state=present

  - name: Crea usuario de aplicación
    user:
      name: "{{flask_user}}"
      groups: users,www-data

  - name: Crea virtualenv e instala paquetes
    pip:
      virtualenv: /home/{{flask_user}}/.virtualenvs/{{flask_app_name}}
      requirements: "{{flask_requirement_file}}"

La sintaxis de estos archivos es bastante simple de entender y seguir, por lo que se simplifica bastante su mantención y modificación futura.

Los módulos que trae por defecto Ansible, permiten provisionar ambientes en AWS, DigitalOcean, Docker o en cualquier servidor Debian o RHEL. Además, trae incorporadas utilidades como checkouts de código desde un repositorio Git, manejar servicios systemd, descarga de archivos, y un largo etc.

Usos prácticos

En estos momentos estoy utilizando esta herramienta para crear los ambientes de las aplicaciones que hago, desde el inicio. Cada nuevo paquete que instalo en mi ambiente de desarrollo y cada cambio en la configuración, lo agrego a un playbook de ansible y lo ejecuto con esta herramienta.

Esto permite que mis ambientes sean repetibles y me evito estar haciendo un manual de deploy.

Otro uso que hago de esta herramienta es el de hardening de servidores. Con el tiempo he ido mejorando algunas prácticas de securitización de ambientes, las que he vaciado a playbooks de ansible.

Lo que últimamente me ha llamado la atención es poder crear los servidores desde cero, dado un cambio de versión de sistema operativo o nuevos parches de seguridad que vayan apareciendo.

Esto último me permite revisar la compatibilidad de mis aplicaciones con los nuevos sistemas operativos y versiones de librerías que vayan apareciendo.

Finalmente, los experimentos que he estado haciendo se han basado en tratar de integrar ansible con herramientas como Jenkins o Bamboo, las que permiten generar releases de aplicaciones, con pruebas automáticas de código.

No me ha ido muy bien en esta parte, dado que estas herramientas están más orientadas a la integración continua, más que a la entrega de artefactos de código a ambientes productivos cambiantes (como es el caso de generación de ambientes dinámicos en la nube).

Hace tiempo quería volver a escribir un blog, pero no me había dado el tiempo ni las ganas. Pero como ahora estoy estudiando más seriamente varias ideas y tecnologías nuevas (y no tan nuevas) que andan dando vueltas por ahí, es un buen momento para retomar la escritura.

Primero, estoy muy interesado en este mundillo de DevOps ya que me parece que todo el movimiento ágil se sentía un poco cojo sin atacar el problema del deployment de las aplicaciones y el manejo de la infraestructura.

Estoy experimentando con herramientas como Ansible, SaltStack y Docker y complementándolas con otras que ya usaba, como git hooks y jenkins principalmente. Por lo que aprovecharé de guardar aquí lo que vaya aprendiendo y creando.