Updated on 2024-06-12 GMT+08:00

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.
  • The size of a custom image cannot exceed 30 GB.
  • 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.

    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