Support multiple Hugo sites #3

New Issue

decentral1se · 2024-03-23T12:41:15Z

decentral1se commented

2024-03-23 12:41:15 +00:00

In general, we could turn HUGO_GIT_URL into HUGO_GIT_URLS="url1;url2;url3" and iterate over that list to generate Nginx configurations and webhookd endpoints for re-building.

I think the main limitations are 1. the basic auth password 2. the deploy key. if you wanted to do per-repository auth password/deploy key, then these need to be put in the config beforehand. That's not very flexible.

If we could compromise on a single "global" deploy key / http basic auth per deployment, then it's more or less Solved ™ That would mean that if your auth password/deploy key is somehow compromise, attackers could get access to info/builds across several sites instead of just one. Not great.

We could just "break out" of the entire swarm/config model and have folks garden their own /root/.ssh/..., /etc/nginx/... and /root/scripts directories (to add keys, nginx configs, http basic auth passwords and webhookd scripts) which we store as volumes. This would the most flexible approach and we'd stop running into docker-isms... the tradeoff is that it's a different mental model from other recipes and requires more documentation to make clear how to work with.

I find it funny how doing static sites remains one of the hardest problems in Co-op Cloud 🤣

In general, we could turn `HUGO_GIT_URL` into `HUGO_GIT_URLS="url1;url2;url3"` and iterate over that list to generate Nginx configurations and webhookd endpoints for re-building. I think the main limitations are 1. the basic auth password 2. the deploy key. if you wanted to do per-repository auth password/deploy key, then these need to be put in the config beforehand. That's not very flexible. If we could compromise on a single "global" deploy key / http basic auth per deployment, then it's more or less Solved ™ That would mean that if your auth password/deploy key is somehow compromise, attackers could get access to info/builds across several sites instead of just one. Not great. We could just "break out" of the entire swarm/config model and have folks garden their own `/root/.ssh/...`, `/etc/nginx/...` and `/root/scripts` directories (to add keys, nginx configs, http basic auth passwords and webhookd scripts) which we store as volumes. This would the most flexible approach and we'd stop running into docker-isms... the tradeoff is that it's a different mental model from other recipes and requires more documentation to make clear how to work with. I find it funny how doing static sites remains one of the hardest problems in Co-op Cloud 🤣

👍 1

decentral1se commented

2024-03-24 10:22:16 +00:00

@basebuilder thoughts updated on this one 🤓

basebuilder commented

2024-03-24 14:15:19 +00:00

With the multi-repo value HUGO_GIT_URLS="url1;url2;url3" where would the multiple domains and sub-domains be configured? In the repos themselves? I don't think I have a good enough mental grasp on this yet, but it feels like it's has possibility to get a bit confusing & squirrely to get it right.

That would mean that if your auth password/deploy key is somehow compromise, attackers could get access to info/builds across several sites instead of just one. Not great.

This indeed does not sound good strategy.

the tradeoff is that it's a different mental model from other recipes and requires more documentation to make clear how to work with.

This also does not sound ideal to me.

What is the main reason / developer-experience / user-goal your thinking this is needed for?

This is really funny and odd that static-sites are such a hard problem for Co-op Cloud 🤔 🤷‍♀️ 😬

With the multi-repo value `HUGO_GIT_URLS="url1;url2;url3"` where would the multiple domains and sub-domains be configured? In the repos themselves? I don't think I have a good enough mental grasp on this yet, but it feels like it's has possibility to get a bit confusing & squirrely to get it right. > That would mean that if your auth password/deploy key is somehow compromise, attackers could get access to info/builds across several sites instead of just one. Not great. This indeed does not sound good strategy. > the tradeoff is that it's a different mental model from other recipes and requires more documentation to make clear how to work with. This also does not sound ideal to me. What is the main reason / developer-experience / user-goal your thinking this is needed for? This is really funny and odd that static-sites are such a hard problem for *Co-op Cloud* 🤔 🤷‍♀️ 😬

decentral1se commented

2024-03-24 17:48:24 +00:00

Yeh I think containers are kinda good for other stuff... in this case it's nice to have some pinned versions of nginx, webhookd, hugo etc. but otherwise, there is a lot of docker swarm-isms getting in the way...

Main goal for multiple Hugo support was to avoid site * 2 containers bloat and instead pack sites into one deployment.

Going through this design / implementation has been pretty useful tho. I feel like it might be good to mindmeld again on design because now I have a pretty good idea of what needs to be done and I feel like we might even be able to just jerryrig a specific tool for all this which leverages containers but skips the limits of the docker swarm-isms?

Yeh I think containers are kinda good for other stuff... in this case it's nice to have some pinned versions of nginx, webhookd, hugo etc. but otherwise, there is a lot of docker swarm-isms getting in the way... Main goal for multiple Hugo support was to avoid site * 2 containers bloat and instead pack sites into one deployment. Going through this design / implementation has been pretty useful tho. I feel like it might be good to mindmeld again on design because now I have a pretty good idea of what needs to be done and I feel like we might even be able to just jerryrig a specific tool for all this which leverages containers but skips the limits of the docker swarm-isms?

basebuilder commented

2024-03-24 18:56:57 +00:00

One use case involving multiple domains that we should support, because it is really helpful for content editing static sites, is automatically generating a preview.example.org which runs a modified hugo build command publishing draft: true and future dated content.

One use case involving multiple domains that we should support, because it is really helpful for content editing static sites, is automatically generating a `preview.example.org` which runs a modified `hugo` build command publishing `draft: true` and future dated content.

basebuilder commented

2024-03-24 23:23:10 +00:00

This person figured out a way with Traefik:

Hosting static sites with Traefik

This person figured out a way with Traefik: - [Hosting static sites with Traefik](https://hyteck.de/post/static-sites-with-mash/)

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: coop-cloud/parasol-static-site#3