search

SQuent / kuma-ingress-watcher

9 stars 2 forks source link

Adding ingress controller #20

Closed angelosnm closed 1 month ago

angelosnm commented 2 months ago

Adding ingress controller for controlling ingress objects along with ingress routes.

Also added a seperate "dev" environment functionality where one can use the codebase when outside of a cluster.

SQuent commented 2 months ago

Hello @angelosnm and thank you for your interest in this project! I don’t know if you’ve seen it, but last week a new version was released with the Ingress feature now supported. I also refactored the code to make it easier to add new features in the future.

I’m particularly interested in the devcontainer part you proposed, as it could really simplify development. Another interesting point is your handling of the Kubernetes connection initialization, which covers more cases than what I had anticipated. What use cases do you have in mind? Is it mainly for use with devcontainer?

The application is primarily used with the Helm deployment found here which deploys a ServiceAccount with associated ClusterRoles but we can add some other connexion options.

angelosnm commented 2 months ago

Hello @SQuent !

Indeed I hadn't noticed the update! I was working on this fork few weeks back and I just made the PR. Since this part is now covered then this PR can be rejected.

Although I have two minor suggestions for the project as a whole.

1) Usage of Upting Kuma API for authenticating instead of using username/password for security reasons. (Thus, make the user to create API keys to use the application).

2) Instead of using the name of the Ingress or the Ingress Route object for the name of the monitor, use its host. I was working on that and personally I find it more convenient as this makes easier to identify which endpoint is monitored. (I am working on a cluster with lots of services & microservices and as an administrator I want to have easy access without having to click here and there all the time). Although this may be a little bit of a personal quirk :laughing:

In regards with the rest of your points, both have to do the simplicity of the development procedures.

The Devcontainer is about setting up a containerized environment for developing without having to worry about messing up dependencies. (You can read more here https://code.visualstudio.com/docs/devcontainers/containers)

The Kubernetes connection initialization has to do with the two runtimes of the application.

The first runtime is when the application operates as a pod inside the cluster (this is where you need to use the load_incluster_config()) and the other is for when you're working on its development outside of the cluster (this is where you would need the service account token or any other method that the k8s client provides for authentication).

I am using the Helm chart too (which btw is pretty nice) and I created a token for the given ServiceAccount with which I was working.

I am happy to discuss more about ideas and I will be more happy to contribute to this project even more :smile:

SQuent commented 1 month ago

Hello @angelosnm,

Thank you again for your suggestions and feedback! 😄 I absolutely agree with both of them.

  1. The first point regarding using the Uptime Kuma API keys for authentication is a great idea! Having the option to choose the authentication method would indeed improve security, and it shouldn't take too much effort to implement.

  2. As for the second point about using the host name instead of the Ingress or IngressRoute name, I hadn’t considered that, but it definitely makes more sense, especially when you have multiple hosts within the same Ingress. This is much more user-friendly for managing multiple services, and I don’t foresee a large refactor to make this change.

With the devcontainer addition, that makes three tasks lined up! I’ll try to tackle them in the coming weeks, but if you need any of them sooner, or just feel like contributing further, feel free to take one on.

By the way, I’m using Conventional Commits for automatic release setup based on commit messages, so if you make another PR, please feel free to follow that convention.

Thanks again, and I’m looking forward to collaborating further!

angelosnm commented 1 month ago

Thank you!

I'll see what I can do about them in the coming weeks too! (Once I catch up with my usual k8s tasks)