A service Model runs alongside all of the other Models in a Workflow. They are typically run as databases where other Models communicate with them to store ongoing information created during the Workflow.
A service Model will not start until the point where it is defined in the Workflow is reached and will then run until the end of the very end of the Workflow.
Creating a service Model
You can create a service Model in the same way you would create a normal Model. But unlike a normal Model, you would design it so that it did not have an endpoint.
To declare a Model as a service you just need to set a flag in the service Model definition's metadata section:
kind: Model api_version: v1beta2 metadata: display_name: Postgres database name: postgres-db type: service summary: A Postgres db service
Connecting to a service
You will need to connect to a service Model from another Model. To do this
you declare in the connecting Model the parameter you wish to receive the IP of the
service Model. This parameter has a type of
link and inside the Workflow
will take the step-name you have given the service.
You specify a link parameter in a Model definition as follows:
spec: inputs: parameters: - name: THE_SERVICE_IP title: Service IP description: The IP of my service type: link
When you create your connecting Model you can use the name of the parameter as an environment variable in your code to connect to the service when required.
There is currently no limit on the number of Models that can connect to a service Model.
Adding a Readiness Probe
If your service Model needs time to be setup before it can accept connections from another Model then you might need to add a readiness probe to ensure the service Model is ready. Databases are one example of a service Model that might need a readiness probe.
To make sure one is added to your Model you can add a
resources section to the
spec of the Model definition file for the service Model. Within this
readiness_probe as below:
spec: resources: readiness_probe: host: POD_IP scheme: HTTP path: /health port: 5000
host defaults to the IP address of the container that runs the service Model,
this can usually be ignored for most service Models.
scheme is the scheme to use for connecting to the container, defaults to
HTTP can either
HTTPS again this can usually be ignored for most service Models.
path is the url to access the service Model at, this defaults to
/. If this
url does not respond at any point during the time the service Model runs then the
Workflow running it will fail so choose a url that will be available throughout the
service Models life.
port is the port number to access the service Model at, this does not have a
If you do not add a
readiness_probe section then no readiness probe will be added.
Creating a Workflow
Workflows with services in work in a similar way to other Workflows. But there are a few more things to remember.
You must make sure that the service is added as a step before any Models that require it are run.
In the parameters section of the Workflow you will have to specify the name of the service in any link parameters of connecting Models by the step-name you have given it in the current Workflow.
All services are automatically stopped at the end of the Workflow.
Example service Models
There are two examples on our GitHub repository that show how to use a service Model and a client Model. You may want to check them out for more information: