CISCO Crosswork 工作流管理器

使用 Docker Installer Tool 安装 CWM
本节包含以下主题:
使用 Docker Installer Tool 安装 CWM,第 1 页
使用 Docker Installer Tool 安装 CWM
CWM 2.0 安装在 Cisco Crosswork 平台上,首先部署 Crosswork OVA file 使用 VMware vCenter 7.0(或更高版本)上的 Docker 映像,然后安装 CWM CAPP file 使用安装脚本。
先决条件
- VMware vCenter Server 7.0(U3p 或更高版本)和 ESXi 7.0(U3p 或更高版本)。有关更多详细信息,请参阅 Crosswork Network Controller 7.0 安装要求。
- Docker 版本 19 或更高版本。
- sshpass 已安装。对于 Mac,您可以使用 brew install sshpass。
使用脚本部署 Crosswork 和 CWM
程序
- 步骤 1 在支持 Docker 的机器上,创建一个目录,用于存储所有 file您将在安装过程中使用。
笔记
如果您使用的是 Mac,请确保目录名称是小写的。 - 第 2 步下载 OVA file 包含来自的 Crosswork 网络控制器包 思科公司 到你创建的目录。它将包含 Crosswork tar.gz CAPP file,CWM .ova file、install.sh安装脚本、configuration.json file 和 Docker 安装程序映像 tar.gz(连同此说明)。
- 步骤 3 运行以下命令导入 Docker 安装程序镜像。请务必根据需要调整镜像名称:docker image import .tar.gz 你的图像名称:你的-tag
- 步骤 4 在目录中创建一个 .txt file 并粘贴下面提供的 VMware 安装模板。在本说明中,我们将命名为 file 例如,deployment.tfvars.txtamp目的。
Cw_VM_Image = “”# 安装程序自动添加的行。- ClusterIPStack = “IPv4”
- 数据IP网络掩码 = “255.255.255.0”
- 数据IP网关 = “192.168.1.1”
- DNS =“DNS”
- 域名 = “域名”
- CWPassword =“你的crosswork密码”
- VMSize =“XLarge”
- 虚拟机大小 = {
- “超大” = {
- vCPU = 24
- CPU预留=24000
- //内存(兆字节)
- 内存 = 128000
- }
- }
- NTP =“ntp.esl.cisco.com
- 时区 = “欧洲/巴黎”
- EnableSkipAutoInstallFeature =“True”
- ManagementVIP = “你的管理贵宾”
- 管理IP网络掩码 = “255.255.255.0”
- 管理IP网关 = “your_mgmt_gateway”
- ThinProvisioned =“真”
- DataVIP = “你的数据vip”
- CwVM = {
- “0” = {
- VMName =“您的虚拟机名称”,
- 管理IP地址 = “你的管理IP”,
- 数据IP地址 = “你的数据IP”,
- 节点类型 = “混合”
- }}
- VCenterDC = {
- VCenterAddress =“您的vcenter地址”,
- VCenterUser =“您的用户名”,
- VCenterPassword =“您的密码”,
- DCname =“您的数据中心名称”,
- MgmtNetworkName = “虚拟机网络”,
- DataNetworkName =“SVM数据网络”
- 虚拟机 = [{
- HostedCwVMs = [“0”],
- 主机 = “your_VM_host”,
- 数据存储 = “your_VM_datastore”,
- HSDatastore = “你的虚拟机的 hsdatastore”
- }
]} - SchemaVersion =“7.1.0”
- 笔记
- 注意 VCenter 和数据中心之间的区别。
- 步骤 5 编辑参数以匹配您的部署。
笔记
要了解有关安装参数的更多信息,请参阅 Cisco Crosswork Network 中的“单 VM”章节
控制器 7.0 安装指南。 - 步骤 6 在目录中,创建另一个 file 名为 product.json file 并粘贴下面的数据。
- {
- “产品ID”:“CWM”,
- “属性”: {
- “键1”:“值1”,
- “键2”:“值2”
- }}
- 步骤 7 打开 configuration.json file 并提供以下参数以匹配您的部署:
- {
- “SVM_NAME”:“您的虚拟机名称”,
- “主持人”: {
- “远程用户”:“你的用户名”,
- “远程密码”:“你的密码”,
- “远程主机”:“你的 scp 主机”,
- “远程端口”:“22”,
- “卡普_file”:“/路径/到/capp_file.tar.gz”
- },
- “cwm_login”:{
- “ip”:“你的管理ip”,
- “cwm_user”:“管理员”,
- “cwm_old_password”:“管理员”,
- “cwm_password”:“你的新密码”
- },
- “部署”:{
- “tfvars_path”:“/path/to/deployment.tfvars.txt”,
- “ova_file”:“/path/to/cwm.ova”,
- “product_json”:“/path/to/product.json”
- }
- }
- 对于主机,请提供 Crosswork CAPP 所在的 SCP 服务器的详细信息 file 位于主机地址和端口、您的用户名和密码以及路径 file.
- 在 cwm_login 中,输入您的管理 IP 以及默认的 Crosswork 用户名和密码。在 cwm_password 中,输入新密码,以便在安装完成后替换默认密码。
- 对于部署,请将上一步中创建的 deployment.tfvars.txt 的本地路径提供给 CWM OVA file 以及 product.json file.
- 步骤 8 从目录运行安装程序脚本:bash install.sh
这将启动 Crosswork 平台的安装过程,然后在平台部署后启动 CWM 的安装过程。 - 步骤 9 要跟踪 Docker 容器内的安装,请运行以下命令:sudo docker ps -a
复制启动安装的容器的 ID。通常其名称包含 OVA file名称,例如:cw-na-cwm-7.1.0-20-releasecnc710-250512-cwm-59-50
要查看日志,请运行:sudo docker logs your_container_id -f - 第 10 步 安装脚本完成且部署状态达到 100% 后,请转到 http://your_mgmt_vip_address:30603 并使用默认管理员用户和您在 configuration.json 中提供的密码登录。
系统
本节涵盖以下主题:
架构结束view,第 5 页
架构结束view
Cisco Crosswork Workflow Manager 2.0 架构是一个基于微服务的解决方案,运行于 CNC 平台之上。本节展示了一个图表,展示了其核心架构组件以及每个组件的简要说明。
UI 服务器:允许操作员添加和实例化工作流、输入工作流数据、列出正在运行的工作流以及监控作业进度。CNC UI 的“管理”部分允许用户添加工作器、管理工作器进程以及将适配器上的活动分配给工作器。- REST API:包括与 CWM 应用程序的所有交互:部署适配器、发布和实例化工作流、管理工作者、资源和秘密。
- API 服务器:将 API 请求分发到相关的微服务。
- 引擎:控制工作流处理的核心组件。它解释并管理工作流定义的执行。
- Engine Worker(工作流工作器):执行工作流任务。它从 Engine 接收工作流任务,按照正确的顺序执行,并将结果返回给 Engine。
- 工作线程管理器:管理工作流工作线程。它确保正在运行的工作线程数量正确,并且配置正确。
- 适配器管理器:管理系统使用的适配器。它安装、配置和更新适配器(“plugins”)并确保它们与系统兼容。
- 事件管理器:管理传入和传出的事件,并将其分派到正确的事件队列。事件是来自外部源的信号,工作流可以与之交互。
- 适配器 SDK 和 XDK:帮助开发者创建新的适配器,以便与外部系统集成。XDK 应用程序扩展了适配器 SDK 的功能,使开发者能够自动构建自定义适配器的接口和消息逻辑。
- 工作流定义:基于无服务器工作流规范以 JSON 格式编写的工作流代码。
- Crosswork 网络控制器 (CNC):CWM 应用程序的运行时平台。它是一组服务,提供必要的基础设施来支持集群部署中应用程序的部署和管理。
- PostgreSQL:系统用于存储和管理其数据的数据库。
- DSL 引擎:执行用于定义工作流的领域特定语言 (DSL)。它解析 DSL,生成适当的工作流代码,并进行编译以供执行。
- 引擎匹配:将传入事件与适当的工作流进行匹配。它根据事件数据和定义的工作流约束来确定应执行哪个工作流。
- 引擎历史记录跟踪已执行工作流的历史记录。它存储所有已完成、正在运行和失败的工作流的元数据和执行详细信息。
API
本节涵盖以下主题:
CWM API 结束view,第 7 页
使用 CNC 工作流自动化 Postman 集合,第 7 页
CWM API 结束view
Cisco 基于表述性状态转移 (REST) 设计原则开发了 Cisco Crosswork Workflow Manager API。您可以使用 HTTP 和数据 file使用 JSON 格式。API 使用相关的 HTTP 响应代码指示给定请求的成功或失败。数据检索方法需要 GET 请求,而添加、更改或删除数据的方法则需要 POST、PUT、PATCH 或 DELETE 方法(视情况而定)。如果您使用错误的请求类型发送请求,API 会返回错误。
您可以在 Postman 中使用 CWM 2.0 Postman 集合来使用 CWM API。
有关完整的 API 参考,请参阅专用的 DevNet 空间: https://devnetapps.cisco.com/docs/crosswork/workflow-manager/introduction/
使用 CNC 工作流自动化 Postman 集合
按照以下步骤将集合导入 Postman 应用程序并设置开发环境。
开始之前
确保您可以访问 Postman web 应用程序帐户或已安装 Postman 桌面应用程序。有关详细信息,请参阅 https://www.postman.com/downloads/
您还必须通过单击此链接下载 JSON 格式的 CNC Workflow Automation Postman 集合,然后将存档解压缩到可访问的存储资源中。
程序
- 步骤 1 启动 Postman 并转到收藏夹。
- 第 2 步单击“导入”,从“拖放到任意位置进行导入”屏幕中选择文件夹,然后指向从 CNC 工作流自动化 Postman 集合档案中解压缩的文件夹。
- 步骤3 进入环境并选择新导入的测试环境。
- 步骤 4 提供基础的当前值Url 和 endPoint 变量以匹配 CNC 工作流自动化实例的 IP 地址和端口。保存更改。
要访问 CNC 工作流自动化 API,请使用基础url/crosswork/cnc/v71/,其中基础url 是安装了 CNC Workflow Automation 的 Crosswork Network Controller (CNC) 实例的 IP 地址和端口号。例如amp网址:https://172.22.141.178:30603
活动
本节涵盖以下主题:
事件处理结束view,第 9 页
定义 Kafka 事件,第 16 页
事件处理结束view
事件处理机制使 CWM 能够与外部代理交互,以处理出站和入站事件。工作流可以充当事件的消费者或生产者,这些事件可用于启动新的工作流或向现有工作流发出信号。对于您定义的每种事件类型,您可以添加关联属性来过滤事件并将其路由到等待包含特定属性值的事件的工作流。
事件消息需要根据 Cloud Events 规范进行定义。更多详情,请参阅第 15 页的“事件消息格式”。
经纪人和协议
CWM 支持 Kafka 代理以及 AMQP 和 HTTP 协议来处理事件。事件可以由 CWM 内部运行的工作流消费(由代理转发的传入事件),也可以由正在运行的工作流生成并转发到外部系统(由代理接收的传出事件)。
需要注意的是,CWM 本身并不充当事件代理。它提供了一种连接到外部代理来转发消息和事件的方法。
Kafka 经纪人
对于消费事件类型,CWM 会连接到 Kafka 代理并监听主题上的特定事件类型。一旦特定类型的事件注册到正确的主题,CWM 就会检索事件数据并将其转发到正在运行的工作流。然后,工作流会执行事件状态中定义的操作和/或运行另一个工作流执行(如果已选择)。
对于生成事件类型,正在运行的工作流会生成单个事件或一组事件,然后 CWM 会将这些事件转发给代理,并在正确的主题中发布它们。
只要发送了有效的内容类型,Kafka 代理就会接受特定语言 SDK 支持的所有事件消息格式。支持的格式列表请参见此 Github 链接: https://github.com/cloudevents/spec?tab=readme-ov-file
AMQP 协议(例如 RabbitMQ 代理)
对于消费事件类型,CWM 会连接到 AMQP 代理并监听队列中的特定事件类型。与 Kafka 代理类似,当特定类型的事件注册到正确的队列时,CWM 会检索事件数据并将其转发到正在运行的工作流。然后,工作流会执行事件状态中定义的操作和/或运行另一个工作流执行(如果已选择)。
对于生成事件类型,正在运行的工作流会生成单个事件或一组事件,然后 CWM 会将这些事件转发给代理,并将它们发布到正确的队列中。
只要发送了有效的内容类型,AMQP 代理就会接受特定 SDK 支持的所有事件消息格式。支持的事件格式列表如下: https://github.com/cloudevents/spec?tab=readme-ov-file
HTTP 协议
对于消费事件类型,CWM 会公开一个 HTTP 端点来监听任何传入事件。如果收到特定类型的事件,则会将其转发到正在等待该事件类型的工作流。
当事件被消费时,CWM 充当目标 HTTP 服务器。因此, URL CWM 服务器的有效内容是您为给定的 HTTP 事件类型提供的资源。
- 事件消息需要是 HTTP POST 请求,并且消息正文需要是表示云事件的 JSON 格式:
- { “规范版本”:“1.0”,
- “id”: “2763482-4-324-32-4”,
- “类型”:“com.github.pull_request.opened”,
- “来源”:“/传感器/tn-1234567/警报”,
- “数据内容类型”:“text/xml”,
- “数据”: ” ”,
- “contextAttrName”:“contextAttrValue”}
- 对于生成事件,工作流会生成 Cloud Event 格式的事件,然后 CWM 会将其转发为
- 向外部系统公开的 HTTP 端点发送 HTTP POST 请求。HTTP 端点地址由主机名和端口号组成。 URL 在 CWM 中的资源配置和
- 工作流定义中的事件定义。在资源配置中,您可以将请求方法更改为 PUT 或其他,并添加键值对作为标头(JSON 格式):

