Open MLOps - A Production-focused Open-Source Machine Learning Framework
Open MLOps is a set of open-source tools carefully chosen to ease user experience of conducting machine learning experiments and deploying machine learning models. Read our announcement blog post with more background here.
We also provide a step by step set-up guide and some other getting started tutorials.
In this repository, we provide these applications as Terraform modules with which the user will be able to install them into a Kubernetes cluster. The tools we provide are the following:
- Prefect for data flow automation
- Jupyter Hub for experimenting lab
- Dask for distributed computing
- Feast for Feature Store and Serving
- MLFlow for model registry and experiment tracking
- Seldon for model deployment
Other repositories
Modules
Jupyter Hub
With the Jupyter Hub, we enabled a multi-user environment in which each of them can spawn a Jupyter server to do their experiments. Users can work on different environments being able to install any library necessary to meet their needs.
We provide a default Jupyter server image that comes with most of the data science packages installed. Users can use their own Jupyter server images as well.
Configuration
Below we provide a lists of the configurable parameters available and their default values.
| Parameter (* required parameter) | Description | Default |
|---|---|---|
jupyterhub_namespace |
Namespace to install jupyterhb | jhub |
Proxy configuration
The proxy receives the requests from the client’s browser and forwards all requests to the Hub. In the JupyterHub docs you can find a more in-depth explanation.
* Required parameters
| Parameter | Description | Default |
|---|---|---|
jhub_proxy_https_enabled |
Indicator to set whether HTTPS should be enabled or not on the proxy | false |
jhub_proxy_https_hosts |
You domains in list form. Required for automatic HTTPS | [] |
jhub_proxy_secret_token * |
A 32-byte cryptographically secure randomly generated string used to secure communications between the hub and the configurable-http-proxy (for example, generated by openssl rand -hex 32) |
nil |
jhub_proxy_https_letsencrypt_contact_email |
The contact email to be used for automatically provisioned HTTPS certificates by Let’s Encrypt | "" |
Authentication configuration
JupyterHub’s OAuthenticator has support for enabling your users to authenticate via a third-party OAuth2 identity provider such as GitHub.
You can configure authentication using GitHub accounts and restrict what users are authorized based on membership in a GitHub organization.
See details on how to set up a GitHub Oauth here.
If you choose not to use GitHub to authenticate users, the DummyAuthenticator will be used as default. The Dummy Authenticator lets any user log in with the given password.
The dummy password is: a-shared-secret-password.
* Required parameters ** Required when oauth_github_enable is enabled
| Parameter | Description | Default |
|---|---|---|
oauth_github_enable |
Defines whether the authentication will be handled by github oauth. Required when oauth_github_enable is enabled |
false |
oauth_github_client_id ** |
Github client id used on GitHubOAuthenticator. | "" |
oauth_github_client_secret ** |
Github secret used to authenticate with github. | "" |
oauth_github_admin_users |
List of github user names to allow as administrator | [] |
oauth_github_callback_url |
The URL that people are redirected to after they authorize your GitHub App to act on their behalf | "" |
oauth_github_allowed_organizations |
List of Github organization to restrict access to the members | [""] |
User configuration
Single user configuration refers to the default settings for each user logged in the JupyterHub.
A user can choose a Docker image to spawn a new Jupyter server. Each Docker image can have different libraries and environments installed. We use the singleuser_profile_list parameter to set up a list of default images available to the user. This parameter receives a list of maps that describes the image details such as the image location and description.
See an example:
[{
display_name = "Prefect"
description = "Notebook with prefect installed"
default = true
kubespawner_override = {
image = "drtools/prefect:notebook-prefect"
}
}]
You must pass the image pull secret if you provide an image located in a private container registry. The image pull secret parameter is defined as below:
default = [{
name = ""
}]
| Parameter | Description | Default |
|---|---|---|
singleuser_profile_list |
List of images which the user can select to spawn a server | |
singleuser_image_pull_secrets |
List of image secrets | nil |
singleuser_image_pull_policy |
Image pull policy | Always |
singleuser_memory_guarantee |
How much memory will be guarateed to the user | 1G |
singleuser_storage_capacity |
How much storage capacity a user will have | 1G |
singleuser_storage_mount_path |
Storage mount path | /home/jovyan/persistent |
Prefect
...
| Parameter | Description | Default |
|---|---|---|
namespace |
Namespace name to deploy the application | `prefect |
prefect_version_tag |
Configures the default tag for prefect images | latest |
Agent
According to Prefect docs, Agents are lightweight processes for orchestrating flow runs. Agents run inside a user's architecture, and are responsible for starting and monitoring flow runs. During operation the agent process queries the Prefect API for any scheduled flow runs, and allocates resources for them on their respective deployment platforms.
| Parameter | Description | Default |
|---|---|---|
agent_enabled |
determines if the Prefect Kubernetes agent is deployed | True |
agent_prefect_labels |
Defines what scheduling labels (not K8s labels) should be associated with the agent | [""] |
agent_image_name |
Defines the prefect agent image name | prefecthq/prefect |
agent_image_tag |
Defines agent image tag | " |
agent_image_pull_policy |
Defines the image pull policy | Always |
Postgresql
| Parameter | Description | Default |
|---|---|---|
postgresql_database |
Defines the postgresql database name | prefect |
postgresql_username |
Defines the username to authenticate with | prefect |
postgresql_existing_secret |
Configures which secret should be referenced for access to the database. | "" |
postgresql_service_port |
Configures the port that the database should be accessed at | 5432 |
postgresql_external_hostname |
Defines the address to contact an externally managed postgres database instance at | "" |
postgresql_use_subchart |
Determines if a this chart should deploy a user-manager postgres database or use an externally managed postgres instance | true |
postgresql_persistence_enabled |
Enables a PVC that stores the database between deployments. If making changes to the database deployment, this PVC will need to be deleted for database changes to take effect. This is especially notable when the authentication password changes on redeploys. | false |
postgresql_persistence_size |
Defines the persistence storage size for postgres | 8G |
postgresql_init_user |
Defines the initial db username | postgres |
Dask
...
| Parameter | Description | Default |
|---|---|---|
namespace |
Namespace name to deploy the application | dask |
worker_name |
Dask worker name | worker |
worker_replicas |
Default number of workers | 3 |
worker_image_repository |
Containe image repository | daskdev/dask |
worker_image_tag |
Container image tag | 2.30.0 |
worker_image_pull_policy |
Container image pull policy. | IfNotPresent |
worker_image_dask_worker_command |
ask worker command. E.g dask-cuda-worker for GPU worker. |
dask-worker |
worker_image_pull_secret |
Container image pull secrets | [{name: ""}] |
worker_environment_variables |
Environment variables. See values.yaml for example values. | [{}] |
Feast
...
| Parameter | Description | Default |
|---|---|---|
namespace |
Namespace name to deploy the application | feast |
feast_core_enabled |
Defines whether to install feast core | True |
feast_online_serving_enabled |
Defines whether to install feast server | True |
feast_jupyter_enabled |
Defines whether to install feast jupyther hub | False |
feast_jobservice_enabled |
Defines whether to install feast job service | True |
feast_posgresql_enabled |
Defines whether to enable postgresql | True |
feast_postgresql_password * |
Postgress password | "" |
feast_kafka_enabled |
Defines whether to enable kafka | False |
feast_redis_enabled |
Defines whether to enable redis | True |
feast_redis_use_password |
Defines whether to enable redis password | False |
feast_prometheus_enabled |
Defines whether to install prometheys | False |
feast_prometheus_statsd_exporter_enabled |
Defines whether to enable statsd exporter | False |
feast_grafana_enabled |
Defines whether to enable grafana | True |
MLFlow
...
| Parameter | Description | Default |
|---|---|---|
namespace |
Namespace name to deploy the application | mlflow |
db_host |
Database host address | `` |
db_username |
Database username | mlflow |
db_password * |
Database password | `` |
database_name |
Database name | mlflow |
db_port |
Database port | 5432 |
default_artifact_root |
local or remote filepath to store model artifacts. It is mandatory when specifying a database backend store | /tmp |
image_pull_policy |
Docker image pull policy | IfNotPresent |
image_repository |
Docker image repository | drtools/mlflow |
image_tag |
Docker image tag | 1.13.1 |
service_type |
Kubernetes service type | NodePort |
docker_registry_server |
Docker Registry Server | `` |
docker_auth_key |
Base64 Enconded combination of {registry_username}:{registry_password}. Can be found in ~/.docker/config.json | `` |
docker_private_repo |
Whether the MLFlow's image comes from a private repository or not. If true, docker_registry_server and docker_auth_key will be required |
false |
Note: The variables docker_registry_server and docker_auth_key are optional and should only be used when pulling MLFlow's image from a private repository.
Seldon
| Parameter | Description | Default |
|---|---|---|
namespace |
Namespace name to deploy the application | mlflow |
istio_enabled |
Whether to install istio as ingress controller | true |
usage_metrics_enabled |
Whether to enable usage metrics | true |
Exposing Services
In order to access the services from outside the cluster, we need to expose them. Usually, this is done through Kubernetes Ingress resources. In this project, since we rely on Seldon to expose our prediction endpoints, we use Ambassador API Gateway as our ingress controller. Seldon Core works well with Ambassador, allowing a single ingress to be used to expose ambassador and running machine learning deployments can then be dynamically exposed through seldon-created ambassador configurations.
Ambassador
Ambassador is a Kubernetes-native API Gateway built on the Envoy Proxy. In addition to the classical routing capabilities of an ingress, it can perform sophisticated traffic management functions, such as load balancing, circuit breakers, rate limits, and automatic retries. Also, it has support for independent authentication systems, such as the ORY ecosystem.
Exposing a service in Ambassador
Ambassador is designed around a declarative, self-service management model. The core resource used to support application development teams who need to manage the edge with Ambassador is the Mapping resource. This resource allows us to define custom routing rules to our services. This routing configuration can achieved by applying a custom Kubernetes Resource like the following
# mapping.yaml
---
apiVersion: getambassador.io/v2
kind: Mapping
metadata:
name: httpbin-mapping
spec:
prefix: /httpbin/
service: httpbin.httpbin_namespace
By applying this configuration with kubectl apply -f httpbin-mapping.yaml.
Terraform
Since this project uses Terraform to manage resources and, with the current version, it's still not possible to apply custom Kubernetes resource definitions, we need to add this YAML file inside the services annotation. One way to do this is by using Service's Metadata field
resource "kubernetes_service" "httpbin" {
metadata {
...
annotations = {
"getambassador.io/config" = <<YAML
---
apiVersion: getambassador.io/v2
kind: Mapping
name: httpbin-mapping
service: httpbin.httpbin_namespace
prefix: /httpbin/
YAML
}
}
}
This will produce the same behaviour as applying the custom yaml file described above.
Authentication
Since we're exposing our services in the Internet, we need an Authentication and Authorization system to prevent unwanted users to accessing our services. Ambassador API Gateway can control the access by using an External Authentication Service resource (AuthService). An AuthService is an API that has a verification endpoint, which determines if the user can access this resource (returning 200 or not, 401). In this project, we rely on ORY ecosystem to enable authentication. ORY is an open-source ecosystem of services with clear boundaries that solve authentication and authorization.
Session Lifespan
The session lifespan of authenticated users can be managed through the /ory/kratos/values.yaml file. By default, the session lifespan is 24h, but it is currently set to 30 days.
kratos:
config:
...
session:
cookie:
domain: ${cookie_domain}
lifespan: 720h
ORY Oathkeeper
ORY Oathkeeper is an Identity and Access Proxy. It functions as a centralized way to manage different Authentication and Authorization methods, and inform the gateway, whether the HTTP request is allowed or not. The Oathkeeper serves perfectly as an Ambassador's External AuthService.
Zero-Trust and Unauthorized Resources
Oathkeeper is rooted in the principle of "never trust, always verify,". This means that if no additional configuration is provided, the Oathkeeper will always block the incoming request. In practice, all endpoints exposed in Ambassador will be blocked by external requests, until further configuration is made.
Access Rules
To configure an access rule to ORY Oathkeeper, the file access-rule-oathkeeper.yaml is used. Example:
Allow all incoming requests
- id: oathkeeper-access-rule
match:
url: <{http,https}>://${hostname}/allowed-service/<**>
methods:
- GET
authenticators:
- handler: anonymous
authorizer:
handler: allow
mutators:
- handler: noop
credentials_issuer:
handler: noop
This configuration will register all the incoming requests as a guest user, thus, not performing any credentials validation.
Authorize on KRATOS
- id: httpbin-access-rule
match:
url: <{http,https}>://${hostname}/blocked-service/<**>
methods:
- GET
authenticators:
- handler: cookie_session
authorizer:
handler: allow
mutators:
- handler: id_token
credentials_issuer:
handler: noop
errors:
- handler: redirect
config:
to: http://${hostname}/auth/login
This configuration will force authenticating all incoming requests by checking a cookie_session, which configuration is specified in config-oathkeeper.yaml
8 Jul 24, 2021
943 Jan 02, 2023
7 Nov 18, 2021
250 Jan 07, 2023
696 Dec 26, 2022
1 Jan 31, 2022
6.7k Jan 07, 2023
416 Jan 06, 2023
2 Dec 03, 2021
0 Dec 06, 2021
1.1k Jan 08, 2023
421 Dec 31, 2022
2 Jan 09, 2022
148 Dec 07, 2022
4 Feb 16, 2022
143 Dec 05, 2022
1 Dec 31, 2021
2k Jan 02, 2023
2k Dec 28, 2022
51 Nov 28, 2022