Docker, Servidores de Bases de Datos y Xojo

A continuación encontrarás traducido al castellano el artículo escrito por Jürg Otter y publicado originalmente en el Blog de Xojo.

Xojo y Servidores de Bases de Datos

Existen múltiples formas de desarrollar con Xojo en combinación con servidores de bases de datos. Puede que estés trabajando en una aplicación de escritorio multiusuario que almacena datos en una base de datos; o bien puede ser que estés creando una aplicación web multiusuario que necesita escalarse a un par de instancias — y que utilizan una base de datos para almacenar la información. O bien puede ser que estés escribiendo una aplicación para dispositivos móviles que se conecten con una API REST en el lado del Backend — probablemente también escrito en Xojo, con Xojo Web o con el proyecto de código abierto Express —.

Como Desarrollador

Cuando se trabaja con este tipo de proyectos te encontrarás afrontando algunos retos relacionados con los múltiples servidores de bases de datos disponibles.

• Has de tener un entorno de desarrollo local en el cual se ejecuten el o los servidores de bases de datos.
• Quieres probar tu aplicación contra una nueva versión de un servidor de bases de datos.
• Un cliente informa de que existe un problema con una versión determinada del servidor de bases de datos que no tienes instalada.

Ordenador de Desarrollo

Me gusta contar con un ordenador de desarrollo tan poco sobrecargado como sea posible. Así que no me gusta mucho la idea de tener que instalar varios servidores sólo por el simple hecho de tener que hacer algunas pruebas. Sería demasiado tedioso el tener que “limpiarlo”, actualizar las bases de datos a otras versiones y también eliminar todos los remanentes de la instalación cuando ya no los necesite. Y tampoco quiero tener varios servicios que no necesito todo el tiempo ejecutándose en el equipo, dado que están consumiendo una cantidad preciosa de memoria y ralentizando el ordenador.

¿No sería maravilloso si existiese una forma simple de poner en marcha varios servidores cuando sean necesario sin contar con todas la molestias asociadas? Lo cierto es que existe, echa un vistazo en Docker y Docker Compose.

Docker Compose y Servidores de Bases de Datos

Con Docker, desarrollar con y para varios servidores de bases de datos se convierte en un abrir y cerrar de ojos.

¿Qué es Docker?

Si no has oido hablar antes de Docker, te recomiendo que eches un vistazo a su excelente documentación: Docker Overview; o también puedes leer mi anterior entrada en el Blog: Running Xojo Web Applications in Docker. Simplemente voy a repetir y citar algunos de los fundamentos básicos de dicha revisión general a modo de breve introducción:

Docker es una plataforma de código abierto para el desarrollo, despliegue y ejecución de aplicaciones. Proporciona la capacidad de empaquetar y ejecutar una aplicación en un entorno aislado denominado container. El hecho de que sea aislado y la seguridad adicional te permiten ejecutar varios contenedores simultáneamente en un host determinado. Los contenedores son ligeres y puede, bueno, contener todo lo que necesites para ejecutar las aplicaciones, de modo que no necesitas contar con nada de lo que esté ya instalado en el host.

Un Contenedor de Docker es una instancia ejecutable de una imagen. Puedes crear, iniciar, detener, mover o eliminar un container. Por defecto, un container está relativamente bien aislado con respecto a otros containers y el equipo que lo alberga. Puedes controlar cuan aislado están la red, almacenamiento o bien los subsistemas subyacentes de un container, o bien si los subsistemas subyacentes son los de otros containers o bien los del equipo host. Un container está definido por su imagen así como por las opciones de configuración proporcionadas al crearlo o bien al iniciarlo.

Docker Compose es una herramienta para definir y ejecutar aplicaciones multi-contenedor. Es la clave para llevar más allá una experiencia de desarrollo y despliegue más eficiente y depurada. Compose simplifica el control sobre la totalidad de tu pila de aplicaciones, haciendo así que resulte más sencilla la gestión de servicios, redes y volúmenes en un único y comprensible archivo de configuración YAML. Luego, con un único comando puedes crear e iniciar todos los servicios desde el archivo de configuración.

