应用服务常常需要存取各种各样的机密信息，比如，数据库的访问凭证，依赖的外部服务的Token和Key，服务之间的通信凭证等等。在每个这样的应用中都重复实现机密信息的存取、更新与吊销等管理操作相当繁重，而且容易出问题。HashiCorp公司的开源项目Vault就将这部分工作以独立服务方式来实现，需要机密信息操作的应用可以与Vault服务交互完成相应的操作。

Vault的应用场景非常广泛，如:

• 机密信息存取
• 凭证的动态生成，比如数据库凭证、PKI证书、公有云服务的凭证等等
• 加密即服务

Vault架构非常清晰，如下图所示，主要分为三部分:

• HTTP/S API: Vault服务对外提供HTTP API接口
• Storage Backend: 负责加密数据的持久化存储, Vault支持多种存储机制。
• Barrier: 负责各种机密信息相关的处理逻辑，最核心的组件是Secrets Engine和Auth Method。Secrets Engine负责实际机密信息处理功能的实现，各种不同的Secrets Engine有着不同的功能服务，Auth Method提供各种不同的身份校验方法。这两个组件都依赖Plugin机制实现，如果官方提供的功能不满足需求，还可以自己写相应Plugin实现特有功能或身份校验方法。

在Kubernetes中, 所有的功能实现都以资源(Resource)形式体现。简单来说，资源就是Kubernetes的API端点(endpoint)，用于存储某种类型的对象。用户通过对资源对象的CRUD操作完成相应功能管理。Kubernetes 1.7之后添加了自定义资源(Custom Resource)的扩展能力，允许使用者通过定义自己的资源类型来扩展Kubernetes API，大大增强扩展Kubernetes的灵活性。这些自定义资源和Pod、Deployment等原生资源对象的操作方法基本一样。

用户使用CRD(Custom Resource Definitions)来定义自定义资源(Custom Resource)。CRD被创建后，Kubernetes APIServer会为CRD中指定的资源版本创建相应的RESTAPI端点。

CRD可以通过YAML文件来创建，YAML文件中指定CRD对象的规范，其中比较重要的字段有:

• metadata.name: 要创建的CRD名称
• spec.group: CRD对象所属的API组
• spec.version: CRD对象所属的API版本
• spec.names: 管理自定义资源所需要的名称描述，可以定义plural(复数名称), singular(单数名称)和shortnames(简称)等字段
• spec.names.kind: 指定自定义资源的类型名称
• spec.scope: 指明自定义资源有效范围，可以是整个集群有效(clustered)或命名空间内有效(namespaced)

在应用开发中，应用程序往往需要跟据特定策略的决策结果来判断后续执行何种操作。比如，权限校验就是策略决策的一种典型场景，它需要判断哪些用户对哪些资源能够执行哪些操作。这些策略可能随着时间需要不断的动态更新。当前策略决策的逻辑往往硬编码实现在软件的业务逻辑中，当需要更新策略规则集时，还需要修改应用代码、重新部署应用，非常不灵活。同时，不同的应用服务也都需要重复实现类似的功能，因而策略决策逻辑非常适合做为独立的模块从业务逻辑中抽离出来。

Open Policy Agent，官方简称OPA, 为这类策略决策需求提供了一个统一的框架与服务。它将策略决策从软件业务逻辑中解耦剥离，将策略定义、决策过程抽象为通用模型，实现为一个通用策略引擎，可适用于广泛的业务场景，比如:

• 判断某用户可以访问哪些资源
• 允许哪些子网对外访问
• 工作负载应该部署在哪个集群
• 二进制物料可以从哪些仓库下载
• 容器能执行哪些操作系统功能
• 系统能在什么时间被访问

需要注意的是，OPA本身是将策略决策和策略施行解耦，OPA负责相应策略规则的评估，即决策过程，业务应用服务需要根据相应的策略评估结果执行后续操作，策略的施行是业务强相关，仍旧由业务应用来实现。

OPA的整体逻辑结构如下图:

在一些场景下，运行在CloudFoundry和Kubernetes等平台上的Cloud Native应用需要使用各种各样的外部服务，如数据库，消息队列等。但应用开发者并不想关心这些服务的配置、管理和位置等信息，以便将精力集中在业务逻辑开发上。为了满足这种需要，CloudFoundry及Google等一系列公司创建了Open Service Broker API(OSBAPI)项目，致力于将外部服务的生命周期管理，应用平台与服务代理的交互，服务实例的访问等内容标准化。

OSBAPI规范定义了高度抽象的应用平台与外部服务代理的交互逻辑，规范化外部服务的使用，主要包括:

• 注册服务代理: 应用平台会获取服务代理提供的服务列表及相应规格，OSBAPI使用术语Plan来表示规格。
• Provision服务实例: OSBAPI使用术语Provision来统一指定服务资源的供应。在外部服务具体实现上，可以是创建虚拟机实例，也可以是分配资源，也可以是创建SaaS帐号等等。
• 绑定应用及服务实例: 当服务实例创建完成后，开发者想要其应用与该服务实例进行交互。从服务代理的角度来看，就是将应用与服务实例进行绑定。具体实现逻辑可以非常灵活，一般情况下，会生成访问该服务实例所需的新凭证。比如，生成数据库实例的IP、端口、用户名、密码等等。这些凭证会被返回给应用平台以提供给具体应用使用。

OSBAPI的具体工作模式如下图:

之前的文章<<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/。

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

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

之前的文章<<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主机组成，通信双方虚拟机t1和t2位于同一台ESXi主机，属于同一个二层网络，IP分别为:10.95.49.150和10.95.49.151, 两台虚拟机的网络接口都接到分布式交换机DSwitch的DPG-original端口组中。此时拓扑如图:

大多数商业化软件产品一般会通过实现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是一个基于消息传递的分布式任务队列。与单纯的消息队列相比较，队列中传递的消息为任务(Task/Job)信息，而不是数据类信息，Celery基于这些消息完成了任务信息的管理。实现这种任务管理的相似项目还有Gearman，只不过这个项目已经很久未更新了，更推荐使用Celery。

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

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

默认情况下，在OpenStack上私有网络上开启的虚拟机接口必须配置IP，否则网络包无法到达该接口。而之前的文章<<OpenStack私有网络旁路部署虚拟防火墙>>最后提到某些厂商的VFW只支持二层透明接入，那么我们怎样在OpenStack环境上跑通这样的VFW实例呢？本文来通过实例说明。

上篇文章的示例网络拓扑如下: