Linux 上で Docker を使った SQL Server

ローカルインストールの代わりに Docker を使用する理由

[0:00 - 0:57] ティムは、ネイティブデータベースインストールに反対するケースを開きます。 核心の議論: データベースエンジンは専用のサーバー向けに設計されています。 それらをローカルにインストールするということは、使用の有無にかかわらず資源を消費し、複数のバージョン（SQL 2019、2022、2025）を同じボックスで管理すると迅速にメンテナンスの負担になります。

Docker コンテナはこのモデルを逆転します。 各データベースはそれ自体の隔離された環境で動作します。 必要なときに開始し、不要なときに停止します。 削除して、残りの設定がゼロのまま新たに開始します。 開発とテストのために、このアプローチはセットアップがより迅速で、メンテナンスがより簡潔で、従来のインストールよりも柔軟です。

Portainer の再起動ポリシーを修正する

[0:57 - 2:17] SQL Server を起動する前に、Tim はPortainer（前回のエピソードからの Docker コンテナの GUI 管理ツール）が動作していないことに気づきます。 再起動ポリシーが設定されていなかったため、最後にマシンがシャットダウンしたときに終了しました。

修正は2つのコマンドです。

// 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

この unless-stopped ポリシーは、Portainer が再起動時に自動的に再起動することを意味し、明示的に停止した場合には停止したままになります。 Portainer が起動した後、ブラウザで localhost:9000 でアクセスできます。 ティムは、このポリシーを管理ツールには常に実行したいものに推奨し、データベースコンテナは手動で開始するようにします。

SQL Server のための Docker Run コマンド

[2:17 - 6:09] 全 SQL Server セットアップは1つのコマンドにまとまっています。 ティムはそれを Windows マシンから LocalSend を使用して転送し、（前のサイドクエストビデオで紹介された）分割して解析します。

// 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

各フラグは特定の目的に役立ちます。 この -e "ACCEPT_EULA=Y" フラグは、Microsoft のライセンス契約に同意します。 この -e "SA_PASSWORD=Test12345" フラグは、システム管理者のパスワードをプレーンテキストで設定します。これはローカル開発には問題ありませんが、本番環境での使用は絶対に避けるべきです。 この -p 1433:1433 フラグは、コンテナ内部の SQL Server ポートをホストマシン上の同じポートにマッピングします。--name sql2025 フラグは、コンテナに人間が判読できるラベルを付与します。 イメージタグ 2025-latest は、Microsoft のコンテナレジストリから最新の SQL Server 2025 ビルドを取得します。

コマンドを実行すると、Docker はイメージレイヤーをダウンロードして展開し、サーバーを開始します。 プロセス全体は数分で完了し、その大部分は初回のダウンロードです。

Portainer で確認する

[6:09 - 7:04] Portainer に戻ると、新しい SQL Server コンテナがコンテナリストに表示され、そのステータスは実行中です。 ティムはここで意図的な選択をします: データ永続化のためのボリュームマウントは行いません。 コンテナが削除されると、中のデータベースも消えます。

これは開発セットアップに意図されています。新たに開始するということは、蓄積されたテストデータがなく、前回の実験からのスキーマのドリフトもなく、"私のマシンで動作する"問題が残ることもありません。 コンテナを削除する前にデータベースを保持する必要がある場合は、まずそれをエクスポートできますが、クリーンスレートのアプローチがローカル作業に推奨されるワークフローです。

VS Code から接続する

[7:04 - 8:50] データベースを管理するには、ティムは Microsoft からの VS Code 用の SQL Server 拡張機能をインストールします。 インストール後、新しい SQL Server パネルがサイドバーに表示され、接続を追加できます。

接続パラメータは最小限です。 サーバー名は .（ドット）で、localhost を意味します。コンテナがポート 1433（SQL Server のデフォルト）をマッピングしているので、ポート番号を指定する必要はありません。 ユーザー名は sa で、パスワードは Docker コマンドからのもので、デフォルトデータベースは master です。 サーバー証明書を信頼するときにはプロンプトに従います。

接続が確立されると、VS Code は接続の横に Docker アイコンを表示し、コンテナ化された環境を検出したことを確認します。 システムデータベース（master, model, msdb, tempdb）はツリーに表示され、使用可能です。

データベースの作成とクエリの実行