事件系统配置
以下主题涵盖事件配置的详细信息。
事件系统配置:秘密
在事件配置中,密钥存储了连接到由发送或接收事件的第三方服务公开的代理或端点所需的凭据。这包括基本身份验证:用户名和密码。您在创建密钥时提供的密钥 ID 将在创建资源时引用,因此您需要预先添加密钥。有关详细信息,请参阅第 16 页上的“步骤 1:创建 Kafka 密钥”。
事件系统配置:资源
资源是您提供访问第三方服务公开的事件代理或端点所需的所有连接详细信息(包括密钥)的地方。根据您要使用的代理/协议,您可以从三种默认事件资源类型中进行选择
- 系统.事件.amqp.v1.0.0
- 系统.事件.kafka.v1.0.0
- 系统.事件.http.v1.0.0
- 请注意,每个都有一组不同的配置字段
- 对于 AMQP,请以以下格式提供 ServerDSN amqp //localhost 5723。
- 对于 Kafka:
- KafkaVersion:输入您的 Kafka 版本。检查 Kafka 版本的标准方法是在终端中运行 bin/kafka topics.sh version。
- 经纪人:按以下格式输入您的 Kafka 经纪人地址 [“localhost 9092”,“192.168.10.9 9092”]。
- 其他设置:包含默认 Kafka 设置值的可编辑列表。您可以根据需要修改这些值。详情请参阅下方的“Kafka 其他设置”表格。
对于 HTTP:
产生事件类型:填写 URL 字段和可选的方法和标题(例如ample,客户端 ID 标头名称和值作为 JSON 对象)。
这 URL 需要是目标 HTTP 服务器的地址,但不能是 URL 路径。您将输入 URL 配置事件类型时将路径作为终点。
笔记
消费事件类型:填写 URL 与服务器的字段 URL 例如,您的 CWM 实例amp乐,192.168.10.9 9092。
请记住提供 URL 您的 CWM 实例没有 URL 路径 (/event/http)。您将输入 URL 配置事件类型时将路径作为终点。
表 1:Kafka 其他设置
| 场地 | 描述 |
| 客户编号 | Kafka 代理用来跟踪请求来源的标识符 |
| Kafka版本 | 指定客户端兼容的 Kafka 版本(例如“2.0.0”) |
| 元数据已满 | 当 True 时,获取所有主题的元数据,而不仅仅是需要的 |
| 管理员重试次数 | 管理请求的最大重试次数(例如,创建/删除主题) |
| NetSASLVer版本 | SASL(简单身份验证和安全层)协议的版本 |
| 管理超时秒数 | 管理员请求(例如,主题创建)的超时时间(秒) |
| ConsumerFetchMin | 代理应返回给消费者的最小数据量(以字节为单位) |
| 元数据重试次数上限 | 获取元数据(例如主题和分区信息)的最大重试次数 |
| NetS ASL 握手 | 为 True 时,启用 SASL 握手机制 |
| 网络拨号超时秒数 | 与 Kafka 建立连接的超时时间(秒) |
| 网络读取超时(秒) | 从 Kafka 读取数据的超时时间(秒) |
| 网络写入超时秒数 | 向 Kafka 写入数据的超时时间(秒) |
| 生产者超时秒数 | 向 Kafka 生成消息的超时时间(秒) |
| 消费者获取默认值 | 消费者获取请求的默认大小(以字节为单位)(例如 1MB) |
| 生产者必需确认 | 指定消息被视为成功所需的来自代理的确认数量(例如“WaitForLocal”) |
| 生产者返回错误 | 当为 True 时,启用失败的生产请求的错误报告 |
| 消费者隔离级别 | 指定消费者是否读取未提交或已提交的消息(“ReadUncommitted”允许读取正在进行的事务) |
| 消费者抵扣初始 | 当没有提交偏移量时的初始偏移量(最新偏移量为 -1) |
| 场地 | 描述 |
| 净最大打开请求秒数 | 通过网络打开请求的最长时间 |
事件类型
- 要创建新的事件类型,您需要向 CWM 添加资源和密钥。
- 添加事件类型时,以下字段可用:
- 事件类型名称:事件类型的名称。稍后会在工作流定义中引用它。
- 资源:先前添加到 CWM 的资源列表。
- 事件源:完全由用户定义的条目,将在工作流定义中引用。对于生产事件类型而言是必需的。
- 端点:Kafka 主题(事件流)的名称、AMQP 端点(终点)或 HTTP URL (主机)路径。
- 注意对于 HTTP 消费事件类型,请提供 /event/http 作为您的端点。
- 选择种类:由两个选项组成的列表:消费或生产事件种类。
- 注意 CWM 尚不支持 both 选项。
- 启动监听器(仅适用于消费类型):选中它可以开始监听定义的事件类型。
- 运行作业(仅适用于消费类型):如果您希望在收到事件时触发工作流,请勾选此复选框。然后从列表中选择所需的工作流。
相关属性
您也可以为事件设置上下文属性。这些属性仅适用于消费事件类型,并用于选择性地触发工作流。您可以 view 将它们作为一种自定义过滤器,用于细化入站事件数据并将它们路由到正确的工作流,以监听具有特定相关属性值的事件类型。
要向事件类型添加属性,请单击添加属性,然后提供属性名称。
关联属性完全由用户定义。它们需要与要路由到指定工作流的云事件消息中声明的 JSON 键值对相匹配。
事件消息格式
事件消息必须遵循 Cloud Events 规范格式。遵循该规范的最小可行事件消息将包含以下参数:
- {
“ - 规范版本”:“1.0”,
- “id”:“00001”,
- “类型”:“com.github.pull_request.opened”,
- “来源”:“/传感器/tn-1234567/警报”
- }
- 该消息可以携带额外的参数,例如“datacontenttype”、“data”和关联上下文属性名称(本例中为 contextAttrName)amp乐):
- {
- “规范版本”:“1.0”,
- “id”: “2763482-4-324-32-4”,
- “类型”:“com.github.pull_request.opened”,
- “来源”:“/传感器/tn-1234567/警报”,
- “数据内容类型”:“text/xml”,
- “数据”: ” ”,
- “contextAttrName”:“contextAttrValue”
- }
- 工作流事件定义和状态
- 在工作流定义中,有两个主要的语法元素用于处理工作流将等待的事件。它们是:
- 事件定义:用于定义事件类型及其属性。例如amp乐:
- {
- “姓名”:“申请人信息”,
- “类型”:“org.application.info”,
- “源”:“应用程序源”,
- “相关性”: [
- {
- “contextAttrName”:“申请人ID”
- }
- ]
- }
- • 事件状态:用于定义事件发生时要采取的操作。例如amp乐:
- {
- “名称”:“MonitorVitals”,
- “类型”:“事件”,
- “事件”:[
- {
- “动作”:[
- {
- “函数引用”:{
- “refName”:“大写”,
- “参数”:{
- “输入”: {
- “in”:“病人${ .patient }发高烧”
- }
- }
- }
- }
- ],
- “事件引用”:[
- “体温升高”
- ]
- }
- ]
- }
- 定义 Kafka 事件
- 在以下主题中,我们将创建一个 Kafka 事件并将其添加到新的工作流中。唯一的先决条件是:
- 完全设置的 Kafka 服务。
- 已安装 CWM。
- 步骤 1:创建 Kafka 机密
为了启用与 Kafka 服务的安全连接,您需要创建一个包含 Kafka 凭证的密钥和一个包含连接详细信息的资源。
程序
| 命令 or 行动 | 目的 | |
| 步骤 1 | 在 CNC 中,选择 行政 > 工作流管理 > 秘密. | |
| 步骤 2 | 点击 添加秘密. | |
| 步骤 3 | 在 新的秘密 view中,指定以下内容: | |
| 步骤 4 | 选择机密类型后,将在 秘密 输入详细信息部分。填写以下字段: | |
| 步骤 5 | 单击创建密钥。 |
步骤 2:创建 Kafka 资源
您还需要创建一个包含连接详细信息的资源。
| 命令 or 行动 | 目的 | |
| 步骤 1 | 在 CNC 中,选择 行政 > 工作流管理 > 资源. | |
| 步骤 2 | 点击 添加资源. |

