Alternative Prod Deployment options

[elreydetoda]

Haven't tried rclone yet - for 1.0 milestone we'll stick with the method the sysadmin here understands best (container). Not ruling out changes to s3 etc in future but I was advised by @gerbrent a real web server is needed for more advanced functionality somewhere? Not sure what though.

Originally posted by @ironicbadger in #244 (comment)

[anthr76]

Just listened to the last office hours, and I had to dig up this issue that was spoken of. First I must say the website looks awesome and is a huge upgrade to what's existing now!

That being said I did hear that folks would like to practice the KISS principle and I do think having a CI job to push to a Linode is a bit overly complex for a hugo site. :)

For example GitHub pages can statically hosts hugo with ease. If you back that by Cloudflare CDN it's basically distributed serverless at that point. I do have some experience in that realm so happy to help out.

Here's an example of a small blog my wife and I maintain

[1] https://everydayna.art/
[2] https://github.com/jar71/everyday-na/blob/ce8cc7532beb87bed4c854a6cacfb04363c8af78/.github/workflows/ci.yml#L10-L24
[3] https://github.com/jar71/everyday-na/tree/gh-pages

Managing cloudflare with terraform is fairly straight forward as well.

Hope all is well. Anthony

[ironicbadger]

@gerbrent

I was advised by @gerbrent a real web server is needed for more advanced functionality somewhere? Not sure what though.

[elreydetoda]

@gerbrent

I was advised by @gerbrent a real web server is needed for more advanced functionality somewhere? Not sure what though.

I don't know what it was that he was referring to, but one example of where having a webserver is better (if we didn't have cloudflare in front of the site (because they let you handle redirects as well using them IIRC)), and were just on GH pages is this situation: #300 (comment)

The cloudfront + GH pages w/hugo is a pretty slick setup I've done it myself for this project that we built out for a client. We also added the NetlifyCMS on top as well so they didn't have to dig into MD + front matter of hugo (talk about that a bit here).

I will say though, without @ironicbadger's current deployment we won't be able to do self-hosted previews (as discussed here). So, if we're trying to go with self-hosting things then GH pages would be out of the question.

I honestly thought we'd gone with the self-hosted solution just because that's what JB had wanted (since they currently self-host on top of wordpress).

[anthr76]

I think pushing previews on a server makes more sense IMO.

@gerbrent

I was advised by @gerbrent a real web server is needed for more advanced functionality somewhere? Not sure what > though.

That would make sense it would be good to know that limit.

Overall I think pushing to linode is okay if there's a usecase, and regardless of where it's hosted I think it should be fronted by cloudflare. I suppose it's good to know the options

[ironicbadger]

To be perfectly honest, I do not want to be on the critical path at 2am. Self-hosted is nice and got us unblocked in the beginning but if we can concoct a more performant, flexible solution I'm all ears.

It's also worth noting that thanks to sponsorship Linode costs are not a concern for us. Whereas 3rd party services might be. This would be ultimately up @ChrisLAS to decide on as it will be his sats we are spending!

[anthr76]

In that case at some point this weekend I can submit a PR for GH pages enablement and temporarily host it on yet another sub domain (or the one GitHub) provides. to see what's broke.

The cost aspect is a great point @ironicbadger and something I forgot to add in my OP but thought about

[elreydetoda]

That'd be awesome @anthr76 ! I know I personally would prefer GH pages because it's essentially serverless (like you'd mention). Also, because it's so hands off for deployment and management 😁

Also, whenever your doing this IIRC there are going to be some setting which need to be tweaked in the repo. So if you don't mind documenting those steps you do in the docs/ folder when you go to submit the PR that'd be awesome! Then we keep the repo setting modification along with the repo + it let's the JB crew do it on their own time.

[reesericci]

Maybe deploying the site on cloudflare pages/workers could work well. Also we had discussed using Netlify at #173

[elreydetoda]

Also we had discussed using Netlify at #173

I was mainly think about using deploy previews for netlify, not actually deploying to netlify. Technically they could be an option as well, but I think they only give you a certain amount of build minutes a month... 🤔 So, I don't know if I'd recommend deploying there.

---

Also, posting links/summaries to a convo mentioned in matrix a while back.

• convo started here and ended here
• talked about just using the latest tag, and also tagging it with another UUID (i.e. current time of build), until something broke with a versioned docker container artifact

kptech: Also if we want to stay on Linode they actually have an article for hosting your own docker repo that gets backed by their object storage I believe

ironicbadger: this is possibly interesting but i am nervous because self-hosted docker registries are typically a pain to administer certificates for. i'd rather push to a docker hub or GHCR repo and push against those barriers (of cost?) before we host our own. plus its one more thing i can get paged about at 2am if it breaks :D
and i'm also not against building an artifact'd versioned container to deploy the site. that would be fine typically for a website that only updates when creators write a post or whatever. but JB updates automatically via scraper daily or more - so how does a container fit into that paradigm?
are we expecting to run the docker-compose against :latest tag? because that negates some (most?) of the benefits...

it's a hard problem to solve!

kptech: You could expose a webhook on the vps that take a parameter which is the image tag. Have the GitHub action call that webhook and then the vps could response to that webhook and update the image tag.

elrey741:So...I think this could actually be simplified a bit 😅 Mainly because overall I don't like exposing web-hooks to the internet if we can help it (always seemed like a matter of time before something finds/messes with it IMO).

While ironicbadger was trivializing it a bit with this:

are we expecting to run the docker-compose against :latest tag?

That'd be only part of the solution IMO. We could just have the :latest tag be added to the image which gets pushed but also add another tag (i.e. the current time: 2022-08-19T09_44_53-04_00. Then if something goes wrong we can either have
ironicbadger
manually ssh in and change the tag to revert it or there is a dedicated GH action which can be passed an environment variable for the tag which we want to use to "rollback". That way it's "automated", but still possible to do if someone doesn't have ssh access to the server.

Then ironicbadger doesn't have to get paged in the middle of the night, we can just revert the image, stop merging PRs, and troubleshoot it the next day 🙃

ironicbadger: container versions are controlled by the infra repo atm
not by me ssh'ing in
https://github.com/JupiterBroadcasting/infra/blob/3b9490a46119ffdc70018b2ac8315346d947a06d/ansible/group_vars/core.yaml#L517

elrey741: the ssh'ing was just an example of an emergency situation (if need be, and trying to keep it simple)
but, that's perfect well then we'd just need someone who has permissions to merge with the infra repo then 😁

[gerbrent]

From what I gather, the idea of being able to roll back a production image relatively easily sounds like a definite benefit. It'll be in deciding if the additional complexity is worthwhile?

[reesericci]

It's probably worth just using a hosting provider like Netlify, CF workers/pages, or Vercel. The simplicity and featureset just unmatched imo.