SQL Server en Docker en Linux

Por qué Docker en lugar de una instalación local

[0:00 - 0:57] Tim comienza con el caso en contra de las instalaciones nativas de bases de datos. El argumento principal: los motores de bases de datos están diseñados para servidores dedicados. Instalarlos localmente significa que consumen recursos ya sea que los estés usando o no, y gestionar múltiples versiones (SQL 2019, 2022, 2025) en la misma máquina rápidamente se convierte en una carga de mantenimiento.

Los contenedores Docker cambian este modelo. Cada base de datos se ejecuta en su propio entorno aislado. Iníciala cuando la necesites, detenla cuando no. Elimínala y comienza de nuevo sin configuraciones residuales. Para desarrollo y pruebas, este enfoque es más rápido de configurar, más limpio de mantener y más flexible que una instalación tradicional.

Corrigiendo la política de reinicio de Portainer

[0:57 - 2:17] Antes de lanzar SQL Server, Tim nota que Portainer (la herramienta GUI de gestión para contenedores Docker del episodio anterior) no está corriendo. Se cerró cuando la máquina se apagó la última vez porque no se configuró una política de reinicio.

La solución son dos comandos:

// Set Portainer to restart automatically (unless manually stopped)
docker update --restart unless-stopped portainer

// Start it now
docker start portainer

// Set Portainer to restart automatically (unless manually stopped)
docker update --restart unless-stopped portainer

// Start it now
docker start portainer

La política unless-stopped significa que Portainer se reiniciará automáticamente al reiniciar, pero se mantendrá apagado si lo detiene explícitamente. Después de iniciar, Portainer es accesible en localhost:9000 en el navegador. Tim recomienda esta política para herramientas de gestión que quieras que funcionen todo el tiempo, manteniendo los contenedores de bases de datos en inicio manual.

El comando Docker Run para SQL Server

[2:17 - 6:09] Toda la configuración de SQL Server se reduce a un comando. Tim lo transfiere desde su máquina Windows usando LocalSend (cubierto en el video de la misión secundaria anterior), luego lo desglosa pieza por pieza:

// Single command to launch SQL Server 2025 in Docker
docker run -e "ACCEPT_EULA=Y" -e "SA_PASSWORD=Test12345" -p 1433:1433 --name sql2025 mcr.microsoft.com/mssql/server:2025-latest

// Single command to launch SQL Server 2025 in Docker
docker run -e "ACCEPT_EULA=Y" -e "SA_PASSWORD=Test12345" -p 1433:1433 --name sql2025 mcr.microsoft.com/mssql/server:2025-latest

Cada flag tiene un propósito específico. La bandera -e "ACCEPT_EULA=Y" acepta el acuerdo de licencia de Microsoft. La bandera -e "SA_PASSWORD=Test12345" establece la contraseña del administrador del sistema en texto plano, que Tim reconoce que está bien para el desarrollo local, pero nunca debe usarse para nada en producción. La bandera -p 1433:1433 mapea el puerto interno de SQL Server del contenedor al mismo puerto en la máquina host. La bandera --name sql2025 le da al contenedor una etiqueta legible por humanos. Y la etiqueta de imagen 2025-latest extrae la versión más reciente de SQL Server 2025 del registro de contenedores de Microsoft.

Después de ejecutar el comando, Docker descarga las capas de imagen, las extrae y comienza el servidor. Todo el proceso lleva un par de minutos, la mayor parte es la descarga inicial.

Verificación en Portainer

[6:09 - 7:04] De vuelta en Portainer, el nuevo contenedor de SQL Server aparece en la lista de contenedores, mostrando su estado como en ejecución. Tim hace una elección deliberada aquí: sin montaje de volumen para persistencia de datos. Si se elimina el contenedor, las bases de datos dentro de él también desaparecen.

Eso es intencional para una configuración de desarrollo. Comenzar de nuevo significa sin datos de prueba acumulados, sin deriva de esquema de experimentos anteriores, y sin problemas de "funciona en mi máquina" causados por estado residual. Si alguna vez necesitas preservar bases de datos antes de eliminar un contenedor, puedes exportarlas primero, pero el enfoque de hoja limpia es el flujo de trabajo preferido para el trabajo local.

Conectando desde VS Code

[7:04 - 8:50] Para gestionar la base de datos, Tim instala la extensión SQL Server para VS Code de Microsoft. Después de la instalación, aparece un nuevo panel de SQL Server en la barra lateral donde puedes agregar conexiones.

Los parámetros de conexión son mínimos. El nombre del servidor es . (punto), que significa localhost. Dado que el contenedor mapea el puerto 1433 (el predeterminado de SQL Server), no es necesario especificar un número de puerto. El nombre de usuario es sa, la contraseña es la del comando de Docker y la base de datos predeterminada es master. Confía en el certificado del servidor cuando se te solicite.

Una vez conectado, VS Code muestra el icono de Docker junto a la conexión, confirmando que detectó el entorno contenedorizado. Las bases de datos del sistema (master, model, msdb, tempdb) aparecen en el árbol, listas para su uso.

Creando una base de datos y ejecutando consultas

[8:50 - 12:45] Con la conexión establecida, Tim crea una nueva base de datos llamada PeopleDB directamente desde la barra lateral de VS Code. Dentro de ella, crea una tabla People usando el diseñador visual, añadiendo una columna Id de auto-incremento, una columna FirstName y una columna LastName (ambas NVARCHAR(50), no nulas).

