自动化运维

ansible之group模块 group模块是用来添加或者删除组 首先使用ansible-doc来查看用法 [root@note0 ansible]# ansible-doc -s group - name: Add or remove groups group: gid: # Optional `GID' to set for the group. local: # Forces the use of "local" command alternatives on platforms that implement it. This is useful in environments that use centralized authentication when you want to manipulate the local groups. (e.g. it uses `lgroupadd' instead of `groupadd'). This requires that these commands exist on the targeted host, otherwise it will be a fatal error. name: # (required) Name of the group to manage. non_unique: # This option

本帖最后由 陈泽 于 2018-6-20 17:31 编辑 一、协程 1.1协程的概念 协程，又称微线程，纤程。英文名Coroutine。一句话说明什么是线程：协程是一种用户态的轻量级线程。（其实并没有说明白~） 那么这么来理解协程比较容易： 　　线程是系统级别的，它们是由操作系统调度；协程是程序级别的，由程序员根据需要自己调度。我们把一个线程中的一个个函数叫做子程序，那么子程序在执行过程中可以中断去执行别的子程序；别的子程序也可以中断回来继续执行之前的子程序，这就是协程。也就是说同一线程下的一段代码执行着执行着就可以中断，然后跳去执行另一段代码，当再次回来执行代码块的时候，接着从之前中断的地方开始执行。 比较专业的理解是： 　　协程拥有自己的寄存器上下文和栈。协程调度切换时，将寄存器上下文和栈保存到其他地方，在切回来的时候，恢复先前保存的寄存器上下文和栈。因此：协程能保留上一次调用时的状态（即所有局部状态的一个特定组合），每次过程重入时，就相当于进入上一次调用的状态，换种说法：进入上一次离开时所处逻辑流的位置。 1.2 协程的优缺点 协程的优点： 　　（1）无需线程上下文切换的开销，协程避免了无意义的调度，由此可以提高性能（但也因此，程序员必须自己承担调度的责任，同时，协程也失去了标准线程使用多CPU的能力） 　　（2）无需原子操作锁定及同步的开销 　　（3）方便切换控制流

郑昀 创建于2015/12/2 最后更新于2015/12/2 关键词：数据库，MySQL，自动化运维，AutoDDL，刷库，帐号授权，审核，回滚 iDB 是刘勤红部门推出的数据库自动化运维平台，它其实已经断断续续开发了几个月了，线上也跑了一段时间， 最近又发布了新版本 。版本迭代的主力是王晓华同学，李世杰也参与了一部分开发工作，曹富志和张永奎是需求方。 iDB 的主要目的是 解决绝大部分重复、复杂的数据库运维工作 ，满足业务对数据库信息查询和快速变更需求 ，借此提升研发效率，保证数据库操作符合审计要求，有可追溯的变更和审核日志。 0x00，数据库自动化运维什么？别人家是怎么玩的？ 当数据库越来越多时 ，比如按业务垂直分库了，10个，50个，100个…… 当数据库关系越来越复杂时 ，比如 Cobar 水平拆库，从库分组，级联从库，合并库，比如某些索引要求只建在特定从库上…… DBA 的日常管理，手速再快，也不得不希望有系统来帮忙，毕竟数据库拓扑建立起来后，很多操作都可以自动化完成。 举个例子，工程上线前要开数据库访问帐号和权限。没有平台的话，那就得 DBA 一个一个去建，写库是 M 打头的帐号，读库是 S 打头的帐号，密码强度还得高。有了平台之后，DBA 只需要审核研发人员提的需求即可，系统自动化生成帐号密码，然后发邮件给申请人，或者将密码生成对称加密后的密文展示给申请人。 再比如

目录导航： 　　 1. 容器类型强制转换 　　 2. 二级容器 　　 3. 算数运算符 　　 4. 赋值运算符与成员运算符 　　 5. 身份运算符 　　 6. 位运算符 　　 7. 代码块 　　 8. 流程控制 　　 9. 多项分支 　　 10. 循环分支 　　 11. 单循环练习 　　 12. 字符串的相关操作　 　　 13.多循环练习 　　 14. for 循环 1. 容器类型强制转换 var1 = "今天天气转冷了" var2 = [1,2,3] var3 = (4,5,6) var4 = {"a","b","c"} var5 = {"a":1,"b":2} # (1)str 强制转换成字符串 """在原数据类型的两边套上引号""" res = str(var2) res = str(var3) res = str(var4) print(res,type(res)) # repr 在不转移字符串的情况下,原型化输出 res_new = repr(res) print(res_new) # (2)list 强制转换成列表 """ 如果是字符串,那么就是把每一个字符都当成新的元素组合成列表 如果是list , tuple ,set 就是在原数据类型的两边改成[] 如果是字典 , 只是获取字典的键组成列表 """ res = list(var1) res = list(var3)

