Deploying Applications in Batches

Scenario

In some scenarios, you may need to deploy the same applications on a large number of edge nodes. IEF allows deploying applications in batches for this purpose.

• All edge nodes must use the same architecture, for example, x86 or Arm.
• The architecture of the container image to be used must be the same as that of the edge node on which a containerized application is to be deployed. For example, if the edge node uses x86, the container image must also use x86.

Procedure

1. Log in to the IEF console, and click Switch Instance on the Dashboard page to select a platinum service instance.
2. In the navigation pane, choose Batch Management > Application Deployment Jobs and click Create Application Deployment Job in the upper right corner of the displayed page.
3. Specify basic information about the application deployment job.
   Figure 1 Creating a batch application deployment job
   
   • Name: name of the application deployment job to be created.
   • Description: description of the application deployment job.
   • Tags: tag of the application deployment job.
   • Deployment Object: edge node where the containerized application is to be deployed.

     Click Select Edge Node, and select target edge nodes.

     You can also click Search by Tag in the upper right corner of the page, enter the tag key and value, and click Search to filter out the edge nodes with the specified tag. Then, select edge nodes and click OK.

     Figure 2 Selecting tags
     
   • Restart Policy
     • Always restart: The system restarts the container regardless of whether it had quit normally or unexpectedly.
     • Restart upon failure: The system restarts the container only if it had previously quit unexpectedly.
     • Do not restart: The system does not restart the container regardless of whether it had quit normally or unexpectedly.
   • Host PID: Enabling this function allows containers to use the host's PID namespace. This function can be enabled only on edge nodes whose software version is 2.8.0 or later.

4. Click Next. Then, configure application deployment information.
   • Name Prefix: prefix of the application deployment name. IEF generates a complete name based on the prefix.
   • Instances: number of instances deployed for the application.
   • Configuration Method
     • Custom: Configure the application step by step. For details, see 5.
     • Application template: Select a predefined application template and modify it based on your requirements. This method reduces repeated operations. The configurations in a template are the same as those set in 5. For details on how to create a template, see Application Templates.
   • Description: description of the containerized application.
   • Tags: tag of the containerized application. You can select Inhibit common tags from edge nodes.

