应用上架到非平台仓库

通过 violet 工具，您可以向平台上架 operator、chart、集群插件三种类型的应用，且默认情况下会将应用中携带的物料（镜像、chart 等）推送到部署平台时使用的镜像仓库中管理。当您不希望将物料推送到部署平台时使用的镜像仓库中管理时，您需要跟据以下几种场景，通过一些特殊配置才能完成应用的上架。

场景1

场景描述

部署平台（Global集群）使用的镜像仓库和业务应用使用的镜像仓库不同，待上架应用的物料（镜像、chart 等）已经推送到业务应用使用的镜像仓库，且用户希望将应用的物料在业务应用使用的镜像仓库中管理。

• 场景举例：部署平台时使用了“平台默认”的镜像仓库，业务应用使用 operator hub 中部署的 harbor 管理镜像等物料，且用户希望使用该 harbor 继续管理业务应用的物料

操作

所有的应用物料（镜像、chart 等）已经存放在这个镜像仓库中，因此不需要额外再对镜像导出、导入。

1. 参考 violet 工具的使用规范，打包初始化时指定 --skip-package-images 参数，violet 在执行 package 时将不会导出镜像，制作出不带镜像的应用包。

2. 然后通过 violet push 命令，指定 --skip-push 参数，将不带镜像的应用包上架到容器平台中。

• violet push --skip-push --dest-repo

   # percona-server-mongodb-operator 应用包的镜像已经存放在地址为 10.10.1.1:11443 的镜像仓库中
   # 参数 --username 和 --password 分别表示访问该镜像仓库的用户名和密码
  violet push percona-server-mongodb-operator.v3.18.0-beta.2.g361a8da2.tgz --platform-address https://192.168.0.1 --platform-username <user> --platform-password <password> --skip-push --dest-repo 10.10.1.1:11443 --username <user> --password <password>
  
    # 或者当指定的镜像仓库不需要用户名、密码认证时，则需要指定 --no-auth 参数，不需要 https 访问时，则需要指定 --plain 参数
  violet push percona-server-mongodb-operator.v3.18.0-beta.2.g361a8da2.tgz --platform-address https://192.168.0.1 --platform-username <user> --platform-password <password> --skip-push --dest-repo 10.10.1.1:11443 --no-auth --plain

说明

• 即使打包初始化时未指定 --skip-package-images 参数，也支持执行 violet push 时指定 --skip-push 参数忽略推送制品。

• 上架后的应用在被部署时，平台需要知道从哪个镜像仓库获取对应的物料，所以在执行 violet push 命令时指定 --dest-repo 参数来确定对接的外部镜像仓库地址。

• 通过 violet 工具上架过程中，会自动创建必要的 ModulePlugin、Artifact、Artifactversion 相关 Kubernetes 资源。

场景2

场景描述

部署平台（Global集群）使用的镜像仓库和业务应用使用的镜像仓库不同，待上架应用的物料（镜像、chart等）未推送到业务应用使用的镜像仓库，保存在其他镜像仓库中，且用户希望将应用的物料在业务应用使用的镜像仓库中管理。

• 场景举例：有两套独立的平台，且两套独立平台拥有两套不同的业务应用使用的镜像仓库，在“平台A”中开发应用，物料保存在“业务应用镜像仓库A”中，测试完成后，将应用上架到“平台B”中使用，且用户希望将物料在“业务应用镜像仓库B”中管理

操作

1. 将携带容器镜像和 oci 制品的应用包，通过 violet push 命令指定 –dest-repo 参数将应用包中的镜像导入到对接的外部镜像仓库中。

• violet push --dest-repo

   # 将 percona-server-mongodb-operator 包的相关镜像都推送到地址为 10.10.1.1:11443 的镜像仓库中
   # 参数 --username 和 --password 分别表示访问该镜像仓库的用户名和密码
  violet push percona-server-mongodb-operator.v3.18.0-beta.2.g361a8da2.tgz --platform-address https://192.168.0.1 --platform-username <user> --platform-password <password> --dest-repo 10.10.1.1:11443 --username <user> --password <password>
  
   # 或者当指定的镜像仓库不需要用户名、密码认证时，则需要指定 --no-auth 参数，不需要 https 访问时，则需要指定 --plain 参数
  violet push percona-server-mongodb-operator.v3.18.0-beta.2.g361a8da2.tgz --platform-address https://192.168.0.1 --platform-username <user> --platform-password <password> --dest-repo 10.10.1.1:11443 --no-auth --plain