Docker Compose para Servidor de Bases de Datos y Administración

Esto suena fantástico. Sólo has de escribir un archivo de configuración YAML, y ejecutar el servidor de base de datos en el host (es decir: tu equipo de desarrollo); y será capaz de iniciar, detener y borrar en cualquier momento sin tener que lidiar con las Preferencias o los Launch Daemons.

Pero, ¿por qué Docker Compose para “aplicaciones multi-contenedor”? Bien, el servidor de bases de datos es una parte: una aplicación, un container de docker en ejecución. Y como desarrollador lo más seguro es que probablemente quieras contar, además, con alguna herramienta para la administración de la base de datos —la cual también se estaría ejecutando en su propio contenedor aislado. Y para que ambos están disponibles mediante el uso de un solo comando (o al pulsar “run” o “stop”) hemos de “componer” estas dos partes de modo que puedan trabajar juntas.

Ejecutar un Servidor de Bases de Datos y una Herramienta de Administración con Docker Compose

Hagamos eso instalando y configurando tres servidores de bases de datos los cuales podremos usar luego para desarrollar una aplicación en Xojo que se conecte a:

• PostgreSQL y pgAdmin
• cubeSQL y cubeSQL Web Admin
• MariaDB y phpMyAdmin

Nota: Los siguientes archivos de configuración están disponibles en GitHub: jo-tools/docker.

Requisitos

Obviamente necesitamos tener instalado Docker, y dado que estamos hablando de ser desarrolladores y hacer esto en nuestro propio equipo de desarrollo instalaremos Docker Desktop. Con Desktop Desktop podrás iniciar, detener y borrar posteriormente los Contenedores que vamos a crear con absoluta sencillez. Cuando está vacío (sin contenedores instalados), tiene este aspecto:

¡Ahora estamos listos para empezar…! Pero espera, aun queda algo de lo que debemos hablar primero.

Almacenamiento de Datos

¿Dónde almacenarán los servidores de bases de datos sus datos?

Si quieres aprender todos estos detalles, te recomiendo que visites la Documentación de Docker: Manage Data in Docker. Lo que necesitamos saber es esto:

Docker tiene dos opciones para que los contenedores guarden los archivos en el equipo host, de modo que los archivos sean persistentes una vez que se detenga la ejecución de los contenedores: Volumes y Bind Mounts.

¿Por qué es importante saber esto? Bueno, asumamos que creamos y detenemos un contenedor “PostgreSQL Server”. Piensa en dicho Contenedor como una “máquina virtual” o bien una bolsa. Puede guardar los datos, correcto; pero una vez que borres dicho contenedor o tires esa bolsa… entonces también perderás todos los datos almacenados.

¡Puede que eso sea lo que deseas! Por ejemplo si sólo quieres jugar con alguna herramienta y no te importa perder los datos que estés creando. Sin embargo, si quisieras hacer una copia de seguridad de forma sencilla de dichos datos, o bien actualizar un contenedor desde “v.15” a “v.16” y mantener la información existente entonces es cuando se necesitan los Volúmenes y los Bind Mounts.

Extraído de la documentación:

Volúmenes:

Los volúmenes son el mecanismo preferido para la persistencia de los datos generados y utilizados por los contendores de Docker. Están completamente gestionados por Docker.

Bind Mounts:

Los datos se almacenan en un directorio en el equipo host, el cual se monta sobre el contendor.

De acuerdo, dos opciones… ¿cuál es la diferencia?

Los Bind Mounts son una carpeta en el host (tu equipo de desarrollo). De esta forma puedes consultarlos fácilmente, así como ver/editor/hacer copias de seguridad de sus datos. Puede ser la opción a tener en cuenta si necesitas un acceso sencillo a dichos archivos.

