Skip to content
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

Merged
merged 25 commits into from
Nov 13, 2020
Merged

Conversation

Matthew-Beckett
Copy link
Contributor

Fixes #2012, #914

Copy link
Contributor

@nhooyr nhooyr left a 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.

@Matthew-Beckett
Copy link
Contributor Author

Matthew-Beckett commented Sep 7, 2020

@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.

#917

@Matthew-Beckett
Copy link
Contributor Author

@nhooyr would you be able to advise on my reply? I can begin trying to shrink the commit if my reply is unacceptable.

@alexgorbatchev
Copy link

alexgorbatchev commented Sep 10, 2020

This is a very slim helm chart IMO. First 200 lines are .gitgnore and README.md. Trimming this PR would mean mostly removing comments.

+1 for merging this in. To make this chart useful it needs to be published via Github pages.

@nhooyr
Copy link
Contributor

nhooyr commented Sep 11, 2020

@nhooyr would you be able to advise on my reply? I can begin trying to shrink the commit if my reply is unacceptable.

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 helm here versus shipping a couple basic k8s manifest files? That'd be much smaller, easier to audit and understand. And just as easy to delete by targeting a label cdr/code-server.

@nhooyr
Copy link
Contributor

nhooyr commented Sep 11, 2020

Also cc @sreya92 for thoughts as I know he's been in helm land for a while.

@Matthew-Beckett
Copy link
Contributor Author

To make this chart useful it needs to be published via Github pages.

@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?

What's the advantage to helm here versus shipping a couple basic k8s manifest files?

@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.

@alexgorbatchev
Copy link

alexgorbatchev commented Sep 11, 2020

To make this chart useful it needs to be published via Github pages.

@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?

Sure, I can help.

What's the advantage to helm here versus shipping a couple basic k8s manifest files?

@nhooyr indeed, there is no argument the complexity of Helm charts is considerable when compared to that of native manifests.

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.

@Matthew-Beckett
Copy link
Contributor Author

@alexgorbatchev how would we implement Helm repositories on GitHub pages for cdr/code-server as external contributors to the project?

@alexgorbatchev
Copy link

@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.

@alexgorbatchev
Copy link

alexgorbatchev commented Sep 16, 2020

@Matthew-Beckett in order to get easy github pages hosting, cdr team needs to create a cdr.github.io (see https://pages.github.com/) repo and clone the repo I made as "PR" to the project:

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 index.html with Bash.

The output from the build.sh file looks like this:

❯ ./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.

@alexgorbatchev
Copy link

Please let me know when I can take down the example from my public page :)

@alexgorbatchev
Copy link

@code-asher @nhooyr Could you please have a look at this?

@MnrGreg
Copy link

MnrGreg commented Sep 18, 2020

I'm surprised how fast code-server starts up. Would be interesting to see how well it works with a requests based HPA Scale to 0. Should be able to drive quite a high density of deployments.

Just need HPA Scale to 0 to mature. +1 here: kubernetes/kubernetes#69687

@alexgorbatchev
Copy link

@code-asher @nhooyr ping

@Matthew-Beckett
Copy link
Contributor Author

@code-asher @nhooyr nudge

@Matthew-Beckett
Copy link
Contributor Author

@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 😅

@nhooyr
Copy link
Contributor

nhooyr commented Nov 10, 2020

🎉

@Matthew-Beckett
Copy link
Contributor Author

🎉

Got a bottle of champagne in the fridge I've been saving, this might be the moment 😆

@nhooyr nhooyr added this to the v3.6.3 milestone Nov 10, 2020
@nhooyr nhooyr requested a review from sreya November 10, 2020 20:31
@Matthew-Beckett
Copy link
Contributor Author

Matthew-Beckett commented Nov 10, 2020

@Matthew-Beckett in order to get easy github pages hosting, cdr team needs to create a cdr.github.io (see https://pages.github.com/) repo and clone the repo I made as "PR" to the project:

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 index.html with Bash.

The output from the build.sh file looks like this:

❯ ./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.

@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
Copy link
Contributor

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 👍🏼

@nhooyr
Copy link
Contributor

nhooyr commented Nov 10, 2020

I believe we can just use https://raw.githubusercontent.com/Matthew-Beckett/code-server/feature/helm3/charts/code-server but once it's merged it'd be https://raw.githubusercontent.com/Matthew-Beckett/code-server/master/charts/code-server.

Can you give it a shot and see if it works?

@nhooyr
Copy link
Contributor

nhooyr commented Nov 10, 2020

Ooops, nevermind I'm wrong. I see, we need to serve a tgz file that contains the chart.

@Matthew-Beckett
Copy link
Contributor Author

Ooops, nevermind I'm wrong. I see, we need to serve a tgz file that contains the chart.

Indeed, furthermore, Helm expects a certain HTTP response to list the charts and their version, Helm wouldn't natively support GitHub Release pulling.

@nhooyr
Copy link
Contributor

nhooyr commented Nov 10, 2020

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.

@alexgorbatchev
Copy link

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 brew install - doable, but regrettable :)

@Matthew-Beckett
Copy link
Contributor Author

@sreya @code-asher nudge ☺️

Copy link
Collaborator

@sreya sreya left a 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
Copy link
Collaborator

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
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
$ helm install code-server/charts/code-server
$ helm install code-server code-server/charts/code-server

##
# storageClass: "-"
accessMode: ReadWriteOnce
size: 1Gi
Copy link
Collaborator

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.

@nhooyr
Copy link
Contributor

nhooyr commented Nov 13, 2020

Going to merge and fix comments myself so we can get this into today's release!

@nhooyr
Copy link
Contributor

nhooyr commented Nov 13, 2020

Thanks for reviewing @sreya

@nhooyr nhooyr merged commit affa64c into coder:master Nov 13, 2020
@nhooyr
Copy link
Contributor

nhooyr commented Nov 13, 2020

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 brew install - doable, but regrettable :)

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.

@nhooyr
Copy link
Contributor

nhooyr commented Nov 13, 2020

I opened #2302 regardless though.

This was referenced Nov 13, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants