- 2022年入职的新公司,是一家小型公司,暂时没有专业的运维人员。我入职后,承担起我们团队研发项目的运维工作
- 一方面,承担起将平台项目打包部署的到测试环境,持续集成,配合测试人员测试
- 另一方面,我们研发的产品慢慢向市场铺开,要承担起客户环境的部署与更新。这方面还好,我们的交通优化工程师出差,我负责远程电话视频支持(客户内网,不允许远程)
- 在此过程中,遇到了各种各样的问题,在此记录下。
低级错误
错误一 配置文件参数错误
- 在与现场实施人员沟通时,出现信息错位,实施人员发来的截图里的ip地址不是正在使用的ip地址(机器重装系统且换了ip地址),而我不知道这个信息
- 我们使用
docker
部署平台,使用docker-compose
管理所有组件,使用nginx
作为静态文件的代理服务器,我们的nginx
配置文件和docker-compose.yml
配置文件,需要填写客户现场的实际ip地址 - 由于我们的优化工程师大多不熟悉
Linux
系统,我会将配置文件修改好发给他们部署,错误的ip地址导致我传输过去的配置文件错误 - 服务部署可以正常启动(代码配置都没问题),但是应用无法访问。后面看到他发的新的测试访问页面截图,才发现ip不一致,浪费了一两个小时时间
错误二 文件位置错误
- 有一个文件的位置放错了,打成压缩包发给现场实施人员后,执行结果不符合预期
- 根据报错信息,一开始怀疑是实施人员使用的账户不是root账户,文件权限问题
- 后来发现确实是自己打压缩包时,有2个文件放错了文件夹
- 在本地测试时,自己直接拖动文件上传,更新部署启动都没问题,测试也没问题,也就没有发现文件夹路径错误
- 由于前面进展很顺利,打成整个更新部署压缩包时,就没有对整个压缩包进行测试,导致在实施人员实际部署过程遇到报错,才排查发现该问题,浪费了一两个小时
- 此处得到的教训:最终发给实施人员的文件,最好发之前测一遍,保持一致性
压缩包解压问题
- 我们微服务和中间件全部使用
docker
部署,将Spring Boot
程序打包成tar
包镜像 - 部署时,按照服务器里的文件目录结构,将需要更新的服务tar包和静态文件按照目录结构放好,再整个打成压缩包交给实施人员
- 以前是实施人员将压缩包通过U盘拷贝到客户电脑,先解压,再通过传输工具上传到
linux
系统。为了简化实施人员的操作步骤,将解压这一步放到更新脚本里(直接把整个压缩包上传到linux
系统指定文件夹) - 前两次更新界面等静态资源,没有遇到问题
- 上周更新部署后台服务时遇到问题,显示tar包损坏,无效的tar头,无法识别使用
Error processing tar file(exit status 1): archive/tar: invalid tar header
- 在
windows
系统压缩页面文件、tar
包为zip
后,在linux
里使用unzip
解压,出现了tar文件损坏
,无法load
镜相 - 还是需要在
windows Server
里先解压,再使用传输根据传输进linux
系统
浏览器版本问题
- 很多客户的机器很老,
win7
系统,老版本浏览器。而且在内网环境,无法去下载更新浏览器 - 现有的
B/S
应用一般只会适配主流浏览器,我们的平台在老版本浏览器里也出现过js
加载报错 - 而且不仅是我们的平台系统界面,一些中间件的可视化界面,例如
consul
,也是对浏览器有要求的,太低版本的浏览器就会页面空白,加载不出来 - 需要提前准备好一些比较新的浏览器版本的离线安装包,谷歌、火狐、360都可以
经验教训
- 对于无法联网的部署环境和不是很熟练的实施人员,需要尽可能简化流程,并将更新部署文档写的详细点,多加截图
- 大多数参数配置都是不变的,对于需要变动的配置,应该和现场实施人员反复确认好,保证一次部署更新成功
- 现场实施人员,虽然可以协助做一些文件上传和脚本执行的工作,但是对于排错,有点困难,远程视频和拍照都很模糊。由于对开发和linux环境不熟悉,双方配合起来也很麻烦。对于交付给现场实施人员的更新包和更新脚本,不要盲目自信,要在公司模拟相似环境测试一下,实际运行下脚本,查看是否有报错,提前处理掉,保证一次部署更新成功
- 对于离线内网环境,多准备一些可能用到的软件的离线安装包,尤其是文件上传工具(如winscp)和浏览器