paramiko

负载均衡了A,B两台服务器win2008r2，同样的路径 D:\\IIS\\proName 放着Asp MVC4开放编译好的项目，每次团队修改bug或者添加新功能，我需要把A，B服务器的项目备份好，本机从TFS(感觉还是SVN好用点)获取最新代码，之后编译，再覆盖上服务器，操作的过程中要注意些问题，比如说服务器项目里的log4net生成的日志文件不要压缩备份，要不然压缩文件会很大，覆盖的时候，有些文件是不能替换的，比如说web.config，因为数据库连接等一些信息是不一样的，除此之外，还要做升级更新记录，以备领导查询等等 所以萌发搞一个程序自动化升级更新，之所以用Python，只是因为正在学习，当然另一方面是因为需要使用SSH协议来跟远程服务器交互，Python的paramiko插件比我拿手C#的ssh.net好用多 说说我的思路 1. 只压缩A服务器项目 2. 下载到本机解压 3. 本机TFS更新项目，编译发布 4. 对比获取服务器项目和本机发布项目的差异文件，并压缩差异文件，以及记录信息到数据库 5. 上传差异压缩包到A和B服务器，并覆盖替换 部分核心代码 # 压缩服务器项目 client = paramiko.SSHClient() client.set_missing_host_key_policy(paramiko.AutoAddPolicy()) client

首发自公.众.号：Python编程时光 在使用 Python 写一些脚本的时候，在某些情况下，我们需要频繁登陆远程服务去执行一次命令，并返回一些结果。 在 shell 环境中，我们是这样子做的。 $ sshpass -p ${passwd} ssh -p ${port} -l ${user} -o StrictHostKeyChecking=no xx.xx.xx.xx "ls -l" 然后你会发现，你的输出有很多你并不需要，但是又不去不掉的一些信息（也许有方法，请留言交流），类似这样 host: xx.xx.xx.xx, port: xx Warning: Permanently added '[xx.xx.xx.xx]:xx' (RSA) to the list of known hosts. Login failure: [Errno 1] This server is not registered to rmp platform, please confirm whether cdn server. total 4 -rw-r--r-- 1 root root 239 Mar 30 2018 admin-openrc 对于直接使用 shell 命令，来执行命令的，可以直接使用管道，或者将标准输出重定向到文件的方法取得执行命令返回的结果 1. 使用 subprocess

首发自公.众.号：Python编程时光 在使用 Python 写一些脚本的时候，在某些情况下，我们需要频繁登陆远程服务去执行一次命令，并返回一些结果。 在 shell 环境中，我们是这样子做的。 $ sshpass -p ${passwd} ssh -p ${port} -l ${user} -o StrictHostKeyChecking = no xx.xx.xx.xx "ls -l" 然后你会发现，你的输出有很多你并不需要，但是又不去不掉的一些信息（也许有方法，请留言交流），类似这样 host: xx.xx.xx.xx, port: xx Warning: Permanently added '[xx.xx.xx.xx]:xx' ( RSA ) to the list of known hosts. Login failure: [ Errno 1 ] This server is not registered to rmp platform, please confirm whether cdn server. total 4 -rw-r--r-- 1 root root 239 Mar 30 2018 admin-openrc 对于直接使用 shell 命令，来执行命令的，可以直接使用管道，或者将标准输出重定向到文件的方法取得执行命令返回的结果 1. 使用

