新闻详情

新闻详情

首页 / 资讯中心 / 详情

DjangoBlog Docker 部署全攻略:docker-compose 一键编排、独立镜像运行与环境变量深度解析

发布时间:2026/9/28 8:38:25来源:尧图网络
DjangoBlog Docker 部署全攻略:docker-compose 一键编排、独立镜像运行与环境变量深度解析
后端前端CMS【免费下载链接】DjangoBlog基于Django的博客系统项目地址https://gitcode.com/gh_mirrors/dj/DjangoBlog点击查看免费下载本文以 DjangoBlog 官方的 Docker 部署文档docs/docker-en.md为主线结合仓库内的 Dockerfile、docker-compose 配置、启动脚本 与 settings.py 源码系统讲解如何用 Docker 在几分钟内完成博客的容器化部署。读完本文你将掌握三种部署路径docker-compose 一键部署、叠加 Elasticsearch 全文检索、独立镜像对接外部 MySQL并彻底搞懂每一个DJANGO_*环境变量在源码层面如何生效从而安全、正确地完成生产环境配置。1. 部署前置条件在开始之前请确保本机已安装以下两样软件Docker Engine容器运行时负责拉取镜像、构建镜像并运行容器Docker Compose容器编排工具负责按docker-compose.yml一次性拉起多服务栈。Docker DesktopmacOS / Windows用户无需单独安装已内置 Compose。兼容性提示本文所有命令均基于文档撰写时的 Compose V1 语法version: 3、docker-compose子命令与当前仓库中的 docker-compose 文件 实测结构若你的环境使用 Compose V2可将docker-compose替换为docker compose。2. 推荐方式docker-compose 一键部署基础服务栈官方推荐使用docker-compose一键启动应用 数据库 缓存 反向代理的完整服务栈它会自动完成镜像拉取、项目镜像构建与多容器编排是上手最快、最省心的部署方式。2.1 关于 compose 文件位置的说明原文档中写明在项目根目录执行docker-compose up -d --build即假定根目录存在docker-compose.yml。在当前仓库快照中两个 compose 文件均位于deploy/docker-compose/目录下经仓库文件检索确认仅有这两份。因此若从仓库根目录执行请通过-f显式指定文件路径docker-compose -f deploy/docker-compose/docker-compose.yml up -d --build如果你将项目发布到服务器时习惯把 compose 文件放到根目录也可以保持原文档的直接写法二者的服务定义完全相同只是文件位置不同。2.2 服务栈拆解这份 compose 到底编排了哪些容器打开 deploy/docker-compose/docker-compose.yml 可以看到基础栈共编排了 4 个服务服务名镜像职责端口映射关键配置dbmysql:latest博客数据库3306:3306自动建库djangoblog根密码QQQQwww123!#数据卷mysql_data:/var/lib/mysqlredisredis:latest缓存服务6379:6379无密码供DJANGO_REDIS_URLredis:6379连接djangoblog本地构建build: ../..Django 应用8000:8000启动命令执行 entrypoint.sh挂载静态文件卷、日志与上传目录nginxnginx:latest反向代理 静态文件80:80、443:443挂载 deploy/nginx.conf以只读方式共享静态文件卷几个值得注意的实现细节应用镜像来自本地构建djangoblog服务的build.context指向../../仓库根目录dockerfile指定根目录的 Dockerfile因此--build会先构建应用镜像静态文件通过 named volume 共享static_files:/code/djangoblog/collectedstaticdjangoblog 容器可写、nginx 容器以:ro只读挂载这是 nginx 直接服务静态资源、Django 只处理动态请求的基础服务依赖关系djangoblog依赖dbdb又依赖redis保证了启动顺序。2.3 启动命令与访问方式# 构建并以后台模式启动容器包含 Django 应用、MySQL、Redis、Nginx docker-compose -f deploy/docker-compose/docker-compose.yml up -d --build访问博客启动完成后浏览器打开http://127.0.0.1Nginx 监听 80 端口并转发给容器内的 8000 端口数据持久化原文档描述为MySQL 数据存放在项目根目录的data/mysql中。在当前仓库的 compose 文件中db服务实际使用的是 Docker named volumemysql_data挂载点为容器内/var/lib/mysql数据同样在容器重启后不会丢失且更便于用docker volume管理。若你确实想用宿主机目录把该卷改成./data/mysql:/var/lib/mysql即可。2.4 (可选) 叠加 Elasticsearch 启用全文搜索默认情况下DjangoBlog 使用 Whoosh 作为本地全文检索后端如果你希望获得更强的全文搜索能力可以在基础栈之上叠加 ES 覆盖文件docker-compose -f deploy/docker-compose/docker-compose.yml \ -f deploy/docker-compose/docker-compose.es.yml up -d --build-f可以多次使用Compose 会将两个文件合并编排。查看 deploy/docker-compose/docker-compose.es.yml它会额外引入两个服务es使用liangliangyy/elasticsearch-analysis-ik:8.6.1镜像已内置 IK 中文分词插件以discovery.typesingle-node单节点模式运行ES_JAVA_OPTS限制 JVM 堆为 512MB映射端口9200:9200kibanakibana:8.6.1通过ELASTICSEARCH_HOSTShttp://es:9200连接 ES映射端口5601:5601便于可视化调试索引。同时在djangoblog服务中注入DJANGO_ELASTICSEARCH_HOSTes:9200这正是触发源码切换到 ES 后端的开关详见第 6.5 节。数据持久化原文档描述为ES 数据存放在data/elasticsearch而当前仓库的 es 覆盖文件挂载的是./bin/datas/es/:/usr/share/elasticsearch/data/部署时按仓库实际路径确认即可。版本一致性提醒当前仓库的 es 覆盖文件中对djangoblog服务的command与links仍引用旧版启动脚本bin/docker_start.sh和memcached服务与主 compose 存在历史版本差异。若叠加启动报错可参考第 7 节直接在叠加命令中显式覆盖djangoblog.command为sh /code/djangoblog/deploy/entrypoint.sh。3. 首次运行初始化进入容器执行管理命令当容器首次启动后应用容器服务名web在仓库 compose 中实际名为djangoblog会自动执行数据库迁移、静态文件收集等初始化工作详见第 7 节但你还需要手动创建管理员账号。# 进入 djangoblog 应用容器 docker-compose exec djangoblog bash # 在容器内执行以下命令 # 创建超级管理员账户按提示设置用户名、邮箱和密码 python manage.py createsuperuser # (可选) 创建一批测试数据 python manage.py create_testdata # (可选如果启用了 ES) 重建搜索索引 python manage.py rebuild_index # 退出容器 exit这些命令对应仓库中的真实管理命令create_testdata的实现位于 blog/management/commands/create_testdata.py用于批量生成文章、分类、标签等演示数据rebuild_index是 django-haystack 提供的标准索引重建命令对应后端为 djangoblog/elasticsearch_backend.py 或 djangoblog/whoosh_cn_backend.py由是否启用 ES 决定。此外仓库还提供build_index见 blog/management/commands/build_index.py它会在容器启动时被 entrypoint 自动调用一次。4. 备选方式使用独立 Docker 镜像对接外部 MySQL如果你已经有一套运行中的 MySQL不需要 Compose 管理数据库可以直接运行官方发布的应用镜像liangliangyy/djangoblog# 从 Docker Hub 拉取最新镜像 docker pull liangliangyy/djangoblog:latest # 运行容器并通过环境变量连接你的外部数据库 docker run -d \ -p 8000:8000 \ -e DJANGO_SECRET_KEYyour-strong-secret-key \ -e DJANGO_MYSQL_HOSTyour-mysql-host \ -e DJANGO_MYSQL_USERyour-mysql-user \ -e DJANGO_MYSQL_PASSWORDyour-mysql-password \ -e DJANGO_MYSQL_DATABASEdjangoblog \ --name djangoblog \ liangliangyy/djangoblog:latest访问博客启动完成后访问http://127.0.0.1:8000此时没有 Nginx直接访问 Django 端口创建管理员docker exec -it djangoblog python manage.py createsuperuser该镜像的构建入口与 Compose 完全一致见第 7 节因此容器首次启动时同样会自动执行迁移、静态文件收集与索引构建只需把DJANGO_*数据库变量指向你的外部 MySQL 即可。5. 配置总览环境变量逐项解析项目的大部分生产配置都通过环境变量驱动你可以在 compose 文件的environment段修改也可以在docker run时用-e传入。下表完整继承自官方文档并补充了对应的源码影响位置环境变量默认值 / 示例说明源码影响位置DJANGO_SECRET_KEYyour-strong-secret-key务必改成随机复杂字符串生产安全的核心settings.py L31-L32DJANGO_DEBUGFalse是否开启 Django 调试模式生产必须Falsesettings.py L34DJANGO_MYSQL_HOSTmysql数据库主机名Compose 内为服务名dbsettings.py L114DJANGO_MYSQL_PORT3306数据库端口settings.py L115-L116DJANGO_MYSQL_DATABASEdjangoblog数据库名称settings.py L111DJANGO_MYSQL_USERroot数据库用户名settings.py L112DJANGO_MYSQL_PASSWORDdjangoblog_123数据库密码settings.py L113DJANGO_REDIS_URLredis:6379/0Redis 连接地址用于缓存settings.py L295-L301DJANGO_ELASTICSEARCH_HOSTelasticsearch:9200ES 主机地址设置后切换全文检索后端settings.py L210-L233DJANGO_EMAIL_HOSTsmtp.example.org邮件服务器地址settings.py L311DJANGO_EMAIL_PORT465邮件服务器端口settings.py L312DJANGO_EMAIL_USERuserexample.org发信邮箱账户settings.py L313DJANGO_EMAIL_PASSWORDyour-email-password发信邮箱密码settings.py L314DJANGO_EMAIL_USE_SSLTrue是否启用 SSLsettings.py L310DJANGO_EMAIL_USE_TLSFalse是否启用 TLSsettings.py L309DJANGO_ADMIN_EMAILadminexample.org接收异常报告的管理员邮箱settings.py L318DJANGO_BAIDU_NOTIFY_URLhttp://data.zz.baidu.com/...百度站长平台链接推送接口settings.py L304-L3056. 环境变量在源码中如何生效理解了环境变量表再看它们在settings.py中真实的读取逻辑你就能明白改哪个变量会引发什么行为。6.1 布尔变量的解析规则DJANGO_DEBUG、DJANGO_EMAIL_USE_SSL/TLS等布尔型变量并不是简单的字符串而是经过env_to_bool统一解析settings.py L19-L21def env_to_bool(env, default): str_val os.environ.get(env) return default if str_val is None else str_val True即变量未设置时返回默认值设置时只有字符串字面量True才解析为真其余任何写法true、1、yes都会被当作False。这一点在配置 compose 环境时很容易踩坑务必写成True/False。6.2 DEBUG 的默认值陷阱注意 settings.py L34 的代码DEBUG env_to_bool(DJANGO_DEBUG, True)若你不设置DJANGO_DEBUG源码默认值是True开发模式——这与文档表格中的示例值False并不等价。生产部署时必须在 compose 或docker run中显式设置DJANGO_DEBUGFalse否则调试模式会把敏感信息暴露给访客。仓库的 docker-compose.yml 中已经显式写入了DJANGO_DEBUGFalse这是正确的生产姿势。6.3 SECRET_KEY 与 MySQL 连接SECRET_KEY在 settings.py L31-L32 通过os.environ.get(DJANGO_SECRET_KEY) or n9ceqv38...读取——内置默认值仅用于本地开发生产环境必须覆盖否则所有部署此项目的站点将共享同一把密钥存在被伪造签名会话的风险。MySQL 连接settings.py L109-L116则完整读取DJANGO_MYSQL_DATABASE / USER / PASSWORD / HOST / PORT五个变量并强制使用utf8mb4字符集以支持完整 Unicode包括 emoji存储。6.4 Redis 缓存的切换当设置DJANGO_REDIS_URL时settings.py L295-L301CACHES会切换到 Django 内置的redis.RedisCache后端LOCATION被拼接为redis://DJANGO_REDIS_URL未设置时则回退到项目默认的缓存方案。注意在 compose 中该变量的写法是redis:6379不含redis://前缀和数据库编号源码会自动补全协议头。6.5 Elasticsearch 后端的自动切换这是最值得关注的一处联动逻辑settings.py L210-L250只要检测到DJANGO_ELASTICSEARCH_HOST环境变量就会构造ELASTICSEARCH_DSL配置支持ELASTICSEARCH_VERIFY_CERTS、ELASTICSEARCH_USERNAME/PASSWORD等附加变量随后HAYSTACK_CONNECTIONS依据ELASTICSEARCH_DSL in locals()自动选择后端启用 ES 时使用 djangoblog/elasticsearch_backend.py 的ElasticSearchEngine否则回退到 djangoblog/whoosh_cn_backend.py 的WhooshEngine索引目录whoosh_index。这解释了为什么第 2.4 节只需叠加一个 compose 文件、注入一个环境变量全文检索后端就会从 Whoosh 平滑切换为 Elasticsearch。6.6 邮件与错误报告settings.py L308-L318 显示邮件功能使用 SMTP 后端EMAIL_USE_SSL默认True、EMAIL_USE_TLS默认False两者互斥同时为True会冲突DJANGO_ADMIN_EMAIL会写入ADMINS当DEBUGFalse时 Django 会把未捕获异常以邮件形式发送给该管理员。也就是说邮件变量不仅用于发送评论通知等业务邮件也是生产环境异常告警的通道。7. 镜像构建与容器启动的完整流程理解了配置再看应用镜像本身。根目录的 Dockerfile 采用两阶段构建这是理解为什么--build会比较慢以及静态资源从哪来的关键。7.1 阶段一Node 前端构建FROM node:20-alpine AS frontend-builder WORKDIR /app COPY frontend/package*.json ./frontend/ RUN cd frontend npm config set registry https://registry.npmjs.org/ npm ci COPY frontend/ ./frontend/ COPY templates/ ./templates/ RUN cd frontend npm run build前端工程位于 frontend/基于 Vite Tailwind 构建见 frontend/vite.config.js由于模板中的 Tailwind 类名需要参与扫描构建阶段同时拷贝了 templates/。构建产物输出到blog/static/blog/dist。7.2 阶段二Python 运行时FROM python:3.11 RUN apt-get update apt-get install default-libmysqlclient-dev gettext -y RUN pip install --upgrade pip pip install --no-cache-dir -r requirements.txt \ pip install --no-cache-dir gunicorn[gevent] pip cache purge COPY . . RUN rm -rf /code/djangoblog/blog/static/blog/dist COPY --fromfrontend-builder /app/blog/static/blog/dist /code/djangoblog/blog/static/blog/dist ENTRYPOINT [/code/djangoblog/deploy/entrypoint.sh]python:3.11基础镜像安装 MySQL 客户端库用于django.db.backends.mysql驱动和 gettext用于compilemessages国际化编译依赖安装完毕后从第一阶段拷贝前端构建产物并清掉源码树中可能残留的旧产物。7.3 entrypoint容器启动即自动初始化容器启动后执行的 deploy/entrypoint.sh 会按顺序自动完成python manage.py makemigrations \ python manage.py migrate \ python manage.py collectstatic --noinput \ python manage.py compress --force \ python manage.py build_index \ python manage.py compilemessages即生成并执行数据库迁移、收集静态文件到collectedstatic、压缩静态资源、构建搜索索引、编译翻译文件——首次启动时这些步骤已经替你完成这也是为什么第 3 节只需要创建超级管理员。全部成功后最终以 Gunicorn 启动服务exec gunicorn djangoblog.wsgi:application \ --workers 1 --bind 0.0.0.0:8000 \ --worker-class gevent --threads 4采用 gevent 协程 worker 每 worker 4 线程的组合入口模块见 djangoblog/wsgi.py在单 worker 情况下仍能并发处理请求。7.4 Nginx静态资源与反向代理deploy/nginx.conf 中监听 80 端口/static/请求通过alias直接命中collectedstatic目录expires max设置长缓存其余请求由proxy_pass http://djangoblog:8000转发给 Django并透传X-Real-IP、X-Forwarded-For、Host头。静态文件之所以能被 nginx 读取正是得益于 compose 中static_files命名卷在 djangoblog读写与 nginx只读两个容器之间的共享挂载。8. 部署完成后的安全检查清单部署完成后请务必对照以下几点逐项确认尤其是密钥与数据库、邮件相关项更换DJANGO_SECRET_KEY为一个随机、复杂、足够长的字符串可用python -c import secrets; print(secrets.token_urlsafe(50))生成确认DJANGO_DEBUGFalse并验证异常页面不再展示堆栈与调试工具栏核对数据库变量与你的 MySQL 实例用户名、密码、库名、主机、端口完全一致且数据库密码已从默认值QQQQwww123!#或djangoblog_123改为强密码配置邮件变量DJANGO_EMAIL_*否则生产环境的异常告警邮件无法送达DJANGO_ADMIN_EMAIL如启用全文搜索确认DJANGO_ELASTICSEARCH_HOST指向可达的 ES 实例并已在容器内执行过索引构建/重建检查http://127.0.0.1能正常访问博客/admin/后台可用管理员账号登录。完成以上步骤你的 DjangoBlog 便已在 Docker 环境中稳定运行。若需要更完整的集群化部署方案可继续阅读仓库中的 Kubernetes 部署指南 与中文版 Docker 部署文档。赞分享后端前端CMS【免费下载链接】DjangoBlog基于Django的博客系统项目地址https://gitcode.com/gh_mirrors/dj/DjangoBlog点击查看免费下载相关推荐DjangoBlog Docker 部署实战docker-compose 一键搭建、Elasticsearch 全文搜索与完整环境变量配置DjangoBlog Docker 部署实战docker compose 一键搭建、Elasticsearch 全文搜索与完整环境变量配置 本指南以 Djan后端前端CMSProxyPool 的 Docker 部署指南镜像运行、docker-compose 编排与容器化实践ProxyPool 的 Docker 部署指南镜像运行、docker compose 编排与容器化实践 导读 本文围绕 proxy_poolPython P后端网页爬虫网络Sanic 应用 Docker 化部署实战镜像构建、容器运行与 docker-compose 编排Sanic 应用 Docker 化部署实战镜像构建、容器运行与 docker compose 编排 导读 本文基于 Sanic 官方部署文档完整讲解如何将一后端Web框架上一篇d3d8to9终极指南让经典Direct3D 8游戏在现代Windows系统上完美运行下一篇如何用d3d8to9让老游戏在Windows 10/11上焕发新生终极兼容性解决方案创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
网站建设高端定制企业官网
RELATED

