고급 오버클라우드 사용자 정의

1. 코어 heat 템플릿 컬렉션에서 기본 구성을 로드합니다.
2. environment-file-1.yaml 의 구성을 적용하여 기본 구성의 일반적인 설정을 재정의합니다.
3. environment-file-2.yaml 의 구성을 적용하여 기본 구성 및 environment-file-1.yaml 의 공통 설정을 재정의합니다.

1. 구성할 옵션을 식별합니다. 옵션을 사용하는 서비스를 기록합니다.

2. 이 옵션에 해당하는 Puppet 모듈을 확인합니다. Red Hat OpenStack Platform용 Puppet 모듈은 director 노드의 /etc/puppet/modules 에 있습니다. 각 모듈은 특정 서비스에 해당합니다. 예를 들어 keystone 모듈은 OpenStack ID(keystone)에 해당합니다.

   • Puppet 모듈에 선택한 옵션을 제어하는 변수가 포함된 경우 다음 단계로 이동합니다.
   • Puppet 모듈에 선택한 옵션을 제어하는 변수가 없으면 이 옵션에 대한 hieradata가 없습니다. 가능한 경우 오버클라우드가 배포를 완료한 후 수동으로 옵션을 설정할 수 있습니다.

3. hieradata 형식으로 Puppet 변수의 코어 Heat 템플릿 컬렉션을 확인합니다. deployment/* 의 템플릿은 일반적으로 동일한 서비스의 Puppet 모듈에 해당합니다. 예를 들어 deployment/keystone/keystone-container-puppet.yaml 템플릿은 keystone 모듈에 hieradata를 제공합니다.

   • heat 템플릿에서 Puppet 변수에 hieradata를 설정하는 경우 템플릿에서 수정할 수 있는 director 기반 매개 변수도 공개해야 합니다.
   • heat 템플릿에서 Puppet 변수에 hieradata를 설정하지 않으면 구성 후크를 사용하여 환경 파일을 사용하여 hieradata를 전달합니다. hieradata 사용자 지정에 대한 자세한 내용은 4.5절. “Puppet: 역할에 대한 hieradata 사용자 정의” 을 참조하십시오.

절차

1. OpenStack Identity(keystone)의 알림 형식을 변경하려면 워크플로우를 사용하고 다음 단계를 완료합니다.

   1. 구성할 OpenStack 매개 변수(notification_format)를 식별합니다.

   2. notification_format 설정을 위해 keystone Puppet 모듈을 검색합니다.

      $ grep notification_format /etc/puppet/modules/keystone/manifests/*

      이 경우 keystone 모듈은 keystone ::notification_format 변수를 사용하여 이 옵션을 관리합니다.

   3. 이 변수에 대해 keystone 서비스 템플릿을 검색합니다.

      $ grep "keystone::notification_format" /usr/share/openstack-tripleo-heat-templates/deployment/keystone/keystone-container-puppet.yaml

      출력에는 director에서 KeystoneNotificationFormat 매개변수를 사용하여 keystone::notification_format hieradata를 설정하는 것을 확인할 수 있습니다.

절차

1. 스크립트를 실행하여 각 노드에 resolv .conf 파일을 특정 이름 서버로 추가하는 기본 heat 템플릿 ~/templates/nameserver. yaml 을 생성합니다. OS::TripleO::MultipartMime 리소스 유형을 사용하여 구성 스크립트를 보낼 수 있습니다.

   heat_template_version: 2014-10-16
   
   description: >
     Extra hostname configuration
   
   resources:
     userdata:
       type: OS::Heat::MultipartMime
       properties:
         parts:
         - config: {get_resource: nameserver_config}
   
     nameserver_config:
       type: OS::Heat::SoftwareConfig
       properties:
         config: |
           #!/bin/bash
           echo "nameserver 192.168.1.1" >> /etc/resolv.conf
   
   outputs:
     OS::stack_id:
       value: {get_resource: userdata}

2. heat 템플릿을 OS::TripleO::NodeUserData 리소스 유형으로 등록하는 환경 파일 ~/templates/firstboot.yaml 을 생성합니다.

   resource_registry:
     OS::TripleO::NodeUserData: /home/stack/templates/nameserver.yaml

3. 첫 번째 부팅 구성을 오버클라우드에 추가하려면 다른 환경 파일과 함께 스택에 환경 파일을 추가합니다.

   $ openstack overcloud deploy --templates \
       ...
       -e /home/stack/templates/firstboot.yaml \
       ...

   그러면 처음 생성될 때 모든 노드에 구성이 추가되고 처음으로 부팅됩니다. 이후 오버클라우드 스택 업데이트와 같은 이러한 템플릿은 이러한 스크립트를 실행하지 않습니다.

절차

1. 스크립트를 실행하여 노드의 resolv .conf 파일에 변수 이름 서버를 작성하는 기본 heat 템플릿 ~/templates/nameserver. yaml 을 생성합니다.

   heat_template_version: 2014-10-16
   
   description: >
     Extra hostname configuration
   
   parameters:
     server:
       type: string
     nameserver_ip:
       type: string
     DeployIdentifier:
       type: string
   
   resources:
     CustomExtraConfigPre:
       type: OS::Heat::SoftwareConfig
       properties:
         group: script
         config:
           str_replace:
             template: |
               #!/bin/sh
               echo "nameserver _NAMESERVER_IP_" > /etc/resolv.conf
             params:
               _NAMESERVER_IP_: {get_param: nameserver_ip}
   
     CustomExtraDeploymentPre:
       type: OS::Heat::SoftwareDeployment
       properties:
         server: {get_param: server}
         config: {get_resource: CustomExtraConfigPre}
         actions: ['CREATE','UPDATE']
         input_values:
           deploy_identifier: {get_param: DeployIdentifier}
   
   outputs:
     deploy_stdout:
       description: Deployment reference, used to trigger pre-deploy on changes
       value: {get_attr: [CustomExtraDeploymentPre, deploy_stdout]}

   이 예제에서 resources 섹션에는 다음 매개변수가 포함되어 있습니다.

   CustomExtraConfigPre

   소프트웨어 구성을 정의합니다. 이 예제에서는 Bash 스크립트를 정의하고 heat는 _NAMESERVER_IP_ 를 nameserver_ip 매개 변수에 저장된 값으로 바꿉니다.

   CustomExtraDeploymentPre

   그러면 CustomExtraConfigPre 리소스의 소프트웨어 구성인 소프트웨어 구성이 실행됩니다. 다음을 확인합니다.

   • heat가 적용할 구성을 인식하도록 config 매개변수는 CustomExtraConfigPre 리소스를 참조합니다.
   • server 매개 변수는 Overcloud 노드 맵을 검색합니다. 이 매개 변수는 상위 템플릿에서 제공하며 이 후크의 템플릿에서 필요합니다.
   • actions 매개 변수는 구성을 적용할 시기를 정의합니다. 이 경우 오버클라우드가 생성될 때 구성을 적용해야 합니다. 가능한 작업에는 CREATE,UPDATE,DELETE,SUSPEND, RESUME 등이 있습니다.
   • input_values 에는 상위 템플릿에서 DeployIdentifier 를 저장하는 deploy_identifier 라는 매개 변수가 포함되어 있습니다. 이 매개 변수는 각 배포 업데이트의 리소스에 타임스탬프를 제공하여 후속 오버클라우드 업데이트에 리소스가 다시 적용되도록 합니다.

2. heat 템플릿을 역할 기반 리소스 유형에 등록하는 환경 파일 ~/templates/pre_config.yaml 을 생성합니다. 예를 들어 컨트롤러 노드에만 구성을 적용하려면 ControllerExtraConfigPre 후크를 사용합니다.

   resource_registry:
     OS::TripleO::ControllerExtraConfigPre: /home/stack/templates/nameserver.yaml
   
   parameter_defaults:
     nameserver_ip: 192.168.1.1

3. 다른 환경 파일과 함께 스택에 환경 파일을 추가합니다.

   $ openstack overcloud deploy --templates \
       ...
       -e /home/stack/templates/pre_config.yaml \
       ...

   그러면 초기 오버클라우드 생성 또는 이후 업데이트에서 코어 구성이 시작되기 전에 모든 컨트롤러 노드에 구성이 적용됩니다.

절차

1. 스크립트를 실행하여 각 노드의 resolv .conf 파일을 변수 이름 서버로 추가하는 기본 heat 템플릿 ~/templates/nameserver. yaml 을 생성합니다.

   heat_template_version: 2014-10-16
   
   description: >
     Extra hostname configuration
   
   parameters:
     server:
       type: string
     nameserver_ip:
       type: string
     DeployIdentifier:
       type: string
   
   resources:
     CustomExtraConfigPre:
       type: OS::Heat::SoftwareConfig
       properties:
         group: script
         config:
           str_replace:
             template: |
               #!/bin/sh
               echo "nameserver _NAMESERVER_IP_" >> /etc/resolv.conf
             params:
               _NAMESERVER_IP_: {get_param: nameserver_ip}
   
     CustomExtraDeploymentPre:
       type: OS::Heat::SoftwareDeployment
       properties:
         server: {get_param: server}
         config: {get_resource: CustomExtraConfigPre}
         actions: ['CREATE','UPDATE']
         input_values:
           deploy_identifier: {get_param: DeployIdentifier}
   
   outputs:
     deploy_stdout:
       description: Deployment reference, used to trigger pre-deploy on changes
       value: {get_attr: [CustomExtraDeploymentPre, deploy_stdout]}

   이 예제에서 resources 섹션에는 다음 매개변수가 포함되어 있습니다.

   CustomExtraConfigPre

   이 매개 변수는 소프트웨어 구성을 정의합니다. 이 예제에서는 Bash 스크립트를 정의하고 heat는 _NAMESERVER_IP_ 를 nameserver_ip 매개 변수에 저장된 값으로 바꿉니다.

   CustomExtraDeploymentPre

   이 매개 변수는 CustomExtraConfigPre 리소스의 소프트웨어 구성인 소프트웨어 구성을 실행합니다. 다음을 확인합니다.

   • heat가 적용할 구성을 인식하도록 config 매개변수는 CustomExtraConfigPre 리소스를 참조합니다.
   • server 매개 변수는 Overcloud 노드 맵을 검색합니다. 이 매개 변수는 상위 템플릿에서 제공하며 이 후크의 템플릿에서 필요합니다.
   • actions 매개 변수는 구성을 적용할 시기를 정의합니다. 이 경우 오버클라우드가 생성될 때만 구성을 적용합니다. 가능한 작업에는 CREATE,UPDATE,DELETE,SUSPEND, RESUME 등이 있습니다.
   • input_values 매개 변수에는 상위 템플릿에서 DeployIdentifier 를 저장하는 deploy_identifier 라는 하위 매개 변수가 포함되어 있습니다. 이 매개 변수는 각 배포 업데이트의 리소스에 타임스탬프를 제공하여 후속 오버클라우드 업데이트에 리소스가 다시 적용되도록 합니다.

2. heat 템플릿을 OS::TripleO::NodeExtraConfig 리소스 유형으로 등록하는 환경 파일 ~/templates/pre_config.yaml 을 생성합니다.

   resource_registry:
     OS::TripleO::NodeExtraConfig: /home/stack/templates/nameserver.yaml
   
   parameter_defaults:
     nameserver_ip: 192.168.1.1

3. 다른 환경 파일과 함께 스택에 환경 파일을 추가합니다.

   $ openstack overcloud deploy --templates \
       ...
       -e /home/stack/templates/pre_config.yaml \
       ...

   이렇게 하면 초기 오버클라우드 생성 또는 이후 업데이트에서 코어 구성이 시작되기 전에 모든 노드에 구성이 적용됩니다.

절차

1. 스크립트를 실행하여 각 노드의 resolv .conf 파일을 변수 이름 서버로 추가하는 기본 heat 템플릿 ~/templates/nameserver. yaml 을 생성합니다.

   heat_template_version: 2014-10-16
   
   description: >
     Extra hostname configuration
   
   parameters:
     servers:
       type: json
     nameserver_ip:
       type: string
     DeployIdentifier:
       type: string
     EndpointMap:
       default: {}
       type: json
   
   resources:
     CustomExtraConfig:
       type: OS::Heat::SoftwareConfig
       properties:
         group: script
         config:
           str_replace:
             template: |
               #!/bin/sh
               echo "nameserver _NAMESERVER_IP_" >> /etc/resolv.conf
             params:
               _NAMESERVER_IP_: {get_param: nameserver_ip}
   
     CustomExtraDeployments:
       type: OS::Heat::SoftwareDeploymentGroup
       properties:
         servers:  {get_param: servers}
         config: {get_resource: CustomExtraConfig}
         actions: ['CREATE','UPDATE']
         input_values:
           deploy_identifier: {get_param: DeployIdentifier}

   이 예제에서 resources 섹션에는 다음 매개변수가 포함되어 있습니다.

   CustomExtraConfig

   소프트웨어 구성을 정의합니다. 이 예제에서는 Bash 스크립트를 정의하고 heat는 _NAMESERVER_IP_ 를 nameserver_ip 매개 변수에 저장된 값으로 바꿉니다.

   CustomExtraDeployments

   그러면 CustomExtraConfig 리소스의 소프트웨어 구성인 소프트웨어 구성이 실행됩니다. 다음을 확인합니다.

   • heat가 적용할 구성을 인식하도록 config 매개변수는 CustomExtraConfig 리소스를 참조합니다.
   • servers 매개 변수는 Overcloud 노드 맵을 검색합니다. 이 매개 변수는 상위 템플릿에서 제공하며 이 후크의 템플릿에서 필요합니다.
   • actions 매개 변수는 구성을 적용할 시기를 정의합니다. 이 경우 오버클라우드가 생성될 때 구성을 적용해야 합니다. 가능한 작업에는 CREATE,UPDATE,DELETE,SUSPEND, RESUME 등이 있습니다.
   • input_values 에는 상위 템플릿에서 DeployIdentifier 를 저장하는 deploy_identifier 라는 매개 변수가 포함되어 있습니다. 이 매개 변수는 각 배포 업데이트의 리소스에 타임스탬프를 제공하여 후속 오버클라우드 업데이트에 리소스가 다시 적용되도록 합니다.

2. heat 템플릿을 OS::TripleO::NodeExtraConfigPost: 리소스 유형으로 등록하는 환경 파일 ~/templates/post_config.yaml 을 생성합니다.

   resource_registry:
     OS::TripleO::NodeExtraConfigPost: /home/stack/templates/nameserver.yaml
   
   parameter_defaults:
     nameserver_ip: 192.168.1.1

3. 다른 환경 파일과 함께 스택에 환경 파일을 추가합니다.

   $ openstack overcloud deploy --templates \
       ...
       -e /home/stack/templates/post_config.yaml \
       ...

   이렇게 하면 초기 오버클라우드 생성 또는 이후 업데이트 시 코어 구성이 완료된 후 모든 노드에 구성이 적용됩니다.

절차

1. 배포 후 구성 프로세스에 구성을 추가하려면 parameter_defaults 섹션에 이러한 매개 변수를 포함하는 환경 파일을 생성합니다. 예를 들어 Compute 호스트의 예약된 메모리를 1024MB로 늘리고 VNC 키맵을 일본어로 설정하려면 ComputeExtraConfig 매개변수에서 다음 항목을 사용합니다.

   parameter_defaults:
     ComputeExtraConfig:
       nova::compute::reserved_host_memory: 1024
       nova::compute::vnc_keymap: ja

2. 배포와 관련된 기타 환경 파일과 함께 openstack overcloud deploy 명령에 이 환경 파일을 포함합니다.

절차

1. 노드의 인트로스펙션 데이터에서 시스템 UUID를 식별합니다.

   $ openstack baremetal introspection data save 9dcc87ae-4c6d-4ede-81a5-9b20d7dc4a14 | jq .extra.system.product.uuid

   이 명령은 시스템 UUID를 반환합니다. 예를 들면 다음과 같습니다.

   "f5055c6c-477f-47fb-afe5-95c6928c407f"

2. 환경 파일을 생성하여 노드별 hieradata를 정의하고 per_node.yaml 템플릿을 사전 구성 후크에 등록합니다. NodeDataLookup 매개변수에 구성하려는 노드의 시스템 UUID를 포함합니다.

   resource_registry:
     OS::TripleO::ComputeExtraConfigPre: /usr/share/openstack-tripleo-heat-templates/puppet/extraconfig/pre_deploy/per_node.yaml
   parameter_defaults:
     NodeDataLookup: '{"f5055c6c-477f-47fb-afe5-95c6928c407f": {"nova::compute::vcpu_pin_set": [ "2", "3" ]}}'

3. 배포와 관련된 기타 환경 파일과 함께 openstack overcloud deploy 명령에 이 환경 파일을 포함합니다.

절차

1. Puppet 구성을 시작하는 heat 템플릿 ~/templates/custom_puppet_config.yaml 을 생성합니다.

   heat_template_version: 2014-10-16
   
   description: >
     Run Puppet extra configuration to set new MOTD
   
   parameters:
     servers:
       type: json
     DeployIdentifier:
       type: string
     EndpointMap:
       default: {}
       type: json
   
   resources:
     ExtraPuppetConfig:
       type: OS::Heat::SoftwareConfig
       properties:
         config: {get_file: motd.pp}
         group: puppet
         options:
           enable_hiera: True
           enable_facter: False
   
     ExtraPuppetDeployments:
       type: OS::Heat::SoftwareDeploymentGroup
       properties:
         config: {get_resource: ExtraPuppetConfig}
         servers: {get_param: servers}

   이 예제에는 템플릿에 /home/stack/templates/motd.pp 이 포함되어 있으며 구성을 위해 노드에 전달합니다. motd.pp 파일에는 motd를 설치하고 구성하는 데 필요한 Puppet 클래스가 포함되어 있습니다 .

2. heat 템플릿을 OS::TripleO::NodeExtraConfigPost: 리소스 유형으로 등록하는 환경 파일 ~templates/puppet_post_config.yaml 을 생성합니다.

   resource_registry:
     OS::TripleO::NodeExtraConfigPost: /home/stack/templates/custom_puppet_config.yaml

3. 배포와 관련된 기타 환경 파일과 함께 openstack overcloud deploy 명령에 이 환경 파일을 포함합니다.

   $ openstack overcloud deploy --templates \
       ...
       -e /home/stack/templates/puppet_post_config.yaml \
       ...

   그러면 motd.pp 의 구성이 오버클라우드의 모든 노드에 적용됩니다.

절차

1. templates/rhsm.yml 이라는 환경 파일을 만들어 구성을 저장합니다.

2. 환경 파일에 구성을 포함합니다. 예를 들면 다음과 같습니다.

   resource_registry:
     OS::TripleO::Services::Rhsm: /usr/share/openstack-tripleo-heat-templates/deployment/rhsm/rhsm-baremetal-ansible.yaml
   parameter_defaults:
     RhsmVars:
       rhsm_repos:
         - rhel-8-for-x86_64-baseos-eus-rpms
         - rhel-8-for-x86_64-appstream-eus-rpms
         - rhel-8-for-x86_64-highavailability-eus-rpms
         …​
       rhsm_username: "myusername"
       rhsm_password: "p@55w0rd!"
       rhsm_org_id: "1234567"
       rhsm_pool_ids: "1a85f9223e3d5e43013e3d6e8ff506fd"
       rhsm_method: "portal"
       rhsm_release: 8.4

   • resource_registry 섹션은 각 역할에서 사용할 수 있는 OS::TripleO::Services::Rhsm 리소스와 rhsm 구성 가능 서비스를 연결합니다.
   • RhsmVars 변수는 Red Hat 등록을 구성하기 위해 매개 변수를 Ansible에 전달합니다.
3. 환경 파일을 저장합니다.

절차

1. templates/rhsm.yml 이라는 환경 파일을 만들어 구성을 저장합니다.

2. 환경 파일에 구성을 포함합니다. 예를 들면 다음과 같습니다.

   resource_registry:
     OS::TripleO::Services::Rhsm: /usr/share/openstack-tripleo-heat-templates/deployment/rhsm/rhsm-baremetal-ansible.yaml
   parameter_defaults:
     ControllerParameters:
       RhsmVars:
         rhsm_repos:
           - rhel-8-for-x86_64-baseos-eus-rpms
           - rhel-8-for-x86_64-appstream-eus-rpms
           - rhel-8-for-x86_64-highavailability-eus-rpms
           - ansible-2.9-for-rhel-8-x86_64-rpms
           - openstack-16.2-for-rhel-8-x86_64-rpms
           - fast-datapath-for-rhel-8-x86_64-rpms
         rhsm_username: "myusername"
         rhsm_password: "p@55w0rd!"
         rhsm_org_id: "1234567"
         rhsm_pool_ids: "55d251f1490556f3e75aa37e89e10ce5"
         rhsm_method: "portal"
         rhsm_release: 8.4
     ComputeParameters:
       RhsmVars:
         rhsm_repos:
           - rhel-8-for-x86_64-baseos-eus-rpms
           - rhel-8-for-x86_64-appstream-eus-rpms
           - rhel-8-for-x86_64-highavailability-eus-rpms
           - ansible-2.9-for-rhel-8-x86_64-rpms
           - openstack-16.2-for-rhel-8-x86_64-rpms
           - fast-datapath-for-rhel-8-x86_64-rpms
         rhsm_username: "myusername"
         rhsm_password: "p@55w0rd!"
         rhsm_org_id: "1234567"
         rhsm_pool_ids: "55d251f1490556f3e75aa37e89e10ce5"
         rhsm_method: "portal"
         rhsm_release: 8.4
     CephStorageParameters:
       RhsmVars:
         rhsm_repos:
           - rhel-8-for-x86_64-baseos-rpms
           - rhel-8-for-x86_64-appstream-rpms
           - rhel-8-for-x86_64-highavailability-rpms
           - ansible-2.9-for-rhel-8-x86_64-rpms
           - openstack-16.2-deployment-tools-for-rhel-8-x86_64-rpms
         rhsm_username: "myusername"
         rhsm_password: "p@55w0rd!"
         rhsm_org_id: "1234567"
         rhsm_pool_ids: "68790a7aa2dc9dc50a9bc39fabc55e0d"
         rhsm_method: "portal"
         rhsm_release: 8.4

   resource_registry 는 각 역할에서 사용할 수 있는 OS::TripleO::Services::Rhsm 리소스와 rhsm 구성 가능 서비스를 연결합니다.

   ControllerParameters,ComputeParameters 및 CephStorageParameters 매개 변수는 각각 별도의 RhsmVars 매개변수를 사용하여 서브스크립션 세부 정보를 해당 역할에 전달합니다.

   참고

   CephStorageParameter s 매개변수 내에서 RhsmVar s 매개변수를 설정하여 Red Hat Ceph Storage 서브스크립션 및 Ceph Storage 관련 리포지토리를 사용합니다. rhsm_repos 매개변수에 컨트롤러 및 컴퓨팅 노드에 필요한 EUS(Extended Update Support) 리포지토리 대신 표준 Red Hat Enterprise Linux 리포지토리가 포함되어 있는지 확인합니다.

3. 환경 파일을 저장합니다.

절차

1. templates/rhsm.yml 이라는 환경 파일을 만들어 구성을 저장합니다.

2. 환경 파일에 구성을 포함합니다. 예를 들면 다음과 같습니다.

   resource_registry:
     OS::TripleO::Services::Rhsm: /usr/share/openstack-tripleo-heat-templates/deployment/rhsm/rhsm-baremetal-ansible.yaml
   parameter_defaults:
     RhsmVars:
       rhsm_activation_key: "myactivationkey"
       rhsm_method: "satellite"
       rhsm_org_id: "ACME"
       rhsm_server_hostname: "satellite.example.com"
       rhsm_baseurl: "https://satellite.example.com/pulp/repos"
       rhsm_release: 8.4

   resource_registry 는 각 역할에서 사용할 수 있는 OS::TripleO::Services::Rhsm 리소스와 rhsm 구성 가능 서비스를 연결합니다.

   RhsmVars 변수는 Red Hat 등록을 구성하기 위해 매개 변수를 Ansible에 전달합니다.

3. 환경 파일을 저장합니다.

절차

1. rhel-registration 환경 파일을 향후 배포 작업에서 제외합니다. 대부분의 경우 다음 파일을 제외합니다.

   • rhel-registration/environment-rhel-registration.yaml
   • rhel-registration/rhel-registration-resource-registry.yaml

2. 사용자 지정 roles_data 파일을 사용하는 경우 roles_data 파일의 각 역할에 OS::TripleO::Services::Rhsm 구성 가능 서비스가 포함되어 있는지 확인합니다. 예를 들면 다음과 같습니다.

   - name: Controller
     description: |
       Controller role that has all the controller services loaded and handles
       Database, Messaging and Network functions.
     CountDefault: 1
     ...
     ServicesDefault:
       ...
       - OS::TripleO::Services::Rhsm
       ...

3. 향후 배포 작업에 환경 파일 for rhsm composable 서비스 매개변수를 추가합니다.

절차

1. openstack overcloud deploy 명령을 사용하여 rhsm.yml 환경 파일을 포함합니다.

   openstack overcloud deploy \
       <other cli args> \
       -e ~/templates/rhsm.yaml

   이렇게 하면 오버클라우드의 Ansible 구성 및 Ansible 기반 등록이 활성화됩니다.

2. Overcloud 배포가 완료될 때까지 기다립니다.

3. 오버클라우드 노드에서 서브스크립션 세부 정보를 확인합니다. 예를 들어 컨트롤러 노드에 로그인하고 다음 명령을 실행합니다.

   $ sudo subscription-manager status
   $ sudo subscription-manager list --consumed

절차

1. redhat_subscription 모듈을 사용하여 노드를 등록하는 플레이북을 생성합니다. 예를 들어 다음 플레이북은 컨트롤러 노드에 적용됩니다.

   ---
   - name: Register Controller nodes
     hosts: Controller
     become: yes
     vars:
       repos:
         - rhel-8-for-x86_64-baseos-eus-rpms
         - rhel-8-for-x86_64-appstream-eus-rpms
         - rhel-8-for-x86_64-highavailability-eus-rpms
         - ansible-2.9-for-rhel-8-x86_64-rpms
         - openstack-beta-for-rhel-8-x86_64-rpms
         - fast-datapath-for-rhel-8-x86_64-rpms
     tasks:
       - name: Register system
         redhat_subscription:
           username: myusername
           password: p@55w0rd!
           org_id: 1234567
           release: 8.4
           pool_ids: 1a85f9223e3d5e43013e3d6e8ff506fd
       - name: Disable all repos
         command: "subscription-manager repos --disable *"
       - name: Enable Controller node repos
         command: "subscription-manager repos --enable {{ item }}"
         with_items: "{{ repos }}"

   • 이 플레이에는 세 가지 작업이 포함됩니다.

     • 노드를 등록합니다.
     • 자동 활성화 리포지토리를 비활성화합니다.
     • 컨트롤러 노드와 관련된 리포지토리만 활성화합니다. 리포지토리는 repos 변수를 사용하여 나열됩니다.

2. 오버클라우드를 배포한 후 Ansible이 오버클라우드에 대해 플레이북(ansible-osp-registration.yml)을 실행하도록 다음 명령을 실행할 수 있습니다.

   $ ansible-playbook -i /usr/bin/tripleo-ansible-inventory ansible-osp-registration.yml

   이 명령은 다음 작업을 수행합니다.

   • 동적 인벤토리 스크립트를 실행하여 호스트 및 해당 그룹 목록을 가져옵니다.
   • 플레이북의 hosts 매개 변수에 정의된 그룹의 노드에 플레이북 작업을 적용합니다. 이 경우 Controller 그룹입니다.

절차

1. 기본 역할 템플릿을 나열합니다.

   $ openstack overcloud roles list
   BlockStorage
   CephStorage
   Compute
   ComputeHCI
   ComputeOvsDpdk
   Controller
   ...

2. openstack overcloud roles show 명령을 사용하여 YAML 형식으로 역할 정의를 확인합니다.

   $ openstack overcloud roles show Compute

3. 사용자 지정 roles_data 파일을 생성합니다. openstack overcloud roles generate 명령을 사용하여 사전 정의된 여러 역할을 하나의 파일에 결합합니다. 예를 들어 다음 명령을 실행하여 Controller,Compute 및 Networker 역할이 포함된 roles_data.yaml 파일을 생성합니다.

   $ openstack overcloud roles generate -o ~/roles_data.yaml Controller Compute Networker

   출력 파일에서 이름을 정의하는 데 -o 옵션을 사용합니다.

   이 명령은 사용자 지정 roles_data 파일을 생성합니다. 그러나 이전 예제에서는 모두 동일한 네트워킹 에이전트를 포함하는 Controller 및 Networker 역할을 사용합니다. 즉, 네트워킹 서비스는 컨트롤러 역할에서 Networker 역할로 확장되고, 오버클라우드에서 컨트롤러 노드와 네트워크 노드 간에 네트워킹 서비스의 부하를 분산합니다.

   이 Networker 역할을 독립 실행형으로 만들려면 고유한 사용자 지정 컨트롤러 역할과 필요한 다른 역할을 만들 수 있습니다. 이를 통해 고유한 사용자 지정 역할에서 roles_data 파일을 생성할 수 있습니다.

4. 코어 heat 템플릿 컬렉션의 디렉터리를 stack 사용자의 홈 디렉터리에 복사합니다.

   $ cp -r /usr/share/openstack-tripleo-heat-templates/roles ~/.

5. 이 디렉터리에서 사용자 지정 역할 파일을 추가하거나 수정합니다. 역할 하위 명령과 함께 --roles-path 옵션을 사용하여 이 디렉터리를 사용자 지정 역할의 소스로 사용합니다.

   $ openstack overcloud roles generate -o my_roles_data.yaml \
     --roles-path ~/roles \
     Controller Compute Networker

   이 명령은 ~/ roles 디렉터리의 개별 역할에서 하나의 my_roles _data.yaml 파일을 생성합니다.

절차

1. 기본 역할 디렉터리의 사용자 지정 사본을 생성합니다.

   $ cp -r /usr/share/openstack-tripleo-heat-templates/roles ~/.

2. ~/roles/Horizon.yaml 이라는 새 파일을 생성하고 기본 및 핵심 OpenStack 대시보드 서비스가 포함된 새 Horizon 역할을 생성합니다.

   - name: Horizon
     CountDefault: 1
     HostnameFormatDefault: '%stackname%-horizon-%index%'
     ServicesDefault:
       - OS::TripleO::Services::CACerts
       - OS::TripleO::Services::Kernel
       - OS::TripleO::Services::Ntp
       - OS::TripleO::Services::Snmp
       - OS::TripleO::Services::Sshd
       - OS::TripleO::Services::Timezone
       - OS::TripleO::Services::TripleoPackages
       - OS::TripleO::Services::TripleoFirewall
       - OS::TripleO::Services::SensuClient
       - OS::TripleO::Services::FluentdClient
       - OS::TripleO::Services::AuditD
       - OS::TripleO::Services::Collectd
       - OS::TripleO::Services::MySQLClient
       - OS::TripleO::Services::Apache
       - OS::TripleO::Services::Horizon

   • name 매개변수를 사용자 정의 역할의 이름으로 설정합니다. 사용자 지정 역할 이름의 길이는 최대 2048자입니다.
   • 기본 오버클라우드에 항상 Horizon 노드가 포함되도록 CountDefault 매개변수를 1 로 설정합니다.

3. 선택 사항: 기존 오버클라우드에서 서비스를 확장하려면 Controller 역할의 기존 서비스를 유지합니다. 새 오버클라우드를 생성하고 OpenStack 대시보드를 독립 실행형 역할에 유지하려면 컨트롤러 역할 정의에서 OpenStack 대시보드 구성 요소를 제거합니다.

   - name: Controller
     CountDefault: 1
     ServicesDefault:
       ...
       - OS::TripleO::Services::GnocchiMetricd
       - OS::TripleO::Services::GnocchiStatsd
       - OS::TripleO::Services::HAproxy
       - OS::TripleO::Services::HeatApi
       - OS::TripleO::Services::HeatApiCfn
       - OS::TripleO::Services::HeatApiCloudwatch
       - OS::TripleO::Services::HeatEngine
       # - OS::TripleO::Services::Horizon                # Remove this service
       - OS::TripleO::Services::IronicApi
       - OS::TripleO::Services::IronicConductor
       - OS::TripleO::Services::Iscsid
       - OS::TripleO::Services::Keepalived
       ...

4. ~/roles 디렉터리를 소스로 사용하여 새 roles_data-horizon.yaml 파일을 생성합니다.

   $ openstack overcloud roles generate -o roles_data-horizon.yaml \
     --roles-path ~/roles \
     Controller Compute Horizon

5. 특정 노드에 태그를 지정할 수 있도록 이 역할에 대한 새 플레이버를 정의합니다. 이 예에서는 다음 명령을 사용하여 Horizon 플레이버를 생성합니다.

   1. Horizon 플레이버를 생성합니다.

      (undercloud)$ openstack flavor create --id auto --ram 6144 --disk 40 --vcpus 4 horizon

      참고

      이러한 속성은 인스턴스를 예약하는 데 사용되지 않지만 Compute 스케줄러는 디스크 크기를 사용하여 루트 파티션 크기를 결정합니다.

   2. 대시보드 서비스(horizon)를 사용자 정의 리소스 클래스로 지정할 각 베어 메탈 노드에 태그를 지정합니다.

      (undercloud)$ openstack baremetal node set --resource-class baremetal.HORIZON <NODE>

      <NODE> 를 베어 메탈 노드의 ID로 바꿉니다.

   3. Horizon 플레이버를 사용자 지정 리소스 클래스와 연결합니다.

      (undercloud)$ openstack flavor set --property resources:CUSTOM_BAREMETAL_HORIZON=1 horizon

      베어 메탈 노드의 리소스 클래스에 해당하는 사용자 정의 리소스 클래스의 이름을 확인하려면 리소스 클래스를 대문자로 변환하고 문장 부호를 밑줄로 바꾸고, 값 앞에 CUSTOM_ 을 추가합니다.

      참고

      플레이버는 베어 메탈 리소스 클래스의 인스턴스 하나만 요청할 수 있습니다.

   4. Compute 스케줄러가 인스턴스 예약에 베어 메탈 플레이버 속성을 사용하지 않도록 다음 플레이버 속성을 설정합니다.

      (undercloud)$ openstack flavor set --property resources:VCPU=0 --property resources:MEMORY_MB=0 --property resources:DISK_GB=0 horizon

6. 다음 환경 파일 스니펫을 사용하여 Horizon 노드 수 및 플레이버를 정의합니다.

   parameter_defaults:
     OvercloudHorizonFlavor: horizon
     HorizonCount: 1

7. 배포와 관련된 기타 모든 환경 파일과 함께 openstack overcloud deploy 명령에 새 roles_data-horizon.yaml 파일 및 환경 파일을 포함합니다.

   $ openstack overcloud deploy --templates -r ~/templates/roles_data-horizon.yaml -e ~/templates/node-count-flavor.yaml

   이 구성에서는 컨트롤러 노드 1개, 컴퓨팅 노드 1개, Networker 노드 1개로 구성된 3노드 오버클라우드가 생성됩니다. 오버클라우드의 노드 목록을 보려면 다음 명령을 실행합니다.

   $ openstack server list

절차

1. 기본 역할 디렉터리의 사용자 지정 사본을 생성합니다.

   $ cp -r /usr/share/openstack-tripleo-heat-templates/roles ~/.

2. ~/roles/Controller.yaml 파일을 편집하고 ServicesDefault 매개변수의 서비스 목록을 수정합니다. OpenStack Orchestration 서비스로 스크롤하여 제거합니다.

       - OS::TripleO::Services::GlanceApi
       - OS::TripleO::Services::GlanceRegistry
       - OS::TripleO::Services::HeatApi            # Remove this service
       - OS::TripleO::Services::HeatApiCfn         # Remove this service
       - OS::TripleO::Services::HeatApiCloudwatch  # Remove this service
       - OS::TripleO::Services::HeatEngine         # Remove this service
       - OS::TripleO::Services::MySQL
       - OS::TripleO::Services::NeutronDhcpAgent

3. 새 roles_data 파일을 생성합니다.

   $ openstack overcloud roles generate -o roles_data-no_heat.yaml \
     --roles-path ~/roles \
     Controller Compute Networker

4. openstack overcloud deploy 명령을 실행할 때 이 새 roles_data 파일을 포함합니다.

   $ openstack overcloud deploy --templates -r ~/templates/roles_data-no_heat.yaml

   이 명령은 컨트롤러 노드에 OpenStack Orchestration 서비스를 설치하지 않고 오버클라우드를 배포합니다.

절차

1. CinderBackup 서비스를 cinder-backup 구성이 포함된 heat 템플릿에 연결하는 환경 파일에 항목을 추가합니다.

   resource_registry:
     OS::TripleO::Services::CinderBackup: ../podman/services/pacemaker/cinder-backup.yaml
   ...

   이 항목은 기본 null 작업 리소스를 재정의하고 서비스를 활성화합니다.

2. openstack overcloud deploy 명령을 실행할 때 이 환경 파일을 추가합니다.

   $ openstack overcloud deploy --templates -e /usr/share/openstack-tripleo-heat-templates/environments/cinder-backup.yaml

절차

1. ServicesDefault 목록이 포함되지 않은 사용자 정의 roles_data.yaml 파일에 일반 역할을 생성합니다.

   - name: Generic
   - name: Controller
     CountDefault: 1
     ServicesDefault:
       - OS::TripleO::Services::AuditD
       - OS::TripleO::Services::CACerts
       - OS::TripleO::Services::CephClient
       ...
   - name: Compute
     CountDefault: 1
     ServicesDefault:
       - OS::TripleO::Services::AuditD
       - OS::TripleO::Services::CACerts
       - OS::TripleO::Services::CephClient
       ...

   기존 Controller 및 Compute 역할을 유지해야 합니다.

2. 환경 파일 generic-node-params.yaml 을 생성하여 필요한 일반 Red Hat Enterprise Linux 8 노드 수와 프로비저닝할 노드를 선택할 때 플레이버를 지정합니다.

   parameter_defaults:
     OvercloudGenericFlavor: baremetal
     GenericCount: 1

3. openstack overcloud deploy 명령을 실행할 때 역할 파일과 환경 파일을 모두 포함합니다.

   $ openstack overcloud deploy --templates \
   -r ~/templates/roles_data_with_generic.yaml \
   -e ~/templates/generic-node-params.yaml

   이 구성은 컨트롤러 노드 1개, 컴퓨팅 노드 1개, 일반 Red Hat Enterprise Linux 8 노드 1개가 있는 3-노드 환경을 배포합니다.

절차

1. stack 사용자로 언더클라우드 호스트에 로그인합니다.

2. 기본 컨테이너 이미지 준비 파일을 생성합니다.

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

   이 명령은 다음과 같은 추가 옵션을 사용합니다.

   • --local-push-destination은 언더클라우드의 레지스트리를 컨테이너 이미지의 위치로 설정합니다. 즉 director가 Red Hat Container Catalog에서 필요한 이미지를 가져와서 언더클라우드의 레지스트리로 푸시합니다. director는 이 레지스트리를 컨테이너 이미지 소스로 사용합니다. Red Hat Container Catalog에서 직접 가져오려면 이 옵션을 생략합니다.

   • --output-env-file은 환경 파일 이름입니다. 이 파일 내용에는 컨테이너 이미지를 준비하는 데 필요한 매개변수가 포함되어 있습니다. 이 경우 파일 이름은 containers-prepare-parameter.yaml입니다.

     참고

     동일한 containers-prepare-parameter.yaml 파일을 사용하여 언더클라우드와 오버클라우드의 컨테이너 이미지 소스를 모두 정의할 수 있습니다.

3. containers-prepare-parameter.yaml을 요구 사항에 맞게 수정합니다.

절차

1. 다음 예제에서는 nova-compute 이미지에 대해 사용자 지정 Dockerfile을 실행합니다.

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

2. /home/stack/nova-custom/Dockerfile 파일의 예는 다음과 같습니다. USER root 지시문을 실행한 후에는 원본 이미지의 기본 사용자로 다시 전환해야 합니다.

   FROM registry.redhat.io/rhosp-rhel8/openstack-nova-compute:latest
   
   USER "root"
   
   COPY customize.sh /tmp/
   RUN /tmp/customize.sh
   
   USER "nova"

절차

1. 오버클라우드의 새 컨테이너 이미지 파일을 생성합니다.

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

2. containers-prepare-parameter-dellemc.yaml 파일을 편집합니다.

3. 기본 Red Hat OpenStack Platform 컨테이너 이미지의 전략에 exclude 매개변수를 추가합니다. 벤더 컨테이너 이미지가 교체할 컨테이너 이미지를 제외하려면 이 매개변수를 사용합니다. 이 예에서 컨테이너 이미지는 cinder-volume 이미지입니다.

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

4. 공급자 플러그인의 대체 컨테이너 이미지가 포함된 ContainerImagePrepare 매개변수에 새 전략을 추가합니다.

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

5. registry.connect.redhat.com 레지스트리의 인증 세부 정보를 ContainerImageRegistryCredentials 매개변수에 추가합니다.

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

6. containers-prepare-parameter-dellemc.yaml 파일을 저장합니다.

7. openstack overcloud deploy 와 같은 모든 배포 명령을 사용하여 containers-prepare-parameter-dellemc.yaml 파일을 포함합니다.

   $ openstack overcloud deploy --templates
       ...
       -e containers-prepare-parameter-dellemc.yaml
       ...

   director가 오버클라우드를 배포할 때 오버클라우드는 표준 컨테이너 이미지 대신 벤더 컨테이너 이미지를 사용합니다.

   중요

   containers-prepare-parameter-dellemc.yaml 파일은 오버클라우드 배포의 표준 containers-prepare-parameter.yaml 파일을 대체합니다. 오버클라우드 배포에 표준 containers-prepare-parameter.yaml 파일을 포함하지 마십시오. 언더클라우드 설치 및 업데이트에 대한 표준 containers-prepare-parameter.yaml 파일을 유지합니다.

절차

1. 기본 network_data.yaml 파일을 복사합니다.

   $ cp /usr/share/openstack-tripleo-heat-templates/network_data.yaml /home/stack/.

2. network_data.yaml 파일의 로컬 사본을 편집하고 네트워킹 요구 사항에 맞게 매개변수를 수정합니다. 예를 들어 내부 API 네트워크에는 다음과 같은 기본 네트워크 세부 정보가 포함되어 있습니다.

   - name: InternalApi
     name_lower: internal_api
     vip: true
     vlan: 201
     ip_subnet: '172.16.2.0/24'
     allocation_pools: [{'start': '172.16.2.4', 'end': '172.16.2.250'}]

절차

1. openstack overcloud deploy 명령을 실행할 때 다음과 같은 렌더링된 환경 파일을 포함해야 합니다.

   • 사용자 지정 network_data.yaml 파일입니다.
   • 렌더링된 기본 네트워크 격리 파일의 이름입니다.
   • 렌더링된 기본 네트워크 환경 파일의 파일 이름입니다.
   • 렌더링된 기본 네트워크 인터페이스 구성 파일의 파일 이름입니다.
   • 구성과 관련된 추가 환경 파일입니다.

절차

1. 기본 network_data.yaml 파일을 복사합니다.

   $ cp /usr/share/openstack-tripleo-heat-templates/network_data.yaml /home/stack/.

2. network_data.yaml 파일의 로컬 사본을 편집하고 새 네트워크의 섹션을 추가합니다.

   - name: StorageBackup
     name_lower: storage_backup
     vlan: 21
     vip: true
     ip_subnet: '172.21.1.0/24'
     allocation_pools: [{'start': '171.21.1.4', 'end': '172.21.1.250'}]
     gateway_ip: '172.21.1.1'

절차

1. 사용자 지정 roles_data.yaml 파일이 없는 경우 기본값을 홈 디렉터리에 복사합니다.

   $ cp /usr/share/openstack-tripleo-heat-templates/roles_data.yaml /home/stack/.

2. 사용자 지정 roles_data.yaml 파일을 편집합니다.

3. 네트워크를 추가할 역할에 대한 네트워크 목록에 네트워크 이름을 포함합니다. 예를 들어 StorageBackup 네트워크를 Ceph Storage 역할에 추가하려면 다음 예제 스니펫을 사용합니다.

   - name: CephStorage
     description: |
       Ceph OSD Storage node role
     networks:
       - Storage
       - StorageMgmt
       - StorageBackup

4. 사용자 지정 네트워크를 해당 역할에 추가한 후 파일을 저장합니다.

절차

1. openstack overcloud deploy 명령을 실행할 때 다음 파일을 포함해야 합니다.

   • 사용자 지정 network_data.yaml 파일입니다.
   • 네트워크-역할 할당이 있는 사용자 지정 roles_data.yaml 파일
   • 기본 네트워크 격리의 렌더링된 파일 이름입니다.
   • 렌더링된 기본 네트워크 환경 파일의 파일 이름입니다.
   • 렌더링된 기본 네트워크 인터페이스 구성의 파일 이름입니다.
   • 서비스 재할당과 같은 네트워크 관련 추가 환경 파일.

절차

1. network_data.yaml 파일에서 이름을 변경할 각 네트워크의 name_lower 매개변수에 새 이름을 입력합니다.

   - name: InternalApi
     name_lower: MyCustomInternalApi

2. service_net_map _replace 매개변수에 name_ lower 매개변수의 기본값을 포함합니다.

   - name: InternalApi
     name_lower: MyCustomInternalApi
     service_net_map_replace: internal_api

절차

1. process-templates.py 스크립트를 사용하여 openstack-tripleo-heat-templates 컬렉션 사본을 렌더링합니다.

   $ cd /usr/share/openstack-tripleo-heat-templates
   $ ./tools/process-templates.py -o ~/openstack-tripleo-heat-templates-rendered

   이렇게 하면 모든 Jinja2 템플릿을 렌더링된 YAML 버전으로 변환하고 결과를 ~/openstack-tripleo-heat-templates-rendered에 저장합니다.

   사용자 지정 네트워크 파일 또는 사용자 지정 역할 파일을 사용하는 경우 각각 -n 및 - r 옵션을 사용하여 이러한 파일을 포함할 수 있습니다.

   $ ./tools/process-templates.py -o ~/openstack-tripleo-heat-templates-rendered -n /home/stack/network_data.yaml -r /home/stack/roles_data.yaml

2. 여러 NIC 예제를 복사합니다.

   $ cp -r ~/openstack-tripleo-heat-templates-rendered/network/config/multiple-nics/ ~/templates/custom-nics/

3. 사용자 지정 NIC의 템플릿을 편집하여 고유한 네트워크 구성에 맞게 템플릿 설정을 편집합니다.

절차

1. openstack overcloud deploy 명령을 실행하면 다음 파일을 포함합니다.

   • 사용자 지정 network_data.yaml 파일입니다.
   • 기본 네트워크 격리의 렌더링된 파일 이름입니다.
   • 렌더링된 기본 네트워크 환경 파일의 파일 이름입니다.
   • 사용자 지정 NIC 템플릿에 대한 리소스 참조가 포함된 사용자 지정 환경 네트워크 구성입니다.
   • 구성과 관련된 추가 환경 파일입니다.

절차

1. ~/templates/custom-nics 디렉터리에서 사용자 지정 NIC 템플릿에 route_table 및 인터페이스 항목을 생성하고, 인터페이스의 경로를 정의하며, 배포와 관련된 규칙을 정의합니다.

   $network_config:
     network_config:
   
     - type: route_table
       name: custom
       table_id: 200
   
     - type: interface
       name: em1
       use_dhcp: false
       addresses:
         - ip_netmask: 192.0.2.1/24
   
       routes:
         - ip_netmask: 10.1.3.0/24
           next_hop: 192.0.2.5
           route_options: "metric 10"
           table: 200
       rules:
         - rule: "iif em1 table 200"
           comment: "Route incoming traffic to em1 with table 200"
         - rule: "from 192.0.2.0/24 table 200"
           comment: "Route all traffic from 192.0.2.0/24 with table 200"
         - rule: "add blackhole from 172.19.40.0/24 table 200"
         - rule: "add unreachable iif em1 from 192.168.1.0/24"

2. run-os-net-config.sh 스크립트 위치를 사용자가 생성한 각 사용자 지정 NIC 템플릿의 절대 경로로 설정합니다. 스크립트는 언더클라우드의 /usr/share/openstack-tripleo-heat-templates/network/scripts/ 디렉터리에 있습니다.

   resources:
     OsNetConfigImpl:
       type: OS::Heat::SoftwareConfig
       properties:
         group: script
         config:
           str_replace:
             template:
               get_file: /usr/share/openstack-tripleo-heat-templates/network/scripts/run-os-net-config.sh

3. 배포와 관련된 기타 환경 파일과 함께 배포 명령에 사용자 정의 NIC 구성 및 네트워크 환경 파일을 추가합니다.

   $ openstack overcloud deploy --templates \
   -e ~/templates/<custom-nic-template>
   -e <OTHER_ENVIRONMENT_FILES>

절차

1. 커널 버전을 확인합니다.

   ovs-appctl -t ovs-vswitchd dpif/show-dp-features br-int

2. 출력에 pkt 길이 작업 확인: no 또는 출력에 Check pkt length action 문자열이 없거나 RHEL 8.2.0.4 이상으로 업그레이드하거나 점보 프레임이 더 작은 외부 네트워크로 전송하지 마십시오.

3. 출력에 pkt 길이 작업 확인: 예, ml2_conf.ini의 [ovn] 섹션에서 다음 값을 설정합니다.

   ovn_emit_need_to_frag = True

절차

1. 언더클라우드 호스트에 stack 사용자로 로그인합니다.

2. 언더클라우드 인증 정보 파일을 소싱합니다.

   $ source ~/stackrc

3. 사용자 지정 YAML 환경 파일을 생성합니다.

   예제

   $ vi /home/stack/templates/my-environment.yaml

4. 환경 파일에는 키워드 parameter_defaults 및 ExtraSysctl 509 가 포함되어야 합니다. netfilter가 변수 net.nf_conntrack_max 에서 추적할 수 있는 최대 연결 수의 새 값을 입력합니다.

   예제

   이 예제에서는 RHOSP 배포의 모든 호스트에 conntrack 제한을 설정할 수 있습니다.

   parameter_defaults:
     ExtraSysctlSettings:
       net.nf_conntrack_max:
         value: 500000

   <role>Parameter 매개변수를 사용하여 특정 역할에 대한 conntrack 제한을 설정합니다.

   parameter_defaults:
     <role>Parameters:
       ExtraSysctlSettings:
         net.nf_conntrack_max:
           value: <simultaneous_connections>

   • <role> 을 역할 이름으로 바꿉니다.

     예를 들어 컨트롤러 매개 변수를 사용하여 컨트롤러 역할에 대한 conntrack 제한을 설정하거나 ComputeParameters 를 사용하여 Compute 역할의 conntrack 제한을 설정합니다.

   • <simultaneous_connections> 를 허용하려는 동시 연결 수로 바꿉니다.

     예제

     이 예제에서는 RHOSP 배포의 Controller 역할에 대해서만 conntrack 제한을 설정할 수 있습니다.

     parameter_defaults:
       ControllerParameters:
         ExtraSysctlSettings:
           net.nf_conntrack_max:
             value: 500000

     참고

     net.nf_conntrack_max 의 기본값은 500000 연결입니다. 최대값은 다음과 같습니다. 4294967295.

5. 배포 명령을 실행하고 핵심 heat 템플릿, 환경 파일 및 이 새 사용자 지정 환경 파일을 포함합니다.

   중요

   후속 환경 파일에 정의된 매개변수 및 리소스가 우선하므로 환경 파일의 순서가 중요합니다.

   예제

   $ openstack overcloud deploy --templates \
   -e /home/stack/templates/my-environment.yaml

절차

1. 컴퓨팅 스케줄러가 배포 시 일치하는 노드별 기능으로 ID를 할당합니다.

   openstack baremetal node set --property capabilities='node:controller-0,boot_option:local' <id>

   이 명령은 기능 node:controller-0 을 노드에 할당합니다. 모든 노드에 대해 0부터 시작하여 고유한 연속 인덱스를 사용하여 이 패턴을 반복합니다. 지정된 역할(Controller, Compute 또는 각 스토리지 역할)의 모든 노드에 동일한 방식으로 태그가 지정되어 있는지 또는 Compute 스케줄러가 기능과 올바르게 일치할 수 없는지 확인합니다.

2. 스케줄러 힌트를 사용하여 각 노드의 기능과 일치시키는 Heat 환경 파일(예: scheduler_hints_env.yaml)을 생성합니다.

   parameter_defaults:
     ControllerSchedulerHints:
       'capabilities:node': 'controller-%index%'

   다음 매개변수를 사용하여 다른 역할 유형에 대한 스케줄러 힌트를 구성합니다.

   • 컨트롤러 노드의 ControllerSchedulerHints 입니다.
   • 컴퓨팅 노드의 ComputeSchedulerHints 입니다.
   • 블록 스토리지 노드의 BlockStorageSchedulerHints 입니다.
   • 오브젝트 스토리지 노드의 ObjectStorageSchedulerHints 입니다.
   • Ceph Storage 노드의 CephStorageSchedulerHints.
   • [ROLE] 사용자 정의 역할을 위한 스케줄 힌트입니다. [ROLE] 을 역할 이름으로 바꿉니다.
3. Overcloud 배포 명령에 scheduler_hints_env.yaml 환경 파일을 포함합니다.

절차

1. 환경 파일을 생성하여 예측 가능한 IP 주소를 정의합니다.

   $ touch ~/templates/predictive_ips.yaml

2. ~/templates/predictive _ips.yaml 파일에서 parameter_ defaults 섹션을 생성하고 다음 구문을 사용하여 각 네트워크의 각 노드에 대한 예측 가능한 IP 주소 지정을 정의합니다.

   parameter_defaults:
     <role_name>IPs:
       <network>:
       - <IP_address>
       <network>:
       - <IP_address>

   각 노드 역할에는 고유한 매개 변수가 있습니다. <role_name>IP를 관련 매개변수로 바꿉니다.

   • 컨트롤러 노드의 ControllerIP.
   • 컴퓨팅 노드 의 ComputeIP.
   • Ceph Storage 노드의 CephStorageIP.
   • 블록 스토리지 노드 의 BlockStorageIP.
   • 오브젝트 스토리지 노드의 SwiftStorageIPs.

   • [ROLE]사용자 정의 역할을 위한 IP입니다. [ROLE] 을 역할 이름으로 바꿉니다.

     각 매개 변수는 네트워크 이름에서 주소 목록에 대한 맵입니다. 각 네트워크 유형에는 해당 네트워크에 노드가 있을 만큼의 주소가 있어야 합니다. director에서 주소를 순서대로 할당합니다. 각 유형의 첫 번째 노드는 각 목록에서 첫 번째 주소를 수신하고 두 번째 노드는 각 목록에서 두 번째 주소를 수신합니다.

     예를 들어 예측 가능한 IP 주소가 있는 오버클라우드에 세 개의 Ceph Storage 노드를 배포하려면 다음 예제 구문을 사용합니다.

     parameter_defaults:
       CephStorageIPs:
         storage:
         - 172.16.1.100
         - 172.16.1.101
         - 172.16.1.102
         storage_mgmt:
         - 172.16.3.100
         - 172.16.3.101
         - 172.16.3.102

     첫 번째 Ceph Storage 노드는 두 개의 주소를 수신합니다. 172.16.1.100 및 172.16.3.100. 두 번째는 172.16.1.101 및 172.16.3.101을 수신하고 세 번째는 172.16.1.102 및 172.16.3.102를 수신합니다. 동일한 패턴은 다른 노드 유형에 적용됩니다.

     컨트롤 플레인에서 예측 가능한 IP 주소를 구성하려면 /usr/share/openstack-tripleo-heat-templates/environments/ips-from-pool-ctlplane.yaml 파일을 stack 사용자의 templates 디렉터리에 복사합니다.

     $ cp /usr/share/openstack-tripleo-heat-templates/environments/ips-from-pool-ctlplane.yaml ~/templates/.

     다음 매개 변수 예제를 사용하여 새 ips-from-pool-ctlplane.yaml 파일을 구성합니다. 컨트롤 플레인 IP 주소 선언을 다른 네트워크에 대한 IP 주소 선언과 결합하고 한 파일만 사용하여 모든 역할에 있는 모든 네트워크에 대한 IP 주소를 선언할 수 있습니다. 스파인/리프형에 대해 예측 가능한 IP 주소를 사용할 수도 있습니다. 각 노드에는 올바른 서브넷의 IP 주소가 있어야 합니다.

     parameter_defaults:
       ControllerIPs:
         ctlplane:
         - 192.168.24.10
         - 192.168.24.11
         - 192.168.24.12
         internal_api:
         - 172.16.1.20
         - 172.16.1.21
         - 172.16.1.22
         external:
         - 10.0.0.40
         - 10.0.0.57
         - 10.0.0.104
       ComputeLeaf1IPs:
         ctlplane:
         - 192.168.25.100
         - 192.168.25.101
         internal_api:
         - 172.16.2.100
         - 172.16.2.101
       ComputeLeaf2IPs:
         ctlplane:
         - 192.168.26.100
         - 192.168.26.101
         internal_api:
         - 172.16.3.100
         - 172.16.3.101

     선택한 IP 주소가 네트워크 환경 파일에 정의된 각 네트워크에 대해 할당 풀 외부에 속하는지 확인합니다. 예를 들어 internal_api 할당이 자동으로 선택된 IP와 충돌하지 않도록 InternalApiAllocationPools 범위를 벗어나는지 확인합니다. 또한 IP 할당이 VIP 구성과 충돌하지 않는지 확인합니다(예: 13.4절. “예측 가능한 가상 IP 할당”참조) 또는 외부 로드 밸런싱( 21.4절. “외부 로드 밸런싱 구성”참조).

     중요

     Overcloud 노드가 삭제되면 IP 목록의 항목을 제거하지 마십시오. IP 목록은 노드를 삭제해도 변경되지 않는 기본 heat 인덱스를 기반으로 합니다. 목록에 지정된 항목이 더 이상 사용되지 않음을 나타내려면 IP 값을 DELETED 또는 UNUSED 와 같은 값으로 바꿉니다. 항목은 변경 또는 추가만 IP 목록에서 제거해서는 안 됩니다.

3. 배포 중에 이 구성을 적용하려면 openstack overcloud deploy 명령을 사용하여 predictive _ips.yaml 환경 파일을 포함합니다.

   중요

   네트워크 분리를 사용하는 경우 network-isolation .yaml 파일 뒤에 predictive_ips.yaml 파일을 포함합니다.

   $ openstack overcloud deploy --templates \
     -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
     -e ~/templates/predictive_ips.yaml \
     [OTHER OPTIONS]

절차

1. /etc/pki/CA/index.txt 파일에는 서명된 모든 인증서의 기록이 포함되어 있습니다. 파일 시스템 경로와 index.txt 파일이 있는지 확인합니다.

   $ sudo mkdir -p /etc/pki/CA
   $ sudo touch /etc/pki/CA/index.txt

2. /etc/pki/CA/serial 파일은 서명할 다음 인증서에 사용할 다음 일련번호를 식별합니다. 이 파일이 있는지 확인합니다. 파일이 없는 경우 새 시작 값으로 새 파일을 생성합니다.

   $ echo '1000' | sudo tee /etc/pki/CA/serial

절차

1. 인증 기관 역할을 하는 키와 인증서 쌍을 생성합니다.

   $ openssl genrsa -out ca.key.pem 4096
   $ openssl req  -key ca.key.pem -new -x509 -days 7300 -extensions v3_ca -out ca.crt.pem

2. openssl req 명령은 기관에 대한 특정 세부 정보를 요청합니다. 메시지가 나타나면 해당 세부 정보를 입력합니다. 이 명령을 수행하면 ca.crt.pem이라는 인증 기관 파일이 생성됩니다.

3. enable-tls.yaml 파일에서 인증서 위치를 PublicTLSCAFile 매개변수 값으로 설정합니다. 인증서 위치를 PublicTLSCAFile 매개변수 값으로 설정하면 CA 인증서 경로가 clouds.yaml 인증 파일에 추가됩니다.

   parameter_defaults:
       PublicTLSCAFile: /etc/pki/ca-trust/source/anchors/cacert.pem

절차

1. 클라이언트 시스템에 인증 기관을 복사합니다.

   $ sudo cp ca.crt.pem /etc/pki/ca-trust/source/anchors/

2. 각 클라이언트에 인증 기관 파일을 복사한 후 각 클라이언트에서 다음 명령을 실행하여 인증 기관 신뢰 번들에 인증서를 추가합니다.

   $ sudo update-ca-trust extract

절차

1. 다음 명령을 실행하여 SSL/TLS 키(server.key.pem)를 생성합니다.

   $ openssl genrsa -out server.key.pem 2048

절차

1. 기본 OpenSSL 설정 파일을 복사합니다.

   $ cp /etc/pki/tls/openssl.cnf .

2. 새 openssl.cnf 파일을 편집하고 director에 사용할 SSL 매개변수를 설정합니다. 수정할 매개변수 유형의 예제는 다음과 같습니다.

   [req]
   distinguished_name = req_distinguished_name
   req_extensions = v3_req
   
   [req_distinguished_name]
   countryName = Country Name (2 letter code)
   countryName_default = AU
   stateOrProvinceName = State or Province Name (full name)
   stateOrProvinceName_default = Queensland
   localityName = Locality Name (eg, city)
   localityName_default = Brisbane
   organizationalUnitName = Organizational Unit Name (eg, section)
   organizationalUnitName_default = Red Hat
   commonName = Common Name
   commonName_default = 192.168.0.1
   commonName_max = 64
   
   [ v3_req ]
   # Extensions to add to a certificate request
   basicConstraints = CA:FALSE
   keyUsage = nonRepudiation, digitalSignature, keyEncipherment
   subjectAltName = @alt_names
   
   [alt_names]
   IP.1 = 192.168.0.1
   DNS.1 = instack.localdomain
   DNS.2 = vip.localdomain
   DNS.3 = 192.168.0.1

   commonName_default를 다음 항목 중 하나로 설정합니다.

   • IP 주소를 사용하여 SSL/TLS를 통해 director에 액세스하는 경우 undercloud.conf 파일의 undercloud_public_host 매개변수를 사용합니다.
   • 정규화된 도메인 이름을 사용하여 SSL/TLS을 통해 director에 액세스하는 경우 도메인 이름을 사용합니다.

   alt_names 섹션을 편집하여 다음 항목을 포함합니다.

   • IP - 클라이언트가 SSL을 통해 director에 액세스하는 데 사용하는 IP 주소 목록입니다.
   • DNS - 클라이언트가 SSL을 통해 director에 액세스하는 데 사용하는 도메인 이름 목록입니다. 또한 공용 API IP 주소를 alt_names 섹션 끝에 DNS 항목으로 추가합니다.
   참고

   openssl.cnf에 대한 자세한 내용을 보려면 man openssl.cnf 명령을 실행합니다.

3. 다음 명령을 실행하여 인증서 서명 요청(server.csr.pem)을 생성합니다.

   $ openssl req -config openssl.cnf -key server.key.pem -new -out server.csr.pem

   -key 옵션을 사용하여 OpenStack SSL/TLS 키를 지정합니다.

절차

1. 아직 없는 경우 새certs 디렉터리를 만듭니다.

   sudo mkdir -p /etc/pki/CA/newcerts

2. 다음 명령을 실행하여 언더클라우드 또는 오버클라우드에 대한 인증서를 생성합니다.

   $ sudo openssl ca -config openssl.cnf -extensions v3_req -days 3650 -in server.csr.pem -out server.crt.pem -cert ca.crt.pem -keyfile ca.key.pem

   이 명령은 다음 옵션을 사용합니다.

   -config

   사용자 지정 구성 파일, 즉 v3 확장이 포함된 openssl.cnf 파일을 사용합니다.

   -extensions v3_req

   v3 확장을 활성화합니다.

   -days

   인증서가 만료될 때까지 남은 기간(일)을 정의합니다.

   -in'

   인증서 서명 요청입니다.

   -out

   생성된 서명된 인증서입니다.

   -cert

   인증 기관 파일입니다.

   -keyfile

   인증 기관 개인 키입니다.

절차

1. heat 템플릿 컬렉션에서 enable-tls.yaml 환경 파일을 복사합니다.

   $ cp -r /usr/share/openstack-tripleo-heat-templates/environments/ssl/enable-tls.yaml ~/templates/.

2. 이 파일을 편집하여 해당 매개변수에 대해 다음과 같이 변경합니다.

   SSLCertificate

   인증서 파일(server.crt.pem)의 내용을 SSLCertificate 매개변수에 복사합니다.

   parameter_defaults:
     SSLCertificate: |
       -----BEGIN CERTIFICATE-----
       MIIDgzCCAmugAwIBAgIJAKk46qw6ncJaMA0GCSqGS
       ...
       sFW3S2roS4X0Af/kSSD8mlBBTFTCMBAj6rtLBKLaQ
       -----END CERTIFICATE-----

   중요

   인증서 콘텐츠에는 모든 새 행에 대해 동일한 들여쓰기 수준이 필요합니다.

   SSLIntermediateCertificate

   중간 인증서가 있는 경우 중간 인증서의 내용을 SSLIntermediateCertificate 매개변수로 복사합니다.

   parameter_defaults:
     SSLIntermediateCertificate: |
       -----BEGIN CERTIFICATE-----
       sFW3S2roS4X0Af/kSSD8mlBBTFTCMBAj6rtLBKLaQbIxEpIzrgvpBCwUAMFgxCzAJB
       ...
       MIIDgzCCAmugAwIBAgIJAKk46qw6ncJaMA0GCSqGSIb3DQE
       -----END CERTIFICATE-----

   중요

   인증서 콘텐츠에는 모든 새 행에 대해 동일한 들여쓰기 수준이 필요합니다.

   SSLKey

   개인 키(server.key.pem)의 콘텐츠를 SSLKey 매개변수로 복사합니다.

   parameter_defaults:
     ...
     SSLKey: |
       -----BEGIN RSA PRIVATE KEY-----
       MIIEowIBAAKCAQEAqVw8lnQ9RbeI1EdLN5PJP0lVO
       ...
       ctlKn3rAAdyumi4JDjESAXHIKFjJNOLrBmpQyES4X
       -----END RSA PRIVATE KEY-----

   중요

   개인 키 콘텐츠에는 모든 새 행에 대해 동일한 들여쓰기 수준이 필요합니다.

절차

1. heat 템플릿 컬렉션에서 inject-trust-anchor-hiera.yaml 환경 파일을 복사합니다.

   $ cp -r /usr/share/openstack-tripleo-heat-templates/environments/ssl/inject-trust-anchor-hiera.yaml ~/templates/.

절차

1. 다음 콘텐츠를 사용하여 heat 템플릿을 편집합니다.

   • enable-tls.yaml 파일을 편집하고 SSLCertificate, SSL Key 및 SSLIntermediateCertificate 매개변수를 업데이트합니다.
   • 인증 기관이 변경된 경우 inject-trust-anchor-hiera.yaml 파일을 편집하고 CAMap 매개변수를 업데이트합니다.

2. 배포 명령을 다시 실행합니다.

   $ openstack overcloud deploy --templates \
   [...]
   -e /home/stack/templates/enable-tls.yaml \
   -e ~/templates/custom-domain.yaml \
   -e ~/templates/inject-trust-anchor-hiera.yaml \
   -e /usr/share/openstack-tripleo-heat-templates/environments/ssl/tls-endpoints-public-dns.yaml

3. director에서 각 컨트롤러에 대해 다음 명령을 실행합니다.

   ssh heat-admin@<controller> sudo podman \
   restart $(podman ps --format="{{.Names}}" | grep -w -E 'haproxy(-bundle-.*-[0-9]+)?')

1. /etc/resolv.conf 파일을 구성합니다.

   /etc/resolv.conf 의 언더클라우드에 적절한 검색 도메인과 이름 서버를 설정합니다. 예를 들어 배포 도메인이 example.com 이고 FreeIPA 서버의 도메인이 bigcorp.com 인 경우 /etc/resolv.conf에 다음 행을 추가합니다.

   search example.com bigcorp.com
   nameserver $IDM_SERVER_IP_ADDR

2. 필요한 소프트웨어를 설치합니다.

   sudo dnf install -y python3-ipalib python3-ipaclient krb5-devel

3. 환경에 고유한 값을 사용하여 환경 변수를 내보냅니다.

   export IPA_DOMAIN=bigcorp.com
   export IPA_REALM=BIGCORP.COM
   export IPA_ADMIN_USER=$IPA_USER
   export IPA_ADMIN_PASSWORD=$IPA_PASSWORD
   export IPA_SERVER_HOSTNAME=ipa.bigcorp.com
   export UNDERCLOUD_FQDN=undercloud.example.com
   export USER=stack
   export CLOUD_DOMAIN=example.com

   참고

   IdM 사용자 자격 증명은 새 호스트 및 서비스를 추가할 수 있는 관리자여야 합니다.

4. 언더클라우드에서 undercloud-ipa-install.yaml ansible 플레이북을 실행합니다.

   ansible-playbook \
   --ssh-extra-args "-o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null" \
   /usr/share/ansible/tripleo-playbooks/undercloud-ipa-install.yaml

5. undercloud.conf에 다음 매개 변수를 추가합니다.

   undercloud_nameservers = $IDM_SERVER_IP_ADDR
   overcloud_domain_name = example.com

6. 언더클라우드를 배포합니다.

   openstack undercloud install

1. IdM에 호스트를 나열합니다.

   $ kinit admin
   $ ipa host-find

2. 언더클라우드에 /etc/novajoin/krb5.keytab 이 있는지 확인합니다.

   ls /etc/novajoin/krb5.keytab

1. 오버클라우드를 배포하기 전에 다음과 유사한 내용을 사용하여 YAML 파일 tls-parameters.yaml 을 생성합니다. 선택한 값은 환경에 따라 다릅니다.

   parameter_defaults:
       DnsSearchDomains: ["example.com"]
       DnsServers: ["192.168.1.13"]
       CloudDomain: example.com
       CloudName: overcloud.example.com
       CloudNameInternal: overcloud.internalapi.example.com
       CloudNameStorage: overcloud.storage.example.com
       CloudNameStorageManagement: overcloud.storagemgmt.example.com
       CloudNameCtlplane: overcloud.ctlplane.example.com
       IdMServer: freeipa-0.redhat.local
       IdMDomain: redhat.local
       IdMInstallClientPackages: False
   
   resource_registry:
         OS::TripleO::Services::IpaClient: /usr/share/openstack-tripleo-heat-templates/deployment/ipa/ipaservices-baremetal-ansible.yaml

   • DnsServers 매개 변수에는 IdM 서버의 IP 주소를 반영하는 값이 있어야 합니다.
   • IdM 서버의 도메인이 클라우드 도메인과 다른 경우 DnsSearchDomains 매개변수에 포함합니다. 예를 들면 다음과 같습니다. DnsSearchDomains: ["example.com", "bigcorp.com"]
   • 사전 프로비저닝된 노드가 있는 경우 오버클라우드 노드에 필요한 패키지를 설치하려면 IDMInstallClientPackages 매개변수 값을 true 로 설정합니다.
   • 복제된 IdM 환경을 사용할 때 IdmServer 매개변수에 대해 여러 쉼표로 구분된 값을 설정할 수 있습니다. IdM 복제본에 대한 자세한 내용은 IdM 복제본 설치를 참조하십시오.
   • OS::TripleO::Services::IpaClient 매개변수의 표시된 값은 enable-internal-tls.yaml 파일의 기본 설정을 재정의합니다. tls-parameters.yaml 파일이 openstack overcloud deploy 명령에서 enable-internal-tls.yaml 을 따르는지 확인해야 합니다.
   • cinder가 active-active로 구성된 DCN(분산 계산 노드) 아키텍처를 실행하는 경우 EnableEtcdInternalTLS 매개변수를 true 로 추가하고 설정해야 합니다.

2. Overcloud를 배포합니다. 배포 명령에 tls-parameters.yaml을 포함해야 합니다.

   DEFAULT_TEMPLATES=/usr/share/openstack-tripleo-heat-templates/
   CUSTOM_TEMPLATES=/home/stack/templates
   
   openstack overcloud deploy \
   -e ${DEFAULT_TEMPLATES}/environments/ssl/tls-everywhere-endpoints-dns.yaml \
   -e ${DEFAULT_TEMPLATES}/environments/services/haproxy-public-tls-certmonger.yaml \
   -e ${DEFAULT_TEMPLATES}/environments/ssl/enable-internal-tls.yaml \
   -e ${CUSTOM_TEMPLATES}/tls-parameters.yaml \
   ...

3. 끝점 목록에 대한 keystone을 쿼리하여 각 끝점이 HTTPS를 사용하고 있는지 확인합니다.

   openstack endpoint list

1. 언더클라우드 노드를 CA(인증 기관)에 추가
2. IdM에 언더클라우드 노드 추가
3. 선택 사항: IdM 서버를 오버클라우드의 DNS 서버로 설정
4. 환경 파일 준비 및 오버클라우드 배포
5. IdM 및 RHOSP에서 오버클라우드 등록 테스트
6. 선택 사항: IdM에서 novajoin의 DNS 항목 추가

절차

1. 언더클라우드 노드에서 python3-novajoin 패키지를 설치합니다.

   $ sudo dnf install python3-novajoin

2. 언더클라우드 노드에서 novajoin-ipa-setup 스크립트를 실행하고 배포에 맞게 값을 조정합니다.

   $ sudo /usr/libexec/novajoin-ipa-setup \
       --principal admin \
       --password <IdM admin password> \
       --server <IdM server hostname> \
       --realm <realm> \
       --domain <overcloud cloud domain> \
       --hostname <undercloud hostname> \
       --precreate

   결과 OTP(One-Time Password)를 사용하여 Undercloud를 등록합니다.

절차

1. novajoin 서비스를 활성화합니다.

   [DEFAULT]
   enable_novajoin = true

2. IdM을 사용하여 언더클라우드 노드를 등록할 수 있도록 1회성 암호(OTP)를 설정합니다.

   ipa_otp = <otp>

3. 오버클라우드의 도메인 이름을 neutron의 DHCP 서버에서 제공하도록 설정합니다.

   overcloud_domain_name = <domain>

4. 언더클라우드의 호스트 이름을 설정합니다.

   undercloud_hostname = <undercloud FQDN>

5. IdM을 언더클라우드의 이름 서버로 설정합니다.

   undercloud_nameservers = <IdM IP>

6. 더 큰 환경의 경우 novajoin 연결 시간 제한 값을 검토하십시오. undercloud.conf 파일에서 undercloud-timeout.yaml이라는 새 파일에 참조를 추가합니다.

   hieradata_override = /home/stack/undercloud-timeout.yaml

   undercloud-timeout.yaml 에 다음 옵션을 추가합니다. 시간 제한 값을 초 단위로 지정할 수 있습니다(예: 5):

   nova::api::vendordata_dynamic_connect_timeout: <timeout value>
   nova::api::vendordata_dynamic_read_timeout: <timeout value>

7. 선택 사항: 로컬 openSSL 인증 기관에서 director의 공용 끝점에 대한 SSL 인증서를 생성하도록 하려면 generate_service_certificate 매개변수를 true 로 설정합니다.

   generate_service_certificate = true

8. undercloud.conf 파일을 저장합니다.

9. 언더클라우드 배포 명령을 실행하여 기존 언더클라우드에 변경 사항을 적용합니다.

   $ openstack undercloud install

1. IdM에 호스트를 나열합니다.

   $ kinit admin
   $ ipa host-find

2. 언더클라우드에 /etc/novajoin/krb5.keytab 이 있는지 확인합니다.

   ls /etc/novajoin/krb5.keytab

절차

1. 언더클라우드에 연결합니다.

   $ source ~/stackrc

2. IdM을 DNS 이름 서버로 사용하도록 컨트롤 플레인 서브넷을 구성합니다.

   $ openstack subnet set ctlplane-subnet --dns-nameserver  <idm_server_address>

3. IdM 서버를 사용하도록 환경 파일에서 DnsServers 매개변수를 설정합니다.

   parameter_defaults:
     DnsServers: ["<idm_server_address>"]

   일반적으로 이 매개변수는 사용자 지정 network-environment.yaml 파일에 정의됩니다.

절차

1. /usr/share/openstack-tripleo-heat-templates/environments/predictable-placement/custom-domain.yaml 환경 파일의 사본을 생성합니다.

   $ cp /usr/share/openstack-tripleo-heat-templates/environments/predictable-placement/custom-domain.yaml \
     /home/stack/templates/custom-domain.yaml

2. /home/stack/templates/custom-domain.yaml 환경 파일을 편집하고 배포에 맞게 CloudDomain 및 CloudName* 값을 설정합니다.

   parameter_defaults:
     CloudDomain: lab.local
     CloudName: overcloud.lab.local
     CloudNameInternal: overcloud.internalapi.lab.local
     CloudNameStorage: overcloud.storage.lab.local
     CloudNameStorageManagement: overcloud.storagemgmt.lab.local
     CloudNameCtlplane: overcloud.ctlplane.lab.local

3. 사용자 환경에 적합한 TLS 구현을 선택합니다.

   • enable-tls.yaml 환경 파일을 사용하여 사용자 정의 인증서로 외부 끝점을 보호합니다.

     1. /usr/share/openstack-tripleo-heat-templates/environments/ssl/enable-tls.yaml 을 /home/stack/templates 에 복사합니다.
     2. 사용자 정의 인증서 및 키를 포함하도록 /home/stack/enable-tls.yaml 환경 파일을 수정합니다.

     3. 배포에 다음 환경 파일을 포함하여 내부 및 외부 엔드포인트를 보호합니다.

        • enable-internal-tls.yaml
        • tls-every-endpoints-dns.yaml
        • custom-domain.yaml

        • enable-tls.yaml

          openstack overcloud deploy \
            --templates \
            -e /usr/share/openstack-tripleo-heat-templates/environments/ssl/enable-internal-tls.yaml \
            -e /usr/share/openstack-tripleo-heat-templates/environments/ssl/tls-everywhere-endpoints-dns.yaml \
            -e /home/stack/templates/custom-domain.yaml \
            -e /home/stack/templates/enable-tls.yaml

   • haproxy-public-tls-certmonger.yaml 환경 파일을 사용하여 IdM 발행 인증서가 있는 외부 엔드포인트를 보호합니다. 이 구현을 위해 novajoin에서 사용하는 VIP 끝점에 대한 DNS 항목을 생성해야 합니다.

     1. novajoin에서 사용하는 VIP 엔드포인트에 대한 DNS 항목을 생성해야 합니다. '/home/stack/templates의 사용자 지정 network-environment.yaml 파일에 있는 오버클라우드 네트워크를 식별합니다.

        parameter_defaults:
            ControlPlaneDefaultRoute: 192.168.24.1
            ExternalAllocationPools:
            -   end: 10.0.0.149
                start: 10.0.0.101
            InternalApiAllocationPools:
            -   end: 172.17.1.149
                start: 172.17.1.10
            StorageAllocationPools:
            -   end: 172.17.3.149
                start: 172.17.3.10
            StorageMgmtAllocationPools:
            -   end: 172.17.4.149
                start: 172.17.4.10

     2. heat 템플릿에 각 오버클라우드 네트워크의 가상 IP 주소 목록을 생성합니다(예: /home/stack/public_vip.yaml ).

        parameter_defaults:
            ControlFixedIPs: [{'ip_address':'192.168.24.101'}]
            PublicVirtualFixedIPs: [{'ip_address':'10.0.0.101'}]
            InternalApiVirtualFixedIPs: [{'ip_address':'172.17.1.101'}]
            StorageVirtualFixedIPs: [{'ip_address':'172.17.3.101'}]
            StorageMgmtVirtualFixedIPs: [{'ip_address':'172.17.4.101'}]
            RedisVirtualFixedIPs: [{'ip_address':'172.17.1.102'}]

     3. 필요에 따라 각 VIP 및 영역에 대한 IdM에 DNS 항목을 추가합니다.

        ipa dnsrecord-add lab.local overcloud --a-rec 10.0.0.101
        ipa dnszone-add ctlplane.lab.local
        ipa dnsrecord-add ctlplane.lab.local overcloud --a-rec 192.168.24.101
        ipa dnszone-add internalapi.lab.local
        ipa dnsrecord-add internalapi.lab.local overcloud --a-rec 172.17.1.101
        ipa dnszone-add storage.lab.local
        ipa dnsrecord-add storage.lab.local overcloud --a-rec 172.17.3.101
        ipa dnszone-add storagemgmt.lab.local
        ipa dnsrecord-add storagemgmt.lab.local overcloud --a-rec 172.17.4.101

     4. 배포에 다음 환경 파일을 포함하여 내부 및 외부 엔드포인트를 보호합니다.

        • enable-internal-tls.yaml
        • tls-everywhere-endpoints-dns.yaml
        • haproxy-public-tls-certmonger.yaml
        • custom-domain.yaml

        • public_vip.yaml

          openstack overcloud deploy \
            --templates \
             -e /usr/share/openstack-tripleo-heat-templates/environments/ssl/enable-internal-tls.yaml \
             -e /usr/share/openstack-tripleo-heat-templates/environments/ssl/tls-everywhere-endpoints-dns.yaml \
             -e /usr/share/openstack-tripleo-heat-templates/environments/services/haproxy-public-tls-certmonger.yaml \
             -e /home/stack/templates/custom-domain.yaml \
             -e /home/stack/templates/public-vip.yaml

절차

1. 새 파일(예: glance-settings.yaml )을 만듭니다. 예제의 구문을 사용하여 이 파일을 채웁니다.

2. openstack overcloud deploy 명령에 glance-settings.yaml 파일과 배포와 관련된 기타 환경 파일을 포함합니다.

   $ openstack overcloud deploy --templates -e glance-settings.yaml

1. 스키마가 선택됩니다.

   1. 누락된 스키마: 거부
   2. 허용 목록이 있고 allowlist: reject에 체계가 없는 경우. 그렇지 않으면 C를 건너뛰고 2로 계속합니다.
   3. blocklist가 있고 체계가 blocklist: reject에 있는 경우.

2. 호스트 이름이 선택됩니다.

   1. 누락된 호스트 이름: reject
   2. 허용 목록이 있고 allowlist: reject에 호스트 이름이 없는 경우. 그렇지 않으면 C를 건너뛰고 3으로 계속합니다.
   3. blocklist가 있고 blocklist: reject에 호스트 이름이 있는 경우.

3. URI에 포트가 있는 경우 포트가 확인됩니다.

   1. 허용 목록이 있고 allowlist: reject에 포트가 없는 경우. 그렇지 않으면 B를 건너뛰고 4까지 계속합니다.
   2. blocklist가 있고, 포트가 blocklist: reject에 있는 경우.
4. URI는 유효한 것으로 허용됩니다.

절차

1. 다음 콘텐츠를 사용하여 swift-external-params.yaml 이라는 새 파일을 생성합니다.

   • EXTERNAL.IP:PORT 를 외부 프록시의 IP 주소 및 포트로 바꿉니다.

   • AUTHTOKEN 을 SwiftPassword 행의 외부 프록시의 authtoken 암호로 교체합니다.

     parameter_defaults:
       ExternalSwiftPublicUrl: 'https://EXTERNAL.IP:PORT/v1/AUTH_%(tenant_id)s'
       ExternalSwiftInternalUrl: 'http://192.168.24.9:8080/v1/AUTH_%(tenant_id)s'
       ExternalSwiftAdminUrl: 'http://192.168.24.9:8080'
       ExternalSwiftUserTenant: 'service'
       SwiftPassword: AUTHTOKEN

2. 이 파일을 swift-external-params.yaml 로 저장합니다.

3. 다음 외부 Object Storage 서비스 환경 파일과 배포와 관련된 기타 환경 파일을 사용하여 오버클라우드를 배포합니다.

   openstack overcloud deploy --templates \
   -e [your environment files] \
   -e /usr/share/openstack-tripleo-heat-templates/environments/swift-external.yaml \
   -e swift-external-params.yaml

절차

1. 다음 parameter_defaults 를 사용자 지정 환경 파일(예: swift-external-params.yaml )에 추가하고 배포에 맞게 값을 조정합니다.

   parameter_defaults:
      ExternalSwiftPublicUrl: 'http://<Public RGW endpoint or loadbalancer>:8080/swift/v1/AUTH_%(project_id)s'
      ExternalSwiftInternalUrl: 'http://<Internal RGW endpoint>:8080/swift/v1/AUTH_%(project_id)s'
      ExternalSwiftAdminUrl: 'http://<Admin RGW endpoint>:8080/swift/v1/AUTH_%(project_id)s'
      ExternalSwiftUserTenant: 'service'
      SwiftPassword: 'choose_a_random_password'

   참고

   예제 코드 스니펫에는 해당 환경에서 사용하는 값과 다를 수 있는 매개변수 값이 포함되어 있습니다.

   • 원격 RGW 인스턴스가 수신 대기하는 기본 포트는 8080 입니다. 포트는 외부 RGW 구성 방법에 따라 다를 수 있습니다.
   • Overcloud에서 생성된 swift 사용자는 SwiftPassword 매개 변수로 정의된 암호를 사용합니다. rgw_keystone_admin_password 를 사용하여 ID 서비스를 인증하도록 동일한 암호를 사용하도록 외부 RGW 인스턴스를 구성해야 합니다.

2. 다음 코드를 Ceph 구성 파일에 추가하여 ID 서비스를 사용하도록 RGW를 구성합니다. 환경에 맞게 변수 값을 바꿉니다.

       rgw_keystone_api_version = 3
       rgw_keystone_url = http://<public Keystone endpoint>:5000/
       rgw_keystone_accepted_roles = member, Member, admin
       rgw_keystone_accepted_admin_roles = ResellerAdmin, swiftoperator
       rgw_keystone_admin_domain = default
       rgw_keystone_admin_project = service
       rgw_keystone_admin_user = swift
       rgw_keystone_admin_password = <password_as_defined_in_the_environment_parameters>
       rgw_keystone_implicit_tenants = true
       rgw_keystone_revocation_interval = 0
       rgw_s3_auth_use_keystone = true
       rgw_swift_versioning_enabled = true
       rgw_swift_account_in_url = true

   참고

   director는 기본적으로 ID 서비스에 다음 역할 및 사용자를 생성합니다.

   • rgw_keystone_accepted_admin_roles: ResellerAdmin, swiftoperator
   • rgw_keystone_admin_domain: default
   • rgw_keystone_admin_project: service
   • rgw_keystone_admin_user: swift

3. 배포와 관련된 기타 환경 파일을 사용하여 추가 환경 파일을 사용하여 오버클라우드를 배포합니다.

   openstack overcloud deploy --templates \
   -e <your_environment_files>
   -e /usr/share/openstack-tripleo-heat-templates/environments/swift-external.yaml
   -e swift-external-params.yaml

검증

1. stack 사용자로 언더클라우드에 로그인합니다.

2. overcloudrc 파일을 소싱합니다.

   $ source ~/stackrc

3. 엔드포인트가 ID 서비스(keystone)에 있는지 확인합니다.

   $ openstack endpoint list --service object-store
   
   +---------+-----------+-------+-------+---------+-----------+---------------+
   | ID | Region    | Service Name | Service Type | Enabled | Interface | URL |
   +---------+-----------+-------+-------+---------+-----------+---------------+
   | 233b7ea32aaf40c1ad782c696128aa0e | regionOne | swift | object-store | True    | admin     | http://192.168.24.3:8080/v1/AUTH_%(project_id)s |
   | 4ccde35ac76444d7bb82c5816a97abd8 | regionOne | swift | object-store | True    | public    | https://192.168.24.2:13808/v1/AUTH_%(project_id)s |
   | b4ff283f445348639864f560aa2b2b41 | regionOne | swift | object-store | True    | internal  | http://192.168.24.3:8080/v1/AUTH_%(project_id)s |
   +---------+-----------+-------+-------+---------+-----------+---------------+

4. 테스트 컨테이너를 생성합니다.

   $ openstack container create <testcontainer>
   +----------------+---------------+------------------------------------+
   | account | container | x-trans-id |
   +----------------+---------------+------------------------------------+
   | AUTH_2852da3cf2fc490081114c434d1fc157 | testcontainer | tx6f5253e710a2449b8ef7e-005f2d29e8 |
   +----------------+---------------+------------------------------------+

5. 구성 파일을 생성하여 데이터를 컨테이너에 업로드할 수 있는지 확인합니다.

   $ openstack object create testcontainer undercloud.conf
   +-----------------+---------------+----------------------------------+
   | object          | container     | etag                             |
   +-----------------+---------------+----------------------------------+
   | undercloud.conf | testcontainer | 09fcffe126cac1dbac7b89b8fd7a3e4b |
   +-----------------+---------------+----------------------------------+

6. 테스트 컨테이너를 삭제합니다.

   $ openstack container delete -r <testcontainer>

절차

1. cinder 를 이미지 서비스 백엔드로 구성하려면 환경 파일에 다음 행을 추가합니다.

   parameter_defaults:
     GlanceBackend: cinder

2. cinder 백엔드가 활성화된 경우 기본적으로 다음 매개변수와 값이 설정됩니다.

   cinder_store_auth_address = http://172.17.1.19:5000/v3
   cinder_store_project_name = service
   cinder_store_user_name = glance
   cinder_store_password = ****secret****

3. 사용자 정의 사용자 이름 또는 cinder_store_ 매개변수의 사용자 지정 값을 사용하려면 ExtraConfig 매개변수를 parameter_defaults 에 추가하고 사용자 정의 값을 포함합니다.

   ExtraConfig:
       glance::config::api_config:
         glance_store/cinder_store_auth_address:
           value: "%{hiera('glance::api::authtoken::auth_url')}/v3"
         glance_store/cinder_store_user_name:
           value: <user-name>
         glance_store/cinder_store_password:
           value: "%{hiera('glance::api::authtoken::password')}"
         glance_store/cinder_store_project_name:
           value: "%{hiera('glance::api::authtoken::project_name')}"

절차

1. 환경 파일에서 glance-api.conf heat 템플릿에서 플레이버 값을 keystone+cachemanagement 로 자동 설정하는 GlanceCacheEnabled 매개변수 값을 true 로 설정합니다.

   parameter_defaults:
       GlanceCacheEnabled: true

2. 오버클라우드를 재배포할 때 openstack overcloud deploy 명령에 환경 파일을 포함합니다.

3. 선택 사항: 오버클라우드를 재배포할 때 대체 빈도로 glance_cache_pruner 를 조정합니다. 다음 예제에서는 5분의 빈도를 보여줍니다.

   parameter_defaults:
     ControllerExtraConfig:
       glance::cache::pruner::minute: '*/5'

   파일 시스템 전체 시나리오를 방지하려면 필요에 따라 빈도를 조정합니다. 대체 빈도를 선택할 때 다음 요소를 포함합니다.

   • 환경에 캐시할 파일의 크기입니다.
   • 사용 가능한 파일 시스템 공간의 양입니다.
   • 환경이 이미지를 캐시하는 빈도입니다.

