公司上线流程 pushonline_alpha

 这是在公司将服务部署上线的一个记录，只是部署很小的python脚本，各公司不同，参考性不是很大

开始吧（版本管理是git）

1.整理好代码后：git add xxx.py

git commit -m "输入这次提交的说明"

2.代码review：git push origin HEAD:refs/for/master%r=username, r=XXX

在公司相应得review管理网页中中找到相应的提交，review通过后submit就好

3.原来就在master分支上，就不用这步了，如果不在的提交到master分支上去

git push origin HEAD:master

4.开发机上 输入Pushonline_alpha 我的理解是将代码提交到远程的机器上去。然后就等代码部署好

关于pushonline_alpha命令是个什么东西，看下面这个：

背景

由于业务规模扩大，pushonline的速度和稳定性已经不能满足业务需求；所以基于nodekeeper，开发了新的上线系统；由于新的系统处于小流量阶段，所以暂时取名pushonline_alpha。老的pushonline上线的流程是先由一个server打一个bundle，然后放到hdfs，再ssh到所有需要上线的机器，然后将bundle下载下来再apply完成上线。这个过程首先是受限与上线的单机能力，所以在处理一些上线机器众多的情况效率会非常低。另外，由于上线以来ssh，所以上线会很不稳定，遇到一些负载高的节点会拖慢整个上线。HDFS作为离线存储，实时性比较难保证，上传下载bundle经常会hung住一段时间。最后，新增节点的库应该上什么版本并不知道，需要专门的初始化的过程。

实现

pushonline_alpha摒弃了ssh的思路，采用基于nodekeeper的方案来实现。nodekeeper简单来说是采用了Master-agent的框架，每个机器会有一个agent与Master保持心跳，Master通过心跳下发agent需要执行的命令，已经执行过的命令会定期检查其状态，保证机器的环境处于一致的状态。因此新增机器也可以通过增加tag来完成节点初始化，详细介绍可以参考nodekeeper。

另一方面，pushonline_alpha也废弃了同步打bundle的方案，采用一个bundle service来订阅gitlab和gerrit的push事件，收到新的push事件后，会马上开始打bundle，上传到一个maven库，需要上线的时候，直接从maven库下载就可以，节约了打bundle的时间。

用户调用pushonline_alpha上线，实际上只是记录一下当前的commit_id，然后向nodekeeper提交一个命令将XX库更新到XX commit，然后交给agent去执行，并定期从nodekeeper获取执行的进度。

5.切换管理员用户（最高权限的用户）。在开发机上ssh user@10.2.xxx.xx 如果发现要输入密码的话，先退出来，输入kinit命令，输入你的邮箱密码。然后在ssh就好了。   切换用户后  用gg 命令就跳转到想要把服务跑起来的机器上（gg 22.161这样）

6.在机器上看下git的代码是不是已经是修改完毕的代码，然后:

（1）进入/home/tiger/.server 目录 ，在这个目录下建立要启动服务的软链，就是建立real_run所在的文件夹的软链

软链就相当于一个快捷方式的感觉，用命令： ln -s 目标文件夹 服务名称      来建立

（2）有些机器没找到.server目录 ，在/home/tiger/.config/systemd/user/ 下执行相同的操作

7.建立连接后 服务就启动了，svc命令来处理服务相关

svc -d 服务名称   ：停止服务

svstat 服务名称  ：查看服务状态，如果启动时间一直是0s,1s的就说明没启动起来

svc -u 服务名称 ：启动服务

svc -i 服务名称  :重新启动服务，查看状态时，启动时间会更新

8.注意，启动的脚步需要有执行权限，遇到了服务怎么都启动不起来，就是real_run脚本没有x权限，要chmod +x 添加下权限

9.关于脚本怎么写，可以在.server文件夹下随便找个服务看看人家的怎么写，基本上格式都一样，改个执行py文件的地址就好