Los Volúmenes son el modo preferido, dado que se gestionan desde Docker. Mediante Docker Desktop puedes ver los contenidos, pero no es tan sencillo ver/editar los archivos dado que no puedes montarlos como un volumen o carpeta más en tu equipo de desarrollo. Por supuesto también hay otros modos avanzados, en los cuales no me adentraré en este artículo. Así que, decididamente, es la mejor opción cuando no necesitas trabajar con dichos archivos o bien abrirlos con otras herramientas. La otra razón por la que no necesitarás los Bind Mounts para nuestros servidores de bases de datos es que simplemente podemos utilizar sus herramientas de administración para importar/exportar datos como meros volcados de la base de datos.

De acuerdo, empecemos y configuremos algunos servidores de bases de datos.

PostgreSQL Server y pgAdmin

Usemos la configuración de ejemplo correspondiente a Volúmenes para el almacenamiento de datos disponible aquí: GitHub: jo-tools/docker – local-postgres-volumes.

Descarga el archivo docker-compose.yml desde mi repositorio de GitHub y guárdalo en una carpeta de tu equipo.

Yo lo guardaré en: ~/Docker/local-postgres-volumes

YAML file: docker-compose.yml

Algo a tener en cuenta cuando se trata de escribir y editar archivos YAML:

• El indentado se realiza con espacios, no con tabuladores.
• El indentado ha de ser exacto (utiliza siempre dos espacios), o de lo contrario obtendrás errores de sintaxis.

Echemos un vistazo a este docker-compose.yml

x-common-timezone: &services-timezone Etc/UTC
 
name: local_postgresql
services:
  postgres-server:
    container_name: postgresql
    hostname: postgresql
    image: postgres:16-alpine
    volumes:
      - postgresql_data:/var/lib/postgresql/data
    environment:
      TZ: *services-timezone
      PGTZ: *services-timezone
      POSTGRES_PASSWORD: postgres
      POSTGRES_USER: postgres
      POSTGRES_DB: postgres
    networks:
      - local_postgresql_net
    ports:
      - 5432:5432
    restart: unless-stopped
 
  pgadmin:
    container_name: pgadmin4
    hostname: pgadmin4
    image: dpage/pgadmin4:8
    environment:
      TZ: *services-timezone
      PGADMIN_DEFAULT_EMAIL: admin@postgres.sql
      PGADMIN_DEFAULT_PASSWORD: admin
      PGADMIN_CONFIG_UPGRADE_CHECK_ENABLED: "False"
      PGADMIN_CONFIG_SERVER_MODE: "False"
      PGADMIN_CONFIG_MASTER_PASSWORD_REQUIRED: "False"
    networks:
      - local_postgresql_net
    volumes:
      - pgadmin4_data:/var/lib/pgadmin
    ports:
      - 5433:80
    restart: unless-stopped
    depends_on:
      - postgres-server
 
volumes:
  postgresql_data:
    driver: local
    name: postgresql_data
  pgadmin4_data:
    driver: local
    name: pgadmin4_data
 
networks:
  local_postgresql_net:
    name: local_postgresql

En la primera jerarquía tenemos:

• x-common-timezone: &services-timezone Etc/UTC

En esta extensión definimos el valor escalar para la franja horaria a utilizar en las variables de entorno para ambos servicios. La plantilla utiliza UTC (que también es la empleada por omisión por Docker). Puedes cambiarla por tu franja horaria, por ejemplo Europe/Zurich. Puede que sea lo deseado si vas a seleccionar la fecha/hora actuales posteriormente desde el servidor de la base de datos.

• name: local_postgresql

Este es el nombre de esta “configuración”. Lo veremos posteriormente en los Contenedores de Docker Desktop. Aquí es donde también podremos iniciar/detener/borrar la configuración en cualquier momento.

• services:

Aquí definimos dos servicios para esta configuración: postgres-server y pgadmin.

• volumes:

Y dos volúmenes: uno para el servidor de bases de datos y otro para la herramienta de administración.

• networks:

Ambos contenedores estarán en la misma red.