절차

1. stack 사용자로 Undercloud 노드에 로그인합니다.
2. 각 오버클라우드 노드에는 heat-admin 사용자 계정이 있습니다. 이 사용자 계정에는 언더클라우드에서 Overcloud 노드로의 암호 없이 SSH 액세스를 제공하는 언더클라우드 공용 SSH 키가 포함되어 있습니다. Undercloud 노드에서 heat-admin 사용자로 SSH를 통해 Overcloud 노드에 로그인합니다.
3. sudo -i 를 사용하여 root 사용자로 전환합니다.

1. tls-ciphers.yaml 이라는 heat 템플릿 환경 파일을 생성합니다.

   touch ~/templates/tls-ciphers.yaml

2. 환경 파일의 ExtraConfig 후크를 사용하여 tripleo::haproxy::ssl_cipher_suite 및 tripleo::haproxy::ssl_options hieradata에 값을 적용합니다.

   parameter_defaults:
     ExtraConfig:
       tripleo::haproxy::ssl_cipher_suite: 'DHE-RSA-AES128-CCM:DHE-RSA-AES256-CCM:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-CCM:ECDHE-ECDSA-AES256-CCM:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305'
   
       tripleo::haproxy::ssl_options: 'no-sslv3 no-tls-tickets'

   참고

   암호화 방식 컬렉션은 연속된 한 행으로 되어 있습니다.

