• Welcome to the Chevereto user community!

    Here users from all over the world gather around to learn the latest about Chevereto and contribute with ideas to improve the software.

    Please keep in mind:

    • This community is user driven. Be polite with other users.
    • Is required to purchase a Chevereto license to participate in this community (doesn't apply to Pre-sales).
    • Purchase a Pro Subscription to get access to active software support and faster ticket response times.

high availability / resiliency / multi-node deployments?

Wolfspyre

Wolfspyre

Chevereto Member
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)
 
Sort by date Sort by votes
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.
 
Upvote 0 Downvote
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? 🙂
 
Upvote 0 Downvote
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)
 
Upvote 0 Downvote
Wolfspyre said:
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....
Click to expand...
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.
 
Upvote 0 Downvote
Rodolfo said:
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.
Click to expand...
Although in real world talk, the average person wouldn't completely understand this but instead domain name as a good idea.
 
Upvote 0 Downvote
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.
Click to expand...

Hm. sorta. I went RFC diving.. and you are correct
TLDR it says
Any label may be used so long as in sum it’s <255 chars.
Click to expand...

I think my confusion is around the fact that in common terminology, hostname refers to node shortname, whereas fqdn is explicitly the full name.

What I propose, is adding two new envvars:

  • 'CHEVERETO_DOMAIN_NAME'
  • 'CHEVERETO_FQDN'

in addition to the existing 'CHEVERETO_HOSTNAME'

internally, have 'CHEVERETO_HOSTNAME' + 'CHEVERETO_DOMAIN_NAME' = 'CHEVERETO_FQDN'
and have chevereto prefer to consume 'CHEVERETO_FQDN' as the fully-qualified name if set;
if only 'CHEVERETO_HOSTNAME' is set, that will be used.. perhaps splitting it if it has a period.

  • If only 'CHEVERETO_HOSTNAME' is set, that will be used as FQDN
  • If 'CHEVERETO_HOSTNAME' AND 'CHEVERETO_DOMAIN_NAME' is set
    'CHEVERETO_HOSTNAME' is expected to either:
    • Not contain a period '.'
      or
    • The content of the CHEVERETO_HOSTNAME var is split at the first '.' character, and the second sub-string is expected to match the CHEVERETO_DOMAIN_NAME envvar.
  • If 'CHEVERETO_FQDN' is set, and it conflicts with 'CHEVERETO_HOSTNAME', error:

Terrible exemplar:
Code: 
$ for MockHN in baz foo whee; do  \
  CHEVERETO_HOSTNAME=${MockHN}; \
  CHEVERETO_FQDN='foo.baz.buzz';
  HN=$(awk -F. '{print $1}' <<< ${CHEVERETO_FQDN}:-'');
  if [[ "${HN}" != "${CHEVERETO_HOSTNAME}" ]] ; then
    echo "Hm. CHEVERETO_HOSTNAME has the value of ${CHEVERETO_HOSTNAME} and CHEVERETO_FQDN has the value of ${CHEVERETO_FQDN}. However ${HN} and ${CHEVERETO_HOSTNAME} Don't match. Not sure what you want me to do here... sorry.";
  else
    echo "\o/ CHEVERETO_FQDN is set, and ${HN} matches ${CHEVERETO_HOSTNAME}." ;
  fi;
done

Code: 
Hm. CHEVERETO_HOSTNAME has the value of baz and CHEVERETO_FQDN has the value of foo.baz.buzz. However foo and baz Don't match. Not sure what you want me to do here... sorry.
\o/ CHEVERETO_FQDN is set, and foo matches foo.
Hm. CHEVERETO_HOSTNAME has the value of whee and CHEVERETO_FQDN has the value of foo.baz.buzz. However foo and whee Don't match. Not sure what you want me to do here... sorry.

This way, if one is pedantic, they can use hostname, hostname + domain_name, or fqdn.

internally, you can do pretty much wot I did there, chop the string on the first period; assuming that $2 is domain_name and $1 is host_name

in the docs example, you show an fqdn being assigned to chevereto_hostname in some places, and a shortname in others. while I concur that both are fine, the ambiguity is confusing, as it's not clear what the system is expecting.

I figured that reducing ambiguity, or at least providing mechanism by which one could do so if they wished, would ultimately result in fewer headaches for all; but I don't REALLY care that much? just trying to advocate for the path of least surprise.
🤷
 
Last edited:
Upvote 0 Downvote
Chevereto only needs the "hostname" once to build the display URL, that's the sole use of the CHEVERETO_HOSTNAME variable.

Code: 
<proto>://<hostname><hostname_path><app_uri>

Splitting this in more variables doesn't have that much sense as the sole use is to build the URL. Keep in mind that in early networking "hostname" referred to any addressable entity.
 
Upvote 0 Downvote
Rodolfo said:
Chevereto only needs the "hostname" once to build the display URL, that's the sole use of the CHEVERETO_HOSTNAME variable.

Code: 
<proto>://<hostname><hostname_path><app_uri>

Splitting this in more variables doesn't have that much sense as the sole use is to build the URL. Keep in mind that in early networking "hostname" referred to any addressable entity.
Click to expand...

While that's true, that's only really true until you're at the end of the 199x decade 😉 (arguably earlier)

that was the case during the days of arpanet, and the early internet, but quickly transitioned to fqdn once The Internet™️ became a thing.

regardless.... I concur it's not worth the effort to address 😉
 
Upvote 0 Downvote
on the subject of ha/durable configs, do you think the most likely useful topology would essentially be a pair of compose rigs which are configured (mostly) identically, and each web instance talks to the compose-rig-local db/redis?

that would provide durability/ upgrade/maintenance resilience, and would likely deviate the least from a topology/setup perspective…

obvs. a (durable redis cluster), (mysql cluster), (scalable web pool) would allow for the dif components to scale independently, which is arguably a more beneficial layout for larger deployments.. my thought there is tho that the majority of THOSE users are likely more inclined to use a saas offering for their db/memory cache ((redis)) …
 
Upvote 0 Downvote
Rodolfo said:
Chevereto is a database driven application, everything happens there. You need to focus on the database mostly.
Click to expand...
obviously...
I guess I didn't frame the question properly.


end goal:
( resilient chevereto )

current deploy model:
single vm/singledocker compose stack

question:

Would a pair of docker compose rigs, each (generally) similar...
- With the connective tissue plumbed to wire:
- compose-rig-A_redis to compose-rig-B_redis
- compose-rig-A_mysql to compose-rig-B_mysql
which would provide the general ability to have node hosting rig-A die, and b take its place automagically...
(more for redundancy/resiliency more than to scale)

be generally useful to the community at large?

or am I jus building it for myself 🙂

(if I'm jus doing it for my'll prolly rip mysql out of compose and manage the resiliency outside the scope of chev)
 
Upvote 0 Downvote
You must log in or register to reply here.
Back
Top