Solution Overview
Modern Configuration Management solution revolutionizes IT operations by centralizing configuration management, operations automation, and state management, ensuring streamlined workflows, consistent configurations, and fortified security and reliability.
VMware Aria Automation Config (formerly vRealize Automation SaltStack Config) is a versatile Modern Configuration solution that seamlessly operates with virtual machines, bare metal machines, and IoT devices across various cloud platforms and physical hosts, supporting a wide array of Operating Systems such as Linux, Windows, Mac OS X, and Unix.
Benefits
- Configuration Automation: Automate system configuration standards and application configuration
- Desired State Enforcement: Ensure consistency across your IT infrastructure with event-driven technolgoy
- Continuous Compliance: Streamline compliance standards with automated remediation
- Closed-loop Vulnerability Management: Enhance security and automate patching at scale
Architecture Design
VMware Aria Automation Config architecture consists of four main components:
Redis Database
Redis database used to store cached data in temporary storage.
PostgreSQL Database
PostgreSQL database used to store Salt minion data, job returns, event data, files, pillar data, local user accounts and additional settings for the Enterprise Console.
Automation Config API server (RaaS)
Also referred to as RaaS (Returner as a Service). The Enterprise API provides RPC endpoints to receive management commands from the console.
Automation Config User Interface
Web application that provides frontend for the Enterprise API. While SaltStack Config has been written with an API first approach the console interfaces directly with the APIs to enable simple management of systems.
In standard installation scenario, each component will be deployed on a dedicated node, which means there will be four dedicated nodes after the installation. If your system requires high availability, you may need to deploy multiple Salt Master nodes, PostgreSQL databases, and Redis databases.
Communications
Salt masters and minions by default communicate using the ZeroMQ messaging library. This provides high performance network communication between parties allowing Salt to send messages and data at rapid speeds.
Salt maintains a public key system for authenticating masters and minions. On first boot a minion generates a key pair and sends its credentials to the master server. The master can accept this key after verifying the identity of the minion. The two parties can communicate quickly and securely using ZeroMQ.
Salt Communication Ports
Salt communicates with managed systems using a publish-subscribe pattern.
- Publisher Port - TCP 4505 All Salt minions establish a persistent connection to the publisher port where they listen for messages. Commands are sent asynchronously to all connections over this port, which enables commands to be executed over large numbers of systems simultaneously.
- Request Server - TCP 4506 Salt minions connect to the request server as needed to send results to the Salt master, and to securely request files and minion-specific data values (Salt pillars). Connections to this port are 1:1 between the Salt master and Salt minion (not asynchronous).
Connections are initiated by the Salt minion, which means that you do not need to open any incoming ports on those systems (thereby reducing the attack vector). TCP Ports 4505 & 4506 must be allowed incoming to the Salt master for communication to succeed.
Terminology
Salt Master
Central management system. Used to send commands and configurations to the Salt minion that is running on managed systems. A daemon called salt-master is installed on the master to provide this functionality.
Salt Minion
Servers that Salt manages are called minions. A daemon called salt-minion is installed on each managed machine and configured to communicate with the master.
Grains
Grains are static information about the underlying managed system such as operating system, memory, IP address etc. These are collected by the salt-minion daemon and passed back to the master.
Pillar
A Pillar represents a secure key-value store that a minion can use to retrieve assigned data. Salt pillars store data values such as file paths, configuration parameters and passwords.
Beacon
Salt Beacons monitor non-Salt processes and send an event to the Salt Event bus when a change in activity occurs. The beacon events are used to trigger a reactor.
Reactor
The reactor system gives Salt the ability to trigger actions in response to an event. The reactor monitors the Salt event bus for event tags that match a given pattern and run one or more commands in response.
Runners
Salt runners are modules that execute on the master servers instead of minions. The typical use case for runners is to perform orchestration of multiple workflows.
Returners
Salt returners are used to specify alternative locations where results of an action run on a minion are sent. By default minions return their data to the master but can be configured to return to another source such as a database or logging service.
Salt Mine
The Salt mine is an area on the master server where results from regularly executed commands on minions can be stored.
Wheel
The wheel system is used to manage master side management routines such as minion keys.
Additional Resources
The SaltStack Components documentation page.
The Understanding SaltStack documentation page.
YouTube video breaking down SaltStack Config components