企业官网建设流程全解析

1. 这次要装的是啥：青龙面板和Ninja到底各管哪一块

先把要干的事儿捋清楚。服务器上的“Jd代挂”，核心就是让你的一台云服务器24小时在线运行脚本，自动完成签到、做任务这类重复操作。而要做到这一点，你需要在服务器上装一套调度系统，再把账号登录态接进来。这次主角是两个东西：青龙面板和Ninja。

青龙面板是一个开源的多语言定时任务管理面板，支持Python、JavaScript、Shell三种脚本语言。你把脚本文件或者脚本仓库丢进去，设定好cron表达式，它到点自动执行，跑完以后保留日志、记录结果，同时还能管理环境变量、安装脚本依赖、推送运行通知。它本质上是一个调度中心，只不过为脚本运行场景优化得很到位，早些年用crontab裸跑脚本的都知道，一旦脚本数量多起来，日志、依赖、定时规则全得自己维护，非常折腾，青龙就是把这些痛点收敛到一个Web界面上。

Ninja的定位完全不同。它更像一个登录授权中转站，负责把账号的登录cookie获取流程做成一个可视化的网页。你在浏览器里打开Ninja页面，扫码确认登录，它就会把cookie整理好，转而交给青龙面板去使用。它不是为了让你在页面上手动点点点，而是解决“登录态怎么来”的问题。没有Ninja的话，你也能手动从浏览器开发者工具里抠cookie，只是既繁琐又容易失效，Ninja把这步工作量压缩到一次扫码。

这套方案最终呈现出来的效果是：服务器上跑着青龙面板，面板里挂着定时任务，脚本定时读取账号cookie，去完成一系列自动操作，再把结果写进日志或推送到你的消息工具。Ninja只出现在最开始获取cookie那一步，以及后续cookie过期需要重新扫码时。把这两个工具的职责边界搞清楚，后面配置起来就不会晕。

这篇教程先解决“跑起来”的问题，也就是从一台空服务器开始，装好Docker、部署青龙2.8、装好Ninja、完成第一次授权登录。至于脚本仓库的拉取、依赖配置、任务定时、多账号管理这些内容，放在下一篇聊。

2. 服务器选型与账号安全基本功

2.1 服务器配置选什么才好用

装这套环境不需要很高配置，但也不建议买最便宜的乞丐款。青龙面板本身吃资源不多，真正吃资源的是脚本执行。Jd脚本这类任务通常几分钟跑一轮，高频的时候会在短时间内同时创建多个进程，如果服务器内存只有512M，很容易触发OOM，容器直接被系统杀掉。我自己的经验，流畅起步配置是1核2G内存，硬盘40G就足够。如果你预算允许，直接上2核4G，跑起来会从容很多，尤其是后续要加多个账号、多个依赖的时候。

系统镜像首选Debian 11或Debian 12，其次Ubuntu 20.04以上的版本。这两个系统用的人最多，出问题随便搜都能搜到答案。CentOS 7年代久远，不少源已经不可用，不建议新部署再踩那个坑。你登录云服务器管理后台，把系统重装成Debian 12，然后等机器起来就行。

磁盘方面有个细节容易忽略：有些便宜套餐默认系统盘只有20G，而Docker镜像、脚本依赖、容器日志会慢慢把磁盘吃满。建议买的时候直接选40G甚至50G的系统盘，或者看清套餐里数据盘的大小。磁盘满了以后，面板页面会变得非常卡，容器日志写不进去，任务报错也不明显，排查起来很头大。

2.2 服务器安全初始化：别裸奔

服务器开机第一件事，不要急着安装软件，先把基础安全做了。我这里说的不是要你去配置多复杂的防火墙策略，而是几个最基础的动作。

如果你习惯用密码登录，先把密码换成一个足够长的随机密码，这个密码不要和任何其他网站重复。如果你用的是云厂商的密钥登录，那就保持现状。装完环境以后，建议关闭直接root登录、改用普通用户加sudo的方式，不过对于个人练手环境，root直接操作问题也不大，自己心里有数就行。

