.

.

Wallaroo Configuration Guide

How to configure Wallaroo

Wallaroo comes with a plethora of options to enable different services, set performance options, and everything you need to run Wallaroo in the most efficient way.

The following guides are made to help organizations configure Wallaroo and provides integrate it into other services.

1 - DNS Integration Guide

Integrate Wallaroo Enterprise Into an Organization’s DNS.

The following guide demonstrates how to integrate a Wallaroo Enterprise instance with an organization’s DNS. DNS services integration is required for Wallaroo Enterprise edition. It is not required for Wallaroo Community. This guide is indented to assist organizations complete their Wallaroo Enterprise installation, and can be used as a reference if changes to the DNS services are modified and updates to the Wallaroo Enterprise instance are required.

DNS Services Integration Introduction

DNS services integration is required for Wallaroo Enterprise to provide access to the various supporting services that are part of the Wallaroo instance. These include:

  • Simplified user authentication and management.
  • Centralized services for accessing the Wallaroo Dashboard, Wallaroo SDK and Authentication.
  • Collaboration features allowing teams to work together.
  • Managed security, auditing and traceability.

This guide is not intended for Wallaroo Community, as those DNS entries are managed by Wallaroo during the installation. For more information on installing Wallaroo Community, see the Wallaroo Community Install Guides.

Once integrated, users can access the following services directly from a URL starting with the suffix domain - this is the domain name where other DNS entries are appended to. For example, if the suffix domain is sales.example.com, then the other services would be referenced by https://api.sales.sample.com, etc.

Note that even when accessing specific Wallaroo services directly that the user must still be authenticated through Wallaroo.

ServiceDNS EntryDescription
Wallaroo Dashboardsuffix domainProvides access to a user interface for updating workspaces, pipelines, and models. Also provides access to the integrated JupyterHub service.
JupyterHubjupyterhubAllows the use of Jupyter Notebooks and access to the Wallaroo SDK.
APIapiProvides access to the Wallaroo API.
KeycloakkeycloakKeycloak provides user management to the Wallaroo instance.

Connections to Wallaroo services are provided as https://service.{suffix domain}. For example, if the domain suffix is wallaroo.example.com then the URLs to access the various Wallaroo services would be:

  • https://wallaroo.example.com
  • https://jupyter.wallaroo.example.com
  • https://api.wallaroo.example.com
  • https://keycloak.wallaroo.example.com

Prerequisites

  • Install Wallaroo Enterprise into a qualified environment. For more details, see the Wallaroo Install Guides and the Wallaroo Enterprise Install Guides.
  • Determine whether your organization will use a prefix or not as detailed above.
  • Have access to the Wallaroo Administrative Dashboard - this requires access to the Kubernetes environment that the Wallaroo instance is installed into.
  • Have access to internal corporate DNS configurations that can be updated. A subdomain for the Wallaroo instance will be created through this process.
  • Have the IP address for the Wallaroo instance.
  • Install kubectl into the Kubernetes cluster administrative node.

Wallaroo IP Address Retrieval Methods

Retrieve LoadBalancer IP with kubectl

For most organizations that install Wallaroo into a cloud based Kubernetes cluster such as Micosoft Azure, AWS, etc the external IP address is tied to Wallaroo Loadbalancer service. This can be retrieved with the kubectl command as follows:

  1. Retrieve the external IP address for your Wallaroo instance LoadBalancer. For example, this can be performed through the following kubectl command:

    kubectl get svc  -A
    

    Example Result:

    NAMESPACE     NAME                           TYPE           CLUSTER-IP     EXTERNAL-IP    PORT(S)                                     AGE
    default       kubernetes                     ClusterIP      10.64.16.1     <none>         443/TCP                                     3d19h
    wallaroo      alertmanager                   ClusterIP      10.64.16.48    <none>         9093/TCP                                    2d22h
    wallaroo      api-lb                         LoadBalancer   10.64.30.169   34.173.211.9   80:32176/TCP,443:32332/TCP,8080:30971/TCP   2d22h
    

    In this example, the External-IP of the wallaroo LoadBalancer is 34.173.211.9. A more specific command to retrieve just the LoadBalancer address would be:

    kubectl get svc api-lb -n wallaroo -o jsonpath='{.status.loadBalancer.ingress[0].ip}'
    
    34.173.211.9
    

    This procedure is appropriate for both clusters that are in external or internal mode.