Cuando miramos los dos servicios postgres-server y pgadmin4:

• container_name:

El nombre del Contenedor. Luego lo veremos como un sub-elemento de la configuración docker-compose bajo el nombre de local_postgresql.

• hostname:

Piensa en el container como en una máquina virtual. Cada uno tiene su nombre de host; y los dos contenedores de esta configuración utilizan la misma red, de modo que pueden comunicarse mediante su nombre de host.

• image:

Este es básicamente el contenido del contenedor. Vamos a instalar:

• postgres:16-alpine

PostgreSQL Server en su versión 16.x, ejecutándose en Linux Alpine (una distribución muy ligera).

• dpage/pgadmin4:8

pgAdmin 4 en su versión 8.x como herramienta de administración.

• environment:

Aquí se definen las variables de entorno para los contenedores. TZ define la franja horaria y utiliza el valor que se haya definido en la extensión de la parte superior. Las otras variables de entorno contienen los valores por defecto y los estándares – se utilizan cuando los contenedores se inician por primera vez para definir los login por defecto, usuarios y contraseñas. Nuestro servidor PostgreSQL tendrá un login por defecto en el que tanto el usuario como la contraseña serán “postgres”. En pgAdmin hemos configurado el auto-logado sin requerir autenticación, además de haber desactivado las comprobaciones de actualizaciones.

• networks:

Recuerda: ambos en la misma red (definido posteriormente).

• volumes:

El formato en este caso es: nombre_de_volumen:/montar/en/carpeta

Posteriormente veremos estos volúmenes en Docker Desktop. Estos contendrán los datos. Generalmente la documentación de las Imágenes de Docker explican qué carpetas se utilizan a la hora de guardar los datos, de modo que pueden ser montados tanto en un Volumn o bien un Bind Mount.

• ports:

El formato en este caso es: puerto-del-host:puerto-del-contenedor

Para el Servidor PostgreSQL estamos usando 5432:5432, lo que significa que podemos conectar en nuestro equipo de desarrollo con el puerto 5432 (y este será redirigido al contenedor que ejecuta PostgreSQL Server, el cual estará escuchando en el puerto 5432 dentro del contenedor). pgAdmin está funcionando en el Puerto 80 en el container, pero conectamos a él desde nuestro equipo de desarrollo mediante el Puerto 5433.

• restart: unless-stopped

Esto significa básicamente: si tienes esta configuración funcionando y reinicias tu host (el equipo de desarrollo), entonces se reiniciará automáticamente esta configuración. Si vas a detener esta configuración (porque no la necesites en funcionamiento todo el tiempo), entonces también se detendrá tras un reinicio.

Iniciar la Configuración de Docker Compose

Dado que no podemos utilizar Docker Desktop para iniciar una configuración de Docker Compose (quizá se añada esta capacidad en el futuro), hemos de utilizar el Terminal. Cambia al directorio en el que se encuentre el archivo docker-compose.yml y teclea: docker-compose up -d

Se obtendrán las Imágenes referenciadas, se creará la red definida y se iniciarán los Contenedores.

Abre el Dashboard en Docker Desktop y mira en Container. Encontrarás una configuración con el nombre local_postgresql con los dos contenedores: postgresql y pgadmin4:

De hecho estarán levantados y en funcionamiento.

Si quieres detener esta configuración sólo has de pulsar el botón bajo “Actions”. Al hacerlo los detendrá incluso tras un reinicio. En el caso de que necesites volver a ejecutar nuevamente la configuración posteriormente, sólo has de pulsar el botón “Run”.

Bajo Volumes podemos ver los que hemos creado:

Puedes hacer clic en uno para ver sus contenidos. Estos serían los datos de postgresl:

Conectar Con PGADMIN4

Vuelve de nuevo a “Containers” y haz clic en el enlace “5433:80” en la columna “Port” del container “pgadmin4” en Docker Desktop, o bien abre un navegador y dirígete a http://localhost:5433.

