github.com/cloud-foundations/dominator@v0.0.0-20221004181915-6e4fee580046/design-docs/Dominator/ArchitecturalOverview.md (about)

     1  Dominator Architectural Overview
     2  ================================
     3  Richard Gooch
     4  -------------
     5  	
     6  Overview
     7  ========
     8  
     9  The **Dominator** is a robust, reliable and efficient system to push operating system images to large fleet of machines (physical or virtual). The design target is that a single system and administrator can manage the content of *at least* 10,000 systems with negligible performance impact on the managed systems, fast response to global changes and nearly atomic changes on those systems.
    10  
    11  The **Dominator** takes a radically different approach from to fleet management based on three principles:
    12  
    13  -   immutable infrastructure
    14  
    15  -   golden “baked” images
    16  
    17  -   fast, robust transitions.
    18  
    19  Rather than package management, the **Dominator** uses an image management and deployment approach.
    20  
    21  Please see [https://github.com/Cloud-Foundations/Dominator](https://github.com/Cloud-Foundations/Dominator) for the source code, [design document](README.md), [fact sheet](FactSheet.md) and [user guide](https://github.com/Cloud-Foundations/Dominator/blob/master/user-guide/README.md).
    22  
    23  Dominator Components
    24  ====================
    25  
    26  The system is comprised of the following components:
    27  
    28  -   an **Image Server** which stores images which include:
    29  
    30      -   file-system trees
    31  
    32      -   *trigger lists* which describes which services/daemons should be restarted if specified files change
    33  
    34      -   a *filter* which lists regular expression pathnames which should not be changed
    35  
    36      -   references to *computed files* which are dynamically generated
    37  
    38  -   a **M**achine **D**ata**B**ase (**MDB**) which lists all the machines in the fleet and the name of the *required* image that should be on each machine (an enhancement is a secondary *planned* image for each machine)
    39  
    40  -   a controller (master) system called the **Dominator** which;
    41  
    42      -   continuously *polls* each **sub** for it’s file-system state
    43  
    44      -   computes differences with the *required image*
    45  
    46      -   directs deviant **subs** to *fetch* files from an **Image Server** and *update* its file-system
    47  
    48  -   zero or more **File Generator** servers which serve *computed file* data based on the **MDB** data for a particular machine
    49  
    50  -   a slave agent on each machine in the fleet called the **sub**ject daemon (**subd**) which continuously checksum scans the root file-system with built-in rate limiting so as to avoid impacting system workload
    51  
    52  The following diagram shows how these components are connected: