Compare commits
1 Commits
main
...
propose-sw
Author | SHA1 | Date | |
---|---|---|---|
9e49daead1 |
After Width: | Height: | Size: 9.6 KiB |
After Width: | Height: | Size: 9.4 KiB |
After Width: | Height: | Size: 49 KiB |
After Width: | Height: | Size: 12 KiB |
After Width: | Height: | Size: 17 KiB |
After Width: | Height: | Size: 12 KiB |
After Width: | Height: | Size: 23 KiB |
After Width: | Height: | Size: 6.4 KiB |
After Width: | Height: | Size: 24 KiB |
After Width: | Height: | Size: 14 KiB |
After Width: | Height: | Size: 8.9 KiB |
After Width: | Height: | Size: 24 KiB |
After Width: | Height: | Size: 35 KiB |
After Width: | Height: | Size: 361 B |
After Width: | Height: | Size: 439 B |
After Width: | Height: | Size: 17 KiB |
After Width: | Height: | Size: 65 KiB |
After Width: | Height: | Size: 131 B |
After Width: | Height: | Size: 277 B |
After Width: | Height: | Size: 14 KiB |
After Width: | Height: | Size: 16 KiB |
After Width: | Height: | Size: 18 KiB |
After Width: | Height: | Size: 277 B |
After Width: | Height: | Size: 17 KiB |
After Width: | Height: | Size: 11 KiB |
After Width: | Height: | Size: 218 B |
After Width: | Height: | Size: 179 KiB |
After Width: | Height: | Size: 51 KiB |
After Width: | Height: | Size: 59 KiB |
After Width: | Height: | Size: 59 KiB |
After Width: | Height: | Size: 48 KiB |
After Width: | Height: | Size: 51 KiB |
134
doc/best-practice/source/basics_of_the_container_engine.rst
Normal file
14
doc/best-practice/source/best_practices/index.rst
Normal file
@ -0,0 +1,14 @@
|
||||
:original_name: swr_bp_index.html
|
||||
|
||||
.. _swr_bp_index:
|
||||
|
||||
Best Practices
|
||||
==============
|
||||
|
||||
- :ref:`Migrating Container Images <swr_bestpractice_0016>`
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
:hidden:
|
||||
|
||||
migrating_container_images/index
|
@ -0,0 +1,18 @@
|
||||
:original_name: swr_bestpractice_0016.html
|
||||
|
||||
.. _swr_bestpractice_0016:
|
||||
|
||||
Migrating Container Images
|
||||
==========================
|
||||
|
||||
- :ref:`Migrating Images to SWR Using Docker Commands <swr_bestpractice_0012>`
|
||||
- :ref:`Migrating Images to SWR Using image-syncer <swr_bestpractice_0015>`
|
||||
- :ref:`Synchronizing Images Across Clouds from Harbor to SWR <swr_bestpractice_0004>`
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
:hidden:
|
||||
|
||||
migrating_images_to_swr_using_docker_commands
|
||||
migrating_images_to_swr_using_image-syncer
|
||||
synchronizing_images_across_clouds_from_harbor_to_swr
|
@ -0,0 +1,65 @@
|
||||
:original_name: swr_bestpractice_0012.html
|
||||
|
||||
.. _swr_bestpractice_0012:
|
||||
|
||||
Migrating Images to SWR Using Docker Commands
|
||||
=============================================
|
||||
|
||||
Scenarios
|
||||
---------
|
||||
|
||||
SWR provides easy-to-use image hosting and efficient distribution services. If small quantity of images need to be migrated, enterprises can use the **docker pull/push** command to migrate images to SWR.
|
||||
|
||||
Procedure
|
||||
---------
|
||||
|
||||
#. .. _swr_bestpractice_0012__en-us_topic_0000001281347382_en-us_topic_0000001262401516_li13905204219362:
|
||||
|
||||
Pull images from the source repository.
|
||||
|
||||
Run the **docker pull** command to pull the images.
|
||||
|
||||
Example: **docker pull nginx:latest**
|
||||
|
||||
Run the **docker images** command to check whether the images are successfully pulled.
|
||||
|
||||
.. code-block::
|
||||
|
||||
# docker images
|
||||
REPOSITORY TAG IMAGE ID CREATED SIZE
|
||||
nginx latest 22f2bf2e2b4f 5 hours ago 22.8MB
|
||||
|
||||
#. Push the images pulled in :ref:`1 <swr_bestpractice_0012__en-us_topic_0000001281347382_en-us_topic_0000001262401516_li13905204219362>` to SWR.
|
||||
|
||||
a. Log in to the VM where the target container is located and log in to SWR. For details, see .
|
||||
|
||||
b. Tag the images.
|
||||
|
||||
**docker tag** **[Image name:Tag name] [Image repository address]/[Organization name]/[Image name:Tag name]**
|
||||
|
||||
Example:
|
||||
|
||||
**docker tag nginx:v1 swr..myhuaweicloud.com/cloud-develop/nginx:v1**
|
||||
|
||||
c. Run the following command to push the images to the target image repository.
|
||||
|
||||
**docker push** **[Image repository address]/[Organization name]/[Image name:Tag name]**
|
||||
|
||||
Example:
|
||||
|
||||
**docker push swr..myhuaweicloud.com/cloud-develop/nginx:v1**
|
||||
|
||||
d. Check whether the following information is returned. If yes, the push is successful.
|
||||
|
||||
.. code-block::
|
||||
|
||||
fbce26647e70: Pushed
|
||||
fb04ab8effa8: Pushed
|
||||
8f736d52032f: Pushed
|
||||
009f1d338b57: Pushed
|
||||
678bbd796838: Pushed
|
||||
d1279c519351: Pushed
|
||||
f68ef921efae: Pushed
|
||||
v1: digest: sha256:0cdfc7910db531bfa7726de4c19ec556bc9190aad9bd3de93787e8bce3385f8d size: 1780
|
||||
|
||||
To view the pushed image, refresh the **My Images** page.
|
@ -0,0 +1,91 @@
|
||||
:original_name: swr_bestpractice_0015.html
|
||||
|
||||
.. _swr_bestpractice_0015:
|
||||
|
||||
Migrating Images to SWR Using image-syncer
|
||||
==========================================
|
||||
|
||||
Scenarios
|
||||
---------
|
||||
|
||||
If small quantity of images need to be migrated, you can use Docker commands. However, for thousands of images and several TBs of image repository data, it takes a long time and even data may be lost. In this case, you can use the open-source image migration tool `image-syncer <https://github.com/AliyunContainerService/image-syncer>`__.
|
||||
|
||||
Procedure
|
||||
---------
|
||||
|
||||
#. Download, decompress, and run image-syncer.
|
||||
|
||||
The following uses image-syncer v1.3.1 as an example.
|
||||
|
||||
**wget https://github.com/AliyunContainerService/image-syncer/releases/download/v1.3.1/image-syncer-v1.3.1-linux-amd64.tar.gz**
|
||||
|
||||
**tar -zvxf image-syncer-v1.3.1-linux-amd64.tar.gz**
|
||||
|
||||
#. Create **auth.json**, the authentication information file of the image repositories.
|
||||
|
||||
image-syncer supports the Docker image repository based on Docker Registry V2. Enter the authentication information as required. In the following example, the image repository of is migrated to .
|
||||
|
||||
The following describes how to write the authentication information of the source and target repositories.
|
||||
|
||||
.. code-block::
|
||||
|
||||
{
|
||||
"swr..myhuaweicloud.com": {
|
||||
"username": "@F1I3Q......",
|
||||
"password": "2fd4c869ea0......"
|
||||
},
|
||||
"swr..myhuaweicloud.com": {
|
||||
"username": "@4N3FA......",
|
||||
"password": "f1c82b57855f9d35......"
|
||||
}
|
||||
}
|
||||
|
||||
In the preceding commands, **swr..myhuaweicloud.com** indicates the image repository address. You can obtain the username and password from the login command as follows:
|
||||
|
||||
Log in to the SWR console, and click **Generate Login Command** in the upper right corner to obtain the login command in the dialog box displayed, as shown in the following figure.
|
||||
|
||||
In ,
|
||||
|
||||
**swr..myhuaweicloud.com** is the image repository address.
|
||||
|
||||
.. caution::
|
||||
|
||||
For security, the example username and password are not complete. You should use the actual username and password obtained from the console.
|
||||
|
||||
#. Create **images.json**, the image synchronization description file.
|
||||
|
||||
In the following example, the source repository address is on the left, and the target repository address is on the right. image-syncer also supports other description modes. For details, see `README.md <https://github.com/AliyunContainerService/image-syncer/blob/master/README.md>`__.
|
||||
|
||||
.. code-block::
|
||||
|
||||
{
|
||||
"swr..myhuaweicloud.com/org-ss/canary-consumer": "swr..myhuaweicloud.com/dev-container/canary-consumer"
|
||||
}
|
||||
|
||||
#. Run the following command to migrate the images to SWR:
|
||||
|
||||
**./image-syncer --auth=./auth.json --images=./images.json --namespace=dev-container --registry=swr..myhuaweicloud.com --retries=3 --log=./log**
|
||||
|
||||
.. table:: **Table 1** Command parameter description
|
||||
|
||||
+-------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
|
||||
| Parameter | Description |
|
||||
+=============+=================================================================================================================================================================================================================================================================================+
|
||||
| --config | Sets the path of config file. This file needs to be created before starting synchronization. Default config file is at "current/working/directory/config.json". (This flag can be replaced with flag **--auth** and **--images** which for better organization.) |
|
||||
+-------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
|
||||
| --images | Sets the path of image rules file. This file needs to be created before starting synchronization. Default config file is at "current/working/directory/images.json". |
|
||||
+-------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
|
||||
| --auth | Sets the path of authentication file. This file needs to be created before starting synchronization. Default config file is at "current/working/directory/auth.json". |
|
||||
+-------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
|
||||
| --log | Sets the path of log file. Logs will be printed to Stderr by default. |
|
||||
+-------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
|
||||
| --namespace | Sets default-namespace. default-namespace can also be set by environment variable **DEFAULT_NAMESPACE**. If they are both set at the same time, **DEFAULT_NAMESPACE** will not work at this synchronization. default-namespace will work only if default-registry is not empty. |
|
||||
+-------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
|
||||
| --proc | Number of goroutines. Default value is 5. |
|
||||
+-------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
|
||||
| --retries | Number of retries. Default value is 2. The retries of failed sync tasks will start after all sync tasks are executed once. Reties of failed sync tasks will resolve most occasional network problems during synchronization. |
|
||||
+-------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
|
||||
| --registry | Sets default-registry. Default-registry can also be set by environment variable **DEFAULT_REGISTRY**. If they are both set at the same time, **DEFAULT_REGISTRY** will not work at this synchronization. default-registry will work only if default-namespace is not empty. |
|
||||
+-------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
|
||||
|
||||
After the migration command is executed, you can log in to the target image repository to view the migrated images.
|
25
doc/best-practice/source/change_history.rst
Normal file
@ -0,0 +1,25 @@
|
||||
:original_name: swr_change_index.html
|
||||
|
||||
.. _swr_change_index:
|
||||
|
||||
Change History
|
||||
==============
|
||||
|
||||
+-----------------------------------+-------------------------------------------------------------------------------------------------------+
|
||||
| Release Date | Description |
|
||||
+===================================+=======================================================================================================+
|
||||
| 2022-06-09 | Permission description is added in :ref:`User Permissions <swr_01_0015>`. |
|
||||
+-----------------------------------+-------------------------------------------------------------------------------------------------------+
|
||||
| 2021-08-30 | :ref:`Service Overview <swr_pd_index>`, :ref:`FAQs <swr_faq_index>` is added. |
|
||||
+-----------------------------------+-------------------------------------------------------------------------------------------------------+
|
||||
| 2020-06-18 | - Prerequisites in :ref:`Uploading an Image Through the Client <swr_01_0011>` are updated. |
|
||||
| | - Content related to organization deletion is added in :ref:`Organization Management <swr_01_0014>`. |
|
||||
+-----------------------------------+-------------------------------------------------------------------------------------------------------+
|
||||
| 2020-05-26 | Updated: |
|
||||
| | |
|
||||
| | - :ref:`Basics of the Container Engine <swr_01_0006>` |
|
||||
| | - :ref:`Uploading an Image Through the Client <swr_01_0011>` |
|
||||
| | - :ref:`User Permissions <swr_01_0015>` |
|
||||
+-----------------------------------+-------------------------------------------------------------------------------------------------------+
|
||||
| 2020-04-21 | This issue is the first official release. |
|
||||
+-----------------------------------+-------------------------------------------------------------------------------------------------------+
|
36
doc/best-practice/source/faqs/general_faqs/about_swr.rst
Normal file
@ -0,0 +1,36 @@
|
||||
:original_name: swr_faq_0013.html
|
||||
|
||||
.. _swr_faq_0013:
|
||||
|
||||
About SWR
|
||||
=========
|
||||
|
||||
How Many Images Can Be Stored in SWR?
|
||||
-------------------------------------
|
||||
|
||||
SWR has no limit on the number of images. You can upload any number of images.
|
||||
|
||||
What Is the Bandwidth of SWR?
|
||||
-----------------------------
|
||||
|
||||
The bandwidth of SWR dynamically changes based on actual usage.
|
||||
|
||||
Is SWR Charged?
|
||||
---------------
|
||||
|
||||
The billing items of SWR include storage space and traffic. Currently, it is free of charge.
|
||||
|
||||
Does SWR Support Querying the CPU Architecture (x86 or Arm) of an Image?
|
||||
------------------------------------------------------------------------
|
||||
|
||||
- For a public image, you can log in to the SWR console, go to the image center, search for the target image, and view its details, including the architectures supported by the image.
|
||||
|
||||
- For a private image, you can Run **docker inspect** **[Image name:Version name]** to query the image architecture.
|
||||
|
||||
*Example:* **docker inspect openjdk:7**\ *.*
|
||||
|
||||
|
||||
.. figure:: /_static/images/en-us_image_0000001539405909.png
|
||||
:alt: **Figure 1** Example
|
||||
|
||||
**Figure 1** Example
|
@ -0,0 +1,20 @@
|
||||
:original_name: en-us_topic_0000001539549873.html
|
||||
|
||||
.. _en-us_topic_0000001539549873:
|
||||
|
||||
Are There Quotas for SWR Resources?
|
||||
===================================
|
||||
|
||||
No quotas are imposed on SWR images. You can push as many images as you need.
|
||||
|
||||
Quotas are imposed on the number of organizations a user can create, as shown in :ref:`Table 1 <en-us_topic_0000001539549873__table88365720443>`.
|
||||
|
||||
.. _en-us_topic_0000001539549873__table88365720443:
|
||||
|
||||
.. table:: **Table 1** SWR resource quotas
|
||||
|
||||
============= =====
|
||||
Resource Type Quota
|
||||
============= =====
|
||||
Organization 5
|
||||
============= =====
|
@ -0,0 +1,31 @@
|
||||
:original_name: swr_faq_0004.html
|
||||
|
||||
.. _swr_faq_0004:
|
||||
|
||||
How Do I Create an Image Package?
|
||||
=================================
|
||||
|
||||
Run the **docker save** command to compress the container image into a .tar or .tar.gz package. The command format is as follows:
|
||||
|
||||
**docker save [OPTIONS] IMAGE [IMAGE...]**
|
||||
|
||||
**[OPTIONS]** can be set to **--output** or **-o**, indicating that the image is exported to a file.
|
||||
|
||||
Example:
|
||||
|
||||
.. code-block::
|
||||
|
||||
$ docker save nginx:latest > nginx.tar
|
||||
$ ls -sh nginx.tar
|
||||
108M nginx.tar
|
||||
|
||||
$ docker save php:5-apache > php.tar.gz
|
||||
$ ls -sh php.tar.gz
|
||||
372M php.tar.gz
|
||||
|
||||
$ docker save --output nginx.tar nginx
|
||||
$ ls -sh nginx.tar
|
||||
108M nginx.tar
|
||||
|
||||
$ docker save -o nginx-all.tar nginx
|
||||
$ docker save -o nginx-latest.tar nginx:latest
|
24
doc/best-practice/source/faqs/general_faqs/index.rst
Normal file
@ -0,0 +1,24 @@
|
||||
:original_name: swr_faq_1001.html
|
||||
|
||||
.. _swr_faq_1001:
|
||||
|
||||
General FAQs
|
||||
============
|
||||
|
||||
- :ref:`What Is SWR? <swr_faq_1011>`
|
||||
- :ref:`About SWR <swr_faq_0013>`
|
||||
- :ref:`How Do I Create a Container Image? <swr_faq_0012>`
|
||||
- :ref:`How Do I Create an Image Package? <swr_faq_0004>`
|
||||
- :ref:`Are There Quotas for SWR Resources? <en-us_topic_0000001539549873>`
|
||||
- :ref:`Why Does Organization Creation Fail? <en-us_topic_0000001488470084>`
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
:hidden:
|
||||
|
||||
what_is_swr
|
||||
about_swr
|
||||
how_do_i_create_a_container_image
|
||||
how_do_i_create_an_image_package
|
||||
are_there_quotas_for_swr_resources
|
||||
why_does_organization_creation_fail
|
@ -0,0 +1,8 @@
|
||||
:original_name: swr_faq_1011.html
|
||||
|
||||
.. _swr_faq_1011:
|
||||
|
||||
What Is SWR?
|
||||
============
|
||||
|
||||
SoftWare Repository for Container (SWR) allows users to easily manage the full lifecycle of container images and facilitates secure deployment of images for your applications.
|
@ -0,0 +1,12 @@
|
||||
:original_name: en-us_topic_0000001488470084.html
|
||||
|
||||
.. _en-us_topic_0000001488470084:
|
||||
|
||||
Why Does Organization Creation Fail?
|
||||
====================================
|
||||
|
||||
Symptom: The creation of an organization fails, and a message is displayed indicating that the organization already exists. However, the organization is not found on the **Organizations** page.
|
||||
|
||||
Solution: Change the organization name to one which is globally unique in the Region.
|
||||
|
||||
If a message is displayed indicating that the organization already exists, the organization name may have been used by another user. Use another organization name.
|
@ -0,0 +1,8 @@
|
||||
:original_name: swr_faq_1013.html
|
||||
|
||||
.. _swr_faq_1013:
|
||||
|
||||
How Many Tenants Can I Share an SWR Private Image with?
|
||||
=======================================================
|
||||
|
||||
500
|
@ -0,0 +1,48 @@
|
||||
:original_name: swr_faq_1012.html
|
||||
|
||||
.. _swr_faq_1012:
|
||||
|
||||
Image Push and Pull
|
||||
===================
|
||||
|
||||
How Do I Push an Image to SWR by Calling APIs?
|
||||
----------------------------------------------
|
||||
|
||||
Currently, SWR does not provide APIs for image push. You can push images using the **docker push** command on a client or using the SWR console.
|
||||
|
||||
How Do I Pull an Image from SWR by Calling APIs?
|
||||
------------------------------------------------
|
||||
|
||||
Currently, SWR does not provide APIs for image pull. You can pull images using the **docker pull** command on a client.
|
||||
|
||||
Can I Push Arm-based Container Images to SWR?
|
||||
---------------------------------------------
|
||||
|
||||
SWR has no restriction on the kernel architecture of images. There is no difference between pushing an Arm-based image and an x86-based image to SWR.
|
||||
|
||||
What Protocol Is Used to Push Images to SWR When I Run the **docker push** Command?
|
||||
-----------------------------------------------------------------------------------
|
||||
|
||||
HTTPS is used.
|
||||
|
||||
Will an Image Be Overwritten If I Push an Image That Have the Same Name and Tag with it?
|
||||
----------------------------------------------------------------------------------------
|
||||
|
||||
Yes, the original image will be overwritten.
|
||||
|
||||
Where Are the Images Pulled by Running the **docker pull** Command Stored?
|
||||
--------------------------------------------------------------------------
|
||||
|
||||
Images pulled by running the **docker pull** command are stored on your local hosts. You can run the **docker save** command to save images into TAR archive files.
|
||||
|
||||
What Is the Maximum Size of an SWR Layer?
|
||||
-----------------------------------------
|
||||
|
||||
If you use the container engine client to push images to SWR, each image layer cannot exceed 10 GB.
|
||||
|
||||
Can SWR Be Accessed over Private Networks? Will I Be Charged for Pushing and Pulling Images over Private Networks?
|
||||
------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
If your machine and the image repository are in the same region, you can access the image repository through private networks. No additional fees are charged for private network access because you have paid for your servers and EIPs.
|
||||
|
||||
If your machine and the image repository are in different regions, the node must have access to public networks to pull images from the image repository.
|
@ -0,0 +1,18 @@
|
||||
:original_name: swr_faq_1002.html
|
||||
|
||||
.. _swr_faq_1002:
|
||||
|
||||
Image Management FAQs
|
||||
=====================
|
||||
|
||||
- :ref:`Image Push and Pull <swr_faq_1012>`
|
||||
- :ref:`How Many Tenants Can I Share an SWR Private Image with? <swr_faq_1013>`
|
||||
- :ref:`What Are the Differences Between Long-Term Valid Login Commands and Temporary Login Commands? <swr_faq_0015>`
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
:hidden:
|
||||
|
||||
image_push_and_pull
|
||||
how_many_tenants_can_i_share_an_swr_private_image_with
|
||||
what_are_the_differences_between_long-term_valid_login_commands_and_temporary_login_commands
|
@ -0,0 +1,13 @@
|
||||
:original_name: swr_faq_0015.html
|
||||
|
||||
.. _swr_faq_0015:
|
||||
|
||||
What Are the Differences Between Long-Term Valid Login Commands and Temporary Login Commands?
|
||||
=============================================================================================
|
||||
|
||||
- Temporary login commands will expire after 24 hours.
|
||||
- Long-term valid login commands are valid for a year.
|
||||
|
||||
After you obtain a long-term valid login command, your temporary login commands will still be valid as long as they are in their validity periods.
|
||||
|
||||
The long-term valid and temporary login commands can be used by multiple users to log in to the system at the same time.
|