Ce contenu n'est pas disponible dans la langue sélectionnée.
Chapter 3. Preparing for director installation
3.1. Preparing the undercloud Copier lienLien copié sur presse-papiers!
The director installation requires the following:
- A non-root user to execute commands.
- Directories to organize images and templates
- A resolvable hostname
- A Red Hat subscription
- The command line tools for image preparation and director installation
This procedure shows how to create these items.
Procedure
-
Log into your undercloud as the
rootuser. Create the
stackuser:useradd stack
[root@director ~]# useradd stackCopy to Clipboard Copied! Toggle word wrap Toggle overflow Set a password for the user:
passwd stack
[root@director ~]# passwd stackCopy to Clipboard Copied! Toggle word wrap Toggle overflow Disable password requirements when using
sudo:echo "stack ALL=(root) NOPASSWD:ALL" | tee -a /etc/sudoers.d/stack chmod 0440 /etc/sudoers.d/stack
[root@director ~]# echo "stack ALL=(root) NOPASSWD:ALL" | tee -a /etc/sudoers.d/stack [root@director ~]# chmod 0440 /etc/sudoers.d/stackCopy to Clipboard Copied! Toggle word wrap Toggle overflow Switch to the new
stackuser:su - stack
[root@director ~]# su - stack [stack@director ~]$Copy to Clipboard Copied! Toggle word wrap Toggle overflow Create directories for system images and Heat templates.
mkdir ~/images mkdir ~/templates
[stack@director ~]$ mkdir ~/images [stack@director ~]$ mkdir ~/templatesCopy to Clipboard Copied! Toggle word wrap Toggle overflow The director uses system images and Heat templates to create the overcloud environment. Red Hat recommends creating these directories to help you organize your local file system.
Check the base and full hostname of the undercloud:
hostname hostname -f
[stack@director ~]$ hostname [stack@director ~]$ hostname -fCopy to Clipboard Copied! Toggle word wrap Toggle overflow If either of the previous commands do not report the correct fully-qualified hostname or report an error, use
hostnamectlto set a hostname:sudo hostnamectl set-hostname manager.example.com sudo hostnamectl set-hostname --transient manager.example.com
[stack@director ~]$ sudo hostnamectl set-hostname manager.example.com [stack@director ~]$ sudo hostnamectl set-hostname --transient manager.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow Edit the
/etc/hoststo include an entry for the system’s hostname. The IP address in/etc/hostsmust match the address that you plan to use for your undercloud public API. For example, if the system is namedmanager.example.comand uses10.0.0.1for its IP address, then/etc/hostsrequires an entry like:10.0.0.1 manager.example.com manager
10.0.0.1 manager.example.com managerCopy to Clipboard Copied! Toggle word wrap Toggle overflow Register your system either with the Red Hat Content Delivery Network or with a Red Hat Satellite. For example, run the following command to register the system to the Content Delivery Network. Enter your Customer Portal user name and password when prompted:
sudo subscription-manager register
[stack@director ~]$ sudo subscription-manager registerCopy to Clipboard Copied! Toggle word wrap Toggle overflow Find the entitlement pool ID for Red Hat OpenStack Platform director. For example:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Locate the
Pool IDvalue and attach the Red Hat OpenStack Platform 15 entitlement:sudo subscription-manager attach --pool=Valid-Pool-Number-123456
[stack@director ~]$ sudo subscription-manager attach --pool=Valid-Pool-Number-123456Copy to Clipboard Copied! Toggle word wrap Toggle overflow Disable all default repositories, and then enable the required Red Hat Enterprise Linux repositories:
sudo subscription-manager repos --disable=* sudo subscription-manager repos --enable=rhel-8-for-x86_64-baseos-rpms --enable=rhel-8-for-x86_64-appstream-rpms --enable=rhel-8-for-x86_64-highavailability-rpms --enable=ansible-2.8-for-rhel-8-x86_64-rpms --enable=openstack-15-for-rhel-8-x86_64-rpms --enable=fast-datapath-for-rhel-8-x86_64-rpms
[stack@director ~]$ sudo subscription-manager repos --disable=* [stack@director ~]$ sudo subscription-manager repos --enable=rhel-8-for-x86_64-baseos-rpms --enable=rhel-8-for-x86_64-appstream-rpms --enable=rhel-8-for-x86_64-highavailability-rpms --enable=ansible-2.8-for-rhel-8-x86_64-rpms --enable=openstack-15-for-rhel-8-x86_64-rpms --enable=fast-datapath-for-rhel-8-x86_64-rpmsCopy to Clipboard Copied! Toggle word wrap Toggle overflow These repositories contain packages the director installation requires.
Set the RHEL version to RHEL 8.2:
sudo subscription-manager release --set=8.2
[stack@director ~]$ sudo subscription-manager release --set=8.2Copy to Clipboard Copied! Toggle word wrap Toggle overflow Perform an update on your system to ensure you have the latest base system packages:
sudo dnf update -y sudo reboot
[stack@director ~]$ sudo dnf update -y [stack@director ~]$ sudo rebootCopy to Clipboard Copied! Toggle word wrap Toggle overflow Install the command line tools for director installation and configuration:
sudo dnf install -y python3-tripleoclient
[stack@director ~]$ sudo dnf install -y python3-tripleoclientCopy to Clipboard Copied! Toggle word wrap Toggle overflow
3.2. Installing ceph-ansible Copier lienLien copié sur presse-papiers!
The ceph-ansible package is required when you use Ceph Storage with Red Hat OpenStack Platform.
If you use Red Hat Ceph Storage, or if your deployment uses an external Ceph Storage cluster, install the ceph-ansible package. For more information about integrating with an existing Ceph Storage cluster, see Integrating an Overcloud with an Existing Red Hat Ceph Cluster.
Procedure
Enable the Ceph Tools repository:
sudo subscription-manager repos --enable=rhceph-4-tools-for-rhel-8-x86_64-rpms
[stack@director ~]$ sudo subscription-manager repos --enable=rhceph-4-tools-for-rhel-8-x86_64-rpmsCopy to Clipboard Copied! Toggle word wrap Toggle overflow Install the
ceph-ansiblepackage:sudo dnf install -y ceph-ansible
[stack@director ~]$ sudo dnf install -y ceph-ansibleCopy to Clipboard Copied! Toggle word wrap Toggle overflow
3.3. Preparing container images Copier lienLien copié sur presse-papiers!
The undercloud configuration requires initial registry configuration to determine where to obtain images and how to store them. Complete the following steps to generate and customize an environment file for preparing your container images.
Procedure
- Log in to your undercloud host as the stack user.
Generate the default container image preparation file:
openstack tripleo container image prepare default \ --local-push-destination \ --output-env-file containers-prepare-parameter.yaml
$ openstack tripleo container image prepare default \ --local-push-destination \ --output-env-file containers-prepare-parameter.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow This command includes the following additional options:
-
--local-push-destinationsets the registry on the undercloud as the location for container images. This means the director pulls the necessary images from the Red Hat Container Catalog and pushes them to the registry on the undercloud. The director uses this registry as the container image source. To pull directly from the Red Hat Container Catalog, omit this option. --output-env-fileis an environment file name. The contents of this file include the parameters for preparing your container images. In this case, the name of the file iscontainers-prepare-parameter.yaml.NoteYou can also use the same
containers-prepare-parameter.yamlfile to define a container image source for both the undercloud and the overcloud.
-
-
Edit the
containers-prepare-parameter.yamland make the modifications to suit your requirements.
3.4. Container image preparation parameters Copier lienLien copié sur presse-papiers!
The default file for preparing your containers (containers-prepare-parameter.yaml) contains the ContainerImagePrepare Heat parameter. This parameter defines a list of strategies for preparing a set of images:
Each strategy accepts a set of sub-parameters that define which images to use and what to do with them. The following table contains information about the sub-parameters you can use with each ContainerImagePrepare strategy:
| Parameter | Description |
|---|---|
|
| List of image name substrings to exclude from a strategy. |
|
|
List of image name substrings to include in a strategy. At least one image name must match an existing image. All |
|
|
String to append to the tag for the destination image. For example, if you pull an image with the tag |
|
| A dictionary of image labels that filter the images to modify. If an image matches the labels defined, the director includes the image in the modification process. |
|
| String of ansible role names to run during upload but before pushing the image to the destination registry. |
|
|
Dictionary of variables to pass to |
|
|
The namespace of the registry to push images during the upload process. When you specify a namespace for this parameter, all image parameters use this namespace too. If set to |
|
| The source registry from where to pull the original container images. |
|
|
A dictionary of |
|
|
Defines the label pattern to tag the resulting images. Usually sets to |
The set parameter accepts a set of key: value definitions. The following table contains information about the keys:
| Key | Description |
|---|---|
|
| The name of the Ceph Storage container image. |
|
| The namespace of the Ceph Storage container image. |
|
| The tag of the Ceph Storage container image. |
|
| A prefix for each OpenStack service image. |
|
| A suffix for each OpenStack service image. |
|
| The namespace for each OpenStack service image. |
|
|
The driver to use to determine which OpenStack Networking (neutron) container to use. Use a null value to set to the standard |
|
|
The tag that the director uses to identify the images to pull from the source registry. You usually keep this key set to |
The ContainerImageRegistryCredentials parameter maps a container registry to a username and password to authenticate to that registry.
If a container registry requires a username and password, you can use ContainerImageRegistryCredentials to include their values with the following syntax:
In the example, replace my_username and my_password with your authentication credentials. Instead of using your individual user credentials, Red Hat recommends creating a registry service account and using those credentials to access registry.redhat.io content. For more information, see "Red Hat Container Registry Authentication".
The ContainerImageRegistryLogin parameter is used to control the registry login on the systems being deployed. This must be set to true if push_destination is set to false or not used.
3.5. Layering image preparation entries Copier lienLien copié sur presse-papiers!
The value of the ContainerImagePrepare parameter is a YAML list. This means you can specify multiple entries. The following example demonstrates two entries where the director uses the latest version of all images except for the nova-api image, which uses the version tagged with 15.0-44:
The includes and excludes entries control image filtering for each entry. The images that match the includes strategy take precedence over excludes matches. The image name must include the includes or excludes value to be considered a match.
3.6. Excluding Ceph Storage container images Copier lienLien copié sur presse-papiers!
The default overcloud role configuration uses the default Controller, Compute, and Ceph Storage roles. However, if you use the default role configuration to deploy an overcloud without Ceph Storage nodes, director still pulls the Ceph Storage container images from the Red Hat Container Registry because the images are included as a part of the default configuration.
If your overcloud does not require Ceph Storage containers, you can configure director to not pull the Ceph Storage containers images from the Red Hat Container Registry.
Procedure
Edit the
containers-prepare-parameter.yamlfile to exclude the Ceph Storage containers:Copy to Clipboard Copied! Toggle word wrap Toggle overflow The
excludesparameter uses regular expressions to exclude any container images that contain thecephorprometheusstrings.-
Save the
containers-prepare-parameter.yamlfile.
3.7. Obtaining container images from private registries Copier lienLien copié sur presse-papiers!
Some container image registries might require authentication to access images. In this situation, use the ContainerImageRegistryCredentials parameter in your containers-prepare-parameter.yaml environment file.
Private registries require push_destination set to true for their respective strategy in the ContainerImagePrepare.
The ContainerImageRegistryCredentials parameter uses a set of keys based upon the private registry URL. Each private registry URL uses its own key and value pair to define the username (key) and password (value). This provides a method to specify credentials for multiple private registries.
The default ContainerImagePrepare parameter pulls container images from registry.redhat.io, which requires authentication.
The ContainerImageRegistryLogin parameter is used to control if the system needs to login to the remote registry to fetch the containers.
parameter_defaults: ... ContainerImageRegistryLogin: true
parameter_defaults:
...
ContainerImageRegistryLogin: true
You must set this to true if push_destination is not configured for a given strategy. If push_destination is configured in a ContainerImagePrepare strategy and the ContainerImageRegistryCredentials parameter is configured, the system logs in to fetch the containers and pushes them to the remote system.
3.8. Modifying images during preparation Copier lienLien copié sur presse-papiers!
It is possible to modify images during image preparation, then immediately deploy with modified images. Scenarios for modifying images include:
- As part of a continuous integration pipeline where images are modified with the changes being tested before deployment.
- As part of a development workflow where local changes need to be deployed for testing and development.
- When changes need to be deployed but are not available through an image build pipeline. For example, adding proprietry add-ons or emergency fixes.
To modify an image during preparation, invoke an Ansible role on each image that you want to modify. The role takes a source image, makes the requested changes, and tags the result. The prepare command can push the image to the destination registry and set the Heat parameters to refer to the modified image.
The Ansible role tripleo-modify-image conforms with the required role interface, and provides the behaviour necessary for the modify use-cases. Modification is controlled using modify-specific keys in the ContainerImagePrepare parameter:
-
modify_rolespecifies the Ansible role to invoke for each image to modify. -
modify_append_tagappends a string to the end of the source image tag. This makes it obvious that the resulting image has been modified. Use this parameter to skip modification if thepush_destinationregistry already contains the modified image. It is recommended to changemodify_append_tagwhenever you modify the image. -
modify_varsis a dictionary of Ansible variables to pass to the role.
To select a use-case that the tripleo-modify-image role handles, set the tasks_from variable to the required file in that role.
While developing and testing the ContainerImagePrepare entries that modify images, it is recommended to run the image prepare command without any additional options to confirm the image is modified as expected:
sudo openstack tripleo container image prepare \ -e ~/containers-prepare-parameter.yaml
sudo openstack tripleo container image prepare \
-e ~/containers-prepare-parameter.yaml
3.9. Updating existing packages on container images Copier lienLien copié sur presse-papiers!
The following example ContainerImagePrepare entry updates in all packages on the images using the undercloud host’s dnf repository configuration:
3.10. Installing additional RPM files to container images Copier lienLien copié sur presse-papiers!
You can install a directory of RPM files in your container images. This is useful for installing hotfixes, local package builds, or any package not available through a package repository. For example, the following ContainerImagePrepare entry installs some hotfix packages only on the nova-compute image:
3.11. Modifying container images with a custom Dockerfile Copier lienLien copié sur presse-papiers!
For maximum flexibility, you can specify a directory containing a Dockerfile to make the required changes. When you invoke the tripleo-modify-image role, the role generates a Dockerfile.modified file that changes the FROM directive and adds extra LABEL directives. The following example runs the custom Dockerfile on the nova-compute image:
An example /home/stack/nova-custom/Dockerfile follows. After running any USER root directives, you must switch back to the original image default user:
3.12. Preparing a Satellite server for container images Copier lienLien copié sur presse-papiers!
Red Hat Satellite 6 offers registry synchronization capabilities. This provides a method to pull multiple images into a Satellite server and manage them as part of an application life cycle. The Satellite also acts as a registry for other container-enabled systems to use. For more details information on managing container images, see "Managing Container Images" in the Red Hat Satellite 6 Content Management Guide.
The examples in this procedure use the hammer command line tool for Red Hat Satellite 6 and an example organization called ACME. Substitute this organization for your own Satellite 6 organization.
This procedure requires authentication credentials to access container images from registry.redhat.io. Instead of using your individual user credentials, Red Hat recommends creating a registry service account and using those credentials to access registry.redhat.io content. For more information, see "Red Hat Container Registry Authentication".
Procedure
Create a list of all container images:
sudo podman search --limit 1000 "registry.redhat.io/rhosp15-rhel8" | awk '{ print $2 }' | grep -v beta | sed "s/registry.redhat.io\///g" | tail -n+2 > satellite_images$ sudo podman search --limit 1000 "registry.redhat.io/rhosp15-rhel8" | awk '{ print $2 }' | grep -v beta | sed "s/registry.redhat.io\///g" | tail -n+2 > satellite_imagesCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
Copy the
satellite_images_namesfile to a system that contains the Satellite 6hammertool. Alternatively, use the instructions in the Hammer CLI Guide to install thehammertool to the undercloud. Run the following
hammercommand to create a new product (OSP15 Containers) in your Satellite organization:hammer product create \ --organization "ACME" \ --name "OSP15 Containers"
$ hammer product create \ --organization "ACME" \ --name "OSP15 Containers"Copy to Clipboard Copied! Toggle word wrap Toggle overflow This custom product will contain our images.
Add the base container image to the product:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Add the overcloud container images from the
satellite_imagesfile.Copy to Clipboard Copied! Toggle word wrap Toggle overflow Add the Ceph Storage 4 container image:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Synchronize the container images:
hammer product synchronize \ --organization "ACME" \ --name "OSP15 Containers"
$ hammer product synchronize \ --organization "ACME" \ --name "OSP15 Containers"Copy to Clipboard Copied! Toggle word wrap Toggle overflow Wait for the Satellite server to complete synchronization.
NoteDepending on your configuration,
hammermight ask for your Satellite server username and password. You can configurehammerto automatically login using a configuration file. For more information, see the "Authentication" section in the Hammer CLI Guide.-
If your Satellite 6 server uses content views, create a new content view version to incorporate the images and promote it along environments in your application life cycle. This largely depends on how you structure your application lifecycle. For example, if you have an environment called
productionin your lifecycle and you want the container images available in that environment, create a content view that includes the container images and promote that content view to theproductionenvironment. For more information, see "Managing Container Images with Content Views". Check the available tags for the
baseimage:hammer docker tag list --repository "base" \ --organization "ACME" \ --environment "production" \ --content-view "myosp15" \ --product "OSP15 Containers"
$ hammer docker tag list --repository "base" \ --organization "ACME" \ --environment "production" \ --content-view "myosp15" \ --product "OSP15 Containers"Copy to Clipboard Copied! Toggle word wrap Toggle overflow This command displays tags for the OpenStack Platform container images within a content view for an particular environment.
Return to the undercloud and generate a default environment file for preparing images using your Satellite server as a source. Run the following example command to generate the environment file:
(undercloud) $ openstack tripleo container image prepare default \ --output-env-file containers-prepare-parameter.yaml
(undercloud) $ openstack tripleo container image prepare default \ --output-env-file containers-prepare-parameter.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
--output-env-fileis an environment file name. The contents of this file will include the parameters for preparing your container images for the undercloud. In this case, the name of the file iscontainers-prepare-parameter.yaml.
-
Edit the
containers-prepare-parameter.yamlfile and modify the following parameters:-
namespace- The URL and port of the registry on the Satellite server. The default registry port on Red Hat Satellite is 5000. name_prefix- The prefix is based on a Satellite 6 convention. This differs depending on whether you use content views:-
If you use content views, the structure is
[org]-[environment]-[content view]-[product]-. For example:acme-production-myosp15-osp15_containers-. -
If you do not use content views, the structure is
[org]-[product]-. For example:acme-osp15_containers-.
-
If you use content views, the structure is
-
ceph_namespace,ceph_image,ceph_tag- If using Ceph Storage, include the additional parameters to define the Ceph Storage container image location. Note thatceph_imagenow includes a Satellite-specific prefix. This prefix is the same value as thename_prefixoption.
-
The following example environment file contains Satellite-specific parameters:
Use this environment file when creating both your undercloud and overcloud.