Ce contenu n'est pas disponible dans la langue sélectionnée.

Chapter 7. Customizing container images

Red Hat OpenStack Platform (RHOSP) services run in containers, therefore to deploy the RHOSP services you must obtain the container images. You can generate and customize the environment file that prepares the container images for your RHOSP deployment.

7.1. Preparing container images for director installation

Red Hat supports the following methods for managing container images for your overcloud:

Pulling container images from the Red Hat Container Catalog to the image-serve registry on the undercloud and then pulling the images from the image-serve registry. When you pull images to the undercloud first, you avoid multiple overcloud nodes simultaneously pulling container images over an external connection.
Pulling container images from your Satellite 6 server. You can pull these images directly from the Satellite because the network traffic is internal.

The undercloud installation requires an environment file to determine where to obtain container images and how to store them. You generate a default container image preparation file when preparing for director installation. You can customize the default container image preparation file.

7.1.1. Container image preparation parameters

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:

parameter_defaults:
  ContainerImagePrepare:
  - (strategy one)
  - (strategy two)
  - (strategy three)
  ...

Each strategy accepts a set of sub-parameters that defines which images to use and what to do with the images. The following table contains information about the sub-parameters that you can use with each ContainerImagePrepare strategy:

Parameter	Description
`excludes`	List of regular expressions to exclude image names from a strategy.
`includes`	List of regular expressions to include in a strategy. At least one image name must match an existing image. All `excludes` are ignored if `includes` is specified.
`modify_append_tag`	String to append to the tag for the destination image. For example, if you pull an image with the tag 17.1.0-5.161 and set the `modify_append_tag` to `-hotfix`, the director tags the final image as 17.1.0-5.161-hotfix.
`modify_only_with_labels`	A dictionary of image labels that filter the images that you want to modify. If an image matches the labels defined, the director includes the image in the modification process.
`modify_role`	String of ansible role names to run during upload but before pushing the image to the destination registry.
`modify_vars`	Dictionary of variables to pass to `modify_role`.
`push_destination`	Defines the namespace of the registry that you want to push images to during the upload process. If set to `true`, the `push_destination` is set to the undercloud registry namespace using the hostname, which is the recommended method. If set to `false`, the push to a local registry does not occur and nodes pull images directly from the source. If set to a custom value, director pushes images to an external local registry. If you set this parameter to `false` in production environments while pulling images directly from Red Hat Container Catalog, all overcloud nodes will simultaneously pull the images from the Red Hat Container Catalog over your external connection, which can cause bandwidth issues. Only use `false` to pull directly from a Red Hat Satellite Server hosting the container images. If the `push_destination` parameter is set to `false` or is not defined and the remote registry requires authentication, set the `ContainerImageRegistryLogin` parameter to `true` and include the credentials with the `ContainerImageRegistryCredentials` parameter.
`pull_source`	The source registry from where to pull the original container images.
`set`	A dictionary of `key: value` definitions that define where to obtain the initial images.
`tag_from_label`	Use the value of specified container image metadata labels to create a tag for every image and pull that tagged image. For example, if you set `tag_from_label: {version}-{release}`, director uses the `version` and `release` labels to construct a new tag. For one container, `version` might be set to 17.1.0 and `release` might be set to `5.161`, which results in the tag 17.1.0-5.161. Director uses this parameter only if you have not defined `tag` in the `set` dictionary.

Important

When you push images to the undercloud, use push_destination: true instead of push_destination: UNDERCLOUD_IP:PORT. The push_destination: true method provides a level of consistency across both IPv4 and IPv6 addresses.

The set parameter accepts a set of key: value definitions:

