high availability / resiliency / multi-node deployments?

[Wolfspyre]

Has anyone configured Chevereto to be HAish?

My thought was essentially provisioning an active/standby mysql vm pair to pull the db out of the stack.

Then have two frontend web nodes each running a php container (one for each 'site' per vm essentially) and using haproxy on opnsense to LB them...

obvs, the most obvious problem that I see with this is storage/state/sync... either something needs to manage storage synchronization outside chev; (ie/drbd/etcd.) or using shared storage (nfs/iscsi) .... or use external-storage-only (ie s3)....

this isn't urgent; I'm just exploring options and figured I'd ask here before undertaking the task of inventing the "round friction reducer and transitive locomotion device" ... only to discover that A) it already exists, and B) its proper name is "Wheel" (which is kinda a silly name but that's a different topic entirely)

 

[Rodolfo]

Chevereto is a 12-factor app, so setting it up for high availability is straightforward.

You can use Redis for shared sessions and external storage (like S3) for handling files. With those in place, you'll have everything you need to support your HA architecture.

 

[Barry]

You can use Redis for shared sessions

Is this part documented somwhere?

 

[Rodolfo]

@Barry
Yes, https://v4-docs.chevereto.com/application/configuration/environment.html#session-variables

 

[Wolfspyre]

hm;
the challenge here is it’s not clear what a redis configuration might look like.

this shows one can toggle the variable to “use redis” but …. erm…. how? 🙂

 

[Rodolfo]

@Wolfspyre

CHEVERETO_SESSION_SAVE_HANDLER = "redis"
CHEVERETO_SESSION_SAVE_PATH = "tcp://your-server-ip:6379?auth=securepassword"

 

[Wolfspyre]

https://v4-docs.chevereto.com/application/configuration/environment.html:

it'd be helpful if that was shown... The only example in the docs:

Environment variables for the session driver.

Variable	Example
CHEVERETO_SESSION_SAVE_HANDLER	files, redis
CHEVERETO_SESSION_SAVE_PATH	/tmp

 

[Rodolfo]

Feel free to contribute with the documentation.

GitHub - chevereto/v4-docs: Documentation for Chevereto V4

Documentation for Chevereto V4. Contribute to chevereto/v4-docs development by creating an account on GitHub.

github.com

 

[Wolfspyre]

after reading this, I'd forked the docs to do so; but I see you've already pushed a tiny fix including a redis example;
That's really cool of you!

Thanks! Much appreciated!

Not NOW obviously; but do you think it would be sensible to add the envvars 'CHEVERETO_DOMAIN_NAME' and 'CHEVERETO_FQDN'
and ultimately transition from "CHEVERETO_HOSTNAME" to "CHEVERETO_FQDN" as the key to consume....

(I ask, as hostname typically refers to node shortname; so, using the label "hostname" as the mechanism for the user to provide chevereto with its' fqdn is prolly an antipattern in the long-term)

 

[Rodolfo]

but do you think it would be sensible to add the envvars 'CHEVERETO_DOMAIN_NAME' and 'CHEVERETO_FQDN'
and ultimately transition from "CHEVERETO_HOSTNAME" to "CHEVERETO_FQDN" as the key to consume....

FQDN applies only to domain names, a hostname is more universal as it applies to machine label and a domain name can be also a hostname. With a hostname you can serve at potato, ip, whatever. That's why we use a more generic term.

 

[SunnyBlueSkies]

FQDN applies only to domain names, a hostname is more universal as it applies to machine label and a domain name can be also a hostname. With a hostname you can serve at potato, ip, whatever. That's why we use a more generic term.

Although in real world talk, the average person wouldn't completely understand this but instead domain name as a good idea.