Umami web analytics

Si ofreces un servicio online, quieres conocer a tu audiencia. Interactuar con ellos, saber qué contenido consideran más interesante. Esto, claro está, no es gratis. Quien diga lo contrario, te miente.

Umami es un proyecto open source que nos ofrece la posibilidad de alojar en nuestros propios servidores una solución de web analytics.

*Nota: Esta no pretende ser una guía exhaustiva sino una presentación de una alternativa. Se muestra eso sí el proceso de instalación y fotos para visualizar su funcionamiento. En la web del proyecto se puede encontrar una demo

Antes de empezar debemos resolver una pregunta.

¿qué ventajas nos ofrece esto respecto a otras alternativas?

  • Tiempo de carga: Al tener un diseño sencillo y un único objetivo a cumplir, no sobrecarga nuestra página.
  • Dependencia: No estamos sujetos a las condiciones de uso de otra entidad, a los cambios que pueda hacer en busca exclusiva de su beneficio.
  • Evitamos la recopilación de datos de nuestros clientes por terceras partes.
  • Adaptabilidad: Si lo necesitas, siempre puedes mejorar el código y adaptarlo a tus necesidades.

Pss: si te interesan las ventajas pero umami no te acaba de convencer, puedes echarle un ojo a ackee

Podemos tener todo esto listo en apenas 30 minutos. Lo sé, lo sé, no es un click y ya. ¿Pero donde esta la gracia en eso?

Requisitos previos:

  • Docker instalado en tu sistema.
  • Conocimientos intermedios/avanzados de gnu/linux
  • Capacidad para configurar un servidor web.

A ver, que me enrollo mucho, porque solo necesitamos tres lineas

git clone https://github.com/mikecao/umami.git
cd umami
sudo docker-compose up -d 

Y ya esta, finito, nada más que hacer… Bueno más o menos.

Con esto ya podríamos tener las analytics de cualquier página que funcione en el mismo servidor, pues efectivamente puede reportar los datos a localhost. Sin embargo ¿qué pasa si el servicio web se encuentra en un servidor distinto al de umami?

Pues nada, simplemente configuramos un dominio o subdomino.

Añadir una web a umami

Página principal
Página principal: Demasiado vacía

Una vez añadida la web, clickamos en el icono de código y nos muestra nuestro código de rastreo ( ¡Muahaha! Big brother cuidado que te haremos la competencia… Bueno, not really)

Obtenemos y copiamos el código de rastreo en nuestra web

Lo ideal es colocar este código en una zona de la web que siempre sea cargada por el usuario. Por ejemplo el footer.

Ya tenemos nuestra web en la lista

Ahh por cierto… ¡cambia la contraseña!

WordPress-fpm nginx reverse proxy

Aviso para navegantes: ¿muy dificil no puede ser verdad? Bueno, la cuestión es ¿cúantos fallos puedes cometer?

Usando de ejemplo wordpress-fpm vamos a ver cómo configurar un programa fpm corriendo en un contenedor y usando nginx como reverse proxy.

En cuánto a por qué fpm, la idea es consumir menos recursos. Además, cusando nginx como proxy, tener una instancia de apache corriendo solo para docker, no es de mi agrado.

Aclarar que antes de seguir este tutorial debes tener docker instalado y configurado para evitar colisiones con el firewall.

En este caso contaremos con NGINX funcionando en el servidor como reverse proxy para múltiples apps. NGINX NO estará funcionando en ningún container.

(Si vas a levantar múltiples programas/webs/apps que usen mysql, puede ser más conveniente levantar una sola instancia y conectar los demás contenedores a ella)

version: '3.1'

services:

  db-blog:
    image: mariadb
    restart: unless-stopped
    environment:
      MYSQL_DATABASE: blogdb
      MYSQL_USER: MySqlU
      MYSQL_PASSWORD: contraseña
      MYSQL_ROOT_PASSWORD: contraseña
    volumes:
      - ./db-data:/var/lib/mysql


  wordpress:
    image: wordpress:5.4.2-php7.2-fpm
    restart: unless-stopped
    ports:
      - "127.0.0.1:8082:9000"
    depends_on: 
      - db-blog

    environment:
      WORDPRESS_DB_HOST: db-blog
      WORDPRESS_DB_USER: MySqlU
      WORDPRESS_DB_NAME: blogdb
      WORDPRESS_DB_PASSWORD: contraseña
    
    user: www-data

    volumes:
      - /var/www/html/blog/wp-content:/var/www/html/blog/wp-content
    links: 
      - db-blog


volumes:
  wordpress:
  db-data:

Debemos tener en cuenta que si cambiamos el directorio local de /var/www/html a otro en la carpeta de un usuario, por ejemplo, los permisos pueden ser problemáticos. Pues aunque concedamos permisos al directorio concreto nginx necesita acceso a los directorios superiores, para funcionar correctamente.

Actualizar wordpress gracias a docker

Quiero llamar aún más la atención sobre este punto:

 volumes:    
  - /var/www/html/blog/wp-content:/var/www/html/blog/wp-content

es muy importante añadir el wp-content, pues queremos delegar en docker las actualizaciones de wordpress. De esta forma, al recrear el contenedor con la nueva versión, actualizará todo lo necesario. Y simplemente al acceder al panel de administración de la web nos notificará de que es necesario actualizar la base de datos.

En caso contrario, nos encontraremos con problemas al intentar actualizar desde el panel de wordpress, pues este no cuenta con permisos para hacerlo.

Realmente esa es la parte complicada. Lo siguiente sería configurar nginx como reverse proxy.

Un ejemplo del archivo de configuración de nginx sería:

server {

    
        # Add index.php to the list if you are using PHP
        index index.html index.htm index.php;

        server_name example.es;
        root /var/www/html/example.es;

        access_log /var/log/nginx/example-access.log;
        error_log /var/log/nginxexample-error.log;


    add_header X-Frame-Options "SAMEORIGIN";
    add_header X-XSS-Protection "1; mode=block";
    add_header X-Robots-Tag none;
    add_header X-Download-Options noopen;
    add_header X-Permitted-Cross-Domain-Policies none;
    add_header Referrer-Policy no-referrer;



location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ \.php$ {
        try_files $uri =404;
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_pass 127.0.0.1:8082;
        fastcgi_index index.php;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param PATH_INFO $fastcgi_path_info;
    }


    listen [::]:443 ssl; 
    listen 443 ssl; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot



    ssl_certificate /etc/letsencrypt/live/example.es/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/example.es/privkey.pem; # managed by Certbot
}


server {
    if ($host = example.com) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


        listen 80;

        server_name example.com;
    return 404; # managed by Certbot


}