记一次Go项目打包部署

记一次Go项目打包部署

快一个月没有更新博客了,可以看到之前的主要博客内容都是一些偏向于面试的内容,因为实习期间也没那么多给我自由学习的时间,所以更新的频率也就低了,另外一点也是自己基于博客内容的考虑吧,不想把博客和学习笔记混为一谈,写一些专题的总结,或者是遇到的问题以及解决方法,这是我对今后博客内容的期待,而不是将一些学习笔记铺天盖地的放上来,这里不是走量的,不多说了, 进入今天要写的正题吧。

最近完成了一个管理端的操作历史模块的功能需求,在本地完成编码测试之后,需要上到测试环境一下,目的就是不是我一个人进行测试,其他人在本地hosts文件中配置域名之后,也可以进行访问,因为是第一次搞Go的部署,自然也是是踩了一些坑,做个记录。


想要在服务器上部署项目,那么第一件事情自然就是找到服务器,企业级服务器和个人的不一样,这也是我今天遇到的第一个问题,就是堡垒机,这个概念之前没怎么接触过,具体太深入的咱也不用知道太多,这是功能的介绍:

image-20200805191742868

我理解的是他的作用和名字很像,他就是企业里面服务器的一个堡垒、城墙,如果想要访问服务器,那么就需要先过这一关,主要还是方便了运维吧,可以看到上面的功能确实强大,实现了一种权限验证分发的功能。今天使用客户端ssh的方式疯狂怼后面的容器ip,我也是太楞了,好在后面出坑了。

另外一点就是两个主机直接文件的传输问题,也让我第一次在生产环境上亲身体会到了,开发为什么一定要用苹果,正常的通用上传命令是:rz,应该是这个命令的问题,这是具体的传输情况:

image-20200805192233864

这倒怪不得人家widows,能够想到的就是使用其他的传输命令替换这个rz,没错,就是scp

不过scp的命令是这样用的:

看到了吧,源文件路径得是这样婶的,而我们的windows文件路径那种反斜杠形式的,放进去直接报错,这确实没办法,只能使用rz等待了。


另外一个遇到的问题就是Go项目的打包问题。

看了网上的教程,我直接就使用go build main.go进行打包,然后中间还使用rz上传了两次,花费很长时间,上传成功执行后发现了一个问题:首先,运行日志中缺少配置信息,我手动的将配置信息导入之后,访问出现了这个情况:

image-20200805192832467

我的第一感觉就是缺少静态文件,原来,使用build这种方式打包,只是将可执行文件的linux形式发过去了, 这个可执行文件的一些上下文依赖,例如配置信息、静态文件,全部没有带过去,正确的做法是使用beego框架的bee命令来做

bee pack -be GOOS=linux -f=zip

我老老实实的在项目路径下执行:

image-20200805193145158

也就是没有bee这个可执行文件的意思呗,去安装

找到了bee.go这个文件,我们来手动编译一下,估计编译完就可以出来可执行文件bee.exe

image-20200805193743147

额,失败,继续递归找下去,环境问题往往是最恶心人的,而且带有劝退性质,刚下去就好了

是代理出现问题了,在系统环境变量中配置了代理变量,然后就可以进行正常的编译了:

image-20200806105212622

将GOPATH/bin放到环境变量中的path下面,然后:

image-20200806105709891

可以了!!!

然后,执行我们正确的打包命令:

bee pack -be GOOS=linux -f=zip

image-20200806105835944

接下来就是使用rz进行龟速上传环节:

image-20200806110201437

估计怎么也得两个小时吧,该干嘛干嘛去吧,散了吧


上传完成,在测试环境服务器进行解压,然后使用启动脚本进行启动

在本地配置好域名映射之后,就可以进行访问了!

image-20200806224608333

明天进行测试~希望不要回炉~上传一次耗时太大了~