Key	Description
`ceph_image`	The name of the Ceph Storage container image.
`ceph_namespace`	The namespace of the Ceph Storage container image.
`ceph_tag`	The tag of the Ceph Storage container image.
`ceph_alertmanager_image` `ceph_alertmanager_namespace` `ceph_alertmanager_tag`	The name, namespace, and tag of the Ceph Storage Alert Manager container image.
`ceph_grafana_image` `ceph_grafana_namespace` `ceph_grafana_tag`	The name, namespace, and tag of the Ceph Storage Grafana container image.
`ceph_node_exporter_image` `ceph_node_exporter_namespace` `ceph_node_exporter_tag`	The name, namespace, and tag of the Ceph Storage Node Exporter container image.
`ceph_prometheus_image` `ceph_prometheus_namespace` `ceph_prometheus_tag`	The name, namespace, and tag of the Ceph Storage Prometheus container image.
`name_prefix`	A prefix for each OpenStack service image.
`name_suffix`	A suffix for each OpenStack service image.
`namespace`	The namespace for each OpenStack service image.
`neutron_driver`	The driver to use to determine which OpenStack Networking (neutron) container to use. Use a null value to set to the standard `neutron-server` container. Set to `ovn` to use OVN-based containers.
`tag`	Sets a specific tag for all images from the source. If not defined, director uses the Red Hat OpenStack Platform version number as the default value. This parameter takes precedence over the `tag_from_label` value.

Note

The container images use multi-stream tags based on the Red Hat OpenStack Platform version. This means that there is no longer a latest tag.

7.1.2. Guidelines for container image tagging

The Red Hat Container Registry uses a specific version format to tag all Red Hat OpenStack Platform container images. This format follows the label metadata for each container, which is version-release.

version: Corresponds to a major and minor version of Red Hat OpenStack Platform. These versions act as streams that contain one or more releases.
release: Corresponds to a release of a specific container image version within a version stream.

For example, if the latest version of Red Hat OpenStack Platform is 17.1.0 and the release for the container image is 5.161, then the resulting tag for the container image is 17.1.0-5.161.

The Red Hat Container Registry also uses a set of major and minor version tags that link to the latest release for that container image version. For example, both 17.1 and 17.1.0 link to the latest release in the 17.1.0 container stream. If a new minor release of 17.1 occurs, the 17.1 tag links to the latest release for the new minor release stream while the 17.1.0 tag continues to link to the latest release within the 17.1.0 stream.

The ContainerImagePrepare parameter contains two sub-parameters that you can use to determine which container image to download. These sub-parameters are the tag parameter within the set dictionary, and the tag_from_label parameter. Use the following guidelines to determine whether to use tag or tag_from_label.

The default value for tag is the major version for your OpenStack Platform version. For this version it is 17.1. This always corresponds to the latest minor version and release.
```
parameter_defaults:
  ContainerImagePrepare:
  - set:
      ...
      tag: 17.1
      ...
```
To change to a specific minor version for OpenStack Platform container images, set the tag to a minor version. For example, to change to 17.1.2, set tag to 17.1.2.
```
parameter_defaults:
  ContainerImagePrepare:
  - set:
      ...
      tag: 17.1.2
      ...
```
When you set tag, director always downloads the latest container image release for the version set in tag during installation and updates.

If you do not set tag, director uses the value of tag_from_label in conjunction with the latest major version.

parameter_defaults:
  ContainerImagePrepare:
  - set:
      ...
      # tag: 17.1
      ...
    tag_from_label: '{version}-{release}'

The tag_from_label parameter generates the tag from the label metadata of the latest container image release it inspects from the Red Hat Container Registry. For example, the labels for a certain container might use the following version and release metadata:
```
  "Labels": {
    "release": "5.161",
    "version": "17.1.0",
    ...
  }
```
The default value for tag_from_label is {version}-{release}, which corresponds to the version and release metadata labels for each container image. For example, if a container image has 17.1.0 set for version and 5.161 set for release, the resulting tag for the container image is 17.1.0-5.161.
The tag parameter always takes precedence over the tag_from_label parameter. To use tag_from_label, omit the tag parameter from your container preparation configuration.
A key difference between tag and tag_from_label is that director uses tag to pull an image only based on major or minor version tags, which the Red Hat Container Registry links to the latest image release within a version stream, while director uses tag_from_label to perform a metadata inspection of each container image so that director generates a tag and pulls the corresponding image.