Other Methods

For organizations install Wallaroo other methods, such as Air Gap or Single Node Linux may find the kubectl get svc api-lb command only returns the internal IP address.

Depending on the instance, there are different methods of acquiring that IP address. The links below reference difference sources.

Refer to your Wallaroo support representative if further assistance is needed.

DNS Integration Steps

To integrate the Wallaroo instance IP address with a DNS service:

  1. Create a CA-signed TLS certificate for your Wallaroo domain with the following settings:

    1. Certificate Authority Options:
      1. Use a public Certificate Authority such as Let’s Encrypt or Verisign. In general, you would send a Certificate Signing Request to your CA and they would respond with your certificates.
      2. Use a private Certificate Authority (CA) to provide the certificates. Your organization will have procedures for clients to verify the certificates from the private CA.
      3. Use a Wallaroo certificate and public name server. Contact our CSS team for details.
    2. Subject Domain:
      1. Set the certificate’s Subject CN to your Wallaroo domain.
        1. With Wildcards: To use wildcards, use the wildcard *.{suffix domain}. For example, if the domain suffix is wallaroo.example.com, then the Subject CNs would be:
          1. wallaroo.example.com
          2. *.wallaroo.example.com
        2. If wildcard domains are not desired, use a combination of Subject and Subject Alternative Names to set names as follows:
          1. wallaroo.example.com
          2. api.wallaroo.example.com
          3. jupyter.wallaroo.example.com
          4. keycloak.wallaroo.example.com
    3. Save your certificates.
      1. You should have two files: the TLS Certificate (.crt) and TLS private key (.key). Store these in a secure location - these will be installed into Wallaroo at a later step.
  2. Create DNS the following entries based on the list above for the Wallaroo instance’s IP address, updating the domain name depending on whether there is a prefix or not:

    1. api: A (address) record
    2. jupyter: A (address) record
    3. keycloak: A (address) record
    4. Suffix domain: A record, NS (Name Server) record, SOA (Start Of Authority) record.

    For example:

    Wallaroo DNS Records
  3. Access the Wallaroo Administrative Dashboard in your browser. This can be done either after installation, or through the following command (assuming your Wallaroo instance was installed into the namespace wallaroo). By default this provides the Wallaroo Administrative Dashboard through the URL https://localhost:8080.

    kubectl-kots admin-console --namespace wallaroo
    
  4. From the Wallaroo Dashboard, select Config and set the following:

    1. Networking Configuration
      1. Ingress Mode for Wallaroo Endpoints:
        1. None: Port forwarding or other methods are used for access.
        2. Internal: For environments where only nodes within the same Kubernetes environment and no external connections are required.
        3. External: Connections from outside the Kubernetes environment is allowed.
          1. Enable external URL inference endpoints: Creates pipeline inference endpoints. For more information, see Model Endpoints Guide.
    2. DNS
      1. DNS Suffix (Mandatory): The domain name for your Wallaroo instance.
    3. TLS Certificates
      1. Use custom TLS Certs: Checked
      2. TLS Certificate: Enter your TLS Certificate (.crt file).
      3. TLS Private Key: Enter your TLS private key (.key file).
    4. Other settings as desired.
    Wallaroo DNS Records
  5. Once complete, scroll to the bottom of the Config page and select Save config.

  6. A pop-up window will display The config for Wallaroo Enterprise has been updated.. Select Go to updated version to continue.

  7. From the Version History page, select Deploy. Once the new deployment is finished, you will be able to access your Wallaroo services via their DNS addresses.

To verify the configuration is complete, access the Wallaroo Dashboard through the suffix domain. For example if the suffix domain is wallaroo.example.com then access https://wallaroo.example.com in a browser and verify the connection and certificates.

2 - Model Endpoints Guide

Enable external deployment URLs to perform inferences through API calls.