前言 大家做运维普遍经历这样的过程： 首先我们会把操作做一个标准化，这个阶段是运维质量的提升的阶段。 在标准化实施完以后，由于数目的增加，或者是一些运维场景的增多，我们会逐步的进行一些工具化和自动化，这个阶段我们的运维的效率得到提升。 但是众多的工具以及自动化脚本，会让我们的管理过程中比较困难，随着人员的变动或者是一些工具维护过程中的差错，我们的自动化运维工具的受众群体不太稳定。 这个时候我们就需要一个平台将我们的运维工具以及运维过程中的一些经验进行沉淀，借助这个平台实现我们的智能化运维，于是我们从运维人员的需求和体验出发出发进行了一个运维平台产品化的构建。 银行卡组织云运维平台的概况 我给大家介绍一下我们IT体系建设的情况，差不多十年前我们以ITIL为基础构建了流程平台，变更、事件、问题、服务等流程通过这个平台进行流转。 在五年前我们从开放平台转化为云运维平台，在这个过程中，我也建立了IaaS虚拟化资源平台，同时我们也跟业界一样构建了CMDB，用于同意管理运维数据。 但是在运转下来以后，我们发现还有很多需求需要实现，主要三个方面： 软硬件节点数目不断增加，日常运维迫切需要一个适应各种运维场景的高效自动化平台，减少重复劳动。 需求是将运维人员的经验需要在一个平台沉淀，形成一个智能化场景库，将运维服务或能力的复用，从而提高整体运维质量和运维效率。

前言 大家做运维普遍经历这样的过程： 首先我们会把操作做一个标准化，这个阶段是运维质量的提升的阶段。 在标准化实施完以后，由于数目的增加，或者是一些运维场景的增多，我们会逐步的进行一些工具化和自动化，这个阶段我们的运维的效率得到提升。 但是众多的工具以及自动化脚本，会让我们的管理过程中比较困难，随着人员的变动或者是一些工具维护过程中的差错，我们的自动化运维工具的受众群体不太稳定。 这个时候我们就需要一个平台将我们的运维工具以及运维过程中的一些经验进行沉淀，借助这个平台实现我们的智能化运维，于是我们从运维人员的需求和体验出发出发进行了一个运维平台产品化的构建。 银行卡组织云运维平台的概况 我给大家介绍一下我们IT体系建设的情况，差不多十年前我们以ITIL为基础构建了流程平台，变更、事件、问题、服务等流程通过这个平台进行流转。 在五年前我们从开放平台转化为云运维平台，在这个过程中，我也建立了IaaS虚拟化资源平台，同时我们也跟业界一样构建了CMDB，用于同意管理运维数据。 但是在运转下来以后，我们发现还有很多需求需要实现，主要三个方面： 软硬件节点数目不断增加，日常运维迫切需要一个适应各种运维场景的高效自动化平台，减少重复劳动。 需求是将运维人员的经验需要在一个平台沉淀，形成一个智能化场景库，将运维服务或能力的复用，从而提高整体运维质量和运维效率。

前言 通常来说，自动化运维有两种类型的运维方式： 定时的脚本任务， 比如定时更换云服务的 acess key secret , 定时检查 ecs 对外暴露的端口等 报警事件的紧急处理, 比如 ecs 实例发生异常重启 在传统的运维中，对于定时任务的处理通常用crontab脚本来实现，但是一旦管理的机器多了，必定会对脚本进行集中管理，这个时候对集中管理脚本的机器的可用性、脚本里面会散落密码明文等相关信息以及定时任务执行的记录都是一个很大的挑战；而对于事件驱动的报警处理，要么是通过短信报警告知运维人员，要么需要自建服务来处理报警信息, 无论是哪种方式，财务成本和运维成本都很大。本文探讨一种新的运维方式，利用函数计算做自动化运维，以极低的成本就可以获得一个高可靠，高质量的运维服务。 函数计算 阿里云 函数计算 是一个事件驱动的serverless计算服务。通过函数计算，您无需管理服务器等基础设施，只需编写代码并上传。函数计算会为您准备好计算资源，以弹性、可靠的方式运行您的代码，具体表现为： 无需采购和管理服务器等基础设施 按需付费，比如对运维管控这类低频调用的系统，财务成本通常能节约90%以上 专注业务逻辑的开发，能极大提高开发效率，比如 十分钟上线弹性高可用的图片处理服务 稳定高可用，毫秒级别弹性伸缩，快速实现底层扩容以应对峰值压力 提供日志查询、性能监控、报警等功能快速排查故障

