https://github.com/treethought/spherics
https://github.com/treethought/spherics
Last synced: 4 months ago
JSON representation
- Host: GitHub
- URL: https://github.com/treethought/spherics
- Owner: treethought
- Created: 2021-08-29T00:10:44.000Z (almost 5 years ago)
- Default Branch: main
- Last Pushed: 2022-04-21T02:37:32.000Z (about 4 years ago)
- Last Synced: 2025-03-31T08:30:08.658Z (about 1 year ago)
- Language: Makefile
- Size: 42 KB
- Stars: 0
- Watchers: 2
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
# spherics stack
The repo consists of all the self-hosted apps and services deployed on my
personal domain spherics.space.
This repo is meant quick, easy, and simple to configure template for deploying a
collection of services t your own kubernetes cluster.
## Supported Components
- [ingress-nginx](https://github.com/kubernetes/ingress-nginx/tree/master/charts/ingress-nginx)
ingress controller, for exposing your services
- [cert-manager](https://cert-manager.io/docs/) for automatically issuing
certificates for each of your components
- [gitea](https://docs.gitea.io) - self hosted git service
- owncloud
- nextcloud
## Why helmfile?
You may be wondering what the point of this repo even is, since all it does is
deploy helm charts. So why not just helm deploy aganst vaues file for each
service?
Good question, that's how it started off. However, instead of manually deploying
each chart individually and maintaining a values file that would need to be chaged for each
person using this repo, I decided to go with
[helmfiles](https://github.com/roboll/helmfile).
Helmfiles allow us to declaritively configure sets of helm charts, acting as a
kind of meta helm chart.
I had considered grouping all these charts as dependencies of a umbrella chart,
but wanted to have control over namespacing and versioning independent of the
parent and other sub charts.
By using helmfiles, each chart can still easily be managed and deployed in
isolation, but it become smuch easier to manage the entire set of services
including what is enabled for a domain and diffing the current state of the
cluster against the desired state configuration.