运维平台化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,如需转载请自行联系原作者



相关文章
|
8月前
|
数据采集 运维 监控
运维靠经验拍脑袋?不如上车:构建“数据驱动”的智能决策系统
运维靠经验拍脑袋?不如上车:构建“数据驱动”的智能决策系统
245 0
|
6月前
|
存储 运维 监控
57_大模型监控与运维:构建稳定可靠的服务体系
随着大语言模型(LLM)技术的快速发展和广泛应用,如何确保模型在生产环境中的稳定运行、高效服务和安全合规已成为企业和开发者面临的关键挑战。2025年,大模型服务已从实验室走向各行各业的核心业务流程,其运维复杂度也随之呈指数级增长。与传统软件系统不同,大模型服务具有参数规模庞大、计算密集、行为不确定性高等特点,这使得传统的运维监控体系难以满足需求。
1107 0
|
运维 Cloud Native 开发工具
智能运维:云原生大规模集群GitOps实践
智能运维:云原生大规模集群GitOps实践,由阿里云运维专家钟炯恩分享。内容涵盖云原生运维挑战、管理实践、GitOps实践及智能运维体系。通过OAM模型和GitOps优化方案,解决大规模集群的发布效率与稳定性问题,推动智能运维工程演进。适用于云原生环境下的高效运维管理。
547 8
|
Prometheus 运维 监控
运维实战来了!如何构建适用于YashanDB的Prometheus Exporter
今天分享的是构建YashanDB Exporter的核心设计理念和关键方法,希望也能为你的运维实战加分!
|
运维 监控 Cloud Native
构建深度可观测、可集成的网络智能运维平台
本文介绍了构建深度可观测、可集成的网络智能运维平台(简称NIS),旨在解决云上网络运维面临的复杂挑战。内容涵盖云网络运维的三大难题、打造云原生AIOps工具集的解决思路、可观测性对业务稳定的重要性,以及产品发布的亮点,包括流量分析NPM、网络架构巡检和自动化运维OpenAPI,助力客户实现自助运维与优化。
|
数据采集 机器学习/深度学习 人工智能
基于AI的网络流量分析:构建智能化运维体系
基于AI的网络流量分析:构建智能化运维体系
2250 13
|
Prometheus 运维 监控
Prometheus+Grafana+NodeExporter:构建出色的Linux监控解决方案,让你的运维更轻松
本文介绍如何使用 Prometheus + Grafana + Node Exporter 搭建 Linux 主机监控系统。Prometheus 负责收集和存储指标数据,Grafana 用于可视化展示,Node Exporter 则采集主机的性能数据。通过 Docker 容器化部署,简化安装配置过程。完成安装后,配置 Prometheus 抓取节点数据,并在 Grafana 中添加数据源及导入仪表盘模板,实现对 Linux 主机的全面监控。整个过程简单易行,帮助运维人员轻松掌握系统状态。
2257 3
|
运维 监控
构建高效运维体系:从理论到实践
在当今快速发展的信息化时代,高效的运维体系是保障企业信息系统稳定运行的关键。本文旨在探讨如何构建一个高效、可靠的运维体系,通过分析当前运维面临的挑战,提出相应的解决策略,并结合实际案例,展示这些策略的实施效果。文章首先介绍了高效运维的重要性,接着分析了运维过程中常见的问题,然后详细阐述了构建高效运维体系的策略和步骤,最后通过一个实际案例来验证这些策略的有效性。
|
人工智能 运维 监控
构建高效运维体系:理论与实践的深度融合####
本文旨在探讨高效IT运维体系的构建策略,通过理论框架与实际案例并重的方式,深入剖析了现代企业面临的运维挑战。文章开篇概述了当前运维领域的新趋势,包括自动化、智能化及DevOps文化的兴起,随后详细阐述了如何将这些先进理念融入日常运维管理中,形成一套既灵活又稳定的运维机制。特别地,文中强调了数据驱动决策的重要性,以及在快速迭代的技术环境中保持持续学习与适应的必要性。最终,通过对比分析几个典型企业的运维转型实例,提炼出可复制的成功模式,为读者提供具有实操性的指导建议。 ####

推荐镜像

更多