Just For Coding

Keep learning, keep living …

Python远程执行库Fabric简要介绍

之前的文章<<Ansible入门>>介绍了做为自动化配置管理的Ansible,这篇文章简要来介绍Python远程执行库Fabric

Fabric是一个通过SSH远程执行SHELL命令的库,主要用于自动化的安装部署及远程管理任务。Ansible也能够实现Fabric的这些能力,但Fabric更为轻量,只是单纯地用于远程执行。它本身是一个Python库,可以在我们自己的Python程序中直接import,并基于它实现远程命令执行。此外,它还提供了一个fab命令行工具,使用它可以更简单地编写我们需要执行的任务。这种模式被使用的更为普遍,我们主要来介绍以fab命令来使用fabric。

需要注意的是,Fabric的2.x版本并不兼容1.x版本,而且2.x版本很大程度上边缘化了fab命令行工具,因而我们还是来介绍1.x版本。当前最新1.x版本为1.14, 文档地址为:http://docs.fabfile.org/en/1.14/%E3%80%82

Python TUI库npyscreen简要介绍

之前的文章<<TUI库newt和snack简要介绍>>介绍了如何使用newt库开发控制台应用程序。newt库是一个非常简单的库,只适合开发逻辑为顺序流程的程序,比如,典型的程序安装向导。当程序逻辑较为复杂时,可以直接使用ncurses来实现。但ncurses是一个较为底层的库,使用它开发工作量会较大。本文介绍一个使用更为简易但可实现复杂功能的TUI库:npyscreen。

当前最新版本为4.10.5,如图:

基于PVLAN实现VMware vSphere环境DVS东西向防护

之前的文章<<VMware vSphere东西向网络防护>>介绍了基于不同VLAN来实现二层网络内虚拟机的东西向隔离防护技术。这种方法在每台ESXi主机上对VLAN ID的管理和分配较为烦琐,本文介绍基于PVLAN实现二层网络内东西向隔离防护的方法。由于VMware vSphere环境中只有DVS(Distributed Virtual Switch,分布式虚拟交换机)支持PVLAN,所以这种方法只能使用在DVS中。

PVLAN(Private VLAN,专用VLAN)技术是为了解决网络内需要大量隔离而VLAN ID不足的情况。它采用两层VLAN隔离技术,即上行的主VLAN(Primary VLAN)和下行的辅助VLAN(Secondary VLAN)。对上行设备而言,只可见主VLAN,而不可见辅助VLAN。辅助VLAN包含两种类型:隔离VLAN(isolated VLAN)和团体VLAN(community VLAN)。支持PVLAN的交换机的端口对应有三种类型: 隔离端口(isolated port),团体端口(community port),混杂端口(promiscuous port),它们分别对应隔离VLAN,团体VLAN和主VLAN。在隔离VLAN中,隔离端口之间不能通信,隔离端口只能和混杂端口通信。在团体VLAN中,团体端口之间以及团队端口与混杂端口之间都可以通信。

可以看到,隔离端口的特性天生就满足二层网络完全隔离的要求,为了能使他们通信,我们需要虚拟网络设备完成隔离端口间的数据包中继。

我们的测试环境由两台ESXi主机组成,通信双方虚拟机t1t2位于同一台ESXi主机,属于同一个二层网络,IP分别为:10.95.49.15010.95.49.151, 两台虚拟机的网络接口都接到分布式交换机DSwitchDPG-original端口组中。此时拓扑如图:

TUI库newt和snack简要介绍

大多数商业化软件产品一般会通过实现GUI(Graphical User Interface)或者TUI(Text-based User Interface/Textual User Interface/Terminal User Interface)来降低软件的使用难度。本文简要介绍一个TUI库: newt

newt是由RedHat开发,主要用在RatHat的Linux发行版本(RHEL, Fedora和CentOS)的安装程序项目Anaconda中。NEWT的全称是: Not Erik’s Windowing Toolkit,它基于S-Lang库实现。

