最近部署hy记事
这段时间摊上了个挺恶心的项目,叫什么hy鞋同平台。。前后左右整的人挺难受的。学到的东西特别少,而且比较浪费时间。不过,还是总结一下吧,好歹花了这么久的时间了
Doc管理xi tong
话说这个hy平台的起因,罪魁祸首就是6月份开始调研的wen dang管理系统。只从技术角度说说吧。
audit 审计
我这块负责审计功能的开发,就是把用户在系统上的操作都记录下来。这儿最初的思想十分简单,就是找到源码中相应的执行操作的点,把审计函数插入进去就行了,传入一些相关的参数即可。也是第一次接触django,刚开始手足无措,后来才知道有url.py文件,才慢慢从前端js跟踪到了后端的python函数,将审计函数插入其中。刚开始做的时候想起了linux系统自带的审计,记得它也是将某个审计函数插入在所需的地方,然后通过一些配置文件能够对审计的开启、关闭,审计信息的详细程度进行配置。我们这里就不用这么复杂了。。写了个简单的审计函数,先将数据丢进es去了。之后有了其他组做好了mysql Rest API,就把es换成他们得api了。其实都是一样的:写了个函数,调用python的curl模块,继而调用Rest API。后来发现有时curl速度比较慢,影响到了用户的页面体验。然后就调研django异步执行框架celery,将curl函数一包装,放进celery的worker里执行,这样就不影响页面响应速度了。不过,这里还没有做的地方是审计函数的执行结果没有进行判断(成功or失败?)。其实想了一个方案,把结果丢进redis里,随后找个午夜时间(定时执行也靠celery框架)用相关函数处理一下(但后来没实现这方案)。
部署django项目
哎呀,这块刚开始时候可是被整的。。系统依赖的软件包、python模块相当的多,而且没有提供自动部署脚本,导致大量时间浪费在了部署上面。不过,也正因为此,才导致我遇见了docker这货。当时由于部署复杂,开发组专门提供了一个虚拟机镜像,里面预装好了所有依赖包。但是该镜像居然有8.0G大小,携带、传输都十分困难(百度网盘也不支持这么大的。。。),导致没有什么卵用。然后就想起了过年来的时候调研过docker,它不就是做依赖包封装、持续集成用的吗?很兴奋的用起docker来,果不其然,特别方便,镜像做出来也特别小(很少超过1G)。更好的地方是部署、迁移、更新、启动、关闭速度都远远优于笨拙的虚拟机。接着,我将本机的所有服务都搞成docker容器了。。。(当时热衷于此,觉得是赶时髦了),然后还搞了mesos+zookeeper+marathon来管理本机的这5、6个容器。真是不亦乐乎。要说docker有什么缺点,那就是无法跑在win系列机器上(但是听说win也支持docker了),其他方面都是优点,用起来大大的爽,部署时间从2-3天减少到2-3个小时。
随着docker使用的频繁,也想试试持续集成是什么鬼。于是自己鼓捣出一个方式。由于在本机之前搭建过一套gitlab服务器,就想着怎么能把他们联系起来。我写好代码之后,push到gitlab上,然后利用git的hooks方式,判断本次commit的代码注释(-m)是否带有[deploy]字样的,如果有,就进入一个特定目录执行pull操作。该特定目录是mount在docker容器内的。还是在hooks这个脚本中,执行docker exec命令,进而在容器内部执行部署脚本(部署脚本也是在commit的源码中)。然后就大功告成了,容器中会对源码进行编译、安装、服务启动。也就是说,开发完后直接执行push,然后就等着刷新浏览器吧!自以为体验到了持续集成的一点小优势~(但是整个过程的最后一步docker exec没有实现,当时好像是因为docker版本太低,还不支持exec命令。当时都是人工进容器,然后执行部署脚本的。。。)
此事后记:从此对docker感兴趣,最近又自己看了看go语言的书 。。。想着啥时候能看看docker的源码呢!
被逼使用Openstack
不知是为了实际作用还是说为了能让项目花哨点儿、有料点儿,后来提出了让各个服务部署在Openstack虚拟机上,列出了一堆堆Openstack的优势。
但是当时的形势是我在自己机器上已经通过docker基本构建起了hy平台的各项服务,又因为对新东西Openstack不熟,所以情绪还是蛮抵制的。不过也是久闻大名了,也看到很多帖子写到为什么docker能替代Openstack的争论,后来还是老老实实开始了Openstack的调研(其实主要是领导热衷于这个。。 我当然不得不去做了)。
但是,此处应该记住教训,不要对新东西犹豫不决,不去用过,是没有发言权的。
云计算这么火,Openstack作为云平台的管理软件,起着核心的作用。我们的hy平台运行的服务大概有5、6种,初步思想是把每种服务都单独运行在一台实例上。于是乎开始调研,然后尝试安装K版;在安装基本完成时,官网又发布了L版。。
下面总结这个过程中的关键点。首先是部署结构的设计。devstack使用单机部署所有服务,但官网的手动部署教程是使用控制、网络、计算三节点的部署方式。我使用后者在virtualbox上搞了一套L版。然后,最重要的就是网络配置部分,这里要首先理解原理然后再进行部署才行。在这块刚开始弄的时候,一头雾水,搞了3、4天没有头绪,因为想赶紧把环境搞起来,但是根本不了解原理,瞎打瞎撞。这些相关资料网上都有,而且这里的思想就是SDN,学习一下这些技术还是很令人兴奋。最后,还有一个关键点是备份。我们部署中间有一次断电了,然后重启后各种都起不来。。 这时所需的应该是将虚拟机镜像进行断电前备份、断电后导入;导入包括从控制节点1导入控制节点2、从控制节点导入宿主机kvm,其实方法都是一样,就是把实例的虚拟磁盘搞出来就好,这块要理解kvm虚拟磁盘的格式、backing file、打快照的方法等。
被文档折磨的死去活来
需求文档写了将近一个月,紧接着开始写设计文档。实际上我们的系统基本已经成型(反正是基于开源的搞的),但是上面要求用写文档的形式理顺目前做的事。
写文档过程中的经验教训。首先,心态要好。做程序猿虽说应该以代码为重,但是文档任务也不能掉以轻心。能叙述的清楚的程序猿,编码起来才能行云流水。文档中的文字描述、流程图之类的能很好的帮助思路。不要抵制,既然是工作,就不是自己想怎样就怎样的;任务分下来了,那就认真对待,好好做。不要区分任务的等级高低、类型贵贱(不要分脏活累活还是好活),不管啥活,用心认真做了,学到的东西就是自己的。然后,网上粘贴的东西要仔细过两遍,不能为了堆砌篇幅而瞎贴。其实还是回到之前说的,不要用应付的心态去做这件事。
是挺难受的,我承认。需求文档、设计文档写了好几稿,都被打回来。还是那句话,对于有些任务,真的心态要好。
补充内容
这次项目让知识面拓宽了不少。一直在思考是要广还是要精的问题,在目前的工作环境下,做的活杂七杂八,接触东西很多,在广上有优势。但我还是想确定好自己的方向,比如云计算,比如虚拟化。兴趣我是有的,但这得自己努力了。听说要做开发者很难的,每天下班、周末都应该去学习、看代码的。自己还是差太远了。