Levantando la infraestructura local con Docker

Hace ya varios años que descubrí Docker y ahora (bueno, desde hace un buen tiempo ya) es una tendencia global: microservicios en contenedores, clusters de contenedores en la nube, etc.

En realidad, esto al 99% de los programadores que conozco ni lo quieren saber ni les interesa: quieren hacer su micro, su back, que funcione y a tirar millas. El problema es que este 99% de programadores ignoran cómo les puede facilitar la vida Docker para multitud de tareas muy básicas y hoy voy a contar una de ellas: montar la infraestructura en local para probar y desarrollar.

Esto es algo que podría enmarcarse dentro de “prácticas DevOps”, pero sobre el término creo que hay cierta controversia porque cada cual asocia DevOps con responsabilidades diferentes: para unos es más Bamboo y Jenkins, y para otros es Docker y Kubernetes.

No me enrollo más: al grano.

Ahora mismo estoy trabajando en un side project con Laravel 8 en el que estoy implementando el back (lo que vendría a ser una API, un micro). Para probarlo, como mínimo necesito una base de datos, pero además me gusta pasar un análisis de código por lo que también quiero Sonar (sí amigos, aunque desarrolles para ti… utiliza Sonar!).

Así que para desarrollar en local quiero/necesito:

  • Una base de datos y un gestor para esa base de datos
  • Sonar, para el que también necesito una base de datos (podría ser la misma, podría ser otra)

Antiguamente, esto implicaba instalarte MySQL, MySQL Admin, configurarlo como servicio (o no), luego SonarQube…

Ahora con Docker no instalas cada uno de los componentes de la infra: instalas únicamente Docker y “levantas” los servicios.

Para levantar varios contenedores a la vez, yo utilizo docker compose por simplicidad (ahora ya lo han integrado dentro del Docker CLI) y para la infraestructura de servicios que indicaba anteriormente este sería:

Publicidad
docker-compose.yml

# Use root/example as user/password credentials
version: '3.1'

services:

  mysql_laravel:
    image: mysql:8.0.22
    command: --default-authentication-plugin=mysql_native_password
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: local
      MYSQL_DATABASE: laravel
    ports:
      - 3306:3306
    volumes:
      - ./data/mysql:/var/lib/mysql
    networks:
      - laravel
  adminer:
    image: adminer:4.7.7-standalone
    restart: always
    ports:
      - 8080:8080
    networks:
      - laravel
  postgres_sonar:
    image: postgres:13.1
    environment:
      - POSTGRES_USER=sonar
      - POSTGRES_PASSWORD=sonar
    volumes:
      - ./data/postgresql/db:/var/lib/postgresql
      - ./data/postgresql/data:/var/lib/postgresql/data
    networks:
      - laravel
  sonarqube:
    image: sonarqube:8.5.1-community
    expose:
      - 9000
    ports:
      - "127.0.0.1:9000:9000"
    environment:
      - sonar.jdbc.url=jdbc:postgresql://postgres_sonar:5432/sonar
      - sonar.jdbc.username=sonar
      - sonar.jdbc.password=sonar
    volumes:
      - ./data/sonarqube/conf:/opt/sonarqube/conf
      - ./data/sonarqube/data:/opt/sonarqube/data
      - ./data/sonarqube/extensions:/opt/sonarqube/extensions
      - ./data/sonarqube/bundled-plugins:/opt/sonarqube/lib/bundled-plugins
    networks:
      - laravel
    depends_on: 
      - postgres_sonar


networks:
  laravel:

Esta infraestructura se compone de 4 servicios, es decir, 4 contenedores:

  • mysql_laravel: la base de datos para la aplicación. Imagen: mysql:8.0.22
  • adminer: un gestor para la base de datos mysql_laravel muy muy básico pero suficiente en estos momentos. Imagen: adminer:4.7.7-standalone
  • postgres_sonar: una base de datos postgreSQL para almacenar los datos de sonar. Imagen: postgres:13.1
  • sonarqube: poco más que decir: SonarQube. Imagen: sonarqube:8.5.1-community

En el fichero se pueden ver las variables de entorno (que básicamente son los usuarios y passwords por defecto y una ruta) y lo más importante: qué directorios de la máquina local se montan dentro de cada uno de los contenedores. Esto sirve para persistir los datos de las bases de datos (SonarQube tiene un ElasticSearch embebido, ya hablaré de él en otro artículo).

Este fichero docker-compose.yml está almacenado en el repositorio de la aplicación, por lo que si un compañero se baja el repo y quiere levantar exactamente la misma infraestructura para desarrollar en local sólo tiene que ejecutar en línea de comandos:

$ docker-compose up -d

Y ya está :p ¡¡¡¡Si es que no puede ser más fácil!!!

Esta es la infra que yo utilizo pero puedes coger el docker-compose y modificarlo a tu antojo. Dependiendo de cuál sea tu infra tendrás que modificarla pero apuesto a que prácticamente cualquier aplicación que puedas necesitar la puedes encontrar en DockerHub (el “directorio” de imágenes de contenedores).

Disclaimer 1:

  • Sí, claro, pero tienes que instalar Docker.
  • Sí, claro: tienes que instalar sólo UNA aplicación, y no 4 como sería en mi caso.

Disclaimer 2:

¿Podría haber utilizado la misma base de datos para la aplicación y para sonar utilizando esquemas distintos?

Sí, pero dado que me interesa poder borrar la base de datos de la aplicación muy rápido, la manera más fácil es borrar directamente el directorio donde se guarda y recrearla.

Teniendo las dos bases de datos separadas:

  • Evito errores (sería bien fácil borrar el esquema de sonar por equivocación).
  • Me puedo cargar la base de datos de la aplicación cuando quiera y recrearla.
  • Me cuesta lo mismo levantar una base de datos que dos, una vez están puestas en el docker-compose.

Deja una respuesta

Tu dirección de correo electrónico no será publicada.

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.