运维平台化saltstack和jinja2模板构建高可用集群配置平台

简介:

    最近正在做一个集群配置平台,以前也做过类似的demo,记得是去年做的时候用的是paramiko模块,先说他的连接配置是用ssh,交互也有时用pexpect。在复杂的配置下会经常出问题的。 配置主要是出在正则匹配的方面。


   现在到了新公司,第一件是就是重构代码,目的是做成一个全网集群的配置工具,支持nginx、lvs、haproxy多种集群配置的平台。 里面含有流程的自动流转审批,在测试服务器上做测试,配置文件的操作之前的配置,及出问题时候的回滚。


因为新公司的环境是puppet,打算推广下saltstack !  我还是喜欢saltsatck那种简便的二次开发。

自己现在的思路是:  

通过web框架的模板来渲染配置配置,最好是把nginx.conf keepalived.conf 整形到 yaml类似的格式里面。推送到客户端只是get url,通过接口的ip和类型,给你渲染出配置文件,直接下载就行了。


这能说是没招呀~  哎。。。。   saltstack 这东西不错 !


下面的集群管理平台,我自己也就写了两天,把前端页面及后端的mysql库做了设计。  我会把后续思路和解决方案更新给大家下。  还没有上线,只是给大家一个样子参考 ~



前端没啥东西,就是写了点表单的验证,及美化的js特效。

wKiom1M6ekyARktGAATtBF09qOY127.jpg


对于集群的参数,做了特定的格式规范 !

wKiom1LSryTTW3E5AAOKH9yeokI259.jpg


特殊说明,这里可以填写一些特殊的需求 !

wKioL1LSr0PyLbBHAAOsh6w7FW0163.jpg


点提交后,会给领导发邮件等待确认~

wKiom1LSr1uCRJ1QAAOaHZOWLbw197.jpg


数据是随便写的 ~

wKiom1LTpS2QdnojAAKS8XHPWaI010.jpg


mysqldb 获取timestamp的出现点问题,大家可以参考下 ~


1
2
3
ValueError
ValueError: unsupported format character  'm'  ( 0x6d ) at index  138
Traceback (most recent call last)


对于%的符号,尤其格式化时间用的多,需要这么搞

1
FROM_UNIXTIME(unix_timestamp(ltime), "%%m-%%d %%H:%%i" )


wKioL1LTt6ij5BNqAALSOwDK3SY134.jpg

领导说,页面看起来不舒服,改版

wKioL1LU8dPTvIzyAAWIuyfVO1w614.jpg



wKioL1LWITbQGBJRAAQHXGoCUpk601.jpg


wKioL1LXrA6jFcHCAAMZUWP0OwQ803.jpg



wKiom1LZDsvga53tAAK6gaoIwL0240.jpg

关于saltstack这边对于lvs yaml的过程


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
global_defs: ruifengyun@xxx.com
vrrp_sync_group: [VI_1,VI_2]
vrrp_instance:
     VI_1:
         state: master
         interface : eth0
         virtual_router_id:  51
         priority:  100
         advert_int:  1
         authentication:
             auth_type: PASS
             auth_pass:  1111
         virtual_ipaddress:
             vip:  192.168 . 1.100
         virtual_server:
             delay_loop:  5
             lb_algo rr: wlc
             lb_kind DR: DR
             persistence_timeout:  50
             protocol: TCP
             - real_server:
                 ip:  192.168 . 1.236
                 port:  80
                 weight: weight
                 mode: HTTP_GET
                 heathmonitor:
                     path: /mo/monitor.html
                     connect_timeout:  3
                     nb_get_retry:  3
                     delay_before_retry:  3
             - real_server:
                 ip:  192.168 . 1.236
                 port:  80
                 weight: weight
                 mode: HTTP_GET
                 heathmonitor:
                     path: /mo/monitor.html
                     connect_timeout:  3
                     nb_get_retry:  3
                     delay_before_retry:  3


wKioL1Lc16DjfiqUAANifrJPvJg099.jpg

遇到了一个问题,jinja2的list循环的时候取出他的index 。

这里是用在lvs haproxy nginx的数据渲染的 !


