Ir al contenido principal

Anuncio de verano veranete

Aunque San Lorenzo se está portando y no nos está castigando, desde La Brecha Digital no podemos negar que el veranito ya ha llegado.

Esto se está notando como todos los años en una reducción en la presencia a las sesiones. Por ello creemos que no merece la pena que la gente se prepare sesiones para que solo vayan unas pocas personas.

Y tampoco nos engañemos, despues de un añito de curro también nos apetece descansar un poco de la obligación de abrir todos los miercoles.

Por ello colgamos el cartel de vacaciones hasta la asamblea del 2018-09-05.

Significa esto que no nos vamos a reunir en la brecha digital hasta entonces?

No exactamente, los que estamos tirando más del carro últimamente nos queremos quitar la "obligación" de abrir, no obstante es probable que una o dos veces al mes nos reunamos para hacer taerillas o algún cineforum.

Puede que de ser así lo plasmemos en el blog, pero es más probable que las quedadas se organicen de manera improvisada a través del canal de jabber brechadigital@sala.chat.cslabrecha.org.

Así que si quieres ir un miercoles, métete en el canal y dínoslo, si somos gente suficiente puede que nos acerquemos.

Buen verano!

Asamblea: 2018-07-11

Este míercoles, 11 de Julio vamos a reunirnos en Asamblea.

Aprovecharemos para planificar que haremos este mes con el comienzo del verano. Animamos a participar a todo el mundo que esté interesado puesto que no son densas y se tratan temas técnicos.

El orden del día es el siguiente:

  • Rotado de responsabilidades
  • Elección de las temática de cada miércoles
  • Anuncio sobre temas de actualidad
  • Revisión de las tareas del mes pasado
  • Plan de tareas para este mes
  • Varios

Para agilizar el planning del mes siguiente, es muy recomendable revisar las incidencias abiertas y pensar en qué podríamos centrarnos.

Un saludo!

Mantener Git limpio

Si has utilizado git de manera habitual estarás familiarizado con los repositorios con miles de ramas ya mergeadas, tanto en local como en el repositorio remoto.

Esto hace que por ejemplo cuando quieras hacer un merge request sea muy pesado buscar la rama que quieres mergear.

En esta tarea nos propusimos revisar como hacer una limpieza automática.

Como aún le estamos quitando el polvo a nuestra nueva mascota, drone (os podéis logar con los credenciales de gitea), pensamos que estaría bien que un paso de la integración continua fuese el limpiar las ramas mergeadas.

Nos pusimos manos a la obra, hicimos un docker para que drone lo lanzase durante este paso. Este tenía git y ssh ya que como es un proceso automático no se podía clonar con credenciales https.

Por lo tanto el docker cogía la clave ssh de unos secretos de drone para hacer el pull y el push necesario para borrar las ramas. No obstante por problemas de conectividad no terminó de funcionar. Además de que habría que dar manualmente permiso al usuario de gitea de integración continua a cada repositorio para que este pudiese modificar el repositorio.

Ello hizo que desechasemos a priori esta aproximación. Lo siguiente que pensamos fue hacer un cron job que borrase localmente las ramas mergeadas en el servidor donde tenemos gitea. El problema es que la información almacenada son repositorios git bare, no lo que ven los clientes, por lo tanto todas las herramientas o comandos de limpieza fallaban.

Por último se nos ocurrió que lo más fácil era instalar un hook de git en los clientes. Como es pesado agregar el hook en cada repositorio que utilicemos se pueden establecer hooks genéricos para todos los repositorios con el siguiente comando:

git config --global core.hooksPath /path/to/hooks

Donde /path/to/hooks/ puede ser ~/.git/hooks. La desventaja de esta medida es que se desactivan los hooks de los repositorios en particular, a no ser que los actives manualmente (y entonces no funcionarán los globales).

Utilizaremos el hook post-merge que se dispara cuando tras hace run git pull hay alguna rama que se ha mergeado.

Dentro de este script podemos poner cualquier script nosotros utilizaremos dos herramientas git-sweep y git-extras para instalarlas haremos:

pip install --user git-sweep
sudo apt-get install git-extras