[8:50 - 12:45] 接続が確立された後、Tim は VS Code サイドバーから直接 PeopleDB という新しいデータベースを作成します。 その中で、彼はビジュアルデザイナーを使用して People テーブルを作成し、自動インクリメントする Id カラム、FirstName カラム、LastName カラム（両方 NVARCHAR(50) で、null ではない）を追加します。

その後、新しいクエリウィンドウを開いてテストデータを挿入します。

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')

SELECT を実行することで、行が設定されていることが確認されます。

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

全サイクル（データベースの作成、テーブルデザイン、データ挿入、フィルタを使ったクエリ）はわずか数分で完了します。 すべて Docker コンテナ内で実行され、VS Code 経由で管理され、ホストマシンに SQL Server をインストールすることはありません。

停止、開始、リソース管理

[12:45 - 14:20] SQL Server の作業が終わったら、Portainer で1回クリックするかターミナルで1つのコマンドを使用して停止できます。

docker stop sql2025

docker stop sql2025

停止されたコンテナは、すべての CPU とメモリリソースを解放します。 消費を続けるものは、イメージおよびコンテナファイルのディスクスペースのみで、これは通常ネイティブの SQL Server インストールよりも小さく、比較可能なものです。

ティムは、これが従来のインストールに対する核心の利点であると指摘します。 ローカルにインストールされた SQL Server は、Windows または Linux サービスとして実行し、常にリソースを消費します。 Docker コンテナは、使用を選択した時にのみリソースを使用します。

複数のバージョンを並行して実行する

[14:20 - 17:17] データベース開発のための Docker の最も実用的な機能の1つは、複数のバージョンを同時に実行する能力です。 ティムは、既存の2025コンテナに並行してSQL Server 2022を起動してデモンストレーションを行います。

// 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

ポートマッピングの主要な違いは、-p 2022:1433 がコンテナの内部ポート 1433 をホストのポート 2022 にマッピングすることです。これにより、すでに 1433 を使用している 2025 インスタンスとのポート競合が回避されます。ダウンロードが完了すると、Portainer に両方のコンテナが表示され、同時に実行されています。

これは、クライアントが本番環境でSQL Server 2022を実行しているが、チームが2025に対して開発している場合に役立ちます。バージョンを切り替えるには再インストールは不要で、適切なコンテナを起動するだけです。 利用可能なすべてのSQL Server イメージ（2017、2019、2022、2025）が mcr.microsoft.com に一覧化されており、同じアプローチは MySQL、PostgreSQL、MongoDB、Cosmos DB に対しても機能します。

まとめ: 1つのコマンドで完全なデータベース環境を構築する

[17:17 - 17:47] 1つの Docker コマンドで設定ウィザード、サービス管理、バージョン競合を伴う、かつては複数ステップあったインストールプロセスを置き換えることができることをウォークスルーで示しています。 コンテナは数分で起動し、必要なときにのみ実行し、ホストシステムに痕跡を残さず削除できます。

異なるデータベース要件を持つ複数のプロジェクトに取り組む開発者にとって、このパターンはクリーンにスケールします。 各プロジェクトには自分のコンテナ、自分のバージョン、そして自らの隔離されたデータがあります。

結論

[17:47 - 18:20] 要約すると、Linux 上での SQL Server は Docker で単一の docker run コマンドで実行されます。 VS Code から SQL Server 拡張を使用して接続し、サイドバーからデータベースとテーブルを作成し、他の SQL Server インスタンスに対して行うようにクエリを書くことができます。 終わったら、コンテナを停止してリソースを回収します。

Docker をデータベース管理に使用し、VS Code でクエリを実行する組み合わせにより、Linux 上でネイティブデータベースインストールが不要な完全な SQL 開発ワークフローを提供します。

例としてのヒント: 特定の SQL Server バージョンでテストする必要がある場合は、利用可能なすべてのタグをチェックするため mcr.microsoft.com を確認してください。 2017, 2019, 2022, および 2025 を同時に実行するには、それぞれのコンテナに異なるホストポート (1433, 2019, 2022, 2025) を割り当てることができます。 Portainer と docker ps の出力が読みやすくなるように、sql2022 のように説明的に名前を付けてください。

彼の YouTube チャンネルで完全なビデオを観て、Linux 上でデータベースを用いた C# 開発に関するさらなる洞察を得てください。