Merge pull request #51 from Olasergiolas/Objetivo-7

[IV-21-22] Objetivo 7

.github/workflows/tests.yaml

@@ -10,6 +10,9 @@ jobs:
     name: Run tests Go ${{ matrix.golang }}
     runs-on: ubuntu-latest
     steps:
+      - name: Install Task
+        uses: arduino/setup-task@v1
+
       - name: Check out the repo
         uses: actions/checkout@v2
 
@@ -19,4 +22,4 @@ jobs:
           go-version: ${{ matrix.golang }}
 
       - name: Run tests
-        run: go test -v ./...
+        run: task test

.gitignore

@@ -1 +1,2 @@
 .DS_Store
+.env

Taskfile.yml

@@ -21,6 +21,8 @@ tasks:
   test:
     cmds:
       - go test -v ./...
+    env:
+      LOGPATH: /tmp/go-autoeq-test.log
 
   fmt:
     cmds:

docs/README.md

@@ -8,3 +8,5 @@
 - [Framework de tests y biblioteca de aserciones](test-framework.md)
 - [Contenedor Docker para tests](dockerfile.md)
 - [Integración Continua](CI.md)
+- [Registro de eventos](logging.md)
+- [Configuración remota](remote-config.md)

docs/logging.md

@@ -0,0 +1,28 @@
+# Registro de eventos :memo:
+## Paquete de logging utilizado
+Finalmente se ha decidido utilizar [zerolog](https://github.com/rs/zerolog).
+## Motivación
+En primer lugar, es necesario definir qué requisitos esperamos de los distintos servicios que van a ser comparados. El servicio de logging que utilicemos para este proyecto tendrá que cumplir lo siguiente:
+- **Posibilidad de usar formato JSON**: Esto resulta muy conveniente para poder parsear los logs en otras herramientas.
+- **Posibilidad de establecer campos por defecto**: Querremos que los logs contengan campos por defecto como el timestamp o la versión de Go utilizada para no tener que indicar de forma repetitiva que se incluyan dichos campos.
+- **Soporte para cualquier io.Writer**: Querremos poder escribir los logs tanto en la salida estandar (os.Stdout) como en un fichero.
+- **Distintos niveles de log**: Posibilidad de establecer el nivel de logging deseado (Info, Warn, Error, Fatal...).
+
+Respecto su estado de mantenimiento, requerimos lo básico en su repositorio:
+- Que el proyecto haya tenido commits en el último año.
+- Que no tenga un número considerable de PRs o Issues acumulados sin atender.
+- Que el desarrollo del proyecto no esté detenido.
+
+Teniendo todos estos requisitos en cuenta, comparamos **log**, **logrus**, **zerolog** y **apex log**.
+### Log
+Es el paquete de logging ya incluido por defecto en Go. Queda descartado debido a que carece de soporte para logs con formato o niveles de logging.
+### Logrus
+Es el más comúnmente utilizado. Aunque cumple los requisitos de funcionalidad, su desarrollo ha quedado reducido a arreglar pequeños problemas ya que son incapaces de realizar cambios considerables sin romper la compatibilidad con proyectos que lo utilizan. Debido a esto, ya que es factible que una versión futura de Go deje de ser compatible con logrus, descartamos esta opción.
+### Apex log
+Es también una opción popular para implementar el uso de logs en Go, pero por desgracia, su repositorio de Github parece algo abandonado, con issues y PRs abiertas desde hace meses sin actividad, además de no haber tenido commits desde hace más de un año.
+
+### Zerolog
+Zerolog se caracteriza por su velocidad y la posibilida de generar logs con formato. Zerolog cumple con todos los requisitos expuestos previamente, así que será nuestra elección.
+
+## Implementación
+Para la implementación, se han tenido en cuenta algunas de las mejores prácticas de logging como la implementación de una interfaz de logging estándar que haga uso de mensajes y eventos predefinidos, inyección de dependencias, escritura a archivo o el uso de logs formateados.

docs/remote-config.md

@@ -0,0 +1,23 @@
+# Configuración remota :gear:
+## Sistema elegido
+Para esta tarea, se han utilizado [etcd](https://etcd.io/) y [godotenv](https://github.com/joho/godotenv).
+## Motivación
+### Almacenamiento distribuido
+Para implementar la funcionalidad de configurar la aplicación de forma remota, necesitamos algún sistema de almacenamiento distribuido que no solo nos permita poder almacenar ciertas configuraciones, sino que también se encargue automáticamente de comunicar al resto de nodos los posibles cambios de configuración realizados, de forma que sea posible escalar el número de instancias de la aplicación y que todas compartan una misma configuración. Hay una serie de servicios que pueden proveernos con la funcionalidad descrita como son **etcd**, **Zookeeper** y **consul**.
+
+El servicio finalmente elegido deberá de ser fácil de configurar, usar un mecanismo de almacenamiento simple (más cercano al almacenamiento de parejas clave-valor que a bases de datos SQL) y tener un cliente nativo para Go.
+#### 1. etcd
+Es un sistema de almacenamiento distribuido de parejas clave-valor escrito en Go con la fiabilidad y tolerancia a fallos como principales objetivos. Gracias a su simplicidad, facilidad de configuración y su [cliente nativo](https://pkg.go.dev/go.etcd.io/etcd/clientv3) de Go, [etcd](https://etcd.io/) es una alternativa a considerar.
+#### 2. ZooKeeper
+[ZooKeeper](https://zookeeper.apache.org/) es el proyecto de coordinación distribuida de Apache usado en algunos de sus proyectos como Kafka o Solr. Para nuestro uso, tiene las desventajas de no tener un cliente oficial para Go (aunque existe uno mantenido por la [comunidad](https://github.com/go-zookeeper/zk) pero cuya documentación carece de ejemplos de uso rápidos que nos faciliten su puesta en marcha), estar escrito en Java, o el que ZooKeeper tenga que abrir un nuevo socket de conexión por cada petición que realicemos.
+#### 3. Consul
+[Consul](https://www.consul.io/) es la solución diseñada por Hashicorp. Aunque cumple con los requisitos de funcionalidad establecidos (cliente oficial en Go, almacenamiento KV y fácil configuración), es un servicio que aporta mucha más funcionalidad de la que necesitamos para este proyecto. Es por esto que nos inclinamos por un servicio más simple y orientado a nuestras necesidades como es **etcd**.
+
+### Carga de variables de entorno
+Además, por motivos de seguridad y de buenas prácticas, querremos poder tener una forma de evitar hardcodear en el cliente parámetros como por ejemplo la dirección IP o claves de acceso al servidor etcd. Esto se puede conseguir haciendo uso de variables de entorno cargadas desde un fichero local secreto.
+
+La solución elegida para gestionar variables de entorno deberá de ser fácil de usar y estar correctamente mantenida. En Go, las principales opciones son [Godotenv](https://github.com/joho/godotenv) y [Viper](https://github.com/spf13/viper).
+#### 1. Viper
+Viper es la opción de referencia cuando se trata de configuración en Go. Entre sus funciones, Viper es capaz no solo de gestionar ficheros de configuración para usar su contenido como variables de entorno sino que también de conectarse directamente con etcd y obtener la configuración del almacenamiento distribuido. Aunque usar Viper nos ahorraría la necesidad de usar dos herramientas distintas, su uso y configuración resultan algo más complejos y no he sido capaz de conseguir utilizarlo.
+#### 2. Godotenv
+Es la herramienta destinada a esta tarea más simple en Go. Cumple su función perfectamente y gracias a su paquete autoload no es necesario siquiera escribir una sola línea de código más allá del import para que cargue las variables de entorno de un fichero ".env". Es por su simplicidad, facilidad de uso y el buen estado de su repositorio de Github por lo que será la opción elegida.

go.mod

@@ -2,10 +2,30 @@ module github.com/Olasergiolas/Go-AutoEQ
 
 go 1.17
 
-require github.com/stretchr/testify v1.7.0
+require (
+	github.com/joho/godotenv v1.4.0
+	github.com/rs/zerolog v1.26.1
+	github.com/stretchr/testify v1.7.0
+	go.etcd.io/etcd/client/v3 v3.5.1
+)
 
 require (
-	github.com/davecgh/go-spew v1.1.0 // indirect
+	github.com/coreos/go-semver v0.3.0 // indirect
+	github.com/coreos/go-systemd/v22 v22.3.2 // indirect
+	github.com/davecgh/go-spew v1.1.1 // indirect
+	github.com/gogo/protobuf v1.3.2 // indirect
+	github.com/golang/protobuf v1.5.2 // indirect
 	github.com/pmezard/go-difflib v1.0.0 // indirect
-	gopkg.in/yaml.v3 v3.0.0-20200313102051-9f266ea9e77c // indirect
+	go.etcd.io/etcd/api/v3 v3.5.1 // indirect
+	go.etcd.io/etcd/client/pkg/v3 v3.5.1 // indirect
+	go.uber.org/atomic v1.9.0 // indirect
+	go.uber.org/multierr v1.7.0 // indirect
+	go.uber.org/zap v1.19.1 // indirect
+	golang.org/x/net v0.0.0-20210805182204-aaa1db679c0d // indirect
+	golang.org/x/sys v0.0.0-20210809222454-d867a43fc93e // indirect
+	golang.org/x/text v0.3.6 // indirect
+	google.golang.org/genproto v0.0.0-20210602131652-f16073e35f0c // indirect
+	google.golang.org/grpc v1.38.0 // indirect
+	google.golang.org/protobuf v1.26.0 // indirect
+	gopkg.in/yaml.v3 v3.0.0-20210107192922-496545a6307b // indirect
 )