离线内网环境部署更新问题记录

文章目录

    • 低级错误
      • 错误一 配置文件参数错误
      • 错误二 文件位置错误
    • 压缩包解压问题
    • 浏览器版本问题
    • 经验教训

  • 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)和浏览器

你可能感兴趣的:(异常报错,linux,运维,服务器,离线内网环境)