还有端口问题。青龙面板默认要走5700端口，Ninja走5701端口。你需要去云服务器的安全组/防火墙里放通这两个TCP端口，否则浏览器从外部访问不通。很多新手第一步栽在“容器明明启动了，页面打不开”，十有八九就是安全组没放行。放行的时候注意，不要为了省事直接放行0.0.0.0/0的全部端口，只放行5700、5701，以及你SSH需要的22端口就够了。

2.3 登录服务器与基础命令准备

用终端SSH登录服务器。Windows用户可以用系统自带的终端或者常见SSH客户端，Mac和Linux直接终端输入：

ssh root@你的服务器IP

登录以后先做一轮源更新：

apt update && apt upgrade -y

这一步会把系统自带的软件包索引刷新到最新，避免后续安装的时候遇到版本过旧的问题。执行过程可能需要一点时间，取决于服务器带宽。更新完以后，顺手把时间同步确认一下，确保服务器时区是Asia/Shanghai，不然定时任务跑出来的时间点跟你预期的对不上。

timedatectl set-timezone Asia/Shanghai

这些做完，服务器基础状态就算准备好了。

3. 安装Docker：为什么选容器方式部署

3.1 直接用Docker的核心理由

青龙面板支持多种安装方式，裸机运行脚本、直接在服务器上用Python拉项目跑，理论上都行。但实际部署推荐用Docker，原因很直接：隔离环境、方便卸载、升级不污染系统。

举个例子，青龙面板要执行Python脚本，脚本又依赖一堆第三方库，这些库直接装系统Python里很可能跟系统自带的包冲突。而容器把面板、脚本执行环境、依赖全部封装在一起，你在宿主机上只看到一个镜像、一个容器，随便折腾坏了直接删掉容器重新拉一个，五分钟恢复原状。这种可恢复性，对后续反复测试脚本非常有价值。

另外，脚本领域经常要装新依赖，青龙面板本身提供了依赖管理功能，可以在容器内自动安装。Docker方式下你不需要关心宿主机里Python版本是谁，所有依赖都装在容器内部，互不干扰。

3.2 Docker安装步骤

Debian 12上安装Docker，最稳的办法是使用官方脚本。先执行：

curl -fsSL https://get.docker.com | bash

这个过程会自动添加Docker官方源并安装完整组件。如果因为网络原因下载很慢或者失败，可以换成国内镜像源的方式安装，但那种办法通常需要手动添加apt源，操作步骤多一点。实际测试下来，官方脚本在多数云服务器上都能顺利完成，只要你的服务器能正常访问外网。

安装完成后验证一下：

docker version

能看到Client和Server两段版本信息，说明安装成功。接着配置镜像加速，因为后续拉取镜像时如果直接从Docker官方仓库拉，有些地区速度比较慢。在配置文件里写入镜像加速地址：

vim /etc/docker/daemon.json

内容如下：

{ "registry-mirrors": ["https://docker.m.daocloud.io"] }

保存后重启Docker服务：

systemctl restart docker

这里要提醒一下，镜像加速地址只是可选项。如果你的服务器网络本身很快，不配置也不影响。配置错了反而可能导致Docker启动失败，改完以后用上面那条systemctl命令重启，再看看docker version是否正常。

3.3 Docker Compose是否需要单独装

青龙面板部署只需要docker run命令就够，不强制用Compose。但是如果你想后续把青龙、Ninja、其他辅助容器统一管理，写一个docker-compose.yml会更优雅。Debian 12上Docker官方安装包通常不带Compose V2插件，需要手动确认。

docker compose version

如果有输出，说明自带Compose插件。如果没有，可以用apt安装：

apt install docker-compose-plugin

装不装都行，不影响你读完这篇教程。我自己的习惯是，单容器部署用docker run，多容器搭配服务端环境用Compose，看场景灵活切换。

4. 部署青龙面板2.8版本

4.1 拉取镜像与创建容器

青龙面板的官方镜像名称是whyour/qinglong，2.8版本对应的标签是2.8。直接拉取：

docker pull whyour/qinglong:2.8

拉好以后，创建数据目录并启动容器。先建目录：

mkdir -p /data/qinglong

然后执行启动命令：

docker run -dit \ -v /data/qinglong:/ql/data \ -p 5700:5700 \ --name qinglong \ --hostname qinglong \ --restart unless-stopped \ whyour/qinglong:2.8

逐项解释一下：

