简介：面向Linux运维初学者与后端开发者的自动化部署资源包，聚焦在单台Linux服务器上快速搭建Java Web运行环境这一常见需求，将JDK、MySQL、Redis、Nginx四大核心组件的安装流程脚本化，免去逐个下载、编译与配置的繁琐过程。压缩包共27个文件，约930.56MB，以11个sh安装与启动脚本为主体，配合9个gz源码及依赖包、2个rpm系统依赖、2个cnf与2个conf配置文件，另含tar归档，覆盖从环境准备到服务启动的完整链路。资源已吸引298人学习下载。读者可借助其中的初始化配置与各组件独立安装脚本，理解环境变量设置、数据库安全初始化、缓存服务守护进程配置及Nginx反向代理配置的落地方式，并参考系统服务脚本完成开机自启管理，适合作为搭建测试环境或学习自动化部署思路的实践素材。
1. 一套脚本把 JDK、MySQL、Redis、Nginx 全装进新机器：先看清它到底替你做了什么
拿到一台干净的 Linux 机器，第一件事往往不是写业务代码，而是把 JDK、MySQL、Redis、Nginx 这四个基础件挨个装好。手动装过一遍的人都懂那种体验：JDK 要配环境变量，MySQL 要初始化数据目录再改认证插件，Redis 要改 bind 和 protected-mode，Nginx 要处理源和编译依赖，中间任何一步报错都得回头翻日志。所谓「一键式安装」脚本，本质就是把这四件事的固定动作串成一条可重复执行的流水线，让新机器从裸系统到能跑 Java 服务，压缩到几分钟。它适合两类人：一类是频繁开测试机、需要快速拉起环境的开发者；另一类是想搞清楚「一条命令背后到底发生了什么」、以后能自己改脚本的运维新手。这篇不吹脚本多神，而是把它拆开，讲清每一步在干什么、参数怎么改、哪里最容易翻车。
2. 拆开一键脚本：四个组件的安装顺序与依赖关系
一键脚本看着是一条命令，实际内部是有严格先后顺序的。顺序错了，轻则某个服务起不来，重则脚本中途退出、留下半装状态。这一章先把脚本的执行骨架讲透，再逐个组件说清安装动作和关键参数。
2.1 为什么顺序是「基础依赖 → JDK → MySQL → Redis → Nginx」
四个组件里，JDK 是纯运行时，不依赖另外三个；MySQL 和 Redis 都是独立服务，互不依赖；Nginx 只作为反向代理时才会和前面几个产生配置层面的关联，安装阶段同样独立。真正决定顺序的是系统层依赖：编译工具链、下载工具、系统库。常见做法是脚本开头先统一装gcc、make、wget、tar、openssl-devel这类包，再进入组件安装。把依赖放最前面，是因为后面每个组件的安装都可能用到它们，尤其是源码编译 Nginx 和某些发行版的 MySQL 客户端库。
另一个隐性顺序是「先 JDK 后业务服务」。如果 MySQL 或 Redis 的启动脚本里带了 Java 相关的健康检查（有些团队会这么写），JDK 没装好就会误判服务失败。所以脚本里通常把 JDK 放在第一个业务组件位置，装完立刻java -version验证，验证不过就exit 1，避免后面白装。
#!/usr/bin/env bash set -euo pipefail # 统一的基础依赖，缺一个后面就可能编译失败 install_base_deps() { if command -v yum >/dev/null 2>&1; then yum install -y gcc gcc-c++ make wget tar openssl-devel libaio numactl elif command -v apt-get >/dev/null 2>&1; then apt-get update apt-get install -y build-essential wget tar libssl-dev libaio1 numactl else echo "unsupported package manager" >&2 exit 1 fi } install_base_deps这段是脚本的地基。set -euo pipefail三个开关分别管：命令失败立即退出、引用未定义变量报错、管道中任一环节失败整体失败。很多网上流传的脚本没有这三行，结果某个wget失败后继续往下跑，最后装出一个残缺环境，排查起来非常费劲。install_base_deps里按包管理器分支，是因为同一份脚本要兼容 CentOS 系和 Debian 系，这是「一键」能跨机器用的前提。libaio和numactl是 MySQL 运行需要的系统库，漏装会在初始化阶段报错。
2.2 JDK 安装：版本选择与环境变量落盘
JDK 这块最容易出的问题是版本和发行版。脚本一般会固定一个 LTS 版本（比如 8 或 17），从压缩包解压到/usr/local下，再写/etc/profile.d/里的环境变量文件。为什么不直接yum install java-1.8.0-openjdk？因为一键脚本追求「装到哪个路径、用哪个版本」完全可控，压缩包方式不依赖系统源里有没有这个版本，也不怕源被换掉。
install_jdk() { local jdk_tar="/tmp/jdk.tar.gz" local jdk_home="/usr/local/jdk" # 压缩包由脚本内置或提前放到固定路径，避免运行时依赖外网 tar -zxf "$jdk_tar" -C /usr/local mv /usr/local/jdk-* "$jdk_home" 2>/dev/null || true cat > /etc/profile.d/jdk.sh <<'EOF' export JAVA_HOME=/usr/local/jdk export PATH=$JAVA_HOME/bin:$PATH EOF # 当前 shell 立即生效，并做一次硬校验 source /etc/profile.d/jdk.sh java -version || { echo "jdk install failed" >&2; exit 1; } }逻辑上分三步：解压、落环境变量、验证。JAVA_HOME写死在/usr/local/jdk，是为了让后续所有脚本和服务的配置都能引用同一个路径，不用每次猜。环境变量放/etc/profile.d/而不是~/.bashrc，是因为服务进程通常不以登录 shell 启动，读不到用户级配置。最后的java -version是后悔药：装完不验证，等 MySQL 或业务服务报「找不到 java」时，你根本分不清是 JDK 没装好还是 PATH 没生效。参数上唯一要改的是jdk_tar的来源和jdk_home的路径，如果机器上已有其他 JDK，务必先确认JAVA_HOME不会覆盖掉正在用的版本。
2.3 MySQL 安装：初始化、认证插件与远程访问开关
MySQL 是四个组件里初始化动作最多的。脚本通常做这几件事：解压或安装二进制包、创建mysql用户、初始化数据目录、启动服务、设置 root 密码、按需开放远程访问。这里有个高频坑：MySQL 8 默认认证插件是caching_sha2_password，很多老客户端连不上，脚本里一般会显式改成mysql_native_password，或者在建用户时指定插件。
install_mysql() { local base="/usr/local/mysql" local datadir="/data/mysql" id mysql >/dev/null 2>&1 || useradd -r -s /sbin/nologin mysql mkdir -p "$datadir" && chown -R mysql:mysql "$datadir" # 初始化数据目录，生成临时 root 密码 "$base/bin/mysqld" --initialize --user=mysql --datadir="$datadir" "$base/bin/mysqld_safe" --user=mysql --datadir="$datadir" & # 从错误日志里取临时密码，首次登录必须改 local tmp_pass tmp_pass=$(grep 'temporary password' "$datadir"/*.err | awk '{print $NF}') "$base/bin/mysql" -uroot -p"$tmp_pass" --connect-expired-password <<'SQL' ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'ChangeMe_123'; FLUSH PRIVILEGES; SQL }--initialize会生成一个临时密码写在错误日志里，脚本用grep抓出来完成首次登录，这是自动化里比较稳的做法。IDENTIFIED WITH mysql_native_password是给老客户端留的兼容口子，如果你的客户端都支持新插件，这行可以去掉，安全性更好。datadir单独放/data而不是默认路径，是为了数据盘和系统盘分离，生产环境尤其要这么干。要提醒的是，脚本里写死 root 密码是方便演示，实际用的时候应该改成从环境变量或交互输入读取，否则密码就躺在脚本里了。
2.4 Redis 与 Nginx：配置项比安装本身更关键
Redis 和 Nginx 的安装动作相对轻，但配置项决定它们能不能被外部正常访问。Redis 默认bind 127.0.0.1且protected-mode yes，脚本如果只装不改，远程连不上是必然的。Nginx 则常见于源里版本太老，脚本会选择加官方源或源码编译。
install_redis() { local conf="/etc/redis.conf" # 假设二进制已就位，这里只处理配置 sed -i 's/^bind 127.0.0.1/bind 0.0.0.0/' "$conf" sed -i 's/^protected-mode yes/protected-mode no/' "$conf" sed -i 's/^# requirepass .*/requirepass ChangeMe_456/' "$conf" redis-server "$conf" --daemonize yes } install_nginx() { # 源码编译时显式带上常用模块 ./configure --prefix=/usr/local/nginx --with-http_ssl_module --with-http_gzip_static_module make -j"$(nproc)" && make install }Redis 这三行sed分别改监听地址、关闭保护模式、设密码。注意protected-mode no只有在设了密码或绑定了可信地址时才相对安全，两个都放开等于把 Redis 暴露在公网，这是血泪经验里最常见的事故来源。Nginx 的--with-http_ssl_module是 HTTPS 的前提，--with-http_gzip_static_module影响静态资源压缩，编译时漏了后面只能重编。make -j$(nproc)用满 CPU 核数，能明显缩短编译时间。
3. 把脚本跑起来：执行前检查、执行中观察、执行后验证
脚本写对只是第一步，真正在机器上跑的时候，环境差异会带来一堆意外。这一章讲怎么安全地执行，以及每一步该看什么。
3.1 执行前的三项检查
第一，确认系统版本和包管理器。脚本里如果只写了yum，跑到 Debian 系机器上第一步就挂。第二，确认磁盘空间，MySQL 数据目录和 Nginx 编译临时文件都吃空间，df -h看一眼/和/data。第三，确认端口没被占用，ss -lntp | grep -E '3306|6379|80|443'，有残留进程先清掉，否则服务起不来还以为是脚本问题。
# 执行前自检，任何一项不满足就先处理 check_env() { grep -Eq 'CentOS|Red Hat' /etc/os-release || echo "warn: not RHEL-like" [ "$(df -P / | awk 'NR==2 {print $4}')" -gt 5242880 ] || echo "warn: / free < 5G" ss -lntp | grep -E ':(3306|6379|80|443)\b' && echo "warn: port occupied" }这三项检查不阻断执行，只给警告，是因为有些环境确实端口被别的服务占着但可以换端口。把警告打出来，比闷头跑完再排查强。
3.2 执行中怎么观察，失败时看哪里
脚本执行时最好保留完整输出，bash install.sh 2>&1 | tee install.log，出问题直接搜error、failed、No such file。四个组件各自的失败特征不一样：JDK 失败通常是压缩包路径不对或解压后目录名不匹配；MySQL 失败集中在初始化阶段，看datadir下的.err日志；Redis 失败多半是配置项写错或端口占用；Nginx 失败看configure阶段的缺库提示和make的编译错误。
| 组件 | 典型失败现象 | 优先查看位置 |
|---|---|---|
| JDK | java: command not found | /etc/profile.d/jdk.sh是否生效 |
| MySQL | 初始化卡住或退出 | $datadir/*.err错误日志 |
| Redis | 启动后立即退出 | redis-server前台启动看报错 |
| Nginx | configure报缺库 | 编译输出里的not found行 |
3.3 装完之后的验证清单
装完不验证等于没装。JDK 看java -version和echo $JAVA_HOME；MySQL 用mysql -uroot -p登录并show databases;；Redis 用redis-cli -a 密码 ping应返回PONG；Nginx 用curl -I http://127.0.0.1看是否返回 200。四个都过了，再考虑把服务设成开机自启，systemctl enable或写 init 脚本，这一步脚本里如果有就顺手做了，没有就手动补。
4. 避坑与排查：一键脚本最容易翻车的五个地方
一键脚本的坑大多不在「装不上」，而在「装上了但不对」。下面五条是按现象、原因、解决整理的实战记录。
现象一：脚本跑完提示成功，但java -version报找不到命令。原因多半是环境变量写进了~/.bashrc，而当前 shell 没重新加载，或者脚本用了sh执行导致source行为不一致。解决：环境变量统一放/etc/profile.d/，执行脚本用bash，跑完手动source /etc/profile再验证。
现象二：MySQL 初始化报libaio.so.1: cannot open shared object file。原因是基础依赖里漏了libaio，或者装的是libaio1但系统要的是libaio。解决：在install_base_deps里按发行版补对应包名，装完ldconfig刷新库缓存。
现象三：Redis 远程连不上，本地redis-cli却正常。原因是bind还是127.0.0.1，或者protected-mode没关但也没设密码。解决：确认bind 0.0.0.0和requirepass同时生效，改完必须重启 Redis，配置不会热加载。
现象四：Nginx 编译到一半报SSL modules require the OpenSSL library。原因是openssl-devel没装或版本太老。解决：先装开发包再./configure，如果系统源里的 OpenSSL 版本过低，需要单独指定--with-openssl=路径。
现象五：重复执行脚本导致 MySQL 数据目录被二次初始化，数据丢失。原因是一键脚本没有幂等判断，--initialize对非空目录会失败或覆盖。解决：初始化前判断$datadir/mysql是否存在，存在就跳过初始化只启动服务。这条是最该重视的，测试机上重跑脚本很常见，没有幂等保护就是定时炸弹。
5. 把一键脚本改成可维护的版本：参数化、幂等与分步执行
原始的一键脚本适合一次性拉起环境，但要长期用，得做三件事：参数外置、幂等判断、支持分步执行。参数外置是把 JDK 版本、安装路径、各服务端口和密码抽到脚本顶部的变量区或单独的config.env，改配置不用动逻辑。幂等判断是每个安装函数开头先检查「是否已装」，已装就跳过，这样脚本可以反复跑而不破坏现有环境。分步执行是支持bash install.sh jdk只装 JDK，bash install.sh all全装，调试单个组件时不用每次从头来。
# config.env 示例，脚本开头 source 进来 JDK_HOME=/usr/local/jdk MYSQL_DATADIR=/data/mysql REDIS_PORT=6379 NGINX_PREFIX=/usr/local/nginx # 幂等判断的写法 install_jdk() { [ -x "$JDK_HOME/bin/java" ] && { echo "jdk already installed"; return 0; } # ... 原安装逻辑 } # 分步入口 case "${1:-all}" in jdk) install_jdk ;; mysql) install_mysql ;; redis) install_redis ;; nginx) install_nginx ;; all) install_jdk; install_mysql; install_redis; install_nginx ;; *) echo "usage: $0 [jdk|mysql|redis|nginx|all]"; exit 1 ;; esac这套改法的价值在于把「一次性脚本」变成「可复用工具」。参数区让不同机器用同一份脚本、不同配置；幂等让重跑安全；分步入口让排错时能单独重装某个组件。验证方法也简单：连续跑两次all，第二次应该全部输出already installed且服务状态不变，这就说明幂等生效了。从那以后我每次拿到这类一键脚本，都先看它有没有幂等判断和分步入口，没有就先补上再跑，省下的返工时间远比改脚本的几分钟多。希望帮到你。
本文还有配套的精品资源，点击获取