Luego abre una nueva ventana de consulta e inserta datos de prueba:

INSERT INTO dbo.People (FirstName, LastName)
VALUES
    ('Tim', 'Corey'),
    ('Sue', 'Storm'),
    ('Dave', 'Corey')

INSERT INTO dbo.People (FirstName, LastName)
VALUES
    ('Tim', 'Corey'),
    ('Sue', 'Storm'),
    ('Dave', 'Corey')

Ejecutar un SELECT confirma que las filas están en su lugar:

SELECT * FROM dbo.People
-- Returns: Tim Corey, Sue Storm, Dave Corey

SELECT * FROM dbo.People WHERE LastName = 'Corey'
-- Returns: Tim Corey, Dave Corey

SELECT * FROM dbo.People
-- Returns: Tim Corey, Sue Storm, Dave Corey

SELECT * FROM dbo.People WHERE LastName = 'Corey'
-- Returns: Tim Corey, Dave Corey

El ciclo completo (crear base de datos, diseñar tabla, insertar datos, consultar con filtros) lleva solo unos minutos. Todo se ejecuta dentro del contenedor Docker, gestionado a través de VS Code, sin SQL Server instalado en la máquina host.

Detener, iniciar y gestionar recursos

[12:45 - 14:20] Cuando hayas terminado de trabajar con SQL Server, detenerlo es un solo clic en Portainer o un comando en la terminal:

docker stop sql2025

docker stop sql2025

Un contenedor detenido libera todos los recursos de CPU y memoria. Lo único que sigue consumiendo es espacio en disco para la imagen y los archivos del contenedor, lo cual es comparable a (y generalmente más pequeño que) una instalación nativa de SQL Server.

Tim señala que esta es la ventaja central sobre una instalación tradicional. Un SQL Server instalado localmente se ejecuta como un servicio de Windows o Linux, consumiendo recursos todo el tiempo. Un contenedor Docker solo usa recursos cuando decides iniciarlo.

Ejecutar múltiples versiones lado a lado

[14:20 - 17:17] Una de las características más prácticas de Docker para el desarrollo de bases de datos es la capacidad de ejecutar múltiples versiones simultáneamente. Tim lo demuestra lanzando SQL Server 2022 junto al contenedor 2025 existente:

// SQL Server 2022 on a different port
docker run -e "ACCEPT_EULA=Y" -e "SA_PASSWORD=Test12345" -p 2022:1433 --name sql2022 mcr.microsoft.com/mssql/server:2022-latest

// SQL Server 2022 on a different port
docker run -e "ACCEPT_EULA=Y" -e "SA_PASSWORD=Test12345" -p 2022:1433 --name sql2022 mcr.microsoft.com/mssql/server:2022-latest

La diferencia clave es el mapeo del puerto: -p 2022:1433 mapea el puerto interno 1433 del contenedor al puerto 2022 en el host. Esto evita un conflicto de puertos con la instancia de 2025 que ya está usando 1433. Después de completar la descarga, ambos contenedores aparecen en Portainer, ambos funcionando al mismo tiempo.

Esto es útil cuando un cliente ejecuta SQL Server 2022 en producción, pero el equipo desarrolla contra 2025. Cambiar entre versiones no requiere ninguna reinstalación, solo iniciar el contenedor correcto. Todas las imágenes de SQL Server disponibles (2017, 2019, 2022, 2025) se listan en mcr.microsoft.com, y el mismo enfoque funciona para MySQL, PostgreSQL, MongoDB y Cosmos DB.

Resumen: Un comando para un entorno completo de base de datos

[17:17 - 17:47] El tutorial demuestra que un solo comando Docker reemplaza lo que solía ser un proceso de instalación de múltiples pasos con asistentes de configuración, gestión de servicios y conflictos de versiones. El contenedor comienza en minutos, ejecuta solo cuando es necesario y puede ser eliminado sin dejar rastros en el sistema host.

Para los desarrolladores que trabajan en múltiples proyectos con diferentes requisitos de bases de datos, este patrón escala limpiamente. Cada proyecto obtiene su propio contenedor, su propia versión y sus datos aislados.

Conclusión

[17:47 - 18:20] En resumen: SQL Server en Linux se ejecuta en Docker con un solo comando docker run. Conéctate a él desde VS Code usando la extensión SQL Server, crea bases de datos y tablas a través de la barra lateral y escribe consultas como lo harías contra cualquier otra instancia de SQL Server. Cuando termines, detén el contenedor y reclama los recursos.

La combinación de Docker para la gestión de bases de datos y VS Code para consultar te da un flujo de trabajo completo de desarrollo SQL en Linux sin necesidad de una instalación nativa de base de datos.

Ejemplo de consejo: Si necesita probar contra una versión específica de SQL Server, consulte mcr.microsoft.com para todas las etiquetas disponibles. Puedes ejecutar 2017, 2019, 2022 y 2025 simultáneamente asignando a cada contenedor un puerto distinto del host (1433, 2019, 2022, 2025). Nómbralos de manera descriptiva (sql2019, sql2022) para que la salida de Portainer y docker ps se mantenga legible.

Mira el video completo en su canal de YouTube y obtén más información sobre el desarrollo de C# con bases de datos en Linux.