5. Configure containers.
   Click Use Image under the target image.

   • My Images: shows all the images you have created in SWR.
   • Shared Images: displays images shared by other users. Shared images are managed and maintained in SWR. For details, see Sharing a Private Image.

   After selecting an image, specify container configurations.

   • Image Version: Select the version of the image to be used to deploy the application.
     

     Do not use version latest when deploying containers in the production environment. Otherwise, it will be difficult to determine the version of the running image and to roll back the application properly.

   • Container Specifications: Specify the CPU, memory, Ascend AI accelerator card, and GPU quotas.
   • Ascend AI accelerator card: The AI accelerator card configuration of the containerized application must be the same as that of the edge node actually deployed. Otherwise, the application will fail to be created. For details, see Registering an Edge Node.
     

     For NPUs after virtualization partition, only one virtualized NPU can be mounted to a container. The virtualized NPU can be allocated to another container only after the original container quits.

     AI accelerator cards support NPU types listed in the following table:

     Table 1 NPU types

     Type	Description
     Ascend 310	Ascend 310 chips
     Ascend 310B	Ascend 310B chips

     Figure 3 Container configuration
     

   You can also configure the following advanced settings for the container:

   • Command

     A container image has metadata that stores image details. If lifecycle commands and arguments are not set, IEF runs the default commands and arguments provided during image creation, that is, ENTRYPOINT and CMD in the Dockerfile.

     If the commands and arguments used to run a container are set during application creation, the default commands ENTRYPOINT and CMD are overwritten during image building. The rules are as follows:

     Table 2 Commands and arguments used to run a container

     Image ENTRYPOINT	Image CMD	Command to Run a Container	Arguments to Run a Container	Command Executed
     [touch]	[/root/test]	Not set	Not set	[touch /root/test]
     [touch]	[/root/test]	[mkdir]	Not set	[mkdir]
     [touch]	[/root/test]	Not set	[/opt/test]	[touch /opt/test]
     [touch]	[/root/test]	[mkdir]	[/opt/test]	[mkdir /opt/test]

     Figure 4 Command
     
     • Command

       Enter an executable command, for example, /run/start.

       If there are multiple commands, separate them with spaces. If the command contains a space, enclose the command in quotation marks ("").

       

       In the case of multiple commands, you are advised to run /bin/sh or other shell commands. Other commands are used as arguments.

     • Arguments

       Enter the argument that controls the container running command, for example, --port=8080.

       If there are multiple arguments, separate them with line breaks.

   • Security Options
     • You can enable Privileged Mode to grant root permissions to the container for accessing host devices (such as GPUs and FPGAs).
     • RunAsUser Switch

       By default, IEF runs the container as the user defined during image building.

       You can specify a user to run the container by turning this switch on, and entering the user ID (an integer ranging from 0 to 65534) in the text box displayed. If the OS of the image does not contain the specified user ID, the application fails to be started.

   • Environment Variables

     An environment variable affects the way a running container will behave. Variables can be modified after workload deployment. Currently, environment variables can be manually added, imported from secrets or ConfigMaps, or referenced from hostIP.

     • Added manually: Customize a variable name and value.
     • Added from Secret: You can customize a variable name. The variable value is referenced from secret configuration data. For details on how to create a secret, see Secrets.
     • Added from ConfigMap: You can customize a variable name. The variable value is referenced from ConfigMap configuration data. For details on how to create a ConfigMap, see ConfigMaps.
     • Variable reference: The variable value is referenced from hostIP, that is, the IP address of an edge node.
     

     IEF does not encrypt the environment variables you entered. If the environment variables you attempt to configure contain sensitive information, you need to encrypt them before entering them and also need to decrypt them when using them.

     IEF does not provide any encryption and decryption tools. If you need to configure cypher text, choose your own encryption and decryption tools.

   • Data Storage

     You can define a local volume and mount the local storage directory of the edge node to the container for persistent data storage.

     Currently, the following four types of local volumes are supported:

     • hostPath: used for mounting a host directory to the container. hostPath is a persistent volume. After an application is deleted, the data in hostPath still exists in the local disk directory of the edge node. If the application is re-created later, previously written data can still be read after the directory is mounted.

       You can mount the application log directory to the var/IEF/app/log/{appName} directory of the host. In the directory name, {appName} indicates the application name. The edge node will upload the .log and .trace files in the /var/IEF/app/log/{appName} directory to AOM.

       Figure 5 Log volume mounting
       
     • emptyDir: a simple empty directory used for storing transient data. It can be created in hard disks or memory. emptyDir is an empty directory after being mounted. The application can read files from and write files into the directory. emptyDir has the same lifecycle as the application. If the application is deleted, the data in emptyDir is deleted along with it.
     • configMap: a type of resources that store configuration details required by the application. For details on how to create a ConfigMap, see ConfigMaps.
     • secret: a type of resources that store sensitive data, such as authentication, certificate, and key details. For details on how to create a secret, see Secrets.
       

       • The container path cannot be a system directory, such as / or /var/run. Otherwise, an exception occurs. You are advised to mount the container to an empty directory. If the directory is not empty, ensure that the directory does not contain any files that affect container startup. Otherwise, the files will be replaced, making it impossible for the container to be properly started. As a result, the application creation will fail.
       • If the container is mounted into a high-risk directory, you are advised to use an account with minimum permissions to start the container. Otherwise, high-risk files on the host machine may be damaged.
   • Health Check

     Health check regularly checks the status of containers or workloads.

     • Liveness Probe: The system executes the probe to check if a container is still alive, and restarts the instance if the probe fails. Currently, the system probes a container by HTTP request or command and determines whether the container is alive based on the response from the container.
     • Readiness Probe: The system invokes the probe to determine whether the instance is ready. If the instance is not ready, the system does not forward requests to the instance.

     For details, see Health Check Configuration.

6. Click Next.

   Containers can be accessed through a bridged network or a host network.

   • Bridged network

     The container uses an independent virtual network. A mapping between container and host ports needs to be configured to enable the external communication. After port mapping is configured, traffic destined for a host port is distributed to the mapping container port. For example, if container port 80 is mapped to host port 8080, the traffic destined for host port 8080 will be directed to container port 80.

     

     For automatic port assigning during port mapping, enter a proper port range to avoid port conflicts.

     You can select a host NIC to enable the port bound to this NIC to communicate with the container port. Note that port mapping does not support NICs with IPv6 addresses.

   • Host network

     The network of the host (edge node) is used. To be specific, the container and the host use the same IP address, and network isolation is not required between them.

7. Click Next. Confirm the specifications of the containerized application and click Create.

Status Description

A batch application deployment job can be in any of the following states.

• Pending: The job is waiting to be executed.
• Running: The job is being executed.
• Successful: All tasks in the job are executed successfully.
• Partially successful: Some tasks in the job are executed successfully.
• Failed: All tasks in the job failed.
• Stopping: The job is being stopped.
• Stopped: The job is stopped.
• Update timed out: The job is pended for more than 10 minutes or the job has not completed even after 10 minutes.

A job can be stopped during execution and resumed after being stopped.

If a job fails to be executed, partially succeeds, or times out, you can retry the job.