Wallaroo provides the ability to perform inferences through deployed pipelines via both internal and external inferences URLs. These URLs allow inferences to be performed by submitting data to the internal or external inferences URL, with the inference results returned in the same format as the InferenceResult Object.

Internal URLs are available only through the internal Kubernetes environment hosting the Wallaroo instance.
External URLs are available outside of the Kubernetes environment, such as the public internet. Authentication will be required to connect to these external deployment URLs.

The following process will enable external inference URLs

  1. Enable external URl inference endpoints through the Wallaroo Administrative Dashboard or through helm setup. This can be accessed through the kots or helm as detailed in the Wallaroo Install Guides and the How to Install Wallaroo Enterprise via Helm guides.

    helm users can update the configuration and enable endpoints by setting the apilb\external_inference_endpoints_enabled to true as follows:

    apilb:
        # Required to perform remote inferences either through the SDK or the API
        external_inference_endpoints_enabled: true
    

    For kots users: To access the Wallaroo Administrative Dashboard:

    1. From a terminal shell connected to the Kubernetes environment hosting the Wallaroo instance, run the following kots command:
    kubectl kots admin-console --namespace wallaroo
    

    This provides the following standard output:

      • Press Ctrl+C to exit
      • Go to http://localhost:8800 to access the Admin Console
    

    This will host a http connection to the Wallaroo Administrative Dashboard, by default at http://localhost:8800.

    1. Open a browser at the URL detailed in the step above and authenticate using the console password set as described in the as detailed in the Wallaroo Install Guides.

    2. From the top menu, select Config then verify that Networking Configuration -> Ingress Mode for Wallaroo interactive services -> Enable external URL inference endpoints is enabled.

      Endpoint enabled
    3. Save the updated configuration, then deploy it. Once complete, the external URL inference endpoints will be enabled.

3 - Manage Minio Storage for Models Storage

How to manage model storage in Wallaroo
Targeted Role
Dev Ops

Organizations can manage their ML Model storage in their Wallaroo instances through the MinIO interface included in the standard Wallaroo installation.

The following details how to access and the Wallaroo MinIO service. For full details on using the MinIO service, see the MinIO Documentation site.

All of the steps below require administrative access to the Kubernetes service hosting the Wallaroo instance.

Wallaroo MinIO Model Storage

Wallaroo ML Models are stored in the MinIO bucket model-bucket.

Retrieving the Wallaroo MinIO Password

Access to the Wallaroo MinIO service is password protected. DevOps with administrative access to the Kubernetes cluster hosting the Wallaroo instance can retrieve this password with the following:

  • The kubectl command.
  • The namespace the Wallaroo instance is installed to.

This command takes the following format:

kubectl -n {Wallaroo Namespace} get secret minio -o 'jsonpath={.data.rootPassword}' | base64 -d

For example, if the Wallaroo instance is installed into the namespace wallaroo this command would be:

kubectl -n wallaroo get secret minio -o 'jsonpath={.data.rootPassword}' | base64 -d

Accessing the MinIO Service

Access to the MinIO service in a Wallaroo instance is performed either with the Command Line Interface (CLI), or through a browser based User Interface (UI).

Accessing the MinIO Service Through CLI

Access to the MinIO service included with the Wallaroo instance can be performed with the command line tool mc. For more details, see the MinIO Client documentation.

Installing Minio CLI

The following demonstrates installing the mc command for MacOS and Linux.

Installing for MacOS with Brew

MacOS users who have installed Homebrew can install mc with the following:

brew install minio/stable/mc

Installing for Linux

Linux users can install the MinIO CLI tool mc with the following:

wget https://dl.min.io/client/mc/release/linux-amd64/mc
chmod +x mc
sudo mv mc /usr/local/bin/mc

Port Forward for MinIO CLI Access

To access the Wallaroo MinIO service, use Kubernetes port-forward to connect. By default this is on port 9000. This command requires the following:

  • The kubectl command.
  • The namespace the Wallaroo instance is installed to.

This command is in the following format:

kubectl port-forward services/minio 9000:9000 -n {Wallaroo Namespace}

For example, if the Wallaroo instance is installed to the default namespace wallaroo, this command is:

