Private Image Sharing
Overview
The image sharing feature enables users to share their personal images with others. These shared images can be viewed and downloaded by other users.
Create Image Share
1. Access the Cloud Container Repository console.
2. Click on the name of the activated Enterprise Edition instance.
3. In the left navigation pane, click Distribution Management - Image Share, then under the Share to Others tab and click Create Image Share.
4. Input the target user for sharing on the creation page. The username here is the one the target user uses for docker login. Select the namespace, image repository, expiration date, and provide a description, then click Confirm to complete the creation.
5. After creation, you can view the record of image sharing created on the list.
6. The Edit button in the operation bar is used to modify the expiration date and description of the image sharing record. The Enable/Disable button is used to change the enabled status of the image sharing record. The Delete button is used to remove image sharing records.
Viewing Shared Images From Others
1. Access the Cloud Container Repository console.
2. Click on the name of the activated Enterprise Edition instance.
3. In the left navigation pane, select Distribution Management - Image Share and click the Shared by Others tab to view the list of images others have shared with you.
4. By clicking on the repository name of the shared image, you can view the operation guide for pulling the image as well as the image edition. Users cannot push images shared by others.
Cross-Namespace Sync Within the Same Instance
Within a single instance, different development teams may be confined to their own namespaces. When certain images need to be shared across namespaces, sync rules can be configured to achieve cross-namespace sync within the same instance. This section introduces how to manually and automatically sync images across namespaces within a single instance.
Before You Begin
Ensure that the instance you are using for image sync, either automatically or manually, is the Enterprise Edition. The Personal Edition does not support this function.
Auto Image Sync
By configuring automatic sync rules, images uploaded to the source repository that meet the conditions in the source namespace can be automatically synced to the target namespace.
Please note: The automatic sync will only synchronize images that meet the conditions after the rules are set. For images that already existed before the rules were set, automatic sync cannot be achieved.
The steps to set up automatic image sync rules are as follows:
1. Log in to the Container Image Console;
2. On the top menu bar, select the resource pool required.
3. Choose the instance you need to synchronize in the instance page.
4. On the left menu of the Enterprise Edition Instance Management page, select " Distribution Management " > " Image Synchronization ". Choose the " Auto Sync Rules " tab, and click " Create Rule " in the top left corner;
5. In the " Create Rule " dialog box, configure the sync rules and then click " Confirm " to create the rules. The descriptions of the configuration parameters are as follows:
Please note: For the automatic sync rule setting across namespaces within the same instance, the target namespace cannot be used as the target namespace or the source namespace in other rules. For example, if " proj1 " and " proj2 " are set as the source namespace and target namespace for rule 1 respectively, in subsequent rule settings, " proj1 " can still be set as the source namespace but cannot be set as the target namespace. Meanwhile, " proj2 " cannot be set as either the source or target namespace.
Parameter | Description |
Name | Customizing Names of Sync Rules |
Description | Customize additional descriptions, notes, and other information for sync rules |
Synchronization Content | For the content to sync, you can choose " Image " or Chart |
Source Instance | Fix as the current instance |
Source Namespace | Select the namespace in the source instance. This setting is required |
Source Repository | Select the image repository under the source namespace. This can be left blank. If you leave it blank, all image repositories under the namespace are included |
Source Version | Select the image edition to be synced. This can be left blank. If you leave it blank, all editions of the image will be synced |
Target Instance | Select the region and the name of the target instance. Since it's a cross-namespace synchronization within the same instance, you should choose the current instance |
Target Namespace | Select the namespace to be synced to |
Overwrite | Whether to overwrite when encountering an image of the same edition in the same image repository. You can choose yes or no |
When a new container image is pushed to a repository that meets the above rules, a sync task will be triggered automatically.
Select " Distribution Management " > " Image Synchronization " from the left menu on the Enterprise Edition instance management page. Choose the " Auto Sync Rules " tab and click the corresponding sync rule. You can view the task execution status at the bottom of the rule details page.
Manual Image Sync
By creating a manual sync task, you can manually sync images from the source namespace to the target namespace.
1. Log in to the Container Image Console;
2. On the top menu bar, select the resource pool required.
3. Choose the instance you need to synchronize in the instance page.
4. In the Enterprise Edition Instance Management page, select " Distribution Management " > " Image Sync " from the left menu. Then, select the " Manual Sync Records " tab and click " Create Sync Task " at the top left corner.
5. In the " Create Sync Task " dialog box, configure the sync task and then click " Confirm " to create the task;
6. Once the task is created, you can view the task execution status in the " Manual Sync Record " tab.
Cross-instance Sync Under the Same Account
By configuring sync rules, you can synchronize container images from the source instance to the target instance under the same account. If the target instance and the source instance are located in different resource pools, you can achieve cross-resource pool image synchronization. This section explains how to manually and automatically synchronize instances within the same account.
Before You Begin
Ensure that the instance you are using for image sync, either automatically or manually, is the Enterprise Edition. The Personal Edition does not support this function.
Auto Image Sync
By configuring automatic sync rules, images uploaded to the source repository that meet the conditions in the source instance can be automatically synced to any resource pool under the same account in the target instance.
Please note: The automatic sync will only synchronize images that meet the conditions after the rules are set. For images that already existed before the rules were set, automatic sync cannot be achieved.
The steps to set up automatic image sync rules are as follows:
1. Log in to the Container Image Console;
2. On the top menu bar, select the resource pool required.
3. Choose the instance you need to synchronize in the instance page.
4. On the left menu of the Enterprise Edition instance management page, select " Distribution Management " > " Image Synchronization", select the " Auto Sync Rules " tab, and click " Create Rule " in the upper left corner.
5. In the " Create Rule " dialog box, configure the sync rules and then click " Confirm " to create the rules. The descriptions of the configuration parameters are as follows:
Please note: For auto sync rules set across instances, the target instance and namespace cannot be set as the target instance and namespace or as the source instance and namespace of other rules. For example, if you currently have "ins1" as the instance and "proj1" as the namespace for the source of rule 1, and "ins2" and "proj2" as the instance and namespace respectively for the target of rule 1, in subsequent rule settings, "inst1-proj1" can still be set as the source but cannot be set as the target. Meanwhile, "ins2-proj2" cannot be set as either the source or target.
Parameter | Description |
Name | Customizing Names of Sync Rules |
Description | Customize additional descriptions, notes, and other information for sync rules |
Synchronization Content | For the content to sync, you can choose " Image " or Chart |
Source Instance | Fix as the current instance |
Source Namespace | Select the namespace in the source instance. This setting is required |
Source Repository | Select the image repository under the source namespace. This can be left blank. If you leave it blank, all image repositories under the namespace are included |
Source Version | Select the image edition to be synced. This can be left blank. If you leave it blank, all editions of the image will be synced |
Target Instance | Select the region and the name of the target instance. Since it's a cross-namespace synchronization within the same instance, you should choose the current instance |
Target Namespace | Select the namespace to be synced to |
Overwrite | Whether to overwrite when encountering an image of the same edition in the same image repository. You can choose yes or no |
When a new container image is pushed to a repository that meets the above rules, a sync task will be triggered automatically.
Select " Distribution Management " > " Image Synchronization " from the left menu on the Enterprise Edition instance management page. Choose the " Auto Sync Rules " tab and click the corresponding sync rule. You can view the task execution status at the bottom of the rule details page.
Manual Image Sync
By creating a manual sync task, you can manually synchronize images from the source instance to the target instance.
1. Log in to the Container Image Console;
2. On the top menu bar, select the resource pool required.
3. Choose the instance you need to synchronize in the instance page.
4. In the Enterprise Edition Instance Management page, select " Distribution Management " > " Image Sync " from the left menu. Then, select the " Manual Sync Records " tab and click " Create Sync Task " at the top left corner.
5. In the " Create Sync Task " dialog box, configure the synchronization task and click " Confirm " to create the task.
Once the task is created, you can view the task execution status in the " Manual Sync Record " tab.
On-Demand Container Image Loading
Traditional container operations require the complete download and decompression of full image data. However, a container start-up may only use a portion of the content, resulting in lengthy start-up time. By using the on-demand loading feature of the Cloud Container Repository Enterprise Edition, you can use accelerated image editions during business deployment. This enables image data to be exempt from full downloads and online decompression, greatly improving application distribution efficiency and providing an exceptional elasticity experience. This section explains how to load container images on demand.
Before You Begin
• The Enterprise Edition image management service has been activated.
• Activated CCSE, ECI, or CCSEOne clusters.
Background
With the on-demand acceleration feature, you can use accelerated images when deploying business workloads. This allows for image data to be used without the need for full downloading and online decompression, significantly improving the efficiency of application distribution and shortening container startup time, while also reducing the storage space consumed by container images. The acceleration effect is dependent on factors such as image size and network conditions.
Limitations
When creating a CCSE instance, clusters that use Containerd as the container runtime support the use of image acceleration. However, instances that use Docker as the runtime do not support this feature.
Converting Accelerated Images
By enabling automatic conversion of accelerated images at the image repository or namespace level, images will be automatically converted to accelerated images after upload. The time required to convert an image is dependent on the size of the image. No modifications are made to the original image during this process.
Note: After conversion, the accelerated image remains consistent with the namespace and repository of the original image. Only the image edition ( i.e., the Tag of the image ) will have an additional "accelerated" suffix compared to the original image.
Attention: If automatic image acceleration conversion in existing namespaces or image repositories is enabled, existing images within the overlapped namespaces or image repositories will not be automatically converted.
1. Log in to the Container Image Console;
2. On the top menu bar, select the resource pool required.
3. In the instance page, select the specified Enterprise Edition instance
4. Enable image acceleration in namespaces:
1. On the left menu of the Enterprise Edition instance management page, select "Container Image" > "Namespace".
2. When creating a namespace, turn on the " Enable Image Acceleration " switch, fill in the rest of the information, and then click the " Create " button;
3. For existing namespaces, turn on the switch in the " Enable Image Acceleration " column of the namespace list;
5. To enable image acceleration in the image repository:
1. In the Enterprise Edition instance management page, select " Container Images " > " Image Repository " from the left menu;
2. When creating an image repository under a namespace where image acceleration has not been enabled, turn on the " Enable Image Acceleration " switch, and click " Create " after filling in the remaining information;
3. For existing image repositories, select the image repository under a namespace where image acceleration has not been enabled from the image repository list. Click " Edit ", turn on the " Enable Image Acceleration " switch on the edit page, then click the " Update " button.
Upload images to the namespace or image repository where image acceleration has been enabled. After a short while, you can view the accelerated image with the "accelerated" suffix in the edition list page of the image repository. The conversion time depends on the size of the image.
Using Accelerated Images
When creating workloads, or replacing images for existing workloads, select an image from the "Whether to accelerate images or not" column marked as "Yes" in the image edition selection box. Click OK to use the accelerated image.
Performance Testing
Now, select five images: busybox, centos, openjdk, and tensorflow. Conduct performance testing by pulling these images, creating containers, and executing the pwd command. Then, observe the time consumed by these operations.
Upon review of the data, we can see that "accelerated" performs slightly less efficiently than "oci" with smaller images. However, as the image size grows, the benefits of "accelerated" become increasingly clear. This is especially noticeable during image pulling, container creation, and container startup.
1. When pulling an image, "accelerated" only needs to pull a small amount of content such as the mainifest and config of the image. However, "oci" images require the full pull of all layers of the image in addition to the above data. The time difference between the two is directly proportional to the size of the image.
2. When creating a container, "accelerated" generally takes slightly longer, but the difference is within 300 milliseconds.
3. When a container is run, "accelerated" pulls the required image data blocks from the image repository as needed, while "oci" loads the layers directly from the disk into the file system. "oci" has an advantage when dealing with smaller images. As the image size grows, the time taken by "accelerated" does not increase significantly, but the time taken by "oci" scales with the image size.
4. However, in actual operation, a container is usually run directly. After pulling an image, there is no need to separately create and start a container. The creation and operation are often " done in one go ", Therefore, the time is usually controlled within about 200 milliseconds for oci and within 2 seconds for "accelerated".
In summary, for an image with a pull time around one to two seconds, it typically runs faster with oci than with accelerated. As the image size increases and the image pull time rises, the advantage of on-demand loading will become evident.
P2P Image Acceleration Distribution
Overview
The P2P image acceleration feature leverages the bandwidth resources of cluster nodes for image distribution, reducing the pressure on the Cloud Container Repository. This can significantly increase the speed of image pulling and reduce app deployment time.
Before You Begin
• Install the cube-p2p-acceleration plug-in
• The cluster uses containerd as the container runtime, and the containerd version is 1.6 or higher.
• A Cloud Container Repository Enterprise Edition instance has been created.
Usage Steps
Install Plug-in
There are currently two ways to install the cube-p2p-acceleration plug-in:
1. ( Recommended ): Log in to the CCSE console. From the Plug-ins - Plug-in Market, install the cube-p2p-acceleration plug-in
2. You can deploy using helm with this command: helm install RELEASE_NAME --set key=value https://registry-vpc-crs-huadong1.ctyun.cn/plugins/cube-p2p-acceleration:1.0.0 --namespace kube-system
Configuration Parameters
The crsRegistries parameter configures the Intranet instance addresses of the Cloud Container Repository used by the user. Multiple addresses can be configured, but note that the HTTPS protocol must be specified.
Please note that the example should be modified to the actual instance address. If the instance address is not configured correctly, the P2P acceleration plug-in cannot accelerate the corresponding image pulling process.
crsRegistries: - "https://registry-vpc-crs-huadong1.ctyun.cn" - "https://xxx-registry-vpc-huadong1.crs.ctyun.cn"
The persistence parameter configures data storage.
persistence.nodeNames specifies the names of several nodes in the cluster for local data storage. It is recommended to set 5 nodes.
persistence.directoryPath specifies the local data storage directory path on each node. Each node directory should have no less than 8G of space.
Note, the example needs to be modified to the actual node names; otherwise, the plug-in installation may fail.
If the specified node encounters a fault, it will affect the functionality of the P2P acceleration plug-in.
persistence: nodeNames: - "ccse-nodename1" - "ccse-nodename2" - "ccse-nodename3" - "ccse-nodename4" - "ccse-nodename5" directoryPath: /p2p-data
By default, the P2P acceleration plug-in will use ports 65001 and 40901 on each node for request proxy and health checks.
The corresponding ports can be modified through the proxyPort and healthCheckPort parameters.
#### proxyPort proxyPort: 65001 #### healthCheckPort healthCheckPort: 40901
Acceleration Verification
Once the P2P acceleration plug-in is installed, workloads in the cluster will automatically use acceleration when pulling images from the corresponding container image repository. After a workload successfully pulls an image,
you can log into the container group named "cube-p2p-acceleration-dfdaemon" within the corresponding node and use the following command to view the logs:
grep "peer task done" /var/log/dragonfly/daemon/core.log
If you see logs similar to the following, it indicates that the image pull was successfully accelerated by the P2P plug-in:
{
"level":"info",
"ts":"2023-04-10 07:31:02.897",
"caller":"peer/peertask_conductor.go:1330",
"msg":"peer task done, cost: 6483ms",
"peer":"10.244.0.5-1-be485ea5-6d54-4f56-8f56-bdbe76ec8469",
"task":"0fe34e3fcb64d49b09fe7c759f47a373b7590fe4dbe1da6d9c732eee516e4cb4",
"component":"PeerTask",
"trace":"daa2ffd1021779dfbd3162ead765e0ba"
}Otherwise, you need to check whether the address of the Cloud Container Repository instance was entered correctly during plug-in installation, and then reinstall the plug-in.
Unmount
It is recommended to uninstall this plug-in through the CCSE Plug-in console. If you need to uninstall this app through Helm, please refer to the following commands:
$ helm uninstall RELEASE_NAME --namespace kube-system
After uninstalling the P2P acceleration plug-in, the related services will be automatically deleted. In addition, you will also need to delete the following persistent volume claims and persistent volumes left by the plug-in, either through the console or manually:
#### 5 Persistent Volume Claims data-cube-p2p-acceleration-mysql-0 redis-data-cube-p2p-acceleration-redis-master-0 redis-data-cube-p2p-acceleration-redis-replicas-0 redis-data-cube-p2p-acceleration-redis-replicas-1 redis-data-cube-p2p-acceleration-redis-replicas-2 #### 5 Persistent Volumes p2p-local-pv-0 p2p-local-pv-1 p2p-local-pv-2 p2p-local-pv-3 p2p-local-pv-4
Failure to delete these can affect the reinstallation of the plug-in..