如何触发Harbor的12种Webhook事件
文章目录
- 前言
- 一、Harbor是什么？
- 二、 Harbor 架构简介
- 三、Harbor的Webhook触发12种事件
-
- webhook返回结构体
-
- Harbor权限管理和跨仓库镜像远程复制
- 总结
前言
近年来，随着docker容器技术的发展，各行业的各企业似乎都在探讨docker容器、弹性伸缩、持续集成等技术。 大家似乎都想借助docker容器技术登上云端。 个子高，长高一根。 脱轨了。 脱轨了。 今天不是共享镜像仓库吗？ 有机会可以和大家一起探讨这些新潮技术。 言归正传，回到这次的共享主题“Harbor集装箱镜像仓库”。 一个项目需要使用Harbor作为镜像的存储仓库，研究这个产品花了很多时间。 通过试用，我觉得用于管理docker镜像操作的可视化Web界面很简单，为多个项目提供了镜像权限管理控制。 接下来，我们将介绍Harbor镜像仓库管理。 介绍Harbor自身的特性以及Harbor专用仓库的构建方法。
提示：以下是本篇文章正文内容，下面案例可供参考
一、Harbor是什么？
VMware公司于去年3月开放了企业级集装箱Registry项目Harbor，由VMware中国开发的团队负责开发。 Harbor帮助用户快速构建企业级的注册表服务。 Harbor提供了图形界面管理、基于角色的访问控制RBAC、镜像远程复制(同步)、AD/LDAP集成和分析日志等满足企业用户需求的功能许多开源社区的开发人员也为Harbor项目添加了平铺，提供代码贡献、问题反馈和建议。 在大家的共同努力下，Harbor项目开始以来，在GitHub上获得了近2000颗好评星和500多只福克斯。
二、 Harbor 架构简介
三、Harbor的Webhook触发12种事件
事件源
webhook返回结构体
{"type":"PUSH_ARTIFACT",
"occur_at":1655810585,
"operator":"admin",
"event_data":{
"resources":
[{"digest":"sha256:706446e9c6667c0880d5da3f39c09a6c7d2114f5a5d6b74a2fafd24ae30d2078",
"tag":"1.14",
"resource_url":"192.168.4.207/base-images/nginx:1.14"}],
"repository":
{"date_created":1655352035,
"name":"nginx",
"namespace":"base-images",
"repo_full_name":"base-images/nginx",
"repo_type":"private"
}}}
- 1、Artifact deleted：当Artifact被删除时触发。
即删除Harbor仓库镜像即会触发
- 2、Artifact pulled：当Artifact被拉取时触发。
拉取Harbor仓库镜像即会触发 - 3、Artifact pushed：当Artifact被推送时触发。
push镜像到这个Harbor仓库即会触发
docker push 192.168.0.1/base-images/nginx:1.14
- 4、Chart deleted：当Helm Chart被删除时触发。
当删除helm Chart时候触发
- 5、Chart downloaded：当Helm Chart被下载时触发。
(3) 部署Chart
1) 下载后部署
# helm pull --version 0.1.0 harbor_lc_chart/demo
# helm install web demo-0.1.0.tgz -n default
2) 在线部署
# helm install web --version 0.1.0 harbor_lc_chart/demo -n default
- 6、Chart uploaded：当Helm Chart被上传时触发。
(1) 推送与安装Chart
1) 带用户名、密码、仓库url推送
# helm cm-push demo-0.1.0.tgz --username admin --password Harbor12345 http://172.16.1.61/chartrepo/lc_chart
Pushing demo-0.1.0.tgz to http://172.16.1.61/chartrepo/lc_chart...
Done.
2) 根据本地添加认证的仓库推送
# helm cm-push demo-0.1.0.tgz harbor_lc_chart
Pushing demo-0.1.0.tgz to harbor_lc_chart...
Done.
-
7、Quota exceed：当上传Artifact且项目配额超限时触发。
超出存储容量会触发 -
8、Quota near threshold：当上传Artifact且项目配额达到限制85%时触发。
-
9、Replication finished：当远程复制镜像任务完成时触发。
Harbor权限管理和跨仓库镜像远程复制
- 项目权限管理
角色权限分类：
项目管理员：项目管理、用户管理、镜像管理和复制策略等权限
开发人员：只能针对自己项目镜像具有pull/push等权限
访客：只能针对自己项目镜像具有pull权限
1）给testrpo项目分配一个漂亮的小鸽子xinju，角色权限为开发人员
2）通过xinju用户登录我们可以正常看到，testrpo项目，仓库中有2个镜像，权限为开发人员，只要上传和下载权限。无删除镜像权限。
3）通过API给项目添加用户权限（5代表项目testrpo）
- 跨仓库镜像远程复制
目前Harbor支持跨数据仓库镜像远程复制功能，从某种程度上满足了镜像仓库HA高可用。但复制策略是以"项目"为中心， 通过管理员对具体项目的Harbor源端配置"复制策略"，标明需要复制的项目以及镜像到harbor目标仓库。并对它的地址和连接时使用的用户名密码进行设置。当复制策略被激活时，Harbor源项目下的所有镜像，都会被复制到harbor目标仓库；此外，当Harbor源项目下的镜像被添加或删除（push或delete), 只要策略还在激活状态，镜像的变化都会同步到harbor目标仓库上去， 如下图所示：
以下验证一下如何完成跨仓库远程镜像复制功能
Harbor源仓库主机：192.168.56.105 （主节点）
Harbor目标仓库主机：192.168.56.106 （从节点）
将主节点的其中一个testrpo项目中的镜像文件同步到从节点中
1）登录Harbor源仓库web ui https:// 192.168.56.105,选择testrpo项目来做镜像同步
首先需要新建一个目标仓库
然后去选择目标仓库
3）开启复制策略，看到下面的复制任务已完成
4）登录Harbor目标仓（https://192.168.56.106）发现目标仓库中已经同步过来了testrpo目标中有两个镜像文件。
-
10、Scanning failed：当扫描镜像任务失败时触发。
选择扫描镜像，失败会触发 -
11、Scanning finished：当扫描镜像任务完成时触发。
-
12、Tag retention finished ：标签保留完成（创建标签去查询 存储库 A 中保留了 10 个最近拉出被标记Artifact ）
功能解释：用 Cosign 对 OCI 制品签名后，可将生成的签名推入（push）到 Harbor 中。这个签名作为制品的附件（accessory）和该制品一起存储。Harbor 管理和维护已签名制品和 cosign 签名之间的联系，在Tag保留规则（tag retention rules）和不可变规则（immutable rules）等功能中，Harbor的内置功能自动维护制品和签名之间的对应关系。
将 Cosign 与 Harbor 结合使用解决了之前一个悬而未决的问题：镜像等制品在远程复制中，其签名信息无法被复制到目标端。现在，当用户通过复制规则（replication rule）把已签名制品复制到远端时，Harbor 把签名信息也同步复制到了远端，使得远端的制品具有同样的签名。
操作步骤：
2. 创建新项目“cosign”
在项目中启用 cosign：
3. 创建新用户“cosign-demo ”，并将其分配给项目“cosign”
4. 在第二个实例上创建项目“cosign”
5. 在第二个实例上创建机器人帐户[7]“robot$cosign”
保存机器人账号的认证凭证，将在配置远程复制的时候使用：
6. 在第一个 Harbor 实例上设置复制[8]
设置新的目标 Harbor 实例：
设置从 Harbor1->Harbor2 的复制规则：
7. 创建 cosign 密钥对
为了能够执行以下步骤，需要安装“cosign”。见安装说明[9]。
$ cosign generate-key-pair
Enter password for private key:
Enter again:
Private key written to cosign.key
Public key written to cosign.pub
你可以导出密钥的密码（ 也称为 pass-phrase ），以便在自动化中使用：
export COSIGN_PASSWORD=Your_Super_P1$$w0rD
- 镜像推送和签名
使用你的 cosign-demo 用户登录第一个 Harbor 实例。
$ docker login harbor1.orlix.org
Authenticating with existing credentials...
Login Succeeded
然后将镜像推送到你已经设置好的 cosign 项目，下面的例子使用了镜像 pause:1。
$ docker push harbor1.orlix.org/cosign/pause:1
The push refers to repository [harbor1.orlix.org/cosign/pause]
5f70bf18a086: Layer already exists
e16a89738269: Layer already exists
1: digest: sha256:b31bfb4d0213f254d361e0079deaaebefa4f82ba7aa76ef82e90b4935ad5b105 size: 938
一旦我们在Harbor中有了可用的镜像，我们就可以用 cosign 来做镜像签名。
$ cosign sign --key cosign.key harbor1.orlix.org/cosign/pause:1
Enter password for private key:
Pushing signature to: harbor1.orlix.org/cosign/pause
- 触发复制并验证结果
验证复制结果：
在 Harbor1 实例上触发复制规则 harbor1->harbor2 之后，我们可以看到该镜像在两个 Harbor 实例中都有 Cosign 签名，可通过运行命令 cosign verify 验证签名。
$ cosign verify --key cosign.pub harbor1.orlix.org/cosign/pause:1 | jq .
Verification for harbor1.orlix.org/cosign/pause:1 --
The following checks were performed on each of these signatures:
- The cosign claims were validated
- The signatures were verified against the specified public key
[
{
"critical": {
"identity": {
"docker-reference": "harbor1.orlix.org/cosign/pause"
},
"image": {
"docker-manifest-digest": "sha256:b31bfb4d0213f254d361e0079deaaebefa4f82ba7aa76ef82e90b4935ad5b105"
},
"type": "cosign container image signature"
},
"optional": null
}
]
$ cosign verify --key cosign.pub harbor2.orlix.org/cosign/pause:1 | jq .
Verification for harbor2.orlix.org/cosign/pause:1 --
The following checks were performed on each of these signatures:
- The cosign claims were validated
- The signatures were verified against the specified public key
[
{
"critical": {
"identity": {
"docker-reference": "harbor1.orlix.org/cosign/pause"
},
"image": {
"docker-manifest-digest": "sha256:b31bfb4d0213f254d361e0079deaaebefa4f82ba7aa76ef82e90b4935ad5b105"
},
"type": "cosign container image signature"
},
"optional": null
}
验证返回结果和退出代码为零，表明签名有效！摘要（digest）值也相同！这样，Cosign 功能配置成功了!
总结
Harbor系统平台不支持镜像文件自动清理，在平台上删除一些镜像却只是删除了镜像的软链接，需要人工用命令去后台清理镜像。