Azure SQLやSQL Server系アプリの開発・検証でDockerを使っている場合、まず確認すべきポイントは「起動コマンド」だけではありません。実行できるホスト環境、使用するコンテナーイメージのタグ、SA_PASSWORDからMSSQL_SA_PASSWORDへの移行、mssql-tools18へのパス変更、データ永続化、ライセンス指定まで見直す必要があります。
今回の公式情報は、Azure SQL Databaseそのもののサービス変更ではなく、SQL Server on LinuxのDockerコンテナーを使うためのクイックスタートと周辺運用に関する内容です。Azure SQL Database向けの開発・移行検証でSQL Serverコンテナーを使う場合は、ローカル検証環境として便利な一方、Azure SQL DatabaseとSQL ServerにはT-SQLやインスタンスレベル機能の差異があるため、本番反映前にAzure側での検証も必要です。(Microsoft Learn)
Azure SQL利用者にとっての位置づけ
「Docker: Run Containers for SQL Server on Linux」は、DockerでSQL Server Linuxコンテナーイメージを取得し、起動し、sqlcmdで接続するためのクイックスタートです。対象はMicrosoft Learn上で「SQL Server on Linux」とされており、Azure SQL Databaseの設定変更やAzureポータルの新機能ではありません。(Microsoft Learn)
ただし、Azure SQLを使う開発者にとって無関係ではありません。たとえば、次のような場面でSQL Server Dockerコンテナーは役立ちます。
| 活用シーン | 使いどころ | 注意点 |
|---|---|---|
| ローカル開発 | アプリからSQL接続、テーブル作成、基本的なT-SQL実行を素早く試す | Azure SQL Databaseの完全な再現環境ではない |
| CI/CDのテスト | GitHub Actionsなどで一時的なDBを起動し、マイグレーションや統合テストを実行する | latestタグ任せにせず、検証済みタグを固定する |
| 移行前の整理 | SQL Server系スキーマやアプリの動作確認を行う | Azure SQL Databaseで非対応のT-SQL構文は別途確認する |
| チーム共通環境 | Dockerコマンドで同じDB環境を再現する | ボリューム、パスワード、ポート番号を標準化する |
Azure SQL Databaseでは多くのT-SQL機能がSQL Serverと同様に動作しますが、インスタンスレベルの機能、OSやファイルシステムに依存する構成、高可用性関連の一部構文などは異なります。Docker上で動いたからといって、Azure SQL Databaseでそのまま動くとは限りません。(Microsoft Learn)
何が変わるのか：押さえるべき主な変更点
今回の確認ポイントは、新しい派手な機能追加というより、既存のDocker運用で見落としやすい前提条件と非推奨設定の整理です。特に、古いサンプルコマンドを社内WikiやCI設定に貼ったまま使っている場合は注意が必要です。
| 確認項目 | 現在のポイント | 影響を受けやすい人 |
|---|---|---|
| 対象バージョン | SQL Server 2017、2019、2022、2025のLinuxコンテナー手順が整理されている | 複数バージョンを検証する開発チーム |
| 実行ホスト | SQL Serverコンテナーイメージは、Intel/AMD x86-64 CPU上のLinuxホストでの利用が前提 | Apple Silicon、Arm環境、エミュレーション環境の利用者 |
| パスワード環境変数 | SA_PASSWORDは非推奨。MSSQL_SA_PASSWORDを使う | 古いDockerコマンドやCI定義を使っている人 |
mssql-tools18 | SQL Server 2022 CU14、SQL Server 2019 CU28以降のコンテナーイメージでは新しいmssql-tools18パッケージが含まれる | sqlcmdのパスを固定しているスクリプト |
| データ永続化 | コンテナーを停止・削除すると、コンテナー内のデータが失われる可能性がある | テストDBを残したい開発者、検証環境管理者 |
| ライセンス指定 | クイックスタートの既定はDeveloper Edition。運用エディションではMSSQL_PIDと有効なライセンス確認が必要 | 本番・準本番でコンテナーを使う管理者 |
sqlcmdの暗号化 | 新しいsqlcmdはセキュアな接続を既定にするため、検証環境で接続オプションの調整が必要になる場合がある | 接続エラーを切り分ける開発者 |
Microsoft Learnでは、SQL ServerコンテナーイメージがLinux上のDocker Engine 1.8以降で使用できること、SA_PASSWORDではなくMSSQL_SA_PASSWORDを使うこと、mssql-tools18の新しいパスが/opt/mssql-tools18/binであることが示されています。(Microsoft Learn)
管理者・開発者が最初に確認すべき設定
DockerでSQL Serverを起動できるかどうかよりも、継続的に安全に使える設定になっているかを確認してください。特にAzure SQLへの移行検証やチーム開発で使う場合、個人PCで一度動いた設定をそのまま共有すると、後から接続エラーやデータ消失が起きやすくなります。
| 確認項目 | 推奨される判断基準 | 確認方法の例 |
|---|---|---|
| イメージタグ | 本番・CIではlatest任せにせず、検証済みタグを使う | docker pull mcr.microsoft.com/mssql/server:<image_tag> |
| CPU/ホスト | サポート対象のLinuxホスト、Intel/AMD x86-64 CPUで動かす | ホストOS、CPUアーキテクチャを確認 |
| パスワード | 8文字以上かつ大文字・小文字・数字・記号のうち3種類以上を含める | コンテナー起動後にdocker logsを確認 |
| ポート | ローカルSQL Serverや別コンテナーと1433番が競合しないようにする | -p 1400:1433のようにホスト側ポートを変更 |
| 永続化 | /var/opt/mssqlまたはdata/log/secretsをボリュームに保存する | docker volume ls、ホスト側ディレクトリを確認 |
sqlcmdパス | 古い/opt/mssql-tools/bin固定を避ける | /opt/mssql-tools18/bin/sqlcmdを使う |
| ライセンス | Developer Editionを本番用途に使わない | MSSQL_PIDとライセンス条件を確認 |
SQL Serverコンテナーの前提条件には、Docker Engine、overlay2ストレージドライバー、最新のsqlcmd、少なくとも2GBのディスク領域と2GBのRAMが含まれます。メモリ不足やパスワードポリシー違反は、コンテナーがすぐ終了する典型的な原因です。(Microsoft Learn)
最小構成でSQL Server Linuxコンテナーを起動する
開発検証でまず動作を確認するなら、以下のような最小構成から始めます。SQL Server 2025を試す場合の例です。既存システムがSQL Server 2022相当で動いているなら、検証対象に合わせて2022-latestや特定CUのタグに変更してください。
docker pull mcr.microsoft.com/mssql/server:2025-latest
docker run -e "ACCEPT_EULA=Y" \
-e "MSSQL_SA_PASSWORD=<強力なパスワード>" \
-p 1433:1433 \
--name sql1 \
--hostname sql1 \
-d mcr.microsoft.com/mssql/server:2025-latest起動後は、コンテナーの状態とログを確認します。
docker ps -a
docker logs sql1STATUSがUpで、SQL Serverのエラーログに接続可能になったことを示すメッセージが出ていれば、接続準備はできています。公式手順でも、docker ps -aのSTATUS列とSQL Serverエラーログを確認する流れが示されています。(Microsoft Learn)
コンテナー内からsqlcmdで接続する場合は、mssql-tools18のパスを意識します。
docker exec -it sql1 /opt/mssql-tools18/bin/sqlcmd \
-S localhost \
-U sa \
-P "<強力なパスワード>" \
-Q "SELECT @@VERSION"古い手順では/opt/mssql-tools/bin/sqlcmdが使われていることがあります。今後のスクリプト更新では、/opt/mssql-tools18/binを前提に見直すのが安全です。(Microsoft Learn)
データを失わないための永続化設計
SQL Server Dockerコンテナーで最も多い失敗は、「テストデータを入れたあとにコンテナーを削除してしまい、DBが消えた」というものです。docker stopとdocker startで再起動するだけならコンテナー内のデータは残りますが、docker rmでコンテナーを削除すると、コンテナー内のSQL Serverやデータベースも削除されます。(Microsoft Learn)
開発環境でも、チームで使うなら最初からボリュームを使いましょう。
docker volume create sqlvolume
docker run -e "ACCEPT_EULA=Y" \
-e "MSSQL_SA_PASSWORD=<強力なパスワード>" \
-p 1433:1433 \
--name sql1 \
--hostname sql1 \
-v sqlvolume:/var/opt/mssql \
-d mcr.microsoft.com/mssql/server:2025-latestより運用に近い形で分けるなら、data、log、secretsを個別にマウントします。
docker run -e "ACCEPT_EULA=Y" \
-e "MSSQL_SA_PASSWORD=<強力なパスワード>" \
-p 1433:1433 \
--name sql1 \
--hostname sql1 \
-v /path/to/mssql/data:/var/opt/mssql/data \
-v /path/to/mssql/log:/var/opt/mssql/log \
-v /path/to/mssql/secrets:/var/opt/mssql/secrets \
-d mcr.microsoft.com/mssql/server:2025-latest/var/opt/mssql/secretsには証明書やキーなど重要なファイルが置かれる場合があります。ホスト側にマウントする場合は、mssqlユーザーやrootユーザー以外が不用意にアクセスできないよう、権限設計を確認してください。(Microsoft Learn)
Azure SQLへの移行・展開で注意すべき点
SQL ServerコンテナーはAzure SQL Databaseの完全な代替ではない
SQL Serverコンテナーは、T-SQLや接続処理、アプリケーションのDB依存部分を素早く検証するには有効です。一方で、Azure SQL DatabaseはPaaSとして高可用性やファイル管理などをサービス側で担うため、SQL Serverとは一部構文や機能が異なります。(Microsoft Learn)
特に、次のような要素を使っている場合はAzure SQL Databaseでの互換性確認が必要です。
| 確認対象 | Docker上のSQL Serverで動いても注意すべき理由 |
|---|---|
CREATE DATABASEやALTER DATABASEの詳細オプション | SQL Server固有のファイル配置やサービス設定がAzure SQL Databaseでは異なる |
| SQL Server Agent依存の処理 | Azure SQL Databaseでは同じ前提で使えない |
| FILESTREAM、FileTable | Azure SQL Databaseではサポートされない機能に該当する |
| Always On関連構文 | Azure SQL Databaseでは高可用性がサービス側で管理される |
| サーバーレベル権限、ログイン、トリガー | データベースレベルの設計に置き換える必要がある場合がある |
ローカルのSQL Serverコンテナーで通ったマイグレーションSQLを、そのままAzure SQL Databaseに流すのではなく、Azure SQL Database向けの構文差分チェックを必ず挟んでください。
本番利用ではDeveloper Editionのままにしない
クイックスタートの既定ではDeveloper Editionのコンテナーが作成されます。開発・検証用途なら便利ですが、本番用途でEnterprise、Standardなどのエディションを使う場合は、有効なライセンスを確認し、MSSQL_PIDでエディションを指定する必要があります。(Microsoft Learn)
例として、Enterprise Coreを指定する場合は次のようになります。
docker run --name sqlenterprise \
-e "ACCEPT_EULA=Y" \
-e "MSSQL_SA_PASSWORD=<強力なパスワード>" \
-e "MSSQL_PID=EnterpriseCore" \
-p 1433:1433 \
-d mcr.microsoft.com/mssql/server:2022-latest注意したいのは、sqlcmd create mssqlによる作成手順では、現時点でMSSQL_PIDパラメーターがサポートされない点です。任意のライセンスでコンテナーを作成したい場合は、CLIのdocker run手順で明示的に指定します。(Microsoft Learn)
アップグレードは「実行中コンテナーを更新」ではなく「新しいコンテナーへ移す」
Dockerで新しいイメージをpullしても、実行中のSQL Serverコンテナー自体が自動的に更新されるわけではありません。新しいイメージを使って別コンテナーを作成し、永続化されたデータやバックアップを使って移行・検証する流れになります。(Microsoft Learn)
実務では、次の順序にすると失敗しにくくなります。
| 手順 | 作業内容 | 失敗しやすいポイント |
|---|---|---|
| 現行確認 | 現在のイメージタグ、SQL Serverバージョン、ボリューム名を記録する | latestだけで管理していて実体が分からない |
| バックアップ | DBバックアップをコンテナー外に保存する | バックアップファイルまでコンテナー内に置いて削除してしまう |
| 新イメージ取得 | 対象のタグを指定してdocker pullする | 本番相当で未検証のタグを使う |
| 新コンテナー作成 | 永続化ボリュームまたは復元用バックアップを使って起動する | 古いsaパスワードがボリューム側に残っている |
| 検証 | 接続、クエリ、アプリ連携、Azure SQL差分を確認する | Docker上の成功だけでAzure SQL対応済みと判断する |
| 切り替え | 名前、ポート、接続文字列を整理する | 旧コンテナーを削除してから不備に気付く |
既存ボリュームを再利用する場合、MSSQL_SA_PASSWORDを変えても、ボリューム内に保存済みのsaパスワードが使われます。接続できないときは、新しい環境変数ではなく、既存データに紐づくパスワードを確認してください。(Microsoft Learn)
よくあるトラブルと切り分け
SQL Server Dockerコンテナーは起動が簡単な反面、エラーの原因がDocker、SQL Server、接続ツール、ポート、認証のどこにあるのか分かりにくいことがあります。まずは以下の表で切り分けます。
| 症状 | 主な原因 | 確認・対応 |
|---|---|---|
コンテナーがすぐExitedになる | パスワードポリシー違反、メモリ不足、起動時エラー | docker logs sql1でエラーログを確認 |
1433が使えない | ホスト側でSQL Serverや別コンテナーが同じポートを使用中 | -p 1400:1433のようにホスト側ポートを変更 |
| Dockerコマンドが権限エラーになる | Dockerデーモンへのアクセス権がない | Linuxではsudo実行やdockerグループ設定を確認 |
sqlcmdで接続できない | コンテナー未起動、ポート指定漏れ、暗号化設定 | docker ps -a、PORTS列、接続先ポートを確認 |
| ボリューム再利用後にログインできない | 既存データ側のsaパスワードが使われている | 新しい環境変数ではなく、ボリューム作成時のパスワードを使う |
| 可用性グループ検証で通信できない | レプリカ通信用ポート未公開、ホスト名未設定 | -p 5022:5022と明示的なホスト名を確認 |
公式トラブルシューティングでは、Dockerサービスの状態、docker logs、docker ps -a、ポートマッピング、SQL Serverの/var/opt/mssql/log配下のログ確認が推奨されています。(Microsoft Learn)
セキュリティ面で見直すべきポイント
SQL Server 2019以降のコンテナーは非rootで起動しますが、SQL Server 2017コンテナーは既定でrootとして起動します。古い検証環境を使い続けている場合は、非root実行や権限設定を見直してください。(Microsoft Learn)
特に、次の3点はチーム開発でも本番相当検証でも重要です。
| 項目 | 実務上の注意 |
|---|---|
saパスワード | 環境変数に平文で残るため、運用環境では起動後の変更やシークレット管理を検討する |
| 永続化ディレクトリ | data、log、secretsの権限を分け、不要なユーザーが読めないようにする |
| 接続暗号化 | ローカル検証で接続を緩める場合も、本番では証明書と暗号化方針を別途設計する |
MSSQL_SA_PASSWORDはps -eax出力や環境変数として見える可能性があるため、実稼働環境では起動後にSAパスワードを変更することも公式手順で触れられています。(Microsoft Learn)
次に取るべき行動
Azure SQLやSQL Server系アプリでDockerを使っているなら、まず既存のDockerコマンド、CI設定、社内手順書を確認してください。見るべき箇所は明確です。
SA_PASSWORDを使っている場合は、MSSQL_SA_PASSWORDへ置き換える/opt/mssql-tools/bin/sqlcmdを固定している場合は、/opt/mssql-tools18/bin/sqlcmdへの変更を検討するlatestタグだけで運用している場合は、検証済みの具体的なタグを使うdocker rmでデータが消えないよう、ボリュームとバックアップを用意する- Azure SQL Databaseへ移行・展開する場合は、T-SQL差分とAzure側の本番検証を必ず行う
Docker上のSQL Serverは、Azure SQL開発の初期検証を速くする強力な選択肢です。ただし、使い方を誤ると、データ消失、接続エラー、ライセンス不備、Azure SQLとの差分見落としにつながります。まずは起動コマンドを最新化し、永続化とタグ固定を標準化し、そのうえでAzure SQL Database上の最終検証へ進めるのが安全です。
コメント