7.1.3. Excluding Ceph Storage container images

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.yaml file and add the ceph_images: false parameter.

The following is an example of this file with the parameter bolded:

parameter_defaults:
  ContainerImagePrepare:
  - tag_from_label: {version}-{release}
    set:
      name_prefix: rhosp17-openstack-
      name_suffix: ''
      tag: 17.1_20231214.1
      rhel_containers: false
      neutron_driver: ovn
      ceph_images: false
    push_destination: true

Save the containers-prepare-parameter.yaml file.
Create a new container images file for use in the overcloud deployment:
sudo openstack tripleo container image prepare -e containers-prepare-parameter.yaml --output-env-file <new_container_images_file>
- Replace <new_container_images_file> with the output file that contains the new parameter.
Add the new container images file to the list of overcloud deployment environment files.

7.1.4. Modifying images during preparation

It is possible to modify images during image preparation, and then immediately deploy the overcloud with modified images.

Note

Red Hat OpenStack Platform (RHOSP) director supports modifying images during preparation for RHOSP containers, not for Ceph containers.

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 must be deployed for testing and development.
When changes must be deployed but are not available through an image build pipeline. For example, adding proprietary 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. Control the modification with the modify-specific keys in the ContainerImagePrepare parameter:

modify_role specifies the Ansible role to invoke for each image to modify.
modify_append_tag appends 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 the push_destination registry already contains the modified image. Change modify_append_tag whenever you modify the image.
modify_vars is 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, run the image prepare command without any additional options to confirm that the image is modified as you expect:

sudo openstack tripleo container image prepare \
  -e ~/containers-prepare-parameter.yaml

Important

To use the openstack tripleo container image prepare command, your undercloud must contain a running image-serve registry. As a result, you cannot run this command before a new undercloud installation because the image-serve registry will not be installed. You can run this command after a successful undercloud installation.

7.1.5. Updating existing packages on container images

You can update the existing packages on the container images for Red Hat OpenStack Platform (RHOSP) containers.

Note

Red Hat OpenStack Platform (RHOSP) director supports updating existing packages on container images for RHOSP containers, not for Ceph containers.

Procedure

Download the RPM packages for installation on the container images.

Edit the containers-prepare-parameter.yaml file to update all packages on the container images:

ContainerImagePrepare:
- push_destination: true
  ...
  modify_role: tripleo-modify-image
  modify_append_tag: "-updated"
  modify_vars:
    tasks_from: yum_update.yml
    compare_host_packages: true
    yum_repos_dir_path: /etc/yum.repos.d
  ...

Save the containers-prepare-parameter.yaml file.
Include the containers-prepare-parameter.yaml file when you run the openstack overcloud deploy command.

7.1.6. Installing additional RPM files to container images

You can install a directory of RPM files in your container images. This is useful for installing hotfixes, local package builds, or any package that is not available through a package repository.

Note

Red Hat OpenStack Platform (RHOSP) director supports installing additional RPM files to container images for RHOSP containers, not for Ceph containers.

Note

When you modify container images in existing deployments, you must then perform a minor update to apply the changes to your overcloud. For more information, see Performing a minor update of Red Hat OpenStack Platform.

Procedure

The following example ContainerImagePrepare entry installs some hotfix packages on only the nova-compute image:

ContainerImagePrepare:
- push_destination: true
  ...
  includes:
  - nova-compute
  modify_role: tripleo-modify-image
  modify_append_tag: "-hotfix"
  modify_vars:
    tasks_from: rpm_install.yml
    rpms_path: /home/stack/nova-hotfix-pkgs
  ...

7.1.7. Modifying container images with a custom Dockerfile

