webhook

下边回到我们的原始需求，来看下邮件开关机应该如何解决安全问题 分析这个需求，其实可以通过Microsoft Flow + Azure Automation的方式实现，首先O365邮箱接收邮件，然后通过Flow触发Azure Automation的runbook，在runbook里定义好我们需要执行的的任务，这样就可以实现我们需要的功能了 而身份验证实际上这里用的是我们之前讲的第二种，也就是service principal的方式，automation本身实际就是使用的service principal的方式，在Azure AD中实际上是可以看到automation注册的application的 而Flow触发runbook，其实可以通过Flow来触发webhook，而automation其实是可以直接创建webhook的，这样其实就可以直接通过Flow触发Azure automation的webhook，我们的需求就可以实现了 关于Microsoft Flow，如果说有人了解的不是很多的话，可以这里先做一个简单的介绍 Microsoft Flow实际上是一个在线的workflow的service，可以在多个app之间执行一些自动化的任务，Flow对接的系统非常的多，比如Facebook，Twitter，Dynamic CRM，O365 目前来说，可以通过Flow对接超过200个服务

参考文章： 从零搭建Prometheus监控报警系统 什么是Prometheus? Prometheus是由SoundCloud开发的开源监控报警系统和时序列数据库(TSDB)。Prometheus使用Go语言开发，是Google BorgMon监控系统的开源版本。 2016年由Google发起Linux基金会旗下的原生云基金会(Cloud Native Computing Foundation), 将Prometheus纳入其下第二大开源项目。 Prometheus目前在开源社区相当活跃。 Prometheus和Heapster(Heapster是K8S的一个子项目，用于获取集群的性能数据。)相比功能更完善、更全面。Prometheus性能也足够支撑上万台规模的集群。 Prometheus的特点 多维度数据模型。 灵活的查询语言。 不依赖分布式存储，单个服务器节点是自主的。 通过基于HTTP的pull方式采集时序数据。 可以通过中间网关进行时序列数据推送。 通过服务发现或者静态配置来发现目标服务对象。 支持多种多样的图表和界面展示，比如Grafana等。 官网地址： https://prometheus.io/ 架构图 基本原理 Prometheus的基本原理是通过HTTP协议周期性抓取被监控组件的状态，任意组件只要提供对应的HTTP接口就可以接入监控

commit message 应该如何写才更清晰明了？团队开发中有没有遇到过让人头疼的git commit？本文分享在git commit规范建设上的实践，规定了commit message的格式，并通过webhook在提交时进行监控，避免不规范的代码提交。 Git每次提交代码都需要写commit message，否则就不允许提交。一般来说，commit message应该清晰明了，说明本次提交的目的，具体做了什么操作……但是在日常开发中，大家的commit message千奇百怪，中英文混合使用、fix bug等各种笼统的message司空见怪，这就导致后续代码维护成本特别大，有时自己都不知道自己的fix bug修改的是什么问题。基于以上这些问题，我们希望通过某种方式来监控用户的git commit message，让规范更好的服务于质量，提高大家的研发效率。 初期我们在互联网上搜索了大量有关git commit规范的资料，但只有Angular规范是目前使用最广的写法，比较合理和系统化，并且有配套的工具（IDEA就有插件支持这种写法）。最后综合阿里巴巴高德地图相关部门已有的规范总结出了一套git commit规范。 commit message格式 <type>(<scope>): <subject> type(必须) 用于说明git commit的类别，只允许使用下面的标识。

前面已经介绍过了 .Net Core 程序发布到 Docker 容器 的内容。但是每次通过 SSH 链接到服务器敲命令，运行脚本也是挺麻烦的一件事。程序员是最懒的，能让电脑解决的问题绝不手动解决，如果当我们push一次代码后自动build代码，自动跑单元测试，如果测试通过，自动发布程序，如果失败就发邮件通知管理员，这样的话该多美好。为了达成这个目标于是持续集成(CI)持续交付/部署(CD)就被发明出来了。CICD领域有个大名鼎鼎的工具：Jenkins，但是这次不使用它。如果你使用阿里云的话，阿里云已经提供了类似的功能，可以免去自己搭建Jenkins服务，以及Docker镜像私仓的过程，而且目前它们是免费的。 阿里云Codepipeline服务，是一套类似Jenkins的服务（其实我觉得它的核心引擎就是来自Jenkins）。 阿里云容器镜像服务，是一个镜像仓库，可以是公开的，也可以是私有的。 持续集成CI 持续集成指的是，频繁地（一天多次）将代码集成到主干。 它的好处主要有两个。 （1）快速发现错误。每完成一点更新，就集成到主干，可以快速发现错误，定位错误也比较容易。 （2）防止分支大幅偏离主干。如果不是经常集成，主干又在不断更新，会导致以后集成的难度变大，甚至难以集成。 持续集成的目的，就是让产品可以快速迭代，同时还能保持高质量。它的核心措施是，代码集成到主干之前

不想看前面这么多废话的可以直接跳到 具体实现 Github Actions 是什么？ 说到 Github Actions 不得不提一下。 持续集成 （continuous integration）：高质量的让产品快速迭代 持续交付 （continuous delivery）：交付给团队测试 持续部署 （continuous deployment）：持续交付的下一步核心概念团队测试完成后自动部署到生产环境 CI/CD 是由很多操作组成的(如：执行单元测试、语法检查、打包、部署等等)。Github 把这些操作称为 action ，不同的项目很多的操作都是类似，Github 把这些操作整合成了一个 市场 允许大家发布或使用别人写好的 action 。 Github Actions 的核心概念 操作（Action） action 是工作流中最小的可移植模块 可以创建属于自己的 action ，使用 Github 社区提供的 action 以及自定义公开的 action 在工作流中使用需要将其作为 steps 包含 使用是 用户名/仓储名/版本(或分支) 如： actions/checkout@master 事件（Event） 触发工作流运行的特定事件 Github 本身事件 提交 、 创建问题 、 PR 等 使用 webhook 配置发生在外部的事件 具体事件请参阅 GitHub

