Linux下H5开发环境与数据库一键配置

文章配图，仅供参考

我写的这个Shell脚本，核心就三步：检测系统环境→下载预编译包→执行配置模板。比如处理Node.js时，它先通过`lsb_release -a`判断是Ubuntu还是CentOS，再根据版本号从阿里云镜像站拉取对应的Node.js二进制包——这比用`apt`或`yum`装快5倍以上，还能避开源里可能存在的旧版本。数据库部分更绝，MySQL 8.0的默认认证插件在旧版PHP里会报错，脚本直接修改`/etc/my.cnf`的`default_authentication_plugin=mysql_native_password`，连手动改配置的步骤都省了。

上周测试时出了个幺蛾子——某台服务器的`/tmp`目录被挂载成了noexec，导致脚本里的临时编译命令全报错。后来我在脚本开头加了段检测逻辑：`if [ -x /tmp ]; then echo "/tmp可执行" else mount -o remount,exec /tmp; fi`。这细节估计90%的自动化脚本都没考虑过——毕竟大家测试时都用干净的环境，哪会想到这种边缘情况？

有个失败案例特别典型：某次用`sed -i`直接改Nginx配置文件，结果因为用户没有写权限，整个脚本卡在等待输入密码的界面。后来改成先`chmod 644`再修改，最后再`chmod 600`恢复权限——这种对文件权限的精细控制，手动配置时容易忽略，但自动化脚本必须考虑到。现在脚本里光是权限相关的操作就有12处，全是踩坑踩出来的。

新技术带来的便利太明显了——比如用`systemd`的`TemplateUnit`功能，脚本能动态生成`nginx@h5_project.service`这样的单元文件，不同项目用不同的实例名，互不干扰。再比如MySQL的`--initialize-insecure`参数，配合脚本里的`expect`模块，能自动完成初始化而不用手动输入临时密码。这些玩法，五年前的配置工具根本做不到。

不过说实话，这脚本也有局限——它假设服务器是干净的新系统，如果之前装过相关软件，可能会因为残留文件报错。比如有次测试时，系统里已经有个旧版Redis在运行，脚本里的`systemctl stop redis`没生效，结果端口冲突。后来我加了段检测逻辑：`if systemctl is-active redis; then systemctl stop redis && systemctl disable redis; fi`。但要是用户自己改过服务名，这招还是不管用——自动化配置的边界，到底该管多宽？

下一步我打算把脚本改成Ansible Playbook，用变量控制不同项目的配置差异。比如前端项目可能需要开启Gzip压缩，后端API项目需要配置SSL证书，这些现在都得手动改脚本，用Ansible的`vars`和`when`条件判断会更灵活。不过话说回来，Shell脚本的轻量级优势还是明显——一个300行的Shell脚本，比等效的Ansible代码少一半，执行速度也快不少——到底选哪种方案，得看具体场景。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!