... | ... | @@ -4,10 +4,29 @@ Aegir is made up of several components. First off, there is a front-end built on |
|
|
|
|
|
The front-end is written in Drupal 8. It consists of some base entities and traits, along with basic admin interfaces for creating and managing fields and bundles.
|
|
|
|
|
|
### Entity types
|
|
|
|
|
|
We should implement base entities that represent useful abstractions from an operational stand-point. These should come with default admin interfaces, but we can then separately build out a user-friendly UI that further abstracts low-level components.
|
|
|
|
|
|
|
|
|
|
|
|
## Queue system
|
|
|
|
|
|
The queue is implemented using Celery, a full-featured task queue written in Python.
|
|
|
|
|
|
## Back-end (queue worker)
|
|
|
|
|
|
The back-end will consume tasks from the queue, and run various commands. The initial engine is `ansible-playbook`, but Kubernetes is also likely to follow. |
|
|
\ No newline at end of file |
|
|
The back-end will consume tasks from the queue, and run various commands. The initial engine is `ansible-playbook`, but Kubernetes is also likely to follow.
|
|
|
|
|
|
###
|
|
|
|
|
|
## Secrets
|
|
|
|
|
|
## Security model
|
|
|
|
|
|
Broadly speaking, Aegir maps a web GUI to CLI commands. Ansible provides a handy, secure mechanism to allow multiple servers, since it uses SSH to communicate between VMs. We *don't* want to be able to run arbitrary commands on the back-end, since this could easily lead to compromised security. Rather, the Ansible roles will represent a whitelist of commands, and safe variables.
|
|
|
|
|
|
|
|
|
## User experience
|
|
|
|
|
|
By default, entities should provide only admin UI components. But, being built on fieldable entities, these should then all be accessible to Views, Panels, etc. to allow for better end-user experience. We should provide a "default" UI, but ensure that this can be easily customized, or replaced entirely. |
|
|
\ No newline at end of file |