# KEEL - Config Management as I like it

KEEL is a distributed configuration management tool inspired by SaltStack. It is designed to manage large-scale infrastructure through a high-performance, scalable Master-Minion architecture.

## 🚀 Core Principles

### Master-Minion Architecture
KEEL operates on a centralized management model:
*   **The Master:** Acts as the central authority. It manages the distribution of states, handles communication between minions, and provides an interface for orchestrating complex workflows. The Master is responsible for determining which configuration applies to which host using the **Top File**.
*   0The Minion:** A lightweight agent installed on every managed host. Minions are responsible for "rendering" the desired state (the configuration) and applying it to the local system. Once the local system matches the desired state, the Minion reports the results back to the Master.

### Declarative State Management
Instead of writing scripts to perform actions, you define the *desired state* of your system. KEEL ensures that the system moves toward that state, regardless of its starting condition.

## 🏗️ Key Concepts

### 🗺️ The Top File
The `top.sls` (or equivalent) is the "map" of your infrastructure. It defines the relationship between your configuration states and your minions. It allows you to say: *"Apply these web server configurations to all hosts identified as 'web-servers'."*

### 📦 States
States are the building blocks of KEEL. They describe what a system should look like (e.s. `package: nginx must be installed`, `service: nginx must be running`).

### 💎 Pillars (Global Data)
Pillars allow you to inject data into your states. This is ideal for storing sensitive information (like API keys or passwords) or environment-specific variables (like database URLs) that are not part of the state logic itself.

### 🌾 Grains (System Metadata)
Grains are local data collected from the Minion. They describe the "identity" of the host, such as its Operating System, CPU architecture, or IP address. This allows you to write conditional logic in your states (e.g., *"If OS is Ubuntu, use `apt`; if OS is CentOS, use `yum`"*).

## 🛠️ Workflow

1.  **Define:** You write **States** describing your desired infrastructure.
    2.s. **Map:** You update the **Top File** to assign those states to specific hosts.
3.  **Push:** The **Master** communicates the intent to the **Minions**.
4.  **Apply:** The **Minion** evaluates the current system state, executes necessary changes, and reports success or failure back to the Master.