买了个Linux服务器，Centos系统，装了个宝塔搭建了10个网站，比如有时候要在某个文件上加点代码，就要依次去10个文件改动,虽然宝塔是可视化页面操作，不需要用命令，但是也麻烦，虽然还有git的hook方法,但是操作也麻烦，新建个目录的话还得操作一次，所以萌生了一个想法，用Python来批量更新服务器上的文件 注意：很多人学Python过程中会遇到各种烦恼问题，没有人帮答疑容易放弃。为此小编建了个Python全栈免费答疑交流.裙 ：七衣衣九起起巴而五（数字的谐音）转换下可以找到了，不懂的问题有老司机解决里面还有最新Python教程项目可拿,，一起相互监督共同进步！ 序言 在网上搜索了一圈，发现Python有个库叫 paramiko 可以专门拿来干这个事，具体资料和安装就网上去搜索吧，我就直接上代码了,不到100行,其实还可以精简吧,后面再说了,先把功能实现了再说, Show Code 代码 import paramiko import os # 连接信息 host = 'xxx.65.9.191' port = 22 username = 'root' password = 'root' # 忽略的目录 skipArry = ['kai.xxxx.com','demo.xxxx.com'] fullpathArry = [] currentIndex = '' #

Python之路_Day13_课堂笔记 前期回顾 一、redis 发布订阅 二、rabbitMQ 原始队列 exchange ex全部转发 ex，关键字 ex，模糊匹配 rpc 三、MySQL 四、Python MySQL pymysql excute 执行单条语句 ，返回受影响的行数 excutemany 执行多条语句，返回受影响的行数 fetchone fetchall fetchmany scroll lastrowid 五、SQLAlchemy ORM框架 db first code first ====> 我们以后通过类和对象操作数据库 code first 1、自定义生成表 2、使用类操作表 本节摘要 一、ORM 连表 一对多 多对多 二、Paramiko模块 链接： 堡垒机 三、前端 HTML http://www.cnblogs.com/wupeiqi/articles/5699254.html 一、ORM—SQLAlchemy 连表 一对多 1、创建表，主动知道外键 2、操作： 类：repr 单表 连表 session.query(表1).join(表2).all() #!/usr/bin/env python# -.- coding:utf-8 -.-# By Sandlerfrom sqlalchemy import create_enginefrom

CMDB和运维自动化 一、运维 运维，指的是对已经搭建好的网络，软件，硬件进行维护。运维领域也是细分的，有硬件运维和软件运维 硬件运维 主要包括对基础设施的运维，比如机房的设备，主机的硬盘，内存这些物理设备的维护 软件运维 主要包括系统运维和应用运维，系统运维主要包括对OS，数据库，中间件的监控和维护，这些系统介于设备和应用之间，应用运维主要是对线上业务系统的运维 讨论的主要是软件运维的自动化，包括系统运维和应用运维的自动化 二、软件运维 传统运维 日常工作繁琐 日常运维工作是比较繁琐的，研发同学会经常需要到服务器上查日志，重启应用，或者是说今天上线某个产品，需要部署下环境。这些琐事是传统运维的大部分工作 应用运行环境不统一 在部署某应用后，应用不能访问，就会听到开发人员说，在我的环境运行很好的，怎么部署到测试环境后，就不能用了，因为各类环境的类库不统一 还有一种极端情况，运维人员习惯不同，可能凭自己的习惯来安装部署软件，每种服务器上运行软件的目录不统一 运维及部署效率低下 想想运维人员需要登陆到服务器上执行命令，部署程序，不仅效率很低，并且非常容易出现人为的错误，一旦手工出错，追溯问题将会非常不容易 无用报警信息过多 经常会收到很多报警信息，多数是无用的报警信息，造成运维人员经常屏蔽报警信 另外如果应用的访问速度出了问题，总是需要从系统、网络、应用、数据库等一步步的查找原因

