Application Templates

Creating an Application Template

1. Log in to the IEF console.
2. In the navigation pane, choose Edge Applications > Application Templates. Then, click Create Application Template in the upper right corner.
3. Specify basic information.
   • Name (mandatory): name of an application template.
   • Version (mandatory): version number of the application template.
   • Alias: alias of the application template.
   • Architecture: architecture supported by the application.
   • Description: description of the application template.
   • Tags: Tags can be used to classify application templates, facilitating template management. The tags specified in this step are only used to identify application templates. You can use these tags to filter the application templates during search.

4. Click Next. Then, add a container.
   1. Click Use Image under the image to be used to deploy the application.
      • My Images: shows all the images you have uploaded to the image repository.
      • Shared Images: shows the images shared by other users.
   2. Click Next. Then, specify container specifications.
      Figure 1 Image information
      
      • Image Version: Select the version of the image to be used to deploy the application.
      • Container Specifications: Specify 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 AI Accelerator Card Configurations.
        NOTE:

        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.

      The following table lists the NPU types supported by Ascend AI accelerator cards.

      Table 1 NPU types

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

5. Click Next. Then, configure the application.
   • Startup Commands

     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 2 Startup 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 ("").

       NOTE:

       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.

   • Environment Variables

     An environment variable affects the way a running container will behave. You can modify environment variables even after applications are deployed.

     Click Add Environment Variable to add a variable. 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.
     NOTE:

     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.

   • Volumes

     A volume is used for storage when the container is running. Currently, the following four volume types 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 3 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.
     NOTICE:

     • 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.
   • Options
     • Privileged Mode

       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.

     • 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.

     • Container Network

       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.

       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.

   • Health Check
     • 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. After configuration, click Create.

Creating an Application Template Version

You can create multiple application versions for an application template to facilitate application management.

1. Log in to the IEF console.
2. In the navigation pane, choose Edge Applications > Application Templates.
3. Click the application template whose version is to be added. The application template details page is displayed.
4. In the lower left corner of the page, click Create Application Version.
   Figure 4 Creating an application version
   

5. Enter a version, and click Next. Then, configure other parameters by following the description in Creating an Application Template.