You can specify a directory that contains 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.

Note

Red Hat OpenStack Platform (RHOSP) director supports modifying container images with a custom Dockerfile for RHOSP containers, not for Ceph containers.

Procedure

The following example runs the custom Dockerfile on the nova-compute image:

ContainerImagePrepare:
- push_destination: true
  ...
  includes:
  - nova-compute
  modify_role: tripleo-modify-image
  modify_append_tag: "-hotfix"
  modify_vars:
    tasks_from: modify_image.yml
    modify_dir_path: /home/stack/nova-custom
  ...

The following example shows the /home/stack/nova-custom/Dockerfile file. After you run any USER root directives, you must switch back to the original image default user:
```
FROM registry.redhat.io/rhosp-rhel9/openstack-nova-compute:latest

USER "root"

COPY customize.sh /tmp/
RUN /tmp/customize.sh

USER "nova"
```

7.1.8. Preparing a Satellite server for container images

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 information about 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.

Note

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/rhosp-rhel9" --format="{{ .Name }}" | sort > satellite_images
$ sudo podman search --limit 1000 "registry.redhat.io/rhceph" | grep <ceph_dashboard_image_file>
$ sudo podman search --limit 1000 "registry.redhat.io/rhceph" | grep <ceph_image_file>
$ sudo podman search --limit 1000 "registry.redhat.io/openshift4" | grep ose-prometheus
```
- Replace <ceph_dashboard_image_file> with the name of the image file for the version of Red Hat Ceph Storage that your deployment uses:
  - Red Hat Ceph Storage 5: rhceph-5-dashboard-rhel8
  - Red Hat Ceph Storage 6: rhceph-6-dashboard-rhel9
- Replace <ceph_image_file> with the name of the image file for the version of Red Hat Ceph Storage that your deployment uses:
  - Red Hat Ceph Storage 5: rhceph-5-rhel8
  - Red Hat Ceph Storage 6: rhceph-6-rhel9
    Note
    The openstack-ovn-bgp-agent image is located at registry.redhat.io/rhosp-rhel9/openstack-ovn-bgp-agent-rhel9:17.1.
- If you plan to install Ceph and enable the Ceph Dashboard, you need the following ose-prometheus containers:
```
registry.redhat.io/openshift4/ose-prometheus-node-exporter:v4.12
registry.redhat.io/openshift4/ose-prometheus:v4.12
registry.redhat.io/openshift4/ose-prometheus-alertmanager:v4.12
```
Copy the satellite_images file to a system that contains the Satellite 6 hammer tool. Alternatively, use the instructions in the Hammer CLI Guide to install the hammer tool to the undercloud.
Run the following hammer command to create a new product (OSP Containers) in your Satellite organization:
```
$ hammer product create \
  --organization "ACME" \
  --name "OSP Containers"
```
This custom product will contain your images.

Add the overcloud container images from the satellite_images file:

$ while read IMAGE; do \
  IMAGE_NAME=$(echo $IMAGE | cut -d"/" -f3 | sed "s/openstack-//g") ; \
  IMAGE_NOURL=$(echo $IMAGE | sed "s/registry.redhat.io\///g") ; \
  hammer repository create \
  --organization "ACME" \
  --product "OSP Containers" \
  --content-type docker \
  --url https://registry.redhat.io \
  --docker-upstream-name $IMAGE_NOURL \
  --upstream-username USERNAME \
  --upstream-password PASSWORD \
  --name $IMAGE_NAME ; done < satellite_images

Add the Ceph Storage container image:

$ hammer repository create \
  --organization "ACME" \
  --product "OSP Containers" \
  --content-type docker \
  --url https://registry.redhat.io \
  --docker-upstream-name rhceph/<ceph_image_name> \
  --upstream-username USERNAME \
  --upstream-password PASSWORD \
  --name <ceph_image_name>

Replace <ceph_image_file> with the name of the image file for the version of Red Hat Ceph Storage that your deployment uses:
- Red Hat Ceph Storage 5: rhceph-5-rhel8
- Red Hat Ceph Storage 6: rhceph-6-rhel9
  Note
  If you want to install the Ceph dashboard, include --name <ceph_dashboard_image_name> in the hammer repository create command:
  $ hammer repository create \ --organization "ACME" \ --product "OSP Containers" \ --content-type docker \ --url https://registry.redhat.io \ --docker-upstream-name rhceph/<ceph_dashboard_image_name> \ --upstream-username USERNAME \ --upstream-password PASSWORD \ --name <ceph_dashboard_image_name>
  Replace <ceph_dashboard_image_file> with the name of the image file for the version of Red Hat Ceph Storage that your deployment uses:
  Red Hat Ceph Storage 5: rhceph-5-dashboard-rhel8
  Red Hat Ceph Storage 6: rhceph-6-dashboard-rhel9

Synchronize the container images:
```
$ hammer product synchronize \
  --organization "ACME" \
  --name "OSP Containers"
