Red Hat SummitChapter 2. Containerized services
Director installs the core OpenStack Platform services as containers on the overcloud. This section provides some background information on how containerized services work.
2.1. Containerized service architecture
Director installs the core OpenStack Platform services as containers on the overcloud. The templates for the containerized services are located in the /usr/share/openstack-tripleo-heat-templates/deployment/.
You must enable the OS::TripleO::Services::Podman service in the role for all nodes that use containerized services. When you create a roles_data.yaml file for your custom roles configuration, include the OS::TripleO::Services::Podman service along with the base composable services. For example, the IronicConductor role uses the following role definition:
- name: IronicConductor
description: |
Ironic Conductor node role
networks:
InternalApi:
subnet: internal_api_subnet
Storage:
subnet: storage_subnet
HostnameFormatDefault: '%stackname%-ironic-%index%'
ServicesDefault:
- OS::TripleO::Services::Aide
- OS::TripleO::Services::AuditD
- OS::TripleO::Services::BootParams
- OS::TripleO::Services::CACerts
- OS::TripleO::Services::CertmongerUser
- OS::TripleO::Services::Collectd
- OS::TripleO::Services::Docker
- OS::TripleO::Services::Fluentd
- OS::TripleO::Services::IpaClient
- OS::TripleO::Services::Ipsec
- OS::TripleO::Services::IronicConductor
- OS::TripleO::Services::IronicPxe
- OS::TripleO::Services::Kernel
- OS::TripleO::Services::LoginDefs
- OS::TripleO::Services::MetricsQdr
- OS::TripleO::Services::MySQLClient
- OS::TripleO::Services::ContainersLogrotateCrond
- OS::TripleO::Services::Podman
- OS::TripleO::Services::Rhsm
- OS::TripleO::Services::SensuClient
- OS::TripleO::Services::Snmp
- OS::TripleO::Services::Timesync
- OS::TripleO::Services::Timezone
- OS::TripleO::Services::TripleoFirewall
- OS::TripleO::Services::TripleoPackages
- OS::TripleO::Services::Tuned2.2. Containerized service parameters
Each containerized service template contains an outputs section that defines a data set passed to the OpenStack Orchestration (heat) service. In addition to the standard composable service parameters, the template contains a set of parameters specific to the container configuration.
puppet_configData to pass to Puppet when configuring the service. In the initial overcloud deployment steps, director creates a set of containers used to configure the service before the actual containerized service runs. This parameter includes the following sub-parameters:
-
config_volume- The mounted volume that stores the configuration. -
puppet_tags- Tags to pass to Puppet during configuration. OpenStack uses these tags to restrict the Puppet run to the configuration resource of a particular service. For example, the OpenStack Identity (keystone) containerized service uses thekeystone_configtag to ensure that all require only thekeystone_configPuppet resource run on the configuration container. -
step_config- The configuration data passed to Puppet. This is usually inherited from the referenced composable service. -
config_image- The container image used to configure the service.
-
kolla_config- A set of container-specific data that defines configuration file locations, directory permissions, and the command to run on the container to launch the service.
docker_configTasks to run on the configuration container for the service. All tasks are grouped into the following steps to help director perform a staged deployment:
- Step 1 - Load balancer configuration
- Step 2 - Core services (Database, Redis)
- Step 3 - Initial configuration of OpenStack Platform service
- Step 4 - General OpenStack Platform services configuration
- Step 5 - Service activation
host_prep_tasks- Preparation tasks for the bare metal node to accommodate the containerized service.
2.3. 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
excludeparameter 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 thecinder-volumeimage:parameter_defaults: ContainerImagePrepare: - push_destination: true excludes: - cinder-volume set: namespace: registry.redhat.io/rhosp-rhel9 name_prefix: openstack- name_suffix: '' tag: 16.2 ... tag_from_label: "{version}-{release}"Add a new strategy to the
ContainerImagePrepareparameter 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
ContainerImageRegistryCredentialsparameter: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.yamlfile. Include the
containers-prepare-parameter-dellemc.yamlfile with any deployment commands, such as asopenstack 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.yamlfile replaces the standardcontainers-prepare-parameter.yamlfile in your overcloud deployment. Do not include the standardcontainers-prepare-parameter.yamlfile in your overcloud deployment. Retain the standardcontainers-prepare-parameter.yamlfile for your undercloud installation and updates.