说明

• 通过 violet 工具上架过程中，会自动创建必要的 ModulePlugin、Artifact、Artifactversion 相关 Kubernetes 资源。

2. 添加镜像替换白名单

应用上架后，部署相应的 operator 时，需要 pod 通过对接的外部镜像仓库地址拉取镜像，因此还需要额外配置镜像替换白名单。镜像替换白名单功能能够保证某个应用在部署启动时，Pod 使用正确的镜像仓库地址，以确保容器能够拉取到镜像。

比如，开发某个 operator、chart 还是集群插件时，在源码中 deployment 使用了固定的镜像地址，但是当把该应用包上架到某个私有容器平台，需要通过其他镜像仓库拉取容器镜像时，就需要使用镜像替换白名单的功能。

通过创建 Imagewhitelist 资源，就可以增加一条或者多条镜像替换白名单，可以在一个 Imagewhitelist cr 中增加一条或多条待替换的镜像名单。

• imagewhitelist.yaml

  cat <<EOF | kubectl create -f -
  apiVersion: app.alauda.io/v1alpha1
  kind: ImageWhiteList
  metadata:
    name: elasticsearch
    namespace: cpaas-system
  spec:
    repoList:
      - harbor.demo.io/3rdparty/elasticsearch/elasticsearch:v3.14.4
      - harbor.demo.io/3rdparty/kibana/kibana:v3.14.4
    rewriteRules:
      - regexp: harbor.demo.io/3rdparty/elasticsearch/elasticsearch:(.*)
        replacement: 10.10.1.1:11443/3rdparty/elasticsearch/elasticsearch:${1}
      - regexp: harbor.demo.io/3rdparty/kibana/kibana:(.*)
        replacement: 10.10.1.1:11443/3rdparty/kibana/kibana:${1}
  EOF

参数说明：

• metadata.name elasticsearch 是 cr 的名称，确保不与其他 cr 名称冲突并且容易识别即可

• metadata.namespace cpaas-system 是 cr 所在的命名空间，理论上任意命名空间都可以，平台内置的 Imagewhitelist cr 都在 cpaas-system ns 下

• spec.repoList 是镜像列表，例子中表示 3rdparty/elasticsearch/elasticsearch:v3.14.4 和 3rdparty/kibana/kibana:v3.14.4 这两个镜像被记录到白名单，一旦 Pod 启动使用这两个镜像时，会自动对镜像地址 harbor.demo.io 进行替换

• spec.rewriteRules 是描述将某个镜像地址替换规则，例子中表示 Pod 启动时使用了上述两个镜像时，会自动将 harbor.demo.io 地址替换为 10.10.1.1:11443

说明

• 默认情况下，当 operator 上架时，会自动识别 operator 中包含的相关镜像，并将这些镜像地址写入镜像替换白名单，operator 部署时平台组件会自动将 Pod 启动容器的镜像地址替换为部署平台时使用的镜像仓库地址。

场景3

场景描述

部署平台（Global集群）使用的镜像仓库和业务应用使用的镜像仓库为同一个镜像仓库。

• 场景举例：部署平台时选择使用项目的“私有仓库”，业务应用也使用相同的“私有仓库”

操作

所有的应用物料（镜像、chart 等）已经存放在这个镜像仓库中，因此不需要额外再对物料导出、导入。

1. 参考 violet 工具的使用规范，打包初始化时指定 --skip-package-images 参数，violet 在执行 package 时将不会导出镜像，制作出不带镜像的应用包。

2. 然后通过 violet push 命令，指定 --skip-push 参数，将不带镜像的应用包上架到容器平台中。

• violet push --skip-push

   # percona-server-mongodb-operator 应用包的镜像已经存放在 Global registry 的镜像仓库中
  violet push percona-server-mongodb-operator.v3.18.0-beta.2.g361a8da2.tgz --platform-address https://192.168.0.1 --platform-username <user> --platform-password <password> --skip-push

说明

• 即使打包初始化时未指定 --skip-package-images 参数，也支持执行 violet push 时指定 --skip-push 参数忽略推送制品.

• 通过 violet 工具上架过程中，会自动创建必要的 ModulePlugin、Artifact、Artifactversion 相关 Kubernetes 资源。