git-sweep es un programa para borrar ramas mergeadas en remoto, y utilizaremos el comando git delete-merged-branches de git-extras para borrar las ramas en local.

Por lo tanto el archivo ~/.git/hooks/post-merge quedará como:

#!/bin/sh

git-sweep cleanup --force
git delete-merged-branches

Por lo que vemos, la ñapa es bastante fea. Ya va siendo hora de que esta "feature" tan necesaria esté integrada en los gestores de git como gitea o gitlab.

Asamblea: 2018-07-04

Este míercoles, 4 de Julio vamos a reunirnos en Asamblea.

Aprovecharemos para planificar que haremos este mes con el comienzo del verano. Animamos a participar a todo el mundo que esté interesado puesto que no son densas y se tratan temas técnicos.

El orden del día es el siguiente:

  • Rotado de responsabilidades
  • Elección de las temática de cada miércoles
  • Anuncio sobre temas de actualidad
  • Revisión de las tareas del mes pasado
  • Plan de tareas para este mes
  • Varios

Para agilizar el planning del mes siguiente, es muy recomendable revisar las incidencias abiertas y pensar en qué podríamos centrarnos.

Un saludo!

Integración Continua con Drone

Hace poco que hemos empezado a usar Drone como plataforma de integración continua. A continuación veremos que es la integración continua, historia y usos.

La integración continua es la práctica que consiste en hacer integraciones automáticas de un proyecto lo más a menudo posible para detectar fallos cuanto antes, entendiendo integración como compilación (de ser necesaria) y ejecución de pruebas del proyecto. Esta integración suele activarse desde el control de versiones del proyecto, como por ejemplo git. La idea es que cada vez que se realiza un evento (un push, un pull request, …) se ejecuta la integración. Lo bueno es que se puede escoger qué se ejecuta en cada evento. Por ejemplo, los tests unitarios suelen ser bastante ligeros, y aún siendo varios cientos, tardan pocos segundos en ejecutarse. Por lo tanto, tiene sentido que se ejecuten con cada push. Pero, por ejemplo, replicar una infraestructura es más costoso, aún con tecnologías como docker. Por lo tanto, tendría sentido ejecutar pruebas de integración con docker solo en los merge request.

Se entenderá todo mejor con un ejemplo. Antes de eso, explicaré brevemente como lo hemos instalado. Como ya sabrá quien haya venido a alguna asamblea, en La Brecha Digital tenemos un proyecto, que es ansibilizar y dockerizar el un servidor con todos los componentes que queremos. Uno de estos es drone. Por lo tanto, si se quiere instalar, se puede usar el rol deploy-docker, que es un rol que hemos desarrollado para desplegar contenedores docker que se puedan gestionar como servicios de systemd. Las lineas exactas se pueden consultar en nuestro playbook.

Suponiendo que tenemos drone ya instalado y integrado con algún servidor git (en nuestro caso gitea, aunque hay más opciones), veamos como empezar a usarlo. Un detalle que hace que drone mole más que otros engendros gigantes, deformes y javosos como Jenkins, es que tiene una cli funcional muy simple de usar. Una vez logueado en tu servidor drone, hay una sección que se llama Token. En esta saldrá algo como esto:

export DRONE_SERVER=https://drone.cslabrecha.org
export DRONE_TOKEN=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.aa29iwidHlwZSI6InVzZXIifQ.XtTbzRLeZngWiXAd_TzOyfYEKAQ8OF_9xJzYeH4J3q8
drone info

Solo hay que copiarlo y ejecutarlo en la shell y ya se puede usar la cli. Para activar un repositorio, solo hay que ejecutar:

drone repo add La_Brecha_Digital/brechadigital-web

Y ya. Al añadirlo como repositorio, automáticamente configura el repositorio git, por lo que todos los eventos push del repositorio activaran el pipeline de drone, una vez este exista. Para ver un ejemplo real, vamos a examinar el repositorio para crear la imagen de docker de nikola que hemos hecho. El repositorio consta de tres ficheros, un README, un Dockerfile y un .drone.yml. El fichero .drone.yml es el que contiene el pipeline del repositorio. A fecha de hoy, contiene esto:

