Helm charts in template?

Hi there, we're taking our first baby steps with coder at the moment. We're trying to figure out how to get better dev/prod parity. For production, we use Gitlab's CI/CD to deploy our container images to a K8S cluster running in Google's GKE. We use helm charts for each project to cut releases into production. This works well for production, but for dev we currently more-or-less replicate the whole helm chart in our

docker-compose.yml

docker-compose.yml

docker-compose.yml

docker-compose.yml file.

As we move to Coder, what's the path for creating a template that makes use of our production helm charts? Would we install helm and use it in a startup script? https://coder.com/docs/v2/latest/templates#startup_script

Or is there a better way to use helm?

Or is there not a good answer here for helm+dev/prod parity and we should start moving away from helm (currently pretty costly with ~30 in-house created and maintained helm charts)?

Templates - Coder v2 Docs

Learn about templates, which define the infrastructure underlying workspaces

kyle•2/14/23, 9:19 PM

You might be able to use the Helm provider itself!

https://registry.terraform.io/providers/hashicorp/helm/latest/docs

Then with each provisioned container, just start the Coder agent.

Terraform Registry

DonOP•2/14/23, 9:51 PM

@kyle Ah, I think I see now. OK, I'll give that a go!

kyle•2/14/23, 9:51 PM

Please do! If you have success let us know, I think you'd be the first to do this!

Scott•2/15/23, 5:05 AM

@Don - I'm also learning about how to use Coder too with k8s. My take is, the workspace (its container) should only have to replicate what the app being developed on needs to run and be developed.

Complimentary to that, you'd need to also have the services necessary for the app to do its work "wired up/ prepared" for any communication/ data needs. For instance dev database(s) created, migrations done (if using SQL), any data migrations or seeding done and setting up access keys/ credentials to work with the services/ databases/ cache, etc.

The only thing I know of that has to definitely be generated before the workspace can start is the k8s namespace, where the workspace should do its work in (and also not forgetting to give the Coder service account permissions to work outside of the Coder workspace).

So, I'd venture to say, the Terraform templates should be used for as much of that prepping/ building as possible, because when the workspace is destroyed, Coder can also have anything, which was created to make the workspace "workable" for remote dev'ing, also destroyed.

I've also seen discussions, where others see Coder as the nothing to all to nothing orchestrator (via Terraform). By that I mean, firing up a workspace means ALL infra is generated, kind of like with a docker compose file. (Not using k8s). I think with k8s or rather in a k8s cluster, that is not necessary, especially if you are going to be firing up workspaces a lot (which I also believe should be per dev task). A lot of the services/ databases can already be up and running and should be, to save developer time, which is probably infinitely more expensive than the infra costs.

In other words, a dev process to accomplish a task should be, fire up a workspace, do the work, commit and close the workspace. Wash, rinse and repeat. Even the cloning, committing and pushing could be automated this way. That is were we are heading.

Scott•2/15/23, 5:06 AM

.
Helm charts install applications/ services into k8s to generate the application's specific infrastructure and services needs (along with firing up the applications). To me, they shouldn't even need to be used, as I mentioned above, the infra should be, for the most part, already there and waiting, in order to have access to workspaces be as quick as possible.

Scott•2/15/23, 5:09 AM

Theoretically, you could also develop the helm charts with Coder, but that is a devOps task and to me, that can also still be done on their own workstations/ laptops.

DonOP•2/15/23, 3:25 PM

@Scott Thanks for laying out your detailed thinking on this!

I have more thoughts/questions and I'll try to get them typed up here this morning.

bpmct•2/17/23, 9:53 PM

I'd agree with Scott. Using Terraform to provision inner-workspace infrastructure is a bit tricky (e.g. provision a namespace, then helm on the namespace).

In the Helm example, I think it makes the most sense to only provision the outer layer with Terraform and then use scripts or something outside of Terraform to spin up the rest.

Helm charts in template?

Similar Threads

Similar Threads

Similar Threads