I initially started writing a guide on how so get OIDC/SSO setup locally but realized that there are a lot of concepts I need to introduce first. There are well known limits that ghost has that keep it from scaling horizontally but it’s still nice to have this pattern if everything else in your ecosystem is in Kubernetes.
If anyone has any thought or feedback or anything that is confusing let me know. I did do a pretty quick pass at the general infrastructure I’m running since everyone has their preferences in that regard. As long as you manage to get a gateway up and running the rest is all applicable.
While you probably are doing a value add by spinning your own ghost image (I have my own where I added the GCS/S3 plugin. You’ll likely have way less people being okay with running a random person’s spin of ghost. Can you run that with the stock image?
I would skip ingress completely. Too many versions out there and every implementation and cloud provider does their own thing. You could ship with a Gateway API HTTPRoute that at least would be uniform.
things like this should be removed IMO. .Values.ingress.tls.certificate you should never have sensitive data in a chart values file. No passwords, secrets etc. It’s convenient but that’s a different problem to solve that helm should not encroach on.
It does seem like you are installing a few more components as a single deployment but it looks pretty comparable.
I’m assuming you also landed on only running a single pod of ghost?
Yes, you can run with any stock image and proper config. Besides, the ghost on kubernetes custom image has it’s base images updated on every build, uses a rootless debian trixie based distroless image and every build is signed. Also you can easily fork the repo and build it by yourself if you want. It’s not intended for non-technical users, but anyways everyone is welcome to ask and try.
Agree, I’m working on that feature, but if you are interested, any PR is more than welcome.
You are right, and it’s an ugly “feature” inherited from the early deployment approach, intended to be as a “working example”, but anyways is wrong. I will prioritize the removal of unsafe stuff, thanks!
The helm chart is still pretty messy and needs a lot of corrections.
As you well mentioned, if you use mailgun and more than 1 replica, you are gonna suffer and it’s NOT recommended at all.
Besides that, using a rwx single volume for ghost storage did the trick but still not recommended and not supported at all. Multiple replicas should be used only in testing environments.