3. 오버클라우드를 배포할 때 overcloud deploy 명령을 사용하여 tls-ciphers.yaml 환경 파일을 포함합니다.

   openstack overcloud deploy --templates \
   ...
   -e /home/stack/templates/tls-ciphers.yaml
   ...

절차

1. 환경 파일을 templates 하위 디렉터리에 복사합니다.

   $ cp /usr/share/openstack-tripleo-heat-templates/environments/neutron-ml2-fujitsu-cfab.yaml /home/stack/templates/

2. 절대 경로를 사용하도록 resource_registry 를 편집합니다.

   resource_registry:
     OS::TripleO::Services::NeutronML2FujitsuCfab: /usr/share/openstack-tripleo-heat-templates/puppet/services/neutron-plugin-ml2-fujitsu-cfab.yaml

3. /home/stack/templates/neutron-ml2-fujitsu-cfab.yaml에서 parameter_defaults 를 검토합니다.

   • NeutronFujitsuCfabAddress - C-Fabric의 telnet IP 주소(문자열)
   • NeutronFujitsuCfabUserName - 사용할 C-Fabric 사용자 이름(문자열)
   • NeutronFujitsuCfabPassword - C-Fabric 사용자 계정의 암호(문자열)
   • NeutronFujitsuCfabPhysicalNetworks - <physical_network>:<vfab_id> phyples로 physical_network 이름 및 해당 vfab ID를 지정합니다. (comma_delimited_list)
   • NeutronFujitsuCfabSharePprofile - 동일한 VLAN ID를 사용하는 neutron 포트 간에 C-Fabric pprofile을 공유할지 여부를 결정합니다. (boolean)
   • NeutronFujitsuCfabPprofilePrefix - pprofile 이름의 접두사 문자열(문자열)
   • NeutronFujitsuCfabsaveConfig - 구성을 저장할지 여부를 결정합니다. (부울)

