DingoAdm Overview

DingoAdm is primarily used for rapid deployment and operation and maintenance of DingoFS clusters.

Key Features

  • Rapid deployment of DingoFS clusters

    Users can deploy the entire cluster with a single click once the cluster topology file is ready.

  • Containerized services

    All components run within Docker containers, addressing compatibility issues across different Linux distributions.

  • Manage DingoFS clusters

    Supports common management operations, including one-click service upgrades and cluster scaling.

  • Manage multiple clusters simultaneously

    Users can manage multiple DingoFS clusters simultaneously and switch between them as needed.

  • Precise error localization

    We assign a unique error code to each error that occurs during deployment, and provide detailed explanations and solutions for each error code. Users can look up related error codes online via the Error Code List page.

Overall Design

Installation Directory

To enable multi-user management, DingoAdm is installed by default in the .dingoadm directory under the current user’s home directory, with all files stored in this directory, including:

File

Description

bin/dingoadm

Binary file

dingoadm.cfg

DingoAdm configuration file, configurable for log levels, SSH connection timeout, sudo permissions, etc.

CHANGELOG

Update log for the current version

data/dingoadm.db

SQLite database file, where all persistent data is stored, including cluster name, cluster topology, container IDs for each service, etc.

logs

Log directory, where a log file is generated and stored each time a command is executed

temp

Temporary file directory

 
/home/dingo/.dingoadm
├── bin
│   └── dingoadm
├── CHANGELOG
├── dingoadm.cfg
├── data
│   └── dingoadm.db
├── logs
│   ├── dingoadm-2022-01-17_17-07-57.log
│   └── dingoadm-2022-01-17_17-08-33.log
└── temp

Data Storage

All data in DingoAdm that needs to be persisted is stored in an SQLite database. SQLite is a self-contained, serverless, zero-configuration, transactional SQL database. A complete SQLite database is a single file.

The database primarily stores the following four types of data:

  • Host information: including host addresses, SSH ports, private key paths, etc.

  • Cluster information: including cluster names, cluster UUIDs, and the topology corresponding to each cluster

  • Service information: service IDs and container IDs corresponding to services

  • Client information: client IDs and container IDs corresponding to clients

💡 Note:

Service IDs are generated based on the cluster topology. Given a fixed cluster topology, we generate a unique ID for each service in the topology according to a fixed set of rules, meaning that service IDs are also fixed.

Based on the service ID, the corresponding container ID can be queried in the database. The host module also stores information such as the host and SSH private key path for each service deployment. Using this information, we can manage the containers corresponding to the services.

Service Management

To address component runtime dependency issues, all components in DingoFS run within Docker containers. We package all components, dependencies, and necessary tools for each version into a single image and publish it to the Docker public repository.

DingoAdm connects to the remote server via an SSH client to execute deployment or management commands, and uses the Docker client Docker CLI to manage service containers.