Skip to main content
Version: 0.4.0-beta

Wizard-Client Web UI Deployment

In addition to CLI, Wizard-Client also provides a web interface. This web server can be deployed using a helm chart on Kubernetes.

Requirements​

Wizard-Client WebUI Installation​

Assuming that

  • Website address is wizard-client-webui.example.com
  • Load Balancer is used for exposing website externally, and the load balancer ip is 192.168.132.251
  • Cluster-Wizard is deployed in Kubernetes namespace cluster-wizard and accessible on 192.168.100.100:50001
  • A server CA is provided in secret name cluster-wizard-server-ca
note

The URL needs to be a valid DNS entry.

Preparing Secret​

Wizard-Client WebUI requires a secret referencing the server’s Certificate Authority (Cluster-Wizard CA) if it is not trusted — such as in cases where it's self-signed. This is optional, but it becomes required when the Cluster Wizard’s CA is not trusted.

kubectl create namespace wizard-client
kubectl create secret generic cluster-wizard-server-ca -n wizard-client \
    --from-file=ca.crt=[server ca]

The server CA could be obtained from Cert Manager if it is used for Cluster-Wizard certificates.

kubectl get secret server-ca -n cluster-wizard -o jsonpath='{.data.ca\.crt}' | base64 -d > server-ca.crt
kubectl create secret generic cluster-wizard-server-ca -n wizard-client \
    --from-file=ca.crt=server-ca.crt

Helm Installation (Quick Start)​

A matching helm chart version for Wizard-Client 0.4.x versions is 0.1.0.

helm repo add cluster-wizard https://charts.cluster-wizard.com/  
helm repo update cluster-wizard  
helm search repo cluster-wizard/wizard-client-webui --versions
helm fetch cluster-wizard/wizard-client-webui --version 0.1.0 --untar
helm -n wizard-client install wizard-client-webui ./wizard-client-webui --values ./override.yaml

Helm values​

Below is a minimal set of helm values needed to deploy

  • configMap.backendUrl: backend address, with backPort if it's same as frondEndUrl
  • configMap.frontendUrl: frontend website address
  • configMap.clusterWizardHost: "&clusterWizardHost" is used for etcHost.clusterWizardHost, host name that will be reached by Wizard-Client
  • configMap.clusterWizardPort: Cluster-Wizard port that will be reached by Wizard-Client
  • etcHost.clusterWizardIP: Cluster-Wizard host IP address
  • etcHost.clusterWizardHost: "*clusterWizardHost" is referring "&clusterWizardHost" in configMap.clusterWizardHost
  • clusterWizardCASecretName: secret name for Cluster-Wizard server CA if it is used
  • expose.type: loadBalancer is used here and other types are ingress, clusterIP and nodePort
  • configuration for loadBalancer
    • expose.loadBalancer.IP: external IP address for Webui
    • expose.loadBalancer.ports.frontPort : service port for frontend
    • expose.loadBalancer.ports.backPort : service port for backend

The override yaml file will be like

---
configMap:
  backendUrl: "wizard-client-webui.example.com:23051"
  frontendUrl: "wizard-client-webui.example.com"

  clusterWizardHost: &clusterWizardHost "cluster-wizard"
  clusterWizardPort: "50001"

etcHost:
  addClusterWizard: true
  clusterWizardIP: "192.168.100.100"
  clusterWizardHost: *clusterWizardHost

clusterWizardCASecretName: "cluster-wizard-server-ca"

expose:
  type: loadBalancer
  loadBalancer:
    IP: "192.168.132.251"
    ports:
      frontPort: 25080
      backPort: 23051

Next Steps​

To access the Wizard-Client Webui, a user certificate and key are required. The admin certifcate and key would be generated from Cluster-Wizard deployment and obtained from the Kubernete's secret admin-cred.

kubectl get secret admin-cred -n cluster-wizard -o jsonpath='{.data.cert}' | base64 -d > admin-cert.crt
kubectl get secret admin-cred -n cluster-wizard -o jsonpath='{.data.private_key}' | base64 -d > admin-private.key

Various Expose Methods​

There are a few more methods for exposing services: ingress, proxy server (with clusterIP service) and nodePort.

Ingress​

Kubernetes Ingress is an API object that manages external access to services within a cluster, typically HTTP and HTTPS traffic.

In the helm chart, rewrite rules was added such that backend server URL is in a form of [frontend server URL]/backend. These annotations are for Nignx and HAProxy ingress classes. If a different ingress class is used, appropriate annotations need to be added.

The following example override yaml file is for the case where

  • haproxy ingress class is used
  • A cert manager's cluster issuer (named selfsigned-cluster-issuer) is used for automatic certificate generation
  • The complete frontend server URL is https://wizard-client-webui.example.com
configMap:
  backendUrl: "wizard-client-webui.example.com/backend"
  frontendUrl: "wizard-client-webui.example.com"

expose:
  type: ingress
  ingress:
    tls:
      enabled: true
      clusterIssuer: "selfsigned-cluster-issuer"
      certSource: "secret"
      secretName: "wizard-client-webui.example.com"
    host: wizard-client-webui.example.com
    className: "haproxy"

For http service, remove the tls section.

Over Proxy Server​

A proxy server is an intermediary server that sits between clients and other servers. It acts as a gateway, receiving requests from clients and forwarding them to destination servers, then returning the responses back to the clients.

In Kubernetes clusters, an application proxy server (such as Nginx Proxy server and HAProxy) is often used. We can use a proxy server to expose wizard-client-webui servers.

Depending on how a proxy server is configured, override is similar either to that of ingress or to that of load balancer. If the proxy server provides TLS communication, tlsOverProxy.enabled should be true. The FrontendURL and BackendURL should be set accordingly.

The following example shows how to specify value override when

  • tls commuincation is provided by a proxy server
  • the same rewrite rule is implemented in a proxy server
---
configMap:
  backendUrl: "wizard-client-webui.example.com/backend"
  frontendUrl: "wizard-client-webui.example.com"

expose:
  tlsOverProxy:
    enabled: true

This will create a Kubernetes service object of clusterIP type. A proxy server forwards requests to the frontend/backend server to this service.

Node Port​

NodePort is a type of Kubernetes Service that exposes an application running in a cluster by allocating a specific port on every node in the cluster. It's one of the primary ways to make services accessible from outside the Kubernetes cluster.

NodePort value override is similar to that of load balancer. A simple example is shown below.

---
configMap:
  backendUrl: "wizard-client-webui.example.com:30003"
  frontendUrl: "wizard-client-webui.example.com:30002"

expose:
  internalTLS:
    enabled: true
    secretName: "tls-secret"
  type: nodePort
info

To add a host, a token for node-wizard is necessary. This token will be printed when node-wizard is installed. To retrieve this token, run the following command.

sudo /root/bin/node_wizard/node-wizard --token

To attach a PCI device, its PCI address needs to be added to allowed (PCI address) list.

# Add a PCI address to the allowed list
sudo /root/bin/node_wizard/node-wizard --add-allowed [PCI address]
# To print the list
sudo /root/bin/node_wizard/node-wizard --list-allowed

To prevent a bridge to be attached, the network device/bridge needs to be added to disallowed list

# Add a Device/Bridge to the disallowed list
sudo /root/bin/node_wizard/node-wizard --add-disallowed [network device/bridge]
# To print the list
sudo /root/bin/node_wizard/node-wizard --list-disallowed