The technical term for the desired state in Salt is highstate, which is shortened from high-level state. It describes the goal of the state. The name is a frequent cause of confusion because it seems to be the opposite of a low state, which is described almost nowhere.
The low states, or the low-level states, are the steps Salt takes to get to the goal. Since the compilation of the goal to the low-level states is done internally, nothing in the user-facing documentation talks about a low state, thus leading to confusion.
The following applies the desired state.
$ salt '*' state.highstate
Because a lot of confusion is caused by the name highstate, an alias was created.
$ salt '*' state.apply
Again, both do the same thing: figure out the desired state for all machines and then issue commands to reach it.
The state is described in SLS files. These files are usually in the YAML format and describe the desired state.
The usual way to configure is one file top.sls, which describes which other files apply to which machines. The top.sls name is used by default as the top-level file.
A simple homogenous environment might be as follows.
# top.sls
base:
'*':
- core
- monitoring
- kubelet
This example would have all machines apply the configuration from core.sls (presumably, making sure the basic packages are installed, the right users are configured, etc.), from monitoring.sls (presumably, making sure that tools that monitor the machine are installed and running), and kubelet.sls, defining how to install and configure the kubelet.
Indeed, much of the time, Salt configures machines for workload orchestration tools such as Kubernetes or Docker Swarm.
0 comments:
Post a Comment