Architecture overview
The main idea of ADCM is to provide a simple user interface that supplies sufficient data for running Ansible scripts on a set of hosts.
ADCM can be deployed using a core container and external components:
-
ADCM core container — contains the components responsible for the user interface, API request handling, job scheduling, and execution of cluster and hostprovider management operations.
-
External components — deployed outside the ADCM container:
-
Required: Database.
-
Optional: Celery Worker, Vault, and Consul.
-
The ADCM architecture is shown in the diagrams below.
Core container
The ADCM core container includes the following components:
-
Nginx — ensures ADCM availability by accepting incoming user requests. Nginx runs on the
8000port. The main purpose of Nginx in the ADCM architecture is to act as a reverse proxy, routing requests between Web UI and the Backend Server. -
Web UI — receives user requests redirected from Nginx.
-
Status Server — receives heartbeats from hosts, services, and their components and also sends and handles events via the WebSocket protocol. Status Server is implemented in the Go programming language.
-
Backend Server — processes API requests from Web UI, reads and writes data to the database, and interacts with Status Server via REST API to get information about the status of hosts, services, and components.
-
Job Scheduler — polls the database for new jobs, creates chains of subjobs, and initiates their execution either locally via Local Executor or asynchronously via Celery Worker, depending on the ADCM configuration.
-
Background job — performs various background jobs, such as removing outdated data from the database. The execution frequency is determined by values stored in the database.
-
Local Executor — a built-in ADCM component that initiates the execution of management operations on clusters and hostproviders directly inside the ADCM container. For each operation, Local Executor prepares the execution environment, including generating an inventory file, and then launches an Ansible command. Each Ansible execution is a separate process in UNIX terminology, rather than a thread. Execution is performed asynchronously, and the result is written to the database upon completion.
External components
External components are deployed outside the ADCM container and provide data storage, secure secret management, service discovery, and asynchronous task execution.
Required external component:
-
Database — stores ADCM data, including information about clusters, hosts, services, components, jobs, and their execution results.
Optional external components:
-
Celery Worker — unlike Local Executor, Celery Worker is deployed as a separate external component and uses Celery task chains for asynchronous execution of cluster and hostprovider management operations. This allows task execution to be distributed across multiple Celery Worker instances. Like Local Executor, Celery Worker prepares the execution environment, including generating an inventory file, and then launches an Ansible command. Execution results are stored in the database.
IMPORTANT-
Celery Worker must use the same volume as Backend Server.
-
To ensure correct operation of Celery Worker, Consul must be deployed.
-
-
Vault — provides secure storage and access to secrets required for ADCM operation. Backend Server, Status Server, and Celery Worker access Vault to obtain tokens and sensitive data required for ADCM components to operate correctly.
NOTEADCM supports HashiCorp Vault, OpenBao, and other compatible Vault implementations. -
Consul — used as an external infrastructure service to register ADCM components and monitor their availability.