步骤 3:添加事件类型
当您掌握秘密和资源后,就该指定要使用或生成的事件类型了。
程序
| 命令 or 行动 | 目的 | |
| 步骤 1 | 在 CNC 中,选择 行政 > 工作流管理 > 事件类型. | |
| 步骤 2 | 点击 添加事件类型. | |
| 步骤 3 | 在 新事件类型 窗口,提供所需的输入: |

步骤 4:在工作流中定义事件
现在我们已经添加了事件类型,我们可以创建一个工作流来注册此事件类型,并在 CWM 收到该事件时执行相应的操作。为此,我们需要:
- 使用事件定义来定义事件。
- 指定事件状态
- 定义事件发生时要采取的行动。
作为前任amp例如,让我们考虑这样一种场景:路由器过热警报(入站事件)触发单个工作流事件状态,并定义两个要针对该状态执行的补救措施。
- {
- “id”:“HighRouterTempWorkflow”,
- “name”:“路由器过热报警工作流程”,
- “开始”:“补救高温”,
- “事件”:[
- “种类”:“消耗”,
- “名称”:“HighRouterTemp”,
- “类型”:“HighRouterTemp”,
- “来源”:“监控.app”
- }
- ],
- “状态”:[
- {
- “结尾”: {
- “终止”:真
- },
- “名称”:“RemediateHighTemp”,
- “类型”:“事件”,
- “事件”:[
- {
- “动作”:[
- {
- “函数引用”:{
- “refName”:“调度技术员”,
- “上下文属性”:{
- “路由器IP”:“${ .路由器IP }”
- },
- “resultEventTimeout”:“PT30M”
- }
- }
- ],
- “事件引用”:[
- “路由器温度高”
- ]
- },
- {
- “动作”:[
- {
- “函数引用”:{
- “refName”:“移动流量”,
- “上下文属性”:{
- “路由器IP”:“${ .路由器IP }”
- },
- “resultEventTimeout”:“PT30M”
- }
- }
- ],
- “超时”:{
- “actionExecTimeout”:“PT60M”
- }
- }
- ]
- }
- ],
- “版本”:“1.0.0”,
- “描述”:“修复路由器过热”,
- “specVersion”:“0.8”
笔记
这个前任ample 不是一个完整的工作流程。它是一个 examp如何在工作流中定义事件,设置简单状态,然后定义响应该状态的操作。实际的工作流可以定义更多状态,并定义响应每个状态的操作。
文件/资源
![]() |
CISCO Crosswork 工作流管理器 [pdf] 用户指南 Crosswork 工作流管理器、工作流管理器、管理器 |