此为系列博客 阿里云服务器 CentOS7 Tomcat + Jenkins+国内镜像 TAPD关联Jenkins （当前位置） TAPD pytest自动化测试部署 (git or 本地) TAPD的关联主要参考官方文档https://www.tapd.cn/help/view#1120003271001002987 1. 在TAPD中的操作 首先在流水线设置中找到Jenkins 然后下载插件，并点击新增服务 记录Webhook，一会儿要用 2. 在Jenkins中的操作 在系统管理中找到插件管理 选择刚才下载的插件，安装，重启 点击用户名，选择设置，添加API Token，记得复制 插件配置 在系统管理中找到TAPD Jenkins名称随便搞 访问地址就是当前Jenkins的url API Token就是刚才的API Token Webhook和Secrect Token 就是在TAPD平台中的内容 3. 配置成功！ 如果配置成功的话，就可以在TAPD平台流水线配置中的“关联已有服务”中找到自己的流水线啦 ———————————————— 来源： oschina 链接： https://my.oschina.net/xiaominmin/blog/4294753

https://www.cnblogs.com/chenchen-tester/p/10025420.html 下载所需插件，系统设置--》插件管理，搜索以下两个插件，选择安装 登录gitLab，生成一个Personal Access Tokens 进入Jenkins，添加api token,路径：首页--》凭据--》添加凭据 添加后再次打开，如图所示 然后打开系统管理，进入系统设置，配置gitLab 然后进入job，进行配置 进入GitLab,打开项目--》settings 测试成功，返回200 到此，触发器配置成功，开发一旦有提交代码，就会自动构建，如图所示 Ps:遇到的问题：gitLab上添加webhook保存，报错Requests to localhost are not allowed 解决方案：需要使用管理员帐号登录，进入Admin area，在Admin area中，在settings标签下面，找到OutBound Request，勾选上Allow requests to the local network from hooks and services ，保存更改即可解决问题 来源： oschina 链接： https://my.oschina.net/xxjbs001/blog/4439728

本章主要对如何使用开源组件和Alertmanager组件集成警报通知。Kubernetes的警报集成后续会直接在配置文件讲解，原理大同小异，此处仅对相关警报通知做集成。 警报通知接收器 前面一直是在Web UI 查看警报信息，现在开始使用接收器与Alertmanager集成，发送警报信息到 Email 、 企业微信 、 钉钉机器人 ，对于警报要求比较高的同学，可以根据下面提到的开源组件 【PrometheusAlert全家桶】 配置飞书、短信、语音电话等警报。 Email 前面已经讲过，Alertmanager默认支持配置Email，也是最普通的方式，在Alertmanager组件中内置了SMTP协议。直接可以把前面的Alertmanager.yml中的SMTP部分截取出来，然后进行调整与配置 global: resolve_timeout: 5m # smtp配置 smtp_from: "1234567890@qq.com" # 发送邮件主题 smtp_smarthost: 'smtp.qq.com:465' # 邮箱服务器的SMTP主机配置 smtp_auth_username: "1234567890@qq.com" # 登录用户名 smtp_auth_password: "auth_pass" # 此处的auth password是邮箱的第三方登录授权密码，而非用户密码

本文主要为您介绍容器服务ACK与原生Kubernetes名词对照情况。 容器服务ACK 原生Kubernetes 集群 Cluster 节点 Node 容器 Container 镜像 Image 命名空间 Namespace 无状态 Deployment 有状态 StatefulSet 任务 Job 定时任务 CronJob 服务 Service 路由 Ingress 标签 Label 配置项 Configmap 保密字典 Secret 存储卷 PersistentVolume 存储声明 PersistentVolumeClaim 水平弹性伸缩 HPA 虚拟集群IP Cluster IP 节点端口 NodePort 负载均衡 LoadBalancer 节点亲和性 NodeAffinity 应用亲和性 PodAffinity 应用非亲和性 PodAntiAffinity 选择器 LabelSelector 注解 Annotation 触发器 Webhook 端点 Endpoint 资源配额 Resource Quota 资源限制 Limit Range 模板 Template 工作负载 Workload 来源： oschina 链接： https://my.oschina.net/huanke/blog/4471319

本文主要为您介绍容器服务ACK与原生Kubernetes名词对照情况。 容器服务ACK 原生Kubernetes 集群 Cluster 节点 Node 容器 Container 镜像 Image 命名空间 Namespace 无状态 Deployment 有状态 StatefulSet 任务 Job 定时任务 CronJob 服务 Service 路由 Ingress 标签 Label 配置项 Configmap 保密字典 Secret 存储卷 PersistentVolume 存储声明 PersistentVolumeClaim 水平弹性伸缩 HPA 虚拟集群IP Cluster IP 节点端口 NodePort 负载均衡 LoadBalancer 节点亲和性 NodeAffinity 应用亲和性 PodAffinity 应用非亲和性 PodAntiAffinity 选择器 LabelSelector 注解 Annotation 触发器 Webhook 端点 Endpoint 资源配额 Resource Quota 资源限制 Limit Range 模板 Template 工作负载 Workload 来源： oschina 链接： https://my.oschina.net/huanke/blog/4471319