The #infrastructure of #Hachyderm was discussed at #FOSDEM in a Birds Of a Feather. We talked about the different components and why they are structured as they are now, explaining both their history and the financial aspect.
In the photo below @hazelweakly and @esk ; @e_nomem and myself were also there.
=> View attached media | View attached media
=> More informations about this toot | More toots from slamp@hachyderm.io
@slamp @hazelweakly @esk missed a set of nginx's between puma and cdn edge β buttons & fritz both have nginx to expose mastodon web (puma) to the CDN nginx
So:
Edge nginx -> Node nginx -> puma
Edge nginx -> streaming
=> More informations about this toot | More toots from thisismissem@hachyderm.io
@thisismissem @slamp @hazelweakly yup - we were short on time even with an hour m, so we didn't hit quite everything π
=> More informations about this toot | More toots from esk@hachyderm.io
@esk @slamp @hazelweakly I mean, theoretically we could tell mastodon-web (puma) to serve the static assets instead of using nginx for that since edge could cache those long term, but it's fine
=> More informations about this toot | More toots from thisismissem@hachyderm.io
@thisismissem @esk @slamp @hazelweakly this also reminds me that we need to move the static assets to a separate domain so that we can cache it at the edge better. At that point it may not matter if we have nginx or puma serving up those files.
=> More informations about this toot | More toots from e_nomem@hachyderm.io
@e_nomem @esk @slamp @hazelweakly I don't think Mastodon supports that?
=> More informations about this toot | More toots from thisismissem@hachyderm.io
Oh, actually, CDN_HOST environment variable, didn't know about that
=> More informations about this toot | More toots from thisismissem@hachyderm.io
@thisismissem yep, was about to link it but static.hachyderm.io should definitely be a thing
=> More informations about this toot | More toots from e_nomem@hachyderm.io
@e_nomem I'm just not 100% sure how this would affect deployment of new versions? Would we back static.hachyderm.io with a bucket? Then have a step to copy public/ to that bucket?
=> More informations about this toot | More toots from thisismissem@hachyderm.io
@thisismissem@hachyderm.io @e_nomem@hachyderm.io You could yes, presumably using a tool like rclone with them both entered as remote targets. Although... that sort of brings into question "why?". Assuming these are referring to stuff like hachyderm.io's logo, icons and other branding, wouldn't the point be to keep them separate? They aren't going to change much unlike user uploaded content. I think it'd be interesting to have some sort of version control backing your static assets. Not sure git is the answer here but presumably the workflow would be "commits a change -> approved -> some action invokes rclone to copy the newly changed asset and deploy it".
=> More informations about this toot | More toots from puppygirlhornypost2@transfem.social
@thisismissem@hachyderm.io @e_nomem@hachyderm.io never mind - i see this includes scripts served for mastodon's front end.
=> More informations about this toot | More toots from puppygirlhornypost2@transfem.social
@puppygirlhornypost2 Yeah, it's not super clear but the 'assets' referenced here are the sort of things that get updated only when we update to a new version of mastodon itself. They're highly cachable
=> More informations about this toot | More toots from e_nomem@hachyderm.io
@e_nomem@hachyderm.io Before I make an ass of myself further - Does the talk from earlier go into detail how you deploy new versions of mastodon? I am thinking that if you do continuous deployment it shouldn't be that hard to have a stage where you copy files like https://hachyderm.io/custom.css to the bucket used in serving these static assets?
=> More informations about this toot | More toots from puppygirlhornypost2@transfem.social This content has been proxied by September (3851b).Proxy Information
text/gemini