Skip to content

Step 4: replicas

Replicas need a database that every host reaches. On SQLite, the layout is refused, with the next step named:

$ WEB_INSTANCES=3 myxo check layouts/app.toml
layouts/app.toml: process web cannot run 3 instances on SQLite, which book and the layout's database use: move it to PostgreSQL first (step 2 of the continuum: a postgresql:// URL)

On PostgreSQL, the export runs three replicas of web:

$ export DATABASE_URL=postgresql://guestbook@db.example.org/guestbook
$ WEB_INSTANCES=3 myxo export layouts/app.toml kubernetes \
    --name guestbook --image registry.example.org/guestbook:1 --out k8s
k8s/migrate.json
k8s/app.json
k8s/env.example

Any process can take a count the same way: an instances setting that reads a variable of your choice, as WEB_INSTANCES does here. Apply the manifests as in step 3; only app.json changed:

$ kubectl apply -f k8s/app.json
$ kubectl rollout status deployment/guestbook-web

A change of the count alone leaves the running pods in place, so the application stays up while the new ones start. The manifests read the environment from a secret, guestbook-env, which the operator creates from env.example. Each pod is ready once its services run and its database answers: Kubernetes probes /readyz on the process's own listener, its url, which the public port does not serve. A replica that cannot reach PostgreSQL stops receiving calls. Moderation's consumer group holds whatever the number of workers: one of them handles the events at a time, and another takes over within seconds if it dies.

Further