Monty Taylor | 93ad221 | 2017-08-02 14:59:50 -0500 | [diff] [blame] | 1 | Ansible Integration |
| 2 | =================== |
| 3 | |
| 4 | Zuul contains Ansible modules and plugins to control the execution of Ansible |
| 5 | Job content. These break down into two basic categories. |
| 6 | |
| 7 | * Restricted Execution on Executors |
| 8 | * Build Log Support |
| 9 | |
| 10 | Restricted Execution |
| 11 | -------------------- |
| 12 | |
| 13 | Zuul runs ``ansible-playbook`` on executors to run job content on nodes. While |
| 14 | the intent is that content is run on the remote nodes, Ansible is a flexible |
| 15 | system that allows delegating actions to ``localhost``, and also reading and |
| 16 | writing files. These actions can be desirable and necessary for actions such |
| 17 | as fetching log files or build artifacts, but could also be used as a vector |
| 18 | to attack the executor. |
| 19 | |
| 20 | For that reason Zuul implements a set of Ansible action plugins and lookup |
| 21 | plugins that override and intercept task execution during untrusted playbook |
| 22 | execution to ensure local actions are not executed or that for operations that |
| 23 | are desirable to allow locally that they only interact with files in the zuul |
| 24 | work directory. |
| 25 | |
| 26 | .. autoclass:: zuul.ansible.action.normal.ActionModule |
| 27 | :members: |
| 28 | |
| 29 | Build Log Support |
| 30 | ----------------- |
| 31 | |
| 32 | Zuul provides realtime build log streaming to end users so that users can |
| 33 | watch long-running jobs in progress. As jobs may be written that execute a |
| 34 | shell script that could run for a long time, additional effort is expended |
| 35 | to stream stdout and stderr of shell tasks as they happen rather than waiting |
| 36 | for the command to finish. |
| 37 | |
| 38 | Zuul contains a modified version of the :ansible:module:`command` |
| 39 | that starts a log streaming daemon on the build node. |
| 40 | |
| 41 | .. automodule:: zuul.ansible.library.command |
| 42 | |
| 43 | All jobs run with the :py:mod:`zuul.ansible.callback.zuul_stream` callback |
| 44 | plugin enabled, which writes the build log to a file so that the |
| 45 | :py:class:`zuul.lib.log_streamer.LogStreamer` can provide the data on demand |
| 46 | over the finger protocol. Finally, :py:class:`zuul.web.LogStreamingHandler` |
| 47 | exposes that log stream over a websocket connection as part of |
| 48 | :py:class:`zuul.web.ZuulWeb`. |
| 49 | |
| 50 | .. autoclass:: zuul.ansible.callback.zuul_stream.CallbackModule |
| 51 | :members: |
| 52 | |
| 53 | .. autoclass:: zuul.lib.log_streamer.LogStreamer |
| 54 | .. autoclass:: zuul.web.LogStreamingHandler |
| 55 | .. autoclass:: zuul.web.ZuulWeb |
| 56 | |
| 57 | In addition to real-time streaming, Zuul also installs another callback module, |
| 58 | :py:mod:`zuul.ansible.callback.zuul_json.CallbackModule` that collects all |
| 59 | of the information about a given run into a json file which is written to the |
| 60 | work dir so that it can be published along with build logs. Since the streaming |
| 61 | log is by necessity a single text stream, choices have to be made for |
| 62 | readability about what data is shown and what is not shown. The json log file |
| 63 | is intended to allow for a richer more interactive set of data to be displayed |
| 64 | to the user. |
| 65 | |
| 66 | .. autoclass:: zuul.ansible.callback.zuul_json.CallbackModule |