hy这个破项目

最近部署hy记事

这段时间摊上了个挺恶心的项目，叫什么hy鞋同平台。。前后左右整的人挺难受的。学到的东西特别少，而且比较浪费时间。不过，还是总结一下吧，好歹花了这么久的时间了

---

Doc管理xi tong

话说这个hy平台的起因，罪魁祸首就是6月份开始调研的wen dang管理系统。只从技术角度说说吧。

wendang管理系统调研:

• Sea-(f！)ile 国产的，广告做的挺响亮，下一代wendang管理软件.
• Open-(K！)m 国外的开源软件，Java写的，功能挺全面，但是就是很复杂
• 调研情况：后者使用到了很多的Java组件，各种各样的什么都有。对于我Java盲而言确实比较费劲。但第一次接触到了Java的强大，而且理解为什么企业系统是Java在一统天下（如果有一天能有机会接触Java项目，我肯定第一个上）。
  -- tomcat服务器：企业级的应用服务器，保证了稳定性和效率
  -- hibernate数据库驱动：任意连接所有数据库，强大到无法自拔
  -- elasticsearch及其基于的lu什么搜索引擎：搜索就靠它了，无缝集成毫无问题
  -- 还有Spring框架什么的，这个我一点不懂
• 开源选型最后定为了前者，尽管后者功能强大，但是据说主体开发团队不喜欢Java，于是乎，python和C胜出了。从此开启了痛苦的开发历程。

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、打快照的方法等。

被文档折磨的死去活来

需求文档写了将近一个月，紧接着开始写设计文档。实际上我们的系统基本已经成型（反正是基于开源的搞的），但是上面要求用写文档的形式理顺目前做的事。
写文档过程中的经验教训。首先，心态要好。做程序猿虽说应该以代码为重，但是文档任务也不能掉以轻心。能叙述的清楚的程序猿，编码起来才能行云流水。文档中的文字描述、流程图之类的能很好的帮助思路。不要抵制，既然是工作，就不是自己想怎样就怎样的；任务分下来了，那就认真对待，好好做。不要区分任务的等级高低、类型贵贱（不要分脏活累活还是好活），不管啥活，用心认真做了，学到的东西就是自己的。然后，网上粘贴的东西要仔细过两遍，不能为了堆砌篇幅而瞎贴。其实还是回到之前说的，不要用应付的心态去做这件事。
是挺难受的，我承认。需求文档、设计文档写了好几稿，都被打回来。还是那句话，对于有些任务，真的心态要好。

补充内容

这次项目让知识面拓宽了不少。一直在思考是要广还是要精的问题，在目前的工作环境下，做的活杂七杂八，接触东西很多，在广上有优势。但我还是想确定好自己的方向，比如云计算，比如虚拟化。兴趣我是有的，但这得自己努力了。听说要做开发者很难的，每天下班、周末都应该去学习、看代码的。自己还是差太远了。