运维自动化基础建设|配置中心和注册中心 在前面的文章中我们依次提到了工件库,代码仓库、分支模型、代码质量管理等基础建设,今天我们聊聊注册中心和配置中心,这个东西的边界有些模糊,不像最开始我们说的网络的规划 ,主机的规划可以完全交付OPS来管理,尤其是配置中心的日常变更维护管理。 配置中心 配置中心里都会有那些配置(不局限于以下罗列) •资源类的配置•DB资源•常量•三方的key和secert•其他 资源类的配置 配置信息的来源一般是通过运维平台申请得到的,如果没有运维平台的情况下 key的约定,因为配置中心基本都以k v键值对的形式存储的。 参考文档 开源分布式配置中心选型[1] 关于 Nacos 的整理[2] 总结 配置中心和注册中心是一个公司基础架构中的重中之重,当前生产运行时的所有配置都跟这个息息相关,完善的备份策略和高可用集群架构的选型和设计都要慎重再慎重
3 运维管理从运维现状来看,我们优先需要解决的是自动化的问题,而自动化的前提是标准化/规范化,而好的自动化需要配合可视化或web化,可以将我们80%或更多的工作进行优化。 6.2 选择正确的阶段运维自动化一般沿袭这样的阶段:手动支撑 => 线上标准规范化 => 运维工具化 => 平台自助化/自动化。选择适合自己当前业务发展阶段的运维自动化方式,不要一口吃成胖子。 7.2 运维管理文章开头说运维管理主要目标是标准化/规范化,自动化,可视化/web化,从切身体验来看运维管理的目标也是随着运维自动化阶段的不同而变化的。 理由:(1)运维自动化的价值在于,将运维从繁琐的、例行、容易发生人为事故的工作中脱离出来,做更有价值的业务运维和服务运维。所以,从这个角度来看,运维自动化既不是起点,也不是终点。 运维自动化不是万能的,我们需要看清楚它的位置。(2)运维的本质到底是服务,是服务于业务,因为运维是用技术解决业务问题,运维的价值要依托于业务才能体现。
1、运维自动化发展 运维学习和发展的一个线路: 1.搭建服务(部署并运行起来) 2.用好服务(监控、管理、优化) 3.自动化(服务直接的关联和协同工作) 4.产品设计(如何设计一个运维系统) 系统架构师(偏管理):网络 系统 数据库 开发 云计算 自动化 运维管理 服务管理 项目管理 测试 业务 -----专注于某一领域 2、运维自动化发展 运维工作内容分类: 监控运维(7x24 运维值班、故障处理) 应用运维(业务熟悉、服务部署、业务部署、版本管理、灰度发布、应用监控) 安全运维(整体的安全方案、规范、漏洞检测、安全防护等) 系统运维(架构层面的分布式缓存、分布式文件系统 、巡检、报修、硬件监控) 3、运维自动化发展 标准化: 物理设备层面: 1.服务器标签化、设备负责人、设备采购详情、设备摆放标准 2.网络划分、远程控制卡、网卡端口 3.服务器机型、硬盘 运维自动化发展 基于ITIL的运维管理体系 成为一名运维经理: 技术: 运维知识体系 除了技术: 1.服务管理 ITIL 2.项目管理 PMP 做人
当你需要持续、频繁地进行一些事情,自动化运维就是需要的。 OS环境初始化 配置管理工具puppet或satkstack 组件部署 nginx、mysql等 应用程序包部署 xxx 申请关联服务 dns\lvs\cache 自动化测试 对接自动化测试 业务上线 监控系统、CMDB 自动化平台 image.png DNS管理平台+后端BIND:https://www.oschina.net/p/namedmanager
2 系统配置参数优化 web服务器优化:网络连接的压力,硬盘读压力 tcp_max_syn_backlog 处理第二次握手状态的数量,默认1024,可以增加
蓝鲸智云标准运维,以下简称标准运维标准运维中的标准插件:标准运维自带封装好的插件,主要是蓝鲸平台各个产品的原子操作,可以直接拖拽到流程画布里使用。如果标准运维插件不满足,则需要自定义开发插件。 默认标准插件有哪些部署完社区版,标准运维里默认有以下标准插件,覆盖5个类醒,总数40+【蓝鲸服务】标准插件使用方法1、HTTP请求该插件使用需要确保请求的URL在当前网络下是能访问演示:选择http插件配置插件参数新建任务执行效果
在命令行窗口中启动的Python解释器中实现 在Python自带的IDLE中实现
total(内存总数)、used(已使用的内存数)、free(空闲内存数)、buffers(缓冲使用数)、cache(缓存使用数)、swap(交换分区使用数)
标准运维中的执行方案跟作业平台里的执行方案有些不一样,作业平台中的执行方案是作业模板实例化出来的,标准运维中的执行方案主要是不同步骤的一个组合,实际是一个执行任务。
关于 StackStorm是一个用于跨服务和工具进行集成和自动化的平台。它将您现有的基础结构和应用程序环境联系在一起,这样您就可以更容易地自动化该环境。它特别关注在事件发生后采取的行动。 StackStorm帮助自动化常见的操作模式。 大多数自动化操作不止一步,因此需要多个操作。工作流与“原子”操作一样,可以在操作库中使用,可以手动调用或由规则触发。 包是内容部署的单元。 它们通过分组集成(触发器和操作)和自动化(规则和工作流)简化了StackStorm可插内容的管理和共享。越来越多的包可用于StackStorm交换。 它由通过消息总线通信的松散耦合的服务组件组成,并水平扩展以按比例交付自动化。StackStorm有一个Web UI,一个CLI客户端,当然还有一个完整的REST API。
在全局变量使用篇里了解到了各类变量的基本用法,实际在很多场景下,需要对变量进行处理,这就是标准运维里变量的高级用法。
首先,之前所讲的专题是在运维自动化专场,后来一些交流下来,我们共同的感觉是,听众们都特别的关注运维自动化,恰恰说明了我们现在运维的现状是:有太多的公司还没有自动化或者自动化程度很低,还没有找到明确的自动化的方向和思路 这里先不谈运维自动化的问题,想先表达两个观点: 运维不仅仅是自动化,还有很多方向值得我们去发力 运维,技术不是问题,重要得是思维上的转变 运维不仅仅是自动化,还有很多方向值得我们去发力 前两天在运维群里 效率 这块跟日常的运维例行工作紧密相关,如资源分配&回收、域名配置、VIP配置、持续集成&发布、应用部署、应用扩容&缩容等,这块是运维最基础的工作,通常提到的运维自动化,大多是集中在这些工作上,因为这些工作偏日常和重复 ,目前业界的自动化的解决方案也非常完善了,所以可以优先把这些问题解决掉,目标就是解放运维的生产力,提升运维效率,降低人为失误,让运维的同学可以有更多的精力去做更有价值的事情。 所以,我觉得运维在技术上不是障碍。即使你觉得以上工具不好使,可以参选我们团队自己研发的ETL调度工具taskctl 关于taskctl 是一款功能全面的作业自动化调度技术管理工具。
对于数据中心,运维工作的重要性不言而喻,在数据中心生命周期中运维管理是历时时间最长的一个阶段。 投资巨大的数据中心,为了能够尽快得到收益,就需要在运维的工作上多下工夫,切勿进入“一流设备、二流设计、三流运维”的不良运营之中,高品 质数据中心运维的工作至关重要。 那么如何才能提升数据中心的运维水平,本文提出了数据中心运维工作制胜的四大法宝,做好这四个方面的工作将使数据中心一直 运行于最佳状态,为数据中心创造最大的受益。 通过对数据中心运维而 输出的各种技术文档,将为后来人提供方便,并且可以提升数据中心整体的运维能力。数据中心的文档五华八门,你不知道什么时候其中的哪些文档就会派上用场。 工程文档、业务备份、在线监测、周期巡检是数据中心运维工作的四个重要方面,只有做好这四个方面的工作,才能让数据中心保持长期稳定运行,并能产生良好的效益,是数据中心运维水平高低的主要体现,拥有这四大法宝,将使数据中心终身受益
https://smartpublic-10032816.file.myqcloud.com/custom/20221221171951/20044/20221221171951/--2160345a7fc46256700a53b700bf103c.png
蓝鲸智云标准运维,以下简称标准运维标准运维封装了两个节点管理(蓝鲸智云节点管理)的原子操作作为标准插件新建任务插件操作我们看看这两个插件如何使用新建任务新建任务插件主要是封装的节点管理agent安装操作 ,包括安装agent和安装proxy(非直连模式),方便管理员可以把这个动作集成到资源管理的流程中去,比如一个机器从初始到上线的流程,就不需要再单独去节点管理安装agent,直接在标准运维一个流程里集成即可 bkmonitorproxy、exceptionbeat、bkunifylogbeat、gsecmdline 几种,具体功能介绍可以查看:xx插件的托管、安装、升级、卸载等操作都是在节点管理做的,标准运维插件的操作实际就是调用节点管理来执行
职能化功能主要用于一些固化的标准流程可以通过权限开放的方式给到那些负责固定职能的非运维人员,比如外包操作员来执行操作,如此可以释放一些运维的人力,让其可以专注流程的建设和优化。 实操演示新建职能化流程(运维角色操作)在创建完流程之后,创建任务时,流程类型选择职能化任务流程认领职能化任务(非运维角色)认领职能化任务,需要有权限看到职能化的任务列表,并且有该流程的任务执行权限(以及流程里的标准插件的相关权限 ),可以到蓝鲸权限中心进行申请或者由分级管理员授予(推荐)。 比如一个流程里有作业平台执行脚本的插件,那么职能化角色的人员要能认领职能化任务并且执行,需要有的权限:职能化中心查看项目查看流程查看任务认领、执行作业平台脚本执行(可以具体到指定的目标ip)(标准运维的权限申请示例
前言 这些年来,大家都在谈运维自动化。但大家是否也会困惑于“只见树木、不见森林”?或者说,做了几年的运维自动化,但依然不能确定还有哪些工作没做?怎么更优雅的实施运维自动化? 另外,运维自动化会潜在的带来哪些问题?且听本文分解\~ 本文实际上包括两部分,关于运维自动化的一些观点(前3部分)和运维自动化的痛点(第4部分)。 如果已是运维自动化的专业人士,可以跳过前面内容,直接鉴赏第4部分------运维自动化之殇。依惯例放上目录,请享用。 什么是运维自动化? 运维自动化的三个阶段 怎么做运维自动化? 运维自动化之殇 好吧,我们正式开始。 什么是运维自动化? 有人从实用性的角度来表述运维自动化,就是把运维日常需要登录机器的操作,完全Web化,以后只需要点一下鼠标就搞定。 1)环境定义自动化: 很多公司采用的是数据中心+虚拟机,团队需要某种环境的时候,必须要走流程申请,申请就意味着和不同部门打交道,挨个部门进行层层审批,很浪费时间。
1.功能 对IP进行处理的模块 2. 输出一个网段内的所有IP 反向解析,IP类型,IP转换 网段转换 strNomal(0) 无返回 strNomal(1) 后缀 strNomal(2)
1.功能:对比文件差异 2. 对比两个字符的差异 生成对比HTML格式文档,将结果输入到HTML文件,用浏览器打开 单文件对比 多文件对比 输出格式 ( [ 匹配 ],[ 不匹配 ],[ 错误
打通的则无需加-A) pssh -i -A -h list 'uptime' 使用pscp向一堆机器分发文件 pscp -h list localfile remote_dir 从一堆机器中拷贝文件到中心机器