Github pages Lately I've been using a lot, and I would recommend anyone who isn't using it to start using it. github pages It saves you the hassle of having to get hardware to host a server, scaling if you get a lot of users (not that I do), and general availability which you usually don't get with your run of the mill at home closet servers. In fact I host this blog on GH pages and it is dead simple with a github action. Here is the one I use to push this blog to GH pages name: CI on: push: branches: [main] # Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages permissions: contents: read pages: write id-token: write # Allow one concurrent deployment concurrency: group: 'pages' cancel-in-progress: true jobs: home: runs-on: ubuntu-latest environment: name: github-pages url: ${{ steps.deployment.outputs.page_url }} steps: - uses: actions/checkout@v3 - name: Use Node.js 18 uses: actions/setup-node@v2 with: node-version: 18 - name: npm install and build run: | npm install npm run build - name: Setup Pages uses: actions/configure-pages@v2 - name: Upload artifact uses: actions/upload-pages-artifact@v1 with: # Upload entire repository path: './build' - name: Deploy to GitHub Pages id: deployment uses: actions/deploy-pages@v1 But this post is not really about GH pages, it is rather about what to do when you can't use it. Serverless backends So I was writing a time reporting page, because who doesn't love to do time reporting in tons of places! The plan was to make it sync with github gists, but the problem I ran into was that my frontend couldn't read gists without cors issues. The solution to this was to host a server that can proxy the requests to the frontend. Now the issue with that is that I have a bad habbit of creating hobby projects that plain and simply wastes resources by being up all the time. It might not be a lot, since a node server with no traffic doesn't eat a lot of ram and it doesn't take that much CPU, but it still hurts me a bit to have them just lay there doing nothing. What I could do to mitigate this is just do a "regular" kubernetes deployment and scale it down to zero when it is not needed, but I fear that one day when I do need it, and I have no access to my cluster to scale it up. The sane approach is to start using AWS lambda, Azure functions or google cloud functions, as they also scale to zero and cost next to nothing, with the addition of being highly available... but that is not the approach I went with. Instead I installed knative in my k8s cluster. Knative is a k8s controller which gives you "serverless" properties on your k8s cluster. Of course it is not serverless as you need your own k8s servers, but you get the point. Knative You can map a domain to a docker image and knative will spin that container up for you when needed, and kill it after a set time of inactivity. The deployments are quite easy to setup as well, assuming you aren't doing anything fancy apiVersion: serving.knative.dev/v1 kind: Service metadata: name: timestat namespace: timestat spec: template: spec: containers: - image: ghcr.io/munhunger/timestat/kit:{{ .Values.version }} ports: - containerPort: 3000 That piece of config is all that is needed to get a node container available at , which will get get started when needed and killed after in my case 10 minutes of inactivity. https://timestat.home.wunderdev.com/ microk8s I was planning on writing this a while ago, but I got into some issues with upgrading my k8s cluster to support a specific version of knative with auto TLS support. And as it was my third time bricking my k8s cluster during the upgrade I started looking elsewhere as there has to be some k8s installer with sensible defaults. That search led me to my new favorite piece of software, namely . microk8s It might not be for production, but for my home setup it is amazing. Dead simple to install, and it has a pretty decent plugin support (knative among others), so you can quickly spin up a node with some cool k8s controllers and get going within an hour! That is pretty mind boggling, as it usually takes me hours if not days to setup a working k8s cluster (I still have issues with the networking layer). Just remember if you are using microk8s to create an ingress towards your knative network gateway. That did cause me some headache. apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: kourier-ingress namespace: knative-serving annotations: cert-manager.io/cluster-issuer: lets-encrypt spec: tls: - hosts: - '*.home.wunderdev.com' secretName: home-tls rules: - host: '*.home.wunderdev.com' http: paths: - backend: service: name: kourier port: number: 80 path: / pathType: Prefix Without it, I had nginx loadbalancer serve all my network request, and it of course had no concept of knative
