public/geek-cookbook
1
0
Fork 0
mirror of https://github.com/funkypenguin/geek-cookbook/ synced 2025-12-13 17:56:26 +00:00
Code Issues Releases Wiki Activity

Tidy up first elfhosted blog post

Browse Source 
Signed-off-by: David Young <davidy@funkypenguin.co.nz>
This commit is contained in:
David Young
2023-07-08 06:58:18 +12:00
parent 003966bece
commit 7947bb0522
5 changed files with 11 additions and 94 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
docs/blog/posts/notes/elfhosted/kubectl-deploy-elfhosted.md
View File

@@ -4,7 +4,7 @@ categories:
- note - note
tags: tags:
- elfhosted - elfhosted
title: Introducing the ElfHosted experiment title: Kubectl deploy ElfHosted
description: Every journey has a beginning. This is the beginning of the ElfHosted journey description: Every journey has a beginning. This is the beginning of the ElfHosted journey
--- ---
@@ -61,18 +61,18 @@ Our original appbox platform invested in a custom user dashboard, which handled:
1. Account setup and payment 1. Account setup and payment
2. App install/uninstall/restart 2. App install/uninstall/restart
This ended up being a big investment, and an ongoing source of frustration[^1]. Since we want to iterate ElfHosted quickly, we need an "off-the-shelf" billing system which will "just work". I looked into Shopify, Woocommerce, and several other open-source billing systems. This ended up being a big investment, and an ongoing source of frustration[^1]. Since we want to iterate ElfHosted quickly, we need an "off-the-shelf" billing system which will "*just work*". I looked into Shopify, Woocommerce, and several other open-source billing systems.
My philosophy here is that I want as little as possible to do with billing - it's soul-sucking, anti-fun to debug why customer **X** was charged **$Y** instead of **$Z** :rage:! My philosophy here is that I want as little as possible to do with billing - it's soul-sucking, anti-fun to debug why customer **X** was charged **\$Y** instead of **\$Z** :rage:!
I settled on the pragmatic approach of using [Woocommerce](https://woocommerce.com/marketplace-sale/) on Wordpress. It's extensible enough for the customization I'll need for service provision, but it's polished / supported enough to handle all the weird edge cases a billing system needs. I paid for the Subscriptions and Bundles addons, after doing some rudimentary testing to confirm that I could get a webhook sent on a user creation / subscription event. I settled on the pragmatic approach of using [Woocommerce](https://woocommerce.com/marketplace-sale/) on Wordpress. It's extensible enough for the customization I'll need for service provision, but it's polished / supported enough to handle all the weird edge cases a billing system needs. I paid for the Subscriptions and Bundles addons, after doing some rudimentary testing to confirm that I could get a webhook sent on a user creation / subscription event.
### SSO ### Single Sign On (SSO)
One of the killer features of the appbox service was our ability to secure otherwise-insecure applications (*[Gatus](https://github.com/TwiN/gatus), for example*) behind a layer of authentication, in this case driven by Traefik Forward Auth and Auth0. I needed to replace the Auth0 integration with _something_, and in the spirit of quick iteration, I discovered two Wordpress plugins which will allow Wordpress to act as a OIDC authentication server (*sign in with Wordpress*): One of the killer features of the appbox service was our ability to secure otherwise-insecure applications (*[Gatus](https://github.com/TwiN/gatus), for example*) behind a layer of authentication, in this case driven by Traefik Forward Auth and Auth0. I needed to replace the Auth0 integration with _something_, and in the spirit of quick iteration, I discovered two Wordpress plugins which will allow Wordpress to act as a OIDC authentication server (*sign in with Wordpress*):
* [This one](https://wordpress.org/plugins/miniorange-oauth-20-server/), which is highly polished but the free version is intended to upsell you to an expensive paid version * [This one](https://wordpress.org/plugins/miniorange-oauth-20-server/), which is highly polished but the free version is intended to upsell you to an expensive paid version
*[ This other one](https://wordpress.org/plugins/openid-connect-server/), which is very bare-bones, and requires editing Wordpress's config to get it going. * [This other one](https://wordpress.org/plugins/openid-connect-server/), which is very bare-bones, and requires editing Wordpress's config to get it going.
Again, in the interests of expediency, I'm starting with the polished-but-naggy extension! Again, in the interests of expediency, I'm starting with the polished-but-naggy extension!

87
docs/blog/posts/notes/elfhosted/prologue.md
View File

@@ -1,87 +0,0 @@
---
date: 2023-06-08
categories:
- note
tags:
- elfhosted
title: Introducing the ElfHosted experiment
description: Every journey has a beginning. This is the beginning of the ElfHosted journey
---
# Introduction to ElfHosted
I've consulted on the building and operation of an "appbox" platform over the past 2 year, and my client/partner has made the difficult decision to shut the platform down, partly due to increased datacenter power costs, and capital constraints.
So I've got two year's worth of hard-earned lessons and ideas re how to build a GitOps-powered app hosting platform, and a generous and loyal userbase - I don't want to lose either, and I've enjoyed the process of building out the platform, so I thought I'd document the process by setting up ***another** platform, on a smaller scale (*but able to accommodate growth*).
<!-- more -->
--8<-- "what-is-elfhosted.md"
## The Big Picture
### Infrastructure
We'll use Kubernetes. Obviously. :grinning:
But where to get the infrastructure? The appbox hardware was all owned, which was big capital outlay, and while it was fun to drive a big, grunty compute and ceph cluster with redundant 40Gbps network (*for the Ceph nodes*), 10Gbps local and internet connectivity, the power / physical management of the infrascture turned out to be our undoing.
My first thought was to pursue managed Kubernetes clusters, but I was quickly priced out. Next I considered bare-metal managed Kubernetes providers (*servers.com, for example*), but couldn't find something appropriately customizable, resilent, and affordable.
I was directed towards Hetzner's [Server Auction](https://www.hetzner.com/sb), and I found my groove... Hetzner sell older servers at a discount, and based on RAM/CPU, they're simply the most affordable option. The downside is that Hetzner's dedicated server products are very much a "hands-off" arrangement - no magic cloud infrastructure, no elastic block storage, and no managed Kubernetes.
Since managing bare-metal Kubernetes platforms is **literally** my [day job](https://www.funkypenguin.co.nz/work-with-me/), I decided to commit, and ordered a small 64GB 4-core machine as a controller, and a slightly gruntier 12-core, 128GB machine as an initial worker.
=== "Controller"
```
1 x Dedicated Root Server "Server Auction"
* Intel Core i7-7700
* 2x SSD M.2 NVMe 512 GB
* 4x RAM 16384 MB DDR4
* NIC 1 Gbit Intel I219-LM
* Location: Germany, FSN1
```
=== "Worker"
```
1 x Dedicated Root Server "Server Auction"
* Intel Core i9-9900K
* 2x SSD M.2 NVMe 1 TB
* 4x RAM 32768 MB DDR4
* NIC 1 Gbit Intel I219-LM
* Location: Germany, FSN1
```
### Billing System
Our original appbox platform invested in a custom user dashboard, which handled:
1. Account setup and payment
2. App install/uninstall/restart
This ended up being a big investment, and an ongoing source of frustration[^1]. Since we want to iterate ElfHosted quickly, we need an "off-the-shelf" billing system which will "just work". I looked into Shopify, Woocommerce, and several other open-source billing systems.
My philosophy here is that I want as little as possible to do with billing - it's soul-sucking, anti-fun to debug why customer **X** was charged **$Y** instead of **$Z** :rage:!
I settled on the pragmatic approach of using [Woocommerce](https://woocommerce.com/marketplace-sale/) on Wordpress. It's extensible enough for the customization I'll need for service provision, but it's polished / supported enough to handle all the weird edge cases a billing system needs. I paid for the Subscriptions and Bundles addons, after doing some rudimentary testing to confirm that I could get a webhook sent on a user creation / subscription event.
### SSO
One of the killer features of the appbox service was our ability to secure otherwise-insecure applications (*[Gatus](https://github.com/TwiN/gatus), for example*) behind a layer of authentication, in this case driven by Traefik Forward Auth and Auth0. I needed to replace the Auth0 integration with _something_, and in the spirit of quick iteration, I discovered two Wordpress plugins which will allow Wordpress to act as a OIDC authentication server (*sign in with Wordpress*):
* [This one](https://wordpress.org/plugins/miniorange-oauth-20-server/), which is highly polished but the free version is intended to upsell you to an expensive paid version
*[ This other one](https://wordpress.org/plugins/openid-connect-server/), which is very bare-bones, and requires editing Wordpress's config to get it going.
Again, in the interests of expediency, I'm starting with the polished-but-naggy extension!
## Summary
--8<-- "what-is-elfhosted.md"
There are lots more ideas to explore, and problems to solve, but solving billing, infrastructure, and SSO means that the idea "has legs", so let's keep building and testing!
--8<-- "blog-footer.md"
[^1]: Adding products was laborious, and it'd do weird things like cancel subscriptions when an auto-renewal was cancelled, intsead of at the end of the subscription period!

3
docs/elfhosted/index.md Normal file
View File

@@ -0,0 +1,3 @@
# Introducing "Elf Hosted"
Do you enjoy tinkering with Docker, Kubernetes, and self-hosting, but there are some things you want to "Just Work(tm)"? That's what Elf Hosted is about - combining out extensive (*and growing!*) collection of recipes with the Kubernetes / GitOps-managed architecture, and making them available in a well-packaged, automated, gitops, continuouly-delivered bundle!

3
scripts/build-insiders.sh
View File

@@ -1,3 +1,4 @@
#!/bin/bash #!/bin/bash
docker build --build-arg FROM_SOURCE=ghcr.io/geek-cookbook/mkdocs-material-insiders . -t funkypenguin/mkdocs-material --platform amd64 docker pull ghcr.io/geek-cookbook/mkdocs-material-insiders
docker build --build-arg FROM_SOURCE=ghcr.io/geek-cookbook/mkdocs-material-insiders . -t funkypenguin/mkdocs-material
docker run --rm --name mkdocs-material -v ${PWD}:/docs funkypenguin/mkdocs-material build -f mkdocs-insiders.yml docker run --rm --name mkdocs-material -v ${PWD}:/docs funkypenguin/mkdocs-material build -f mkdocs-insiders.yml

2
scripts/serve-insiders.sh
View File

@@ -4,4 +4,4 @@ docker build --build-arg FROM_SOURCE=ghcr.io/geek-cookbook/mkdocs-material-insid
docker run --rm --name mkdocs-material -it -p 8123:8000 -v ${PWD}:/docs -e PROD_BUILD=false funkypenguin/mkdocs-material-insiders serve \ docker run --rm --name mkdocs-material -it -p 8123:8000 -v ${PWD}:/docs -e PROD_BUILD=false funkypenguin/mkdocs-material-insiders serve \
--dev-addr 0.0.0.0:8000 \ --dev-addr 0.0.0.0:8000 \
--dirtyreload \ --dirtyreload \
--config-file mkdocs-insiders.yml --config-file mkdocs-insiders.yml