This document aims to help you understand what the parameters on the page mean when you create a swarm mode application by using an image. Then, you can configure the parameters smoothly. For some parameters, some documents are provided for your reference.
Enter the name of an existing image in the image list.
Enter the image address directly. Take the image address of a Docker Hub user’s WordPress container as an example.
docker.io/namespace/wordpress:tagis a complete image address composed of domain name, namespace, image name, and label.
Mode indicates the service deployment mode. Swarm mode clusters have the following two modes:
Replicated: Indicates the mode to specify the number of containers. Swarm manager specifies the number of tasks. With one task scheduled to a worker node, a corresponding container will be started.
Global: Indicates the global service mode. This mode will not specify the number of containers in advance. Swarm manager schedules a task on each worker node and each node will start a corresponding container. The number of containers will be changed if you scale the cluster.
For more information, see replicated-and-global-services.
Configure the command that will be run by default after the container is started and configure the corresponding parameters. We recommend that you use the Exec format. The command will be run when the container is started and docker run does not specify other commands. For more information, see command.
If docker run specifies other commands, the default command specified by command will be ignored.
Command has three formats:
CMD ["executable","param1","param2"]. This is the recommended format of command.
CMD ["param1","param2"]. Use together with entrypoint command that is in the Exec format to provide the additional parameters.
CMD command param1 param2.
The execution command to start containers. Entrypoint command can run the containers in the form of applications or services.
Entrypoint seems similar to CMD, both of which can specify the command to be run and the corresponding parameters. The difference is that entrypoint will not be ignored and must be run, even if other commands are specified when running docker run.
Entrypoint has two formats:
ENTRYPOINT ["executable", "param1", "param2"]. This is the recommended format of entrypoint.
ENTRYPOINT command param1 param2.
User: Configure the container user. With this parameter not configured, root is the default user by default. After configuring the username, a user with this name will be created. For more information, see USER.
Working Directory: Configure the default working directory. With this parameter not configured, the default working directory is the root directory
/. For more information, see WORKDIR.
Stop Grace Periods: The grace period after the container stops. The container will be killed if it is not restarted beyond the grace period. For more information, see Docker stop.
Default: By default, the number of updated tasks for each batch is one, and the action after failure is Stop. The other relevant parameters are not configured.
Custom: Used for rolling update. The parameters that can be configured are as follows:
- Failure action: The action after the failure, namely, the parameter failure_action. Select Continue or Stop.
- Delay: The update interval for each batch of tasks, namely, the parameter delay.
- Max failure ratio: The allowed failure rate during the update, namely, the parameter max_failure_ratio.
- Parallelism: The number of containers updated in parallel each time, namely, the parameter parallelism.
For more information about rolling update, see rolling_updates.
The restart policy is used to configure how to restart a container when the container exits.
Default: The container will be restarted if it exits, with no restart interval or detection interval. If the restart number of times is not configured, the container will be restarted continuously after the exit.
Custom: You can configure the restart policy for the container flexibly.
- Condition: The restart condition, namely, the parameter condition. Select always, never, or on failure.
- Delay: The interval (in seconds) each time a container is restarted, namely, the parameter delay.
- Max attempts: Namely, the parameter max_attempts. With this parameter configured, the container will not be restarted if the restart number of times exceeds this configured number. With this parameter not configured, the container will be continuously restarted until it is run successfully.
- Window: The detection interval, namely, the parameter window. You can configure a time window and the unit is the second. Container Service will detect whether or not the container is restarted successfully within this interval.
Configure the deployment constraints for services. Swarm mode schedules the tasks to specified nodes according to your configured constraints (generally for nodes and Docker Engine labels), which allows you to deploy the containers flexibly.
You can configure the parameters such as node ID, hostname, role, labels, and Docker Engine labels. For example, to deploy the container only to the manager node, enter node.role == manager. For more information, see Specified node scheduling.
Port mapping has two configuration ways:
Specify the host port and the container port.
Only specify the container port and do not enter the host port. Swarm mode will select a host port randomly.
The parameters for port mapping are as follows:
Host Port: The port exposed by the host.
Container Port: The port exposed by the container.
Protocol: TCP and UDP are supported.
Mode: Select INGRESS, HOST, or None.
- Ingress: The Ingress network can provide the Server Load Balancer capabilities for the added containers. The port must be exposed. Containers of Web service type for routing can use the Ingress network.
- Host: The network stack information to allow containers to use shared host. The network configurations of containers are the same as those of the hosts. The network performance of this mode is good. Containers that have high requirements for network transmission efficiency can adopt this mode. The drawback is that the flexibility is limited and the port conflict issue must be considered.
- None: Containers are not added to the network. Containers that have high security requirements and do not need to connect to the network can select this mode.
We recommend that you use data volumes to store the persistent data generated by containers, which is more secure, and easier to manage, back up, and migrate. For more information, see Use volumes.
The input parameters of data volumes are as follows:
Host Path or Data Volume Name: Select to mount a host directory or select a named data volume, such as OSSFS or NAS. For more information, see Use third-party data volumes.
Container Path: Specify the container path to which the host directory or named data volume is mounted in the container.
Permission: Configure the data volume permission. Select RW (Read and Write) or RO (Read Only).
Type: Configure the mount type of the data volume. Select volume, bind, or tmpfs.
Configurations: Set the other configurations. For example, nocopy indicates to not copy data from containers when creating data volumes.
For more information, see volumes.
By default, containers do not have the resource limit and can use all the resources that can be scheduled by the host kernel. To prevent risks such as OOM, you can limit the resource to control the resources that containers can use and limit the CPU and memory resource of containers.
On the interface, CPU uses 1.0 to indicate one core and supports decimals. The unit for memory is the byte. This parameter corresponds to the label limits in the orchestration template.
By default, resources are not reserved for containers. Containers compete for resources when hardware resources are scarce. When you want to deploy some important services, the corresponding containers might fail to work normally due to resource competition. Therefore, it is necessary to reserve resources for key containers.
On the interface, CPU uses 1.0 to indicate one core and supports decimals. The unit for memory is the byte. This parameter corresponds to the label reservations in the orchestration template.
Swarm mode clusters support flexible network management. Swarm mode has the default network created by the system service, the Ingress network, and your created custom network. You can add applications to the corresponding networks as per your needs. For more information, see Networks overview.
Environment variables support the input form of key/value pairs and the formats such as array, dictionary, and boolean. For more information, see environment-variables.
You can configure the relevant environment variables for Docker containers. Environment variables can be used as flags and represent some parameters of environment deployment. You can also use environment variables to pass configurations and build automated deployment scripts.
Service label is the metadata attached to services in the format of key/value pairs, which defines the service attributes and is used to manage and select services.
Label is a mechanism that applies metadata to Docker objects. The container label is the metadata attached to containers in the format of key/value pairs, which defines the container attributes and is used to manage and select containers.
You can specify multiple labels for containers and these labels are stored in the format of strings. Swarm mode supports Docker native labels and Alibaba Cloud container extension labels. For more information about the supported labels, see Label description.
Secret is a feature provided by swarm mode clusters. You can store the sensitive information such as password and certificate in Container Service by using secrets. For more information, see Secrets overview.
Click Clusters > Manage > Secrets to create a secret first. Then, configure the secret when creating an application by using an image or orchestration template.
Name: The name of the created secret, which corresponds to the parameter source.
Target: The name of the file that will be mounted to the container
/run/secrets/directory, which corresponds to the parameter target. By default, the value is the same as source, namely, the container accesses the secret in the
User ID: The ID of the user who owns the secret file in the container
/run/secrets/directory. The default value is 0.
Group ID: The ID of the group who owns the secret file in the container
/run/secrets/directory. The default value is 0.
Mode: The permission of the secret file that will be mounted to the container
/run/secrets/directory. The format is octal. For example, 0444 indicates to be world readable. Secrets are not writable because they are mounted to the temporary file system. Therefore, if you configure the writable place, the system will ignore your configurations. Use Permission Calculator if you are not familiar with UNIX permission mode.
To meet the demands of applications under different loads, Container Service supports auto scaling for the service, which automatically adjusts the number of containers according to the container resource usage in the service.
For more information, see Container auto scaling.