• -v /data/qinglong:/ql/data：把宿主机的数据目录挂载到容器内部，面板配置、脚本、日志都放在这里面，将来升级容器数据不丢。
• -p 5700:5700：把容器的5700端口映射到服务器上，浏览器通过http://服务器IP:5700访问。
• --name qinglong：给容器命名，后续查看日志、停止、删除都用这个名字。
• --restart unless-stopped：服务器重启后自动拉起容器，这是“24小时在线”的关键。

这里有个2.8版本特有的细节，数据目录挂载点从老版的/ql换成了/ql/data。如果你在网上搜到老教程，里面写的是-v /data/qinglong:/ql，那就容易出问题。2.8以后不要挂整个/ql，只挂/ql/data，否则容器启动时会因为权限问题反复报错。

启动过程只需要几秒钟。跑完以后看一下状态：

docker ps

如果STATUS列显示Up状态，说明容器起来了。

4.2 首次访问与面板初始化

浏览器打开http://服务器IP:5700，第一次访问会进入初始化页面。这里要填的是通知方式设置，你可以先跳过，后续在面板里再补。接着设置面板登录账号和密码，密码设置稍微复杂一点，至少包含字母和数字，不要用太短的弱密码。

设置完成后进入登录页，输入刚才的账号密码登录。进去以后你会看到面板的主界面，左侧有定时任务、脚本管理、环境变量、依赖管理等菜单，右上角可以查看系统运行状态。到了这一步，青龙面板已经安装完成了。

登录以后建议立刻去“系统设置”里确认一下容器数据卷是否正常挂载，界面一般会显示配置文件路径。你不用太纠结里面的参数，保持默认即可，唯一建议改的是登录安全相关选项，比如开启登录失败次数限制，避免面板暴露在公网时被暴力尝试。

4.3 常见容器启动失败的排查

如果你发现容器启动以后一直重启，或者页面打不开，先别急着重新装。几个最典型的原因，按顺序排查。

端口被占用。检查5700有没有被其他进程占：

ss -lntp | grep 5700

如果有其他进程占着端口，青龙容器会一直重启。把占用进程清掉或者换一个映射端口。

挂载目录权限异常。用docker logs qinglong查看日志，看到类似“Permission denied”的错误，多半是宿主机目录权限不对。执行：

chmod -R 755 /data/qinglong

再重启容器。

内存不足。1G内存的服务器如果同时跑了其他大进程，容器很容易被杀掉。用free -m查看内存余量，如果只剩几十兆，建议停掉其他进程，或者扩容服务器。

排查的时候，docker logs永远是第一手段，别靠猜。

5. 安装Ninja并完成首次登录授权

5.1 先理解Ninja的部署形态

Ninja的部署方式有几种，有的是一键脚本直接装在宿主机上，有的是用Docker容器跑。推荐Docker方式，理由跟青龙一样，干净、易删、不污染系统。Ninja部署以后会开放一个HTTP页面，你在页面上扫码完成授权，它会将cookie推送给青龙面板。

Ninja和青龙之间要建立连接关系。青龙面板需要提供一个token给Ninja，Ninja拿到这个token以后才能把cookie写入青龙的环境变量或配置文件里。不同版本的青龙对接方式有一点点差异，2.8版本下主要是获取一个授权token，然后Ninja通过API写入。这一串配置不难，但顺序错了会走很多弯路。

5.2 Docker方式部署Ninja

先创建数据目录：

mkdir -p /data/ninja

然后运行：

docker run -dit \ -v /data/ninja:/ninja/data \ -p 5701:80 \ --name ninja \ --restart unless-stopped \ --hostname ninja \ 你的Ninja镜像地址:latest

这里的“你的Ninja镜像地址”需要替换成你实际使用的镜像名称。Ninja镜像来源在不同时间、不同社区里会不一样，建议以你实际拿到的镜像名为准，不要照抄网上未知来源的地址。

这里要说一句经验：Ninja镜像来源比较杂，我在实际部署中倾向于自己拉取仓库源码构建镜像，虽然多花几分钟编译时间，但至少代码是明明白白的，用起来心里有底。如果你不想折腾构建，直接用社区编译好的镜像也可以，但一定要确认来源可信任，不要随便填充一个看不懂的镜像地址。