kubectl port-forward services/minio 9000:9000 -n wallaroo

Show MinIO Disk Usage through CLI

To view the Wallaroo MinIO service through the CLI, the following is required:

  • The kubectl command.
  • The namespace the Wallaroo instance is installed to.
  • The MinIO CLI tool mc.
  • The MinIO password.

Here’s an example showing MinIO disk usage via the CLI for the namespace wallaroo. When prompted for the Secret Key, press Enter for none.

The following script displays the space used for a default installation of Wallaroo in the namespace wallaroo.

#!/bin/bash
if kubectl -n wallaroo get secret minio >& /dev/null; then
    u="$(kubectl -n wallaroo get secret minio -o jsonpath='{ .data.rootUser }' | base64 -d)"
    p="$(kubectl -n wallaroo get secret minio -o jsonpath='{ .data.rootPassword }' | base64 -d)"
    creds="$u $p"
fi

mc alias set --insecure wallaroo http://localhost:9000 $creds; mc du --recursive wallaroo

The output:

Added `wallaroo` successfully.
2.2GiB	22 objects	model-bucket
2.2GiB	22 objects

Accessing the MinIO Service Through the UI

The MinIO service included with the Wallaroo instance can be access through the MinIO user interface. By default this is port 9001.

Port Forward for MinIO UI Access

The MinIO UI port 9001 can be access through the kubectl port-forward command.

This command requires the following:

  • The kubectl command.
  • The namespace the Wallaroo instance is installed to.

This command is in the following format:

kubectl port-forward services/minio-console 9001:9001 -n {Wallaroo Namespace}

For example, to port forward through the default installation namespace wallaroo:

kubectl port-forward services/minio-console 9001:9001 -n wallaroo

Accessing the Wallaroo MinIO UI

Once the port forward command is running, the MinIO UI is access through a browser on port 9001 with the user minio and the MinIO administrative password retrieved through the step Retrieving the Minio Administrative Password.

Wallaroo MinIO Login

Viewing General Storage

General disk usage is displayed through Monitoring->Metrics.

Wallaroo MinIO *Monitoring->Metrics

Viewing ML Model Storage

ML Models stored for Wallaroo are accessed through the bucket model-bucket.

model-bucket

Select Browse to view the contents of the model-bucket. To determine the specific file name, access the Name of the object and view the Tags. The file name is access via the Tag file-name.

Objects can be deleted from this bucket with the Delete option.

Delete Model

4 - Private Containerized Model Container Registry Guide

How to enable private Containerized Model Container Registry with Wallaroo.

Configure Wallaroo with a Private Containerized Model Container Registry

Organizations can configure Wallaroo to use private Containerized Model Container Registry. This allows for the use of containerized models such as MLFlow.

The following steps will provide sample instructions on setting up different private registry services from different providers. In each case, refer to the official documentation for the providers for any updates or more complex use cases.

The following process is used with a GitHub Container Registry to create the authentication tokens for use with a Wallaroo instance’s Private Model Registry configuration.

See the GitHub Working with the Container registry for full details.

The following process is used register a GitHub Container Registry with Wallaroo.

  1. Create a new token as per the instructions from the Creating a personal access token (classic) guide. Note that a classic token is recommended for this process. Store this token in a secure location as it will not be able to be retrieved later from GitHub. Verify the following permissions are set:
    1. Select the write:packages scope to download and upload container images and read and write their metadata.

    2. Select the read:packages scope to download container images and read their metadata (selected when write:packages is selected by default).

    3. Select the delete:packages scope to delete container images.

  • Configure Wallaroo Via Kots

If Wallaroo was installed via kots, use the following procedure to add the private model registry information.

  1. Launch the Wallaroo Administrative Dashboard through a terminal linked to the Kubernetes cluster. Replace the namespace with the one used in your installation.

    kubectl kots admin-console --namespace wallaroo
    
  2. Launch the dashboard, by default at http://localhost:8800.

  3. From the admin dashboard, select Config -> Private Model Container Registry.

  4. Enable Provide private container registry credentials for model images.

  5. Provide the following:

    1. Registry URL: The URL of the Containerized Model Container Registry. Typically in the format host:port. In this example, the registry for GitHub is used.

    2. email: The email address of the Github user generating the token.

    3. username: The username of the Github user authentication to the registry service.

    4. password: The GitHub token generated in the previous steps.

      Private Model Registry setup via KOTS
  6. Scroll down and select Save config.

  7. Deploy the new version.