pipeline:
  # Build the image when on pull request
  build:
    image: docker
    commands:
      - docker build -t testing/nikola .
      - docker rmi testing/nikola
      - docker system prune -f
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    when:
      event: pull_request
  # Publish the image to the registry
  build-push:
    image: plugins/docker
    repo: r.cslabrecha.org/nikola
    registry: r.cslabrecha.org
    tags: latest
    secrets: [docker_username, docker_password]
    when:
      branch: master
      event: push
branches: master

Se puede apreciar que hay dos partes, por así decirlo. Uno seria build y el otro build-push. Los nombres son bastante descriptivos, uno construye la imagen y el otro construye la imagen y la pushea al registry. La diferencia principal son los when. Estos parámetros son los que deciden cuando se ejecuta un build. En el primer caso, se ejecuta solamente cuando el evento recibido es un pull request. En el caso del segundo, cuando es un push a master, es decir, cuando el pull request se ha mergeado correctamente.

Cuando se activa un pipeline en un evento, se añade un botón al lado del commit. Cuando está en progreso, tiene una redonda amarilla. Cuando termina correctamente e incorrectamente, respectivamente, se ve así:

img

img

Es importante fijarse en esto cuando se siguen políticas estrictas de calidad, por que de momento gitea no permite bloquear el pull request (o peticion de mergeo) hasta que la integración contínua no termine correctamente.

Quien tenga curiosidad, puede echar un ojo al que tenemos montado. Este build en concreto es uno de construcción de la página web. Se pueden ver los stages abajo a la izquierda (clone, builder), y a la derecha se ve el log de las órdenes que ejecutan el stage. También se puede ver más información relevante, como cuando se ejecutó el build, el commit que ejecutó, el estado, …

Y con esto se puede empezar a usar drone. Aviso que la documentación disponible deja bastante que desear. Parece que apunta mucho al rollo enterprise, pero hay que tener en cuenta que el proyecto es relativamente joven, con suerte mejorará. Cualquier duda, se puede comentar en la sala de xmpp que se puede consultar en la sección de contacto.

Mongo para Mongos I

Este miércoles 27 de Junio, tendremos a ls 20:00 una primera charla introductoria a MongoDB (aka Mongo para Mongos) impartida por valmer. Se trata de las primera charla de un ciclo dedicado a esta base de datos no relacional licenciada bajo AGPLv3 y en la que se tratarán cuestiones como las siguientes:

  • Sobre las bases de datos no relacionales.

  • Introducción a MongoDB. Qué es y que no es.

  • Modos de despliegue.

  • Introducción al CRUD de índices.

  • Replica Set y Shardings

¡Os esperamos!

Eventos del mes de Junio

Este mes tenemos los siguientes eventos planificados:

  • 2018-06-06: Asamblea (en la Ingobernable)

  • 2018-06-13: Tareas internas

  • 2018-06-20: Charla: Mongo para Mongos I

  • 2018-06-27: Charla: Mongo para Mongos II

  • 2018-07-04: Asambela de Julio

En el día de tareas internas vamos a poner en común lo realizado este mes y a completar las tareas que nos hemos asignado este mes: Este mes vamos a profundizar en la plataforma de Integración Continua usada en el Hacklab (Drone) y vamos a finalizar la automatización y replicación del sistema de gestión de certificados y de backups entre otros. Si deseas coger alguna otra tarea, puedes hacerlo aquí aunque también puedes venir a compartir impresiones y ganas de aprender.

Las charlas de este mes están dedicadas al sistema de bases de datos no relacionales MongoDB y serán impartidas por Valerian: la primera charla será de carácter introductorio y la siguiente se profundizará más. No es necesario saber de MongoDB en ninguna de las charlas así que no os corteis :D

Por finalizar, el día cuatro de Julio se realizará la asamblea del mes. Como en otras ocasiones, si te interesa conocer como son nuestras asambleas puedes echarle un ojo a las anteriores.

Os esperamos!

Desahucio de la Ingobernable

