Far girare Microsoft SQL Server in un container Docker è uno dei modi più rapidi per allestire un ambiente di sviluppo riproducibile, isolato e facile da eliminare. La parte delicata non è avviare l’immagine, ma gestire correttamente versione, password, volumi persistenti, collegamenti e licenza. Qui mostro una configurazione pratica, i comandi essenziali e i limiti da conoscere prima di usare questa soluzione in un progetto reale.
La configurazione giusta parte da dati persistenti e impostazioni coerenti
- Immagine consigliata: SQL Server Linux dal Microsoft Container Registry.
- Memoria minima: almeno 2 GB assegnati al container, meglio di più per database complessi.
- Persistenza: un volume Docker evita di perdere database e configurazione con la rimozione del container.
- Sicurezza: usare MSSQL_SA_PASSWORD, una password robusta e possibilmente un login diverso da sa.
- Edizione: Developer è adatta a sviluppo e test, non alla produzione.
Perché usare SQL Server con Docker
Un container permette di eseguire SQL Server senza installare direttamente il database nel sistema operativo principale. Per me il vantaggio più concreto è la riproducibilità: lo stesso ambiente può essere avviato da un collega, da una pipeline CI o su un altro computer con pochi comandi.
Questa soluzione è particolarmente utile per sviluppare applicazioni .NET, testare migrazioni Entity Framework, provare query su versioni diverse del database e creare ambienti temporanei per corsi o laboratori. Quando il test è finito, posso fermare o rimuovere il container senza lasciare un’installazione complessa sul computer.
Quando conviene davvero
- Per ambienti locali di sviluppo e test.
- Per progetti che devono avere una configurazione identica tra più sviluppatori.
- Per verificare compatibilità tra applicazione, driver e versione di SQL Server.
- Per pipeline automatiche che richiedono un database temporaneo.
Non considero invece il container una scorciatoia automatica per la produzione. Backup, monitoraggio, aggiornamenti, storage affidabile e alta disponibilità richiedono una progettazione più ampia rispetto a un semplice comando docker run.
Il limite delle architetture ARM
Le immagini ufficiali Linux di SQL Server sono supportate su host Intel e AMD x86-64. Su Mac con chip Apple Silicon o su altri sistemi ARM Docker può ricorrere all’emulazione, ma questa configurazione non è ufficialmente testata né adatta a essere considerata una base affidabile per ambienti importanti.
Come avviare il primo container
Servono Docker Engine oppure Docker Desktop, una macchina con risorse sufficienti e accesso al Microsoft Container Registry. Per un ambiente di sviluppo recente si può usare il tag di SQL Server 2025, mentre in scenari controllati è preferibile fissare una versione precisa invece di affidarsi sempre a latest.
Comando essenziale
docker pull mcr.microsoft.com/mssql/server:2025-latest
docker run \
-e "ACCEPT_EULA=Y" \
-e "MSSQL_SA_PASSWORD=Sostituisci_con_una_password_forte" \
-e "MSSQL_PID=Developer" \
-p 1433:1433 \
--name sqlserver \
--hostname sqlserver \
-d \
mcr.microsoft.com/mssql/server:2025-latestLa porta 1433 collega la porta del computer host a quella del database nel container. Il parametro ACCEPT_EULA=Y conferma l’accettazione della licenza, mentre MSSQL_PID=Developer seleziona l’edizione Developer.
La password deve avere almeno 8 caratteri e includere caratteri appartenenti ad almeno 3 categorie tra maiuscole, minuscole, numeri e simboli. Se la password non rispetta la policy, SQL Server può terminare subito dopo l’avvio. In questi casi il primo comando da controllare è:
docker logs sqlserverPer chi utilizza PowerShell, la sintassi delle virgolette può cambiare leggermente. Il concetto resta lo stesso, ma consiglio di evitare password reali direttamente nella cronologia della shell o nei file di progetto.
Perché fissare il tag in produzione
Il tag 2025-latest è comodo per iniziare, ma può cambiare quando viene pubblicato un nuovo aggiornamento. Per avere build ripetibili conviene usare un tag specifico, ad esempio una versione con cumulative update e distribuzione Ubuntu definite, oppure fissare l’immagine tramite digest.
Come conservare i database quando il container viene eliminato
Il container è usa e getta, i dati del database non dovrebbero esserlo. Fermare un container con docker stop conserva i file, ma eseguire docker rm senza un volume può cancellare database, log e configurazione. È l’errore più comune nelle prime prove.
Usare un volume Docker
docker volume create sqlserver-data
docker run \
-e "ACCEPT_EULA=Y" \
-e "MSSQL_SA_PASSWORD=Sostituisci_con_una_password_forte" \
-e "MSSQL_PID=Developer" \
-p 1433:1433 \
--name sqlserver \
--hostname sqlserver \
-v sqlserver-data:/var/opt/mssql \
-d \
mcr.microsoft.com/mssql/server:2025-latestIl volume sqlserver-data viene montato nella directory interna usata da SQL Server. In questo modo posso ricreare il container mantenendo i database, purché non elimini anche il volume.
Per verificare il volume disponibile:
docker volume inspect sqlserver-dataIn sviluppo preferisco spesso un volume nominato perché riduce i problemi di permessi tra Windows, macOS e Linux. In produzione, invece, è importante valutare storage, prestazioni I/O, snapshot e procedure di backup del sistema che ospita Docker.
Il volume non sostituisce il backup
Un volume protegge dai problemi legati alla rimozione del container, ma non da corruzione, cancellazioni accidentali o guasti del disco. Per dati importanti servono backup verificati, una copia separata e almeno un test periodico di ripristino.
Come collegarsi e fare una prima verifica
Una volta avviato il container, posso collegarmi da Azure Data Studio, SQL Server Management Studio, DBeaver o da qualsiasi applicazione compatibile con SQL Server. I parametri locali più comuni sono server localhost, porta 1433, utente sa e la password impostata all’avvio.
Per una verifica rapida direttamente dal container, nelle immagini recenti il percorso degli strumenti è:
docker exec -it sqlserver \
/opt/mssql-tools18/bin/sqlcmd \
-S localhost \
-U sa \
-P "Sostituisci_con_una_password_forte" \
-C \
-Q "SELECT @@VERSION;"L’opzione -C indica di considerare attendibile il certificato del server in questo ambiente locale. Non la interpreto come una configurazione di sicurezza per internet: in un sistema esposto servono certificati e regole di rete adeguati.
Leggi anche: Comandi DBCC SQL Server per controlli e manutenzione sicura
Creare un database di prova
docker exec -it sqlserver \
/opt/mssql-tools18/bin/sqlcmd \
-S localhost \
-U sa \
-P "Sostituisci_con_una_password_forte" \
-C \
-Q "CREATE DATABASE DemoApp;"Se il comando restituisce un errore di connessione subito dopo l’avvio, il database potrebbe essere ancora in fase di inizializzazione. Controllo lo stato con docker ps e leggo i messaggi di docker logs. Un container in esecuzione non significa necessariamente che SQL Server abbia già completato l’avvio.
Edizioni, licenze e uso in produzione
La scelta dell’edizione non è un dettaglio tecnico secondario. L’immagine può essere la stessa, ma licenza e diritti d’uso cambiano in base al valore di MSSQL_PID e allo scenario.
| Edizione | Uso tipico | Limite principale |
|---|---|---|
| Developer | Sviluppo e test | Non utilizzabile come server di produzione |
| Express | Applicazioni leggere e piccoli progetti | Limiti di capacità e funzionalità |
| Evaluation | Valutazione temporanea | Durata limitata, senza diritti produttivi permanenti |
| Standard o Enterprise | Carichi produttivi con licenza adeguata | Costi e gestione della licenza |
Developer include molte funzionalità dell’edizione Enterprise, ed è quindi eccellente per sviluppare e testare. Proprio per questo può trarre in inganno: una configurazione che funziona in locale non autorizza a usarla in produzione.
Per un ambiente produttivo valuterei anche Kubernetes, un servizio gestito oppure una macchina virtuale dedicata. Docker può essere una buona piattaforma operativa, ma non elimina la necessità di pianificare alta disponibilità, patching, monitoraggio, backup e gestione delle credenziali.
Problemi comuni e controlli da fare
Quando qualcosa non funziona, di solito la causa rientra in pochi casi ricorrenti. Io seguo questa sequenza perché evita di modificare configurazioni a caso.
-
Container terminato: controllare
docker logs sqlserver, soprattutto password e accettazione della licenza. -
Porta occupata: usare una porta diversa, per esempio
-p 1434:1433, e collegarsi alocalhost,1434. - Connessione rifiutata: attendere il completamento dell’avvio e verificare che Docker Desktop abbia risorse sufficienti.
- Dati scomparsi: controllare che il container sia stato avviato con il volume corretto.
- Prestazioni lente: verificare memoria assegnata, spazio disco e latenza del volume montato.
- Errore su Mac ARM: considerare che l’immagine SQL Server Linux non offre supporto ufficiale per questa architettura.
Un’altra attenzione riguarda la variabile SA_PASSWORD. Nelle indicazioni aggiornate è deprecata e va sostituita con MSSQL_SA_PASSWORD. Usare il nome vecchio può generare configurazioni ambigue, soprattutto quando si copia un vecchio esempio da un tutorial.
La configurazione minima che userei per un progetto reale
Per sviluppo locale sceglierei SQL Server 2025 con un tag controllato, un volume nominato e una password fornita tramite variabile d’ambiente non versionata. Terrei separati i dati dal container, limiterei la porta all’ambiente necessario e creerei subito un utente applicativo con permessi inferiori rispetto a sa.
Il punto decisivo è questo: Docker rende SQL Server veloce da avviare e semplice da replicare, ma non trasforma automaticamente un database temporaneo in un servizio pronto per la produzione. Se volume, backup, licenza e aggiornamenti sono trattati correttamente, resta una delle soluzioni più pratiche per lavorare ogni giorno con database Microsoft senza appesantire il sistema principale.