4. 배포에 템플릿을 적용하려면 openstack overcloud deploy 명령에 환경 파일을 포함합니다.

   $ openstack overcloud deploy --templates -e /home/stack/templates/neutron-ml2-fujitsu-cfab.yaml [OTHER OPTIONS] ...

절차

1. 환경 파일을 templates 하위 디렉터리에 복사합니다.

   $ cp /usr/share/openstack-tripleo-heat-templates/environments/neutron-ml2-fujitsu-fossw.yaml /home/stack/templates/

2. 절대 경로를 사용하도록 resource_registry 를 편집합니다.

   resource_registry:
     OS::TripleO::Services::NeutronML2FujitsuFossw: /usr/share/openstack-tripleo-heat-templates/puppet/services/neutron-plugin-ml2-fujitsu-fossw.yaml

3. /home/stack/templates/neutron-ml2-fujitsu-fossw.yaml에서 parameter_defaults 를 검토합니다.

   • NeutronFujitsuFosswIps - 모든 FOS 스위치의 IP 주소. (comma_delimited_list)
   • NeutronFujitsuFosswUserName - 사용할 FOS 사용자 이름(문자열)
   • NeutronFujitsuFosswPassword - FOS 사용자 계정의 암호(문자열)
   • NeutronFujitsuFosswPort - SSH 연결에 사용할 포트 번호입니다(숫자)
   • NeutronFujitsuFosswTimeout - SSH 연결의 시간 초과 기간(숫자)
   • NeutronFujitsuFosswUdpDestPort - FOS 스위치의 VXLAN UDP 대상의 포트 번호입니다(숫자)
   • NeutronFujitsuFosswOvsdbVlanidRangeMin - VNI 및 물리적 포트 바인딩에 사용되는 최소 VLAN ID입니다(숫자)
   • NeutronFujitsuFosswOvsdbPort - FOS 스위치의 OVSDB 서버의 포트 번호입니다(숫자)