Once complete, the Wallaroo instance will be able to authenticate to the Containerized Model Container Registry and retrieve the images.

  • Configure Wallaroo Via Helm
  1. During either the installation process or updates, set the following in the local-values.yaml file:

    1. privateModelRegistry:
      1. enabled: true

      2. secretName: model-registry-secret

      3. registry: The URL of the Containerized Model Container Registry. Typically in the format host:port.

      4. email: The email address of the Github user generating the token.

      5. username: The username of the Github user authentication to the registry service.

      6. password: The GitHub token generated in the previous steps.

        For example:

        
        # Other settings - DNS entries, etc.
        
        # The private registry settings
        privateModelRegistry:
           enabled: true
           secretName: model-registry-secret
           registry: "ghcr.io/johnhansarickwallaroo"
           email: "sample.user@wallaroo.ai"
           username: "johnhansarickwallaroo"
           password: "abcdefg"
        
  2. Install or update the Wallaroo instance via Helm as per the Wallaroo Helm Install instructions.

Once complete, the Wallaroo instance will be able to authenticate to the registry service and retrieve the images.

The following process is an example of setting up an Artifact Registry Service with Google Cloud Platform (GCP) that is used to store containerized model images and retrieve them for use with Wallaroo.

Uploading and downloading containerized models to a Google Cloud Platform Registry follows these general steps.

  • Create the GCP registry.

  • Create a Service Account that will manage the registry service requests.

  • Assign appropriate Artifact Registry role to the Service Account

  • Retrieve the Service Account credentials.

  • Using either a specific user, or the Service Account credentials, upload the containerized model to the registry service.

  • Add the service account credentials to the Wallaroo instance’s containerized model private registry configuration.

  • Prerequisites

The commands below use the Google gcloud command line tool, and expect that a Google Cloud Platform account is created and the gcloud application is associated with the GCP Project for the organization.

For full details on the process and other methods, see the Google GCP documentation.

  • Create the Registry

The following is based on the Create a repository using the Google Cloud CLI.

The following information is needed up front:

  • $REPOSITORY_NAME: What to call the registry.
  • $LOCATION: Where the repository will be located. GCP locations are derived through the gcloud artifacts locations list command.
  • $DESCRIPTION: Any details to be displayed. Sensitive data should not be included.

The follow example script will create a GCP registry with the minimum requirements.

REPOSITORY_NAME="YOUR NAME"
LOCATION="us-west1"
DESCRIPTION="My amazing registry."

gcloud artifacts repositories create REPOSITORY \
    --repository-format=docker \
    --location=LOCATION \
    --description="$DESCRIPTION" \
    --async
  • Create a GCP Registry Service Account

The GCP Registry Service Account is used to manage the GCP registry service. The steps are details from the Google Create a service account guide.

The gcloud process for these steps are:

  1. Connect the gcloud application to the organization’s project.

    $PROJECT_ID="YOUR PROJECT ID"
    gcloud config set project $PROJECT_ID
    
  2. Create the service account with the following:

    1. The name of the service account.
    2. A description of its purpose.
    3. The name to show when displayed.
    SA_NAME="YOUR SERVICE ACCOUNT NAME"
    DESCRIPTION="Wallaroo container registry SA"
    DISPLAY_NAME="Wallaroo the Roo"
    
    gcloud iam service-accounts create $SA_NAME \
    --description=$DESCRIPTION \
    --display-name=$DISPLAY_NAME
    
  • Assign Artifact Registry Role

Assign one or more of the following accounts to the new registry role based on the following criteria, as detailed in the Google GCP Repository Roles and Permissions Guide.

  • For pkg.dev domains.
