• 流水线:如何做到应用分钟级上线交付?


    背景

    每当有新应用、新系统上线时,我们需要做到以下几步:

    1. 准备新的服务器,安装操作系统
    2. 对操作系统进行初始化,满足各种基线要求
    3. 安装应用依赖的基础组件
    4. 配置应用依赖的环境变量
    5. 准备好应用制品包
    6. 配置中心完成对应用的参数更新
    7. 应用启动
    8. 添加监控

    云原生领域,我们可以通过容器化的解决方案来排除操作系统层面的繁杂操作,从而让我们直接面对应用本身。但为了更好的理解应用上线的整个过程,以及通过自动化手段所能达到的极限交付,我们本次将基于传统的vsphere超融合方案进行介绍。

    需求

    对于不同的技术栈,例如Java和Pyhton,应用的部署方式就有不同,但这阻挡不了我们要将其自动化交付的决心,因此我们从以下几点考虑:

    • 遵循相同的目录规范
    • 按目录规范安装不同技术栈依赖基础组件及环境变量
    • 统一守护进程supervisor,可按启动方式区分配置
    • 监控平台遵循统一的端口监控、健康检查接入规范
    • 统一的配置中心

    从以上分析,多技术栈除了在supervisor守护进程中启动方式不同外,其他都是统一的标准化配置,因此要想实现应用自动化上线是可行的。

    方案分析

    1.虚拟机

    Vsphere虚拟化中,我们的常规操作是直接克隆虚拟机或从模板中直接创建虚拟机,但这需要进行二次修改IP地址、网卡等操作,这无疑大大的浪费了时间。

    其实我们可以通过Vsphere提供的自定义规范来直接定制IP、主机名等配置,这样创建出来的虚拟机就可以直接使用,而不需要二次修改。

    在此我们可以参考以下两篇文章,分别从vcenter图形化界面和Python代码实现自定义规范创建虚拟机。
    vcenter自定义规范定制虚拟机-vsphere client
    运维思索:目录管理规范的重要性

    2.目录规范

    操作系统层面,无论是基础组件、软件部署、环境变量都需要遵循统一的目录规范进行配置管理,因此我们可以将其看作为全局配置。

    具体的目录规划,我们可以参考下文:
    《运维思索:目录管理规范的重要性》

    注意:我们既可以按不同技术栈划分目录,也可以不区分目录将其都视为统一的应用名划分。

    3.操作系统初始化

    对于新创建的虚拟机,我们首先需要进行操作系统初始化,交付一台符合标准配置基线、安全基线的操作系统。

    主要包含以下几方面:

    • yum源
    • 内核参数
    • 符合等保要求的安全基线
    • 符合目录规范的基础目录
    • 标准的应用用户
    • 等等

    对于操作系统初始化,我们的解决方式是使用ansible作为配置管理工具,通过自定义的os_init.yml 剧本进行统一管理。

    具体的实现方式可参看下文:
    运维思索:操作系统配置规范化、自动化

    4.基础组件安装

    技术栈不同,应用运行依赖的组件有所不同,但不外乎以下几种:

    • jdk
    • apache
    • miniconda
    • supervisor
    • 等等

    对于基础组件的,我们的解决方式也是使用ansible作为配置管理工具,通过自定义的software_install.yml 剧本进行统一管理。

    具体的实现方式可参看下文:
    ansible自动化:基础软件的自定义安装

    5.应用启动

    技术栈不同,应用的启动参数不同,在此我们以参数比较多的Java应用为例。

    为了更好的定位、分析、排查问题,我们需要提前定义JVM:

    • GC日志,用于JAVA虚拟机垃圾回收情况;
    • dump文件,用于排查OOM等异常情况;
    • 堆内存,合理使用服务器资源;
    • 环境变量,灵活控制开发、测试、生产等各个文件的配置参数;

    此时我们就有个一个需求:《进程管理规范》,来满足不同应用的标准化启动管理。

    对于Java的启动参数配置,我们可以参考以下文章:
    运维思考:Java进程管理规范

    6.添加监控

    应用监控一般分为进程监控、端口监控或标准的url监控,其中进程监控一般需要分别在应用服务器上进行检查,而端口监控和url监控则可以集中在某台机器上统一检查。

    因此我们最终选择了端口监控和url监控进行互补监控,已经有标准url接口的使用url监控,而没有标准url接口的使用端口监控,这样可以满足我们对不同情况的监控接入。

    无论哪种监控,我们的需求是将监控url或端口添加到指定配置文件,监控系统就可以自动生成监控项,例如:Zabbix自动发现。

    延申:基于统一的远程监控,我们也可在后期增加屏蔽/恢复告警功能,用于发布过程中产生的正常告警。

    针对此场景,我们可以参考以下文章:
    版本发布过程中的屏蔽/恢复告警

    7.小结

    针对以上几方面的分析,涉及了很多最基本的规范,如:

    • 《目录管理规范》
    • 《操作系统安装规范》
    • 《系统初始化规范》
    • 《进程管理规范》
    • 等等

    正是基于这些规范,才有了我们运维自动化进行下去的保障。

    流水线接入

    对于流水线的接入,我们并没有从安装操作系统开始接入,而是从操作系统初始化开始。

    在这里插入图片描述

    其中:

    • 环境初始化通过ansible的os_init.yml剧本实现
    • Java/Python组件安装通过ansible的software_install.yml剧本实现
    • supervisor安装及应用启动也是通过ansible的software_install.yml剧本实现
    • 自动添加监控则是通过zabbix自动发现添加到指定配置文件实现

    我们将以上所有的功能全部集成到Jenkins扩展共享库中,通过流水线的方式对其进行编排,最终满足我们应用的自动化上线。

    关于整个流水线的规划,我们可以参看下文:

    CI/CD如何支撑运维自动化

    1.参数化构建
    在这里插入图片描述

    2.构建过程耗费1分钟左右
    在这里插入图片描述

    3.流水线

    @Library('shared-library') _
    pipeline {
       agent any
       stages {
            stage('基础组件初始化') {
                steps {
                    script {
                        hosts = cmdb.GetHosts("${APP_NAME}")
                        for(host in hosts) {
                            build job: 'init_system', parameters: [string(name: 'ENV', value: 'uat'),text(name: 'HOST_IP', value: "${host}"), string(name: 'PLAYBOOK', value: 'software_install.yml'), string(name: 'TAG', value: 'java,miniconda,supervisor')]
                        }
                    }
                }
            }
            stage('应用初始化') {
               steps {
                   script {
                       python_deploy.InitApp("${APP_NAME}")
                   }
               }
            }
            stage('从制品库拉取包文件') {
               steps {
                   script {
                       python_deploy.PullFromArtifactory("${APP_NAME}")
                   }
               }
            }
            stage('版本发布') {
               steps {
                   script {
                       hosts = cmdb.GetHosts("${APP_NAME}")
                       for(host in hosts) {
                       python_deploy.DeployApp("${APP_NAME}", "${START_COMMAND}", "${host}")
                       }
                   }
               }
            }
        }
    }
    
    
    • 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
    • 41

    总结

    通过流水线我们实现了应用的分钟级交付,整个过程涉及到了基础的标准规范、配置管理工具、流水线等,因此需要在前期做大量的基础规划工作。另,通过容器化的解决方案其实可以将整个过程提升到秒级交付,这对传统应用来说简直是一个降维打击。因此企业最终推动容器化进程,向云原生领域迈进将是大势所趋。

  • 相关阅读:
    创建Storageclass存储类-基于csi-nfs-driver
    砥砺的前行|基于labview的机器视觉图像处理|NI Vision Assisant(三)——Image(图像) 功能
    【Excel函数】Trim函数删除前后多余的空格
    【Linux】进程地址空间、进程的概念、进程的描述、物理地址空间、进程地址空间和物理地址空间的关系
    PyTorch基础知识学习
    如何实现动态投票计数功能
    智慧安防:监控防盗两不误的安防视频监控系统是什么样的?
    promise原理
    Python 并行计算
    普通人也能秒变电子画册制作达人
  • 原文地址:https://blog.csdn.net/yanggd1987/article/details/126654577