Agent Creation
Last updated
Last updated
The customer would request an Agent through ISD. Upon request the agent manifest file is available for download and installation in a Kubernetes cluster.
Refer this section to understand how to request a new Agent thru ISD and how to configure it.
When you download and install a manifest file in the customer's 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:
From the application dashboard click on "Setup" and click "Agents" and then click on the "+New Agent" button, as shown in the figure below:
2. Update the required details in the below screen.
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 CD- 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 "Download Agent Manifest" button to download a manifest file as shown below:
Contents of the manifest:
An agent deployment is by default configured for 3 Agent replicas, and has a 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 is 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 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 allows 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.
