You are here

Home » API reference » Hosting 6.2 » hosting.queues.inc

Frontend/Backend Inter-process Communication in Hosting 6.2

Same name and namespace in other branches
  1. 7.4 hosting.queues.inc \backend-frontend-IPC
  2. 7.3 hosting.queues.inc \backend-frontend-IPC

Aegir is based on a very important distinction between the "frontend" and the "backend". The frontend is the Drupal website that creates the user interface that people manipulate. The backend is (usually) a set a drush commands that do the actual operations on the backend objects (servers, platforms, sites).

The frontend and backend run as different users: the frontend runs under the webserver user, while the backend run as a separate UNIX user, which we call the backend sandbox. This distinction is important as it brings an extra layer of security. It also allows for commands to be ran on different servers more easily.

The way the frontend communicates to the backend is through the use of "queues", that are actually defined in the frontend (hosting). The frontend also define drush commands that are ran through a cronjob and therefore provide the glue to the backend.

The point of entry is through the "dispatcher" (the hosting-dispatch command), which runs the different queues appropriately. There are different types of queues (see hook_hosting_queues()), but the most important one is the "task" queue, which runs the basic tasks like install and backup.

When tasks are ran, a provision command is called with the same name of the task type defined in the frontend (see drush_hosting_task()). If we are running a special task like install, verify or import, data from the task is actually saved in the backend, through the backend provision-save command. The data saved is from the associative array "context_options", defined from the hook see hook_hosting_TASK_OBJECT_context_options(). A good example of such a variable is the site name or platform it is on, which are obviously saved in the backend.

There is also an "options" array that are just one-time parameters that are not stored in the backend context. A good example of that is the site email address, that is just sent during the install or password resets task but not saved.

File

./hosting.queues.inc, line 8
This file defines an API for defining new queues.

Functions

Namesort descending Location Description
hook_hosting_tasks task/hosting_task.api.php Define tasks that can be executed in the front-end.
hook_hosting_tasks_alter task/hosting_task.api.php Alter front-end tasks defined by other modules.
hook_hosting_task_update_status task/hosting_task.api.php Reacts to tasks ending, with any status.
hostingService_example_basic::context_options example/hosting_example.service.inc Pass values to the provision backend when we call provision-save.
hosting_get_queues ./hosting.queues.inc Retrieve a list of queues that need to be dispatched
hosting_queues_cron_cmd ./hosting.queues.inc
hosting_run_queue ./hosting.queues.inc Run a queue specified by hook_hosting_queues()
hosting_task_TASK_TYPE_form task/hosting_task.api.php Add fields to the task confirmation form.
hosting_task_TASK_TYPE_form_validate task/hosting_task.api.php Validate the form data defined in hosting_task_TASK_TYPE_form().
_hosting_dispatch_cmd ./hosting.queues.inc
_hosting_queues_clean_output ./hosting.queues.inc
_hosting_queue_next_run ./hosting.queues.inc Calculate the time at which the task queue will run next.