The repository contains a docker configuration file and code that allow fetching, building, and deploying a service with the following open-source planners
- Delfi1, the winner of the sequential optimal track of IPC2018
- Cerberus, participant in satisficing and agile tracks of IPC2018
- ForbidIterative suite of top-k, top-quality, and diverse planners
- K* based top-k planner
- Two-stage build via
docker build -t <YOUR_IMAGE_TAG> -f Dockerfile.twostage .
- Run the service locally via
docker run -d -p 4501:4501 --env server__hostname=`hostname`:4501 --name <YOUR_CONTAINER_NAME> <YOUR_IMAGE_TAG>
. A couple of notes:- This will make the service available on your local machine on port 4501. See the Docker User Guide for manipulating port mappings and binding to specific interfaces.
- The
--env
options are only necessary for the swagger UI available at (http://localhost:4501/api-docs) to properly bind to your physical host name and port instead of the container name. If you do not plan to use the swagger UI, you can safely skip it.
- A swagger UI is available at http://<YOUR_HOSTNAME>:4501/. Please note you should use your actual host name and not localhost, as the browser will prevent calls from going through.
- For a simple command line sample, run
samples/curl_client.sh samples/domain1.pddl samples/problem1.pddl 5
for an example. - If you are interested in a Python client, run
python samples/python_client.py samples/domain1.pddl samples/problem1.pddl 5
for an example. - If you are interested in a JavaScript client, run (you need Node.js v12+ installed)
node samples/js_client.js samples/domain1.pddl samples/problem1.pddl 5
for an example. - You can get a different client using the Swagger specification in
samples/sample_swagger_doc.json
(note the actual service specification is dynamically generated based on the configuration). You can then use either Swagger Codegen or the online Swagger Editor to generate a client in your language of choice.
By default, requests received by the service will be stored to the local file system under /tmp
. Each request will contain a zip of the original planning task and of the returned response,
as well as the console and error logs, if any. Users of the service can choose not to store their request by using the dontstore URL parameter.
You do have the option of configuring different type of storage for your processed requests as follows:
- In
config/default-unified.json
, change thetype
attribute to something that uniquely identifies your storage method. As an example, let's assume this iscloud
. - Define a new module called
storage/cloud.js
. Define and implement one exported function as follows:exports.store = function(filepath, destfname, args) { ... }
. The arguments are:filepath
is the local path to the file containing the request and response as a zip when this method is called. You may need to upload, copy, etc. this file depending on your storage methodology.destfname
is a suggested destination file/bucket/topic/etc... name. You can use this to retrieve the file in the future, or completely ignore it and produce your own. This is guaranteed to be unique while the service is running continuously.args
is a copy of theargs
object you define inconfig/default-unified.json
understorage::args
. You can pass anything you like here to configure your storage service, e.g., cloud IAM credentials, URLs, tokens, etc. - your function needs to interpret this in a meaningful way.
- You can completely disable storage of requests/responses by removing the
storage
entry inconfig/default-unified.json
.
By default, logfiles are output to the console (the current Dockerfile runs the service with a logging level of debug
), as well as to the file specified in config/default-unified.json
under logging
. Use the docker logs
comand to get the latest, or set up a container log monitoring service of your choosing.