RPS Automation Package Guidelines
The RPS is designed to be a re-usable solution that offers similar, flexible functionality for programs, efforts, and automations requirements. It is a solution that was initially designed to survive the inherent constraints and challenges that have been observed within a mobile tactical network. The goal of this design is to create a stable, secure, and highly automated management infrastructure solution to provide the following (but not limited to) capabilities:
How to Load an Automation Package
An Automation Package is typically loaded using a Load Script. The load script is flexible, but is coded to simply place the components for a given automation package in the proper locations. This script is typically only executed one time to initially load a set of functionalities, scripts, metadata, or other configuration information into the RPS system. This script is run once during the initial load of the Automation Package. This can occur at initial system build, or after the system is already established, and should contain all logic necessary to add itself to the RPS system.
Some common actions a Load Script may take will include:
- Inserting MetaData into the RPS CMDB
- Placing Powershell Scripts and Modules into the appropriate locations defined for RPS, this will allow the system to automatically register and load them for use (See Section 2.5 for info on placement)
- Placing external software components used by those Scripts and Modules into the necessary locations as coded by the authors (E.g. VMWare tools being installed)
- Inserting TaskItem and TaskMap metadata into the database. These are the definitions of what should be run, targeting what devices, and in what order.
Once the load script is executed, it is typically removed and no longer required. The initial insert of data serves as a way to inject new business logic into the system. From there, the system will function based on the inserted POR authored Automation Package.
Post-Load Actions and Activity
Once a package is loaded, business requirements begin to dictate what will happen next. For example, if the Load Script is coded to activate automation work on load, then RPS actions will begin immediately processing.
If the Load Script is not coded to activate automation work on load, the following RPS components can be used to control and trigger automation execution
- IsActive settings
- PendingUserActions
- TaskAssignment creation
- TaskMapAssignment creation
Using these core functionalities, automation can be triggered, controlled, and centrally managed on an as-needed basis. Post-Load activities are controlled by the needs of the business, and should be coded to support the intended execution model.
Format of an Automation Package
The format of an automation package should follow the folder structure of the build output that RPS produces, and either be included with the initial set of installations of an RPS software stack, or placed into the same folders once RPS is already installed.
For example, using the figure below showing a sample build output from RPS, there are clearly defined locations for various components of an Automation Package. There are folders and descriptions for the intended location of specific components already defined. The format of the Automation package will vary depending on business use and intended uptake of the content.
Build Output and Automated Support
Some folders supplied as part of the RPS Build output will support automated control and placement of inserted code product. This section will explain which folders are supported and by what action or activity:
| Term | Definition |
|---|---|
| Certificates | This is a general store for storage of certificates required by the system. Some are controlled automatically, but this is done per certificate currently. |
| DSC | This folder is used to hold both DSC configurations and Resources. The RPS support of DSC processes are coded to look to these locations for supporting DSC resources and configuration files. |
| Modules | Any PowerShell modules located in this directory will be automatically placed into the appropriate PowerShell Modules directory on the server RPS is installed on. Once this directory exists on a server with RPS installed, any newly added modules will be copied on next pass of the DSC configuration (typically 30 minutes). |
| Runbooks | Any runbooks in this directory will be automatically loaded and registered into SMA. Once this directory exists on a server with RPS installed, any newly added Runbooks will be registered to SMA on next pass of the DSC configuration (typically 30 minutes). |