Which shape to deploy
Three shapes, and the choice is not made on the number of users: it is made on what you accept to lose when a machine goes, and on how many organisations the gateway serves.
One gateway, community
One container, one volume, nothing beside it. The embedded store holds the routes, the accounts, the roles, the sealed vault and the certificates. That is the whole gateway for one organisation, free, production included.
What it does not do is survive the loss of its machine: a volume does not follow a container from one host to another. Back up the volume and you have backed up the gateway.
# Docker
curl -fsSLO https://meerkat.softwarity.dev/deploy/docker-compose.yml
MEERKAT_ADMIN_PASSWORD='choose-one' docker compose up -d
# Kubernetes
helm repo add meerkat https://meerkat.softwarity.dev/deploy
helm install meerkat meerkat/meerkat -f https://meerkat.softwarity.dev/deploy/values-ce-one-node.yaml \
--set admin.password='choose-one'
One gateway, Enterprise
Same shape, Enterprise image: several organisations, the corporate directories, and the developer tunnel. That one listens on 22222, and it is one more port to publish where your developers reach it and nowhere else. It does not speak HTTP: it is SSH, and what the gateway checks there is the public key each developer deposited on their account. See Development mode.
The Enterprise image lives on a private registry, hence a pull secret:
kubectl create secret docker-registry ghcr \
--docker-server=ghcr.io --docker-username=YOU --docker-password=TOKEN
helm install meerkat meerkat/meerkat -f https://meerkat.softwarity.dev/deploy/values-ee-one-node.yaml \
--set admin.password='choose-one'
To try it first, the evaluation image installs the same shape with no pull secret: -f https://meerkat.softwarity.dev/deploy/values-eval-one-node.yaml.
Three gateways, Enterprise
What makes three pods ONE gateway is the database they share, and nothing else: the nodes never address each other. Sessions live there too, so there is no affinity to ask of the load balancer, and a rolling update takes nobody's session with it.
There is no volume any more: what the gateway knows is rows. But the vault's master key has to be the same on every pod, or a secret sealed by one is unreadable by the others.
kubectl create secret generic meerkat-state \
--from-literal=database-url='postgres://meerkat:PASSWORD@postgres:5432/meerkat?sslmode=require' \
--from-literal=vault-key="$(openssl rand -hex 32)"
helm install meerkat meerkat/meerkat -f https://meerkat.softwarity.dev/deploy/values-ee-cluster.yaml \
--set admin.password='choose-one'
The same cluster on the evaluation image, to try it before buying it: -f https://meerkat.softwarity.dev/deploy/values-eval-cluster.yaml, with the same Secret.
On Swarm, the same shape deploys with the stack below. The three values are interpolated by Swarm at deploy time, from the shell that deploys: they are never in the file.
export MEERKAT_DATABASE_URL='postgres://meerkat:PASSWORD@postgres:5432/meerkat?sslmode=require'
export MEERKAT_VAULT_KEY="$(openssl rand -hex 32)" # once, then keep it
export MEERKAT_ADMIN_PASSWORD='choose-one'
docker stack deploy -c stack.swarm.yml meerkat
The stack also runs a read-only proxy of the Docker socket on every node (docker-proxy, mode: global), on a network only the gateway joins. It lets reads through and refuses every write. Through it the route editor offers the Swarm services, and the Routes list shows each target's ready replicas and image, from the events of every node: a container's events come only from the node it runs on.
The files
These are the repository's own, copied here on every publication of the site: what you download is what the released version deploys.
| File | For |
|---|---|
| index.yaml | The Helm repository: helm repo add meerkat https://meerkat.softwarity.dev/deploy. It lists every released version: helm install takes the newest, and --version 1.9.0 (or a version pinned in Argo CD, Flux or Terraform) stays installable after the next release |
| meerkat-chart.tgz | The Helm chart, installed as it is |
| values-ce-one-node.yaml | One community gateway on its volume |
| values-ee-one-node.yaml | One Enterprise gateway, developer tunnel open |
| values-ee-cluster.yaml | Three Enterprise gateways on a shared PostgreSQL |
| values-eval-one-node.yaml | One gateway on the evaluation image, developer tunnel open |
| values-eval-cluster.yaml | Three gateways on the evaluation image, on a shared PostgreSQL |
| docker-compose.yml | One community gateway, one command |
| docker-compose.ee.yml | One Enterprise gateway with the tunnel |
| stack.swarm.yml | Three gateways on Docker Swarm |
The repository distributes the chart, not the images: the cluster pulls those itself, from the registry the values name. There is one chart for both editions, and the edition is the image:
- Community:
docker.io/softwarity/meerkat, public - the chart's default, nothing to add. - Enterprise:
ghcr.io/softwarity/meerkat, private - a pull secret holding the access you were given, named inimage.pullSecrets. Thevalues-ee-*files set both; that is the whole difference at install time. - Evaluation:
docker.io/softwarity/meerkat:eval, public - everything Enterprise does, with an evaluation notice, not for production. Thevalues-eval-*files set it, with no pull secret.
Every file is commented line by line: what a variable does, and what it costs to forget it. The detail of each variable is on One gateway, and the Kubernetes manifests written out in full are on Kubernetes cluster.