Celery 2.4 版本历史详解：安全修复、Broker URL 支持与关键演进

Celery 2.4 版本历史详解安全修复、Broker URL 支持与关键演进【免费下载链接】celeryDistributed Task Queue (development branch)项目地址: https://gitcode.com/gh_mirrors/ce/celery导读本文基于当前仓库 docs/history/changelog-2.4.rst 完整梳理 Celery 2.4 系列2.4.02.4.5的版本历史覆盖 Python 3 支持、Broker URL 统一配置、AMQP 结果后端默认过期机制、CELERYSA-0001 安全公告CVE-2011-4356等核心变更。读完本文你将能准确理解 Celery 2.x 时代重大配置与 API 演进脉络掌握BROKER_URL、CELERY_TASK_RESULT_EXPIRES、CELERY_RESULT_SERIALIZER等关键设置的由来与用法并了解这些变更在 celery/app/defaults.py、celery/backends/base.py 等源码中的落点。版本一览2.4.0 至 2.4.5Celery 2.4 系列于 2011 年 11 月至 12 月密集发布由 Ask Solem 主持发布共包含 6 个版本版本发布日期核心内容2.4.02011-11-04支持 Python 3Broker URLAMQP 结果默认过期弃用一批 API2.4.12011-11-07修复celeryctl inspect输出缺失、进程池轮询与序列化问题2.4.22011-11-14程序模块改用绝对导入支持python -m celery.bin.name2.4.32011-11-22修复celeryctl模块导入笔误Issue #5382.4.42011-11-25安全修复版本修复 CELERYSA-0001 权限提升漏洞2.4.52011-12-02修复周期任务间隔取整误差与 beat 日志时间展示2.4.0一个里程碑式的版本2.4.0 是 2.4 系列的开篇包含了大量结构性变更很多设计一直影响至今。正式支持 Python 32.4.0 起 Celery 支持 Python 3这是该版本最重要的能力升级。与此同时由于不再需要兼容 Python 2.4内部模块得以采用绝对导入并正确命名两个并发模块被重命名celery.concurrency.evlet→celery.concurrency.eventletcelery.concurrency.evg→celery.concurrency.gevent当前仓库中的目录结构 celery/concurrency/ 仍保留着eventlet.py、gevent.py的完整实现prefork.py、solo.py、thread.py等并发池也在同一目录下。Broker 地址支持 URL 形式BROKER_URL 诞生这是 2.4.0 最重要的易用性改进。此前 broker 只能通过BROKER_HOST等散落配置项指定2.4.0 起可以用一个 URL 描述完整连接信息格式为transport://user:passwordhostname:port/virtual_host例如默认 brokerRabbitMQ 默认 virtual host/amqp://guest:guestlocalhost:5672//关键规则原文档明确强调scheme协议必填用于区分URL与纯主机名user、password、port、virtual_host 均可省略省略时使用该 transport 的默认值path 部分virtual_host必须以正斜杠开头且该前导斜杠始终必须保留——这是为了区分空 virtual host与根 virtual host/virtual host 为/时写成amqp://guest:guestlocalhost:5672//注意末尾双斜杠virtual host 为空时写成amqp://guest:guestlocalhost:5672/。同时新增BROKER_URL设置作为BROKER_HOST的别名。合并规则为URL 与配置同时指定某项时以 URL 为准URL 未提供的项则回落到配置值。命令行与环境变量也可以覆盖$ celery worker -b redis://localhost $ celery inspect -b amqp://guest:guestlocalhost//e环境变量CELERY_BROKER_URL亦可用于快速覆盖默认 broker。从当前源码看这一演进被完整保留celery/app/defaults.py 的 broker 命名空间中定义了urlOption(typestring)等项而 celery/app/utils.py 在处理配置时仍专门处理新旧键并存的情况如broker_url与BROKER_URL同时出现。-b/--broker命令行选项则持续存在于 celery/bin/multi.py 等所有入口中。AMQP 结果后端默认启用结果过期2.4.0 起 AMQPRPC 风格结果后端默认对结果设置过期时间过期值取自CELERY_TASK_RESULT_EXPIRES设置旧的CELERY_AMQP_TASK_RESULT_EXPIRES被弃用计划 4.0 移除。这意味着结果后端需要RabbitMQ 2.1.0 及以上才能支持消息过期若运行在更老版本上必须显式禁用过期CELERY_TASK_RESULT_EXPIRES None这一默认值沿用至今在 celery/app/defaults.py 中result.expires的默认值为timedelta(days1)即一天旧键celery_task_result_expires仍作为兼容别名被识别celery/backends/base.py 的prepare_expires方法在未显式传值时回落到self.app.conf.result_expires正是这套机制的现代形态。错误邮件机制重构ErrorMail 取代白名单:setting:CELERY_TASK_ERROR_WHITELIST白名单设置被更灵活的方案取代Issue #447错误邮件发送逻辑被封装为Task.ErrorMail实现参考celery.utils.mail模块。通过子类化错误邮件类即可完全控制何时发送错误邮件不再需要独立的白名单配置。CELERY_TASK_ERROR_WHITELIST 被弃用计划 4.0 移除。一批 API 与设置的弃用2.4.0 明确了一批计划在 4.0 移除的弃用项已弃用的函数及替代方案旧函数替代方案celery.loaders.current_loadercelery.current_app.loadercelery.loaders.load_settingscelery.current_app.confcelery.execute.applyTask.applycelery.execute.apply_asyncTask.apply_asynccelery.execute.delay_taskcelery.execute.send_task已弃用的设置及替代方案旧设置替代方案CELERYD_LOG_LEVELcelery worker --loglevelCELERYD_LOG_FILEcelery worker --logfileCELERYBEAT_LOG_LEVELcelery beat --loglevelCELERYBEAT_LOG_FILEcelery beat --logfileCELERYMON_LOG_LEVELcelerymon --loglevelCELERYMON_LOG_FILEcelerymon --logfile另外:func:celery.loaders.setup_loader 函数在 2.4.0 中被直接移除而非弃用。其他 2.4.0 功能与修复不再依赖pyparsing依赖 Kombu 升级到1.4.3CELERY_IMPORTS现在可以是标量值Issue #485不再强制要求元组/列表避免新手忘记在单元素元组后加逗号修复线程池内存泄漏Issue #486statedb已撤销任务状态数据库现在会在退出时保存配合--statedb能正确记住此前 revoked 的任务新增EMAIL_USE_TLS设置用于启用安全的 SMTP 连接Issue #418按消息格式文档处理缺失字段缺失必填字段抛出InvalidTaskError缺失args/kwargs视为空修复 celery/events/state.pycelerymon/celeryev中迭代时移除任务信息的竞态条件Issue #501Cache、Cassandra、MongoDB、Redis、Tyrant 后端开始遵守CELERY_RESULT_SERIALIZER设置Issue #435——当时仅数据库Django/SQLAlchemy后端还不支持自定义序列化器日志调用不再手工格式化消息而是交给 logging 系统处理便于 Sentry 等工具对接Issue #445multi新增stop_verify命令用于等待进程完全关闭修复缓存 key 为 unicode 时 Cache 后端失效的问题Issue #504新增CELERY_RESULT_DB_SHORT_LIVED_SESSIONS设置启用后禁用 SQLAlchemy 会话缓存Issue #449所有结果后端实现__reduce__以支持 pickleIssue #441修复multi在 Windows 上不工作的问题Issue #472新版CELERY_REDIS_*设置现在优先于旧版REDIS_*配置键Issue #508通用 beat init 脚本不再设置bash -eIssue #510文档说明redis-server2.2 之前的版本与 Chord 配合不佳CELERYBEAT_MAX_LOOP_INTERVAL设置此前未被遵守本次修复inspect.registered_tasks更名为inspect.registered旧名保留为别名worker 日志输出 args/kwargs 字符串表示时增加安全防护Issue #480修复KeyValueStoreBackend.get_many不遵守timeout参数的问题Issue #512修复 beat/events 的--workdir选项未在配置加载前执行chdir(2)的问题Issue #506AUTHORS文件改为按字母序排列。RHEL init 脚本启动优先级调整为了让以数据库作为 broker/消息存储的 Celery 在数据库就绪后再启动RHEL init 脚本的 chkconfig 优先级从# chkconfig: - 64 36调整为第三方应用的推荐值# chkconfig: - 85 15从而保证 Celery 在数据库服务启动之后启动、在其停止之前关闭。2.4.1进程池与日志修复修复celeryctl inspect命令缺失输出进程池prefork降低轮询间隔减少空闲 CPU 占用MaybeEncodingError现在被包裹进ExceptionInfoIssue #524worker 不再吞掉任务消费者启动后发生的错误修复 stdout 重定向日志无法写入 unicode 的问题Issue #522。2.4.2支持 python -m 调用程序模块不再使用相对导入从而支持python -m celery.bin.name形式直接运行各子命令。这一设计延续至今celery/bin/ 下的每个子命令模块都可以作为模块执行。2.4.3导入笔误修复修复celeryctl中的模块导入 typoIssue #538。2.4.4安全修复版本CELERYSA-0001CVE-2011-4356权限提升漏洞这是 2.4 系列最重要的安全公告完整细节见仓库 docs/sec/CELERYSA-0001.txt。核心问题celery multi、celeryd_detach、celery beat、celery events程序在处理--uid/--gid参数时只切换了有效用户 IDeffective id而未切换真实 IDreal id后果是权限没有真正丢弃恶意代码随后可以重新获得超级用户权限结合 Celery 默认使用的Pickle 序列化器可以执行任意代码这一事实漏洞风险被进一步放大影响版本2.1、2.2、2.3、2.4不含已修复的 2.2.8、2.3.4、2.4.4风险等级medium问题类型local关联 Issue #544。受影响场景以 root 用户守护运行 Celery 程序并满足以下任一条件使用了--uid或--gid参数使用了带CELERYD_USER或CELERYD_GROUP环境变量的通用 init 脚本。不受影响场景Debian init 脚本、CentOS init 脚本、macOS launchctl 脚本、Supervisor 管理或以非 root 用户启动程序。修复方案为升级对应系列的最新版本pip install -U celery或easy_install -U celery。官方同时建议加固系统防止恶意用户滥用消息 broker 投递消息或禁用 Pickle 序列化器以杜绝任意代码执行。2.4.4 其他修复进程池修复关闭时的罕见死锁Issue #523Webhook 任务的 HTTP POST 请求头修正Issue #515Content-Type从application/json改为application/x-www-form-urlencoded并补充正确的Content-Length头守护化教程新增 Django virtualenv 组合的配置示例Issue #505通用 init 脚本现在会自动创建 log 与 pid 文件目录Issue #545对应仓库 extra/generic-init.d/celeryd 与 extra/generic-init.d/celerybeat。2.4.5周期任务与 beat 日志修复周期任务 interval 调度被意外向下取整、导致部分周期任务提前执行的问题beat 日志中人类可读时间humanized times的日志输出更加详细文档新增 Getting Started 的 brokers 章节替代旧的 Other queues 教程补充了 MongoDB、Beanstalk、CouchDB 的接入文档。从 2.4 到当前版本的演进脉络理解 2.4 的变更有助于理解 Celery 后续版本的很多设计选择Broker URL 成为唯一标准2.4 引入的BROKER_URL在后续版本演化为broker_url新式小写命名当前 celery/app/defaults.py 中的 broker 命名空间同时登记了url等选项并保留旧键兼容结果过期默认开启result_expires默认timedelta(days1)的设定延续至今prepare_expirescelery/backends/base.py仍会在调用方未指定过期时间时回落到该配置弃用节奏明确2.4 宣布的弃用项大多在 4.0 移除体现了 Celery 提前一个大版本预警 的兼容性策略结果序列化器统一CELERY_RESULT_SERIALIZER从 2.4 起逐渐覆盖更多后端现代版本中所有结果后端均支持自定义序列化器默认json见 celery/app/defaults.py安全响应机制CELERYSA-0001 是 Celery 最早的公开安全公告之一docs/sec/ 目录中的 CELERYSA 系列文档已成为其安全披露的标准载体。对于仍在阅读 2.x 代码或迁移历史项目的开发者本文列出的设置对照表BROKER_HOST→BROKER_URL、CELERYD_LOG_LEVEL→命令行参数、celery.execute.apply→Task.apply等是理解新旧代码差异的第一手索引。小结Celery 2.4 是 Celery 历史上承前启后的版本它让 Python 3 用户能够使用 Celery用 URL 统一了 broker 配置模型把结果过期与序列化器控制带到更多后端并通过 CELERYSA-0001 修复了守护进程的权限管理缺陷。无论是排查历史行为、阅读旧教程代码还是理解当前配置项的来源docs/history/changelog-2.4.rst 都是值得对照的权威依据。【免费下载链接】celeryDistributed Task Queue (development branch)项目地址: https://gitcode.com/gh_mirrors/ce/celery创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考