背景:なぜSQL ServerをDocker化すべきなのか?
新しいプロジェクトに参加した際、SQL Serverのインストールやインスタンス設定、バージョンの競合解消だけで午前中を丸々潰してしまった経験はないでしょうか。Dockerを使えば、このプロセスはコマンド一つで完結します。SQL ServerをDocker化することで、ローカルからStaging、Productionまで環境を統一でき、「自分のマシンでは正常に動いていたのに」という開発現場でよくある問題を完全に排除できます。
以前は、SQL Serverといえば重厚なWindows Serverが必要不可欠でした。しかし現在、Linux版のSQL Serverは非常に軽量かつ安定して動作します。実際の導入経験から言うと、SQL Serverのコンテナはわずか15〜20秒ほどで起動し、Windows上で直接実行するよりもリソース消費が明らかに少ないです。
Docker Compose (V2) によるSQL Serverのインストール
長くて覚えにくい docker run コマンドを使う代わりに、docker-compose.yml を使用しましょう。これにより、設定を一元管理でき、チームメンバーとの共有も容易になります。
# 作業ディレクトリの作成
mkdir mssql-docker && cd mssql-docker
touch docker-compose.yml
以下が最適化された設定ファイルです。重要な注意点として、SQL Serverの実行には少なくとも2GBのRAMが必要です。割り当てがそれ以下だと、コンテナは不明なエラーコードを出して即座に終了してしまいます。
services:
sqlserver:
image: mcr.microsoft.com/mssql/server:2022-latest
container_name: mssql_db
restart: always
environment:
- ACCEPT_EULA=Y
- MSSQL_SA_PASSWORD=YourStrong@Password123
- MSSQL_PID=Developer
ports:
- "1433:1433"
volumes:
- mssql_data:/var/opt/mssql
volumes:
mssql_data:
注意点:
MSSQL_SA_PASSWORD: パスワードは、大文字、小文字、数字、特殊文字を含む必要があります。MSSQL_PID: 開発目的であれば、Enterprise版の全機能を無料で利用できるDeveloper版を選択するのが最適です。
Volumeの設定:データを安全に守る秘訣
Volumeを使用せずにコンテナを削除すると、コンテナ内のデータはすべて消失します。しかし、Linuxでのデータマウント(Bind Mount)は、UID의 権限問題により “Permission denied” エラーが発生しがちです。
SQL ServerはUID 10001の mssql ユーザーで実行されます。ホスト上のディレクトリを直接指定するBind Mountを使用する場合、手動で権限を付与する必要があります。私のおすすめは、上記の例のように Named Volume を使用することです。これによりDockerが権限を自動管理し、システムの安定性が向上します。
# bind mountを使用せざるを得ない場合は、このコマンドを実行して権限を付与します
sudo chown -R 10001:0 ./mssql-data
ユーザー管理:アプリにSAアカウントを絶対に使わない
アプリケーションのコード内で sa アカウントを使用することは、重大なセキュリティホールになります。適切な権限を持つ専用のユーザーを作成すべきです。コンテナに直接アクセスして、以下のコマンドを実行しましょう。
docker exec -it mssql_db /opt/mssql-tools/bin/sqlcmd \
-S localhost -U sa -P 'YourStrong@Password123'
接続に成功したら、以下のスクリプトを実行して新しいデータベースとユーザーを作成します。
CREATE DATABASE MyProjectDB;
GO
USE MyProjectDB;
CREATE LOGIN app_user WITH PASSWORD = 'AnotherStrongPassword!';
CREATE USER app_user FOR LOGIN app_user;
EXEC sp_addrolemember 'db_owner', 'app_user';
GO
「標準的」なBackupとRestoreのプロセス
データを失ってから慌ててバックアップ方法を探すのはやめましょう。Dockerなら、sqlcmd を通じて非常に迅速にバックアップが可能です。
1. データのバックアップ
このコマンドはコンテナ内に .bak ファイルを作成し、その後、それをホストマシンにコピーして保存します。
# ステップ1:コンテナ内でのバックアップ
docker exec -it mssql_db /opt/mssql-tools/bin/sqlcmd -S localhost -U sa -P 'YourStrong@Password123' -Q "BACKUP DATABASE [MyProjectDB] TO DISK = N'/var/opt/mssql/MyProjectDB.bak'"
# ステップ2:外部へコピー
docker cp mssql_db:/var/opt/mssql/MyProjectDB.bak ./MyProjectDB_$(date +%F).bak
2. データの復元
別のマシンでデータを復元する必要がある場合は、逆の手順を行うだけです。
# コンテナにファイルをコピー
docker cp ./MyProjectDB.bak mssql_db:/var/opt/mssql/
# Restoreコマンドを実行
docker exec -it mssql_db /opt/mssql-tools/bin/sqlcmd -S localhost -U sa -P 'YourStrong@Password123' -Q "RESTORE DATABASE [MyProjectDB] FROM DISK = N'/var/opt/mssql/MyProjectDB.bak' WITH REPLACE"
ステータス確認と管理ツール
SQL Serverが正常に動作しているか確認するには、定期的にログをチェックしましょう。Service Broker manager has started という行が表示されていれば、準備完了です。
docker logs -f mssql_db
管理ツールについては、Azure Data Studio をおすすめします。SQL Server Management Studio (SSMS) よりも非常に軽量で、LinuxやmacOSでも快適に動作します。
小技:もしアプリケーションの時刻がずれる場合は、Composeファイルに環境変数 TZ=Asia/Tokyo を追加してください。SQL Serverエンジン自体は通常UTCを使用しますが、タイムゾーンを同期させておくと、システムログの照合が非常に容易になります。
これらの共有が、Docker上でSQL Serverを運用する際の自信に繋がれば幸いです。Dockerの最大の利点は、失敗しても数秒で削除してやり直せることです。ぜひ積極的に試してみてください!