```
Wait for the Satellite server to complete synchronization.
Note
Depending on your configuration, hammer might ask for your Satellite server username and password. You can configure hammer to 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 production in your lifecycle and you want the container images to be available in that environment, create a content view that includes the container images and promote that content view to the production environment. For more information, see Managing Content Views.
Check the available tags for the base image:
```
$ hammer docker tag list --repository "base" \
  --organization "ACME" \
  --lifecycle-environment "production" \
  --product "OSP Containers"
```
This command displays tags for the OpenStack Platform container images within a content view for a particular environment.
Return to the undercloud and generate a default environment file that prepares images using your Satellite server as a source. Run the following example command to generate the environment file:
```
$ sudo openstack tripleo container image prepare default \
  --output-env-file containers-prepare-parameter.yaml
```
- --output-env-file is an environment file name. The contents of this file include the parameters for preparing your container images for the undercloud. In this case, the name of the file is containers-prepare-parameter.yaml.
Edit the containers-prepare-parameter.yaml file and modify the following parameters:
- push_destination - Set this to true or false depending on your chosen container image management strategy. If you set this parameter to false, the overcloud nodes pull images directly from the Satellite. If you set this parameter to true, the director pulls the images from the Satellite to the undercloud registry and the overcloud pulls the images from the undercloud registry.
- namespace - The URL of the registry on the Satellite server.
- 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-myosp17-osp_containers-.
  - If you do not use content views, the structure is [org]-[product]-. For example: acme-osp_containers-.
- ceph_namespace, ceph_image, ceph_tag - If you use Ceph Storage, include these additional parameters to define the Ceph Storage container image location. Note that ceph_image now includes a Satellite-specific prefix. This prefix is the same value as the name_prefix option.

The following example environment file contains Satellite-specific parameters:

parameter_defaults:
  ContainerImagePrepare:
  - push_destination: false
    set:
      ceph_image: acme-production-myosp17_1-osp_containers-rhceph-6
      ceph_namespace: satellite.example.com:443
      ceph_tag: latest
      name_prefix: acme-production-myosp17_1-osp_containers-
      name_suffix: ''
      namespace: satellite.example.com:5000
      neutron_driver: null
      tag: '17.1'
      ...

Note

To use a specific container image version stored on your Red Hat Satellite Server, set the tag key-value pair to the specific version in the set dictionary. For example, to use the 17.1.2 image stream, set tag: 17.1.2 in the set dictionary.

You must define the containers-prepare-parameter.yaml environment file in the undercloud.conf configuration file, otherwise the undercloud uses the default values:

container_images_file = /home/stack/containers-prepare-parameter.yaml

7.1.9. Deploying a vendor plugin

To use some third-party hardware as a Block Storage back end, you must deploy a vendor plugin. The following example demonstrates how to deploy a vendor plugin to use Dell EMC hardware as a Block Storage back end.

Procedure

Create a new container images file for your overcloud:

$ sudo openstack tripleo container image prepare default \
    --local-push-destination \
    --output-env-file containers-prepare-parameter-dellemc.yaml

Edit the containers-prepare-parameter-dellemc.yaml file.

Add an exclude parameter to the strategy for the main Red Hat OpenStack Platform container images. Use this parameter to exclude the container image that the vendor container image will replace. In the example, the container image is the cinder-volume image:

parameter_defaults:
  ContainerImagePrepare:
    - push_destination: true
      excludes:
  	   - cinder-volume
      set:
        namespace: registry.redhat.io/rhosp-rhel9
        name_prefix: openstack-
        name_suffix: ''
        tag: 17.1
        ...
      tag_from_label: "{version}-{release}"

Add a new strategy to the ContainerImagePrepare parameter that includes the replacement container image for the vendor plugin:

parameter_defaults:
  ContainerImagePrepare:
    ...
    - push_destination: true
      includes:
        - cinder-volume
      set:
        namespace: registry.connect.redhat.com/dellemc
        name_prefix: openstack-
        name_suffix: -dellemc-rhosp16
        tag: 16.2-2
        ...

Add the authentication details for the registry.connect.redhat.com registry to the ContainerImageRegistryCredentials parameter:

parameter_defaults:
  ContainerImageRegistryCredentials:
    registry.redhat.io:
      [service account username]: [service account password]
    registry.connect.redhat.com:
      [service account username]: [service account password]

Save the containers-prepare-parameter-dellemc.yaml file.
Include the containers-prepare-parameter-dellemc.yaml file with any deployment commands, such as as openstack overcloud deploy:
```
$ openstack overcloud deploy --templates
    ...
    -e containers-prepare-parameter-dellemc.yaml
    ...
