1. What the Ops Project Is
I introduced a commonly used Ops tool in an earlier article.
The design philosophy behind Ops is that the core of an operations tool lies in text distribution and script execution; once these two capabilities are in place, they can satisfy operational requirements.
My main operational targets at the moment are Host machines and Kubernetes clusters, so at the OpsObject layer I implemented the Host and Cluster objects, corresponding to hosts and Kubernetes clusters respectively.
On top of that, I implemented file distribution and script execution for hosts, and file distribution and script execution for Kubernetes clusters β the Core capability layer.
Thanks to the capabilities of the Core layer, I can already do some simple operations work, such as: adding hosts in bulk, and installing or changing Prometheus in bulk.
2. Ops Server and UI Features
In the architecture above, I provide three entry points: opscli, opsserver, and opscontroller.
Since the requirements of earlier work had already completed the opscli and opscontroller components, I recently filled in some functionality of the opsserver project and a simple UI. It can now be installed directly via helm charts; for details see https://www.chenshaowen.com/ops/ .
Below are some screenshots of the features:
- View the list of managed hosts
Ops automatically syncs information from hosts on a schedule, such as: hostname, CPU, memory, disk, system information, and so on.
- View managed clusters
Ops automatically syncs information from clusters on a schedule, such as: version, node count, Pod status, certificate expiration time, and so on.
- View Task objects
Task is the reusable-level object as I define it; it lets operational capabilities be consolidated and shared, enabling standardized operations.
By specifying a particular host or cluster through a Task and setting variable values, you can execute an operations task by creating a TaskRun object. Tasks also support scheduled execution.
- View TaskRun objects
A TaskRun object contains the basic information of the task, including: task name, specific operations, execution results, and so on.
3. Next Steps
At present, iteration on the Server side mainly follows the requirements of the Copilot project.
LLMs are good at analyzing and answering questions, producing a solution or a series of Commands, but an LLM cannot directly execute those Commands. As shown above, the goal of the next iteration of Ops Server is to integrate well with the LLM, so that the LLM can understand the design intent of Ops Server and, after outputting Commands, directly convert them into Actions with real effect β giving the LLM genuine operational capability.
The point of this design is:
- No need to execute commands or configure credentials locally
- Supports bulk host and cluster operations
- Remote execution environments are more constrained, and more secure and auditable
- The remote end can be configured to perform more flexible and complex operations
Put simply, Ops Server provides a kind of remote operational capability that connects to LLM applications through an API to achieve automated operations.
