运维渠道化saltstack和jinja2模板构建高可用集群装备渠道51CTO博客 - 千亿集团

运维渠道化saltstack和jinja2模板构建高可用集群装备渠道51CTO博客

2019年04月14日13时20分15秒 | 作者: 振强 | 标签: 装备,集群,渠道 | 浏览: 3017

前语:

    最近正在做一个集群装备渠道,曾经也做过相似的demo,记住是上一年做的时分用的是paramiko模块,先说他的衔接装备是用ssh,交互也有时用pexpect。在杂乱的装备下会常常出问题的。 装备主要是出在正则匹配的方面。


   现在到了新公司,第一件是便是重构代码,意图是做成一个全网集群的装备东西,支撑nginx、lvs、haproxy多种集群装备的渠道。 里边含有流程的主动流通批阅,在测验服务器上做测验,装备文件的操作之前的装备,及出问题时分的回滚。


由于新公司的环境是puppet,计划推行下saltstack !  我仍是喜爱saltsatck那种简洁的二次开发。

自己现在的思路是:  

经过web结构的模板来烘托装备装备,最好是把nginx.conf keepalived.conf 整形到 yaml相似的格局里边。推送到客户端仅仅get url,经过接口的ip和类型,给你烘托出装备文件,直接下载就行了。


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


下面的集群办理渠道,我自己也就写了两天,把前端页面及后端的mysql库做了规划。  我会把后续思路和解决方案更新给我们下。  还没有上线,仅仅给我们一个姿态参阅 ~



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


关于集群的参数,做了特定的格局标准 !


特别阐明,这儿能够填写一些特别的需求 !


点提交后,会给领导发邮件等候承认~


数据是随意写的 ~


mysqldb 获取timestamp的呈现点问题,我们能够参阅下 ~


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


关于%的符号,特别格局化时刻用的多,需求这么搞

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


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






关于saltstack这边关于lvs yaml的进程


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


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

这儿是用在lvs haproxy nginx的数据烘托的 !


{% for i in ldata[vrrp_sync_group] %}
       {{ ldata[vrrp_instance][VI_1][virtual_ipaddress][loop.index0][vip_server][vip] }}
{% endfor %}
{% for i in range(ldata[vrrp_sync_group]|count) %}
       {{ ldata[vrrp_instance][VI_1][virtual_ipaddress][loop.index0][vip_server][vip] }}
{% endfor %}


现已烘托好keepalived.conf 的测验页面




款式更新了下,都放在一同,的确有点紧




又加了几个功用,把昨日写的逻辑从头改变下,明日开端做后端 !



实时流量图



wgetconf


jinja2的一个问题    {% if type "kkk" %} 里边的type是jinja2里边的关键字  我们避开这个关键字就行了。。。 本来以为是自己逻辑的问题,搞了半天是关键字的抵触 !!!




这个完成的原理便是使用saltstack的pubsub速度,完成实时数据搜集 !



这两天在忙dba的渠道,这个东西发展有点缓慢!



加了表单验证

针对返回值的各种判别,和接连ajax


服务器的自身调试页面!

日志图表剖析




版权声明
本文来源于网络,版权归原作者所有,其内容与观点不代表千亿集团立场。转载文章仅为传播更有价值的信息,如采编人员采编有误或者版权原因,请与我们联系,我们核实后立即修改或删除。

猜您喜欢的文章