1. 项目概述为什么我们需要一个部署脚本在Linux服务器上部署和维护一个项目无论是Web应用、后端服务还是数据处理程序对于开发者或运维人员来说都是家常便饭。回想一下你是不是经常重复执行一系列固定的命令比如先cd到项目目录然后git pull拉取最新代码接着mvn clean package或npm run build进行构建最后用nohup java -jar ... 或者systemctl restart来启动服务。这个过程一次两次还好日复一日尤其是在需要频繁更新、回滚或者多环境部署时不仅繁琐低效还极易因手误敲错命令而导致服务中断。这个项目标题——“Linux环境 使用.sh脚本部署项目启动、停止、重启”——直指的就是这个痛点。它的核心价值在于自动化与标准化。通过编写一个Shell脚本.sh文件我们将所有部署和运维操作封装成几个简单的命令例如./deploy.sh start、./deploy.sh stop、./deploy.sh restart。这不仅仅是偷懒更是提升运维可靠性、降低人为错误、实现一键式操作的最佳实践。对于小团队或个人项目它就是一个轻量级的、自包含的“运维平台”。想象一下深夜接到线上bug修复需求你不再需要睡眼惺忪地回忆完整的命令序列只需要执行一个脚本。或者当有新成员加入时你无需口述复杂的部署流程直接把脚本和文档给他就行。这个.sh脚本就是项目在Linux环境下的“操作说明书”和“自动化工具集”。接下来我将以一个典型的Spring Boot Java后端项目为例拆解如何从零构建一个功能完整、健壮可靠的部署脚本其中包含的思维和技巧同样适用于Node.js、Python、Go等其他技术栈。2. 脚本整体设计与思路拆解在动手写代码之前我们先要规划好脚本的蓝图。一个好的部署脚本不应该只是一个命令的堆砌它需要有清晰的逻辑结构、完善的错误处理、友好的日志记录以及一定的可配置性。2.1 核心功能模块设计我们的部署脚本将围绕以下几个核心功能展开服务管理这是最基本的功能对应标题中的启动、停止、重启。我们需要能够精确地控制应用进程的生命周期。部署更新这是脚本的核心价值所在。它应该能自动拉取代码、构建项目、备份旧版本、部署新版本。这通常是最复杂的部分。状态查看快速检查应用是否正在运行并查看其进程ID、运行时间等基本信息。日志管理能够方便地查看应用输出的实时日志或历史日志这对于排查问题至关重要。基于这些功能我们决定采用“命令参数”的方式来调用脚本这是一种非常经典和直观的设计。例如./deploy.sh start # 启动服务 ./deploy.sh stop # 停止服务 ./deploy.sh restart # 重启服务 ./deploy.sh status # 查看状态 ./deploy.sh deploy # 执行完整部署流程 ./deploy.sh logs # 查看日志2.2 技术选型与考量为什么用Shell脚本Bash因为它几乎是所有Linux发行版的默认配置无需安装任何额外依赖通用性极强。对于自动化部署这种与操作系统紧密交互的任务Shell脚本具有天然的优势直接调用系统命令、管理进程、操作文件都非常方便。在脚本内部我们会大量使用以下几个关键命令和技术点ps、grep、awk用于查找和操作进程这是实现status和stop功能的基础。nohup和用于在后台启动进程并且使进程在终端关闭后依然存活。这是实现start功能的关键。kill用于向进程发送信号实现停止功能。这里需要注意信号的选择如-15TERM信号用于优雅停止-9KILL信号用于强制杀死。变量和函数使脚本模块化、可配置、易维护。条件判断和循环控制脚本的执行流程。输入输出重定向将应用的日志输出到指定文件便于后续查看。注意虽然Python等语言也能完成类似任务但对于纯粹的部署启动脚本Shell脚本的简洁性和直接性往往是首选。除非你的部署逻辑异常复杂涉及大量网络请求或数据结构处理否则Shell脚本足以胜任。2.3 环境与配置分离思想一个硬编码了所有路径和参数的脚本是脆弱的无法在不同环境开发、测试、生产下复用。因此我们需要引入配置分离的思想。常见的做法有在脚本开头定义一系列变量如APP_NAMEJAR_PATHLOG_PATH。使用一个独立的配置文件如deploy.conf脚本去读取它。利用环境变量。在本示例中为了保持简洁和独立我们采用第一种方式将所有可配置项集中在脚本开头的变量定义区域。在实际团队项目中推荐使用第二种或第三种方式以实现更好的工程化管理。3. 脚本核心细节解析与实操要点让我们开始深入脚本的各个部分。我将先展示一个完整的脚本框架然后逐一拆解其中的关键段落。3.1 脚本头部与全局配置这是脚本的“总控台”定义了整个部署任务的所有基本参数。#!/bin/bash # 部署管理脚本 # 用法: ./deploy.sh {start|stop|restart|status|deploy|logs} # 可配置变量区域 # 应用名称用于标识进程和日志 APP_NAMEmy-springboot-app # 应用运行的Java命令根据实际情况调整 JAVA_OPTS-Xms512m -Xmx1024m -Dspring.profiles.activeprod # 应用JAR包所在目录的绝对路径 APP_HOME/home/ubuntu/apps/${APP_NAME} # 应用JAR包的全名带版本号 JAR_FILEmy-app-1.0.0.jar # 应用完整启动路径 APP_PATH${APP_HOME}/${JAR_FILE} # 应用进程ID文件存放路径用于可靠地停止进程 PID_FILE${APP_HOME}/${APP_NAME}.pid # 应用日志输出文件路径 LOG_FILE${APP_HOME}/logs/${APP_NAME}.log # 备份目录 BACKUP_DIR${APP_HOME}/backup # 配置结束 关键点解析#!/bin/bash指定脚本解释器为Bash确保脚本执行环境一致。APP_NAME这是整个脚本的“灵魂”。后续查找进程、命名日志文件、创建PID文件都依赖它。请确保它在你的服务器上是唯一的避免误操作其他应用。JAVA_OPTS这里设置了JVM内存参数和Spring的激活配置文件。你可以根据应用需要调整例如加入GC日志参数-XX:PrintGCDetails。APP_HOME使用绝对路径是最佳实践。绝对路径可以防止因执行脚本时所在目录不同而导致的路径错误。想象一下如果你在/tmp目录下执行脚本而脚本里用的是相对路径./target/app.jar结果肯定是找不到文件。PID_FILE这是一个非常重要的设计。传统上我们通过ps -ef | grep来查找进程PID但这种方式在遇到同名进程或脚本时可能不可靠。将PID写入一个文件停止时直接从文件中读取更加精准和安全。LOG_FILE将标准输出和错误输出重定向到日志文件便于后续排查问题。我们创建了logs子目录来存放日志。3.2 日志与目录准备函数良好的日志是运维的“眼睛”。我们在脚本开始时就应该建立日志记录机制并确保必要的目录存在。# 日志函数 log() { echo [$(date %Y-%m-%d %H:%M:%S)] $1 } # 检查并创建目录 init_dirs() { if [ ! -d ${APP_HOME}/logs ]; then mkdir -p ${APP_HOME}/logs log 创建日志目录: ${APP_HOME}/logs fi if [ ! -d ${BACKUP_DIR} ]; then mkdir -p ${BACKUP_DIR} log 创建备份目录: ${BACKUP_DIR} fi }实操心得log函数为每一条输出信息加上了时间戳这在查看脚本执行历史时非常有用。init_dirs函数在每次执行部署或启动操作前被调用确保不会因为目录不存在而导致失败例如nohup输出日志时找不到logs目录。-p参数能自动创建不存在的父目录非常方便。3.3 核心功能函数实现这是脚本的“肌肉”实现了具体的启动、停止、状态检查等功能。3.3.1 启动start函数start() { log 开始启动应用: ${APP_NAME} # 检查进程是否已存在 if [ -f ${PID_FILE} ]; then PID$(cat ${PID_FILE}) if ps -p ${PID} /dev/null 21; then log 应用已经在运行中 (PID: ${PID}). 如需重启请先执行 stop 或直接使用 restart 命令。 exit 1 else log 发现旧的PID文件但进程 ${PID} 不存在。清理PID文件。 rm -f ${PID_FILE} fi fi # 初始化目录 init_dirs # 启动应用并将输出重定向到日志文件 log 启动命令: nohup java ${JAVA_OPTS} -jar ${APP_PATH} ${LOG_FILE} 21 nohup java ${JAVA_OPTS} -jar ${APP_PATH} ${LOG_FILE} 21 # 获取并保存新进程的PID NEW_PID$! echo ${NEW_PID} ${PID_FILE} sleep 3 # 等待几秒让应用初步启动 # 再次检查进程是否存活 if ps -p ${NEW_PID} /dev/null 21; then log 应用启动成功PID: ${NEW_PID} log 日志文件: ${LOG_FILE} tail -f -n 50 ${LOG_FILE} # 可选启动后自动跟踪最新日志 TAIL_PID$! sleep 5 kill ${TAIL_PID} /dev/null 21 # 5秒后自动结束跟踪 else log 错误应用启动后进程可能已退出请检查日志: ${LOG_FILE} rm -f ${PID_FILE} # 清理无效的PID文件 exit 1 fi }关键点与避坑指南进程存在性检查启动前先检查PID文件对应的进程是否真的存在。这避免了重复启动也处理了进程已死但PID文件残留的“脏”状态。nohup ... 详解nohup让进程忽略挂断信号SIGHUP让进程在后台运行。组合使用确保终端关闭后进程仍在。输出重定向21将标准输出stdout重定向到日志文件。21表示将标准错误stderr也重定向到标准输出所在的地方即同一个日志文件。这样所有输出信息都进了日志。$!变量它保存了最后一个被放入后台执行的进程的PID。这是我们获取应用真实PID的关键。启动后检查写入PID文件后等待几秒再检查进程是否存活。有些应用启动失败会立刻退出这个检查能及时发现问题。自动跟踪日志是一个贴心的小功能方便你快速查看启动初期的报错。3.3.2 停止stop函数stop() { log 开始停止应用: ${APP_NAME} if [ ! -f ${PID_FILE} ]; then log PID文件不存在: ${PID_FILE}。尝试通过进程名查找... PID$(ps -ef | grep -v grep | grep ${APP_PATH} | awk {print $2}) if [ -z ${PID} ]; then log 应用似乎未在运行。 return 0 else log 通过进程名找到PID: ${PID} fi else PID$(cat ${PID_FILE}) if [ -z ${PID} ]; then log PID文件为空。 rm -f ${PID_FILE} return 1 fi fi # 尝试优雅停止 (SIGTERM) log 正在停止进程 (PID: ${PID}) ... kill -15 ${PID} /dev/null 21 # 等待最多30秒直到进程结束 local WAIT_TIME0 while ps -p ${PID} /dev/null 21 [ ${WAIT_TIME} -lt 30 ]; do sleep 1 ((WAIT_TIME)) echo -n . done echo if ps -p ${PID} /dev/null 21; then # 优雅停止失败强制杀死 (SIGKILL) log 进程未在30秒内停止正在强制杀死... kill -9 ${PID} /dev/null 21 sleep 2 if ps -p ${PID} /dev/null 21; then log 错误无法强制杀死进程 ${PID}请手动检查。 return 1 else log 进程已被强制杀死。 fi else log 进程已优雅停止。 fi # 清理PID文件 rm -f ${PID_FILE} log 应用停止完成。 }关键点与避坑指南双重PID获取机制优先从PID文件读取如果文件不存在则回退到通过ps和grep查找。这提高了脚本的健壮性。优雅停止与强制停止kill -15SIGTERM是通知进程“请你自己关闭”允许进程完成收尾工作如保存数据、关闭连接。kill -9SIGKILL是操作系统强制立即终止进程不给任何清理机会。务必先尝试优雅停止等待一段时间如30秒后再考虑强制停止这是生产环境的基本素养。等待循环使用一个循环来等待进程结束并设置超时时间。这避免了脚本在进程还在关闭时就去执行删除PID文件等后续操作。清理工作无论以何种方式停止最后都必须删除PID文件否则会影响下一次启动。3.3.3 状态status与重启restart函数status() { if [ -f ${PID_FILE} ]; then PID$(cat ${PID_FILE}) if ps -p ${PID} /dev/null 21; then log 应用正在运行。 ps -fp ${PID} return 0 else log PID文件存在但进程 (PID: ${PID}) 未运行。 return 1 fi else PID$(ps -ef | grep -v grep | grep ${APP_PATH} | awk {print $2}) if [ -n ${PID} ]; then log 应用正在运行 (通过进程名找到PID: ${PID})但PID文件丢失。 ps -fp ${PID} return 0 else log 应用未在运行。 return 3 fi fi } restart() { log 开始重启应用: ${APP_NAME} stop sleep 2 # 给系统一点清理时间 start }status函数提供了清晰的应用运行状态。restart函数则完美诠释了“组合优于继承”的思想它简单地调用了stop和start代码简洁且行为明确。4. 部署deploy流程的完整实现deploy函数是脚本的“大脑”它串联了从代码更新到服务上线的完整流水线。这里我们假设项目是一个Maven管理的Spring Boot应用代码仓库是Git。deploy() { log 开始执行部署流程... # 0. 检查必要命令是否存在 command -v git /dev/null 21 || { log 错误git 命令未找到。; exit 1; } command -v mvn /dev/null 21 || { log 错误mvn 命令未找到。; exit 1; } # 1. 进入应用目录 cd ${APP_HOME} || { log 错误无法进入目录 ${APP_HOME}; exit 1; } # 2. 停止当前运行的服务 log 步骤1停止当前服务... stop # 给停止操作一点额外时间确保端口释放等 sleep 5 # 3. 从Git拉取最新代码 log 步骤2从Git拉取最新代码... git fetch --all git reset --hard origin/master # 假设主分支是master可根据需要改为main或其他分支 git pull origin master if [ $? -ne 0 ]; then log 错误Git拉取代码失败。 exit 1 fi # 4. 使用Maven构建项目 log 步骤3使用Maven构建项目... mvn clean package -DskipTests # 跳过测试以加快构建生产环境建议执行测试 if [ $? -ne 0 ]; then log 错误Maven构建失败。 exit 1 fi # 5. 备份旧版本JAR包可选但推荐 log 步骤4备份旧版本... if [ -f ${APP_PATH} ]; then BACKUP_FILE${BACKUP_DIR}/${JAR_FILE}.$(date %Y%m%d%H%M%S).bak cp ${APP_PATH} ${BACKUP_FILE} log 旧版本已备份至: ${BACKUP_FILE} fi # 6. 复制新构建的JAR包到运行位置 log 步骤5复制新JAR包... # 假设Maven打包后JAR在target目录下且名称固定或可预测 # 这里需要根据你的项目实际输出路径调整 SOURCE_JAR${APP_HOME}/target/${JAR_FILE} if [ ! -f ${SOURCE_JAR} ]; then # 如果名称不固定可以尝试查找最新的jar SOURCE_JAR$(find ${APP_HOME}/target -name *.jar -type f | head -n 1) if [ -z ${SOURCE_JAR} ]; then log 错误在target目录下未找到JAR文件。 exit 1 fi fi cp ${SOURCE_JAR} ${APP_PATH} log 新版本JAR包已就位: ${APP_PATH} # 7. 启动服务 log 步骤6启动服务... start log 部署流程全部完成 }部署流程深度解析与注意事项前置检查在开始任何操作前检查git和mvn命令是否存在。这可以避免脚本执行到一半才发现环境不满足导致状态混乱。强制重置代码git reset --hard origin/master会强制将本地工作区重置成和远程仓库一模一样的状态这会丢弃所有本地未提交的修改。这在生产部署脚本中是合理的因为你不应该在生产服务器上直接修改代码。但在测试环境要小心。构建跳过测试-DskipTests参数可以大幅缩短构建时间。对于生产部署是否跳过测试需要权衡。严格的CI/CD流程会在独立的构建阶段运行测试部署阶段可能直接使用已通过测试的制品。版本备份备份旧版本是一个至关重要的安全网。如果新版本启动后发现有严重问题你可以立即用备份的旧JAR包回滚。备份文件名中带上时间戳便于管理。JAR包路径处理这里演示了两种方式。第一种是知道确切的JAR包名称。第二种是使用find命令查找这在你使用spring-boot-maven-plugin且未指定finalName导致JAR包名称带版本号时特别有用。head -n 1确保只取第一个找到的JAR。流程原子性与错误处理每个关键步骤后都检查上一条命令的退出状态码$?如果不为0表示失败则用exit 1终止脚本。这保证了部署的原子性——要么全部成功要么在失败点停止不会留下一个半新半旧的不确定状态。5. 查看日志与其他辅助功能日志是运维的生命线一个方便的日志查看功能必不可少。logs() { local actiontail local lines100 # 简单的参数解析例如 ./deploy.sh logs -f 或 ./deploy.sh logs -n 200 while [[ $# -gt 0 ]]; do case $1 in -f|--follow) actiontail -f shift ;; -n|--lines) lines$2 shift 2 ;; *) log 未知参数: $1 echo 用法: $0 logs [-f|--follow] [-n|--lines NUM] return 1 ;; esac done if [ ! -f ${LOG_FILE} ]; then log 日志文件不存在: ${LOG_FILE} return 1 fi log 查看应用日志 (${action} -n ${lines} ${LOG_FILE}): ${action} -n ${lines} ${LOG_FILE} }这个logs函数支持两个常用参数-f实时跟踪日志输出等同于tail -f用于监控正在发生的情况。-n指定查看最近多少行日志例如./deploy.sh logs -n 500。6. 脚本主逻辑与使用帮助最后我们需要一个主函数来解析用户输入的命令并调用对应的功能函数。# 主函数 main() { case $1 in start) start ;; stop) stop ;; restart) restart ;; status) status ;; deploy) deploy ;; logs) shift # 移除第一个参数logs将剩余参数传递给logs函数 logs $ ;; *) echo 用法: $0 {start|stop|restart|status|deploy|logs [-f] [-n lines]} echo echo 命令说明: echo start 启动应用程序 echo stop 停止应用程序先尝试优雅停止超时则强制停止 echo restart 重启应用程序等同于 stop start echo status 查看应用程序运行状态 echo deploy 执行完整部署流程停服 - 拉代码 - 构建 - 备份 - 启动 echo logs 查看应用程序日志支持参数 echo -f, --follow 实时跟踪日志 echo -n, --lines N 查看最近N行日志 exit 1 ;; esac } # 脚本执行入口 main $主函数main使用case语句来分发命令。$1代表执行脚本时传入的第一个参数。shift命令用于处理logs子命令的额外参数这是一个处理命令行参数的常用技巧。7. 常见问题与排查技巧实录即使脚本写得再完善在实际操作中依然会遇到各种问题。下面是我在多年使用这类脚本中积累的一些典型问题及其解决方法。7.1 权限问题问题执行脚本时报错Permission denied。原因脚本文件没有可执行权限或者运行脚本的用户对APP_HOME目录、日志目录等没有读写权限。解决给脚本添加执行权限chmod x deploy.sh。确保运行用户如ubuntu对应用目录有足够权限。通常可以将目录所有者改为该用户sudo chown -R ubuntu:ubuntu /home/ubuntu/apps/。7.2 进程停止失败或残留问题执行stop命令后status显示进程还在或者端口仍然被占用。排查首先检查PID文件内容是否正确cat /home/ubuntu/apps/my-app/my-springboot-app.pid。手动检查进程ps -fp PID。如果进程不存在说明PID文件是旧的手动删除它即可。如果进程存在但不响应kill -15等待脚本中的超时机制30秒后脚本会自动发送kill -9。如果脚本执行完进程还在可能是僵尸进程Z状态或权限问题。可以用ps aux | grep defunct查找僵尸进程其父进程通常是1号进程一般需要重启服务器才能清理。检查端口占用netstat -tlnp | grep :你的端口号看是否是其他进程占用了端口。7.3 应用启动后立即退出问题start命令显示成功但几秒后status显示应用未运行。排查这是最常见的问题根本原因在于应用本身启动失败。首要检查日志./deploy.sh logs -n 100查看应用启动失败的具体错误信息。常见原因有数据库连接失败。配置文件错误如application-prod.yml格式错误或参数缺失。端口被占用。JVM参数设置不当导致内存溢出OOM。手动启动测试切换到应用目录手动执行nohup java -jar ...命令观察终端输出这通常能直接看到错误。检查JAR包完整性确认部署脚本复制的JAR包是完整的可以尝试手动解压jar -tf my-app.jar | head看是否能列出内容。7.4 部署过程中构建失败问题deploy命令在mvn clean package阶段失败。排查网络问题Maven无法下载依赖。检查服务器网络或者使用内网的Nexus私服。内存不足构建Java项目可能消耗大量内存。尝试增加Maven可用内存export MAVEN_OPTS-Xmx1024m或者在脚本的mvn命令前加上它。代码冲突Git拉取代码时出现冲突。这在生产环境不应该发生但如果发生了需要手动进入目录解决冲突。脚本中的git reset --hard可以避免大部分冲突但前提是服务器本地没有需要保留的修改。7.5 日志文件过大问题LOG_FILE日志文件快速增长占满磁盘。解决脚本本身不处理日志轮转这是另一个重要的运维点。使用Linux logrotate服务这是最推荐的方式。创建一个配置文件/etc/logrotate.d/my-springboot-app/home/ubuntu/apps/my-springboot-app/logs/*.log { daily rotate 30 compress delaycompress missingok notifempty create 644 ubuntu ubuntu postrotate # 如果需要可以发送信号让应用重新打开日志文件但Java应用通常不需要 # kill -USR1 cat /home/ubuntu/apps/my-springboot-app/my-springboot-app.pid 2/dev/null 2/dev/null || true endscript }这样配置会每天轮转日志保留30天并自动压缩旧日志。在应用内配置使用Logback或Log4j2等日志框架配置基于大小和时间的滚动策略。7.6 脚本在不同环境下的适配场景开发、测试、生产环境配置不同如数据库地址、JVM参数。建议将配置外置不要将JAVA_OPTS等写死在脚本里。可以创建一个setenv.sh文件或deploy.conf在脚本开头用source命令加载source /path/to/setenv.sh。不同环境部署不同的配置文件。使用环境变量在脚本中引用环境变量如-Dspring.profiles.active${SPRING_PROFILE}然后在服务器上设置export SPRING_PROFILEprod。使用配置中心对于大型项目推荐使用Spring Cloud Config、Apollo等配置中心来管理环境配置。将这个脚本保存为deploy.sh放到你的服务器应用目录下赋予执行权限你就可以通过几个简单的命令来掌控整个项目的生命周期了。它就像一个忠实的助手将你从重复的运维劳动中解放出来让你能更专注于代码和业务逻辑本身。记住所有自动化脚本的前提是充分测试尤其是在生产环境使用前务必在测试环境反复验证其每个环节的可靠性。
