方案概述

本技术方案为基于kubernetes(下文简称K8S)为核心的持续部署(下文简称CD)方案，可以满足开发方的程序级日志查看分析，运维方的快速扩容与日常运维分析，并且可以保证用户的服务体验。并且整套放在可以在资源利用率上进一步提升，在不降低服务可靠性的前提下降低资源使用成本。

使用场景分析

本方案适用于以Tomcat为容器的JavaWeb项目的持续部署过程，在K8S方案中，所有的Node节点均采用统一配置，根据业务环境的需求进行节点数量的控制

技术架构与选型

为加固当前服务器管理的安全性，解决现阶段多个入口的登录方式，推进资产统一使用堡垒机（JumperServer）进行管理

JMS部署架构

基于JMSV1.0修订部分

• 修订JMS节点相关数据结构，加快JMSZtree的生成速度(20s->2s)
• 阉割web terminal(取消掉此功能)
• 阉割资产信息、节点信息的编辑操作(每三分钟与中心应用进行同步)
• 取消每次程序启动执行的资产信息检测，将定期检测修订为每2小时一次
• 阉割coco的分组显示功能(分组无法有层级结构，遂取消，建议使用搜索)
• coco只允许使用密钥登录(不允许使用密码登录)
• 修复重置公钥BUG(管理员重置公钥时不生效BUG修复)
• 默认ssh连接超时修订为30s，修复不支持10s以上超时显示BUG(目前最多支持两位数)
• 禁止删除ROOT帐号(安全性考虑防止用户误删ROOT帐号)

前言

鉴于去年的总结拖延症问题，今年的总结整理的时间还是比较早的，回顾今年的一整年的生活及工作，各方面都在有条不紊的进步，但整体来说我自我感觉对本年度并不是特别满意，其实这也是一个矛盾的体现，生活、工作上事事顺利是努力的目标，但向这个目标努力也越发感到危机，今年比较郁闷的是原先的Blog域名忘记续费了，然后被抢注了，还挂上了六*彩，郁闷！等它到期再买回来吧。好了，感慨就发到这了，下面开始回顾2017年度的大事件吧！

2017大总结

比较惭愧，“2016大总结，2017大畅想”中没有畅想！今年好好畅想。

生活篇

阅读

今年没有读几本书，自己的阅读能力这几年在逐年下降，现在越来越不愿意进行完整化的阅读了，但碎片化的阅读又非常没有营养，今年要立志改善！尽量避免碎片化阅读，像什么刷今日头条、脉脉、微博等今年要一刀切拒绝！阅读的目标转向得到、即刻、知乎、豆瓣。并且今年重启豆瓣主页，在阅读的书籍方面，仍然以技术方向为主（偏技术底层），管理、民科为辅的阅读。

PandoraBox | 私密信息传递工具

基于非对称加密(RSA)的私密信息传递工具，数据由本地客户端进行加密、解密操作，密文通过网络进行传输，确保信息的安全性！
– Browse Website –

系统介绍

PandoraBox 由Server与Client两部分组成，Server使用Java SpringBoot编写，数据存储为Mysql，欢迎页面使用iview编写；Client使用C#编写，数据存储为sqlite，Client使用inno setup打包为安装包。且为了方便快速的信息发送，Server的数据结构内需要维护一套用户验证体系与用户组织结构，目前PandoraBox仅可发送文本信息。

经过一年的敏捷管理实践，基于PO制的敏捷模式在团队内效果良好，尤其是运维团队中，让运维的工作更具有节奏性且工作更为紧密。好的方面有很多，但是其中也发现很多的不足。

• 流程规范中众多的章节都是偏向于开发团队的，很多场景不适合运维团队
• 业务文档，技术文档拆分太细，不利于成员的理解与界限隔离
• 太过于依赖于会议进行沟通，导致开会前准备不足，会议效率过低

基于以上的问题，我们针对2017版的指导规范进行了需要重要的调整，合并运维项目管理与开发项目管理，规范更名在“敏捷迭代管理”，简化会议流程，追加需求实现规划阶段。

下面来看一下新版的规范

非常有幸作为2017GITC的运维专场演讲嘉宾参与本次GITC，下面是本次演讲的内容。

各位运维同胞们早上好，很高兴来到GITC运维专场跟大家共同交流分享我以及我们团队在运维上的一些认知、经验以及历程，来参加GITC好几年了以往都是在会场下聆听，这次站在讲台上还是有些激动哈，好的，下面就开始我本次的主题《开源运维自动化平台架构实现与运营实践》。

开始之前先做个自我介绍，我目前所供职的公司为光宇游戏，是研发、运营、发型一体化的网游公司，我是在2012年加入的光宇游戏，目前负责运维架构、自动化平台、大数据平台的建设及人员管理工作，本次主题主要是分享一下在自动化平台建设方面的一些历程。

本次主题的议程分为三个部分,第一部分为运维系统平台化建设思考，主要介绍一些光宇在运维自动化过程中的一些历程以及思考的一些问题；第二额部分为ELVES开源运维自动化开发平台，主要介绍光宇在解决平台化建设过程中发布的一款针对开发运维自动化平台的一款开源产品；第三部分为光宇游戏平台化建设运营实践，主要简单介绍光宇在运维自动化平台的几个重点组成部分。

社区CC防火墙是公司对外提供服务的WEB站点的一层防护屏障，可以过滤访问请求，识别出攻击者，并与之屏蔽，保证WEB站点安全稳定的运行，新一代的CC防火墙产品是前一代的基础上在架构及功能上的一次重大革新

• 新算法的应用，可缓解、抵御所有web站点遭到CC的攻击强度。
• 整合不同部门的防火墙类产品，降低开发成本，增强用户体验。
• 针对攻击IP的访问行为进行特征分析，增加分析维度

Architecture

规划概述

根据公司的整体战略需求，公司IDC资源在逐步向公有云进行过渡，基于公司混合云的管理思路，并根据目前IDC的问题，对现有IDC规范化统一改造，主要针对主机，网络互联等进行一次较大规模的革新。

混合云网络整体架构

架构描述

• 公司混合云架构融合专线、VPN、互联网三条网络线路方案，实现网络传输的可靠性
• 所有IDC均设置一个10.x.0.0/16位地址段
• 所有IDC间内网实现互通，并可以自主选择使用专线网络或VPN网络
• 办公网均通过10.x.0.0/16位地址段进行主机的管理

SmartPing

SmartPing为一个各机器(点)间间互PING检测工具，支持互PING，单向PING，绘制拓扑及报警功能。

功能

• 单向PING，反向Ping绘图
• 互PING间机器的状态拓扑
• 自定义延迟、丢包阈值报警

设计思路

本系统设计为无中心化原则，所有的数据均存储自身点中，默认每个Ping目标点的数据循环保留1个月时间，由自身点的数据绘制 出PING包 的状态，由各其他点的数据绘制 进PING包 的状态，从任意一点查询数据均会通过Ajax请求关联点的API接口获取其他点数据组装全部数据，绘制 出Ping曲线图，进Ping曲线图，网络互Ping拓扑图。并可以设置阈值进行报警，方便对网络质量的监控。

项目截图

欢迎关注Elves-Project

自动化运维开发平台

Elves-Project 才刚刚起步，欢迎更多的人加入我们，共同见证其成长！

QQ群：69748845

作者列表

• toryzen
• eastFu
• 光宇游戏系统部

贡献列表

• Zhangguangxin
• Liyong
• Xiehuanhuan

如果您在使用Elves，那么可以修改_ huan-ying.md__ , 然后提交pull-request到gy-games/elves-book，等待merge过后，即可在这里显示。_