-
Notifications
You must be signed in to change notification settings - Fork 5.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update Kubernetes Helm Chart #2048
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven't looked into this hard but is it possible to simplify this? 700 additional lines is a lot of code, we don't have to serve every use case.
@nhooyr the 700 lines is generated from helm create, and as such is considered best practice. This actually only caters for a very simple use case 😅 The original pull request for this chart was 600 lines and did not include a helm ignore which would explain why mine is so large. This commit also adds a kubeval GitHub action to ensure new commits do not break the chart, this can be removed to streamline the commit if you do not wish to receive new GitHub Actions from contributors. |
@nhooyr would you be able to advise on my reply? I can begin trying to shrink the commit if my reply is unacceptable. |
This is a very slim helm chart IMO. First 200 lines are +1 for merging this in. To make this chart useful it needs to be published via Github pages. |
Nah you're good! I just need to find the time to review this/dig into helm. I don't want to publish anything we haven't tested and verified ourselves. What's the advantage to |
Also cc @sreya92 for thoughts as I know he's been in helm land for a while. |
@alexgorbatchev absolutely, I agree! I haven't ever done this myself, however I am familiar with how it works. So that the solution is supportable and of a good quality, you mind pairing with me on this?
@nhooyr indeed, there is no argument the complexity of Helm charts is considerable when compared to that of native manifests. However, generally it is accepted that Helm charts are a more reliable way of an application vendor providing a reliable mechanism for deploying the application to their cluster that is managed and life cycled. Helm charts are ultimately packages in a package manager, so it's the argument of copying a binary to /usr/local/bin over installing it through your distribution's package manager and having versioning and state management capability. Apologies if this is an overly dumb explanation! 😅 I'm not sure how else to explain it. |
Sure, I can help.
The main advantage is composability. Every engineering organization uses some form of provisioning system like Terraform or Ansible to manage their infrastructure. Helm charts provide an easy way to install complex Kubernetes manifests with pre-defined configuration specific to the application. It also makes it easy to receive future updates. While you can also use plain manifest files and modify them for your needs, you will have to do this every time there's an update to the manifest, which can be pretty error prone. Think of a Helm chart as as a bash script that takes arguments, and manifest as a bash script that you have to heavily edit to pass the same arguments. |
@alexgorbatchev how would we implement Helm repositories on GitHub pages for cdr/code-server as external contributors to the project? |
I'll have a PR soon. |
@Matthew-Beckett in order to get easy github pages hosting, https://github.com/alexgorbatchev/alexgorbatchev.github.io example output: https://alexgorbatchev.github.io/helm-charts/public/ This repo includes chart files from THIS PR and assumes they will be hosted there. It makes it easier to publish github pages. Alternatively one could simply look at how I've implemented publishing and move it else where. Everything happens via a few simple HELM shell commands and as a bonus I'm generating The output from the ❯ ./scripts/build.sh
Packaging helm charts
Successfully packaged chart and saved it to: public/code-server-1.0.0.tgz
Writing: public/index.yaml
Writing: public/index.html Please let me know if this looks sufficient. |
Please let me know when I can take down the example from my public page :) |
@code-asher @nhooyr Could you please have a look at this? |
I'm surprised how fast Just need |
@code-asher @nhooyr ping |
@code-asher @nhooyr nudge |
@nhooyr I have resolved all your comments, @alexgorbatchev if you do not wish to maintain this going forward I can remove you, it's just to get this finally merged in 😅 |
🎉 |
Got a bottle of champagne in the fridge I've been saving, this might be the moment 😆 |
@nhooyr should we open this into a new issue? I think this would benefit users immensely post-merge. |
@@ -1 +1,2 @@ | |||
* @code-asher @nhooyr | |||
charts/code-server @Matthew-Beckett @alexgorbatchev |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
more automation is better for sure 👍🏼
I believe we can just use Can you give it a shot and see if it works? |
Ooops, nevermind I'm wrong. I see, we need to serve a |
Indeed, furthermore, Helm expects a certain HTTP response to list the charts and their version, Helm wouldn't natively support GitHub Release pulling. |
Yea that's unfortunate. I'm surprised helm doesn't let you use git urls, seem's like huge mistake. There's https://github.com/aslafy-z/helm-git at least. And now helm/helm#6734 Personally, I'm ok with users having to clone the repository before using helm as I think it's unfortunate to have to setup github pages just for helm but I'm open to discussion. |
I think ideally there should be a simple way to use Helm with this chart, via github pages (or similar). Having to clone the repo here is akin to asking users to clone a repo before running |
@sreya @code-asher nudge |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good overall. I obviously didn't validate all the parameters since you provided so many but a basic install works well :) If there are any bugs they will shake out over time.
runAsUser: {{ .Values.volumePermissions.securityContext.runAsUser }} | ||
volumeMounts: | ||
- name: data | ||
mountPath: /home/coder |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we always want the persistent volume to be mounted to /home/coder
? If we allow for users to override the image we should maybe allow them to override the home directory.
|
||
```console | ||
$ git clone https://github.com/cdr/code-server.git | ||
$ helm install code-server/charts/code-server |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
$ helm install code-server/charts/code-server | |
$ helm install code-server code-server/charts/code-server |
## | ||
# storageClass: "-" | ||
accessMode: ReadWriteOnce | ||
size: 1Gi |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
1Gi seems a bit small for a default value I think 10 might be a better value.
Going to merge and fix comments myself so we can get this into today's release! |
Thanks for reviewing @sreya |
I mean it's more on Helm than us though. As a project maintainer, we have to test and support so many different platforms/package managers/combinations already. Adding one more is frustrating when helm could just support git. |
I opened #2302 regardless though. |
Fixes #2012, #914