ansible

不管大型还是中小型互联网公司，运维面对最多的工作就是发布部署，近些年各种运维自动化工具也越来越多，运维自动化每个人都有一套自己的理解，那么中小公司一般都怎么做运维自动化呢？ 我们先看一下中小企业面临的问题: 人员有限，小一点的公司专业运维可能没有，开发自己上线，也有可能1-2个运维人员，基本不会投入专门的运维开发来开发运维自动化平台。 服务器少，可能不超过50台服务器。 版本更新迭代比较快，需要快速方便的发布回滚。 中小企业运维自动化常见做法： Gitlab+Jenkins，创建Jenkins任务，使用Jenkins登录服务器执行脚本实现发布，配合服务器多个脚本实现对服务器管理。 Gitlab+Jenkins+Ansible，使用Jenkins调用Ansible登录服务器执行脚本实现代码的发布，平时服务器管理使用Anaible进行服务器管理。 K8S平台，使用K8s发布平台，打包应用Docker镜像，通过K8s发布到线上。 使用开源的运维自动化平台发布管理，Github上有很多优秀的开源项目，可以使用。 虽然可以通过上面的几种方法把发布和经常操作的都实现自动化，但是避免不了登录服务器操作命令、配置任务计划，修改应用配置文件，配置服务器监控报警等。那么有没有开源平台可以很方便的实现上面说到的这些功能呢？下面就给给大家推荐一款面向中小企业的轻量级开源运维自动化平台： Spug 平台介绍

ansible是新出现的自动化运维工具，基于Python开发，集合了众多运维工具（puppet、cfengine、chef、func、fabric）的优点，实现了批量系统配置、批量程序部署、批量运行命令等功能。 ansible是基于模块工作的，本身没有批量部署的能力。真正具有批量部署的是ansible所运行的模块，ansible只是提供一种框架。主要包括： (1) 连接插件connection plugins：负责和被监控端实现通信； (2) host inventory：指定操作的主机，是一个配置文件里面定义监控的主机； (3) 各种模块核心模块、command模块、自定义模块； (4) 借助于插件完成记录日志邮件等功能；playbook：剧本执行多个任务时，非必需可以让节点一次性运行多个任务。 #如何部署ansible ? 1.准备如表-1所示的实验环境，操作系统为RHEL8，配置主机名称、IP地址、YUM源。 ansible原理： 控制端主机自带很多模块（模块就是脚本）； ansible通过ssh远程被管理主机，将控制端的模块（脚本）或命令传输到被管理主机； 在被管理端主机执行模块（脚本）或命令，执行不同的模块或命令可以实现不同的功能； 最后ansible退出ssh远程。 绝大多数模块（脚本）都需要参数才能执行成功！！！类似于shell脚本的位置变量！ 拓扑结构如图-1所示。

提到Sysdig大家会想到市面比较主流的监控软件Grafana(跨平台的可视化日志分析和监控工具)、Kibana（ELK堆栈的一部分，用于数据分析和日志监视）、Prometheus(容器部署整个技术栈，开源的自主托管监控方案)，基于不同的监控对象和应用规模，它们都有各自不同的特点和优势。 今天我们要介绍的是IBM Cloud的云监控解决方案Sysdig，云上的IaaS资源除了传统的虚拟机实例，同样也包括容器集群，云函数，云数据库等PaaS服务。 根据业务和服务具体需求，算力资源可能在全球多个区域部署，那么对监控平台的数据采集，日志汇总、分析和可视化仪表都会有很高的要求。 IBM Cloud选择Sysdig应该是想借助一套完全托管的企业级监视服务（客户无需维护服务系统，上手简洁方便），统一地管控云上多样化资源，并提供面向服务的视图、全面的指标和强大的预警功能，让云监控变得更加高效。 Sysdig常见的监控对象包括云主机和容器， 在IBM Cloud上云主机实例包括（经典架构）裸机和虚拟机，VPC虚拟机。 今天小实验的对象是经典架构下虚拟机的自动化agent部署和监控。 1.创建sysdig托管服务实例 选择Free tier - Lite 配置，服务创建在哪里？最好的选择是离监控资源就近的区域，如果有需要也可尝试启用“IBM Platform Metrics”