CMDB概述 自动化运维特性 OS的选择统一化，同一个项目使用同样的OS系统部署其所需要的各类软件 软件安装标准化，例如JAVA虚拟机，php，nginx，mysql等各类应用需要的软件版本，安装目录，数据存放目录，日志存放目录等 应用包目录统一标准化，及应用命名标准化 启动脚本统一目录和名字，需要变化的部分通过参数传递 配置文件标准化，需要变化的部分通过参数传递 日志输出，日志目录，日志名字标准化 应用生成的数据要实现统一的目录存放 主机/虚拟机命名标准化，虚拟机管理使用标准化模板 使用docker比较容易实现软件运行环境的标准化 CMDB架构 CMDB设计模式 Agent方式 可以将服务器上面的Agent程序作定时任务（ crontab ），定时将资产信息提交到指定API录入数据库 本质上就是在各个服务器上执行 subprocess.getoutput() 命令，然后将每台机器上执行的结果，返回给主机API，然后主机API收到这些数据之后，放入到数据库中，最终通过web界面展现给用户。 优点：速度快 场景：适合机器多的情况 缺点：每个机器都要部署脚本 SSH方式（paramiko模块） 中控机通过paramiko模块登录到各个服务器上，执行命令获取服务器信息。 import paramiko # 创建SSH对象 ssh = paramiko.SSHClient() #

CMDB项目： cmdb包含的功能： 1、用户管理，记录测试，开发，运维人员的用户表 2、业务线管理，需要记录业务的详情 3、项目管理，指定此项目用属于哪条业务线，以及项目详情 4、应用管理，指定此应用的开发人员，属于哪个项目，和代码地址，部署目录，部署集群，依赖的应用，软件等信息 5、主机管理，包括云主机，物理机，主机属于哪个集群，运行着哪些软件，主机管理员，连接哪些网络设备，云主机的资源池，存储等相关信息 6、主机变更管理，主机的一些信息变更，例如管理员，所属集群等信息更改，连接的网络变更等 7、网络设备管理，主要记录网络设备的详细信息，及网络设备连接的上级设备 8、IP管理，IP属于哪个主机，哪个网段, 是否被占用等 1、自动化运维：分类：基础运维和应用运维 2、为什么需要 自动化运维 1. 项目上线: 流程: 产品经理调研(画出原型图) ---> 定需求 ---> 三方会谈(产品经理, 研发,老大们) ---> 定日期--->测试项目---> 最终上线---> 应用运维 目前: 是把代码打包给运维, 运维解压上线 问题: 随着机器数量的线性增加,运维的工作量也是线性增加, 重复而且是无意义的劳动 解决: 1. 写一个shell脚本, 进行部署 2. 搞一个自动化代码上线系统 必要条件: 服务器的各种信息 (主机名, cpu, 硬盘大小等) ​ 2. 监控系统:

CMDB和运维自动化 一、运维 运维，指的是对已经搭建好的网络，软件，硬件进行维护。运维领域也是细分的，有硬件运维和软件运维 硬件运维 主要包括对基础设施的运维，比如机房的设备，主机的硬盘，内存这些物理设备的维护 软件运维 主要包括系统运维和应用运维，系统运维主要包括对OS，数据库，中间件的监控和维护，这些系统介于设备和应用之间，应用运维主要是对线上业务系统的运维 讨论的主要是软件运维的自动化，包括系统运维和应用运维的自动化 二、软件运维 传统运维 日常工作繁琐 日常运维工作是比较繁琐的，研发同学会经常需要到服务器上查日志，重启应用，或者是说今天上线某个产品，需要部署下环境。这些琐事是传统运维的大部分工作 应用运行环境不统一 在部署某应用后，应用不能访问，就会听到开发人员说，在我的环境运行很好的，怎么部署到测试环境后，就不能用了，因为各类环境的类库不统一 还有一种极端情况，运维人员习惯不同，可能凭自己的习惯来安装部署软件，每种服务器上运行软件的目录不统一 运维及部署效率低下 想想运维人员需要登陆到服务器上执行命令，部署程序，不仅效率很低，并且非常容易出现人为的错误，一旦手工出错，追溯问题将会非常不容易 无用报警信息过多 经常会收到很多报警信息，多数是无用的报警信息，造成运维人员经常屏蔽报警信 另外如果应用的访问速度出了问题，总是需要从系统、网络、应用、数据库等一步步的查找原因