Create your containerized application after creating a container cluster and template. This section uses the Guestbook application as an example to describe how to create a containerized application from a component template.
Type of the template that will be used to create the containerized application.
There are two types of templates: application template and component template.
In the Guestbook example, Component template is selected.
For details on how to create containerized applications using application templates, see section Creating a Containerized Application.
Container cluster on which the containerized application will run.
In the Guestbook example, the cluster name is gbk.
Name of the containerized application to be created.
An application name must:
In the Guestbook example, the application name is guestbook.
Component template created in section Creating Component Templates.
In the Frontend component example, the template name is gbkfrontend.
A component name must be unique within a cluster and 1 to 24 characters long. It must begin with a lowercase letter and but it must not end with a hyphen (-). Only lowercase letters, digits, and hyphens (-) are allowed.
Affinity: Affinity rules define in which AZs the application will be deployed. It is recommended that the AZs in which cluster nodes will be deployed should be selected as affinity AZs.
AntiAffinity: Anti-affinity rules define in which AZs the application must not be deployed.
If the affinity or anti-affinity rule is inappropriate, the CCE console displays a Warning dialog box "According to the selected affinity or anti-affinity rule, the application may not be scheduled onto any node. Are you sure you want to continue?" Click Cancel and correct the affinity or anti-affinity rule.
In the Guestbook example, this parameter is set to the recommended value Automatic.
Node on which the component will run.
Number of instances that the component has. Every instance is shipped as a container.
In the Frontend component example, the number of instances is 1.
Service names serve a similar purpose as domain names. Components are addressed by their service names.
A service name can be 1 to 24 characters long. It must begin with a lowercase letter and but it must not end with a hyphen (-). Only lowercase letters, digits, and hyphens (-) are allowed.
Indicates whether the component is accessible to external networks.
In the Frontend component example, Public Service must be selected. Otherwise, the Frontend component is not accessible to Guestbook users.
The value is either NodePort or LoadBalancer.
In the Frontend component example, NodePort is selected.
The value is either TCP or UDP. In the Frontend component example, TCP is selected.
Listening port used by the component. It is advisable to retain the default value.
Port that a node will use to provide services externally. In the Guestbook example, an automatically allocated node port is selected.
The Redis_master and Redis_slave components do not need to provide external access. Therefore, Public Service should be deselected.
The service name used must be the same as the service name defined in the process of Building a Container Image of the Frontend Component. The Frontend component maps the service name of the Redis_master component into the IP address of the Redis_master while attempting to access Redis_master.
It takes about 3 to 5 minutes to create a containerized application. If the Status of the application is Running, the application has been created successfully.
If the service type is NodePort, the service address is <Public IP address>:<Node port> of any node in the cluster. To view nodes' public IP addresses, go to the Nodes tab page on the Container Cluster page.