Freight核心架构解析Flask API、Redis队列与子进程worker三层异步流水线【免费下载链接】freightFreight is a service which aims to make application deployments better.项目地址: https://gitcode.com/gh_mirrors/fr/freightFreight 是一个开源持续部署CD服务目标是让应用部署变得更简单、更可控。它的核心架构是一条三层异步流水线Flask API 负责接收部署请求Redis 队列负责任务解耦与调度子进程 Worker 负责真正执行部署命令。理解这条流水线你就掌握了 Freight 90% 的源码逻辑。一图看懂三层异步部署流水线整个系统的信息流非常清晰用户/前端 │ POST /deploys/ (应用名 环境 版本 ref) ▼ ┌─────────────────────────┐ │ ① Flask REST API 层 │ 创建 Task/Deploy 记录状态: pending │ (freight/api/) │ 跑预检 checks发已入队通知 └───────────┬─────────────┘ │ 任务写入 RedisRQ 队列 ▼ ┌─────────────────────────┐ │ ② Redis 任务队列层 │ 4 条队列分流 │ (freight/queue.py) │ tasks / queue / notifications... └───────────┬─────────────┘ │ Worker 进程轮询取任务 ▼ ┌─────────────────────────┐ │ ③ 子进程 Worker 层 │ 每个部署再 fork 一个 │ (bin/worker → bin/run-task) │ 子进程跑真实命令 └───────────┬─────────────┘ │ 日志按 4KB 分块写入数据库 ▼ LogChunk 表 → API 流式输出 → 前端实时看日志 关键思想每一层都不互相阻塞。API 收到请求后立即返回 201部署在后台慢慢跑日志通过数据库中转API 和 Worker 彻底解耦。第一层Flask API 是部署请求的入口应用的入口在 freight/app.py它只做一件事——调用create_app()。真正干活的是 freight/config.py创建 Flask 应用挂载四个基础设施dbSQLAlchemy PostgreSQL、redisFlaskRedis、queueRQ 任务队列、apiREST 控制器前缀/api/0注册全部 REST 路由如/apps/、/deploys/、/deploys/app/env/number/log/等见configure_api()所有配置支持环境变量覆盖REDIS_URL、SQLALCHEMY_DATABASE_URI、GITHUB_TOKEN等并兼容 Docker 环境自动发现。一次部署请求的完整链路在 freight/api/deploy_index.py 中步骤做了什么防并发手段1. 鉴权从 session 或参数解析用户—2. 预检跑配置的 checks如 GitHub CI 是否通过force可跳过3. 建记录创建TaskpendingDeploy带环境序号Redis 分布式锁deploy:create:app_id4. 发通知推送任务已入队事件给 Slack 等—5. 返回201 部署详情不等待执行—值得注意创建部署时还会用 Redis 锁repo:update:repo_id保护代码库的 clone/update避免多个请求同时git fetch互相踩踏。第二层Redis 队列如何分流与调度队列封装在 freight/queue.py底层是 Redis RQRedis Queue。freight/config.py 中定义了 4 条队列和路由规则队列承载的任务用途freight.default未指定路由的任务兜底freight.tasksexecute_task真正执行部署freight.queuecheck_queue每秒轮询派发待执行任务freight.notificationssend_pending_notifications每秒轮询补发通知这里藏着一个巧妙的二级派发机制源码见 freight/jobs/check_queue.pyAPI 建好 Task 后并不直接执行而是先把任务交给定时任务check_queueQUEUE_SCHEDULE中配置为每秒 1 次check_queue按应用 环境分组检查如果该环境已有 in_progress 的部署就跳过Redis 锁deploycheck:app-env保护空闲时取出最早的 pending 任务标记为 in_progress然后向freight.tasks队列推送execute_deploy任务。这带来两个实际好处天然实现了同一环境串行部署staging 和 production 互不干扰以及任务积压时自动排队。调度器同样跑在 Redis 上Scheduler用 Redis 的 ZSetrq:schedule记录下次触发时间多进程间通过NX语义避免重复触发。第三层子进程 Worker 与实时日志上报Worker 进程由 bin/worker 启动核心逻辑只有几行multiprocessing.Process按-n参数 fork 出 N 个 RQ Worker外加 1 个 Scheduler 进程。每个 Worker 调用queue.get_worker()监听全部 4 条队列并进入worker.work()循环。当execute_deploy源码见 freight/jobs/execute_task.py被 Worker 取出后加锁去重lock(redis, deploy:id)防止同一部署被两个 Worker 重复执行并把状态推进到 in_progressspawn 子进程TaskRunner.start()用subprocess.Popen启动bin/run-task task_idstdout/stderr 合并进管道真正干活bin/run-task 这个子进程内完成完整部署——轮询等待 checks 通过 → 用 Redis 锁保护 clone/update 仓库 → 把目标 sha 检出到临时工作区→ 调用 provider默认ShellProvider见 freight/providers/shell.py执行部署命令 → 更新任务状态 → 清理工作区超时兜底TaskRunner.wait()每 0.1 秒检查一次总超时 / 读超时 / 是否被取消触发后先terminate()再在 10 秒内kill()并把失败原因写入日志和数据库。日志是怎么做到实时可见的关键在LogReporter——一个守护线程它以 4KB 为块从子进程 stdout 读取输出每个块立即 commit 到LogChunk表注释原话we commit immediately to ensure the API can stream logs。随后前端轮询/deploys/app/env/number/log/源码见 freight/api/deploy_log.py按offset增量拉取新日志块还支持offset-1模拟tail -f。API 层和 Worker 层通过数据库里的日志块完成交接互不依赖。通知与状态闭环部署的每个状态变化queued / started / finished都会经过send_task_notificationsfreight/notifiers/utils.pyfinished 事件即时发送——因为不会有后续事件直接调用 notifier其他事件先进队列——写入freight.notifications由每秒运行的send_pending_notifications兜底补发保证通知不丢。内置的 notifier 覆盖 Slack、Sentry、Webhook、Datadog、GitHub Status源码见 freight/notifiers/ 目录这也是它和 CI 系统对接的入口。新手源码导航清单想理解什么看这里应用如何装配Flask DB Redis 队列freight/config.pyREST 路由与部署创建逻辑freight/api/目录Redis 队列与调度器实现freight/queue.py任务如何被派发执行freight/jobs/check_queue.py、freight/jobs/execute_task.py部署命令实际怎么跑bin/run-task、freight/providers/shell.pyWorker 进程如何启动bin/worker数据模型Task/Deploy/LogChunkfreight/models/目录数据库迁移历史了解架构演进migrations/versions/总结Freight 用最小代价实现了企业级部署流水线的三个核心能力快速响应的 API——请求秒回部署异步化Flask REST可靠的排队与调度——同环境串行、跨环境并行Redis RQ 分布式锁可控的执行与可观测性——每个部署一个独立子进程超时/取消/日志全兜底subprocess 日志分块入库。这条Flask → Redis → 子进程的三层流水线模式对任何想自建 CI/CD 系统的工程师都是很好的参考范本。【免费下载链接】freightFreight is a service which aims to make application deployments better.项目地址: https://gitcode.com/gh_mirrors/fr/freight创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Freight核心架构解析Flask API、Redis队列与子进程worker三层异步流水线【免费下载链接】freightFreight is a service which aims to make application deployments better.项目地址: https://gitcode.com/gh_mirrors/fr/freightFreight 是一个开源持续部署CD服务目标是让应用部署变得更简单、更可控。它的核心架构是一条三层异步流水线Flask API 负责接收部署请求Redis 队列负责任务解耦与调度子进程 Worker 负责真正执行部署命令。理解这条流水线你就掌握了 Freight 90% 的源码逻辑。一图看懂三层异步部署流水线整个系统的信息流非常清晰用户/前端 │ POST /deploys/ (应用名 环境 版本 ref) ▼ ┌─────────────────────────┐ │ ① Flask REST API 层 │ 创建 Task/Deploy 记录状态: pending │ (freight/api/) │ 跑预检 checks发已入队通知 └───────────┬─────────────┘ │ 任务写入 RedisRQ 队列 ▼ ┌─────────────────────────┐ │ ② Redis 任务队列层 │ 4 条队列分流 │ (freight/queue.py) │ tasks / queue / notifications... └───────────┬─────────────┘ │ Worker 进程轮询取任务 ▼ ┌─────────────────────────┐ │ ③ 子进程 Worker 层 │ 每个部署再 fork 一个 │ (bin/worker → bin/run-task) │ 子进程跑真实命令 └───────────┬─────────────┘ │ 日志按 4KB 分块写入数据库 ▼ LogChunk 表 → API 流式输出 → 前端实时看日志 关键思想每一层都不互相阻塞。API 收到请求后立即返回 201部署在后台慢慢跑日志通过数据库中转API 和 Worker 彻底解耦。第一层Flask API 是部署请求的入口应用的入口在 freight/app.py它只做一件事——调用create_app()。真正干活的是 freight/config.py创建 Flask 应用挂载四个基础设施dbSQLAlchemy PostgreSQL、redisFlaskRedis、queueRQ 任务队列、apiREST 控制器前缀/api/0注册全部 REST 路由如/apps/、/deploys/、/deploys/app/env/number/log/等见configure_api()所有配置支持环境变量覆盖REDIS_URL、SQLALCHEMY_DATABASE_URI、GITHUB_TOKEN等并兼容 Docker 环境自动发现。一次部署请求的完整链路在 freight/api/deploy_index.py 中步骤做了什么防并发手段1. 鉴权从 session 或参数解析用户—2. 预检跑配置的 checks如 GitHub CI 是否通过force可跳过3. 建记录创建TaskpendingDeploy带环境序号Redis 分布式锁deploy:create:app_id4. 发通知推送任务已入队事件给 Slack 等—5. 返回201 部署详情不等待执行—值得注意创建部署时还会用 Redis 锁repo:update:repo_id保护代码库的 clone/update避免多个请求同时git fetch互相踩踏。第二层Redis 队列如何分流与调度队列封装在 freight/queue.py底层是 Redis RQRedis Queue。freight/config.py 中定义了 4 条队列和路由规则队列承载的任务用途freight.default未指定路由的任务兜底freight.tasksexecute_task真正执行部署freight.queuecheck_queue每秒轮询派发待执行任务freight.notificationssend_pending_notifications每秒轮询补发通知这里藏着一个巧妙的二级派发机制源码见 freight/jobs/check_queue.pyAPI 建好 Task 后并不直接执行而是先把任务交给定时任务check_queueQUEUE_SCHEDULE中配置为每秒 1 次check_queue按应用 环境分组检查如果该环境已有 in_progress 的部署就跳过Redis 锁deploycheck:app-env保护空闲时取出最早的 pending 任务标记为 in_progress然后向freight.tasks队列推送execute_deploy任务。这带来两个实际好处天然实现了同一环境串行部署staging 和 production 互不干扰以及任务积压时自动排队。调度器同样跑在 Redis 上Scheduler用 Redis 的 ZSetrq:schedule记录下次触发时间多进程间通过NX语义避免重复触发。第三层子进程 Worker 与实时日志上报Worker 进程由 bin/worker 启动核心逻辑只有几行multiprocessing.Process按-n参数 fork 出 N 个 RQ Worker外加 1 个 Scheduler 进程。每个 Worker 调用queue.get_worker()监听全部 4 条队列并进入worker.work()循环。当execute_deploy源码见 freight/jobs/execute_task.py被 Worker 取出后加锁去重lock(redis, deploy:id)防止同一部署被两个 Worker 重复执行并把状态推进到 in_progressspawn 子进程TaskRunner.start()用subprocess.Popen启动bin/run-task task_idstdout/stderr 合并进管道真正干活bin/run-task 这个子进程内完成完整部署——轮询等待 checks 通过 → 用 Redis 锁保护 clone/update 仓库 → 把目标 sha 检出到临时工作区→ 调用 provider默认ShellProvider见 freight/providers/shell.py执行部署命令 → 更新任务状态 → 清理工作区超时兜底TaskRunner.wait()每 0.1 秒检查一次总超时 / 读超时 / 是否被取消触发后先terminate()再在 10 秒内kill()并把失败原因写入日志和数据库。日志是怎么做到实时可见的关键在LogReporter——一个守护线程它以 4KB 为块从子进程 stdout 读取输出每个块立即 commit 到LogChunk表注释原话we commit immediately to ensure the API can stream logs。随后前端轮询/deploys/app/env/number/log/源码见 freight/api/deploy_log.py按offset增量拉取新日志块还支持offset-1模拟tail -f。API 层和 Worker 层通过数据库里的日志块完成交接互不依赖。通知与状态闭环部署的每个状态变化queued / started / finished都会经过send_task_notificationsfreight/notifiers/utils.pyfinished 事件即时发送——因为不会有后续事件直接调用 notifier其他事件先进队列——写入freight.notifications由每秒运行的send_pending_notifications兜底补发保证通知不丢。内置的 notifier 覆盖 Slack、Sentry、Webhook、Datadog、GitHub Status源码见 freight/notifiers/ 目录这也是它和 CI 系统对接的入口。新手源码导航清单想理解什么看这里应用如何装配Flask DB Redis 队列freight/config.pyREST 路由与部署创建逻辑freight/api/目录Redis 队列与调度器实现freight/queue.py任务如何被派发执行freight/jobs/check_queue.py、freight/jobs/execute_task.py部署命令实际怎么跑bin/run-task、freight/providers/shell.pyWorker 进程如何启动bin/worker数据模型Task/Deploy/LogChunkfreight/models/目录数据库迁移历史了解架构演进migrations/versions/总结Freight 用最小代价实现了企业级部署流水线的三个核心能力快速响应的 API——请求秒回部署异步化Flask REST可靠的排队与调度——同环境串行、跨环境并行Redis RQ 分布式锁可控的执行与可观测性——每个部署一个独立子进程超时/取消/日志全兜底subprocess 日志分块入库。这条Flask → Redis → 子进程的三层流水线模式对任何想自建 CI/CD 系统的工程师都是很好的参考范本。【免费下载链接】freightFreight is a service which aims to make application deployments better.项目地址: https://gitcode.com/gh_mirrors/fr/freight创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