```
When director deploys the overcloud, the overcloud uses the vendor container image instead of the standard container image.
IMPORTANT
The containers-prepare-parameter-dellemc.yaml file replaces the standard containers-prepare-parameter.yaml file in your overcloud deployment. Do not include the standard containers-prepare-parameter.yaml file in your overcloud deployment. Retain the standard containers-prepare-parameter.yaml file for your undercloud installation and updates.

7.2. Performing advanced container image management

The default container image configuration suits most environments. In some situations, your container image configuration might require some customization, such as version pinning.

7.2.1. Pinning container images for the undercloud

In certain circumstances, you might require a set of specific container image versions for your undercloud. In this situation, you must pin the images to a specific version. To pin your images, you must generate and modify a container configuration file, and then combine the undercloud roles data with the container configuration file to generate an environment file that contains a mapping of services to container images. Then include this environment file in the custom_env_files parameter in the undercloud.conf file.

Procedure

Log in to the undercloud host as the stack user.
Run the openstack tripleo container image prepare default command with the --output-env-file option to generate a file that contains the default image configuration:
```
$ sudo openstack tripleo container image prepare default \
--output-env-file undercloud-container-image-prepare.yaml
```
Modify the undercloud-container-image-prepare.yaml file according to the requirements of your environment.
1. Remove the tag: parameter so that director can use the tag_from_label: parameter. Director uses this parameter to identify the latest version of each container image, pull each image, and tag each image on the container registry in director.
2. Remove the Ceph labels for the undercloud.
3. Ensure that the neutron_driver: parameter is empty. Do not set this parameter to OVN because OVN is not supported on the undercloud.
4. Include your container image registry credentials:
```
ContainerImageRegistryCredentials:
  registry.redhat.io:
    myser: 'p@55w0rd!'
