Custom Image Specifications for Creating AI Applications

When building a custom image using a locally developed model, ensure that the image complies with ModelArts specifications.

• No malicious code is allowed.
• A custom image 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 image in asynchronous mode.
• 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://{Listening IP address}:8080/ \ -F images=@seven.jpg

    Figure 1 Example of obtaining listen_ip
    
  • Sample response

    {"mnist_result": 7}

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

  

  • The health check API 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 the files in the OBS mount directory. You can delete only the files in the mount directory 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

  Configure standard output so that logs can be properly displayed.

• 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 dependency packages such as Python, JRE/JDK, and ZIP in the image.

• (Optional) 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 a 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) 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 exiting, 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  # Transfer SIGTERM signals to the Gunicorn process.
        wait $gunicorn_pid           # Wait until the Gunicorn process stops.
    fi
  }
  
  trap handle_sigterm TERM