You can create or upload state files and pillar data in the Automation Config File Server and Pillar workspaces. If you don’t want to use the File Server, Automation Config also supports connecting to an external repository (such as a Git repository) where you can save your state files and pillar data.
Instead of manually configuring each node or application one-by-one, you can use the Automation Config state management system to create state files that you can apply to many nodes simultaneously. These state files can include a set of instructions that tell Automation Config which operations should be run on the node and in which order. They can also explain which configuration files or settings should be applied.
After you’ve written or modified a state file, you can automatically run these state files and apply them to many nodes at once. You can target nodes based on each node’s inherent properties (such as its operating system) or you could also target nodes based on custom labels that you define. See How do I create targets? for more information.
The state management system also ensures each node is configured properly and as efficiently as possible. If a configuration has drifted, Automation Config can put nodes and applications back into its compliant configuration state. If a configuration needs to change, Automation Config can quickly deploy those changes to the affected nodes.
State files are usually written in YAML and Jinga, but other formats such as JSON are compatible with Salt. A typical state file might look like this:
install_apache:
pkg.installed:
- name: httpd
ensure_service_running:
service.running:
- name: httpd
- watch:
- pkg: install_apache
default_html_page:
file.managed:
- name: /var/www/html/index.html
- source: salt://apache/index.html
This state file has three steps that run three different Salt execution modules. When this state file is applied to a minion, Automation Config:
Note:
It is recommended and best practice to reserve Pillar data for sensitive information. Pillar data increases the resource load on the associated salt master, and as a result it is recommended to use configuration map files for all other information.
Pillars are structures of data stored on the Salt master and passed through to one or more minions that have been authorized to access that data. Pillar data has two main use cases:
Data stored in the Automation Config Pillar Store is encrypted using the Raas encryption key associated with the specific instance of Automation Config (for example: “/etc/raas/pki/.raas.key”). Once the Pillar data is defined in the Automation Config UI, it is encrypted with this key and stored in the PostgreSQL database. This key is also used to decrypt the data for display in the Automation Config UI.
Pillar data is assigned in Automation Config through the pre-defined target groups of minions.
When pillar data is assigned to a specific target system and included in state files, it is processed by the master for each minion system. During processing, the data is encrypted with a separate AES key for each minion for transmission to the target system during a state or orchestration file application.
Once pillar data is defined and saved, click Update Targets > Select targets to attach pillar > Save to assign the pillar data to a group of minion systems.
Pillar files are usually written in YAML and Jinja, but other formats such as JSON are compatible with Salt. Pillar data is stored as a dictionary and uses key-value pairs to look up values. A typical pillar file might look like this:
pillar1: value
pillar2:
- value
- value
pillar3:
sub_key:
- value
- value
This example shows three different methods for formatting your pillar data. The syntax you choose to use will depend on your needs and the type of data you need to store.
Because Automation Config is powered by Salt, it helps to have a basic working knowledge of Salt and the concepts related to these features. The following table lists some helpful resources for more information:
To learn about… | See |
---|---|
The basics of working with Salt | |
Salt states | |
Pillar data | |
Salt execution and state modules |
After defining your pillar data, you can assign the pillar data to a group of minion systems by clicking Update Targets, selecting the target group, and then clicking Save.
When pillar data is assigned to a specific target system and included in state files, it is processed by the master for each minion system and encrypted with a separate AES key for each minion. This key allows the pillar data to be transmitted to the target system during a state or orchestration file program.
To add a state file to the File Server so that it can be used in jobs:
.sls
. For example, /my-directory/my-state-file.sls
.Although you could use the Automation Config Pillar workspace to add pillar data to the Salt master, it might be easier to add the pillar data directly to the Salt master. To add pillar data so that it can be referenced in state files or assigned to targets, you could do one of two methods:
salt-run
command, which uses the Salt runner feature. See How do I create jobs? for more information.After creating state files and pillar data that can be accessed by the minions, you can then reference these files in jobs that you create in Automation Config. See How do I create jobs? for more information.