Changes to swr_umn from docs/doc-exports#702 (SWR UMN: Permission description is
Reviewed-by: Eotvos, Oliver <oliver.eotvos@t-systems.com> Co-authored-by: proposalbot <proposalbot@otc-service.com> Co-committed-by: proposalbot <proposalbot@otc-service.com>
BIN
umn/source/_static/images/en-us_image_0000001127297210.png
Normal file
After Width: | Height: | Size: 9.6 KiB |
Before Width: | Height: | Size: 15 KiB |
Before Width: | Height: | Size: 22 KiB |
Before Width: | Height: | Size: 19 KiB |
BIN
umn/source/_static/images/en-us_image_0000001361665969.png
Normal file
After Width: | Height: | Size: 35 KiB |
BIN
umn/source/_static/images/en-us_image_0000001507528236.png
Normal file
After Width: | Height: | Size: 361 B |
BIN
umn/source/_static/images/en-us_image_0000001507688112.png
Normal file
After Width: | Height: | Size: 439 B |
BIN
umn/source/_static/images/en-us_image_0000001539405909.png
Normal file
After Width: | Height: | Size: 17 KiB |
BIN
umn/source/_static/images/en-us_image_0000001539605245.png
Normal file
After Width: | Height: | Size: 65 KiB |
BIN
umn/source/_static/images/en-us_image_0000001558527697.png
Normal file
After Width: | Height: | Size: 131 B |
@ -115,3 +115,20 @@ This section describes how to compress a container image into a .tar or .tar.gz
|
||||
|
||||
$ docker save -o nginx-all.tar nginx
|
||||
$ docker save -o nginx-latest.tar nginx:latest
|
||||
|
||||
Importing an Image File
|
||||
-----------------------
|
||||
|
||||
This section describes how to import an image package as an image using the **docker load** command.
|
||||
|
||||
There are two modes:
|
||||
|
||||
**docker load <** **Path/File name.tar**
|
||||
|
||||
**docker load --input** **Path/File name.tar** or **docker load -i** **Path/File name.tar**
|
||||
|
||||
Sample:
|
||||
|
||||
.. code-block::
|
||||
|
||||
$ docker load --input fedora.tar
|
||||
|
36
umn/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
|
||||
============= =====
|
@ -17,7 +17,11 @@ Approach 1: Creating a Snapshot
|
||||
|
||||
This approach is suitable for images that will only be updated occasionally.
|
||||
|
||||
|image1|
|
||||
|
||||
.. figure:: /_static/images/en-us_image_0165153802.png
|
||||
:alt: **Figure 1** Creating a snapshot
|
||||
|
||||
**Figure 1** Creating a snapshot
|
||||
|
||||
Procedure:
|
||||
|
||||
@ -65,7 +69,11 @@ This approach is suitable for images that will be frequently updated. In :ref:`A
|
||||
|
||||
The idea behind :ref:`Approach 2 <swr_faq_0012__section1690134131216>` is to write the process of :ref:`Approach 1 <swr_faq_0012__section1017412550210>` into a Dockerfile and then run the **docker build -t test/image:tag.** command to automatically build an image from the Dockerfile. In the preceding command, **.** indicates the path to the Dockerfile.
|
||||
|
||||
|image2|
|
||||
|
||||
.. figure:: /_static/images/en-us_image_0165153805.png
|
||||
:alt: **Figure 2** Creating a Dockerfile to build an image
|
||||
|
||||
**Figure 2** Creating a Dockerfile to build an image
|
||||
|
||||
Example Dockerfile:
|
||||
|
||||
@ -199,6 +207,3 @@ Basic Syntax of Dockerfile
|
||||
Using the FROM instruction to build a child image based on the parent image created by the Dockerfile:
|
||||
|
||||
**ONBUILD ADD. /app/src**: The **ADD. /app/src** command is automatically executed.
|
||||
|
||||
.. |image1| image:: /_static/images/en-us_image_0165153802.png
|
||||
.. |image2| image:: /_static/images/en-us_image_0165153805.png
|
||||
|
@ -5,14 +5,20 @@
|
||||
General FAQs
|
||||
============
|
||||
|
||||
- :ref:`SWR Overview <swr_faq_0013>`
|
||||
- :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:
|
||||
|
||||
swr_overview
|
||||
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
|
||||
|
@ -1,26 +0,0 @@
|
||||
:original_name: swr_faq_0013.html
|
||||
|
||||
.. _swr_faq_0013:
|
||||
|
||||
SWR Overview
|
||||
============
|
||||
|
||||
How Many Images Can Be Stored in SWR?
|
||||
-------------------------------------
|
||||
|
||||
SWR has no limit on the number of images. You can upload any number of images.
|
||||
|
||||
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.
|
8
umn/source/faqs/general_faqs/what_is_swr.rst
Normal file
@ -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.
|
@ -1,24 +0,0 @@
|
||||
:original_name: swr_faq_0035.html
|
||||
|
||||
.. _swr_faq_0035:
|
||||
|
||||
Can I Pull Container Images on the SWR Console to a Local PC?
|
||||
=============================================================
|
||||
|
||||
Container images stored in SWR cannot be directly downloaded through the console. You can perform the following operations to pull the images:
|
||||
|
||||
#. Obtain the image pull command on the image details page.
|
||||
|
||||
#. Run the obtained command on the device where the Docker client is installed.
|
||||
|
||||
Example:
|
||||
|
||||
**docker pull swr.eu-de.otc.t-systems.com/group/nginx:v1**
|
||||
|
||||
#. Save the image as a TAR or TAR.GZ file.
|
||||
|
||||
Example:
|
||||
|
||||
**docker save** **nginx:v1** **>** **nginx.tar**
|
||||
|
||||
#. Download the file to the local host.
|
@ -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.
|
@ -5,14 +5,14 @@
|
||||
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>`
|
||||
- :ref:`Why Is an Image Uploaded Through the Client to SWR Different in Size From One Uploaded Through the SWR Console? <swr_faq_0005>`
|
||||
- :ref:`Can I Pull Container Images on the SWR Console to a Local PC? <swr_faq_0035>`
|
||||
|
||||
.. 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
|
||||
why_is_an_image_uploaded_through_the_client_to_swr_different_in_size_from_one_uploaded_through_the_swr_console
|
||||
can_i_pull_container_images_on_the_swr_console_to_a_local_pc
|
||||
|
@ -1,27 +0,0 @@
|
||||
:original_name: swr_faq_0005.html
|
||||
|
||||
.. _swr_faq_0005:
|
||||
|
||||
Why Is an Image Uploaded Through the Client to SWR Different in Size From One Uploaded Through the SWR Console?
|
||||
===============================================================================================================
|
||||
|
||||
Symptom
|
||||
-------
|
||||
|
||||
Assume that a nginx image of v2.0.0 is created on the local Docker client. The **docker images** command is run to query **SIZE** of the image. The size is **22.8 MB**.
|
||||
|
||||
.. code-block::
|
||||
|
||||
$ docker images
|
||||
REPOSITORY TAG IMAGE ID CREATED SIZE
|
||||
nginx v2.0.0 22f2bf2e2b4f 9 days ago 22.8MB
|
||||
|
||||
#. Run the **docker push** command to upload the image to SWR. The size of the image is **9.5 MB**.
|
||||
#. On the local Docker client, pack the image into a **.tar** package. Download the **nginx.tar** package to the local host, and upload the package to SWR. The size of the package is **23.2 MB**.
|
||||
|
||||
The size of the image uploaded through the client is different from that of the image uploaded through the SWR console.
|
||||
|
||||
Cause Analysis
|
||||
--------------
|
||||
|
||||
Image layers are compressed into **.tgz** packages when images are uploaded to SWR through the client, whereas when they are uploaded through the SWR console, they are only packed without being compressed. Therefore, the same image will be of different sizes when it is uploaded in these two different ways.
|
@ -8,6 +8,7 @@ FAQs
|
||||
- :ref:`General FAQs <swr_faq_1001>`
|
||||
- :ref:`Image Management FAQs <swr_faq_1002>`
|
||||
- :ref:`Troubleshooting <swr_faq_2000>`
|
||||
- :ref:`Other FAQs <en-us_topic_0000001488475196>`
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
@ -16,3 +17,4 @@ FAQs
|
||||
general_faqs/index
|
||||
image_management_faqs/index
|
||||
troubleshooting/index
|
||||
other_faqs/index
|
||||
|
14
umn/source/faqs/other_faqs/index.rst
Normal file
@ -0,0 +1,14 @@
|
||||
:original_name: en-us_topic_0000001488475196.html
|
||||
|
||||
.. _en-us_topic_0000001488475196:
|
||||
|
||||
Other FAQs
|
||||
==========
|
||||
|
||||
- :ref:`Why Does a CCE Workload Cannot Pull an Image from SWR and the Message Indicating "Not Logged In" Is Displayed? <en-us_topic_0000001539235197>`
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
:hidden:
|
||||
|
||||
why_does_a_cce_workload_cannot_pull_an_image_from_swr_and_the_message_indicating_not_logged_in_is_displayed
|
@ -0,0 +1,35 @@
|
||||
:original_name: en-us_topic_0000001539235197.html
|
||||
|
||||
.. _en-us_topic_0000001539235197:
|
||||
|
||||
Why Does a CCE Workload Cannot Pull an Image from SWR and the Message Indicating "Not Logged In" Is Displayed?
|
||||
==============================================================================================================
|
||||
|
||||
If a CCE workload cannot pull an SWR image and the message indicating "Not logged in" is displayed, check whether the YAML file of the workload contains the **imagePullSecrets** field and whether the value of **name** is fixed to **default-secret**.
|
||||
|
||||
Example:
|
||||
|
||||
.. code-block::
|
||||
|
||||
apiVersion: extensions/v1beta1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: nginx
|
||||
spec:
|
||||
replicas: 1
|
||||
selector:
|
||||
matchLabels:
|
||||
app: nginx
|
||||
strategy:
|
||||
type: RollingUpdate
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: nginx
|
||||
spec:
|
||||
containers:
|
||||
- image: nginx
|
||||
imagePullPolicy: Always
|
||||
name: nginx
|
||||
imagePullSecrets:
|
||||
- name: default-secret
|
@ -49,15 +49,8 @@ name invalid: 'repository' is invalid
|
||||
|
||||
**Solution**: The regular expressions of the organization (namespace) name and image (repository) name are as follows:
|
||||
|
||||
Organization name: The value contains a maximum of 64 characters and must meet regular expression **^([a-z]+(?:(?:(?:_|__|[-]*)[a-z0-9]+)+)?)$**.
|
||||
namespace: The value contains a maximum of 64 characters and must meet regular expression **^([a-z]+(?:(?:(?:_|__|[-]*)[a-z0-9]+)+)?)$**.
|
||||
|
||||
Image name: The value contains a maximum of 128 characters and must meet regular expression **^([a-z0-9]+(?:(?:(?:_|__|[-]*)[a-z0-9]+)+)?)$**.
|
||||
repository: The value contains a maximum of 128 characters and must meet regular expression **^([a-z0-9]+(?:(?:(?:_|__|[-]*)[a-z0-9]+)+)?)$**.
|
||||
|
||||
Specify a valid organization name or image name, and push the image again.
|
||||
|
||||
Image Push Occasionally Times Out
|
||||
---------------------------------
|
||||
|
||||
**Problem**: Image push occasionally times out.
|
||||
|
||||
**Solution**: When you push an image from a server in Chinese mainland to a server outside Chinese mainland, the network may be unstable.
|
||||
|
@ -17,7 +17,7 @@ x509: certificate sigined by unknown authority
|
||||
|
||||
**Solution**:
|
||||
|
||||
- If you trust the server, skip certificate authentication. Specifically, manually configure the container engine startup parameters using either of the following two methods. Replace *Image repository address* with the actual SWR repository address.
|
||||
- If you trust the server and skip certificate authentication, manually configure the startup parameters for the container engine using either of the following methods (use the actual image repository address):
|
||||
|
||||
- Add the following configuration to the **/etc/docker/daemon.json** file. If the file does not exist, manually create it. Ensure that two-space indents are used in the configuration.
|
||||
|
||||
@ -33,7 +33,7 @@ x509: certificate sigined by unknown authority
|
||||
|
||||
INSECURE_REGISTRY='--insecure-registry=Image repository address'
|
||||
|
||||
After configuration, run the **systemctl restart docker** or **service restart docker** command to restart the container engine.
|
||||
After configuration, run the **systemctl restart docker** or **service docker start** command to restart the container engine.
|
||||
|
||||
- Run the **docker info** command to check whether the proxy is correctly configured. If not, modify the configuration.
|
||||
|
||||
|
@ -39,17 +39,15 @@ Possible causes are as follows:
|
||||
a. Change the image repository address in the login command.
|
||||
b. Generate a temporary login command. For detailed instructions, see :ref:`2 <swr_faq_0016__li48456813192>`.
|
||||
|
||||
4. **x509: certficate has expired or is not yet valid**
|
||||
4. **x509: certificate has expired or is not yet valid**
|
||||
|
||||
The preceding error is reported when the AK/SK in the login command with long-term validity is deleted. In this case, use a valid AK/SK to generate a login command.
|
||||
|
||||
5. **x509: certficate signed by unknown authority**
|
||||
5. **x509: certificate signed by unknown authority**
|
||||
|
||||
**Possible Causes**:
|
||||
|
||||
The container engine client communicates with SWR through HTTPS. The client verifies the server certificate. If the server certificate is not issued by an authoritative organization, the following error message is displayed: "x509: certficate signed by unknown authority".
|
||||
|
||||
|image2|
|
||||
The container engine client communicates with SWR through HTTPS. The client verifies the server certificate. If the server certificate is not issued by an authoritative organization, the following error message is displayed: "x509: certificate signed by unknown authority"
|
||||
|
||||
**Solutions**:
|
||||
|
||||
@ -91,4 +89,3 @@ Possible causes are as follows:
|
||||
After the configuration, run the **systemctl restart docker** command to restart the container engine.
|
||||
|
||||
.. |image1| image:: /_static/images/en-us_image_0168961239.png
|
||||
.. |image2| image:: /_static/images/en-us_image_0000001137013964.png
|
||||
|
@ -14,15 +14,36 @@ This section describes how to obtain a login command that is valid for a year.
|
||||
|
||||
For security purposes, it is advised to obtain the login command in the development environment.
|
||||
|
||||
Process
|
||||
-------
|
||||
|
||||
You can obtain a long-term valid login command as the following process:
|
||||
|
||||
|
||||
.. figure:: /_static/images/en-us_image_0000001539605245.png
|
||||
:alt: **Figure 1** Process
|
||||
|
||||
**Figure 1** Process
|
||||
|
||||
Procedure
|
||||
---------
|
||||
|
||||
#. **Obtain the programmatic access permission. (If the current user has the permission, skip this step.)**
|
||||
|
||||
a. Log in to the management console as an administrator.
|
||||
b. Click |image1| in the upper left corner and select a region and a project.
|
||||
c. Click |image2| in the navigation pane on the left and choose **Management & Governance** > **Identity and Access Management**.
|
||||
d. Enter the name of the user to whom you want to grant the programmatic access permission in the search box on the **Users** page.
|
||||
e. Click the user to go to its details page.
|
||||
f. Click |image3| next to **Access Type**.
|
||||
g. Select **Programmatic access**. (You can select only programmatic access or both access types.)
|
||||
|
||||
#. .. _swr_01_1000__li5768123671815:
|
||||
|
||||
Obtain the region project name and image repository address.
|
||||
Obtain the region, project name, and image repository address.
|
||||
|
||||
a. Log in to the management console, click your username in the upper right corner, and click **My Credentials**.
|
||||
b. On the **Project List** tab page, search for the project corresponding to the current region.
|
||||
b. On the **Projects** tab page, search for the project corresponding to the current region.
|
||||
c. Obtain the image repository address by referring to :ref:`1.b <swr_01_0011__en-us_topic_0112596104_li182568055016>`. The domain name at the end of the login command is the image repository address.
|
||||
|
||||
#. .. _swr_01_1000__li1863783911295:
|
||||
@ -48,25 +69,19 @@ Procedure
|
||||
|
||||
**printf "$AK" \| openssl dgst -binary -sha256 -hmac "$SK" \| od -An -vtx1 \| sed 's/[ \\n]//g' \| sed 'N;s/\\n//'**
|
||||
|
||||
In the command, **$AK** and **$SK** indicate the AK and SK obtained in :ref:`Step 2 <swr_01_1000__li1863783911295>` respectively.
|
||||
In the command, **$AK** and **$SK** indicate the AK and SK obtained in :ref:`3 <swr_01_1000__li1863783911295>` respectively.
|
||||
|
||||
|
||||
.. figure:: /_static/images/en-us_image_0165729699.png
|
||||
:alt: **Figure 1** Sample command output
|
||||
:alt: **Figure 2** Sample command output
|
||||
|
||||
**Figure 1** Sample command output
|
||||
**Figure 2** Sample command output
|
||||
|
||||
#. Put the information you obtained in the following format to generate a long-term valid login command:
|
||||
|
||||
**docker login -u** [*Regional project name*]\ **@**\ [*AK*] **-p** [*Login key*] [*Image repository address*]
|
||||
|
||||
In the command, the regional project name and image repository address are obtained in :ref:`Step 1 <swr_01_1000__li5768123671815>`, the AK in :ref:`Step 2 <swr_01_1000__li1863783911295>`, and the login key in :ref:`Step 3 <swr_01_1000__li132430753010>`.
|
||||
|
||||
|
||||
.. figure:: /_static/images/en-us_image_0000001154534788.png
|
||||
:alt: **Figure 2** Long-term login command
|
||||
|
||||
**Figure 2** Long-term login command
|
||||
In the command, the regional project name and image repository address are obtained in :ref:`2 <swr_01_1000__li5768123671815>`, the AK in :ref:`3 <swr_01_1000__li1863783911295>`, and the login key in :ref:`4 <swr_01_1000__li132430753010>`.
|
||||
|
||||
.. note::
|
||||
|
||||
@ -75,3 +90,7 @@ Procedure
|
||||
The login command can be used on other devices.
|
||||
|
||||
#. Run the **history -c** command to clear the operation records.
|
||||
|
||||
.. |image1| image:: /_static/images/en-us_image_0000001507688112.png
|
||||
.. |image2| image:: /_static/images/en-us_image_0000001558527697.png
|
||||
.. |image3| image:: /_static/images/en-us_image_0000001507528236.png
|
||||
|
@ -15,7 +15,7 @@ Procedure
|
||||
|
||||
#. Log in to the VM running the container engine as the **root** user.
|
||||
|
||||
#. Obtain a login command by referring to :ref:`Step 1 <swr_01_0011__en-us_topic_0112596104_en-us_topic_0075378957_li58001655123>` and access SWR.
|
||||
#. Obtain a login command by referring to :ref:`1 <swr_01_0011__en-us_topic_0112596104_en-us_topic_0075378957_li58001655123>` and access SWR.
|
||||
|
||||
#. Log in to the SWR console.
|
||||
|
||||
@ -31,7 +31,7 @@ Procedure
|
||||
|
||||
**Figure 1** Obtaining the image pull command
|
||||
|
||||
#. Run the **image pull** command obtained in :ref:`Step 5 <swr_01_0017__en-us_topic_0084266454_li197783469319>` on the VM.
|
||||
#. Run the **image pull** command obtained in :ref:`5 <swr_01_0017__en-us_topic_0084266454_li197783469319>` on the VM.
|
||||
|
||||
Run the **docker images** command to check whether the images are successfully pulled.
|
||||
|
||||
|
@ -10,10 +10,6 @@ Scenario
|
||||
|
||||
This section walks you through the steps of uploading an image to SWR through the client by taking the **nginx:v1** image built in :ref:`Basics of the Container Engine <swr_01_0006>` as an example. Uploading an image through the client is to run Docker commands on the client where Docker is installed to push the image to an image repository of SWR.
|
||||
|
||||
.. note::
|
||||
|
||||
Each image layer uploaded through the client cannot exceed 10 GB.
|
||||
|
||||
Notes and Constraints
|
||||
---------------------
|
||||
|
||||
@ -36,7 +32,7 @@ Prerequisites
|
||||
]
|
||||
}
|
||||
|
||||
To obtain the value of {*Intranet address*}, log in to the SWR console. On the **Dashboard** page, click **Generate Login Command** and obtain the private network address (IP:20202) in the private network command.
|
||||
To obtain the value of {*Intranet address*}, log in to the SWR console. On the **Dashboard** page, click **Generate Login Command** and obtain the private network address in the private network command.
|
||||
|
||||
|
||||
.. figure:: /_static/images/en-us_image_0000001201043047.png
|
||||
|
@ -6,7 +6,8 @@ Software Repository for Containers - User Guide
|
||||
:maxdepth: 1
|
||||
|
||||
service_overview/index
|
||||
introduction
|
||||
overview
|
||||
permissions_management/index
|
||||
basics_of_the_container_engine
|
||||
image_management/index
|
||||
organization_management
|
||||
|
@ -31,10 +31,10 @@ You can create organizations based on the organizational structure of your enter
|
||||
#. In the navigation pane on the left, choose **Organization Management** and click **Create Organization**. On the page displayed, specify **Organization Name** and click **OK**.
|
||||
|
||||
|
||||
.. figure:: /_static/images/en-us_image_0000001200800369.png
|
||||
:alt: **Figure 2** Creating an Organization
|
||||
.. figure:: /_static/images/en-us_image_0000001361665969.png
|
||||
:alt: **Figure 2** Creating an organization
|
||||
|
||||
**Figure 2** Creating an Organization
|
||||
**Figure 2** Creating an organization
|
||||
|
||||
.. note::
|
||||
|
||||
@ -50,13 +50,13 @@ After you create an organization and push images to it, you can view the image l
|
||||
|
||||
#. In the navigation pane, choose **Organization Management**. On the page displayed, click the desired organization name in the list.
|
||||
|
||||
#. To view the images of this organization, click the **Image** tab.
|
||||
#. To view the images of this organization, click the **Images** tab.
|
||||
|
||||
|
||||
.. figure:: /_static/images/en-us_image_0000001154966988.png
|
||||
:alt: **Figure 3** Viewing the Images of an Organization
|
||||
:alt: **Figure 3** Viewing the images of an organization
|
||||
|
||||
**Figure 3** Viewing the Images of an Organization
|
||||
**Figure 3** Viewing the images of an organization
|
||||
|
||||
Deleting an Organization
|
||||
------------------------
|
||||
@ -65,7 +65,7 @@ Before deleting an organization, delete all the images in the organization.
|
||||
|
||||
#. Log in to the SWR console.
|
||||
#. In the navigation pane, choose **Organization Management**. On the page displayed, click the desired organization name in the list.
|
||||
#. Click **Delete** in the upper right corner. In the displayed dialog box, enter **DELETE** as prompted and click **Yes**.
|
||||
#. Click **Delete** in the upper right corner. In the displayed dialog box, enter DELETE as prompted and click **Yes**.
|
||||
|
||||
.. important::
|
||||
|
||||
|
@ -2,8 +2,8 @@
|
||||
|
||||
.. _swr_01_0009:
|
||||
|
||||
Introduction
|
||||
============
|
||||
Overview
|
||||
========
|
||||
|
||||
SoftWare Repository for Container (SWR) allows you to easily manage the full lifecycle of container images and facilitates secure deployment of images for your applications.
|
||||
|
@ -0,0 +1,43 @@
|
||||
:original_name: swr_01_0072.html
|
||||
|
||||
.. _swr_01_0072:
|
||||
|
||||
Creating a User and Granting SWR Permissions
|
||||
============================================
|
||||
|
||||
This section describes how to use `IAM <https://docs.otc.t-systems.com/en-us/usermanual/iam/iam_01_0026.html>`__ for fine-grained permission management on your SWR resources. With IAM, you can:
|
||||
|
||||
- Create IAM users for employees based on your enterprise's organizational structure. Each IAM user will have their own security credentials for accessing SWR resources.
|
||||
- Grant only the permissions required for users to perform a specific task.
|
||||
- Entrust a cloud account or cloud service to perform efficient O&M on your SWR resources.
|
||||
|
||||
If your account does not need individual IAM users, you may skip over this chapter.
|
||||
|
||||
This section describes the procedure for granting permissions (see :ref:`Figure 1 <swr_01_0072__fig5293113815405>`).
|
||||
|
||||
Prerequisite
|
||||
------------
|
||||
|
||||
Learn about the permissions supported by SWR and choose policies or roles according to your requirements.
|
||||
|
||||
Process Flow
|
||||
------------
|
||||
|
||||
.. _swr_01_0072__fig5293113815405:
|
||||
|
||||
.. figure:: /_static/images/en-us_image_0000001127297210.png
|
||||
:alt: **Figure 1** Process for granting SWR permissions
|
||||
|
||||
**Figure 1** Process for granting SWR permissions
|
||||
|
||||
#. .. _swr_01_0072__li8135822590:
|
||||
|
||||
`Create a user group and assign permissions <https://docs.otc.t-systems.com/en-us/usermanual/iam/iam_01_0030.html>`__.
|
||||
|
||||
Create a user group on the IAM console, and assign the **SWR Administrator** policy to the group.
|
||||
|
||||
#. `Create an IAM user and add the user to a user group <https://docs.otc.t-systems.com/en-us/usermanual/iam/iam_01_0031.html>`__.
|
||||
|
||||
Create a user on the IAM console and add the user to the group created in :ref:`1 <swr_01_0072__li8135822590>`.
|
||||
|
||||
#. `Log in <https://docs.otc.t-systems.com/en-us/usermanual/iam/iam_01_0552.html>`__ as the IAM user and verify permissions.
|
14
umn/source/permissions_management/index.rst
Normal file
@ -0,0 +1,14 @@
|
||||
:original_name: swr_01_0070.html
|
||||
|
||||
.. _swr_01_0070:
|
||||
|
||||
Permissions Management
|
||||
======================
|
||||
|
||||
- :ref:`Creating a User and Granting SWR Permissions <swr_01_0072>`
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
:hidden:
|
||||
|
||||
creating_a_user_and_granting_swr_permissions
|
@ -20,5 +20,4 @@ Security and Reliability
|
||||
Image Acceleration
|
||||
------------------
|
||||
|
||||
- SWR uses the P2P image download acceleration technology to ensure faster image pull for CCE clusters in high concurrency scenarios.
|
||||
- Intelligent node scheduling around the globe ensures that your image build tasks can be automatically assigned to the idle nodes nearest to the image repository.
|
||||
SWR uses the image pull acceleration technology to ensure faster image pull for CCE clusters in high concurrency scenarios.
|
||||
|
@ -12,14 +12,14 @@ You can use SWR to build, push, pull, synchronize, and delete container images.
|
||||
|
||||
**Advantages**
|
||||
|
||||
- P2P download acceleration ensures faster image pull for CCE clusters.
|
||||
- Pull acceleration ensures faster image pull for CCE clusters.
|
||||
- Up to 99.999999999% image storage reliability is achieved by working with Object Storage Service (OBS).
|
||||
- Fine-grained authorization allows you to control access to specific images and images in specific organizations.
|
||||
|
||||
**Related Services**
|
||||
**Related service: Cloud Container Engine (CCE)**
|
||||
|
||||
You can use SWR together with CCE in this scenario.
|
||||
|
||||
|image1|
|
||||
.. figure:: /_static/images/en-us_image_0294353976.png
|
||||
:alt: **Figure 1** SWR working with CCE
|
||||
|
||||
.. |image1| image:: /_static/images/en-us_image_0294353976.png
|
||||
**Figure 1** SWR working with CCE
|
||||
|
@ -10,6 +10,7 @@ Service Overview
|
||||
- :ref:`Application Scenarios <swr_03_0004>`
|
||||
- :ref:`Basic Concepts <swr_03_0003>`
|
||||
- :ref:`Notes and Constraints <swr_03_0007>`
|
||||
- :ref:`Permissions <en-us_topic_0000001488156484>`
|
||||
- :ref:`Related Services <swr_03_0006>`
|
||||
|
||||
.. toctree::
|
||||
@ -21,4 +22,5 @@ Service Overview
|
||||
application_scenarios
|
||||
basic_concepts
|
||||
notes_and_constraints
|
||||
permissions/index
|
||||
related_services
|
||||
|
@ -26,9 +26,9 @@ Features
|
||||
|
||||
Private image repository and fine-grained permission management allow you to grant different access permissions, namely, read, write, and edit, to different users.
|
||||
|
||||
- **P2P acceleration of large scale image distribution**
|
||||
- **Large scale image distribution acceleration**
|
||||
|
||||
SWR uses the image download acceleration technology to ensure faster image pull for CCE clusters in high concurrency scenarios.
|
||||
SWR uses the image pull acceleration technology to ensure faster image pull for CCE clusters in high concurrency scenarios.
|
||||
|
||||
Accessing SWR
|
||||
-------------
|
||||
|
22
umn/source/service_overview/permissions/index.rst
Normal file
@ -0,0 +1,22 @@
|
||||
:original_name: en-us_topic_0000001488156484.html
|
||||
|
||||
.. _en-us_topic_0000001488156484:
|
||||
|
||||
Permissions
|
||||
===========
|
||||
|
||||
If you need to assign different permissions to employees in your enterprise to access your SWR resources, Identity and Access Management (IAM) is a good choice for fine-grained permissions management. IAM provides identity authentication, permissions management, and access control, enabling secure access to your cloud resources.
|
||||
|
||||
With IAM, you can use your account to create IAM users, and assign permissions to the users to control their access to specific cloud resources. For example, some software developers in your enterprise need to use SWR resources but should not be allowed to delete the resources or perform any other high-risk operations. In this scenario, you can create IAM users for the software developers and grant them only the permissions required for using SWR resources.
|
||||
|
||||
If your account does not require individual IAM users for permissions management, skip this section.
|
||||
|
||||
IAM can be used free of charge. You pay only for the resources in your account. For more information about IAM, see `IAM Service Overview <https://docs.otc.t-systems.com/en-us/usermanual/iam/iam_01_0026.html>`__.
|
||||
|
||||
- :ref:`SWR Permissions <en-us_topic_0000001488156664>`
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
:hidden:
|
||||
|
||||
swr_permissions
|
28
umn/source/service_overview/permissions/swr_permissions.rst
Normal file
@ -0,0 +1,28 @@
|
||||
:original_name: en-us_topic_0000001488156664.html
|
||||
|
||||
.. _en-us_topic_0000001488156664:
|
||||
|
||||
SWR Permissions
|
||||
===============
|
||||
|
||||
By default, new IAM users do not have any permissions granted. You need to add them to one or more groups and attach permissions policies or roles to these groups. In this way, the users can inherit permissions from the groups and perform operations on specific cloud resources.
|
||||
|
||||
SWR is a project-level service deployed and accessed in specific physical regions. To assign AOM permissions to a user group, specify the scope as region-specific projects and select projects for the permissions to take effect. If **All projects** is selected, the permissions will take effect for the user group in all region-specific projects. When accessing SWR, the users need to switch to a Region where they have been authorized to use this service.
|
||||
|
||||
.. table:: **Table 1** SWR permissions
|
||||
|
||||
+------------------------+----------------------------------------------------------------------------------------------+---------------------+
|
||||
| Name | Description | Type |
|
||||
+========================+==============================================================================================+=====================+
|
||||
| SWR Administrator | SWR administrator permissions, including all SWR permissions. | System-defined role |
|
||||
+------------------------+----------------------------------------------------------------------------------------------+---------------------+
|
||||
| Tenant Administrator | Administrator permissions for all services except IAM, including all SWR permissions. | System-defined role |
|
||||
+------------------------+----------------------------------------------------------------------------------------------+---------------------+
|
||||
| Tenant Guest | Read-only permissions for all services except IAM, including permissions such as image pull. | System-defined role |
|
||||
+------------------------+----------------------------------------------------------------------------------------------+---------------------+
|
||||
| ServiceStage Developer | ServiceStage developer permissions, including permissions such as image pull. | System-defined role |
|
||||
+------------------------+----------------------------------------------------------------------------------------------+---------------------+
|
||||
|
||||
.. note::
|
||||
|
||||
- `Granting user permissions <https://docs.otc.t-systems.com/en-us/usermanual/swr/swr_01_0015.html>`__ enables you to grant read, write, and management permissions to different users for them to access either a specific image or images of a specific organization.
|
@ -5,16 +5,16 @@
|
||||
User Permissions
|
||||
================
|
||||
|
||||
Scenarios
|
||||
---------
|
||||
Scenario
|
||||
--------
|
||||
|
||||
To manage SWR permissions, you can use Identity and Access Management (IAM). If you have the SWR Admin or Tenant Administrator permission, you become an admin user of SWR. You can grant permissions to other IAM users in SWR.
|
||||
To manage SWR permissions, you can use Identity and Access Management (IAM). If you have the SWR Administrator or Tenant Administrator permission, you become an admin user of SWR accounts. You can grant permissions to other IAM users in SWR.
|
||||
|
||||
If you are not an SWR admin user, you can request an SWR admin user to grant you permissions to read, write, or manage a specific image or images in a specific organization.
|
||||
If you are not an SWR account admin user, you can request an SWR account admin user to grant you permissions to read, write, or manage a specific image or images in a specific organization.
|
||||
|
||||
.. note::
|
||||
|
||||
- An admin user is granted image management permission of all organizations by default, even if the user is not in the authorized user list of the organizations.
|
||||
- An SWR account admin user is granted image management permission of all organizations by default, even if the user is not in the authorized user list of the organizations.
|
||||
- SWR is deployed and accessed in specific physical regions. To assign permissions to a user group, specify the scope as region-specific projects and select projects for the permissions to take effect.
|
||||
|
||||
Authorization Method
|
||||
@ -55,9 +55,9 @@ To allow users to read, write, and manage a specific image, grant corresponding
|
||||
|
||||
|
||||
.. figure:: /_static/images/en-us_image_0000001154645118.png
|
||||
:alt: **Figure 2** Granting Permissions for a Specific Image
|
||||
:alt: **Figure 2** Granting permissions for a specific image
|
||||
|
||||
**Figure 2** Granting Permissions for a Specific Image
|
||||
**Figure 2** Granting permissions for a specific image
|
||||
|
||||
Modifying or Deleting Permissions for a Specific Image
|
||||
------------------------------------------------------
|
||||
@ -65,7 +65,7 @@ Modifying or Deleting Permissions for a Specific Image
|
||||
You can also modify or delete user permissions on the image details page.
|
||||
|
||||
- To modify permissions, click **Modify** in the row of the desired username on the **Permissions** tab page. Select a permission in the **Permission** drop-down list, and click **Save** in the **Operation** column.
|
||||
- To delete permissions, click **Delete** in the row of the desired username on the **Permissions** tab page. In the dialog box displayed, enter **DELETE** and click **Yes**.
|
||||
- To delete permissions, click **Delete** in the row of the desired username on the **Permissions** tab page, enter **DELETE** in the dialog box displayed, and then click **Yes**.
|
||||
|
||||
.. _swr_01_0015__section950354645517:
|
||||
|
||||
|