mait.sh1.132.1

Private beta: features and content may change. No warranty; use at your own risk.

Install VaaS Server

Receive the relay's files, deploy it as a container or with the Helm chart, check that it answers, and point your applications at it in place of the relay MAIT hosts.

Beta
OverviewInstallWorkflowsOperateCustomizeAll components
Steps

Six steps from the supplied files to two applications paired through your own relay.

Deploying the relay, proving that clients can reach it, proving that protected requests are accepted and proving that your applications pair are separate steps, and success at one does not prove the next. Check each result before moving on. The full procedures are in Run with Docker and Run on Kubernetes.

  1. Step 1 of 6

    Receive your files

    The MAIT Team supplies four things with your on-premise setup. The server identity file lets clients confirm they reached your relay's hostname. The server trust file is passed to curl as --cacert on verification hosts. The account-access setting is the address the relay uses to confirm your accounts. Credential files, each issued for one account, identify your applications and carry their permissions.

    You need a Linux amd64 host with Docker, or a Kubernetes cluster with Helm 3 and a storage class that provides ReadWriteOnce volumes. You also need a hostname for the relay that matches the identity file, inbound TCP on the relay port from every peer, and a data volume the service user can write. Run exactly one instance per database.

    What you get

    The identity file, the trust file, the account-access setting and one credential file per holder, from a source you can name.

  2. Deploy as a container
    $ sudo install -d -o 1004 -g 1004 /srv/vaas/data
    $ sudo install -d /srv/vaas/tls
    $ sudo install -o 1004 -g 1004 -m 0600 relay-bundle.pem /srv/vaas/tls/tls.crt
    $ docker run -d --name vaas-server --restart unless-stopped \
    $ -p 9443:9443 \
    $ -v /srv/vaas/tls/tls.crt:/etc/vaas/tls/tls.crt:ro \
    $ -v /srv/vaas/data:/var/lib/vaas \
    $ --env-file /srv/vaas/access.env \
    $ -e MAIT_CHANNEL=<channel> \
    $ --no-healthcheck \
    $ <image>:<version>
    Deploy with the Helm chart
    $ kubectl create namespace vaas
    $ kubectl -n vaas create secret generic vaas-server-tls --from-file=tls.crt=relay-bundle.pem
    $ helm install vaas-server ./vaas-server-chart -n vaas -f vaas-values.yaml
    $ kubectl -n vaas rollout status deployment/vaas-server
    vaas-values.yaml
    image:
  tag: "<version>"
channel: <channel>   # the channel your on-premise setup names
liveAccess:
  url: "<account-access address from your on-premise setup>"
persistence:
  size: 2Gi
ingressRoute:
  tcp:
    hostSni: relay.example.com
    Step 2 of 6

    Deploy the relay

    As a container, restrict the identity file to the service user and start the image on port 9443. Start the container with --no-healthcheck and check health from a client machine (step 4). Set MAIT_CHANNEL to the channel your on-premise setup names (stable, beta or edge); for this relay it only labels metrics.

    On Kubernetes, store the identity file in the secret the chart mounts (the key must be tls.crt), write the values you change, and install.

    Keep replicaCount: 1; the chart refuses higher values. The route must pass TLS through to the relay unchanged: a proxy that ends TLS in front of it makes every protected request fail.

    What you get

    One running relay, listening on its TLS port, with its database on persistent storage.

  3. Read the log
    docker logs --tail 20 vaas-server
kubectl -n vaas logs deploy/vaas-server --tail 20
    Step 3 of 6

    Read the startup log

    On first start the relay creates its database and reports the address it listens on. A missing or incomplete identity file stops it with an error that names the file.

    What you get

    A line stating the listening address, and no error about the identity file or the database.

  4. Check health
    $ curl --fail --cacert server-trust.pem https://relay.example.com:9443/health
    What it prints
    {"status":"ok","version":"<version>","commit":"<build>"}
    Step 4 of 6

    Check health

    Health needs no credentials, so it shows only that the process runs and that its TLS port answers.

    What you get

    A response with status, version and commit.

  5. Authenticated check
    $ curl --fail --cacert server-trust.pem --cert client.pem --key client.pem \
    $ https://relay.example.com:9443/api/v1/sessions
    What it prints
    {"sessions":[]}
    Step 5 of 6

    Check access with a credential

    A session list proves that credentials, the account-access setting and the database work together. Use a credential that may list sessions; an empty list is the right answer on a new relay.

    A 503 while health is green means the account-access setting is missing or its address is unreachable from the relay.

    What you get

    {"sessions":[]}, or a status that tells you which setting to repair.

  6. Step 6 of 6

    Point your applications at the relay

    Give each application the relay address wss://relay.example.com:9443, the server trust file and its own credential file. Pairing is done by applications that speak the relay protocol, so test with them: start the first, then the second with the same fresh token, and confirm that a harmless message arrives both ways. Workflows walks through it.

    What you get

    Two applications paired through your relay, and one entry in the session list while they are connected.

Next

Where to go next.

  • Workflows, for pairing, sessions and upgrades