百度网盘：Python项目开发实战（第2版）PDF高清完整版免费下载 提取码：exep 内容简介 本书来自真正的开发现场，是BePROUD公司众多极客在真实项目中的经验总结和智慧结晶。作者从Python的环境搭建开始讲起，介绍了Web应用的开发方法、项目管理及审查、测试与高效部署、服务器调试等内容，尽可能网罗了Python项目开发流程中的方方面面，有助于开发者建立有序生产环境，提高开发效率，让编程事半功倍。此外，在本书中Python仅仅是一个载体，很多知识点在非Python下也适用。 作者简介 日本BePROUD股份有限公司 BePROUD是一家专注于Python开发的公司，因云集了众多行业精英而闻名于日本国内。多年来的软件开发硕果累累，其精湛的技术水平，得到了客户及业界人士的认可和好评。 目录 第1部分　Python开发入门　　1 第1章　Python入门　　2 1.1 安装Python　　2 1.1.1 安装deb包　　3 1.1.2 安装第三方包　　4 1.1.3 virtualenv的使用方法　　5 1.1.4 多版本Python的使用　　7 1.2 安装Mercurial　　9 1.2.1 Mercurial概述　　10 1.2.2 安装Mercurial　　10 1.2.3 创建版本库　　11 1.2.4 文件操作　　12 1.3 编辑器与辅助开发工具　　14 1.3

Enterprise Holdings. 的IT团队超过2000人，在2018年的演讲中介绍了Enterprise Holdings的DevOps是如何转型的。我们通过打造一个不只包涵了pipeline的CI/CD平台，将其称之为SDLC。在最开始的200+个应用中，我们挑选出5个来作为试点。当时的情况证明这次DevOps转型计划是成功的，我们的团队有4+位工程师和两位架构师，从2年半前就开始了整个平台的开发工作，根据业务需求确保平台可以适配各种云服务、也要适配已有的中间件，我们也在不断对CI/CD平台进行改进，以适应所有业务场景。其的目标是让开发人员更专注于具体的项目开发，让工具去解决一些通用性的问题。为了达到目前的效果，我们做了很多关于平台的需求收集及问题反馈相关的运营工作，所以在过去的一年里，我们已经将此套平台服务于70%的应用中，并且这个数字还在持续的增加。 在DevOps转型过程中，我们的角色并不是软件的开发者，但我们支撑了应用开发团队和他们所开发的应用，我们的服务工作介于应用程序与基础设施之间。在我们的角度来看，应用程序的开发应该是这样的： ·开发人员在本地开发 ·在仓库中检查源码 ·在构建服务器上构建应用 ·运行安全扫描 ·打包发布到JFrog的Artifactory ·发布应用到不同的环境测试 ·所有测试结束后，发布到生产环境 这个模式很简单，但是也很高效

1.安装方式 1.yum -y install ansible 2.pip install ansible 3.https://releases.ansible.com/ansible or https://github.com/ansible/ansible.git 查看ansible 版本 ：ansible --version 使用要求： 服务端要求： Python2/3，Linux操作系统，不支持Windows 被管理端要求 OpenSSH，Python2.6/2.7 2.配置文件 vi /etc/ansible/ansible.cfg 来源： oschina 链接： https://my.oschina.net/u/3966437/blog/4287058

之前我们最常用的就是命令模式，也简称为“临时命令模式”。如下： [root@chuangxindasai-prometheus ansible]# ansible ceph -m ping 172.18.0.132 | SUCCESS => { "ansible_facts": { "discovered_interpreter_python": "/usr/bin/python" }, "changed": false, "ping": "pong" } 172.18.0.133 | SUCCESS => { "ansible_facts": { "discovered_interpreter_python": "/usr/bin/python" }, "changed": false, "ping": "pong" } 172.18.0.131 | SUCCESS => { "ansible_facts": { "discovered_interpreter_python": "/usr/bin/python" }, "changed": false, "ping": "pong" } [root@chuangxindasai-prometheus ansible]# ansible ceph -m shell -a "hostname" 172.18.0.131 |

一篇文章带你玩转TiDB灾难恢复 一、背景 高可用是 TiDB 的另一大特点，TiDB/TiKV/PD 这三个组件都能容忍部分实例失效，不影响整个集群的可用性。下面分别说明这三个组件的可用性、单个实例失效后的后果以及如何恢复。 TiDB TiDB 是无状态的，推荐至少部署两个实例，前端通过负载均衡组件对外提供服务。当单个实例失效时，会影响正在这个实例上进行的 Session，从应用的角度看，会出现单次请求失败的情况，重新连接后即可继续获得服务。单个实例失效后，可以重启这个实例或者部署一个新的实例。 PD PD 是一个集群，通过 Raft 协议保持数据的一致性，单个实例失效时，如果这个实例不是 Raft 的 leader，那么服务完全不受影响；如果这个实例是 Raft 的 leader，会重新选出新的 Raft leader，自动恢复服务。PD 在选举的过程中无法对外提供服务，这个时间大约是3秒钟。推荐至少部署三个 PD 实例，单个实例失效后，重启这个实例或者添加新的实例。 TiKV TiKV 是一个集群，通过 Raft 协议保持数据的一致性（副本数量可配置，默认保存三副本），并通过 PD 做负载均衡调度。单个节点失效时，会影响这个节点上存储的所有 Region。对于 Region 中的 Leader 节点，会中断服务，等待重新选举；对于 Region 中的 Follower 节点