Creating a Custom Image for an AI Application

Procedure

Scenario 1: The environment software of the preset image meets the requirements. You only need to import a model package to create an AI application by saving the image. For details, see Creating a Custom Image in a Notebook Instance Using the Image Saving Function.

Figure 1 Creating a custom image for an AI application (scenario 1)

Scenario 2: The preset image does not meet the software environment requirements. You need to import a model package and create the image using Dockerfile. For details, see Creating a Custom Image in a Notebook Instance Using Dockerfile.

Figure 2 Creating a custom image for an AI application (scenario 2)

Scenario 3: The preset does not meet the software environment requirements. You need to import a model package. The new image is larger than 35 GB and needs to be created on a server such as ECS. For details, see Creating a Custom Image on ECS.

Figure 3 Creating a custom image for an AI application (scenario 3)

Constraints

• No malicious code is allowed.
• The image for creating an AI application cannot be larger than 50 GB.
• For AI applications in synchronous request mode, if the prediction request latency exceeds 60 seconds, the request will fail, and there is a possibility that the service may be interrupted. Therefore, in this case, create an AI application in asynchronous mode.

Specifications for Custom Images

• External APIs

  Set the external service API for a custom image. The inference API must be the same as the URL defined by apis in config.json. Then, the external service API can be directly accessed when the image is started. The following is an example of accessing an MNIST image. The image contains a model trained using an MNIST dataset and can identify handwritten digits. listen_ip indicates the container IP address. You can start a custom image to obtain the container IP address from the container.

  • Sample request

    curl -X POST \ http://{listen_ip}:8080/ \ -F images=@seven.jpg

    Figure 4 Example of obtaining listen_ip
    
  • Sample response

    {"mnist_result": 7}

• (Optional) Health check APIs
  If services must not be interrupted during a rolling upgrade, the health check APIs must be configured in config.json for ModelArts. The health check APIs return the health status for a service when the service is running properly or an error when the service becomes faulty.

  

  • The health check APIs must be configured for a hitless rolling upgrade.
  • If you need to use OBS external storage mounting for custom images in real-time services, create a new directory for OBS data, for example, /obs-mount/. Otherwise, the existing files will be overwritten. You can add, view, and modify files in the OBS mount directory. To delete the files, delete them in the OBS parallel file system.

  The following shows a sample health check API:

  • URI

    GET /health

  • Sample request: curl -X GET \ http://{Listening IP address}:8080/health
  • Sample response

    {"health": "true"}

  • Status code

    Table 1 Status code

    Status Code	Message	Description
    200	OK	Request sent.

• Log file output

  To ensure that logs can be properly displayed, the logs must be standard output.

• Image boot file

  To deploy a batch service, set the boot file of an image to /home/run.sh and use CMD to set the default boot path. The following is a sample Dockerfile:

  CMD ["sh", "/home/run.sh"]

• Image dependencies

  To deploy a batch service, install dependencies such as Python, JRE/JDK, and ZIP in the image.

• (Optional) Maintaining HTTP persistent connections for hitless rolling upgrade

  To ensure that services are not interrupted during a rolling upgrade, set HTTP keep-alive to 200. For example, Gunicorn does not support keep-alive by default. To ensure hitless rolling upgrade, install Gevent and configure --keep-alive 200 -k gevent in the image. The parameter settings vary depending on the service framework. Set the parameters as required.

• (Optional) Processing SIGTERM signals and gracefully exiting a container

  To ensure that services are not interrupted during a rolling upgrade, the system must capture SIGTERM signals in the container and wait for 60s before gracefully exiting the container. If the duration is less than 60s before the graceful exit, services may be interrupted during the rolling upgrade. To ensure uninterrupted service running, the system exits the container after the system receives SIGTERM signals and processes all received requests. The whole duration is not longer than 90s. The following shows example run.sh:

  #!/bin/bash
  gunicorn_pid=""
  
  handle_sigterm() {
    echo "Received SIGTERM, send SIGTERM to $gunicorn_pid"
    if [ $gunicorn_pid != "" ]; then
        sleep 60
        kill -15 $gunicorn_pid  # Pass SIGTERM signals to the Gunicorn process.
        wait $gunicorn_pid           # Wait until the Gunicorn process stops.
    fi
  }
  
  trap handle_sigterm TERM