• 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
Pro
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
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
You must log in or register to reply here.
Back
Top