SqlServerOnDocker：基于 Docker Compose 搭建 SQL Server 与 Django 开发环境的完整实践

示例工程数据库教程后端【免费下载链接】sql-server-samplesAzure Data SQL Samples - Official Microsoft GitHub Repository containing code samples for SQL Server, Azure SQL, Azure Synapse, and Azure SQL Edge项目地址https://gitcode.com/gh_mirrors/sq/sql-server-samples点击查看免费下载本指南基于 sql-server-samples 仓库中的 SqlServerOnDocker 概念验证PoC项目完整讲解如何用 Docker Compose 同时编排 Microsoft SQL ServerLinux 版与 Django Web 应用两个容器并自动下载、恢复 AdventureWorksDW2017 示例数据仓库。读完本文你将掌握 SQL Server 容器化部署、备份文件恢复、ODBC 驱动配置、Django 连接 SQL Serverdjango-pyodbc-azure以及容器间网络通信的完整实战链路。项目概览一个容器化的 SQL Server Django 双服务示例SqlServerOnDocker 是一个概念验证Proof of Concept项目核心目标是在 Docker 容器中同时运行 Microsoft SQL Server 与 Django 框架并让两者协同工作。与常见的SQL Server 单独一个容器、应用连本机数据库的玩法不同这个示例把数据库恢复、应用迁移、Web 服务启动全部编排进容器生命周期用一条命令就能拉起一套完整的开发环境。从仓库目录结构看项目由三部分构成docker-compose.yml服务编排的核心定义了db与web两个服务docker/db/数据库容器构建上下文包含 Dockerfile负责安装 SQL Server 工具链并下载备份文件docker/web/Web 容器构建上下文包含 Dockerfile 与 requirements.txtSqlServerOnDocker/Django 工程配置目录其中 settings.py 是数据库连接配置的关键core/Django 应用目录其 models.py 是对 AdventureWorksDW2017 全部表结构的 Django 模型映射。环境准备开始之前需要在宿主机上安装dockerdocker-compose然后克隆本仓库sql-server-samples并进入samples/development-frameworks/SqlServerOnDocker目录。分步启动从构建镜像到数据库就绪README 给出了完整的启动流程这里结合源码逐条拆解。第一步构建数据库容器镜像docker-compose build db该命令会依据 docker/db/Dockerfile 构建数据库镜像。构建过程实际做了四件事以microsoft/mssql-server-linux:latest为基础镜像即 SQL Server 2017 时代的 Linux 官方镜像安装curl与apt-transport-https并配置微软软件源生成en_US.UTF-8localeSQL Server 容器运行所必需关键一步创建备份目录/var/opt/mssql/backup并通过 curl 直接下载AdventureWorksDW2017.bak备份文件到镜像内RUN mkdir -p /var/opt/mssql/backup WORKDIR /var/opt/mssql/backup RUN curl -L -o AdventureWorksDW2017.bak https://github.com/Microsoft/sql-server-samples/releases/download/adventureworks/AdventureWorksDW2017.bak同时该 Dockerfile 将/opt/mssql-tools/bin加入PATH使容器内可以直接使用sqlcmd命令行工具——这正是后续所有docker-compose run db sqlcmd ...命令能够工作的前提。提示由于备份文件在构建阶段就固化进镜像首次构建会受网络环境影响下载完成后后续启动不再重复下载。第二步以守护进程方式启动数据库容器docker-compose up -d db-d表示 detached后台模式。此时 SQL Server 容器在后台运行监听宿主机 1433 端口见 compose 文件中的ports: 1433:1433。第三步恢复前先验证备份文件docker-compose run db sqlcmd -S db1.internal.prod.example.com -U SA -P Alaska2017 -Q RESTORE FILELISTONLY FROM DISK N/var/opt/mssql/backup/AdventureWorksDW2017.bakRESTORE FILELISTONLY只读取备份内的文件清单而不实际恢复用于确认逻辑文件名这里即AdventureWorksDW2017与AdventureWorksDW2017_log为下一步WITH MOVE提供依据。这是恢复备份前的标准安全操作。第四步将 AdventureWorksDW2017 恢复到 SQL Serverdocker-compose run db sqlcmd -S db1.internal.prod.example.com -U SA -P Alaska2017 -Q RESTORE DATABASE AdventureWorksDW2017 FROM DISK N/var/opt/mssql/backup/AdventureWorksDW2017.bak WITH MOVE AdventureWorksDW2017 TO /var/opt/mssql/data/AdventureWorksDW2017.mdf, MOVE AdventureWorksDW2017_log TO /var/opt/mssql/data/AdventureWorksDW2017_log.ldf由于 Windows 版备份文件的默认文件路径在 Linux 容器内不存在必须用WITH MOVE将数据文件.mdf和日志文件.ldf重定向到 Linux 容器的/var/opt/mssql/data/目录这正是第三步先查询文件清单的原因。第五步对默认数据库执行 Django 迁移docker-compose run web python3 manage.py migratemigrate会把 Django 内置应用auth、admin、contenttypes、sessions 等所需的数据表应用到默认数据库——在本项目中即AdventureWorksDW2017。注意core应用在 models.py 中所有模型均声明了managed False因此 Django 不会改动 AdventureWorksDW 原有的任何业务表只做只读映射。第六步创建管理员账号docker-compose run web python3 manage.py createsuperuser按提示输入用户名、邮箱与密码即可访问 Django Admin 后台/admin/路由定义见 urls.py。运行项目docker-compose up web该命令会以前台方式同时启动db与web因为web通过depends_on依赖db。浏览器访问http://localhost:8080按CTRLC停止。由于web服务将宿主目录挂载进容器volumes: - .:/code/本地修改代码即可热生效符合开发场景定位。源码级解析Django 如何连上容器内的 SQL Server要让 Django 在 Linux 容器中连接 SQL Server链路中每一环都必须正确这也是本示例最有参考价值的部分。依赖层ODBC 驱动与数据库后端requirements.txt 只有两行却是整条链路的核心django ~ 1.11.15 django-pyodbc-azure1.11.0.0django-pyodbc-azure是 Django 的 SQL Server 数据库后端它基于 pyodbc 工作因此 Web 容器的 Dockerfile 必须在 Python 环境之外额外安装微软官方 ODBC 驱动RUN ACCEPT_EULAY apt-get install -y \ msodbcsql \ unixodbc-devmsodbcsql即 ODBC Driver 13 for SQL Serverunixodbc-dev提供 pyodbc 编译所需的头文件。该镜像同时安装了python3.5、python3-pip、python3-setuptools并通过pip3 install -r requirements.txt完成 Django 栈的安装。连接层settings.py 中的数据库配置settings.py 的DATABASES配置完整体现了容器化连接方式DATABASES { default: { ENGINE: sql_server.pyodbc, NAME: AdventureWorksDW2017, USER: sa, PASSWORD: Alaska2017, HOST: db1.internal.prod.example.com, PORT: 1433, OPTIONS: { driver: ODBC Driver 13 for SQL Server } } }各参数含义与源码对应关系如下参数值说明ENGINEsql_server.pyodbcdjango-pyodbc-azure 提供的数据库后端引擎NAMEAdventureWorksDW2017目标数据库即前面恢复的数据仓库USER/PASSWORDsa/Alaska2017与 compose 文件中SA_PASSWORD: Alaska2017保持一致HOSTdb1.internal.prod.example.com关键这不是真实域名而是 compose 网络别名见下文PORT1433SQL Server 默认端口OPTIONS.driverODBC Driver 13 for SQL Server与 Web 镜像中安装的 msodbcsql 版本严格对应网络层容器间如何用假域名互相访问为什么 Django 容器能用db1.internal.prod.example.com这种域名连到数据库容器答案在 docker-compose.yml 中两个服务被放在同一个自定义 bridge 网络mynetwork下并通过aliases为各自容器注册了内部 DNS 别名networks: mynetwork: driver: bridgedb服务的别名是db1.internal.prod.example.comweb服务的别名是web1.internal.prod.example.com。Docker 内置 DNS 会在该网络内解析这些别名因此看起来像生产域名的主机名实际只存在于容器网络中——这也是一个很实用的模式应用代码里写死业务域名通过 compose 网络别名映射到真实容器让开发、预发、生产环境的连接串保持一致。健康检查与启动顺序compose 文件中db服务还配置了 healthcheck用 sqlcmd 探测数据仓库是否已就绪healthcheck: test: sqlcmd -S db1.internal.prod.example.com -U SA -P Alaska2017 -Q select distinct 1 from AdventureWorksDW2017.dbo.DimDate只有当AdventureWorksDW2017.dbo.DimDate可查询时容器才被视为 healthy。web服务则通过depends_on: - db声明依赖避免 Django 在数据库未就绪时启动。web的启动命令由 compose 显式给出command: python3 manage.py runserver 0.0.0.0:8080并设置了DJANGO_SETTINGS_MODULE: SqlServerOnDocker.settings与 manage.py 中的默认值一致user: root与restart: unless-stopped则是开发容器常见的便利配置。进入容器与日常运维通过 sqlcmd 直查数据库sudo docker-compose run db sqlcmd -S db1.internal.prod.example.com -U SA -P Alaska2017 -Q select 1 from AdventureWorksDW2017进入数据库容器 Bashsudo docker exec -it sqlserverondocker_db_1 bash进入容器后备份文件位于/var/opt/mssql/backup/AdventureWorksDW2017.bak数据文件位于/var/opt/mssql/data/可直接查看或执行其他维护操作。模型映射让 Django ORM 直接操作数据仓库core应用下的 models.py 是典型的数据库先行database-first产物为 AdventureWorksDW2017 数据仓库中的核心表生成了 Django 模型例如维度表DimAccount、DimCustomer、DimDate、DimEmployee、DimGeography、DimProduct、DimProductCategory、DimProductSubcategory、DimPromotion、DimReseller、DimSalesReason、DimSalesTerritory、DimScenario、DimDepartmentGroup、DimOrganization、DimCurrency事实表FactInternetSales、FactResellerSales、FactCallCenter、FactFinance、FactCurrencyRate、FactProductInventory、FactSalesQuota、FactSurveyResponse、FactInternetSalesReason、FactAdditionalInternationalProductDescription系统表AuthUser、AuthGroup、DjangoMigrations、DjangoSession等。所有模型均声明managed False表示仅映射、不管理——Django 迁移不会创建、修改或删除这些表彻底保护数据仓库结构。同时字段统一使用db_column显式映射到 SQL Server 的 PascalCase 列名如db_columnSalesOrderNumber是数据库先行模式下保证 ORM 正确性的标准写法。实践要点与限制本示例定位是概念验证PoC从源码中可确认以下适用前提与注意事项版本是固定的SQL Server 镜像为mssql-server-linux:latest对应 SQL Server 2017 Linux 时代、基础系统为 Ubuntu 16.04、Django 1.11.15、ODBC Driver 13。若在更新的系统或新版 SQL Server 上复现需同步升级镜像源配置如新版系统需改用mssql-tools18与ODBC Driver 18。密码是硬编码的SA_PASSWORD: Alaska2017同时出现在 docker-compose.yml 与 settings.py 中且 Web 容器也以user: root运行仅适合本地开发生产环境必须通过环境变量或密钥管理注入凭据。ALLOWED_HOSTS [*]同样仅适合开发部署时应收紧为具体域名。恢复依赖网络备份文件在镜像构建阶段从官方 Release 下载构建环境需能访问该下载地址。重启后数据库仍在备份恢复与迁移完成后数据落在容器的数据卷内docker-compose down后再up不会清空但执行down -v删除卷会重置。总而言之SqlServerOnDocker 用最精简的编排展示了SQL Server Django 全容器化的一条完整可运行链路镜像构建阶段固化备份、sqlcmd 完成恢复、网络别名打通容器互访、ODBC django-pyodbc-azure 实现 ORM 直连、managed False保护既有数据仓库。这套组合拳既是理解 SQL Server on Linux 容器化的入门范例也是后续搭建 Django SQL Server 容器化开发环境时可复用的模板。赞分享示例工程数据库教程后端【免费下载链接】sql-server-samplesAzure Data SQL Samples - Official Microsoft GitHub Repository containing code samples for SQL Server, Azure SQL, Azure Synapse, and Azure SQL Edge项目地址https://gitcode.com/gh_mirrors/sq/sql-server-samples点击查看免费下载相关推荐基于 docker-compose 搭建 SQL Server 快照复制环境Publisher/Subscriber 容器化实操指南基于 docker compose 搭建 SQL Server 快照复制环境Publisher/Subscriber 容器化实操指南 导读 本文以 sampl示例工程数据库教程后端OneUptime 本地开发环境搭建指南基于 docker-compose.dev.yml 的完整实践OneUptime 本地开发环境搭建指南基于 docker compose.dev.yml 的完整实践 本指南围绕 OneUptime 官方文档中的《Déve可观测性后端运维前端云原生微服务AI AgentOneUptime 本地开发实战基于 docker-compose.dev.yml 与 npm run dev 的完整开发环境搭建OneUptime 本地开发实战基于 docker compose.dev.yml 与 npm run dev 的完整开发环境搭建 本文围绕 OneUptim可观测性后端运维前端云原生微服务AI Agent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考