A Juju controller runs as one or more Juju controller agents. Juju clients, e.g. Juju CLI, interact with a controller agent to send commands to and get information from it. The controller agent also interacts with Juju’s database back-end for maintenance of state, and with the cloud provider to arrange its compute, networking, and storage resources for deployed applications.
The high level architecture of the Juju controller agent is depicted in the figure below.
The controller agent maintains state for one or more Juju models. It includes the following:
- API server : The server process that exposes various Juju APIs to external clients, e.g. Juju CLI, Juju Developer Tool, and Juju GUI.
- State : Desired states, which are submitted to the controller via Juju client commands, are saved in persistent storage via the database API. The state engine listens to the API server for requests and calls the database API accordingly. Currently, Juju uses MongoDB as its state storage database, where desired states are kept. The controller aims to bring the current state of workloads, relations, units, and machines to their corresponding desired states.
- Provider : Listens to worker requests and calls the API exposed by the cloud provider.
- Workers : The Juju controller runs a set of workers. This set includes all the workers of a typical machine agent, plus those agents that perform the jobs that a controller specifically does.
The controller agent has some internal APIs used by its components:
- Worker API : Some controller workers expose a set of APIs that the API server consumes.
- State API : The state engine exposes this API for the API server to call when it needs to perform state related operations.
- Provider API : Also referred to as Environ, controller workers use this API set to perform operations for applications and units on the cloud.