4. 배포에 템플릿을 적용하려면 openstack overcloud deploy 명령에 환경 파일을 포함합니다.

   $ openstack overcloud deploy --templates -e /home/stack/templates/neutron-ml2-fujitsu-fossw.yaml [OTHER OPTIONS] ...

배포 중 heat를 사용하여 KernelArgs 수정

1. 언더클라우드 호스트에 stack 사용자로 로그인합니다.

2. stackrc 인증 정보 파일을 소싱합니다.

   $ source stackrc

3. 다음 내용으로 환경 파일 overcloud-console.yaml 을 생성합니다.

   parameter_defaults:
     <role>Parameters:
       KernelArgs: "console=<console-name>"

   <role> 을 설정하려는 오버클라우드 역할의 이름으로 바꾸고 <console-name> 을 사용하려는 콘솔의 ID로 바꿉니다. 예를 들어 다음 스니펫을 사용하여 tty0 을 사용하도록 기본 역할의 모든 오버클라우드 노드를 구성합니다.

   parameter_defaults:
     ControllerParameters:
       KernelArgs: "console=tty0"
     ComputeParameters:
       KernelArgs: "console=tty0"
     BlockStorageParameters:
       KernelArgs: "console=tty0"
     ObjectStorageParameters:
       KernelArgs: "console=tty0"
     CephStorageParameters:
       KernelArgs: "console=tty0"

