SQL Server Docker Containers の公式情報でまず確認すべきポイントは、データ永続化、環境変数、バックアップ、リソース制限、Kubernetes展開時のcgroup v2対応です。Azure SQLのAI/Copilot機能が変わる話ではなく、SQL Server on LinuxコンテナーをDockerやKubernetesで安全に構成・カスタマイズするための運用情報として読むのが正確です。
特に管理者は「コンテナー削除時にデータを失わない構成になっているか」、開発者は「検証用コンテナーと本番相当の展開設定を混同していないか」を確認してください。Microsoft Learnの該当ページはSQL Server on Linux向けで、Dockerを使った構成変更、データ永続化、ファイルコピー、既定設定の変更を扱っています。(Microsoft Learn)
Azure SQLのAI/Copilot更新ではなく、SQL Server Docker Containers設定の実務更新として読む
今回のテーマは「Configure and Customize SQL Server Docker Containers」です。名称にAzure SQLが含まれる文脈で紹介されることがありますが、直接の対象はAzure SQL DatabaseやAzure SQL Managed Instanceそのものではありません。
Azure SQLは、Azure SQL Database、Azure SQL Managed Instance、SQL Server on Azure VMなどを含むSQL関連サービス群です。Microsoft Learnでも、Azure SQLは単一のサービスやリソースではなく、SQL関連サービスのファミリとして説明されています。(Microsoft Learn)
そのため、影響範囲は次のように分けて考えると分かりやすくなります。
| 利用形態 | 今回の情報の関係性 | 確認すべきこと |
|---|---|---|
| ローカルPCでSQL Serverコンテナーを使う開発環境 | 高い | ボリューム、ポート、パスワード、タイムゾーン |
| CI/CDで一時的なSQL Serverコンテナーを起動する | 高い | 初期化スクリプト、データ不要時の削除、イメージタグ |
| Azure VM上でSQL Serverコンテナーを運用する | 高い | 永続ボリューム、バックアップ、監視、OS更新 |
| AKSやKubernetesでSQL Serverコンテナーを動かす | 高い | cgroup v2、CPU/メモリ制限、永続ボリューム |
| Azure SQL Databaseを利用する | 低い | Docker設定ではなくPaaS側の接続、認証、性能設定 |
| Azure SQL Managed Instanceを利用する | 一部関連 | SQL Server互換性や移行設計の参考として確認 |
Azure SQL Databaseは、アップグレード、修正プログラム、バックアップ、監視など多くの管理機能をプラットフォーム側が担うPaaSです。SQL Serverコンテナーのように、利用者がdocker run、ボリューム、OS上の共有メモリ、コンテナー内設定を直接管理する前提とは異なります。(Microsoft Learn)
2026年5月前後の変更点として確認したいポイント
Microsoft Learn上の該当ページでは、表示上の最終更新日は2026年4月21日です。一方、GitHubの履歴では2026年5月8日に「コマンドラインツールの書式修正」を目的としたコミットがあり、該当ファイルを含む複数のSQL Server Linux関連ドキュメントが更新されています。日本時間で2026年5月9日前後の更新として追う場合も、実務上は「書式修正」と「既存の重要設定の再確認」を分けて読むのが安全です。(Microsoft Learn)
特に実務影響が大きいのは、単なる表記変更ではなく、次の設定領域です。
| 項目 | 変更・確認ポイント | 主な対象者 |
|---|---|---|
| データ永続化 | docker rmでコンテナーを削除すると内部データも消えるため、ボリューム設計が必須 | DBA、インフラ担当、開発者 |
| SAパスワード | SA_PASSWORDではなくMSSQL_SA_PASSWORDを使う | 開発者、CI/CD担当 |
| バックアップ | バックアップファイルをコンテナー内だけに置かない | DBA、運用担当 |
| VDIバックアップ | --shm-sizeとmssql.conf設定が必要 | DBA、バックアップ製品担当 |
| cgroup v2 | SQL Server 2025とSQL Server 2022 CU20以降で制約認識が改善 | Kubernetes/AKS担当 |
| CPU制限 | cgroup v2環境ではエラーログ表示と実際のCPU制御の見え方に注意 | パフォーマンス担当 |
| タイムゾーン | TZ環境変数で明示する | 開発者、運用担当 |
tempdb配置 | ユーザーデータベースと分ける設計が推奨 | DBA |
データ永続化は最優先で確認する
SQL Server Docker Containersで最も失敗しやすいのは、データベースファイルをコンテナー内部だけに置いてしまうことです。
公式情報では、docker stopとdocker startによる再起動ではコンテナー内のSQL Server構成やデータベースファイルは保持されますが、docker rmでコンテナーを削除するとSQL Serverやデータベースを含む内部データが削除されると説明されています。(Microsoft Learn)
本番相当の環境、長期検証、チーム共有の開発DBでは、ホストディレクトリまたはDockerボリュームを使って/var/opt/mssql配下を永続化します。
docker run -e 'ACCEPT_EULA=Y' \
-e 'MSSQL_SA_PASSWORD=<strong-password>' \
-p 1433:1433 \
-v /srv/mssql/data:/var/opt/mssql/data \
-v /srv/mssql/log:/var/opt/mssql/log \
-v /srv/mssql/secrets:/var/opt/mssql/secrets \
-d mcr.microsoft.com/mssql/server:2022-latest実務では、data、log、secretsを分けてマウントしておくと、バックアップ、容量監視、アクセス権限の整理がしやすくなります。公式例でも、データ、ログ、シークレット用のディレクトリを分けてマウントする例が示されています。(Microsoft Learn)
一時的な検証だけならコンテナー内部にデータを置いても構いません。ただし、次のようなケースでは必ず永続化してください。
| ケース | 永続化が必要な理由 |
|---|---|
| 複数日にわたる開発DB | コンテナー再作成で作業データが消える |
| テストデータをチームで共有する | 再現性が失われる |
| 本番に近い性能検証を行う | データ配置とI/O条件が変わる |
| バックアップ・リストア手順を検証する | 実運用との差が大きくなる |
| Kubernetesで運用する | Pod再作成時にデータを保持する必要がある |
MSSQL_SA_PASSWORDを使い、パスワードをコードに直書きしない
古いサンプルや社内手順にSA_PASSWORDが残っている場合は見直しが必要です。公式情報では、SA_PASSWORD環境変数は非推奨であり、代わりにMSSQL_SA_PASSWORDを使うよう明記されています。(Microsoft Learn)
また、パスワードはSQL Serverの既定ポリシーに従う必要があります。公式ページでは、既定で8文字以上、かつ大文字・小文字・数字・記号の4種類のうち3種類を含む必要があると説明されています。(Microsoft Learn)
避けたい設定例は次のとおりです。
-e 'MSSQL_SA_PASSWORD=Password123'このようなパスワードは推測されやすく、サンプルとしても危険です。CI/CDやKubernetesでは、環境変数を直接YAMLやスクリプトに書くのではなく、シークレット管理の仕組みを使って渡します。
Kubernetesで使う場合は、少なくとも次の方針にします。
| 項目 | 推奨方針 |
|---|---|
| SAパスワード | Kubernetes Secretや外部シークレット管理から注入 |
| 接続文字列 | アプリ側のSecretに分離 |
| 開発用パスワード | リポジトリにコミットしない |
| ローテーション | 手順を事前に用意する |
| 権限 | sa常用を避け、用途別ログインを作成 |
カスタムDockerfileではSQL Serverプロセスの起動順に注意する
SQL Server Docker Containersをカスタマイズする場合、Dockerfileで初期化スクリプトを実行したくなることがあります。ここで重要なのは、コンテナーのフォアグラウンドプロセスです。
公式情報では、フォアグラウンドプロセスがコンテナーのライフサイクルを制御し、そのプロセスが終了するとコンテナーも停止すると説明されています。SQL Serverを起動しつつスクリプトを実行する場合は、SQL Serverプロセスが右端に来るようにする例が示されています。(Microsoft Learn)
/usr/src/app/do-my-sql-commands.sh & /opt/mssql/bin/sqlservr反対に、初期化スクリプトだけがフォアグラウンドで動き、完了後に終了してしまう構成にすると、コンテナーも停止します。
開発現場でよくある失敗は、次のようなものです。
| 失敗例 | 起きる問題 | 対策 |
|---|---|---|
| 初期化スクリプトを最後に書く | スクリプト終了後にコンテナーが止まる | SQL Server本体をフォアグラウンドにする |
| DB起動前にSQLを流す | 接続エラーになる | 起動待ち処理を入れる |
| Dockerfileに大量の業務データを焼き込む | イメージが肥大化する | データ投入はボリュームや初期化処理で分離 |
| 本番用設定を開発用イメージに混ぜる | 差し替えが難しくなる | 環境変数や設定ファイルで切り替える |
バックアップはコンテナーの外に出す
バックアップファイルをコンテナー内だけに保存する構成は危険です。公式情報でも、バックアップを作成する場合はバックアップファイルをコンテナー外に作成またはコピーするよう注意しています。コンテナーが削除されると、内部にあるバックアップファイルも削除されるためです。(Microsoft Learn)
実務では、バックアップ先を次のように分けて考えます。
| 用途 | 保存先の例 | 注意点 |
|---|---|---|
| ローカル開発の退避 | ホスト側ディレクトリ | コンテナー削除後も残る場所に保存 |
| CIの一時検証 | ジョブの成果物ストレージ | 保存期間を明確にする |
| 本番相当の検証 | 外部ストレージ、共有ディスク | 復元テストまで行う |
| Azure上の運用 | Azure Storageなど | 認証情報と暗号化を確認 |
移行時は「コンテナーを移せば終わり」と考えないほうが安全です。ユーザーデータベースだけでなく、ログイン、SQL Server Agentジョブ、リンクサーバー、照合順序、tempdb設定、接続文字列、監視設定も確認します。
VDIバックアップを使う場合は共有メモリ設定を確認する
バックアップ製品や高度なバックアップ方式でVDIを使う場合は、通常のdocker runだけでは不十分な場合があります。
公式情報では、SQL Server 2019 CU15以降およびSQL Server 2017 CU28以降のコンテナー展開でVDIバックアップとリストアがサポートされると説明されています。さらに、VDIバックアップを使う場合は--shm-sizeを指定し、まず1GBを目安に設定する例が示されています。既定の共有メモリサイズ64MBではVDIバックアップには不十分とされています。(Microsoft Learn)
docker run -e "ACCEPT_EULA=Y" \
-e "MSSQL_SA_PASSWORD=<strong-password>" \
--shm-size 1g \
-p 1433:1433 \
--name sql19 \
--hostname sql19 \
-d mcr.microsoft.com/mssql/server:2019-latest加えて、mssql.confでmemory.enablecontainersharedmemoryを有効化する必要があります。公式例では次の設定が示されています。(Microsoft Learn)
[memory]
enablecontainersharedmemory = trueこの設定は、バックアップ方式に関係するため、DBAだけでなくバックアップ製品の担当者、Kubernetes運用担当、監視担当も確認しておくべきです。
タイムゾーンはTZ環境変数で明示する
SQL Serverコンテナーを開発環境や海外リージョンのサーバーで動かすと、ログやジョブの時刻が想定とずれることがあります。公式情報では、Linuxコンテナーで特定のタイムゾーンを使う場合、TZ環境変数を設定する方法が示されています。(Microsoft Learn)
日本時間で運用する検証環境なら、次のように指定します。
docker run -e 'ACCEPT_EULA=Y' \
-e 'MSSQL_SA_PASSWORD=<strong-password>' \
-e 'TZ=Asia/Tokyo' \
-p 1433:1433 \
--name sql1 \
-d mcr.microsoft.com/mssql/server:2022-latestただし、アプリケーション側でUTC管理を前提にしている場合は、DBコンテナーだけを日本時間に変えると、ログ解析や監査で混乱することがあります。タイムゾーンは「DB」「アプリ」「ログ基盤」「監視」の単位で統一方針を決めてください。
tempdbと既定データディレクトリは性能と運用で分けて考える
公式情報では、tempdbをユーザーデータベースから分離するのがよいプラクティスとして説明され、ALTER DATABASE tempdb MODIFY FILEでtempdbの配置先を変更する手順が示されています。変更を反映するにはSQL Serverコンテナーの再起動が必要です。(Microsoft Learn)
ALTER DATABASE tempdb
MODIFY FILE (NAME = tempdev, FILENAME = '/var/opt/mssql/tempdb/tempdb.mdf');
GO
ALTER DATABASE tempdb
MODIFY FILE (NAME = templog, FILENAME = '/var/opt/mssql/tempdb/templog.ldf');
GO開発環境では見落とされがちですが、tempdbはソート、ハッシュ処理、一時テーブル、バージョンストアなどで頻繁に使われます。重いクエリやテストデータの投入を行う環境では、データファイルとtempdbを同じI/O条件に置くとボトルネックの切り分けが難しくなります。
既定のデータディレクトリを変更する場合は、MSSQL_DATA_DIRを使います。公式情報では、MSSQL_DATA_DIRでデータディレクトリを指定し、その場所にコンテナーユーザーがアクセスできるボリュームをマウントする方法が示されています。(Microsoft Learn)
docker run -e 'ACCEPT_EULA=Y' \
-e 'MSSQL_SA_PASSWORD=<strong-password>' \
-e 'MSSQL_DATA_DIR=/my/file/path' \
-v /my/host/path:/my/file/path \
-p 1433:1433 \
-d mcr.microsoft.com/mssql/server:2022-latestここで重要なのは、パスだけでなく権限です。SQL Server 2019以降のコンテナーは既定で非rootとして起動するため、ホスト側ディレクトリの所有者やアクセス権が合っていないと起動やファイル作成に失敗します。公式情報でも、SQL Server 2019以降のコンテナーは自動的に非rootで起動し、SQL Server 2017コンテナーは既定でrootとして起動すると説明されています。(Microsoft Learn)
mssql-confでコンテナー内のSQL Server設定を変更する
SQL Serverコンテナー内の設定変更には、mssql-confを使えます。公式情報では、docker execでコンテナーに入り、mssql-confでmemory.memorylimitmbを2048MBに設定する例が示されています。(Microsoft Learn)
docker exec -u root -it sqlcontainer "bash"
/opt/mssql/bin/mssql-conf set memory.memorylimitmb 2048ただし、コンテナー運用では「コンテナー内で手作業変更する」方法を本番手順にしないほうが安全です。再作成したときに設定が失われたり、どの環境にどの設定を入れたか分からなくなったりするためです。
本番相当の環境では、次の順で管理すると再現性が上がります。
| 優先度 | 管理方法 | 向いている設定 |
|---|---|---|
| 高 | 環境変数 | パスワード、EULA、タイムゾーン、既定ディレクトリ |
| 高 | マウントした設定ファイル | mssql.conf、証明書、シークレット |
| 中 | Dockerfile | 追加パッケージ、初期化スクリプト |
| 低 | 手作業のdocker exec | 緊急調査、一時検証 |
KubernetesやAKSではcgroup v2の確認が重要
KubernetesやAKSでSQL Serverコンテナーを動かす場合、CPUとメモリの制限がSQL Server側でどう認識されるかが重要です。
公式情報では、SQL Server 2025およびSQL Server 2022 CU20以降で、SQL Serverがcgroup v2の制約を検出して尊重すると説明されています。これにより、Docker、Kubernetes、OpenShift環境でCPUやメモリのリソース分離が改善されます。以前のバージョンでは、たとえばAKS v1.25以降のKubernetesクラスターで、コンテナー仕様に定義したメモリ制限がSQL Serverで強制されず、OOMエラーが発生する可能性があったと説明されています。(Microsoft Learn)
cgroupのバージョン確認には次のコマンドを使います。
stat -fc %T /sys/fs/cgroup結果の見方は次のとおりです。
| 結果 | 意味 |
|---|---|
cgroup2fs | cgroup v2を使用 |
cgroup | cgroup v1を使用 |
cgroup v2でCPU制限を設定している場合、SQL Serverのエラーログには構成したCPUコア数ではなく、ホスト全体のCPU数が表示されることがあります。公式情報では、SQL Serverのスケジューラーやクエリプランを意図したCPU数に合わせるため、プロセッサアフィニティの設定とトレースフラグ8002の有効化が案内されています。(Microsoft Learn)
ALTER SERVER CONFIGURATION
SET PROCESS AFFINITY CPU = 0 TO 3;sudo /opt/mssql/bin/mssql-conf traceflag 8002 onこの点は、単に「CPU制限をYAMLに書けば終わり」ではありません。SQL Serverの並列実行、クエリ最適化、スケジューラー数に影響するため、性能検証時には次の3つを合わせて確認してください。
| 確認項目 | 見るべきポイント |
|---|---|
Kubernetesのresources.limits.cpu | Podに意図したCPU制限が入っているか |
| SQL Serverのスケジューラー | 意図したCPU数で作成されているか |
| クエリ実行計画 | 並列度が過大になっていないか |
管理者が確認すべき設定チェックリスト
SQL Server Docker Containersを継続利用する管理者は、次の順で確認すると抜け漏れを減らせます。
| 確認項目 | 判断基準 |
|---|---|
| イメージタグ | 本番相当ではlatest依存を避け、バージョンを固定する |
| ボリューム | /var/opt/mssql配下のデータ、ログ、シークレットを永続化する |
| パスワード | MSSQL_SA_PASSWORDを使い、平文をリポジトリに置かない |
| 権限 | SQL Server 2019以降の非root起動を前提にホスト側権限を調整する |
| バックアップ | バックアップファイルをコンテナー外へ保存する |
| 復元テスト | バックアップ取得だけでなく別コンテナーへの復元を試す |
| 監視 | CPU、メモリ、I/O、ログ、接続数を取得する |
| タイムゾーン | DB、アプリ、ログ基盤で方針をそろえる |
tempdb | 高負荷環境ではユーザーデータベースと分離する |
| Kubernetes | cgroup v2、PV/PVC、リソース制限、再起動時の挙動を確認する |
特に「バックアップがある」と「復元できる」は別物です。コンテナー運用では、ホストパス、ボリューム、シークレット、設定ファイルのどれが復元対象なのかを明文化しておく必要があります。
開発者が確認すべき使い分け
開発者にとってSQL Server Docker Containersは、ローカルでSQL Server環境を素早く作れる便利な選択肢です。ただし、検証用の簡易構成をそのまま共有環境や本番相当に広げると問題が起きます。
| 目的 | 推奨構成 |
|---|---|
| 1回限りのSQL検証 | 永続化なしでも可。終了後に削除 |
| アプリ開発 | Docker ComposeでDBとアプリを分離 |
| チーム共通DB | ボリューム永続化とバックアップを設定 |
| CIテスト | テストごとに新規作成し、終了後に削除 |
| 本番相当の性能検証 | 固定タグ、永続ボリューム、監視、リソース制限を設定 |
開発環境では、次のようなDocker Composeにしておくと、最低限の再現性を確保できます。
services:
sqlserver:
image: mcr.microsoft.com/mssql/server:2022-latest
container_name: sqlserver-dev
environment:
ACCEPT_EULA: "Y"
MSSQL_SA_PASSWORD: "<strong-password>"
TZ: "Asia/Tokyo"
ports:
- "1433:1433"
volumes:
- sqlserver-data:/var/opt/mssql
volumes:
sqlserver-data:本番相当の検証では、Composeファイルにパスワードを直接書かず、環境変数ファイルやシークレット管理に分離します。
Azure SQL Databaseへ移行する場合の注意点
SQL ServerコンテナーからAzure SQL Databaseへ移行する場合は、同じSQL Serverエンジン系の技術であっても、運用モデルが変わります。Azure SQL Databaseでは、バックアップ、パッチ適用、基盤管理の多くをMicrosoftが管理します。一方、SQL Serverコンテナーでは、ホスト、ボリューム、バックアップ、更新、監視、セキュリティの多くを利用者側で管理します。(Microsoft Learn)
移行前に、次の違いを確認してください。
| 観点 | SQL Server Docker Containers | Azure SQL Database |
|---|---|---|
| インフラ管理 | 利用者が管理 | Microsoftが多くを管理 |
| OS・コンテナー | 利用者が管理 | 利用者は管理しない |
| バックアップ | 利用者が設計 | 自動バックアップ中心 |
| 接続 | ホスト、ポート、ネットワークを自分で設定 | Azure側の接続設定、ファイアウォール、認証を設定 |
| スケール | コンテナーやホストの設計次第 | サービス階層やコンピュートで調整 |
| 機能差 | SQL Server本体に近い | PaaS固有の制約や機能差がある |
「Dockerで動いていたから、そのままAzure SQL Databaseに移せる」とは考えないほうが安全です。SQL Server Agentジョブ、クロスデータベース参照、サーバーレベル設定、バックアップ方式、認証方式などは、移行前に棚卸ししてください。
次に取るべき行動
SQL Server Docker Containersを使っている場合、まず現在の起動コマンド、Compose、Kubernetesマニフェストを確認してください。見るべき順番は、データ永続化、MSSQL_SA_PASSWORD、バックアップ保存先、イメージタグ、タイムゾーン、tempdb、cgroup v2です。
開発用途なら、再作成しても困らないデータと保持すべきデータを分けます。運用用途なら、バックアップと復元、ボリューム権限、非root起動、CPU/メモリ制限まで含めて確認します。Azure SQL DatabaseやAzure SQL Managed Instanceへ移行する予定がある場合は、コンテナーの設定値ではなく、接続方式、認証、バックアップ、ジョブ、機能差を中心に棚卸しするのが次の一手です。
コメント