Ce contenu n'est pas disponible dans la langue sélectionnée.
Chapter 16. Configuring the overcloud with Ansible
Ansible is the main method to apply the overcloud configuration. This chapter provides information about how to interact with the overcloud Ansible configuration.
Although director generates the Ansible playbooks automatically, it is a good idea to familiarize yourself with Ansible syntax. For more information about using Ansible, see https://docs.ansible.com/.
Ansible also uses the concept of roles, which are different to OpenStack Platform director roles. Ansible roles form reusable components of playbooks, whereas director roles contain mappings of OpenStack services to node types.
16.1. Ansible-based overcloud configuration (config-download) Copier lienLien copié sur presse-papiers!
The config-download feature is the method that director uses to configure the overcloud. Director uses config-download in conjunction with OpenStack Orchestration (heat) to generate the software configuration and apply the configuration to each overcloud node. Although heat creates all deployment data from SoftwareDeployment resources to perform the overcloud installation and configuration, heat does not apply any of the configuration. Heat only provides the configuration data through the heat API.
As a result, when you run the openstack overcloud deploy command, the following process occurs:
-
Director creates a new deployment plan based on
openstack-tripleo-heat-templatesand includes any environment files and parameters to customize the plan. - Director uses heat to interpret the deployment plan and create the overcloud stack and all descendant resources. This includes provisioning nodes with the OpenStack Bare Metal service (ironic).
- Heat also creates the software configuration from the deployment plan. Director compiles the Ansible playbooks from this software configuration.
-
Director generates a temporary user (
tripleo-admin) on the overcloud nodes specifically for Ansible SSH access. - Director downloads the heat software configuration and generates a set of Ansible playbooks using heat outputs.
-
Director applies the Ansible playbooks to the overcloud nodes using
ansible-playbook.
16.2. config-download working directory Copier lienLien copié sur presse-papiers!
The ansible-playbook command creates an Ansible project directory, default name ~/config-download/overcloud. This project directory stores downloaded software configuration from heat. It includes all Ansible-related files which you need to run ansible-playbook to configure the overcloud.
The contents of the directory include:
-
tripleo-ansible-inventory.yaml - Ansible inventory file containing
hostsandvarsfor all the overcloud nodes. -
ansible.log - Log file from the most recent run of
ansible-playbook. -
ansible.cfg - Configuration file used when running
ansible-playbook. -
ansible-playbook-command.sh - Executable script used to rerun
ansible-playbook. ssh_private_key - Private ssh key used to access the overcloud nodes.
- Reproducing ansible-playbook
After the project directory is created, run the ansible-playbook-command.sh command to reproduce the deployment.
$ ./ansible-playbook-command.sh
You can run the script with additional arguments, such as check mode --check, limiting hosts --limit, and overriding variables -e.
$ ./ansible-playbook-command.sh --check
16.3. Checking config-download log Copier lienLien copié sur presse-papiers!
During the config-download process, Ansible creates a log file, named ansible.log, in the /home/stack directory on the undercloud.
Procedure
View the log with the
lesscommand:$ less ~/ansible.log
16.4. Performing Git operations on the working directory Copier lienLien copié sur presse-papiers!
The config-download working directory is a local Git repository. Every time a deployment operation runs, director adds a Git commit to the working directory with the relevant changes. You can perform Git operations to view configuration for the deployment at different stages and compare the configuration with different deployments.
Be aware of the limitations of the working directory. For example, if you use Git to revert to a previous version of the config-download working directory, this action affects only the configuration in the working directory. It does not affect the following configurations:
- The overcloud data schema: Applying a previous version of the working directory software configuration does not undo data migration and schema changes.
- The hardware layout of the overcloud: Reverting to previous software configuration does not undo changes related to overcloud hardware, such as scaling up or down.
-
The heat stack: Reverting to earlier revisions of the working directory has no effect on the configuration stored in the heat stack. The heat stack creates a new version of the software configuration that applies to the overcloud. To make permanent changes to the overcloud, modify the environment files applied to the overcloud stack before you rerun the
openstack overcloud deploycommand.
Complete the following steps to compare different commits of the config-download working directory.
Procedure
Change to the
config-downloadworking directory for your overcloud, usually namedovercloud:$ cd ~/config-download/overcloudRun the
git logcommand to list the commits in your working directory. You can also format the log output to show the date:$ git log --format=format:"%h%x09%cd%x09" a7e9063 Mon Oct 8 21:17:52 2018 +1000 dfb9d12 Fri Oct 5 20:23:44 2018 +1000 d0a910b Wed Oct 3 19:30:16 2018 +1000 ...By default, the most recent commit appears first.
Run the
git diffcommand against two commit hashes to see all changes between the deployments:$ git diff a7e9063 dfb9d12
16.5. Deployment methods that use config-download Copier lienLien copié sur presse-papiers!
There are four main methods that use config-download in the context of an overcloud deployment:
- Standard deployment
-
Run the
openstack overcloud deploycommand to automatically run the configuration stage after the provisioning stage. This is the default method when you run theopenstack overcloud deploycommand. - Separate provisioning and configuration
-
Run the
openstack overcloud deploycommand with specific options to separate the provisioning and configuration stages. - Run the ansible-playbook-command.sh script after a deployment
-
Run the
openstack overcloud deploycommand with combined or separate provisioning and configuration stages, then run theansible-playbook-command.shscript supplied in theconfig-downloadworking directory to re-apply the configuration stage. - Provision nodes, manually create config-download, and run Ansible
-
Run the
openstack overcloud deploycommand with a specific option to provision nodes, then run theansible-playbookcommand with thedeploy_steps_playbook.yamlplaybook.
16.6. Running config-download on a standard deployment Copier lienLien copié sur presse-papiers!
The default method for executing config-download is to run the openstack overcloud deploy command. This method suits most environments.
Prerequisites
- A successful undercloud installation.
- Overcloud nodes ready for deployment.
- Heat environment files that are relevant to your specific overcloud customization.
Procedure
-
Log in to the undercloud host as the
stackuser. Source the
stackrcfile:$ source ~/stackrcRun the deployment command. Include any environment files that you require for your overcloud:
$ openstack overcloud deploy \ --templates \ -e environment-file1.yaml \ -e environment-file2.yaml \ ...- Wait until the deployment process completes.
During the deployment process, director generates the config-download files in a ~/config-download/overcloud working directory. After the deployment process finishes, view the Ansible playbooks in the working directory to see the tasks director executed to configure the overcloud.
16.7. Running config-download with separate provisioning and configuration Copier lienLien copié sur presse-papiers!
The openstack overcloud deploy command runs the heat-based provisioning process and then the config-download configuration process. You can also run the deployment command to execute each process individually. Use this method to provision your overcloud nodes as a distinct process so that you can perform any manual pre-configuration tasks on the nodes before you run the overcloud configuration process.
Prerequisites
- A successful undercloud installation.
- Overcloud nodes ready for deployment.
- Heat environment files that are relevant to your specific overcloud customization.
Procedure
-
Log in to the undercloud host as the
stackuser. Source the
stackrcfile:$ source ~/stackrcRun the deployment command with the
--stack-onlyoption. Include any environment files you require for your overcloud:$ openstack overcloud deploy \ --templates \ -e environment-file1.yaml \ -e environment-file2.yaml \ ... --stack-only- Wait until the provisioning process completes.
Enable SSH access from the undercloud to the overcloud for the
tripleo-adminuser. Theconfig-downloadprocess uses thetripleo-adminuser to perform the Ansible-based configuration:$ openstack overcloud admin authorize-
Perform any manual pre-configuration tasks on nodes. If you use Ansible for configuration, use the
tripleo-adminuser to access the nodes. Run the deployment command with the
--config-download-onlyoption. Include any environment files required for your overcloud:$ openstack overcloud deploy \ --templates \ -e environment-file1.yaml \ -e environment-file2.yaml \ ... --config-download-only- Wait until the configuration process completes.
During the configuration stage, director generates the config-download files in a ~/config-download/overcloud working directory. After the deployment process finishes, view the Ansible playbooks in the working directory to see the tasks director executed to configure the overcloud.
16.8. Running config-download with the ansible-playbook-command.sh script Copier lienLien copié sur presse-papiers!
When you deploy the overcloud, either with the standard method or a separate provisioning and configuration process, director generates a working directory in ~/config-download/overcloud. This directory contains the playbooks and scripts necessary to run the configuration process again.
Prerequisites
An overcloud deployed with the one of the following methods:
- Standard method that combines provisioning and configuration process.
- Separate provisioning and configuration processes.
Procedure
-
Log in to the undercloud host as the
stackuser. Run the
ansible-playbook-command.shscript.You can pass additional Ansible arguments to this script, which are then passed unchanged to the
ansible-playbookcommand. This makes it possible to take advantage of Ansible features, such as check mode (--check), limiting hosts (--limit), or overriding variables (-e). For example:$ ./ansible-playbook-command.sh --limit ControllerWarningWhen
--limitis used to deploy at scale, only hosts included in the execution are added to the SSHknown_hostsfile across the nodes. Therefore, some operations, such as live migration, may not work across nodes that are not in theknown_hostsfile.NoteTo ensure that the
/etc/hostsfile, on all nodes, is up-to-date, run the following command as thestackuser:(undercloud)$ cd /home/stack/overcloud-deploy/overcloud/config-download/overcloud (undercloud)$ ANSIBLE_REMOTE_USER="tripleo-admin" ansible allovercloud \ -i /home/stack/overcloud-deploy/overcloud/tripleo-ansible-inventory.yaml \ -m include_role \ -a name=tripleo_hosts_entries \ -e @global_vars.yamlWait until the configuration process completes.
Additional information
The working directory contains a playbook called
deploy_steps_playbook.yaml, which manages the overcloud configuration tasks. To view this playbook, run the following command:$ less deploy_steps_playbook.yamlThe playbook uses various task files contained in the working directory. Some task files are common to all OpenStack Platform roles and some are specific to certain OpenStack Platform roles and servers.
The working directory also contains sub-directories that correspond to each role that you define in your overcloud
roles_datafile. For example:$ ls Controller/Each OpenStack Platform role directory also contains sub-directories for individual servers of that role type. The directories use the composable role hostname format:
$ ls Controller/overcloud-controller-0The Ansible tasks in
deploy_steps_playbook.yamlare tagged. To see the full list of tags, use the CLI option--list-tagswithansible-playbook:$ ansible-playbook -i tripleo-ansible-inventory.yaml --list-tags deploy_steps_playbook.yamlThen apply tagged configuration using the
--tags,--skip-tags, or--start-at-taskwith theansible-playbook-command.shscript:$ ./ansible-playbook-command.sh --tags overcloud
When you run the
config-downloadplaybooks against the overcloud, you might receive a message regarding the SSH fingerprint for each host. To avoid these messages, include--ssh-common-args="-o StrictHostKeyChecking=no"when you run theansible-playbook-command.shscript:$ ./ansible-playbook-command.sh --tags overcloud --ssh-common-args="-o StrictHostKeyChecking=no"
16.9. Running config-download with manually created playbooks Copier lienLien copié sur presse-papiers!
You can create your own config-download files outside of the standard workflow. For example, you can run the openstack overcloud deploy command with the --stack-only option to provision the nodes, and then manually apply the Ansible configuration separately.
Prerequisites
- A successful undercloud installation.
- Overcloud nodes ready for deployment.
- Heat environment files that are relevant to your specific overcloud customization.
Procedure
-
Log in to the undercloud host as the
stackuser. Source the
stackrcfile:$ source ~/stackrcRun the deployment command with the
--stack-onlyoption. Include any environment files required for your overcloud:$ openstack overcloud deploy \ --templates \ -e environment-file1.yaml \ -e environment-file2.yaml \ ... --stack-only- Wait until the provisioning process completes.
Enable SSH access from the undercloud to the overcloud for the
tripleo-adminuser. Theconfig-downloadprocess uses thetripleo-adminuser to perform the Ansible-based configuration:$ openstack overcloud admin authorizeGenerate the
config-downloadfiles:$ openstack overcloud deploy \ --stack overcloud --stack-only \ --config-dir ~/overcloud-deploy/overcloud/config-download/overcloud/-
--stackspecifies the name of the overcloud. -
--stack-onlyensures that the command only deploys the heat stack and skips any software configuration. -
--config-dirspecifies the location of theconfig-downloadfiles.
-
Change to the directory that contains your
config-downloadfiles:$ cd ~/config-downloadGenerate a static inventory file:
$ tripleo-ansible-inventory \ --stack <overcloud> \ --ansible_ssh_user tripleo-admin \ --static-yaml-inventory inventory.yaml-
Replace
<overcloud>with the name of your overcloud.
-
Replace
Use the
~/overcloud-deploy/overcloud/config-download/overcloudfiles and the static inventory file to perform a configuration. To execute the deployment playbook, run theansible-playbookcommand:$ ansible-playbook \ -i inventory.yaml \ -e gather_facts=true \ -e @global_vars.yaml \ --private-key ~/.ssh/id_rsa \ --become \ ~/overcloud-deploy/overcloud/config-download/overcloud/deploy_steps_playbook.yamlNoteWhen you run the
config-download/overcloudplaybooks against the overcloud, you might receive a message regarding the SSH fingerprint for each host. To avoid these messages, include--ssh-common-args="-o StrictHostKeyChecking=no"in youransible-playbookcommand:$ ansible-playbook \ -i inventory.yaml \ -e gather_facts=true \ -e @global_vars.yaml \ --private-key ~/.ssh/id_rsa \ --ssh-common-args="-o StrictHostKeyChecking=no" \ --become \ --tags overcloud \ ~/overcloud-deploy/overcloud/config-download/overcloud/deploy_steps_playbook.yaml- Wait until the configuration process completes.
Generate an
overcloudrcfile manually from the ansible-based configuration:$ openstack action execution run \ --save-result \ --run-sync \ tripleo.deployment.overcloudrc \ '{"container":"overcloud"}' \ | jq -r '.["result"]["overcloudrc.v3"]' > overcloudrc.v3Manually set the deployment status to success:
$ openstack workflow execution create tripleo.deployment.v1.set_deployment_status_success '{"plan": "<overcloud>"}'-
Replace
<overcloud>with the name of your overcloud.
-
Replace
The ~/overcloud-deploy/overcloud/config-download/overcloud/ directory contains a playbook called deploy_steps_playbook.yaml. The playbook uses various task files contained in the working directory. Some task files are common to all Red Hat OpenStack Platform (RHOSP) roles and some are specific to certain RHOSP roles and servers.
The ~/overcloud-deploy/overcloud/config-download/overcloud/ directory also contains sub-directories that correspond to each role that you define in your overcloud roles_data file. Each RHOSP role directory also contains sub-directories for individual servers of that role type. The directories use the composable role hostname format, for example Controller/overcloud-controller-0.
The Ansible tasks in deploy_steps_playbook.yaml are tagged. To see the full list of tags, use the CLI option --list-tags with ansible-playbook:
$ ansible-playbook -i tripleo-ansible-inventory.yaml --list-tags deploy_steps_playbook.yaml
You can apply tagged configuration using the --tags, --skip-tags, or --start-at-task with the ansible-playbook-command.sh script:
$ ansible-playbook \
-i inventory.yaml \
-e gather_facts=true \
-e @global_vars.yaml \
--private-key ~/.ssh/id_rsa \
--become \
--tags overcloud \
~/overcloud-deploy/overcloud/config-download/overcloud/deploy_steps_playbook.yaml
16.10. Limitations of config-download Copier lienLien copié sur presse-papiers!
The config-download feature has some limitations:
-
When you use ansible-playbook CLI arguments such as
--tags,--skip-tags, or--start-at-task, do not run or apply deployment configuration out of order. These CLI arguments are a convenient way to rerun previously failed tasks or to iterate over an initial deployment. However, to guarantee a consistent deployment, you must run all tasks fromdeploy_steps_playbook.yamlin order. You can not use the
--start-at-taskarguments for certain tasks that use a variable in the task name. For example, the--start-at-taskarguments does not work for the following Ansible task:- name: Run puppet host configuration for step {{ step }}-
If your overcloud deployment includes a director-deployed Ceph Storage cluster, you cannot skip
step1tasks when you use the--checkoption unless you also skipexternal_deploy_stepstasks. -
You can set the number of parallel Ansible tasks with the
--forksoption. However, the performance ofconfig-downloadoperations degrades after 25 parallel tasks. For this reason, do not exceed 25 with the--forksoption.
16.11. config-download top level files Copier lienLien copié sur presse-papiers!
The following file are important top level files within a config-download working directory.
Ansible configuration and execution
The following files are specific to configuring and executing Ansible within the config-download working directory.
- ansible.cfg
-
Configuration file used when running
ansible-playbook. - ansible.log
-
Log file from the last run of
ansible-playbook. - ansible-errors.json
- JSON structured file that contains any deployment errors.
- ansible-playbook-command.sh
-
Executable script to rerun the
ansible-playbookcommand from the last deployment operation. - ssh_private_key
- Private SSH key that Ansible uses to access the overcloud nodes.
- tripleo-ansible-inventory.yaml
- Ansible inventory file that contains hosts and variables for all the overcloud nodes.
- overcloud-config.tar.gz
- Archive of the working directory.
Playbooks
The following files are playbooks within the config-download working directory.
- deploy_steps_playbook.yaml
- Main deployment steps. This playbook performs the main configuration operations for your overcloud.
- pre_upgrade_rolling_steps_playbook.yaml
- Pre upgrade steps for major upgrade
- upgrade_steps_playbook.yaml
- Major upgrade steps.
- post_upgrade_steps_playbook.yaml
- Post upgrade steps for major upgrade.
- update_steps_playbook.yaml
- Minor update steps.
- fast_forward_upgrade_playbook.yaml
- Fast forward upgrade tasks. Use this playbook only when you want to upgrade from one long-life version of Red Hat OpenStack Platform to the next.
16.12. config-download tags Copier lienLien copié sur presse-papiers!
The playbooks use tagged tasks to control the tasks that they apply to the overcloud. Use tags with the ansible-playbook CLI arguments --tags or --skip-tags to control which tasks to execute. The following list contains information about the tags that are enabled by default:
- facts
- Fact gathering operations.
- common_roles
- Ansible roles common to all nodes.
- overcloud
- All plays for overcloud deployment.
- pre_deploy_steps
-
Deployments that happen before the
deploy_stepsoperations. - host_prep_steps
- Host preparation steps.
- deploy_steps
- Deployment steps.
- post_deploy_steps
-
Steps that happen after the
deploy_stepsoperations. - external
- All external deployment tasks.
- external_deploy_steps
- External deployment tasks that run on the undercloud only.
16.13. config-download deployment steps Copier lienLien copié sur presse-papiers!
The deploy_steps_playbook.yaml playbook configures the overcloud. This playbook applies all software configuration that is necessary to deploy a full overcloud based on the overcloud deployment plan.
This section contains a summary of the different Ansible plays used within this playbook. The play names in this section are the same names that are used within the playbook and that are displayed in the ansible-playbook output. This section also contains information about the Ansible tags that are set on each play.
- Gather facts from undercloud
Fact gathering for the undercloud node.
Tags:
facts- Gather facts from overcloud
Fact gathering for the overcloud nodes.
Tags:
facts- Load global variables
Loads all variables from
global_vars.yaml.Tags:
always- Common roles for TripleO servers
Applies common Ansible roles to all overcloud nodes, including tripleo-bootstrap for installing bootstrap packages, and tripleo-ssh-known-hosts for configuring ssh known hosts.
Tags:
common_roles- Overcloud deploy step tasks for step 0
Applies tasks from the deploy_steps_tasks template interface.
Tags:
overcloud,deploy_steps- Server deployments
Applies server-specific heat deployments for configuration such as networking and hieradata. Includes NetworkDeployment, <Role>Deployment, <Role>AllNodesDeployment, etc.
Tags:
overcloud,pre_deploy_steps- Host prep steps
Applies tasks from the host_prep_steps template interface.
Tags:
overcloud,host_prep_steps- External deployment step [1,2,3,4,5]
Applies tasks from the external_deploy_steps_tasks template interface. Ansible runs these tasks only against the undercloud node.
Tags:
external,external_deploy_steps- Overcloud deploy step tasks for [1,2,3,4,5]
Applies tasks from the deploy_steps_tasks template interface.
Tags:
overcloud,deploy_steps- Overcloud common deploy step tasks [1,2,3,4,5]
Applies the common tasks performed at each step, including puppet host configuration,
container-puppet.py, andtripleo-container-manage(container configuration and management).Tags:
overcloud,deploy_steps- Server Post Deployments
Applies server specific heat deployments for configuration performed after the 5-step deployment process.
Tags:
overcloud,post_deploy_steps- External deployment Post Deploy tasks
Applies tasks from the external_post_deploy_steps_tasks template interface. Ansible runs these tasks only against the undercloud node.
Tags:
external,external_deploy_steps