4. 배포 명령에 -e 옵션을 사용하여 overcloud-console-tty0.yaml 파일을 포함합니다.

overcloud-full.qcow2 이미지 수정

1. 언더클라우드 호스트에 stack 사용자로 로그인합니다.

2. stackrc 인증 정보 파일을 소싱합니다.

   $ source stackrc

3. overcloud-full.qcow2 이미지의 커널 인수를 수정하여 하드웨어에 대한 올바른 콘솔을 설정합니다. 예를 들어 콘솔을 tty0 으로 설정합니다.

   $ virt-customize --selinux-relabel -a overcloud-full.qcow2 --run-command 'grubby --update-kernel=ALL --args="console=tty0"'

4. 이미지를 director로 가져옵니다.

   $ openstack overcloud image upload --image-path /home/stack/images/overcloud-full.qcow2

5. Overcloud를 배포합니다.

검증

1. 언더클라우드에서 오버클라우드 노드에 로그인합니다.

   $ ssh heat-admin@<IP-address>

   <IP-address> 를 오버클라우드 노드의 IP 주소로 바꿉니다.

2. /proc/cmdline 파일의 내용을 검사하고 console= 매개변수가 사용하려는 콘솔의 값으로 설정되어 있는지 확인합니다.

   [heat-admin@controller-0 ~]$ cat /proc/cmdline
   BOOT_IMAGE=(hd0,msdos2)/boot/vmlinuz-4.18.0-193.29.1.el8_2.x86_64 root=UUID=0ec3dea5-f293-4729-b676-5d38a611ce81 ro console=tty0 console=ttyS0,115200n81 no_timer_check crashkernel=auto rhgb quiet