46b662dacb
This patch removes the old install guide. It is still accessible in the Mitaka section. Change-Id: I47ce62523edd14a1bb20deba3f40e1e0b2df223c Implements: blueprint osa-install-guide-overhaul
95 lines
3.1 KiB
ReStructuredText
95 lines
3.1 KiB
ReStructuredText
========
|
|
Affinity
|
|
========
|
|
|
|
OpenStack-Ansible's dynamic inventory generation has a concept called
|
|
`affinity`. This determines how many containers of a similar type are deployed
|
|
onto a single physical host.
|
|
|
|
Using `shared-infra_hosts` as an example, consider this
|
|
``openstack_user_config.yml``:
|
|
|
|
.. code-block:: yaml
|
|
|
|
shared-infra_hosts:
|
|
infra1:
|
|
ip: 172.29.236.101
|
|
infra2:
|
|
ip: 172.29.236.102
|
|
infra3:
|
|
ip: 172.29.236.103
|
|
|
|
Three hosts are assigned to the `shared-infra_hosts` group,
|
|
OpenStack-Ansible ensures that each host runs a single database container,
|
|
a single memcached container, and a single RabbitMQ container. Each host has
|
|
an affinity of 1 by default, and that means each host will run one of each
|
|
container type.
|
|
|
|
You can skip the deployment of RabbitMQ altogether. This is
|
|
helpful when deploying a standalone swift environment. If you need
|
|
this configuration, your ``openstack_user_config.yml`` would look like this:
|
|
|
|
.. code-block:: yaml
|
|
|
|
shared-infra_hosts:
|
|
infra1:
|
|
affinity:
|
|
rabbit_mq_container: 0
|
|
ip: 172.29.236.101
|
|
infra2:
|
|
affinity:
|
|
rabbit_mq_container: 0
|
|
ip: 172.29.236.102
|
|
infra3:
|
|
affinity:
|
|
rabbit_mq_container: 0
|
|
ip: 172.29.236.103
|
|
|
|
The configuration above deploys a memcached container and a database
|
|
container on each host, without the RabbitMQ containers.
|
|
|
|
|
|
.. _security_hardening:
|
|
|
|
Security hardening
|
|
~~~~~~~~~~~~~~~~~~
|
|
|
|
OpenStack-Ansible automatically applies host security hardening configurations
|
|
using the `openstack-ansible-security`_ role. The role uses a version of the
|
|
`Security Technical Implementation Guide (STIG)`_ that has been adapted for
|
|
Ubuntu 14.04 and OpenStack.
|
|
|
|
The role is applicable to physical hosts within an OpenStack-Ansible deployment
|
|
that are operating as any type of node, infrastructure or compute. By
|
|
default, the role is enabled. You can disable it by changing a variable
|
|
within ``user_variables.yml``:
|
|
|
|
.. code-block:: yaml
|
|
|
|
apply_security_hardening: false
|
|
|
|
When the variable is set to ``true``, the ``setup-hosts.yml`` playbook applies
|
|
the role during deployments.
|
|
|
|
You can apply security configurations to an existing environment or audit
|
|
an environment using a playbook supplied with OpenStack-Ansible:
|
|
|
|
.. code-block:: bash
|
|
|
|
# Perform a quick audit using Ansible's check mode
|
|
openstack-ansible --check security-hardening.yml
|
|
|
|
# Apply security hardening configurations
|
|
openstack-ansible security-hardening.yml
|
|
|
|
For more details on the security configurations that will be applied, refer to
|
|
the `openstack-ansible-security`_ documentation. Review the `Configuration`_
|
|
section of the openstack-ansible-security documentation to find out how to
|
|
fine-tune certain security configurations.
|
|
|
|
.. _openstack-ansible-security: http://docs.openstack.org/developer/openstack-ansible-security/
|
|
.. _Security Technical Implementation Guide (STIG): https://en.wikipedia.org/wiki/Security_Technical_Implementation_Guide
|
|
.. _Configuration: http://docs.openstack.org/developer/openstack-ansible-security/configuration.html
|
|
.. _Appendix H: ../install-guide/app-custom-layouts.html
|
|
|