104 lines
4.2 KiB
ReStructuredText
104 lines
4.2 KiB
ReStructuredText
.. _bootaction:
|
|
|
|
============
|
|
Boot Actions
|
|
============
|
|
|
|
Boot actions can be more accurately described as post-deployment file placement. This file placement
|
|
can be leveraged to install actions for servers to take after the permanent OS is installed
|
|
and the server is rebooted. Including custom or vendor scripts and a SystemD service to run the
|
|
scripts on first boot or on all boots allows almost any action to be configured.
|
|
|
|
Boot Action Schema
|
|
==================
|
|
|
|
Boot actions are configured via YAML documents included in the site topology definition. The schema
|
|
for these YAML documents is described below.
|
|
|
|
.. code-block:: yaml
|
|
|
|
data:
|
|
assets:
|
|
- path: /save/file/here
|
|
location: http://get.data.here/data
|
|
type: unit|file|pkg_list
|
|
data: |
|
|
inline data here
|
|
location_pipeline:
|
|
- template
|
|
data_pipeline
|
|
- base64_decode
|
|
- template
|
|
- base64_encode
|
|
permissions: 555
|
|
node_filter:
|
|
...
|
|
|
|
|
|
``assets`` is a list of data assets. More details below on how each data asset is rendered.
|
|
|
|
``node_filter`` is an optional filter for selecting to which nodes this boot action will apply.
|
|
If no node filter is included, all nodes will receive the boot action. Otherwise it will be
|
|
only the nodes that match the logic of the filter set. See :ref:`task` for a definition of
|
|
the node filter.
|
|
|
|
Rendering Data Assets
|
|
=====================
|
|
|
|
The boot action framework supports assets of several types. ``type`` can be ``unit`` or ``file`` or ``pkg_list``.
|
|
|
|
- ``unit`` is a SystemD unit, such as a service, that will be saved to ``path`` and enabled via ``systemctl enable [filename]``.
|
|
- ``file`` is simply saved to the filesystem at ``path`` and set with ``permissions``.
|
|
- ``pkg_list`` is a list of packages, one per line, that will be installed via apt.
|
|
|
|
Data assets of type ``unit`` or ``file`` will be rendered and saved as files on disk and assigned
|
|
the ``permissions`` as sepcified. The rendering process can follow a few different paths.
|
|
|
|
Referenced vs Inline Data
|
|
-------------------------
|
|
|
|
The asset contents can be sourced from either the in-document ``data`` field of the asset
|
|
mapping or dynamically generated by requesting them from a URL provided in ``location``.
|
|
Currently Drydock supports the schemes of ``http``, ``deckhand+http`` and
|
|
``promenade+http`` for referenced data.
|
|
|
|
Pipelines
|
|
---------
|
|
|
|
The boot action framework supports pipelines to allow for some dynamic rendering. There
|
|
are separate pipelines for the ``location`` field to build the URL that referenced assets should
|
|
be sourced from and the ``data`` field (or the data sourced from resolving the ``location`` field).
|
|
|
|
The ``location`` string will be passed through the ``location_pipeline`` before it is queried. This response
|
|
or the ``data`` field will then be passed through the ``data_pipeline``. Below are pipeline segments available
|
|
for use.
|
|
|
|
base64_decode
|
|
Decode the data element from base64
|
|
|
|
base64_encode
|
|
Encode the data element in base64
|
|
|
|
template
|
|
Treat the data element as a Jinja2 template and apply a node context to it. The defined context available
|
|
to the template is below.
|
|
|
|
- node.network.[network_name].ip - IP address of this node on network [network_name]
|
|
- node.network.[network_name].cidr - CIDR of [network_name]
|
|
- node.network.[network_name].dns_suffix - DNS suffix of [network_name]
|
|
- node.hostname - Hostname of the node
|
|
- node.tags - Sequence of tags assigned to this node
|
|
- node.labels - Key, value pairs of both explicit and dynamic labels for this node
|
|
- action.key - A key that uniquely identifies this boot action on this node. Can be used for signaling boot action result.
|
|
- action.report_url - The URL that can be POSTed to for reporting boot action result.
|
|
|
|
Also available in the Jinja2 template is the ``urlencode`` filter to encode a string for inclusion
|
|
in a URL.
|
|
|
|
Reporting Results
|
|
=================
|
|
|
|
The assets put in place on a server can report the results of applying the boot action using the Drydock :ref:`bootaction-api`. The
|
|
report API URL and boot action key are both available via the ``template`` pipeline segment context. It is up to the boot action
|
|
assets to implement the call back to the API for reporting whatever data the boot action desires.
|