RoleDescription
Artifact Registry Reader (roles/artifactregistry.reader)View and get artifacts, view repository metadata.
Artifact Registry Writer (roles/artifactregistry.writer)Read and write artifacts.
Artifact Registry Repository Administrator (roles/artifactregistry.repoAdmin)Read, write, and delete artifacts.
Artifact Registry Administrator (roles/artifactregistry.admin)Create and manage repositories and artifacts.
  • For gcr.io repositories.
RoleDescription
Artifact Registry Create-on-push Writer (roles/artifactregistry.createOnPushWriter)Read and write artifacts. Create gcr.io repositories.
Artifact Registry Create-on-push Repository Administrator (roles/artifactregistry.createOnPushRepoAdmin)Read, write, and delete artifacts. Create gcr.io repositories.

For this example, we will add the Artifact Registry Create-on-push Writer to the created Service Account from the previous step.

  1. Add the role to the service account, specifying the member as the new service account, and the role as the selected role. For this example, a pkg.dev is assumed for the Artifact Registry type.

    
    # for pkg.dev
    ROLE="roles/artifactregistry.writer"
    
    # for gcr.io 
    #ROLE="roles/artifactregistry.createOnPushWriter
    
    gcloud projects add-iam-policy-binding \
        $PROJECT_ID \
        --member="serviceAccount:$SA_NAME@$PROJECT_ID.iam.gserviceaccount.com" \
        --role=$ROLE
    
  • Authenticate to Repository

To push and pull image from the new registry, we’ll use our new service account and authenticate through the local Docker application. See the GCP Push and pull images for details on using Docker and other methods to add artifacts to the GCP artifact registry.

  • Set up Service Account Key

To set up the Service Account key, we’ll use the Google Console IAM & ADMIN dashboard based on the Set up authentication for Docker, using the JSON key approach.

  1. From GCP console, search for IAM & Admin.

  2. Select Service Accounts.

    Service account page
  3. Select the service account to generate keys for.

  4. Select the Email address listed and store this for later steps with the key generated through this process.

    Service account email
  5. Select Keys, then Add Key, then Create new key.

    Create service account key
  6. Select JSON, then Create.

  7. Store the key in a safe location.

  • Convert SA Key to Base64

The key file downloaded in Set up Service Account Key needs to be converted to base64 with the following command, replacing the locations of KEY_FILE and KEYFILEBASE64:

KEY_FILE = ~/.gcp-sa-registry-keyfile.json
KEYFILEBASE64 = ~/.gcp-sa-registry-keyfile-b64.json
base64 -i $KEY_FILE -o $KEYFILEBASE64
  • Authenticate with Docker
  1. Launch Docker.

  2. Run the following command using the base64 version of the key file.

    cat $KEYFILEBASE64 | docker login -u _json_key_base64 --password-stdin https://$LOCATION-docker.pkg.dev
    

    If successful, the following will be returned.

    Login Succeeded.

  3. Tag the statsmodel and postprocess containers based on the repository used for the container registry. The GCP Registry format is $LOCATION-docker.pkg.dev/$PROJECT_ID/$REPOSITORY/$IMAGE. In this example, it is us-west1-docker.pkg.dev/wallaroo-dev-253816/doc-test-registry/, with the images mlflow-postprocess-example and mlflow-statsmodels-example.

    1. Get the internal name through docker images.

      docker image list
      
      REPOSITORY                                                           TAG       IMAGE ID       CREATED        SIZE
      mlflow-postprocess-example                                           2023.1    ff121d335e24   5 months ago   3.28GB
      mlflow-statsmodels-example                                           2023.1    4c23cac0a7b1   5 months ago   3.34GB
      
    2. Tag the images with the repository address. Note the repository must be in lowercase.

    docker tag mlflow-postprocess-example:2023.1 us-west1-docker.pkg.dev/wallaroo-dev-253816/doc-test-registry/mlflow-postprocess-example:2023.1
    
    docker tag mlflow-statsmodels-example:2023.1 us-west1-docker.pkg.dev/wallaroo-dev-253816/doc-test-registry/mlflow-statsmodels-example:2023.1
    
    1. Verify with docker images. Note that the new tags match the same Image ID as the original tags.
    docker images
    
    REPOSITORY                                                                                 TAG       IMAGE ID       CREATED        SIZE
    mlflow-postprocess-example                                                                 2023.1    ff121d335e24   5 months ago   3.28GB
    us-west1-docker.pkg.dev/wallaroo-dev-253816/doc-test-registry/mlflow-postprocess-example   2023.1    ff121d335e24   5 months ago   3.28GB
    mlflow-statsmodels-example                                                                 2023.1    4c23cac0a7b1   5 months ago   3.34GB
    us-west1-docker.pkg.dev/wallaroo-dev-253816/doc-test-registry/mlflow-statsmodels-example   2023.1    4c23cac0a7b1   5 months ago   3.34GB
    
  4. Push the containers to the registry. This may take some time depending on the speed of your connection. Wait until both are complete.

    docker push us-west1-docker.pkg.dev/wallaroo-dev-253816/doc-test-registry/mlflow-postprocess-example:2023.1
    
    docker push us-west1-docker.pkg.dev/wallaroo-dev-253816/doc-test-registry/mlflow-statsmodels-example:2023.1
    
  5. Verify the uploaded containers are available. From the GCP console, search for “Artifact Registry”, then select the registry.