启动完成后，浏览器打开http://服务器IP:5701。看到Ninja界面说明部署成功。先别急着扫码，下一步要先和青龙建立连接。

5.3 绑定青龙面板

打开青龙面板，进入“系统设置”，找到“安全设置”相关的选项，查看当前面板的token或者重新生成一个token。把这个token复制出来，然后在Ninja页面里找到绑定配置的入口，填入青龙面板地址（格式为http://服务器IP:5700）以及刚才复制的token。保存后Ninja会测试连接，如果显示连接成功，说明两个服务已经打通。

连接成功以后，你在Ninja页面扫码完成登录，账号cookie就会自动写入青龙面板。这一步完成以后，你可以在青龙面板的“环境变量”菜单里看到新增的cookie相关变量。看到变量就说明整条链路已经通了。

5.4 关于扫描设备和cookie的几个提醒

扫码的时候注意要用你自己持有的账号去扫，不要拿别人的账号乱试。cookie会暴露账号的部分身份信息，存放时务必确认服务器只归你本人管理。定期重新扫码也正常，cookie过期后任务会报错，重新去Ninja页面扫一下就好了，不用重装任何东西。

Ninja界面如果放到公网，建议加一层访问限制。最简单的做法是在服务器防火墙或安全组里限制5701端口的来源IP，只允许你自己家里的出口IP访问，其他来源一律拒绝。这样即使Ninja页面被发现，别人也无法打开你环境里的授权页面。

6. 第一阶段的验收清单与典型问题处理

6.1 验收三件套：容器、面板、Ninja

部署到这里，你需要确认三个东西全部正常才算第一阶段合格。

第一，容器状态。执行docker ps，确认qinglong和ninja两个容器都在Up状态，没有反复重启。第二，面板访问。浏览器打开青龙页面，能正常登录、能看到主界面、能看到容器内的数据目录信息。第三，Ninja授权连通。打开Ninja页面，绑定青龙配置是成功的，扫码能正常获取cookie，并且青龙环境变量区能看到对应数据。

三件事都通过，你的“服务器代挂”基础设施就算搭好了。此时的服务器已经不再是空壳，而是有一套能跑脚本、能管理登录态的独立环境。

6.2 部署阶段的高频报错速查

部署过程中很多人会把时间消耗在几个重复问题上。我直接列成表格，对照处理：

这里面的核心思路是：先看日志，再动配置。很多新手一遇到问题就删容器重装，其实大部分问题用docker logs qinglong、docker logs ninja两行命令就能看出端倪。

6.3 个人实践中的几个关键习惯

部署这套环境踩过几次坑之后，我养成了一些习惯，分享出来供参考。

第一，所有自定义配置尽量通过面板界面操作，不要直接改容器内文件。青龙面板和Ninja每次升级可能会调整内部文件结构，直接改容器内文件，下次容器重建配置就丢了。数据目录挂载出来以后，有必要备份的只有/data/qinglong下的config目录，其他临时文件丢了也不心疼。

第二，服务器上只保留必要的容器。青龙、Ninja这种常驻容器没问题，但用完就扔的临时工具容器不要随手启动一堆，占内存不说，日志还会悄悄吃满磁盘。建议养成定期docker system prune -f清理无用镜像和容器的习惯。

第三，安全问题时刻挂在心上。青龙面板和Ninja都是暴露在公网的Web服务，登录密码务必改成高强度随机密码，Ninja的端口访问加上IP白名单。不要觉得“我的账号又不值钱”就不设防，服务器一旦被入侵，被拿去干什么都不是你能控制的。

6.4 下一步：《（二）》会做什么

这次教程到这里为止，你已经拥有了一个正常运行的青龙面板和一个能完成登录授权的Ninja环境。但是“安装”不等于“能用起来”，真正让这套环境产生价值的是后续的脚本配置：拉取一个可用的脚本仓库，配置好依赖，再设定好自动执行的时间规则，让任务自己跑起来。到那时你才会真正体会到代挂的省心之处。

下一篇我会继续写：脚本仓库怎么拉、依赖怎么装、定时规则怎么设定、多账号怎么批量加入、任务运行日志怎么看，以及cookie过期以后的整套维护方案。你可以先把这篇文章的部署步骤跑通，把服务器上的两个容器稳定运行几天，再进入下一部分。