Merge "Add guidelines on adding a new service"
This commit is contained in:
commit
8658eb5261
@ -40,3 +40,120 @@ https://git.openstack.org/cgit/openstack-dev/sandbox, for learning, understandin
|
||||
and testing the `Gerrit Workflow`_.
|
||||
|
||||
.. _Gerrit Workflow: http://docs.openstack.org/infra/manual/developers.html#development-workflow
|
||||
|
||||
Adding a new service
|
||||
====================
|
||||
|
||||
Kolla aims to both containerise and deploy all services within the OpenStack
|
||||
"big tent". This is a constantly moving target as the ecosystem grows, so these
|
||||
guidelines aim to help make adding a new service to Kolla a smooth experience.
|
||||
|
||||
The image
|
||||
---------
|
||||
Kolla follows Docker best practices
|
||||
(https://docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices/)
|
||||
when designing and implementing services where at all possible.
|
||||
|
||||
We use ``jinja2`` templating syntax to help manage the volume and complexity
|
||||
that comes with maintaining multiple Dockerfiles for multiple different base
|
||||
operating systems.
|
||||
|
||||
Images should be created under the ``docker`` directory. OpenStack services
|
||||
should inherit from the provided ``openstack-base`` image, while supporting and
|
||||
infrastructure services (e.g. mongodb) should inherit from ``base``.
|
||||
|
||||
Services consisting of only one service should be placed in an image named the
|
||||
same as that service, e.g. ``horizon``. Services that consist of multiple
|
||||
processes generally use a base image and child images, e.g. ``glance-base``,
|
||||
``glance-api``, and ``glance-registry``.
|
||||
|
||||
Jinja2 'blocks' are employed throughout the Dockerfile's to help operators
|
||||
customise various stages of the build (refer to
|
||||
http://docs.openstack.org/developer/kolla/image-building.html?highlight=override#dockerfile-customisation)
|
||||
|
||||
Some of these blocks are free form however, there are a subset that should be
|
||||
common to every Dockerfile. The overall structure for a multi container service
|
||||
is as follows::
|
||||
|
||||
FROM {{ namespace }}/{{ image_prefix }}openstack-base:{{ tag }}
|
||||
MAINTAINER {{ maintainer }}
|
||||
|
||||
{% import "macros.j2" as macros with context %}
|
||||
|
||||
<< binary specific steps >>
|
||||
|
||||
<< source specific steps >>
|
||||
|
||||
<< common steps >>
|
||||
|
||||
{% block << service >>_footer %}{% endblock %}
|
||||
{% block footer %}{% endblock %}
|
||||
{{ include_footer }}
|
||||
|
||||
.. NOTE::
|
||||
The generic footer block ``{% block footer %}{% endblock %}`` should not be
|
||||
included in base images (e.g. glance-base).
|
||||
|
||||
{{ include_footer }} is legacy and should not be included in new services, it
|
||||
is superseded by {% block footer %}{% endblock %}
|
||||
|
||||
Orchestration
|
||||
-------------
|
||||
As of the Newton release there are two main orchestration methods in existence
|
||||
for Kolla, Ansible and Kubernetes. Ansible is the most mature and generally
|
||||
regarded as the reference implementation.
|
||||
|
||||
When adding a role for a new service in Ansible, there are couple of patterns
|
||||
that Kolla uses throughout that should be followed.
|
||||
|
||||
* The sample inventories
|
||||
|
||||
Entries should be added for the service in each of
|
||||
``ansible/inventory/multinode`` and ``ansible/inventory/all-in-one``.
|
||||
|
||||
* The playbook
|
||||
|
||||
The main playbook that ties all roles together is in ``ansible/site.yml``,
|
||||
this should be updated with appropriate roles, tags, and conditions. Ensure
|
||||
also that supporting hosts such as haproxy are updated when necessary.
|
||||
|
||||
* The common role
|
||||
|
||||
A ``common`` role exists which sets up logging, ``kolla-toolbox`` and other
|
||||
supporting components. This should be included in all services within
|
||||
``meta/main.yml`` of your role.
|
||||
|
||||
* Common tasks
|
||||
|
||||
All services should include the following tasks:
|
||||
|
||||
- ``do_reconfigure.yml`` : Used to push new configuration files to the host and
|
||||
restart the service.
|
||||
|
||||
- ``pull.yml`` : Used to pre fetch the image into the Docker image cache on hosts,
|
||||
to speed up intial deploys.
|
||||
|
||||
- ``upgrade.yml`` : Used for upgrading the service in a rolling fashion. May
|
||||
include service specific setup and steps as not all services can be upgraded
|
||||
in the same way.
|
||||
|
||||
Other than the above, most roles follow the following pattern::
|
||||
|
||||
# Register
|
||||
Involves registering the service with Keystone, creating endpoints, roles, users,
|
||||
etc.
|
||||
|
||||
# Config
|
||||
Distributes the config files to the nodes to be pulled into the container on
|
||||
startup.
|
||||
|
||||
# Bootstrap
|
||||
Creating the database (but not tables), database user for the service,
|
||||
permissions, etc.
|
||||
|
||||
# Bootstrap Service
|
||||
Starts a one shot container on the host to create the database tables, and other
|
||||
initial run time config.
|
||||
|
||||
# Start
|
||||
Start the service(s).
|
||||
|
Loading…
x
Reference in New Issue
Block a user