Las compañeras de la Ingobernable estan bajo amenaza de desahucio, por lo que han propuesto una serie de actividades con las que utilizar el tiempo que se defienda el sitio. Hay más información en este enlace.

Por nuestro lado, queremos poner nuestro granito de arena haciendo la asamblea que ya hemos anunciado en La Ingobernable. Quedaremos en la Cafeta a las 19:30 y haremos un poco de tiempo hasta las ocho, hora en la que buscaremos algún hueco en el que podamos estar sin molestar mucho y llevar a cabo la asamblea.

Os esperamos tanto en la asamblea como en la defensa de la Ingobernable!

Pass como gestor de contraseñas

Desde hoy utilizamos pass como gestor de contraseñas, básicamente es un wrapper por encima de gpg y utiliza git para la sincronización de claves entre diferentes miembros del equipo.

Instalación

Para poder tener acceso a las contraseñas hay que seguir los siguientes pasos:

Primero hay que pedirle a alguien que ya tenga el repositorio que meta vuestra clave publica en el pass (en un apartado posterior se explica cómo).

  • Instalación de pass:

bash sudo apt-get install pass

  • Clonar el repositorio:

bash git clone {{ url_del_repositorio }} ~/.password-store

Si gestionáis más contraseñas con pass podéis hacer el clone a ~/.password-store/brecha.

  • Importar las claves publicas del resto de gente

bash gpg -u {{ gpg_id_de_vuestra_clave_publica }} --import ~/.password-store/.gpg_public_keys/*

Guía rápida de uso de pass

  • Listar las contraseñas

bash pass

  • Buscar una contraseña

bash pass find vault

  • Imprimir una contraseña a la terminal

bash pass brecha/vault

  • Copiar una contraseña al clipboard

bash pass -c brecha/vault

  • Generar una contraseña de 40 caracteres

bash pass generate brecha/nueva_contraseña 40

  • Generar una contraseña de 40 caracteres sin caracteres extraños

bash pass generate brecha/nueva_contraseña 40 -n

  • Editar una contraseña

bash pass edit brecha/vault

  • Si tienes el .git en ~/.password-store/.git, puedes hacer push y pull

bash pass git push pass git pull

Agregar a un nuevo miembro en el repositorio de claves

Si queremos agregar a una persona nueva en el repositorio de claves tendremos que:

  • Si se usa gitea, y el repositorio pertenece a una organización, habrá que agregarla como Owner para que pueda verlo.

  • Crear una nueva rama:

bash git checkout -b feature/agrego_a_X_al_repositorio

  • Agregar su clave publica al repositorio

bash gpg -a --export {{ gpg_id_de_vuestra_clave_publica }} > ~/.password-store/.gpg_public_keys/{{ nick_de_la_persona }}

  • Informar a pass de que encripte las contraseñas también para la clave nueva

bash pass init [--path={{ sub-directory }}] {{ gpg_id1 }} {{ gpg_id2 }} ...

Si hemos creado el directorio de la brecha dentro de ~/.password-store hay que especificarlo en el campo sub-directory.

Hay que inicializarlo con todas las claves gpg, por lo que si se agrega una nueva clave hay que seguir poniendo las anteriores.

  • Hacer el commit y el Merge request

bash git add . git commit -m "Agrego a X al repositorio de claves" git push

Asamblea: 2018-06-06

El próximo miércoles día 6 de junio, tendremos Asamblea.

Es el momento en el que decidimos el rumbo y las tareas que haremos este mes, por lo que os animamos a participar. Las asambleas muy amenas, y al final debatimos temas técnicos.

El orden del día es el siguiente:

  • Rotado de responsabilidades
  • Elección de las temática de cada miércoles
  • Anuncio sobre temas de actualidad
  • Revisión de las tareas del mes pasado
  • Plan de tareas para este mes
  • Varios

Para mayor descripción de cada apartado seguir el link de arriba que apunta al documento colaborativo en el que todos tomaremos acta. (Cambiar el orden del día a placer también).

Para dinamizar el Plan de tareas para este mes, sería interesante que todas trajésemos leídos los issues y pensado en qué nos apetecería colaborar o si falta algún issue crearlo.

Un saludo!