Writing a System Agent
Learn how to design a system agent in Go.
We'll cover the following...
So far, when we have automated operations on a device, we have either done it from an application that executes locally or through a command we run remotely with SSH. But if we look toward managing a small fleet of machines, it can be more practical to write a service that runs on the device that we connect to via RPCs. Using knowledge of the gRPC services we discussed in previous chapters, we can combine these concepts to allow control of our machines in a more uniform way.
Here are a few things we can use system agents for:
Installing and running services.
Gathering machine running stats.
Gathering machine inventory information.
Some of these are the kinds of things Kubernetes does with its system agents. Others, such as inventory information, can be vital in running a healthy fleet of machines, often overlooked in smaller settings. Even in a Kubernetes environment, there may be advantages to running our own agent for certain tasks.
A system agent can provide several advantages. If we define one application programming interface (API) using gRPC, we can have multiple OSs with different agents implementing the same RPCs, allowing us to control our fleet in the same uniform way, regardless of the OS. And because Go will pretty much run on anything, we can write different agents using the same language.
Designing a system agent
For our example system agent, we are going to target Linux specifically, but we'll make our API generic to allow implementation for other OSs to use the same API. Let's talk about a few things we might be interested in. We could consider the following:
Installing/removing binaries using
systemd.Exporting both system and installed binary performance data.
Allowing the pulling of application logs.
Containerizing our application.
For those of us not familiar with systemd, it is a Linux daemon that runs software services in the background. Taking advantage of ...