Open praetorian-peter-mueller opened 2 weeks ago
praetorian-peter-mueller
commented
2 weeks ago Related question @privateducky — in order to be tested, do capabilities currently need to be run inside the context of the overall Chariot container? Or can they be run on their own, in a standalone manner?
privateducky
commented
2 weeks ago Related question @privateducky — in order to be tested, do capabilities currently need to be run inside the context of the overall Chariot container? Or can they be run on their own, in a standalone manner?
They can be run either standalone or in a container. The latter is the only option when the capability is deployed with Chariot however.
Feature Description Currently, all of Chariot appears to run in the same container, defined here. I suggest that capabilities be run in their own individual containers instead.
Problem The following limitations exist:
Preferred Solution Implementing a container orchestration system is a logical solution to these problems.
Alternatives Considered We could instead implement capabilities as REST APIs, but the juice probably isn't worth the squeeze, in terms of the effort to implement vs. expected value.
Additional Information I know this isn't going to get done right now, but it should be on the backlog, and here's why:
We have currently implemented our own "capabilities manager" in cmd/capabilities/main.go. As we add more capabilities, each of which has slightly different requirements, I predict that this file (or others like it) will grow in size and complexity to meet the needs of an increasing number of use cases. When this happens, the capabilities manager will become a more frequent source of bugs and performance bottlenecks.
At this point, migrating to a container orchestration system will let us simplify the capabilities manager by offloading the implementation to k8s. All we'd need to do is provide declarative configuration details that account for our specific use case.