Skip to main content

Package and deploy an image

Once you have a Handler Function, the next step is to package it into a Docker image that can be deployed as a scalable Serverless Worker. This is accomplished by defining a docker file to import everything required to run your handler. Example docker files are in the runpod-workers repository on GitHub.

Unfamiliar with Docker? Check out Docker's overview page or see our guide on Containers.

Docker file

Let's say we have a directory that looks like the following:


project_directory
├── Dockerfile
├── src
│ └── handler.py
└── builder
└── requirements.txt

Your Dockerfile would look something like this:

Docker

from python:3.11.1-buster
WORKDIR /
COPY builder/requirements.txt .
RUN pip install -r requirements.txt
ADD handler.py .
CMD [ "python", "-u", "/handler.py" ]

To build and push the image, review the steps in Get started.

🚧 If your handler requires external files such as model weights, be sure to cache them into your docker image. You are striving for a completely self-contained worker that doesn't need to download or fetch external files to run.

Continuous integrations

Integrate your Handler Functions through continuous integration.

The Test Runner GitHub Action is used to test and integrate your Handler Functions into your applications.

note

Running any Action that sends requests to RunPod occurs a cost.

You can add the following to your workflow file:


- uses: actions/checkout@v3
- name: Run Tests
uses: runpod/runpod-test-runner@v1
with:
image-tag: [tag of image to test]
runpod-api-key: [a valid Runpod API key]
test-filename: [path for a json file containing a list of tests, defaults to .github/tests.json]
request-timeout: [number of seconds to wait on each request before timing out, defaults to 300]

If test-filename is omitted, the Test Runner Action attempts to look for a test file at .github/tests.json.

You can find a working example in the Worker Template repository.

Other considerations

While we do not impose a limit on the docker image size your container registry might have, be sure to review any limitations they may have. Ideally, you want to keep your final docker image as small as possible and only container the absolute minimum to run your handler.

We also highly recommend the use of tags for docker images and not relying on the default :latest tag label, this will make version tracking and releasing updates significantly easier.