With the packages published, they will be available to a Wallaroo instance.

  • Configure Wallaroo Private Registry for GCP Registry

The following process demonstrates how to configure a Wallaroo Instance to use the GCP Registry created and used in previous steps.

  • Prerequisites

Before starting, the following will be needed:

  • The GCP Registry service full URL as created from the Create the Registry process. This can be retrieved through the gcloud command:

    gcloud artifacts repositories describe $REPOSITORY_NAME --location=$LOCATION
    
  • The private registry service account email address. This is retrieved as described in the process Set up Service Account Key.

  • The private registry service account credentials in base64. These were created in the step Convert SA Key to Base64. These can be displayed directly from the base Service Account credentials file with:

    cat $KEYFILEBASE64
    
  • Configure for Kots Installations

For kots based installations of Wallaroo, use the following procedure. These are based on the Wallaroo Install Guides.

  1. Log into the Wallaroo Administrative Dashboard from a Kubernetes terminal with administrative access to the Wallaroo instance with the following command, replacing the namespace wallaroo with the one where the Wallaroo instance is installed.

    kubectl kots admin-console --namespace wallaroo
    
  2. Select Config, then Private Model Container Registry.

  3. Enable Provide private container registry credentials for model images.

  4. Update the following fields:

    Private registry settings
    1. Registry URL: Insert the full path of your registry. The GCP Registry format is $LOCATION-docker.pkg.dev/$PROJECT_ID/$REPOSITORY/$IMAGE. In this example, it is us-west1-docker.pkg.dev/wallaroo-dev-253816/doc-test-registry/.
    2. Email: The email address of the service account used with the registry service.
    3. User: Set to _json_key_base64.
    4. Password: Set to the private registry service account credentials in base64.
  5. Scroll to the bottom and select Save Config.

  6. When the update module appears, select Go to updated version.

  7. Wait for the preflight checks to completed, then select Deploy.

  • Configure Wallaroo Via Helm
  1. During either the installation process or updates, set the following in the local-values.yaml file:

    1. privateModelRegistry:
      1. enabled: true

      2. secretName: model-registry-secret

      3. registry: Insert the full path of your registry. The GCP Registry format is $LOCATION-docker.pkg.dev/$PROJECT_ID/$REPOSITORY/$IMAGE. In this example, it is us-west1-docker.pkg.dev/wallaroo-dev-253816/doc-test-registry/.

      4. email: The email address of the service account used with the registry service.

      5. username: Set to _json_key_base64.

      6. password: Set to the private registry service account credentials in base64.

        For example:

        
        # Other settings - DNS entries, etc.
        
        # The private registry settings
        privateModelRegistry:
        enabled: true
        secretName: model-registry-secret
        registry: "YOUR REGISTRY URL:YOUR REGISTRY PORT"
        email: "serviceAccount:doc-test@wallaroo-dev.iam.gserviceaccount.com"
        username: "_json_key_base64_"
        password: "abcde"
        
  2. Install or update the Wallaroo instance via Helm as per the Wallaroo Helm Install instructions.