Dado que es la primera vez que lanzas pgAdmin4 necesitamos añadir un servidor, al cual he nombrado como “Docker”:

En el registro “Connection” hemos de introducir los datos de conexión:

Los valores para Username y password son los asignados por defecto (¿recuerdas las variables de entorno?). En el caso de esta configuración local de desarrollo he elegido la opción correspondiente a guardar contraseña.

La parte más interesante es la relativa al hostname.

• ¡No puedes utilizar localhost aquí!
  El motivo es simple: pgAdmin está ejecutándose en un Container (piensa nuevamente en ello como en una máquina virtual), de modo que su “localhost” es el contenedor que está ejecutando pgadmin4 y no tu equipo, y tampoco el Container en el que está ejecutando postgres.
• En mi caso he introducido: host.docker.internal
  Esto se explica en la Documentación de Docker: Networking, donde se indica que el host tiene una dirección IP que cambia o bien ninguna en el caso de que no tengas acceso a la red. Te recomiendo que conectes a través del nombre especial del DNS host.docker.internal, el cual se resolverá a la dirección IP interna utilizada por el host.
• Otra opción sería la de utilizar el hostname: postgresql.
  ¿Y por qué funcionaría esto? Bueno, hemos configurado estos dos contenedores para que estén en la misma red, y el servidor se está ejecutando con el nombre de host “postgresql”.

Y allá vamos: expande las entradas del servidor “Docker” recién añadido, haz clic en la base de datos principal “postgres” y ejecuta la consulta: SELECT version();

Conectar con Xojo

Ahora ya estamos listos para usar Xojo y trabajar con las aplicaciones utilizando nuestro servidor PostgreSQL local. Conectemos con nuestro servidor local que se está ejecutando en Docker. Como prueba simple, he incluido el siguiente código en el evento Opening de una Label:

Var db As New PostgreSQLDatabase
db.Host = "localhost"
db.UserName = "postgres"
db.Password = "postgres"
db.Port = 5432
 
Call db.Connect
 
Var rs As RowSet = db.SelectSQL("SELECT version();")
Me.Text = rs.Column("version").StringValue

Información Adicional

Has visto cuan sencillo resulta levantar PostgreSQL con Docker Compose y conectar con dicho servidor utilizando pgAdmin4 y Xojo. ¿Qué más necesitamos saber?

Imágenes

Encontrarás Imágenes disponibles en Docker Hub. En la anterior configuración hemos utilizado postgres y pgAdmin4. Si las consultas en Docker Hub, verás que existen múltiples imágenes. Puedes seleccionarlas por Tag. El Tag “postgres:16-alpine” utilizado aquí significa que obtenemos la última versión 16 (16.2 y algún mes posterior quizá la 16.3 o la 16.4). Si por algún motivo necesitamos utilizar exactamente la versión 16.1, entonces deberemos de utilizar el Tag correspondiente, como por ejemplo “postgres:16.1-alpine”.

Configuración usando Bind Mounts

Si vas a probar docker-compose.yml con los Bind Mounts desde aquí: GitHub: jo-tools/docker – local-postgres-bindmounts, entonces observarás una diferencia en la configuración aquí:

volumes:
– ./postgresql_data:/var/lib/postgresql/data

En este caso no obtendrás un Volumen en Docker sino que crearás una carpeta con el nombre postgresql_data en la carpeta en la que hayas guardado docker-compose.yml y desde la cual hayas lanzado la configuración mediante docker-compose up -d.

Comandos de Docker Compose

Ya hemos mencionado que la primera ejecución de la configuración de Docker Composer requerirá el uso del Terminal. Los siguientes comandos también se han de ejecutar desde el mismo directorio que contenga el archivo yaml:

docker-compose up -d

Este comando busca el archivo docker-compose.yml, obtiene las imágenes, realiza toda la configuración y ejecuta los contenedores. También utilizas este comando para reiniciar la esta configuración en el caso de que la hayas detenido.

docker-compose stop

