Wagtail 部署与托管完全指南从托管商选择、Fly.io 实战部署到底层基础设施原理【免费下载链接】wagtailA Django content management system focused on flexibility and user experience项目地址: https://gitcode.com/GitHub_Trending/wa/wagtail本篇技术指南以 Wagtail 官方部署文档为主体系统讲解三部分内容如何按服务层级选择合适的托管平台、如何借助 Fly.io Backblaze B2 完成一次从零到上线的真实部署以及 Wagtail 托管背后的基础设施原理WSGI/ASGI、静态文件、用户上传文件、缓存与安全。读完本文你将具备独立规划 Wagtail 生产环境、动手部署一个线上站点并在出问题时定位到对应配置与源码的能力。部署前的核心认知Wagtail 即 DjangoWagtail 构建在 Django 之上因此部署 Wagtail 所需的绝大多数步骤与注意事项和部署 Django 完全一致。docs/deployment/under_the_hood.md开篇即明确指出这一点并建议先通读 Django 官方的How to deploy Django文档。换句话说如果你已经熟悉 Django 生产部署那么你已经掌握了 Wagtail 部署的 80%剩下 20% 是 Wagtail 特有的部分——媒体文件图片/文档的存储与安全、后台管理界面的静态资源缓存、以及 CMS 特有的审计日志等。本文的 Fly.io 实战章节和底层原理章节正是围绕这 20% 展开。选择托管平台三级支持模型Wagtail 官方文档docs/deployment/index.md将托管服务商划分为三个层级按部署难度从低到高排列层级适合人群你需要自己处理的事情Wagtail 级支持希望开箱即用的开发者几乎无需配置平台内建数据库、媒体托管、备份等Python 级支持有一定 Python 经验的开发者需要自行配置 WSGI 服务器、媒体文件存储、数据库基础设施级支持熟悉 Linux 运维的工程师需要自己搭建 Linux 服务器、数据库、文件存储等Wagtail 级支持最容易部署官方文档点名了两个提供一等支持first-class support的平台CodeRed Cloudcodered.cloud官方描述强调极简、开箱即用it just works理念无需特殊包或第三方服务免费套餐可用且每个套餐都包含数据库、媒体托管和每日备份。Diviodivio.com面向容器化 Web 应用的云托管平台与 Wagtail 集成顺畅提供自动化备份、预发staging环境等能力官方声明其平台可确保 Wagtail 应用的可扩展性、安全性与可靠性。选择此类平台时你几乎可以把全部精力放在业务开发上数据库、媒体存储、备份等运维负担由平台承担。Python 级支持需要部分基础设施知识这类平台将 Python 运行环境作为服务提供典型代表是Fly.io。官方为此专门撰写了完整的部署教程Fly.io Backblaze 部署教程。使用这类平台你通常需要自行配置一个 WSGI 服务器如 Gunicorn来处理 Django 应用请求媒体文件的存储方案例如对象存储服务一个数据库例如 Fly Postgres。基础设施级支持需要 Linux 知识这类服务商只提供运行 Linux 服务器、数据库、文件存储所需的底层工具常见的包括AWS、Azure、Digital Ocean、Google Cloud、Linode。所有服务器配置、进程管理、反向代理、防火墙等工作都需要你亲自完成灵活性最高但部署成本也最高。其他参考官方还指出部分第三方平台上的部署实例可在 docs/advanced_topics/third_party_tutorials.md 中查看这并非 Wagtail 可运行平台的完整清单也不代表官方推荐的唯一方式。若要进行托管的底层技术深潜请看本文后半部分对应的底层原理内容。实战部署Fly.io Backblaze B2 完整教程接下来我们完整走一遍 docs/deployment/flyio.md 提供的生产部署流程。思路是站点本体托管在 Fly.io图片等媒体文件存放在 Backblaze B2 对象存储。将图片与站点分离的好处是更好的性能、安全性与可靠性——对象存储由专业 CDN 网络分发且不占用应用服务器资源。注意教程中反复出现的yourname占位符请替换为你自己选择的名称。第一步注册 Backblaze B2 云存储在浏览器访问 Backblaze 官网顶部导航点击Products在下拉菜单中选择B2 Cloud Storage注册账户输入邮箱与密码、选择合适的区域Region、点击Sign Up Now验证邮箱进入Account My Settings在 Security 区域点击Verify Email输入注册邮箱并获取验证码然后点击邮件中的验证链接或输入验证码创建存储桶Bucket进入B2 Cloud Storage Bucket点击Create a Bucket按下表填写信息Bucket 信息填写说明Bucket Unique Name使用唯一的桶名例如yourname-wagtail-portfolioFiles in Bucket are选择Public公开Default Encryption选择Disable禁用Object Lock选择Disable禁用点击Create a Bucket完成创建。第二步将站点链接到 Backblaze B2在项目根目录创建.env.production文件。此时你的项目目录结构大致如下以官方教程中的 portfolio 站点为例mysite/ ├── base ├── blog ├── home ├── media ├── mysite ├── portfolio ├── search ├── .dockerignore ├── .gitignore ├── .env.production ├── Dockerfile ├── manage.py ├── mysite/ └── requirements.txt然后在.env.production中写入以下环境变量AWS_STORAGE_BUCKET_NAME AWS_S3_ENDPOINT_URLhttps:// AWS_S3_REGION_NAME AWS_S3_ACCESS_KEY_ID AWS_S3_SECRET_ACCESS_KEY DJANGO_ALLOWED_HOSTS DJANGO_CSRF_TRUSTED_ORIGINShttps:// DJANGO_SETTINGS_MODULEmysite.settings.production用 Backblaze B2 桶信息填充变量环境变量填写说明AWS_STORAGE_BUCKET_NAME填入你的 Backblaze B2 桶名AWS_S3_ENDPOINT_URL填入 Backblaze B2 的端点 URL例如https://s3.us-east-005.backblazeb2.comAWS_S3_REGION_NAME从端点 URL 推断区域。例如端点为s3.us-east-005.backblazeb2.com时区域为us-east-005AWS_S3_ACCESS_KEY_ID暂留空AWS_S3_SECRET_ACCESS_KEY暂留空DJANGO_ALLOWED_HOSTS暂留空DJANGO_CSRF_TRUSTED_ORIGINS使用https://DJANGO_SETTINGS_MODULE使用mysite.settings.production为什么变量名都是AWS_前缀因为 Backblaze B2 提供了与 Amazon S3 兼容的 APIS3-compatibledjango-storages 的 S3 后端可以直接对接所以沿用 AWS 命名习惯。创建 Application Key 获取密钥上表中AWS_S3_ACCESS_KEY_ID与AWS_S3_SECRET_ACCESS_KEY需要去 Backblaze 控制台生成登录 Backblaze B2 账户进入Account Application Keys点击Add a New Application Key按下表配置设置项说明Name of Key提供一个唯一名称Allow access to Buckets选择前面创建的桶Type of Access选择Read and Write读写Allow List All Bucket Names保持不勾选File name prefix留空Duration (seconds)留空点击Create New Key生成后将keyID填入AWS_S3_ACCESS_KEY_ID将applicationKey填入AWS_S3_SECRET_ACCESS_KEY。此时.env.production的内容应为AWS_STORAGE_BUCKET_NAMEyourname-wagtail-portfolio AWS_S3_ENDPOINT_URLhttps://s3.us-east-005.backblazeb2.com AWS_S3_REGION_NAMEus-east-005 AWS_S3_ACCESS_KEY_IDyour Backblaze keyID AWS_S3_SECRET_ACCESS_KEYyour Backblaze applicationKey DJANGO_ALLOWED_HOSTS DJANGO_CSRF_TRUSTED_ORIGINShttps:// DJANGO_SETTINGS_MODULEmysite.settings.production安全警示重要.env.production包含访问站点的凭据绝不能提交到版本库或分享给他人如果遗失了 secret application key按前述步骤重新生成一把新密钥即可。第三步注册并配置 Fly.io在浏览器访问 Fly.io点击Sign Up可使用 GitHub、Google 或邮箱注册查收邮箱中的验证链接完成验证。若验证失败可前往 Fly.io Dashboard 重试进入Dashboard Billing点击Add credit card添加信用卡。官方说明强调添加信用卡只是创建项目的必要条件Fly.io 不会在添加后立刻扣费安装 flyctl 命令行工具按操作系统选择macOSHomebrew 或官方脚本# 已安装 Homebrew 时 brew install flyctl # 未安装 Homebrew 时 curl -L https://fly.io/install.sh | shLinuxcurl -L https://fly.io/install.sh | shWindowsPowerShellpwsh -Command iwr https://fly.io/install.ps1 -useb | iex若 Windows 提示pwsh不是可识别的命令先安装 PowerShell MSI再重跑上面的命令。若安装后提示fly无法识别或flyctl: command not found需要把 flyctl 加入 PATH。登录 Fly.iofly auth login若使用微软 WSL需先执行ln -s /usr/bin/wslview /usr/local/bin/xdg-open创建项目运行fly launch然后按提示输入y配置设置浏览器会打开 Fly.io 管理界面按下表填写字段说明Choose a region for deployment选择与.env.production中AWS_S3_REGION_NAME距离最近的区域CPU MemoryVM Size - shared-cpu-1xVM Memory - 512 MBDatabaseFly Postgres选择最小规格点击Confirm settings确认。注意建议在fly launch时就通过 Web 界面一并创建数据库若不与应用一起创建会导致应用与数据库未建立连接。若后续再次运行fly launch同样推荐通过 Web UI 随应用一起新建数据库。回到终端回答提示问题问题回答Overwrite .../.dockerignore?输入yOverwrite .../Dockerfile?输入yfly launch会在项目目录生成两个新文件Dockerfile和fly.toml。如果使用 VS Code 等第三方终端创建 Postgres 数据库时报错可先删除项目中的fly.toml然后在浏览器中进入 Dashboard逐个删除 Apps 列表中的应用Settings Delete app最后在系统内置终端或 PowerShell MSI 中重新运行fly launch。第四步定制站点以适配 Fly.io忽略敏感文件在.gitignore中加入.env*在.dockerignore中加入让 Docker 忽略环境文件与本地媒体文件.env* media将 Gunicorn worker 数调整为 1Fly.io 免费档内存较小将 worker 数设为 1 可以让站点更好地适配低内存配额。修改Dockerfile最后一行CMD [gunicorn, --bind, :8000, --workers, 1, mysite.wsgi]检查fly.toml确认其中包含数据库迁移的 release 命令[deploy] release_command python manage.py migrate --noinput完整的fly.toml应类似app yourname-wagtail-portfolio primary_region lhr console_command /code/manage.py shell [build] # add the deploy command: [deploy] release_command python manage.py migrate --noinput [env] PORT 8000 [http_service] internal_port 8000 force_https true auto_stop_machines true auto_start_machines true min_machines_running 0 processes [app] [[statics]] guest_path /code/static url_prefix /static/更新生产依赖用下面的内容替换requirements.txtDjango4.2,4.3 wagtail5.1.1 gunicorn21.2.0,22.0.0 psycopg[binary]3.1.10,3.2.0 dj-database-url2.1.0,3.0.0 whitenoise5.0,5.1 django-storages[s3]1.14.0,2.0.0各依赖在生产环境中的作用依赖作用gunicorn在 Docker 中运行站点的 WSGI Web 服务器psycopgPostgreSQL 适配器负责连接 PostgreSQL 数据库dj-database-url简化数据库配置从环境变量解析数据库连接whitenoise由 Django 负责托管静态文件的中间件/存储后端django-storagesDjango 文件存储库负责对接 Backblaze B2 存储注该教程示例的版本号针对当时的 Wagtail 5.1 编写当前仓库版本为 8.1见 wagtail/init.py。实际部署时请以官方发布版本为准选择兼容的版本组合仓库自带的 project_template/requirements.txt 与 project_template/Dockerfile 也提供了官方维护的最新依赖与多阶段构建参考。编写生产环境设置文件用以下内容替换mysite/settings/production.pyimport os import random import string import dj_database_url from .base import * DEBUG False DATABASES { default: dj_database_url.config(conn_max_age600, conn_health_checksTrue) } SECRET_KEY os.environ[SECRET_KEY] SECURE_PROXY_SSL_HEADER (HTTP_X_FORWARDED_PROTO, https) SECURE_SSL_REDIRECT True ALLOWED_HOSTS os.getenv(DJANGO_ALLOWED_HOSTS, *).split(,) CSRF_TRUSTED_ORIGINS os.getenv(DJANGO_CSRF_TRUSTED_ORIGINS, ).split(,) EMAIL_BACKEND django.core.mail.backends.console.EmailBackend MIDDLEWARE.append(whitenoise.middleware.WhiteNoiseMiddleware) STORAGES[staticfiles][BACKEND] ( whitenoise.storage.CompressedManifestStaticFilesStorage ) if AWS_STORAGE_BUCKET_NAME in os.environ: AWS_STORAGE_BUCKET_NAME os.getenv(AWS_STORAGE_BUCKET_NAME) AWS_S3_REGION_NAME os.getenv(AWS_S3_REGION_NAME) AWS_S3_ENDPOINT_URL os.getenv(AWS_S3_ENDPOINT_URL) AWS_S3_ACCESS_KEY_ID os.getenv(AWS_S3_ACCESS_KEY_ID) AWS_S3_SECRET_ACCESS_KEY os.getenv(AWS_S3_SECRET_ACCESS_KEY) INSTALLED_APPS.append(storages) STORAGES[default][BACKEND] storages.backends.s3boto3.S3Boto3Storage AWS_S3_OBJECT_PARAMETERS { CacheControl: max-age86400, } LOGGING { version: 1, disable_existing_loggers: False, handlers: { console: { class: logging.StreamHandler, }, }, loggers: { django: { handlers: [console], level: os.getenv(DJANGO_LOG_LEVEL, INFO), }, }, } WAGTAIL_REDIRECTS_FILE_STORAGE cache try: from .local import * except ImportError: pass代码要点逐条解析DEBUG False关闭调试模式生产环境安全与性能的关键SECRET_KEY os.environ[SECRET_KEY]从环境变量读取项目密钥务必通过flyctl secrets注入不要硬编码SECURE_PROXY_SSL_HEADER (HTTP_X_FORWARDED_PROTO, https)当站点部署在反向代理如 Fly.io 的 HTTPS 边缘之后时让 Django 正确识别安全连接SECURE_SSL_REDIRECT True强制 HTTPS 重定向保证所有连接加密ALLOWED_HOSTS os.getenv(DJANGO_ALLOWED_HOSTS, *).split(,)定义可访问站点的主机名列表从环境变量读取未设置时默认放行所有主机EMAIL_BACKEND django.core.mail.backends.console.EmailBackend使用控制台邮件后端生产可替换为真实邮件服务WAGTAIL_REDIRECTS_FILE_STORAGE cache将 Wagtail 重定向的文件存储配置为使用缓存Wagtail 5.x 时代的旧配置项在新版本中重定向已改用数据库存储部署时以当前版本文档为准。关于STORAGES的说明STORAGES[staticfiles][BACKEND]换成了 WhiteNoise 的压缩清单存储后端让静态文件带哈希文件名、由 Whitenoise 直接提供服务而STORAGES[default][BACKEND]在检测到AWS_STORAGE_BUCKET_NAME环境变量后切换为storages.backends.s3boto3.S3Boto3Storage使上传的图片与文档落盘到 Backblaze B2。补齐环境变量并注入密钥环境变量说明DJANGO_ALLOWED_HOSTS必须匹配 Fly.io 项目名例如yourname-wagtail-portfolio.fly.devDJANGO_CSRF_TRUSTED_ORIGINS必须匹配项目域名例如https://yourname-wagtail-portfolio.fly.dev最终.env.production内容如下AWS_STORAGE_BUCKET_NAMEyourname-wagtail-portfolio AWS_S3_ENDPOINT_URLhttps://s3.us-east-005.backblazeb2.com AWS_S3_REGION_NAMEus-east-005 AWS_S3_ACCESS_KEY_IDyour Backblaze keyID AWS_S3_SECRET_ACCESS_KEYyour Backblaze applicationKey DJANGO_ALLOWED_HOSTSyourname-wagtail-portfolio.fly.dev DJANGO_CSRF_TRUSTED_ORIGINShttps://yourname-wagtail-portfolio.fly.dev DJANGO_SETTINGS_MODULEmysite.settings.production将环境变量作为密钥导入 Fly.ioflyctl secrets import .env.productionWindowsPowerShell MSIGet-Content .env.production | flyctl secrets import第五步部署上线执行部署命令fly deploy --hafalse--hafalse的含义默认fly deploy会为应用创建两台机器高可用加上该参数后只创建一台机器符合免费额度的资源预算。部署完成后站点即已上线。接下来为线上站点创建管理员用户flyctl ssh console然后在容器内执行DJANGO_SUPERUSER_USERNAMEusername DJANGO_SUPERUSER_EMAILmailexample.com DJANGO_SUPERUSER_PASSWORDpassword python manage.py createsuperuser --noinput请将username、mailexample.com、password替换为你自己的用户名、邮箱与密码。第六步为线上站点添加内容线上环境与本地环境是相互独立的之前在本地产出的内容不会自动同步。访问https://yourname-wagtail-portfolio.fly.dev/admin/登录后即可通过后台为线上站点添加内容包括首页内容、社交媒体链接、页脚文本、站点菜单页面、联系信息与简历等对应 docs/tutorial 系列教程的各小节。若访问线上站点报错可前往 Fly.io Dashboard 查看应用日志Dashboard Apps yourname-wagtail-portfolio Monitoring。深入原理Wagtail 托管底层基础设施如果上面的实战教程解决了怎么部署那么 docs/deployment/under_the_hood.md 解决的是为什么这样部署。以下内容适合已经了解基本部署流程、希望掌握原理的读者。WSGI / ASGI 服务器Django 是 Web 框架必须依托 Web 服务器运行而大多数 Web 服务器并不原生讲 Python因此需要 WSGI/ASGI 这样的接口协议来完成通信。Wagtail 同时支持 WSGI 与 ASGI 两种方式部署但Wagtail 自身并未实现任何异步视图或异步中间件因此官方推荐使用 WSGI。这也是为什么上面的 Fly.io 教程选用 Gunicorngunicorn --bind :8000 mysite.wsgi作为应用服务器。仓库自带的 project_template/Dockerfile 同样以 Gunicorn 作为最终运行命令gunicorn {{ project_name }}.wsgi:application并给出了多阶段构建的官方参考实现builder 阶段编译依赖、runtime 阶段以非 root 的wagtail用户运行、EXPOSE 8000、容器启动时先执行migrate再启动 Gunicorn。静态文件生产环境必须单独处理与所有 Django 项目一样静态文件只在开发环境由manage.py runserver负责提供生产环境中必须在 Web 服务器层面另行处理。Wagtail 后台的 JavaScript 与 CSS 文件在每个版本之间变化频繁如果浏览器或服务器缓存了旧版本会引发难以排查的诡异问题。因此官方强烈建议在生产环境的STORAGES[staticfiles]设置中启用ManifestStaticFilesStorage——它会给不同版本的文件分配带内容哈希的独立 URL从而彻底规避缓存串号问题。仓库自带的项目模板 wagtail/project_template/project_name/settings/production.py 正是这样做的DEBUG False # ManifestStaticFilesStorage is recommended in production, to prevent # outdated JavaScript / CSS assets being served from cache # (e.g. after a Wagtail upgrade). STORAGES[staticfiles][BACKEND] django.contrib.staticfiles.storage.ManifestStaticFilesStorage try: from .local import * except ImportError: pass模板中的基础设置wagtail/project_template/project_name/settings/base.py则定义了STATIC_URL /static/、STATIC_ROOT、MEDIA_ROOT BASE_DIR / media、MEDIA_URL /media/等路径并显式声明STORAGES默认后端为FileSystemStorage——生产部署时再按需覆盖为 Manifest 存储或云存储。用户上传文件图片与文档Wagtail 遵循 Django 管理上传文件的惯例Django 文件处理文档。默认情况下Wagtail 使用 Django 内置的FileSystemStorage把文件存放到由MEDIA_ROOT指定的服务器本地目录也可以通过STORAGES[default]设置配合 django-storages 等第三方包将图片与文档存储到 Amazon S3 等云存储服务——这正是 Fly.io 教程中通过S3Boto3Storage对接 Backblaze B2 的原理所在。安全总则任何允许用户上传文件的系统都存在安全风险。例如有上传权限的用户若上传了包含脚本的 HTML 文件当其他用户直接浏览该文件时可能触发跨站脚本攻击XSS。如果所有能访问 Wagtail 后台的人都是完全可信的例如只有你一个编辑的个人站点风险可控但 Wagtail 默认提供安全配置开发者若想放开限制必须充分理解风险。图片的安全与分发使用FileSystemStorage时图片 URL 从MEDIA_URL指定的路径构造。大多数情况下应当让 Web 服务器直接从MEDIA_ROOT下的images子目录提供图片不经过 Django/Wagtail并屏蔽original_images子目录的访问。如果启用了 SVG 图片见 docs/topics/images.md用户可能上传包含脚本的 SVG 文件直接浏览时会执行其中的脚本官方针对这一风险提供了多种规避方案。使用云存储后端时图片 URL 直接指向云存储地址。如果想从独立的资源服务器或 CDN 提供图片可以配置图片 serve 视图的 redirect 动作让图片请求 302 重定向到资源地址参见 docs/advanced_topics/images/image_serve_view.md。文档的三种服务方式WAGTAILDOCS_SERVE_METHOD文档Document的服务方式由WAGTAILDOCS_SERVE_METHOD设置控制完整说明见 docs/reference/settings.md。正常情况下文档请求会经过一个 Django 视图执行隐私检查如集合的 Privacy 设置与访问计数等内务操作但由 Django 服务器代为传输文件会带来性能开销尤其会抵消把文档托管到 S3/CDN 的大部分收益。为此 Wagtail 提供了三种在权限检查严格度与性能之间取舍的服务方法取值行为适用场景serve_view链接指向 Django 视图同时完成权限检查与文件传输若安装了 django-sendfile 且服务器支持则交由 sendfile 发送否则由 Django 以流式响应发送本地存储、需要最强权限保证应配置 Web 服务器禁止直接访问MEDIA_ROOT下的文档目录redirect链接指向 Django 视图做权限检查通过后 302 重定向到存储后端提供的 URL 下载远程存储后端如 S3文档不经 Django 服务器传输注意若用户猜出后者 URL 可绕过检查可配合随机/短时效 URL 缓解direct链接直接指向存储后端提供的 URL完全绕过 Django 视图全静态站点如配合 wagtail-bakery、Gatsby 生成静态页面如果该设置未指定或为None默认规则是使用远程存储后端暴露 URL 但不暴露本地文件路径时为redirect否则为serve_view。这一逻辑在源码中有清晰的对应实现在 wagtail/documents/views/serve.py 中serve视图首先校验document_id与文件名匹配、依次触发before_serve_document钩子并发送document_served信号然后根据WAGTAILDOCS_SERVE_METHOD决定是直接 302 重定向到doc.file.url还是走serve_local流程本地路径用sendfile、远程存储用FileResponse流式传输并在响应头附加Content-Security-Policy: default-src none与X-Content-Type-Options: nosniff等安全头。相关行为在 wagtail/documents/tests/test_views.py 中有系统测试覆盖。与文档安全相关的配套设置还包括WAGTAILDOCS_CONTENT_TYPES指定serve_view方式下各扩展名返回的 MIME 类型未列出的用 Pythonmimetypes.guess_type猜测失败则回退application/octet-streamWAGTAILDOCS_INLINE_CONTENT_TYPES列出以Content-Disposition: inline内联展示而非下载的 MIME 类型列表默认application/pdfWAGTAILDOCS_BLOCK_EMBEDDED_CONTENT默认True为文档返回限制性 CSP阻止内嵌内容如 HTML 文件中的脚本执行官方强烈建议保持默认。云存储的真相并未完全卸载文件处理需要注意配置远程存储并不会把文件处理任务完全卸载给对象存储某些 Wagtail 功能仍要求应用服务器回读文件。最典型的是——每当创建新的缩放版本rendition时应用服务器必须回读原始图片文件文档若配置为经 Django 视图服务以执行权限检查同样需要回读。重要警告django-storages 的 Amazon S3 后端storages.backends.s3boto.S3BotoStorage与storages.backends.s3boto3.S3Boto3Storage在默认配置下不能正确处理重名文件。使用这些后端时必须将AWS_S3_FILE_OVERWRITE设为False否则文件名冲突可能导致文件被意外覆盖。缓存加速后台的关键Wagtail 设计上会利用 Django 的缓存框架来加速页面加载缓存对Wagtail 后台尤其有价值——后台无法借助常规 CDN 缓存。Wagtail 支持 Django 的全部缓存后端但官方不建议使用与运行进程/环境绑定的缓存如FileBasedCache或LocMemCache因为它们在不同进程/实例之间不共享、无法支撑多实例部署。部署技巧清单官方没有唯一正确的部署方式但给出了若干让站点更稳定、更可维护的建议执行 Django 部署检查清单Django 官方提供了一份部署 checklistdjango-admin check --deploy覆盖上线前应完成或至少知晓的所有事项建议逐项过一遍。日志与监控logging and monitoring生产环境通常需要多层日志与指标。Wagtail 本身贡献两样东西审计日志audit log记录创建、编辑、删除、发布、移动等敏感 CMS 操作详见 docs/extending/audit_log.md标准 Django 日志通过 DjangoLOGGING设置记录请求错误与表单校验失败。常见的外部补充包括错误与性能监控对 Django 应用做运行时插桩、Web 服务器/反向代理/CDN 日志关注请求量、状态码与限流、Web 应用防火墙WAF日志用于攻击模式检测。性能优化生产站点应尽可能快官方性能建议见 docs/advanced_topics/performance.md。总结一次部署两种视角本文以官方部署文档为主线给出了完整的行动路径先按三级支持模型选定托管平台再以 Fly.io Backblaze B2 为例完成从对象存储、环境变量、容器配置到fly deploy的全流程实战最后以 WSGI 服务器、静态文件、上传文件与缓存为切入点理解底层原理。部署 Wagtail 站点的核心心智模型可以浓缩为三句话Wagtail 是 DjangoDjango 部署的成熟经验WSGI、数据库、环境变量、部署检查清单全部适用静态文件与媒体文件要分开对待静态文件交给 Manifest 存储 Whitenoise/CDN用户上传文件按图片、文档分别设计存储与安全策略WAGTAILDOCS_SERVE_METHOD是文档服务的总开关安全默认从严DEBUGFalse、密钥走环境变量、HTTPS 强制、上传文件按不可信输入对待是任何生产部署都不可妥协的底线。如果你在某个特定平台上完成了部署并积累了经验Wagtail 官方也欢迎将部署笔记贡献回文档让社区受益。【免费下载链接】wagtailA Django content management system focused on flexibility and user experience项目地址: https://gitcode.com/GitHub_Trending/wa/wagtail创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考