Within infrastructure as code, as with all programming, there is a goal to reduce redundancy as much as possible. With configuration management, duplicated configurations can quickly lead to confusion and unexpected states. One of the key ways to reduce configuration duplication is robust host classification.
As this post is about SaltStack, the terms "minion classification" for "host classification" and "minion" for "host" are used. With Puppet, "node classification" and "node" would be used.
Minion classification consists of rules that determine what a minion is and which states (or configurations) should be applied to it. Good minion classification removes or minimizes the necessity of explicitly assigning configurations to a minion. Our goal is for the computer to do as much of the work as possible.
Minions are added and configured from the primary salt server (called the
salt-master) with the following Minion ID schema:
HSTis the hostname or role. It indications what services are running on the host or the role that it serves.
PODis the pod or group. It indicates the logical grouping of the host.
LOCis the location. It indicates where the host is.
The Minion ID parts are matched against the following list. SaltStack pillar data, like Apache2, uses a last declared wins model. The following list is organized from least-specific to most-specific:
4_POD__LOC(pod/group and location)
5_HST__POD(host/role and pod/group)
Using our Minion ID examples above, this allows configuration data to be specified for both shared data (ex. WordPress security settings that should be applied to all WordPress hosts/roles) and specific data (ex. Let's Encrypt TLS/SSL settings).
The only grain which can be safely used is
grains['id'] which contains the
Minion ID. (FAQ Q.21)
It is important to rely only on the Minion ID as all other grains can be
manipulated by the client. This means a compromised client could change its
grains to collect secrets if a dedicated grain (ex.
role) was used for minion
Imperfect Work in Progress
This implementation has proven to be robust and helpful. However, there is
still room for improvement. For example, I will probably refactor
GRP for added clarity.
Feedback and development is welcomed.
The creativecommons/sre-salt-prime repository is open source.
This host classification is also documented within it: sre-salt-prime/Host_Classification.md at master.