helm chart (and perhaps a terraform module)

[ayushin]

I think it would be really awesome if django-cookiecutter would have an option helm_chart=y that would produce a secure helm chart (or rather helm chart values.yaml for a standard django-cookiecutter helm chart) to facilitate deployment to any cloud infrastructure out of the box.

That would take this project to a whole new level and once you have that one could easily add a terraform module to take it even a level higher.

Anybody having the same thoughts?

We have some custom helm charts we use for our django deployment that I am willing to make open source and we took some (a lot of) inspiration from https://gitlab.com/glitchtip/glitchtip-helm-chart

[ayushin]

A lot of interesting insights!

https://gitlab.com/glitchtip/glitchtip-helm-chart/-/issues/5#note_451868819

[omarsumadi]

@ayushin I'd love to help with this - however, I am a Kubernetes novice. I'll chip in where I can

[ayushin]

Great, I'll make a start this week and we take it from there.

[omarsumadi]

@ayushin It might take me a while to get up to speed - I don't want to make any impressions that I'd be some more of great productive member, but if I see where I can chip in, I will help

[grstein]

Hi! I work in an infrastructure (ops) team in a big governament agency in Brazil and we use K8S to support our applications. We developed our own Helm Chart to deploy internal Java applications. I have experience in developing Helm Charts and you can count on me to solve this issue.

[omarsumadi]

Also working on this now that I've gotten time to go back to Kubernetes.

• Shooting for Promethius and Grafana with Custom Metrics for Celery horizontal scaling.
• Going to keep Traefik as the Ingress

[ayushin]

we already running a number of django projects internally with helm, i think i can make our charts open source.

the work would be to tailor them to the actual cookie-cutter configuration

[omarsumadi]

@ayushin expose them, even if no one picks it up (I don't know how to do that yet, still junior), it will help someone. Worst case scenario it helps someone out haha.

[rustanacexd]

This would take the project to the next level

[ayushin]

Hi, I am sorry I just realised that I published our internal helm charts in December but never posted the link.

https://github.com/apexlabs-ai/django-helm-charts

[grstein]

I've made some progress: https://github.com/grstein/cookiecutter-django

Now one can select yes to use_helm for cookiecutter and it will render a nginx helm chart (output of helm create). The problem is that helm uses Go Templating, which, in turn, uses the same double curly-brackets sintax. So, we need to use Jinja's {% raw %} and {% endraw %} to escape the variables within yaml files.

Next step is to port @ayushin's templates.

[ayushin]

So, I guess there a number of things we should made configurable (some are already in the helm chart):

• postgres deployment / external database
• redis deployment / external database
• celery worker/beat instance yes/no
• extra env variables
• extra env secrets (like AWS_... etc)
• google cloud credentials

Also for the good order, our templates are based mainly on https://gitlab.com/glitchtip/glitchtip-helm-chart/

[bufke]

I'm updating the GlitchTip chart a little now. Eventually I'd like it not to be specific to GlichTip at all. My first priority is updating against a brand new helm create template. @ayushin that list is pretty close to what I'd like to improve myself, except maybe google cloud as that's vendor specific. Let me know any broad level improvements or ideas you come up with.

[bufke]

Also I think I'm going to get more consistent about template filename convention.

web-deployment web-hpa worker-deployment worker-hpa beat-deployment

vs

deployment-web deployment-worker deployment-beat hpa-worker hpa-web

Let me know if anyone strongly prefers one way or another. I keep going back and forth in my mind as can be seen by me editing even this comment :)

[ayushin]

Those are hard problems! :-) For some reason component-resource_type sounds more logical, I guess you are more interested to see the files grouped by component vs by the resource type.

Re Google Cloud - the cookiecutter-django allows you to configure google cloud or AWS out of the box, so an optional support for both makes a lot of sense for me, especially because you can't add it to the chart post-install - i.e. you need to add a mount point to the container etc

I am not sure if this project should be a part of cookiecutter - ideally we would make it independent as the chart itself won't be changing with each django project and it should be possible to refer to it's helm repository from any project using django-celery-redis-postgresql

[bufke]

component-resource_type follows the syntax in values.yaml better.

[bufke]

This is a good example too https://github.com/itswcg/django-helm

They use app.kubernetes.io/component instead of how I use "role". That's a recommended label.

They use directories to organize the various components.

[bufke]

https://gitlab.com/glitchtip/glitchtip-helm-chart/-/merge_requests/1 has been updated for most of what I wanted done. I made directories for components.

One problem is that helm can't seem to correctly replace instead of update the deployments. Strangely, helm diff is very clear that the deploy contains changed immutable values and must destroy and create the deployments. This is probably a helm bug. It can be worked around by destroying the deployments manually.

[bufke]

I finally removed every reference to GlitchTip now https://gitlab.com/burke-software/django-helm-chart/

This chart is being used to host 8 different applications including larger ones like Saleor now.

[Exchizz]

What's the status of this ? :)

[elcolie]

Any update on this?

[foarsitter]

In my opinion is the end product of the project a container. There is nothing special to Django or this project that requires a specific solution. When some masters containers in general and is familiar with helm specification deploying on k8s is no big deal.

Since three years there has not been a PR so I think we need to close this as not plannend.

[browniebroke]

I agree with the above, it feels out of scope of the project. While I've used Terraform a few times, I don't have any real experience with helm charts, so I don't feel comfortable adding this to the project and maintaining this. We gave it some time, but realistically it won't happen unless someone steps up.

Thanks everyone who contributed, there might provide some useful links for folks who are interested.

[ayushin]

This is what we use in production

https://github.com/djangoflow/terraform-kubernetes-django

We moved from cookiecutter to copier, but it's quite similar.