前言 通常来说，自动化运维有两种类型的运维方式： 定时的脚本任务， 比如定时更换云服务的 acess key secret , 定时检查 ecs 对外暴露的端口等 报警事件的紧急处理, 比如 ecs 实例发生异常重启 在传统的运维中，对于定时任务的处理通常用crontab脚本来实现，但是一旦管理的机器多了，必定会对脚本进行集中管理，这个时候对集中管理脚本的机器的可用性、脚本里面会散落密码明文等相关信息以及定时任务执行的记录都是一个很大的挑战；而对于事件驱动的报警处理，要么是通过短信报警告知运维人员，要么需要自建服务来处理报警信息, 无论是哪种方式，财务成本和运维成本都很大。本文探讨一种新的运维方式，利用函数计算做自动化运维，以极低的成本就可以获得一个高可靠，高质量的运维服务。 函数计算 阿里云 函数计算 是一个事件驱动的serverless计算服务。通过函数计算，您无需管理服务器等基础设施，只需编写代码并上传。函数计算会为您准备好计算资源，以弹性、可靠的方式运行您的代码，具体表现为： 无需采购和管理服务器等基础设施 按需付费，比如对运维管控这类低频调用的系统，财务成本通常能节约90%以上 专注业务逻辑的开发，能极大提高开发效率，比如 十分钟上线弹性高可用的图片处理服务 稳定高可用，毫秒级别弹性伸缩，快速实现底层扩容以应对峰值压力 提供日志查询、性能监控、报警等功能快速排查故障

1 前言 即使是在传统的企业当中，日常的备份、服务器状态监控和日志，通过手动的方式来进行的效率也很低，是一种人力的浪费。因此，自动化早已是每个运维都必须掌握的看家本领。 在不同的企业中，自动化的规模、需求与实现方式都各不相同，因此在技术细节层面，运维之间很难将别的企业的方法整个套用过来。然而在很多情况下，自动化的思路是有共通之处的。 运维自动化前三阶段 ◆纯手工阶段：手工操作重复地进行软件部署和运维。 ◆脚本阶段：通过编写脚本、方便地进行软件部署和运维。 ◆工具阶段：借助第三方工具高效、方便地进行软件部署和运维。 这几个阶段是随着运维知识、经验、教训不断积累而不断演进的。而且，第2个阶段和第3个阶段可以说是齐头并进，Linux下的第三方工具虽说已经不少了，但是Linux下的脚本编写对运维工作的促进作用是绝对不可以忽视的。 在DevOps出现之前，运维工作者在工作中还是以这两种方式为主。 下面的研究，都是一些linux下开源的第三方工具，借助第三方工具高效、方便地进行软件部署和运维。 2 业界开源的自动化部署工具 2.1 chef Chef 是一款自动化服务器配置管理工具，可以对所管理的对象实行自动化配置，如系统管理，安装软件，基于ruby语言编写的。 2.1.1 Chef的架构 2.1.2 Chef的工作原理： Chef 由三大组件组成：Chef Server、Chef

自动运维化工具：saltstack ansible： 传统运维效率低，大多工作人为完成； 传统运维工作繁琐，容易出错； 传统运维每日重复做相同的事情； 传统运维没有标准化流程； 传统运维的脚本繁多，不能方便管理； 自动化运维 就是要解决上面所有问题； 常用的自动化运维工具：适用于十多台 上百台 上千台等； puppet ： （ www. puppetlabs.com ） 基于rubby开发,C/S架构,支持多平台,可管理配置文件,用户,crond任务,软件包,系统服务等,分为社区版和企业版(收费,但是支持图形化); saltstack ：https://saltstack.com 文档：docs.saltstack.com 基于python开发, C/S架构,多平台,比puppet轻量,在远程执行命令时非常快捷(因为它有消息队列,它是并行的,所以快,如expect是串行,一个一个执行,比较慢),配置和使用puppet容易多了,能实习puppet的所有功能； ansible ：www.ansible.com 基于python开发,更加方便简洁的自动化运维工具,不需要在客户端安装anget,可以实现批量操作系统配置,批量程序部署,批量运行命令； 注释 ：saltstack与ansible相比,saltstack支持的机器更多,ansible是通过秘钥认证的方式来执行后面的命令,更改文件