Detiene todos los servicios de esta configuración. También puedes hacerlo utilizando los botones en la sección Register “Containers” desde Docker Desktop.

docker-compose down -v

Este comando elimina todos los servicios y volúmenes de la configuración. Utilízalo para limpiar los Contenedores, Volúmenes y sus datos. También puedes pulsar los botones Delete en Docker Desktop tanto en “Containers” como en “Volumes” (y opcionalmente en “Image”).

Si omites la opción “-v”, entonces dejará los Volúmenes en su ubicación. Esto puede resultar interesante si deseas mantener los datos, en el caso de que vuelvas a ejecutar nuevamente esta configuración en algún momento posterior.

docker-compose down
docker-compose pull
docker-compose up -d

Estos tres comandos se encargarán de desactivar los contenedores existentes (dejando tanto los volúmenes como los datos almacenados en su lugar), luego recuperará las últimas versiones desde Docker Hub y configurará todo de nuevo.

¿Recuerdas que hemos utilizado la imagen “postgres:16-alpine”, y que hemos obtenido PostgreSQL 16.2? Una vez que esté disponible PostgreSQL 16.3 podemos ejecutar estos comandos y obtener así la última versión. Nuevamente resulta una forma muy sencilla de actualiza, ¿no es cierto?

CubeSQL y CubeSQL Web Admin

Otro servidor de bases de datos popular en Xojo es cubeSQL. Básicamente añade gestión multiusuario (incluyendo grupos, privilegios y mucho más) sobre SQLite.

cubeSQL es un sistema de gestión de base de datos relacional de alto rendimiento creado sobre el motor de bases de datos SQLite.

Es el servidor de bases de datos ideal tanto para los desarrolladores que quieran convertir una solución de bases de datos de usuario único en un proyecto multiusuario y también para las empresas que estén buscando un sistema de gestión de bases de datos fácil de usar.

Encontrarás una configuración de ejemplo para Docker Composer aquí: GitHub: jo-tools/docker – local-cubesql-volumes. Para conectar con Xojo necesitarás un plugin, que puede descargarse desde GitHub: cubesql/cubeSQLAdmin

cubeSQL Web Admin – Escrito con Xojo Web

cubeSQL tiene una aplicación de escritorio para su administración, la cual encontrarás en el repositorio de GitHub indicado anteriormente. Como puedes suponer, una aplicación basada en escritorio no es muy conveniente cuando se trata de una configuración para Docker Compose.

Si bien he estado utilizando Xojo para aplicaciones de escritorio y de consola desde hace tiempo, nunca he utilizado realmente con anterioridad Xojo Web. Eso es lo que me ha llevado a tomar esta oportunidad para hacerlo; y lo cierto es que en un periodo muy breve de tiempo (la mayor parte de la funcionalidad en el tiempo libre de un fin de semana), he podido escribir una app “Xojo Web Admin“. Ha sido un placer crear algo más que simples proyectos de ejemplo, y de hecho me encanta crear algo útil mientras aprendo algo nuevo. Para ser honesto he encontrado un par de bugs en el Framework Web de Xojo mientras que estaba escribiendo cubeSQL Web Admin, pero estos han sido solucionados e implementados para la próxima versión disponible de Xojo (tomando como referencia, el momento de escritura de este artículo). La tarea de finalizar y pulir este proyecto para que esté disponible de forma pública me tomó un par de tardes adicionales.

cubeSQL Web Admin es un proyecto de código abierto, de modo que puedes echar un vistazo al código fuente (o aun mejor: contribuir y añadir más características, encontrar fallos y corregirlos). Es probable que encuentres algunas cosas interesantes, como por ejemplo:

