Giters

CTFd / CTFd

CTFs as you need them

Home Page:https://ctfd.io

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

[Question] Helm chart contribution

ScribblerCoder opened this issue · comments

commented

Hello there,

I've been working on a Helm chart for deploying CTFd on Kubernetes (Did not publish it yet). I was not able to find any serious high effort helm charts that truly embraces main Kubernetes concepts like Autoscaling/HA.

In fact one of the only helm charts I found clearly says that its "for fun".

Also @bman46's chart is worth mentioning but is still doesn't support autoscaling

I was wondering how open the project is to contributions in this area. Is there anything specific you're looking for, or any particular standards I should adhere to with these contributions? Would love to align my efforts with the needs of the community.

Features I covered so far

  • HA and horizontal autoscaling with CPU and memory metrics
  • Configurable CPU/memory requests and limits
  • Deploy bitnami Redis and bitnami MariaDB as Helm dependencies
  • Option to use external Redis and MariaDB (e.g., AWS RDS, ElastiCache)
  • Customizable CTFd configuration
  • Adjustable configurations for Redis and MariaDB
  • Integration with upload provider (AWS S3 or Persistent Volumes)
  • Liveness and Readiness checks (Healthcheck)
  • Affinity/Toleration/nodeSelector rules
  • Autoscaling with custom metrics (Req/sec, # of sessions)
  • Deploy self-hosted mail server for CTFd email notifications as a helm dependency
  • Automated backups (CTFd export. This could be done with batch/v1 CronJob)
  • Deploys postgres db as a helm dependency
commented

@ScribblerCoder Sure if you want to PR this you can but I don't have a ton of experience with Kubernetes (although not for lack of trying). For some time it will need to be community supported but eventually we could see more k8s focused deployment options.

@pve this isn't really a place for you to farm impressions for your project. The issue tracker is more about "how can we improve CTFd" rather than "link to a fork and come work on it". I am assuming good intent but I'm seeing links to your project too often so please tone it down.

commented
commented

Same thing over here, we (CTFer) try to contribute to the CTFd ecosystem by solving open problems in both the CTF area and the CTFd technical aspects.
Won't develop further as it seems not to be really open about it...

commented

I really don't see how anything I said is equal to not being open but okay.

The issue tracker is fine for discussion but it isn't for advertisement. I would expect conversation like "we have implemented X Y Z, would like to see it in your changes" instead of a link which means we all need to dig through it to figure out what the actual content is. A link with supporting information is fine but the substance should be within the comment.