```
  Note
  You cannot push container images to the undercloud registry on new underclouds because the image-serve registry is not installed yet. You must set the push_destination value to false, or use a custom value, to pull images directly from source. For more information, see Container image preparation parameters.
Generate a new container image configuration file that uses the undercloud roles file combined with your custom undercloud-container-image-prepare.yaml file:
```
$ sudo openstack tripleo container image prepare \
-r /usr/share/openstack-tripleo-heat-templates/roles_data_undercloud.yaml \
-e undercloud-container-image-prepare.yaml \
--output-env-file undercloud-container-images.yaml
```
The undercloud-container-images.yaml file is an environment file that contains a mapping of service parameters to container images. For example, OpenStack Identity (keystone) uses the ContainerKeystoneImage parameter to define its container image:
```
ContainerKeystoneImage: undercloud.ctlplane.localdomain:8787/rhosp-rhel9/openstack-keystone:17.1
```
Note that the container image tag matches the {version}-{release} format.
Include the undercloud-container-images.yaml file in the custom_env_files parameter in the undercloud.conf file. When you run the undercloud installation, the undercloud services use the pinned container image mapping from this file.

7.2.2. Pinning container images for the overcloud

In certain circumstances, you might require a set of specific container image versions for your overcloud. In this situation, you must pin the images to a specific version. To pin your images, you must create the containers-prepare-parameter.yaml file, use this file to pull your container images to the undercloud registry, and generate an environment file that contains a pinned image list.

For example, your containers-prepare-parameter.yaml file might contain the following content:

parameter_defaults:
  ContainerImagePrepare:
    - push_destination: true
      set:
        name_prefix: openstack-
        name_suffix: ''
        namespace: registry.redhat.io/rhosp-rhel9
        neutron_driver: ovn
      tag_from_label: '{version}-{release}'

  ContainerImageRegistryCredentials:
    registry.redhat.io:
      myuser: 'p@55w0rd!'

The ContainerImagePrepare parameter contains a single rule set. This rule set must not include the tag parameter and must rely on the tag_from_label parameter to identify the latest version and release of each container image. Director uses this rule set to identify the latest version of each container image, pull each image, and tag each image on the container registry in director.

Procedure

Run the openstack tripleo container image prepare command, which pulls all images from the source defined in the containers-prepare-parameter.yaml file. Include the --output-env-file to specify the output file that will contain the list of pinned container images:
```
$ sudo openstack tripleo container image prepare -e /home/stack/templates/containers-prepare-parameter.yaml --output-env-file overcloud-images.yaml
```
The overcloud-images.yaml file is an environment file that contains a mapping of service parameters to container images. For example, OpenStack Identity (keystone) uses the ContainerKeystoneImage parameter to define its container image:
```
ContainerKeystoneImage: undercloud.ctlplane.localdomain:8787/rhosp-rhel9/openstack-keystone:17.1
```
Note that the container image tag matches the {version}-{release} format.
Include the containers-prepare-parameter.yaml and overcloud-images.yaml files in that specific order with your environment file collection when you run the openstack overcloud deploy command:
```
$ openstack overcloud deploy --templates \
    ...
    -e /home/stack/containers-prepare-parameter.yaml \
    -e /home/stack/overcloud-images.yaml \
    ...
```

The overcloud services use the pinned images listed in the overcloud-images.yaml file.

Ce contenu n'est pas disponible dans la langue sélectionnée.

Chapter 7. Customizing container images

7.1. Preparing container images for director installation

7.1.1. Container image preparation parameters

7.1.2. Guidelines for container image tagging

7.1.3. Excluding Ceph Storage container images

7.1.4. Modifying images during preparation

7.1.5. Updating existing packages on container images

7.1.6. Installing additional RPM files to container images

7.1.7. Modifying container images with a custom Dockerfile

7.1.8. Preparing a Satellite server for container images

7.1.9. Deploying a vendor plugin

7.2. Performing advanced container image management

7.2.1. Pinning container images for the undercloud

7.2.2. Pinning container images for the overcloud

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Rendre l’open source plus inclusif

À propos de Red Hat

Red Hat legal and privacy links

Red Hat legal and privacy links