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
```