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来管理本机的这五、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平台运行的服务大概有五、6种，初步思想是把每种服务都单独运行在一台实例上。因而乎开始调研，而后尝试安装K版；在安装基本完成时，官网又发布了L版。。
下面总结这个过程当中的关键点。首先是部署结构的设计。devstack使用单机部署全部服务，但官网的手动部署教程是使用控制、网络、计算三节点的部署方式。我使用后者在virtualbox上搞了一套L版。而后，最重要的就是网络配置部分，这里要首先理解原理而后再进行部署才行。在这块刚开始弄的时候，一头雾水，搞了三、4天没有头绪，由于想赶忙把环境搞起来，可是根本不了解原理，瞎打瞎撞。这些相关资料网上都有，并且这里的思想就是SDN，学习一下这些技术仍是很使人兴奋。最后，还有一个关键点是备份。咱们部署中间有一次断电了，而后重启后各类都起不来。。 这时所需的应该是将虚拟机镜像进行断电前备份、断电后导入；导入包括从控制节点1导入控制节点二、从控制节点导入宿主机kvm，其实方法都是同样，就是把实例的虚拟磁盘搞出来就好，这块要理解kvm虚拟磁盘的格式、backing file、打快照的方法等。

被文档折磨的死去活来

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

补充内容

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