Once complete, the Wallaroo instance will be able to authenticate to the registry service and retrieve the images.

Setting Private Registry Configuration in Wallaroo

Configure Via Kots

If Wallaroo was installed via kots, use the following procedure to add the private model registry information.

  1. Launch the Wallaroo Administrative Dashboard through a terminal linked to the Kubernetes cluster. Replace the namespace with the one used in your installation.

    kubectl kots admin-console --namespace wallaroo
    
  2. Launch the dashboard, by default at http://localhost:8800.

  3. From the admin dashboard, select Config -> Private Model Container Registry.

  4. Enable Provide private container registry credentials for model images.

  5. Provide the following:

    1. Registry URL: The URL of the Containerized Model Container Registry. Typically in the format host:port. In this example, the registry for GitHub is used. NOTE: When setting the URL for the Containerized Model Container Registry, only the actual service address is needed. For example: with the full URL of the model as ghcr.io/wallaroolabs/wallaroo_tutorials/mlflow-statsmodels-example:2022.4, the URL would be ghcr.io/wallaroolabs.
    2. email: The email address of the user authenticating to the registry service.
    3. username: The username of the user authentication to the registry service.
    4. password: The password of the user authentication or token to the registry service.
  6. Scroll down and select Save config.

  7. Deploy the new version.

Once complete, the Wallaroo instance will be able to authenticate to the Containerized Model Container Registry and retrieve the images.

Configure via Helm

  1. During either the installation process or updates, set the following in the local-values.yaml file:

    1. privateModelRegistry:

      1. enabled: true
      2. secretName: model-registry-secret
      3. registry: The URL of the private registry.
      4. email: The email address of the user authenticating to the registry service.
      5. username: The username of the user authentication to the registry service.
      6. password: The password of the user authentication to the registry service.

      For example:

      
      # Other settings - DNS entries, etc.
      
      # The private registry settings
      privateModelRegistry:
        enabled: true
        secretName: model-registry-secret
        registry: "YOUR REGISTRY URL:YOUR REGISTRY PORT"
        email: "YOUR EMAIL ADDRESS"
        username: "YOUR USERNAME"
        password: "Your Password here"
      
  2. Install or update the Wallaroo instance via Helm as per the Wallaroo Helm Install instructions.

Once complete, the Wallaroo instance will be able to authenticate to the registry service and retrieve the images.

5 - Wallaroo Support Bundle Generation Guide

How to generate support bundles to troubleshoot Wallaroo

To track potential issues, Wallaroo provides a method to create a support bundle: a collection of logs, configurations, and other information that is submitted to Wallaroo support staff to determine where an issue may be and offer a correction.

Support bundles are generated depending on the method of installation:

  • kots: If Wallaroo was installed via kots, the support bundle is generated through the Wallaroo Administrative Dashboard.
  • helm: If Wallaroo was installed via helm, the support bundle is generated through a command line process.

Generating via Kots

At any time, the administration console can create troubleshooting bundles for Wallaroo technical support to assess product health and help with problems. Support bundles contain logs and configuration files which can be examined before downloading and transmitting to Wallaroo. The console also has a configurable redaction mechanism in cases where sensitive information such as passwords, tokens, or PII (Personally Identifiable Information) need to be removed from logs in the bundle.

Status Ready

To manage support bundles:

  1. Log into the administration console.
  2. Select the Troubleshoot tab.
  3. Select Analyze Wallaroo.
  4. Select Download bundle to save the bundle file as a compressed archive. Depending on your browser settings the file download location can be specified.
  5. Send the file to Wallaroo technical support.

At any time, any existing bundle can be examined and downloaded from the Troubleshoot tab.

Generating via Helm

If issues are detected in the Wallaroo instance, a support bundle file is generated using the support-bundle.yaml file provided by the Wallaroo support representative.

This creates a collection of log files, configuration files and other details into a .tar.gz file in the same directory as the command is run from in the format support-bundle-YYYY-MM-DDTHH-MM-SS.tar.gz. This file is submitted to the Wallaroo support team for review.

This support bundle is generated through the following command:

kubectl support-bundle support-bundle.yaml --interactive=false