因为newt是用于Linux发行版本的安装程序中,因而它的运行空间非常有限,需要保证程序尽可能小,所以在设计时选择使用C语言进行开发,也尽量不支持多余特性。于是在设计之初就不支持事件驱动。在支持事件驱动的窗口库中,有一个事件循环监听事件发生,根据发生的事件展示不同的窗口。在newt中,窗口创建和销毁基于栈模式,新创建的窗口位于之前的窗口之上,且只能展示最上层窗口,当最上层窗口销毁之后才能展示下边的窗口。这也就是说所有窗口都为模态窗口(model windows)。这种特性限制了newt库本身只适合用于完成顺序的程序流程,一个典型的场景就是程序的安装向导。SHELL程序往往也是顺序的流程,从SHELL程序转换为newt窗口程序完全不涉及程序流程的改变,实现非常简单。

Celery实例介绍

Celery是一个基于消息传递的分布式任务队列。与单纯的消息队列相比较,队列中传递的消息为任务(Task/Job)信息,而不是数据类信息,Celery基于这些消息完成了任务信息的管理。实现这种任务管理的相似项目还有Gearman,只不过这个项目已经很久未更新了,更推荐使用Celery。

Celery支持同步和异步执行两种模式。同步模式为任务调用方等待任务执行完成,这种方式等同于RPC(Remote Procedure Call), 异步方式为任务在后台执行,调用方调用后就去做其他工作,之后再根据需要来查看任务结果。Celery自己没有实现消息队列,而是直接已存在的消息队列作为Broker角色。官方推荐的Broker为RabbitMQ,除此之外,Redis、Beanstalkd、MongoDB等也都支持,具体可参考官方文档

Celery整体架构可以理解为下图:

D-BUS API查找与调用

上篇文章<<D-Bus实例介绍>>中简要介绍了D-Bus的基本概念,其中提到systemdNetworkManager等系统服务导出了D-Bus API供其他程序来调用。本文通过示例来说明这些API的查找与调用。

上篇文章我们提到D-Busobject可以实现多个InterfaceD-Bus规范中标准化了一些接口,这些接口对于我们调用其他服务提供的D-Bus API非常有帮助。

我们主要来看其中的两个:

它有一个方法:

1
org.freedesktop.DBus.Introspectable.Introspect (out STRING xml_data)

它会返回一个包含有对象(object), 接口(interface), 方法(methods), 信号(signals),属性(properties)等信息的XML字符串。对象如果实现这个接口, 我们就可以通过调用该方法了解这个对象对外提供的所有信息。

XML字符串的解析方法可以参考官方文档: https://dbus.freedesktop.org/doc/dbus-specification.html#introspection-format

D-Bus实例介绍

D-BusLinux及其他类UNIX系统上的一种IPC(Interprocess communication)机制。相较于传统的管道(PIPE)Socket等原生基于字节流的IPC方式,D-Bus提供了基于独立Message的传输方式,应用程序使用起来更加简单。D-Bus的设计初衷是为Linux桌面环境上的一系列应用程序提供通信方式,它的设计里保留了许多对上层框架设计考虑的元素。

D-Bus的常用架构与传统的Socket一对一通信模式不同,它基于中间消息路由转发的模式来实现, 如下图:

虚拟机KPTI性能影响分析

Meltdown漏洞暴发之后,各云厂商已陆陆续续升级宿主机,升级Guest是否有较大的性能影响, 是否应该升级Guest虚拟机等问题又困扰着云租户们。

本文基于实例来分析Guest虚拟机的性能影响。

首先来看Meltdown的原理。现代CPU架构在不同的安全等级运行指令。内核需要直接操作硬件,运行于最高权限,而几乎所有的应用程序都运行于各低权限上。用户态进程通过系统调用访问内核数据。一般情况下,CPU在执行时使用虚拟内存地址,内核使用页表来控制虚拟内存与物理内存的映射。用户态进程不能访问映射给内核的内存页。这些映射关系的计算较为耗时,因而CPU使用TLB(Translation lookaside buffer)来存储计算后的映射关系。从TLB中移除这些映射再重新计算并缓存会消耗性能,因而内核实现上会尽可能减少刷新TLB,于是内核将用户态和内核的数据都映射进用户态页表中。正常情况下,这不存在安全风险,页表的权限可以阻止用户态进程访问内核数据。