• Cómo utilizar Xojo Web para crear una app que se ejecute en un container de Docker. Consulta también esta entrada del blog: Ejecutar Aplicaciones Xojo Web en Docker
• Una nueva característica añadida durante el desarrollo de GitHub: cubeSQL Web Admin: El Script Post Build crea una Imagen Docker “Multi Arquitectura” (linux/amd64 y linux/arm64v8) mediante la compilación de la app Xojo web en para las arquitecturas Linux x86 64-bit y Linux ARM 64-bit. Esto permite ejecutar la Imagen de Docker de forma nativa en Macs que tengan tanto procesadores Intel como ARM.
• Como utilizar Argumentos de Ejecución y Variables de Entorno para la configuración. Esto nos permite configurar las variables de entorno en nuestra configuración Docker para preconfigurar los datos de conexión.
• La aproximación con subclases de WebContainer que implementan la interfaz WebDataSource. La clase base cntDatasourceBase puede configurarse para:
• Poder realizar búsquedas (La ventana principal muestra/oculta el WebSearchField en el caso de que una subclase del Container se defina en un sentido u otro).
• Definir cuantos Campos de un RowSet deben mostrarse (cubeSQL utiliza comandos especiales personalizados para la administración, de modo que no podemos definir diferentes columnas y tampoco hay paginación cuando se utilizan estos comandos personalizados).
• Definir Campor virtuales que se mostrarán en el WebListbox pero que no son parte de un RowSet.
• Internamente, la clase base utiliza un array de diccionarios que se construye a partir del RowSet, de modo que podemos utilizarlo con otros DataSources externos, por ejemplo.
• Mostrar los Campos en el WebListbox, al tiempo que permite que cada Container sobreescriba el comportamiento definido por omisión (consultar por ejemplo las bases de datos en las que se utiliza un WebListboxImageRenderer para crear un campo virtual. En función de un par de Columnas en el RowSet se muestra el Icono de Estado apropiado).

Para conectarse con esta configuración de cubeSQL desde Xojo he incluido el siguiente código en el evento Opening de una Label:

Var db As New CubeSQLServer
db.Host = "localhost"
db.UserName = "admin"
db.Password = "admin"
db.Port = 4430
 
Call db.Connect
 
Var rs As RowSet = db.SelectSQL("SHOW INFO FOR KEY server_version")
Me.Text = rs.Column("value").StringValue

MariaDB y phpMyAdmin

MariaDB Server es una base de datos relacional de alto rendimiento de código abierto, derivada de MySQL.

Encontrarás una configuración de ejemplo para Docker Composer aquí: GitHub: jo-tools/docker – local-mariadb-volumes.

No voy a explicar mucho más aquí sobre MariaDB (MySQL) o phpMyAdmin. Creo que podrás descubrir por ti mismo cuan fácil es ejecutar la herramienta de administración y conectar con el servidor cuando busques en los contenidos de este docker-compose.yml. Pero desde que se trata de un servidor de bases de datos ampliamente utilizado, deseo proporcionar también una configuración para esta combinación.

Como prueba sencilla para esta configuración, he puesto el siguiente código en el evento Opening de una Label:

Var db As New MySQLCommunityServer
db.Host = "127.0.0.1"
db.UserName = "root"
db.Password = "mariadb"
db.Port = 3306
 
Call db.Connect
 
Var rs As RowSet = db.SelectSQL("SELECT version() AS version;")
Me.Text = rs.Column("version").StringValue

Por algún motivo, la conexión necesita una dirección IP o el Hostname (y no funciona con localhost).

Conclusiones

Las configuraciones vistas en este artículo tienen como propósito la configuración local de pruebas, no los utilices en producción. Incluso en un equipo local de desarrollo no deberías de ejecutar los servicios con estas credenciales de logado iniciales, de modo que cámbialas.

El propósito final es el de explicar cómo funciona Docker Compose y ver de qué forma puede ayudar a los desarrolladores a realizar configurar de una forma sencilla entornos de trabajo locales para trabajar con aplicaciones de bases de datos. Por supuesto estos ejemplos pueden servir como punto de partida para aquellos que no hayan utilizado Docker previamente.

¡Eso es todo amigos!

Confío que esta breve introducción sobre cómo utilizar Docker y los servidores de bases de datos en combinación con Xojo te sirva de utilidad y como alimento para la mente.