简介这份资源是一套基于Python与Django框架搭建的运维平台源码面向具备Python基础、希望了解Web开发与自动化运维实践的开发者与IT运维人员。项目采用前后端不分离架构将主机管理、服务监控、日志查看、任务调度、权限控制、资源统计、脚本执行、故障告警、审计追踪与知识库等功能整合在同一Django工程中适合作为学习Django项目结构与运维场景落地的参考案例。压缩包共164个文件以39个py源码、38个js脚本、23个css样式、11个html模板及18个png图片为主另含字体、日志与说明文档等整体约3.63MB目录结构完整便于按模块阅读与运行调试。目前已有2714人学习下载。通过阅读模型定义、视图函数与模板文件读者可理解Django后台管理与前端页面的协作方式并借鉴远程命令执行、定时任务与告警通知的实现思路为二次开发或课程设计提供可复用的代码基础。1. 从一台跳板机到一套平台这套 Django 运维系统到底解决了什么很多团队早期的运维状态是这样的几台机器靠 SSH 跳板机登录发布靠手敲命令配置散落在各人的笔记里出问题先问“谁最后动过”。这套基于 Django 的运维平台本质上是把这类零散操作收拢到一个 Web 入口里——资产、发布、任务、权限都进数据库操作留痕重复动作脚本化。它适合两类人一是手里管着十几到上百台机器、被手工操作拖住的中小团队运维二是想拿一个真实可跑的 Django 项目练手把 Python 开发-DevOps 工具这条线走通的开发者。下面按“能干什么、怎么跑起来、坑在哪、怎么改”拆开讲。2. 拆开这套 Django 运维平台模块划分与技术选型2.1 它由哪些功能模块组成从项目结构看这类平台通常围绕几个核心域展开每个域对应一个 Django app职责边界清楚方便后续按需裁剪。模块职责典型数据表用户与权限登录、角色、菜单权限用户表、角色表、权限关联表资产管理主机、分组、标签、凭据主机表、主机组表、凭据表任务执行批量命令、脚本下发、结果回传任务表、任务日志表发布部署应用、版本、发布单、回滚应用表、发布记录表审计日志操作留痕、登录记录操作日志表资产模块是整个平台的地基。主机信息一般包含 IP、端口、系统类型、所属业务线、SSH 凭据引用凭据本身加密存储不直接明文落库。任务执行模块依赖资产模块选出的目标主机列表发布模块又依赖任务模块的远程执行能力所以模块之间有明确的依赖顺序改的时候别把底层接口随意动掉。2.2 为什么是 Django 而不是 Flask 或 FastAPI选 Django 做运维平台核心原因是它自带的东西刚好对上这类系统的需求。运维平台天然需要用户体系、后台管理、ORM、表单校验、权限控制这些 Django 开箱就有用 Flask 得自己拼一堆扩展用 FastAPI 则要额外补 admin 和权限层。Django 的 admin 后台还能直接当资产录入的临时界面用前期省掉不少前端工作量。代价也要说清楚Django 偏重同步模型在高并发任务下发场景下不如异步框架灵活。所以常见做法是把耗时的远程执行丢给 Celery 之类的任务队列Web 层只负责接收请求和展示结果避免请求线程被 SSH 连接阻塞。这个分工是这套平台能不能扛住批量操作的关键。2.3 远程执行这条链路怎么走运维平台和普通 Web 系统最大的区别是它要真的去操作远程机器。这条链路通常是Web 请求 → 生成任务记录 → 投递到队列 → worker 取出任务 → 通过 SSH 库连接目标主机 → 执行命令 → 回传结果 → 更新任务状态。远程连接常见用 paramiko也有用 fabric 封装的。paramiko 更底层控制粒度细适合需要自己管理连接池和超时的场景。下面是一段典型的执行封装重点看连接参数和异常处理import paramiko def run_command(host, port, username, password, command, timeout30): # 创建 SSH 客户端禁用自动添加未知主机密钥避免首次连接卡住 client paramiko.SSHClient() client.set_missing_host_key_policy(paramiko.AutoAddPolicy()) try: # timeout 控制连接建立时间banner_timeout 控制握手阶段等待 client.connect( hostnamehost, portport, usernameusername, passwordpassword, timeouttimeout, banner_timeouttimeout, auth_timeouttimeout, ) # exec_command 返回三个流stdout/stderr 需要分别读取 stdin, stdout, stderr client.exec_command(command, timeouttimeout) out stdout.read().decode(utf-8, errorsignore) err stderr.read().decode(utf-8, errorsignore) # 退出码是判断命令成功与否的可靠依据别只看输出 code stdout.channel.recv_exit_status() return {code: code, stdout: out, stderr: err} except Exception as e: return {code: -1, stdout: , stderr: str(e)} finally: client.close()逻辑说明set_missing_host_key_policy设成自动添加是为了避免首次连接时交互式确认卡死 worker三个 timeout 参数分别管连接、握手、认证任何一个缺失都可能导致任务长时间挂起。recv_exit_status()必须在读取完输出后调用否则可能拿不到真实退出码。参数上timeout建议按命令类型区分普通查询 10 到 30 秒部署类命令可以放宽到 300 秒但一定要有上限否则一个卡死的连接会占住 worker。2.4 权限和审计为什么不能省运维平台握着所有机器的入口权限设计不到位等于把钥匙串挂在门上。常见做法是按角色划分普通用户只能看自己业务线的主机、只能执行预定义的安全命令管理员才能做批量操作和发布。命令层面还要做白名单或黑名单过滤像rm -rf、shutdown这类高危命令要么禁止要么强制二次确认。审计日志要记录谁、什么时候、在哪台机器、执行了什么、结果如何。这张表会随使用不断增长建议按时间分区或定期归档不然几个月后查询会明显变慢。日志本身也是排查问题的后悔药任务失败时先看日志里的 stderr 和退出码比盲目重试有效得多。3. 把平台跑起来环境、初始化与第一个任务3.1 环境准备与依赖安装这类项目一般要求 Python 3.8 以上数据库常见用 MySQL 或 PostgreSQL缓存和队列用 Redis。先把虚拟环境建好再装依赖避免污染系统 Python。# 创建并激活虚拟环境 python3 -m venv venv source venv/bin/activate # 安装项目依赖requirements.txt 里通常含 django、paramiko、celery、redis、pymysql pip install -r requirements.txt # 如果数据库驱动是 MySQL确认 pymysql 已装并在 __init__.py 里注册 python -c import pymysql; print(pymysql.__version__)参数说明虚拟环境目录名用venv是惯例方便.gitignore统一忽略。依赖安装失败时先看是不是某个包需要编译工具比如cryptography在部分系统上要装开发头文件。数据库驱动这块Django 默认不认 pymysql需要在项目包的__init__.py里加pymysql.install_as_MySQLdb()否则启动会报驱动找不到。3.2 数据库配置与迁移数据库连接写在 settings 里生产环境不要把密码硬编码进代码用环境变量读取。# settings.py 片段 import os DATABASES { default: { ENGINE: django.db.backends.mysql, NAME: os.environ.get(DB_NAME, ops_platform), USER: os.environ.get(DB_USER, ops), PASSWORD: os.environ.get(DB_PASSWORD, ), HOST: os.environ.get(DB_HOST, 127.0.0.1), PORT: os.environ.get(DB_PORT, 3306), OPTIONS: {charset: utf8mb4}, } }逻辑说明用os.environ.get读取配置本地开发给默认值线上通过环境变量注入避免密码进版本库。utf8mb4字符集是为了支持完整 Unicode主机备注里出现特殊字符时不会报错。配置改完执行迁移python manage.py makemigrations python manage.py migrate python manage.py createsuperuser迁移报错时优先看两点一是数据库是否已手动建好Django 不会自动建库二是已有表结构和迁移记录是否冲突必要时先备份再处理。3.3 启动服务与队列Web 服务和任务 worker 要分开起这是这套平台能正常执行远程任务的前提。# 启动 Django 开发服务生产环境换成 gunicorn 或 uwsgi python manage.py runserver 0.0.0.0:8000 # 另开一个终端启动 Celery worker负责实际执行远程任务 celery -A ops_platform worker -l info参数说明-A指定 Celery 应用所在模块要和项目里 Celery 实例的定义位置一致。-l info是日志级别排查任务不执行时先看 worker 终端有没有收到任务。如果任务一直停在“等待中”八成是 worker 没起或者 broker 地址配错先确认 Redis 能连通。3.4 录入第一台主机并执行命令平台跑起来后先在后台录入一台测试主机填 IP、端口、凭据然后到任务页面选它执行一条uptime。这一步能一次性验证资产、凭据、SSH 连接、任务队列四条链路是否都通。如果失败按顺序查凭据能不能手动 SSH 登录、目标机防火墙是否放行、worker 日志里有没有连接超时。第一次跑通之后再批量导入主机、配置业务分组节奏会顺很多。4. 避坑与排查那些让任务卡住和发布翻车的地方4.1 任务一直处于等待状态现象提交任务后状态不变worker 日志没有任何输出。原因通常是 Celery worker 没启动或者 broker 连接地址和 Web 端配置不一致。解决先确认 Redis 服务在跑再核对 settings 里 broker 的 host、port、db 编号两边必须完全一致worker 启动命令里的应用模块名也要和项目实际结构对上。4.2 SSH 连接超时或认证失败现象任务报连接超时或认证错误但手动 SSH 能登录。原因可能是凭据在数据库里存的是加密值解密环节出错也可能是目标机对来源 IP 做了限制而平台服务器不在白名单里。解决先用平台所在机器手动 SSH 一次目标机排除网络和白名单问题再检查凭据加解密用的密钥是否和录入时一致密钥换过会导致旧凭据全部解不开。4.3 批量任务把 worker 打满现象一次选了几十台机器执行前面几台正常后面全部超时。原因是 worker 并发数有限每个任务又占着一个 SSH 连接连接不释放就会排队。解决给任务加并发上限或者把大批量拆成小批次投递同时确认client.close()在 finally 里执行连接泄漏是这类问题的常见根因。4.4 发布后服务没起来但平台显示成功现象发布任务返回成功实际服务没启动。原因是脚本只判断了命令退出码没校验服务真实状态。解决发布脚本末尾加健康检查比如curl本地端口或查进程把检查结果作为任务成败依据而不是只看命令有没有报错。4.5 审计日志表越来越大现象平台用几个月后日志查询明显变慢。原因是操作日志只增不减。解决按月份归档历史日志或者给日志表按时间加索引并定期清理查询时强制带时间范围避免全表扫描。5. 进阶改造把平台从能用推到好用平台跑通只是起点真正拉开差距的是几个细节改造。第一是命令白名单把允许执行的命令做成可配置表普通用户只能选白名单内的命令管理员才能自由输入这样既安全又不影响日常效率。第二是任务结果的结构化别只存一大段文本把退出码、耗时、目标主机拆成独立字段后续做统计和告警才有数据基础。第三是发布回滚。发布单要记录上一版本回滚时直接切回旧版本而不是重新走一遍发布流程。我一般会在发布记录表里存版本包路径和发布时间回滚就是一次指向旧路径的重新部署。第四是连接复用高频任务场景下每次新建 SSH 连接开销不小可以用连接池按主机维度缓存连接但要注意连接失效检测否则会拿到已经断开的连接。验证改造是否有效有个简单办法拿十台测试机跑一轮批量命令记录总耗时和失败率改造前后对比。如果失败率没降、耗时没变说明改的地方不是瓶颈。最后说个习惯我每次动任务执行或发布相关的代码都会先在测试环境用一台机器完整走一遍录入、执行、回滚确认链路通了再上生产。这套流程帮我挡掉过好几次“改一行崩一片”的情况。希望帮到你。本文还有配套的精品资源点击获取