https://www.161616.top/tags/automation/ Recent content in Automation on Cylon's Collection Hugo -- 0.125.7 zh Sat, 25 May 2024 23:00:36 +0800 https://www.161616.top/stackstorm-sensors/ Fri, 24 May 2024 00:00:00 +0000 https://www.161616.top/stackstorm-sensors/ 工作流模型是指 Stackstorm 中 Orquesta 工作流的定义，包含工作流的执行方式，也可以理解为工作流模型就是 Workflow DSL 定义任务执行的有向图 工作流模型 下表是工作流模型 (Workflow Model) 的属性。工作流接受 Input，按预定义顺序执行一组任务 (Task)，并返回输出 (Output)。此处的工作流模型是一个有向图 (directed graph)，其中 Task 是节点，Taskt 之间的转换及其条件形成边。组成工作流的任务将在 DSL 中定义为名为 Task 的字典， 其中 Key 和 Value 分别是任务名称和任务模型。 Attribute Required Description version Yes The version of the spec being used in this workflow DSL. description No The description of the workflow. input No A list of input arguments for this workflow. vars No A list of variables defined for the scope of this workflow. https://www.161616.top/stackstorm-sensors/ Sat, 02 Dec 2023 00:00:00 +0000 https://www.161616.top/stackstorm-sensors/ 什么是传感器 传感器 (Sensor) 是将外部系统和事件与 StackStorm 集成的一种方式。传感器是 Python 代码片段，它们要么定期轮询某些外部系统，要么被动等待入站事件，通常示例用于每隔一段时间去轮询某一个对象，然后他们将 Trigger 注入 StackStorm，可以通过规则进行匹配，以执行潜在的 Action。 Sensor 是用 Python 编写的，并且必须遵循 StackStorm 定义的传感器接口要求。 什么是触发器 触发器 (Trigger) 是 StackStorm 中用于识别 StackStorm 的传入事件。Trigger 是类型（字符串）和可选参数（对象）的元组。编写 Rule 是为了与 Trigger 一起使用。Sensor 通常会记录 Trigger，但这并不是严格要求的。例如，有一个向 StackStorm 注册的通用Webhooks触发器，它不需要自定义传感器。 Stackstorm内置触发器 默认情况下，StackStorm 会发出一些内部 Trigger，您可以在规则中利用它们。这些触发器可以与非系统触发器区分开来，因为它们的前缀为 “st2”。 下面包含每个资源的可用 Trigger 列表： Action Reference Description Properties core.st2.generic.actiontrigger 封装 Action 执行完成的触发器 execution_id, status, start_timestamp, action_name, action_ref, runner_ref, parameters, result core.st2.generic.notifytrigger 通知触发器 execution_id, status, start_timestamp, end_timestamp, action_ref, runner_ref, channel, route, message, data core. https://www.161616.top/stackstorm-pack/ Thu, 30 Nov 2023 00:00:00 +0000 https://www.161616.top/stackstorm-pack/ 什么是包 包 “pack” 是扩展 StackStorm 的集成和自动化的部署单元。通常， pack 是沿着服务或产品边界组织的，例如 AWS、Docker、Sensu 等。 pack 包含Actions、Workflows、Rules、 Sensors和Aliases。StackStorm 内容始终是 pack 的一部分，因此了解如何创建 pack 并使用它们非常重要。 一些 pack 扩展了 StackStorm 以将其与外部系统集成，例如 AWS，GitHub，JIRA。我们称它们为“集成 pack ”。有些 pack 捕获自动化模式：这类 pack 含特定自动化过程的 workflow, Rule 和 Action - 例如st2 演示 pack 。我们称它们为“自动化 pack ”。这种命名主要是一种约定：StackStorm 本身对两者没有区别。 任何使用该 pack 所针对的服务的人都可以共享和重用集成 pack 。您可以在StackStorm Exchange找到许多这样的示例。自动化 pack 通常是特定于站点的，并且在特定团队或公司之外几乎没有用处；它们通常在内部共享。 总结：Packs是StackStorm中组织工作流、动作和传感器的方式。它们是一组相关的动作、工作流和传感器的集合，通常用于实现特定的自动化任务或集成。 包管理 StackStorm pack 通过命令进行管理：将为您提供有用的概述。st2 pack <...> / st2 pack -h 有些（例如core 基本 StackStorm action）是随 StackStorm 预装的。所有其他 pack 都需要您安装。幸运的是，这很容易！ list和get是获取有关本地 pack 信息的主要命令： https://www.161616.top/stackstorm-rules/ Sat, 25 Nov 2023 00:00:00 +0000 https://www.161616.top/stackstorm-rules/ StackStorm 使用 Rules 和 Workflows 来捕获操作模式并进行自动化。rule将 Triggers 映射到 Actions（或 Workflow），应用匹配条件( Criteria)，并将 Triggers payloads 映射到 Actions 的 Input。 注意 rule不按预期工作吗？请查看rule故障排除文档。其中介绍了rule测试、检查执行、记录和故障排除等内容。 Rule 的配置结构 stackstorm 中的 Rule 是以 YAML 格式来定义。以下是 Rule 定义结构以及 “必需”和 “可选” rule 元素的列表： yaml 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 --- name: "rule_name" # required pack: "examples" # optional description: "Rule description." # optional enabled: true # required trigger: # required type: "trigger_type_ref" criteria: # optional trigger. https://www.161616.top/stackstorm-pack-configuaration/ Thu, 18 May 2023 00:00:00 +0000 https://www.161616.top/stackstorm-pack-configuaration/ 基本概念 从版本 2.4 开始，如果包包含.config.yaml ，可以使用包配置，包配置可以使用配置文件来设置包中资源通用的值，例如 API 凭证、连接详细信息、限制和阈值。这些值在运行时可供操作和传感器使用。 包配置和 Action 参数之间的区别在于，配置通常包含包中所有资源通用的值，并且很少更改。动作参数是随每个动作调用动态提供的，并且可能会发生变化 - 例如，它们可能来自映射某些输入事件的规则。 包配置遵循基础架构即代码方法，并存储在特殊目录中的 YAML 格式文件中（默认情况下 /opt/stackstorm/configs）。每个包都为此配置文件定义自己的架构。 配置 Schema 配置文件的结构是一个 YAML 格式的文件，它定义了该包的配置文件。该配置由包作者自行编写，包含有关每个可用配置项的信息，例如名称, Secret等）。该文件已命名 config.schema.yaml 并位于包目录 /opt/stackstorm/packs/<mypack> 的根目录中。 这是一个示例包配置文件： yaml 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 --- api_key: description: "API key" type: "string" required: true api_secret: description: "API secret" type: "string" secret: true required: true region: description: "API region to use" type: "string" required: true default: "us-east-1" private_key_path: description: "Path to the private key file to use" type: "string" required: false 在该示例中，配置文件由 4 项 配置组成 (api_key, api_secret, region, private_key_path) https://www.161616.top/ansible/ Sat, 02 Jun 2018 00:00:00 +0000 https://www.161616.top/ansible/ 运维工具 OS Provisioning: PXE, Cobbler(repository,distritution, profile) PXE: dhcp, tftp, (http, ftp) dnsusq: dhcp, dns OS Config: puppet, saltstack, func Task Excute: fabric, func, saltstack Deployment: fabric 管理主机，要想管理被管理节点，二者必须有安全管理通道。puppet、saltstack在管理被管节点时，每一个被管节点必须运行puppet agent，管理端进程与每一个被管节点的agent进程进行通信，通信时使用的HTTP协议。此种方式必须在被管节点安装应用程序的agent，远程接收到指令，并在本地负责执行相应的任务。 根据远程管理时，是不是在每一个被管主机上安装agent端，分为两种puppet、func、saltstack；与无需agent端，ansible、fabric。依赖被管节点的ssh服务。而管理端需要知道对方主机上的账号密码。 ansible的组成 ansible核心 host invenory ：为了管控每个被管主机，每个主机在本地需要注册。用来定义由ansible远程配置管理的主机，每个主机的IP地址、掩码、SSH监听的地址、端口号、账号密码等。 core modules：ansible执行任何特定管理任务，都是不由ansible自身玩成的，而是通过模块完成的。 custom Modules：使用任何编程语言来编写模块。 playbooks：将主机要完成的多个任务，事先定义在文件中可以多次调用。 1 ansible的特性 基于Python语言实现，由Paramiko, PyYAML和jiniia2三个关键模块 部署简单，agentless 默认使用SSH协议 主从模式： master:ansible, ssh client slave: ssh server 支持自定文模块：支持各种编程语言，支持Playbook，基于“模块”完成各种“任务”。 安装依赖于epel源 配置文件： text 1 2 /etc/ansible/ansible.cfg Invertory:/etc/ansible/hosts 2 ansible命令应用基础 语法: ansible <host-pattern> [-f forks] [-m module_name] [-a args]