Make a better YAML

The idea started with this issue: - #52
Why not use all my learnings as a DevOps Engineer to build a better YAML to install Kube-ez.
I will keep this open, to keep building on it.
The File I am referring to is here: - one-to-rule-them-all.yaml

Just learnt about a great in-built function in Go that handles panic situation. It will be an easy issue. I will post more details once I get back home from office 👍

Right now the project is using the client-go library and the rest k8sio APIs to query the API server each time the request comes in. This idea is surely not scalable if the traffic increases. I want to rewrite the project and use ShardInformers in place of multiple calls to API Sever of the master node.
If you wanna ask, why didn't I make the project using shared informers in the first place, I just wanna say:

I know I have already optimized the size of the Docker Image used in this project.
But recently I came across a great resource to make Industry ready images.

So, why not include them!??

Here is the Twitter Thread I am referring to : Here

Add practices like retryMax, timeout for requests.
Mainly write a middleware to handle most of these logic
DRY

How the HELL did I miss it!??

I can make a Deployment for the YAML file. This deployment will handle the Pod, and will restart the pod in case it dies of natural causes XD

I will update the YAML File to include it.

Folks! this is PROOF, that nothing good happens late night.

I want to implement more ellaboarte logs in this project.
I will be using Logrus for this purpose.
I am bored this weekend so why not kickoff this old project with an easy task

TBH looking right now at the CI of the project all I can say is:

YES! it hurts to look at such a shitty CI.
What I am looking at?

• A CI that builds binary for each push.
• Uses that binary on the docker image.
• Run that docker image in a Kubernetes cluster.
• Run all the Unit tests against the preexisting functions.

Will I be able to do it??

MAYBE

Let's give it a try!

I am looking into different methods to making this project more secure.

Use this to find the vulnerabilities of my code. We might have to find an automated process to integrate it into github actions so that each push is tested for vulnerability

I know this repository has Documentation for the API already : Here

But I recently learned there are industry standard way to do this.
I have added the postman collection for reference : Here

For this task I was looking forward to use something such as Swagger

I will provide the detailed steps, real soon!

This started here:

• #22 (comment)

I want to run the CI runner only when there is a change in the Go codebase.
WTH is my CI running when I did changes to simple Markdown?

I know it doesn't cost me anything to run the CI.
But it is actually a waste of resources of GitHub.
Github might start getting charged in future
It is out of my training as a DevOps engineer to waste resources.
.
.
.
Mainly I can't sleep, so let's do something😅

So this project can be run on curl or on Browser.
Web Browsers by their nature have this irritating nature to bug the API with a GET Request to "/favicon.ico"
I am no wiz in Frontend, but what I learned is that it does this to get an icon for the tab.
I don't have any problem with it, only that this is making my Logs look ugly !
Without any reason I am seeing 500 error codes in my logs for a URI I never intended to make.

I want to disable this. No matter the cost.
Anyone is welcome to do it! Or else:

Tracking issue for:

• https://github.com/kitarp29/kube-ez/security/code-scanning/1

Right now the CI is set up such that every successful build of Docker Image will be pushed to ghcr.
But this is very risky, as I am not scanning for CVEs. Neither I have Image scanning open on my Docker Hub as I am broke.
So we need to find some CLI-based Docker Image Scanning Jobs in the CI.
Refer to This: Here

Since we are making a project that has to manipulate one's cluster, we should have email triggers set up. Emai, triggers can act as AWS SNS. I am even not sure if it can be implemented in what manner, but surely can be handy feature.
You might want to use this package Email

Can we build a CLI version of this project using this??
I know I know, CLI version of a K8s-api is just kubectl ("as if I didn't knew")

But still, it would be cool to build a CLI with this
CLI-Maker

We could actually make a Helm chart to ease the process of installing this project on any k8s cluster

Implement a better Logging setup. You can implement a better logging system using logrus.

Right now the Image is like 500 MB or something I am not happy with it
I want to reduce to at least half.