简介：Azkaban Solo Server 0.1.0-SNAPSHOT 的已编译单机版分发包，面向需要快速搭建工作流调度环境的小型团队、个人开发者及大数据作业调度初学者，省去从源码编译和手工拼装组件的麻烦。资源包约42.28MB，采用tar.gz格式，解压后即得单机服务端目录；上游文件清单显示文件总数为0、类型明细暂无数据，具体文件构成以压缩包内实际内容为准。目前已有260人学习下载。其价值在于提供一套可直接运行的单机调度环境，Web服务、工作流执行器与内嵌H2数据库集中部署，便于创建项目、定义Shell/Java/Hadoop等作业、按依赖关系编排工作流，并通过定时调度与日志监控观察任务执行状态，适合学习Azkaban的作业组织方式和轻量调度流程。需注意SNAPSHOT版本稳定性有限，生产环境宜选用稳定版或集群部署。
1. 先确认：这个 SNAPSHOT 包并不等于解压即用
第一次拿到azkaban-solo-server-0.1.0-SNAPSHOT.tar.gz的人，多半会以为它是个解压就能跑的包：名字里带 solo，听上去像是把 azkaban 任务调度那整套东西缩成了单机版。真上手才发现，SNAPSHOT 说明它是从源码构建出来的开发包，脚本名、默认账号、目录结构和网上流传的教程经常对不上，JDK 差一个大版本就无法启动。我在一台 2 核 4G 的测试机上装了三次：第一遍机器上默认 JDK 17，启动即退出；第二遍 H2 数据目录权限不对，登录后建项目直接报错；第三遍才发现启动脚本根本不叫azkaban-solo-start.sh。这套环境适合在本地或小规模测试环境里跑通任务调度、验证 flow 编排，不适合原样搬到生产。下面按我实际装成功的顺序写一遍。
2. 环境准备：JDK、内存与目录先对齐
装 Azkaban 最费时间的常常是版本选错，安装本身倒不是主要难点。solo 包是把 web 服务和执行器合并到一个 JVM 进程里的形态，小巧但也挑剔：它对 JDK 的要求基本固定在 8，构建产物里那批依赖也是按 Java 8 的字节码编译的。尤其当你拿到的是0.1.0-SNAPSHOT这种从主干编出来的包，更要把“环境先行”当成硬性条件，别指望运行时报错能给你清晰提示。
2.1 版本对照：哪些必须匹配，哪些随包
先看我这份包的实际情况，下面这张表是我给自己团队留的对照，装之前扫一眼能省掉一半排查时间：
| 组件 | 建议版本 | 说明 |
|---|---|---|
| JDK | 1.8（8u200 以上） | 最低要求是硬性条件，9/11/17 均可能因模块化或反射限制启动失败 |
| Gradle | 不需要单独装 | 包是构建产物，只有自己重新编才用./gradlew |
| H2 | 随包，无需安装 | solo 内置嵌入式库，元数据落在本地文件 |
| MySQL | 可选，不建议在 solo 上用 | solo 形态官方推荐 H2，换库要改部署形态 |
| 内存 | ≥ 2G 可用 | 默认 JVM 参数偏小，任务多时容易 OOM |
| 磁盘 | ≥ 1G | 主要是 lib 目录和执行日志 |
很多人卡在 JDK 上，其实也可以通过查看包内lib/下 jar 的编译版本来反推。在没装 JDK 8 的机器上，我一般会先确认能不能切版本，切换不了就干脆单独下一份 JDK 8 解压到/usr/local/，JAVA_HOME指过去，别去动系统的 alternatives，避免影响机器上别的服务。
2.2 三条命令确认机器条件
装机前我习惯先跑这三条，数字不对就先解决环境，不要急着解压：
# 1. 确认 JDK 是 1.8，且不是 JRE java -version 2>&1 | head -3 javac -version # 2. 看可用内存，solo 进程默认堆不大，但机器太紧张会连解压都费劲 free -m # 3. 确认目标盘空间和挂载点，别装到 / 分区上把根盘撑爆 df -h /optjava -version输出里如果出现1.8.0_xxx才算通过，显示openjdk version "17"之类的，后面大概率会在启动时报UnsupportedClassVersionError或者类加载异常。javac那条是顺带确认装的是 JDK 而不是 JRE——有些精简镜像只带运行时，跑起来才发现编译不了 job 里调用的东西。free -m的 available 小于 1G 时，后面必须手动压-Xmx，否则任务一多就会进入反复垃圾回收。
2.3 解包与目录结构：路径里不要有空格和中文
我一般放在/opt/azkaban/下，用普通用户运行，不用 root 直接跑：
# 建目录并解包，注意 -C 后面是解包目标，不要写错成压缩包路径 sudo mkdir -p /opt/azkaban sudo tar -zxvf azkaban-solo-server-0.1.0-SNAPSHOT.tar.gz -C /opt/azkaban # 授权给运行用户，后面 H2 文件和日志都要往这个目录里写 sudo chown -R azkaban:azkaban /opt/azkaban cd /opt/azkaban/azkaban-solo-server-0.1.0-SNAPSHOT && ls -1解压后看到的目录大致是这样，几个目录的作用心里要有数，后面改配置全靠它：
| 目录/文件 | 用途 |
|---|---|
bin/ | 启停脚本，solo 包通常叫start-solo.sh/shutdown-solo.sh |
conf/ | azkaban.properties、azkaban-users.xml、log4j.properties |
lib/ | 全部依赖 jar，启动脚本靠它拼 classpath |
plugins/ | 作业类型插件目录，command 类型走内置实现，不在这里 |
web/ | 前端静态资源，web.resource.dir指的就是它 |
运行之后才会长出projects/、h2/、logs/、executions/这几个目录。第一次启动前它们是空的甚至不存在，这是正常的，别手动去建，权限容易对不上。
3. 配置环境：azkaban.properties 逐项过一遍
conf/azkaban.properties是这个包唯一的配置入口，solo 形态下 web 端口、数据库、项目目录、用户体系全部集中在这一个文件里。它的坑在于：网上很多教程贴的是多执行器形态的配置，键名有一半是 solo 不认的，照着抄完启动没报错，但行为完全不是你想的那样。下面这份是我改完能稳定跑的版本，只列会真正生效的键。
3.1 端口与 Web 容器：先改 jetty.port
# conf/azkaban.properties —— 服务标识，出现在页面左上角 azkaban.name=azkaban-solo azkaban.label=Local Solo Server # Web 容器：8081 是默认端口，和常见中间件冲突概率中等，冲突就换 jetty.port=8081 jetty.maxThreads=50 jetty.use.ssl=false # 静态资源与默认入口，保持相对路径即可 web.resource.dir=web/ azkaban.default.servlet.path=/indexjetty.port是第一个要确认的键，同一台机器上跑过其他 web 服务的话，8081 很可能被占用，症状是启动日志一路正常，最后抛一个BindException然后进程退出。jetty.maxThreads默认比较小，测试环境够用，但如果打算多个 flow 并行跑，可以调到 50 左右；再往上加收益不大，solo 的执行线程和 web 线程是抢同一份资源的。jetty.use.ssl=false保持关闭就行，开 SSL 要配 keystore，测试环境没必要折腾。
3.2 元数据库：继续用内置 H2，但把路径写固定
# 元数据库：solo 形态用内置 H2，无需外部安装 database.type=h2 # 相对路径是相对启动目录，脚本切了目录就会指到别处 h2.path=./h2 # 首次启动自动建表，后续可以改 false 防止误建 h2.create.tables=trueh2.path这一项我踩过坑：它按启动时的工作目录解析，如果你在别的路径下用绝对路径调bin/start-solo.sh，H2 文件就会在别的地方重新生成一份空库，表现是“登录进去项目全没了”。常见做法是把它写成绝对路径，比如/opt/azkaban/data/h2，一劳永逸。h2.create.tables=true只在第一次启动需要，跑通之后我一般改成 false，避免哪天路径错了又静默建一个新库出来，数据看着像丢了。
至于换成 MySQL，solo 包里改database.type=mysql这条路走不通的部分很多：执行器形态和 solo 形态用的表结构、连接池键名都不一样，硬改通常是能启动但页面报 500。要做持久化元数据，稳妥做法是改用多执行器部署，而不是在这个包里强行改。
3.3 时区、项目目录与默认账号
# 时区必须显式指定，默认值不是东八区，cron 会整体偏 8 小时 default.timezone=Asia/Shanghai # 项目与执行产物目录，同样是相对启动目录 azkaban.project.dir=projects executor.global.properties=conf/global.properties # 用户体系：solo 用 XML 文件管理，改密码就改这个文件 user.manager.class=azkaban.user.XmlUserManager user.manager.xml.file=conf/azkaban-users.xml时区这一项特别容易被忽略：default.timezone不写，包里的默认值按某些版本是美西时间，你设一个每天 9 点的定时任务，实际会在下午 5 点触发，排查时会误以为是 cron 写错了。写死Asia/Shanghai，同时在启动参数里也带上-Duser.timezone，两处一致才彻底不偏。
默认账号在conf/azkaban-users.xml里，出厂是azkaban/azkaban，装完第一件事就是改掉：
<!-- conf/azkaban-users.xml —— 只保留一个管理员，密码换掉 --> <azkaban-users> <user username="azkaban" password="换成你的密码" roles="admin" groups="admin" /> <role name="admin" permissions="ADMIN" /> </azkaban-users>roles="admin"决定能不能建项目、执行 flow，测试环境图省事可以直接用管理员账号，但密码别留默认值——solo 默认监听所有网卡，同一网段的人扫到 8081 就能登进来。改完这个文件不需要重启，下次登录生效；如果改完登不上，先看 XML 是不是少闭合标签，解析失败会回退到内置用户表。
4. 启停脚本：先在前台跑通，再做进程守护
配置改完别急着nohup，先让它在你能看见输出的地方跑一遍。solo 包的启动脚本本质上是拼一条java命令，把conf和lib/*塞进 classpath，然后调azkaban.solo.AzkabanSingleServer这个入口类。不同版本脚本名不一样，0.1.0-SNAPSHOT这类构建产物里常见的是start-solo.sh，老一点的是azkaban-solo-start.sh，先ls bin/看一眼再敲，别照着教程硬套。
4.1 前台启动：让异常留在屏幕上
cd /opt/azkaban/azkaban-solo-server-0.1.0-SNAPSHOT # 先看脚本到底做了什么，确认入口类和配置文件路径 bash -x bin/start-solo.sh 2>&1 | head -30bash -x会把每行命令打出来，你能看到它用的JAVA_HOME、拼的 classpath、以及-conf参数指向哪个目录。这一步的价值在于：当脚本启动失败且日志没写出来时，你能直接拿到那条完整的 java 命令，改成前台执行：
# 脚本本质就是这条，去掉末尾的 & 就是前台运行，Ctrl+C 结束 java -Xms512m -Xmx1024m \ -Dfile.encoding=UTF-8 -Duser.timezone=Asia/Shanghai \ -cp "conf:lib/*" \ azkaban.solo.AzkabanSingleServer -conf conf-Xms和-Xmx建议设成一样，避免堆反复扩容；1024m 对单人测试足够，flow 数量上去后按free -m的余量往上加。-Dfile.encoding=UTF-8不加的话，中文项目名在页面上可能是乱码。-cp "conf:lib/*"里conf必须在前面，否则读不到你改过的azkaban.properties。入口类名以包内脚本为准，个别版本会带包路径前缀。
前台跑起来后屏幕上会打出 Jetty 启动日志，看到Started Server或监听 8081 的提示，再用浏览器访问确认，这一轮通了再谈后台。
4.2 后台守护：systemd 比 nohup 靠谱
测试机上图省事可以nohup bin/start-solo.sh &，但机器重启就没了，而且出问题没人拉起。我一般直接写个 unit：
# /etc/systemd/system/azkaban-solo.service [Unit] Description=Azkaban Solo Server After=network.target [Service] Type=forking User=azkaban WorkingDirectory=/opt/azkaban/azkaban-solo-server-0.1.0-SNAPSHOT Environment="JAVA_HOME=/usr/local/jdk1.8.0_381" Environment="JAVA_OPTS=-Xms512m -Xmx1024m -Dfile.encoding=UTF-8 -Duser.timezone=Asia/Shanghai" ExecStart=/opt/azkaban/azkaban-solo-server-0.1.0-SNAPSHOT/bin/start-solo.sh ExecStop=/opt/azkaban/azkaban-solo-server-0.1.0-SNAPSHOT/bin/shutdown-solo.sh Restart=on-failure RestartSec=10 [Install] WantedBy=multi-user.targetType=forking是因为启动脚本自己会转到后台，systemd 需要按 fork 模式等它退出父进程。如果脚本不是这种风格，改成Type=simple并把ExecStart换成上面那条前台 java 命令，反而更直观。WorkingDirectory必须写，前面说过 H2 和 projects 都是相对路径解析的，少了这行服务一起来就指向/。JAVA_HOME写绝对路径，别依赖登录 shell 的环境变量，systemd 不读.bashrc。
sudo systemctl daemon-reload sudo systemctl enable --now azkaban-solo systemctl status azkaban-solo --no-pagerdaemon-reload在第一次创建或改过 unit 后必须执行，否则 systemd 用的还是旧内容。
4.3 停服务：别直接 kill -9
# 正常停止，脚本会走 shutdown hook 关掉 Jetty 和 H2 bin/shutdown-solo.sh # 确认端口真的释放了 ss -lntp | grep 8081直接kill -9的后果是 H2 的连接没正常关闭，会在数据目录里留下.lock.db文件，下次启动报数据库被占用。真遇到了，先确认没有残留 java 进程，再删锁文件重启，具体见下一章。停服务前最好也确认没有正在跑的 flow，solo 不像集群形态有队列保护，进程一停执行中的任务就断在半路，状态会一直挂着。
5. 避坑与排查：五个我真实踩过的坑
这一章是全篇最值得先读的部分。solo 包的报错信息普遍偏含糊，很多现象看着像配置问题，实际是环境或权限。下面五条按“现象 → 原因 → 解决”写，遇到对得上的直接照着改。
5.1 启动脚本执行完就退出，日志只有一两行
现象：敲完bin/start-solo.sh立刻回到 shell，ps看不到 java 进程，logs/下只有个几百字节的文件，里面是UnsupportedClassVersionError或者一堆类加载失败的堆栈。
原因：九成是 JDK 版本不对。包里的 jar 是按 Java 8 编译的，机器默认 JDK 17 时，JVM 直接拒绝加载；另一种是JAVA_HOME指向了 JRE，缺编译器相关类，脚本一拼 classpath 就瘸。
解决：java -version和echo $JAVA_HOME两条一起看，不一致就改。systemd 里跑的话，尤其要检查 unit 文件里的Environment="JAVA_HOME=..."，那里写错了外层 shell 怎么调都没用。改完记得systemctl daemon-reload再重启。
5.2 8081 端口起不来，或者起来但页面打不开
现象：日志里出现Address already in use，进程随即退出；或者进程活着，本机curl 127.0.0.1:8081有响应，从别的机器访问超时。
原因：前者是同机端口冲突，后者多半是防火墙或监听地址问题——solo 默认监听全部网卡，但有些云主机默认安全组不放行高位端口。
解决：ss -lntp | grep 8081先确认是谁占着，能换端口就改jetty.port，非要占 8081 就把冲突进程挪走。访问不通时先在本机 curl，本机通说明服务没问题，再去查安全组和系统防火墙，别一上来就改配置，我见过有人因为这个把配置改乱了，最后还是端口没放行。
5.3 换了数据目录，登录进去项目全空了
现象：把整个安装目录mv到新路径，或者从别的目录用绝对路径启动脚本，服务正常起来，账号也能登，但项目列表是空的，重新建项目后重启又空。
原因：h2.path和azkaban.project.dir都是相对启动目录解析的。换目录启动后，H2 找不到旧库文件，按h2.create.tables=true静默建了一份新的空库，看着就像数据丢了。
解决：立刻停服务，把h2.path改成绝对路径，指回原来那份库文件，同时把h2.create.tables改成 false，再启动。数据还在旧目录里，没有真的丢。这件事之后我把两个路径全部写成绝对的，再没出过问题。
5.4 上传项目卡在 PREPARING，或者执行一秒就失败
现象：zip 包上传成功，点执行后 flow 状态一直停在 PREPARING 不往下走；或者瞬间变 FAILED，日志里只有一句找不到 job 文件。
原因：两种情况。一是 zip 结构不对，.job文件或 flow 文件被套了一层目录，Azkaban 只认压缩包根目录下的文件；二是 flow 2.0 的版本声明缺失，0.1.0-SNAPSHOT这类新构建默认走 flow 2.0，没有.project里的azkaban-flow-version: 2.0，它按老格式解析就会找不到节点。
解决：unzip -l demo.zip看一眼根目录层，发现多套一层就重新压。确认版本声明的写法：
# 正确结构：两个文件都在压缩包根目录 mkdir -p /tmp/demo-flow && cd /tmp/demo-flow # flow 2.0 的版本声明文件 cat > demo.project <<'EOF' azkaban-flow-version: 2.0 EOF # 节点定义，command 类型是内置的，不依赖插件 cat > demo.flow <<'EOF' nodes: - name: echo-step type: command config: command: echo "azkaban solo ok: $(date)" EOF zip -r demo.zip demo.project demo.flowdemo.project的文件名不要求和项目同名，但内容里那行版本声明必须一字不差；nodes下面每个节点的name要唯一，type=command对应内置命令执行器。如果你的 flow 是用老格式写的多个.job文件，就不要带.project声明，两种格式混在一个包里必失败。
5.5 定时任务时间差 8 小时
现象：cron 写的是0 0 9 * * ?，任务实际在下午 5 点触发，日志时间戳也是 UTC。
原因：default.timezone没配，或者配了但 JVM 的user.timezone没跟着改，两处不一致时以 JVM 为准。
解决：azkaban.properties里写default.timezone=Asia/Shanghai，启动参数里补-Duser.timezone=Asia/Shanghai，重启后看页面上的执行时间戳是不是本地时间。机器时区也顺手timedatectl确认一下，见过机器本身是 UTC 的，配置改了三遍都没用。
6. 装完怎么验证：从登录到第一个 flow 跑完
服务起来不等于装好了，我一般按“端口 → 登录 → 建项目 → 跑 flow → 看产物”五步走一遍，全部通过才算收工。
先卡端口和响应，不用打开浏览器：
# 返回 200 或 302 都算 Jetty 活着，连不上就是服务没起来 curl -s -o /dev/null -w "%{http_code}\n" http://127.0.0.1:8081/index # 确认监听地址和进程 ss -lntp | grep 8081浏览器打开http://<机器IP>:8081，用改过密码的账号登录，能看到项目列表页说明 web 层通了。接着新建项目、上传上一章那个demo.zip，点 Execute 执行，状态从 PREPARING 走到 RUNNING 再到 SUCCEEDED，才算真正跑通。
最后落到文件系统上验证，这一步最不容易骗人：
| 检查点 | 位置 | 期望结果 |
|---|---|---|
| 执行产物 | executions/下按 flow 编号分目录 | 有_log文件且内容包含 echo 输出 |
| 项目元数据 | projects/ | 有对应项目目录 |
| 元数据库 | h2/目录 | 有.mv.db文件且体积在增长 |
| 服务日志 | logs/ | 无异常堆栈，时间戳是本地时间 |
# 进执行目录看最近一次 flow 的日志，确认命令真的被执行了 ls -lt executions | head -3 tail -20 executions/*/_log看到azkaban solo ok:那行输出，说明从 web 到执行器的整条链路都通了。如果状态是 SUCCEEDED 但_log里没内容，多半是 job 的command写法有问题，比如用了容器里不存在的命令，或者被引号吃了参数，换成最简单的echo再试一次能快速定位。
从那以后我每次装完这套环境，都会强制走一遍这个五步验证，尤其是executions/里那个_log——它是唯一不会骗你的黑匣子，页面状态可以因为各种原因显示成功，日志里没输出就是没跑。希望帮到你。
本文还有配套的精品资源，点击获取
