Skip to content
This repository has been archived by the owner on Dec 15, 2021. It is now read-only.

Use Knative to host the Knative website #64

Open
rgregg opened this issue Jul 31, 2019 · 6 comments
Open

Use Knative to host the Knative website #64

rgregg opened this issue Jul 31, 2019 · 6 comments
Assignees

Comments

@rgregg
Copy link
Contributor

rgregg commented Jul 31, 2019

I spent a little spare time over the weekend looking at containerizing the Knative website so that it could be run on a Knative-compatible host. Turns out it wasn't that hard to move everything into a two-stage docker build flow.

I haven't moved all of the configuration in the current build script, e.g. supporting PRs.

I've pushed these changes to a fork of this repo, here: https://github.com/rgregg/website/tree/self-hosted, and you can see an example of it running here on Cloud Run: https://knative-website-7jeitjla7a-uc.a.run.app/

I'd love to see us start to dogfood Knative to run our own website. What do other folks think?

Another advantage of this approach is that local-development is super easy, since the whole build and run environment happens inside a container. You don't need to setup any build environment on your local machine, just clone the repo and go. This is a big improvement over getting the build environment setup on your own machine!

Another big advantage is that we can control more of the process. We're not subjected to Netlify changing the version of Hugo we're using under our nose, potentially breaking how our text is rendered.

If this is interesting, I'm happy to keep working on getting the full set of functionality ported over.

@samodell
Copy link
Contributor

I think it's a nice idea, but I think we lose a lot of the safety and predictability of using Netlify, as well as a lot of the work Richie has done to hook up Netlify to Github, where we see automatic staging builds in the website repo.

It also sounds like a fair amount of work for a small tangible benefit -- most folks are not going to care what backend we run the site on. Right now, it is a bit difficult to set up local builds of Netlify, but it's also true that a pretty small number of people are interested in doing that.

@RichieEscarez
Copy link
Contributor

I like it and I'm very much open to the idea but I need to think about this more.

Does porting over functionality include GitHub PR integration (ie. build staged draft for preview and also publish new merged content)? As Sam touches on, I'd hate to see any regression from where we've gotten to but appreciate the fact that we would overall gain more control.

Thinking further out, who do you envision would own and maintain the Knative site host?

Regarding the local builds, I have a PR open to simplify that a bit (PR #62). This is only a baby step since you still need to install Hugo (and postcss) but after cloning both the docs and website repos, you just run scripts/localbuild.sh (and you get a local build that is similar to what happens on Netlify).

@rgregg
Copy link
Contributor Author

rgregg commented Jul 31, 2019

Netlify has been great for bootstrapping our website. As we get closer to GA, we need to be using Knative more in production ways, and this seems like a way to do that with great visibility (both in terms of usage and finding issues, since if the website breaks due to Knative we'll know pretty quickly). I'd love to see our website adopting more of the best practices that we're encouraging with Knative.

While my current state would be a regression from current behavior, it shouldn't be too difficult to pull in the rest of the work you've done. I just hadn't done it yet since I wanted to see if this approach would work at all. With Knative Eventing we can trigger a build on changes to any of the repos we pull content from (website, docs, and community), build using Tekton, and then deploy into Knative serving.

The real tangible benefit here is to Knative, further validating the pieces we're building, in production for one of the core use-cases (serving HTTP). Having a completely reproducible environment for building, testing, and deploying the website is a nice benefit as well.

I'm happy to work on this more if it seems interesting. Maybe we can find a pathway to where we can transition ownership to the engineerings, so the docs team can spend less time managing infrastructure?

@samodell
Copy link
Contributor

Well, that I'd be in favor of! I thought this plan involved Richie maintaining the new Knative-based version of the site 😂

@RichieEscarez
Copy link
Contributor

Sounds good to me too.

RichieEscarez added a commit to RichieEscarez/website that referenced this issue Oct 10, 2019
@mattmoor
Copy link
Member

mattmoor commented Mar 2, 2020

where we see automatic staging builds in the website repo.

FWIW I have this running against knative/docs PRs where it builds docs and website (HEAD) into a container image that runs on knative/serving using the local build as an entrypoint.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants