Architecture overview
ADCM main idea is to provide a simple user interface that produces enough data to run Ansible scripts on a number of hosts.
ADCM architecture is based on the following components:
-
Nginx. Ensures ADCM availability (for example, in case of many users present) by distributing the load in front of WebUI. Nginx starts at 8000 port. Nginx’s main purpose for ADCM is to act as proxy that redirects user queries to WebUI.
-
WebUI. Receives user queries redirected by Nginx.
-
Status Server. Receives heartbeats from hosts, services, and their components, as well as WebUI events. Sends web sockets to WebUI. Status Server is implemented in Go programming language.
-
Backend Server. Contacts Status Server via the REST API and receives hosts, services, and components heartbeats. Backend Server is able to read and write data to the database and to invoke job runners to run Ansible commands.
-
Database. Stores various data encrypted via Ansible Vault in the form of Ansible secrets.
-
Background job. Works on various background tasks (for example, removing some data from the database according to the time period specified in ADCM). Background jobs use database to receive information on how often they should run.
-
Ad hoc job runner. Prepares environment to run Ansible via creating inventory file, then runs Ansible command. For cluster and hostprovider a job runner starts the set of some commands at host to affect the whole cluster performance (for example, starting a service, configuring files, or installing packages). Job runner works asynchronously: the browser running ADCM doesn’t get locked, and after the process is completed, the result gets written into the database to be accessed by the Backend Server. Job runner prepares the environment from inventory file every time an Ansible command is run, that is depicted in the Ad hoc prefix (meaning "created for a particular purpose"). Each job runner is not a threat, yet a separate process (in UNIX terms).