相关资讯

更多精彩内容,欢迎继续阅读

较早相关资讯

最新相关资讯

快速搭建网站的工具怎么选?3个方案省下5万冤枉钱 2026/9/28 9:42:31

快速搭建网站的工具怎么选?3个方案省下5万冤枉钱

快速搭建网站的工具怎么选?3个方案省下5万冤枉钱 网站做好了没人访问,这是很多老板最头疼的事。你花大价钱做的官网,设计精美、功能齐全,但打开一看,流量为零,咨询为零。这时候你才意识到,问题不在“做没做”,而在“怎么快速做出来并推向市场”。面…

阅读更多 →
昇腾910B多机分布式推理:从HCCL到MindIE的DeepSeek部署实践 2026/9/28 9:42:24

昇腾910B多机分布式推理:从HCCL到MindIE的DeepSeek部署实践

昇腾910B上跑DeepSeek多机分布式推理,很多人卡在第一眼:MindIE、HCCL、ranktable、hccn_tool,每个词都眼熟,串起来就不是那么回事。实际踩过一圈之后你会发现,真正决定能不能跑起来的不是模型代码,而是通信…

阅读更多 →
从CANoe到TSMaster:车载总线测试工具链迁移实战指南 2026/9/28 9:42:24

从CANoe到TSMaster:车载总线测试工具链迁移实战指南

搞车载总线测试的工程师,电脑里大概率都装着一套CANoe。我最早接触CANoe是刚入行那会儿,跟着前辈在项目里做网络测试,从报文发送、DBC解析到UDS诊断,基本全是靠Vector这套工具撑起来的。说实话,CANoe确实是这个行业的标…

阅读更多 →
从刷榜到用榜:GitHub Trending 的增量逻辑、项目筛选与高效落地 2026/9/28 9:42:23

从刷榜到用榜:GitHub Trending 的增量逻辑、项目筛选与高效落地

1. 日榜的"热度"到底是怎么算出来的先别急着收藏仓库。每天打开 GitHub 的 Trending 页面,你看到的是过去 24 小时内 Star 增量最高的仓库,周榜和月榜则分别看一周、一个月内的增量。官方没有公开完整排序算法,但用久了会发现&…

阅读更多 →
【Java开发MCP】SSE模式开发并集成MCP:TaoToken统一Key接入与SpringAI WebFlux配置骨架 2026/9/28 9:42:23

【Java开发MCP】SSE模式开发并集成MCP:TaoToken统一Key接入与SpringAI WebFlux配置骨架

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

阅读更多 →
OpenCompass 高效评测:Partitioner 任务切分与 Runner 执行后端实战指南 2026/9/28 9:42:23

OpenCompass 高效评测:Partitioner 任务切分与 Runner 执行后端实战指南

模型评测人工智能大模型AI 评测 【免费下载链接】opencompass OpenCompass is an LLM evaluation platform, supporting a wide range of models from OpenAI, Anthropic, Gemini, Qwen, GLM, DeepSeek, etc, across 100 datasets covering knowledge, reasoning, coding, scie…

阅读更多 →

今日资讯

本周资讯

本月资讯

看完文章仍有疑问?

联系尧图顾问,获取一对一建站咨询

立即免费咨询 📞 400-888-8888
📞 ✉