1
2
3
4
5
6
{ %  for  in  ldata[ 'vrrp_sync_group' % }
        {{ ldata[ 'vrrp_instance' ][ 'VI_1' ][ 'virtual_ipaddress' ][loop.index0][ 'vip_server' ][ 'vip' ] }}
{ %  endfor  % }
{ %  for  in  range (ldata[ 'vrrp_sync_group' ]|count)  % }
        {{ ldata[ 'vrrp_instance' ][ 'VI_1' ][ 'virtual_ipaddress' ][loop.index0][ 'vip_server' ][ 'vip' ] }}
{ %  endfor  % }


已经渲染好keepalived.conf 的测试页面

wKioL1LfGYKhRMniAAHP6cUoIDA018.jpg


wKiom1LkyazAnk1rAAXnpn5obao825.jpg

wKiom1Lk2Q-AfgfSAAN2FEhYrw4712.jpg



样式更新了下,都放在一起,确实有点紧

wKioL1M6GWGjkZdAAALnrHD7agc602.jpg



wKiom1L5ozaQiEISAAdjWaajjBA886.jpg


又加了几个功能,把昨天写的逻辑重新变更下,明天开始做后端 !


wKiom1L67BrSEYg8AAfk0OOSZBU935.jpg


实时流量图


wKioL1L8c0eRu8aIAAZ_E2uyt9E732.jpg


wgetconf


jinja2的一个问题    {% if type == "kkk" %} 里面的type是jinja2里面的关键字  大家避开这个关键字就行了。。。 原本以为是自己逻辑的问题,搞了半天是关键字的冲突 !!!




wKioL1MBvELy4G0EAAUh_GX0tig162.jpg

这个实现的原理就是利用saltstack的pubsub速度,实现实时数据收集 !


wKiom1MC-_XhfrdiAAMpZ8eHE54321.jpg


这两天在忙dba的平台,这个东西进展有点缓慢!

wKiom1MQbA7CtDZ5AAKc9L0E00M995.jpg


wKiom1MQbBixiOD7AAPB8MqMQsw535.jpg


加了表单验证

wKioL1MZgpvTk_NuAALhO-TV04k330.jpg

针对返回值的各种判断,和连续ajax

wKiom1MZg8rRkccWAAN__tAhorU183.jpg


服务器的本身调试页面!

wKiom1Mi2OrQ9RbnAAeL2oXLUwU317.jpg

日志图表分析

wKiom1MlPUzRXqObAAQDcpFVtUA937.jpg





 本文转自 rfyiamcool 51CTO博客,原文链接:http://blog.51cto.com/rfyiamcool/1351068,如需转载请自行联系原作者



相关文章
|
3月前
|
运维 监控 Linux
WGCLOUD运维平台的分布式计划任务功能介绍
WGCLOUD是一款免费开源的运维监控平台,支持主机与服务器性能监控,具备实时告警和自愈功能。本文重点介绍其计划任务功能模块,可统一管理Linux和Windows主机的定时任务。相比手动配置crontab或Windows任务计划,WGCLOUD提供直观界面,通过添加cron表达式、执行指令或脚本并选择主机,即可轻松完成任务设置,大幅提升多主机任务管理效率。
|
6月前
|
存储 人工智能 运维
阿里云操作系统控制台评测:国产AI+运维 一站式运维管理平台
本文详细评测了阿里云操作系统控制台,作为一款集运维管理、智能助手和系统诊断于一体的工具,它为企业提供了高效管理云资源的解决方案。文章涵盖登录与服务开通、系统管理与实例纳管、组件管理与扩展功能、系统诊断与问题排查以及实时热点分析与性能优化等内容。通过实际操作展示,该平台显著提升了运维效率,并借助AI智能助手简化了复杂操作。建议进一步完善组件库并增强第三方兼容性,以满足更多高级运维需求。
373 2
|
6月前
|
运维 Kubernetes Cloud Native
云栖实录 | 智能运维:云原生大规模集群GitOps实践
云栖实录 | 智能运维:云原生大规模集群GitOps实践
222 1
|
8月前
|
运维 Cloud Native 开发工具
智能运维:云原生大规模集群GitOps实践
智能运维:云原生大规模集群GitOps实践,由阿里云运维专家钟炯恩分享。内容涵盖云原生运维挑战、管理实践、GitOps实践及智能运维体系。通过OAM模型和GitOps优化方案,解决大规模集群的发布效率与稳定性问题,推动智能运维工程演进。适用于云原生环境下的高效运维管理。
231 8
|
8月前
|
运维 监控 Cloud Native
构建深度可观测、可集成的网络智能运维平台
本文介绍了构建深度可观测、可集成的网络智能运维平台(简称NIS),旨在解决云上网络运维面临的复杂挑战。内容涵盖云网络运维的三大难题、打造云原生AIOps工具集的解决思路、可观测性对业务稳定的重要性,以及产品发布的亮点,包括流量分析NPM、网络架构巡检和自动化运维OpenAPI,助力客户实现自助运维与优化。
|
11月前
|
存储 运维 监控
实时计算Flink版在稳定性、性能、开发运维、安全能力等等跟其他引擎及自建Flink集群比较。
实时计算Flink版在稳定性、性能、开发运维和安全能力等方面表现出色。其自研的高性能状态存储引擎GeminiStateBackend显著提升了作业稳定性,状态管理优化使性能提升40%以上。核心性能较开源Flink提升2-3倍,资源利用率提高100%。提供一站式开发管理、自动化运维和丰富的监控告警功能,支持多语言开发和智能调优。安全方面,具备访问控制、高可用保障和全链路容错能力,确保企业级应用的安全与稳定。
200 0
|
运维 Oracle 前端开发
Oracle 11g RAC集群日常运维命令总结
Oracle 11g RAC集群日常运维命令总结
379 2
|
4月前
|
数据采集 机器学习/深度学习 人工智能
运维人的“福音”?AI 驱动的自动化网络监控到底香不香!
运维人的“福音”?AI 驱动的自动化网络监控到底香不香!
330 0
|
30天前
|
人工智能 运维 安全
运维老哥的救星?AI 驱动的自动化配置管理新趋势
运维老哥的救星?AI 驱动的自动化配置管理新趋势
93 11
|
3月前
|
机器学习/深度学习 人工智能 运维
运维不背锅,从“自动修锅”开始:AI自动化运维是怎么回事?
运维不背锅,从“自动修锅”开始:AI自动化运维是怎么回事?
299 49

推荐镜像

更多