vigil
vigil copied to clipboard
valeriansaliou
add fully working Helm Chart
it's enough to get you started, just install it and do a port-forward to :8080 and you'll have a demo status page at your disposal
Resolves: #63
there you go, added the Helm Chart push CI step as well :)
Feel free to adapt it as needed.
Helm is a way to package an app for deploying it on Kubernetes, you'd use a helm chart in order to benefit from the templating language and keeping all manifests DRY.
Sometimes, plain manifests are also good, but when you need to expose the app (ie. by creating a Service + Ingress) you'll realise that you need a better way to package all those manifests and serve them together.
Some use GitOps to help provision these charts in an automated way, Flux is a practical example.
That's a lot of overhead and things to maintain for me just for K8S. Wouldn't it be possible to have it provided by an external repository? I'm kind of not willing to add that much files in Vigil just for K8S, given that K8S is not what all people use.
Now that I think about it you're actually right, the structure of the repo's not going to contain only the app code but also other tooling for deploying it on separate platforms/environments.
Ok, I will close this PR then, but I don't know what do to next, I can just push all these into a separate repo, but not many people will be aware of its existence, so I'm not sure how to handle that.
Could that be all stored in a single folder on this repo? Like a defs folder (for Helm but also any other definitions), not mixing up with the rest of the project.
Ok, I will close this PR then, but I don't know what do to next, I can just push all these into a separate repo, but not many people will be aware of its existence, so I'm not sure how to handle that.
I would suggest to :
- move the helm-chart related stuff to a dedicated project (vigil-helm-chart)
- add link to this project in the README (Install section and/or Related projects)
- close the PR
This is good PR. It's sad to see this will go away. Moving to other repos could mean it will not officially supported by Vigil itself.
I'm willing to merge this, but since I'm not using k8s I won't maintain it over time as Vigil gets updated. Also, I'd like all those files to be nested in a sub-folder, ie. not to have k8s-related resources on the side of Vigil resources at the root.
Would that be possible?
Also, note that since the configuration file model has been since updated, I guess the PR would need to be updated in accordance w/ the changes.
Please, consider that a helm chart is like a Linux package. And the same you won't host ALL possible packages (Debian, RPM, Ubunutu...) the Helm Chart should be manage out of this repo. Motivations are strictly the same: people will like to deploy in a certain way, with some dependencies related to their version of Kubernetes or components already deployed...
IMHO, in regards to Kubernetes, the job of the current repo stop at providing an efficient Dockerfile.
@gbonnefille Thanks. You'd then recommend hosting the Helm charts outside of this repository if I got you right? Such as in a vigil-extras repository?
I would call it something like vigil-helmchart. I did something related but for the Tuleap software: https://github.com/CS-SI/tuleap-helmchart
We can also find a lot of examples. For Elastic: https://github.com/elastic/helm-charts For grafana: https://github.com/grafana/helm-charts For jenkins: https://github.com/jenkinsci/helm-charts
A more ambitious (naming) change would be to create a Vigil organisation on GitHub and manage manay repositories like vigil/vigil and vigil/helm-charts (and perhaps vigil/website, vigil/demo...)
A helm chart is not "like" a linux package. It's a set of files that are part of a templating system that render manifests that are to be deployed in a cluster. Standard practice nowadays is to host them next to your software, and have pipelines that make a helm release and publish it. Also, to accomodate non Helm users, a lot of projects add Kustomize files
Motivations are strictly the same: people will like to deploy in a certain way, with some dependencies related to their version of Kubernetes or components already deployed... this comment outlines the lack of experience you have with k8s. "The certain way" is the only way - use Helm, either as a standalone CLI tool on your machine or using a controller inside the cluster that would do the same thing for you (ArgoCD, or Flux do this)
If you're looking for example of charts, build by a great community, https://github.com/k8s-at-home/charts which use a generic library chart https://github.com/k8s-at-home/library-charts.
These charts in an ideal situation would be hosted by the projects themselves but in many many cases we - k8s admins - find ourselves in these situations where there is analysis paralysis whether to start walking with the right or with the left foot.
One of the greatest examples that i give to anyone looking for a boiler plate is: https://github.com/stefanprodan/podinfo
