- What's New
- Function Overview
- Service Overview
- Billing
- Getting Started
- User Guide
- Best Practices
-
Developer Guide
- Overview
- Using Native kubectl (Recommended)
- Namespace and Network
- Pod
- Label
- Deployment
- EIPPool
- EIP
- Pod Resource Monitoring Metric
- Collecting Pod Logs
- Managing Network Access Through Service and Ingress
- Using PersistentVolumeClaim to Apply for Persistent Storage
- ConfigMap and Secret
- Creating a Workload Using Job and Cron Job
- YAML Syntax
-
API Reference
- Before You Start
- Calling APIs
- Getting Started
- Proprietary APIs
-
Kubernetes APIs
- ConfigMap
- Pod
- StorageClass
- Service
-
Deployment
- Querying All Deployments
- Deleting All Deployments in a Namespace
- Querying Deployments in a Namespace
- Creating a Deployment
- Deleting a Deployment
- Querying a Deployment
- Updating a Deployment
- Replacing a Deployment
- Querying the Scaling Operation of a Specified Deployment
- Updating the Scaling Operation of a Specified Deployment
- Replacing the Scaling Operation of a Specified Deployment
- Querying the Status of a Deployment
- Ingress
- OpenAPIv2
- VolcanoJob
- Namespace
- ClusterRole
- Secret
- Endpoint
- ResourceQuota
- CronJob
-
API groups
- Querying API Versions
- Querying All APIs of v1
- Querying an APIGroupList
- Querying APIGroup (/apis/apps)
- Querying APIs of apps/v1
- Querying an APIGroup (/apis/batch)
- Querying an APIGroup (/apis/batch.volcano.sh)
- Querying All APIs of batch.volcano.sh/v1alpha1
- Querying All APIs of batch/v1
- Querying All APIs of batch/v1beta1
- Querying an APIGroup (/apis/crd.yangtse.cni)
- Querying All APIs of crd.yangtse.cni/v1
- Querying an APIGroup (/apis/extensions)
- Querying All APIs of extensions/v1beta1
- Querying an APIGroup (/apis/metrics.k8s.io)
- Querying All APIs of metrics.k8s.io/v1beta1
- Querying an APIGroup (/apis/networking.cci.io)
- Querying All APIs of networking.cci.io/v1beta1
- Querying an APIGroup (/apis/rbac.authorization.k8s.io)
- Querying All APIs of rbac.authorization.k8s.io/v1
- Event
- PersistentVolumeClaim
- RoleBinding
- StatefulSet
- Job
- ReplicaSet
- Data Structure
- Permissions Policies and Supported Actions
- Appendix
- Out-of-Date APIs
- Change History
-
FAQs
- Product Consulting
-
Basic Concept FAQs
- What Is CCI?
- What Are the Differences Between Cloud Container Instance and Cloud Container Engine?
- What Is an Environment Variable?
- What Is a Service?
- What Is Mcore?
- What Are the Relationships Between Images, Containers, and Workloads?
- What Are Kata Containers?
- Can kubectl Be Used to Manage Container Instances?
- What Are Core-Hours in CCI Resource Packages?
- Workload Abnormalities
-
Container Workload FAQs
- Why Service Performance Does Not Meet the Expectation?
- How Do I Set the Quantity of Instances (Pods)?
- How Do I Check My Resource Quotas?
- How Do I Set Probes for a Workload?
- How Do I Configure an Auto Scaling Policy?
- What Do I Do If the Workload Created from the sample Image Fails to Run?
- How Do I View Pods After I Call the API to Delete a Deployment?
- Why an Error Is Reported When a GPU-Related Operation Is Performed on the Container Entered by Using exec?
- Can I Start a Container in Privileged Mode When Running the systemctl Command in a Container in a CCI Cluster?
- Why Does the Intel oneAPI Toolkit Fail to Run VASP Tasks Occasionally?
- Why Are Pods Evicted?
- Why Is the Workload Web-Terminal Not Displayed on the Console?
- Why Are Fees Continuously Deducted After I Delete a Workload?
-
Image Repository FAQs
- Can I Export Public Images?
- How Do I Create a Container Image?
- How Do I Upload Images?
- Does CCI Provide Base Container Images for Download?
- Does CCI Administrator Have the Permission to Upload Image Packages?
- What Permissions Are Required for Uploading Image Packages for CCI?
- What Do I Do If Authentication Is Required During Image Push?
-
Network Management FAQs
- How Do I View the VPC CIDR Block?
- Does CCI Support Load Balancing?
- How Do I Configure the DNS Service on CCI?
- Does CCI Support InfiniBand (IB) Networks?
- How Do I Access a Container from a Public Network?
- How Do I Access a Public Network from a Container?
- What Do I Do If Access to a Workload from a Public Network Fails?
- What Do I Do If Error 504 Is Reported When I Access a Workload?
- What Do I Do If the Connection Timed Out?
- Storage Management FAQs
- Log Collection
- Account
- SDK Reference
- Videos
- General Reference
Show all
Copied.
Using docker run Commands to Run Containers
Docker is an open source engine that manages images and containers. A Docker image includes all dependencies required for running an application. The processes contained in the image are isolated from each other.
Docker containers are built on Docker images.
Preparing Images
WordPress and MySQL images are general-purpose images and can be obtained from the container registry.
You can run the docker pull command on the device where the container engine is installed to download images.
docker pull mysql:5.7 docker pull wordpress
Run the docker images command to view the images. As shown in the following figure, two images exist on the local host.
Running Containers
You can use the container engine to run the WordPress and MySQL containers, and use the --link parameter to connect the two containers. In this way, the WordPress container can access the MySQL container without code changes.
Run the following command to run the MySQL container:
docker run --name some-mysql -e MYSQL_ROOT_PASSWORD=******** -e MYSQL_DATABASE=wordpress -d mysql:5.7
The parameters are described as follows:
- --name: specifies the container name as some-mysql.
- -e: specifies the environment variable of the container. In this example, the value of MYSQL_ROOT_PASSWORD is ******** (replace ******** with your password). The environment variable MYSQL_DATABASE indicates the name of the database to be created when the image is started. Its value is wordpress in this example.
- -d: indicates that the container runs in the backend.
Run the following command to run the WordPress container:
docker run --name some-wordpress --link some-mysql:mysql -p 8080:80 -e WORDPRESS_DB_PASSWORD=******** -e WORDPRESS_DB_USER=root -d wordpress
The parameters are described as follows:
- --name: specifies the container name as some-wordpress.
- --link: connects the some-wordpress container to the some-mysql container and changes the name of the some-mysql container to mysql. --link provides an easy way to connect two containers. Alternatively, you can configure the environment variable WORDPRESS_DB_HOST of the some-wordpress container to access the IP address and port of the mysql container.
- -p: specifies ports for mapping. In this example, port 80 of the container is mapped to port 8080 of the host.
- -e: specifies the environment variable of the container. In this example, the value of WORDPRESS_DB_PASSWORD is ******** (replace ******** with your password). The value of WORDPRESS_DB_PASSWORD must be the same as that of MYSQL_ROOT_PASSWORD because the WordPress requires a password to access the MySQL database. WORDPRESS_DB_USER indicates the username for accessing the MySQL database. Set it to root.
- -d: indicates that the container runs in the backend.
After the WordPress runs, you can access WordPress blogs through http://127.0.0.1:8080.
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot