List the application to non-platform repository

Using the violet tool, you can list three types of applications on the platform: operators, charts, and cluster plugins. By default, the artifacts (images, charts, etc.) included in the applications will be pushed to the image repository used by the deployment platform for management. However, if you do not wish to push these artifacts to the image repository used by the deployment platform, you will need to follow special configurations based on the following scenarios to complete the listing of your applications.

Scenario 1

Scenario Description

The image repository used by the deployment platform (Global cluster) differs from the one utilized by the business applications. The artifacts (images, charts, etc.) for the applications to be deployed have already been pushed to the image repository used by the business applications, and the user desires to manage these artifacts within the same image repository used by the business applications.

• Example: The deployment platform uses the “platform default” image repository, while the business applications utilize Harbor, deployed through the operator hub, for managing images and other artifacts. The user prefers to continue managing the business application artifacts using this Harbor instance.

Operations

Since all application artifacts (images, charts, etc.) are already stored in this image repository, there’s no need for additional image export or import processes.

1. Following the usage guidelines of the violet tool, specify the --skip-package-images parameter during packaging initialization. This ensures that violet does not export images when executing the package operation, producing an application package without images.

2. Subsequently, use the violet push command with the --skip-push parameter to upload the application package without images to the container platform.

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

  # Assuming the images for the percona-server-mongodb-operator package are already stored in the image repository at 10.10.1.1:11443
  # The --username and --password parameters represent the credentials to access this image repository
  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>
  
  # Alternatively, if the specified image repository does not require username or password authentication, use the --no-auth parameter. If HTTPS access is not necessary, specify the --plain parameter
  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

Notes

• Even if the --skip-package-images parameter is not specified during packaging initialization, it’s still possible to ignore pushing artifacts by specifying the --skip-push parameter during the violet push operation.

• When the uploaded application is deployed, the platform needs to know from which image repository to fetch the corresponding artifacts. Therefore, the --dest-repo parameter is specified during the violet push command to determine the address of the external image repository.

• During the upload process with the violet tool, necessary Kubernetes resources related to ModulePlugin, Artifact, and ArtifactVersion are automatically created.

Scenario 2

Scenario Description

The image repository used by the deployment platform (Global cluster) differs from the one utilized by the business applications. The artifacts (images, charts, etc.) for the applications to be deployed have not been pushed to the image repository used by the business applications and are instead stored in another image repository. The user desires to manage these application artifacts within the image repository used by the business applications.

• Example: There are two separate platforms, each with their own set of image repositories for business applications. An application is developed on “Platform A” with artifacts stored in “Business Application Image Repository A.” After testing, the application is intended to be deployed on “Platform B,” and the user wishes to manage the artifacts in “Business Application Image Repository B.”

Operations

1. Use the violet push command with the --dest-repo parameter to import the images from the application package, including container images and OCI artifacts, into the connected external image repository.

• violet push --dest-repo

  # Push all images related to the percona-server-mongodb-operator package to the image repository at 10.10.1.1:11443
  # The --username and --password parameters represent the credentials to access this image repository
  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>
  
  # Alternatively, if the specified image repository does not require username or password authentication, specify the --no-auth parameter. If HTTPS access is not necessary, specify the --plain parameter
  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

Notes

• During the upload process with the violet tool, necessary Kubernetes resources related to ModulePlugin, Artifact, and ArtifactVersion are automatically created.

2. Adding Image Replacement Whitelist

After an application is onboarded, when deploying the corresponding operator, the pod needs to pull images from the connected external image repository address. Therefore, it is necessary to configure an additional image replacement whitelist. The image replacement whitelist feature ensures that when an application is deployed and started, the pod uses the correct image repository address to ensure that the container can pull the image.

For instance, when developing an operator, chart, or cluster plugin, a fixed image address may be used in the deployment source code. However, when this application package is onboarded to a private container platform and container images need to be pulled from a different image repository, the image replacement whitelist feature is required.

By creating an Imagewhitelist resource, you can add one or more entries to the image replacement whitelist. Each Imagewhitelist custom resource (CR) can contain one or more images to be replaced.

• 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

Parameter Explanation:

• metadata.name - elasticsearch is the name of the CR, ensuring it does not conflict with other CR names and is easily identifiable.

• metadata.namespace - cpaas-system is the namespace where the CR resides. In theory, any namespace can be used, but the platform’s built-in Imagewhitelist CRs are typically under the cpaas-system namespace.

• spec.repoList - The image list, indicating that 3rdparty/elasticsearch/elasticsearch:v3.14.4 and 3rdparty/kibana/kibana:v3.14.4 are recorded in the whitelist. When pods start using these images, the image address harbor.demo.io will be automatically replaced.

• spec.rewriteRules - Describes the rules for replacing a certain image address. The example shows that when pods start using the above two images, the harbor.demo.io address will be automatically replaced with 10.10.1.1:11443.

Notes

• By default, when an operator is onboarded, the platform will automatically identify the relevant images contained in the operator and write these image addresses to the image replacement whitelist. When the operator is deployed, the platform components will automatically replace the image address used by the pod’s startup container with the image repository address used during the deployment of the platform.

Scenario 3

Scenario Description

The image repository used by the deployment platform (Global cluster) is the same as the one used by the business applications.

• Example: When setting up the deployment platform, the project’s “private repository” is selected, and the same “private repository” is also used for business applications.

Operations

All application artifacts (images, charts, etc.) are already stored in this image repository, so there is no need for additional export or import of artifacts.

1. Follow the violet tool usage guidelines and specify the --skip-package-images parameter during packaging initialization. This will prevent violet from exporting images during the packaging process, resulting in an application package without images.

2. Then, use the violet push command with the --skip-push parameter to upload the application package without images to the container platform.

• violet push --skip-push

  # The images for the percona-server-mongodb-operator application package are already stored in the Global registry's image repository
  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

Notes

• Even if the --skip-package-images parameter is not specified during packaging initialization, specifying --skip-push during violet push is still supported to ignore pushing artifacts.

• During the upload process with the violet tool, necessary Kubernetes resources related to ModulePlugin, Artifact, and ArtifactVersion are automatically created.