BotFactory is TRiA’s answer to easy policy automation. The user is able to select from a list of predefined filters, which match resources, and actions, which act upon those resources. If the predefined filters and actions aren’t sufficient for a user’s needs, it’s possible to create new filters and actions that provide the needed functionality.
Components: scope, filters, and actions
BotFactory contains several components which comprise the system. They are scope, filters, actions, and when the bot should run.
Scope specifies the resources the bot will evaluate and is defined using several properties. For example, a bot may have its scope confined to resources of a certain type or it may have its scope confined to resources contained within specific resource groups or cloud accounts.
Filters specify what a bot should act upon. For example, a filter may match each resource based on tags that it does or does not have or it may match based on ports that are or are not open. There are numerous filters included with BotFactory and it is possible for a programmer to define her own.
Actions specify what a bot does. For example, an action may delete a resource, it may start or stop an instance, or it may send an email containing information about the evaluated resource. Actions are executed for a single resource at a time. When a bot possesses multiple actions, the actions are executed in order. There are numerous actions included with BotFactory. As with filters, it is possible for a programmer to define her own actions.
TRiA bots can spawn jobs that run at specified times with specified arguments. These jobs are called scheduled events.
Evaluation is the process of going through scope, filters, and actions. Scope determines which resources are queried, filters select the matching resources from the scope, and actions are executed for matching resources.
Of note, filters and actions can be defined such that bots act upon resources that do or do not match filters or some combination of the two. Therefore, the evaluation process can be quite simple or sophisticated depending on your specific need.
For example, a bot that takes remedial action against resources that are in an unwanted state could be structured in one of two ways. First, the bot could have filters that select for the unwanted state and its remedial action would execute against matching resources. Alternatively, the bot could have filters that select for an acceptable state and its remedial action would execute against not-matching resources.