openstack/openstack-ansible
Code Issues Proposed changes
openstack-ansible/doc/source/developer-docs/configure-affinity.rst
daz 5cc9d0b004 [docs] Revise deployment configuration chapter 
Reorganised content based on feedback and IA proposal in
https://etherpad.openstack.org/p/osa-install-guide-IA:

1. Move affinity content to the appendix
2. Move security hardening configuration to the appendix
3. Create an advanced configuration section in the appendix
4. Delete configuring hosts and configuring target host networking information,
and create a configuration file examples section
5. Move glance configuration information to the developer docs
6. Move overridding configuration defaults to the appendix.
7. Move checking configuration file content to the installation chapter

Change-Id: I71efaf2472b1233f1b1a1367fcb00ca598d27ea9
Implements: blueprint osa-install-guide-overhaul
2016-08-03 09:51:57 +00:00

3.2 KiB
Raw Blame History

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:

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:

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

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:

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:

# 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.