REX-Ray and the Container Storage Interface (CSI) support three architectural models: centralized, decentralized-split, and decentralized-unified. This document identifies the components of each architecture and their relationship to the three, common component types: client, agent, and controller.
This document uses the following terms:
| Term | Description |
|---|---|
| CO | Container orchestrator (ex. Docker, K8s, Mesos). In the models below a CO is a client |
| agent | Long-running process on the same host as the CO that processes identity and filesystem requests and may proxy other requests to controller |
| client | Issues requests to agent and/or controller |
| controller | Long-running process on the same host as the CO or a remote host that processes requests issue by a client or agent |
| master host | A single host (or cluster) responsible for running the controller and sometimes a version of the CO as well |
| node host(s) | One or more hosts running the CO and agent in the centralized model and CO, agent, and controller in the decentralized models |
This section lists some notes of interest:
- The Docker client knows nothing about the executor binary that the REX-Ray agent downloads from the controller. The executor binary is executed on the node host in order to provide information such as the node host's ID and local device information.
- The diagrams below do not illustrate REX-Ray CLI->Agent or REX-Ray CLI->Controller relationships. For the purposes of this document the REX-Ray CLI should not be considered a client, rather the CO is the client.
- In fact there isn't a REX-Ray CLI->Agent relationship. The REX-Ray CLI accesses the REX-Ray Controller directly as the REX-Ray Agent isn't a libStorage API endpoint but rather a Docker Volume Driver endpoint.
- The only CLI tool that could be considered a client with regards to the diagrams below is the Docker Volume Driver CLI (dvdcli) tool as it accesses the REX-Ray Agent, just like Docker.
The Diagrams section below attempts to organize the architectural implementations in such a way that analogues are apparent, but sometimes it is difficult to create the structure necessary to add the desired clarity.
| Role | Components |
|---|---|
| Agent | Node Plugin, REX-Ray Agent |
| Client | CO, Docker, dvdcli |
| Controller | Node Controller, REX-Ray Agent |
This section visually illustrates the relationship between client, agent, and controller for each of the architectural types and implementations:
| Centralized | Decentralized-Split | Decentralized-Unified | |
|---|---|---|---|
| Abstract |  |
 |
 |
| Docker w REX-Ray |  |
 |
 |
| dvdcli w REX-Ray |  |
 |
 |
| CSI |  |
 |
 |
| Docker w REX-Ray.CSI |  |
 |
 |
