Add a New Agent
Last updated
Last updated
As described in the earlier section, OpsMx ISD & the Controller is installed by OpsMx is a public / private cloud which is outside of customers private network (firewall). The customer would request an Agent thru OpsMx ISD. Upon request the agent manifest file is available for the user to download and install it in a Kubernetes cluster. The Kubernetes cluster could be standalone or within AWS cloud. The agent would receive instructions thru controller and would perform actions within the remote private network.
The Agent requires very limited resources, i.e., ~16M RAM, 0 disk currently
Refer this section to understand how to request a new Agent thru OES and how to configure it.
When you download and install a manifest file in the customers remote private network, by default three copies of Agents are created with the same name for redundancy. At any given point of time there is only Agent receiving & executing actions from ISD. If for some reason an agent is not able to take instructions or goes down then one of the other two agents would take over and suffice the requests.
An agent can manage actions on multiple Kubernetes clusters and integrations. But for segregation of responsibilities, a user can choose to create different Agents per cluster or integration type. There are no restrictions on the number of Agents a user can create and use.
The Agent is installed by creating an agent instance in the ISD, downloading and applying the resulting manifest inside a Kubernetes cluster of the customer's secure domain. The Agent connects to the "Controller", which is in the same domain in which OpsMx ISD is available.
To create an agent instance in the ISD follow the steps given below:
Click Setup on the Navigation menu and select the Agent tab as shown below:
2. The list of already created agents appear. Click New Agent as shown below:
3. The create agent screen appears as shown below:
In the above screen enter the following details:
Agent Name - Enter the name of the Agent in the text box.
Cluster Name - Enter the name of the cluster in the text box which you want to access using the Agent.
Description - Enter a description for the Agent. This is optional though.
Connect to Spinnaker - Click the drop-down to select the Spinnaker installation with which you want to connect the cluster.
Click Save.
After creating the agent you will get an option to download the manifest. Click the button to download as shown below:
Contents of the manifest:
An agent deployment is by default configured for 3 Agent replicas, and has configuration for memory limits and CPU limits. These limits are currently very small, but should be sufficient for most installations. These are currently 64 MB of RAM, and 0.1 CPU usage.
A Kubernetes secret for the TLS certificate needed to contact the controller, which is the OpsMx managed side of the system.
A Kubernetes Config Map for how to contact the OpsMx controller, such as hostname, port, and CA certificate to use to authenticate the connection.
A ServiceAccount for the Agent.
A ClusterRole and ClusterRoleMapping to allow access to the Kubernetes cluster the Agent is installed into. Currently this will need to be modified if access is to be restricted at the Agent level.
A Role and a RoleMapping allowing the Agent to read any secret from the namespace it is installed into. This is required to allow the Agent to read secrets dynamically, rather than needing to modify the Agent deployment to add secrets for configured services such as Jenkins.
All auto-installed components will have a label of "agent.opsmx.com/name" and "agent.opsmx.com/role" assigned. The role will be "agent" in all cases, and the "name" will be whatever name is assigned at the time of creating the agent. Other than the ClusterRole and ClusterRoleBinding, all components are created in a namespace opsmx-agentX.
The Agent also mounts and requires a user-supplied configuration to specify which services the Agent advertises to ISD. This configmap must be named "opsmx-services-agentX" where X is a value assigned by OpsMx.
Secrets associated with the services will also need to be created in the same namespace. The secret names can be anything allowed by Kubernetes. The secret contents are read dynamically by the agent at startup. These service-specific secrets are never transmitted to OpsMx or any other party, other than the services configured to use them.
NOTE: Currently the secrets are not refreshed if they change. However, in a future release, secrets will be periodically refreshed.
