... | ... | @@ -14,12 +14,19 @@ We should implement base entities that represent useful abstractions from an ope |
|
|
|
|
|
The queue is implemented using Celery, a full-featured task queue written in Python.
|
|
|
|
|
|
## Back-end (queue worker)
|
|
|
## Back-end
|
|
|
|
|
|
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.
|
|
|
|
|
|
###
|
|
|
### Queue worker
|
|
|
|
|
|
The back-end will be implemented as a Celery queue worker. This can then easily dispatch commands, as needed.
|
|
|
|
|
|
### Ansible roles
|
|
|
|
|
|
We can write small Ansible roles to represent each task we want to implement, rather than the usual model of handling all tasks related to a given application. A small set of variables will need to be mapped to the equivalent front-end fields.
|
|
|
|
|
|
For example, a task on the front-end to deploy a Drupal codebase, could trigger a `aegir.drupal8-codebase-git-deploy` role, where we provide variables for a git repo from whence to clone, as well as a filesystem path where it should be deployed. A separate `aegir.drupal8-codebase-verify` task could then ensure that proper file ownership and permissions are maintained. This should only require a path variable to be passed to the task.
|
|
|
|
|
|
## Security model
|
|
|
|
... | ... | |