각 기본 RHOSP(Red Hat OpenStack Platform) 서비스는 컨테이너에서 실행됩니다. 이를 통해 각 서비스를 호스트와 분리된 자체 네임스페이스 내에 유지하는 방법이 제공됩니다. 다음과 같은 효과가 있습니다.

Red Hat OpenStack Platform은 Kolla 툴셋으로 빌드 및 관리되는 컨테이너 세트를 사용합니다.

director는 핵심 OpenStack Platform 서비스를 오버클라우드에 컨테이너로 설치합니다. 컨테이너화된 서비스의 템플릿은 /usr/share/openstack-tripleo-heat-templates/deployment/ 에 있습니다.

컨테이너화된 서비스를 사용하는 모든 노드에 대해 역할에 OS::TripleO::Services::Podman 서비스를 활성화해야 합니다. 사용자 지정 역할 구성에 roles_data.yaml 파일을 생성할 때 기본 구성 가능 서비스와 함께 OS::TripleO::Services::Podman 서비스를 포함합니다. 예를 들어 IronicConductor 역할은 다음 역할 정의를 사용합니다.

- 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::Tuned

컨테이너화된 각 서비스 템플릿에는 OpenStack Orchestration(heat) 서비스에 전달된 데이터 집합을 정의하는 outputs 섹션이 포함되어 있습니다. 표준 구성 가능 서비스 매개변수 외에도 템플릿에는 컨테이너 구성과 관련된 매개변수 세트가 포함되어 있습니다.

일부 타사 하드웨어를 블록 스토리지 백엔드로 사용하려면 벤더 플러그인을 배포해야 합니다. 다음 예제에서는 Dell EMC 하드웨어를 블록 스토리지 백엔드로 사용하기 위해 벤더 플러그인을 배포하는 방법을 보여줍니다.

오버클라우드 설치에는 컨테이너 이미지를 가져올 위치와 저장 방법을 결정하는 환경 파일이 필요합니다. 컨테이너 이미지를 준비하는 데 사용할 수 있는 이 환경 파일을 생성하고 사용자 지정하십시오.

컨테이너를 준비하는 데 필요한 기본 파일(containers-prepare-parameter.yaml)에는 ContainerImagePrepare heat 매개변수가 포함되어 있습니다. 이 매개변수는 이미지 세트를 준비하기 위한 다양한 설정을 정의합니다.

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

각각의 설정에서 하위 매개변수 세트를 통해 사용할 이미지와 해당 이미지의 사용 방법을 정의할 수 있습니다. 다음 표에는 각 ContainerImagePrepare 전략에 사용할 수 있는 하위 매개변수에 대한 정보가 나와 있습니다.

set 매개변수에 여러 key: value 정의를 사용할 수 있습니다.

Red Hat Container Registry는 특정 버전 형식을 사용하여 모든 Red Hat OpenStack Platform 컨테이너 이미지에 태그를 지정합니다. 이 형식은 version-release인 각 컨테이너의 레이블 메타데이터를 따릅니다.

예를 들어 최신 버전의 Red Hat OpenStack Platform이 17.1.0이고 컨테이너 이미지의 릴리스가 5.161 인 경우 컨테이너 이미지의 결과 태그는 17.1.0-5.161입니다.

Red Hat Container Registry에서는 해당 컨테이너 이미지 버전의 최신 릴리스에 연결되는 메이저 및 마이너 version 버전 태그 세트도 사용합니다. 예를 들어 17.1 및 17.1.0은 모두 17.1.0 컨테이너 스트림의 최신 릴리스에 연결됩니다. 17.1의 새로운 마이너 릴리스가 발생하면 17.1 태그가 새로운 마이너 릴리스 스트림의 최신 릴리스와 관련이 있으며 17.1.0 태그는 17.1.0 스트림 내의 최신 릴리스에 계속 연결됩니다.

ContainerImagePrepare 매개변수에는 다운로드할 컨테이너 이미지를 결정하는 데 사용할 두 개의 하위 매개변수가 포함되어 있습니다. 이러한 하위 매개변수는 set 사전 내의 tag 매개변수와 tag_from_label 매개변수입니다. 다음 지침을 사용하여 tag 또는 tag_from_label을 사용할지 여부를 결정합니다.

registry.redhat.io 레지스트리에는 이미지에 액세스하여 가져오기 위한 인증이 필요합니다. registry.redhat.io 및 기타 개인 레지스트리로 인증하려면 containers-prepare-parameter.yaml 파일에 ContainerImageRegistryCredentials 및 ContainerImageRegistryLogin 매개변수를 포함합니다.

parameter_defaults:
  ContainerImagePrepare:
  - push_destination: true
    set:
      namespace: registry.redhat.io/...
      ...
  ContainerImageRegistryCredentials:
    registry.redhat.io:
      my_username: my_password

예제에서 my_username 및 my_password를 사용자 인증 정보로 교체합니다. 개별 사용자 인증 정보를 사용하는 대신, 레지스트리 서비스 계정을 생성하고 해당 인증 정보를 사용하여 registry.redhat.io 콘텐츠에 액세스하는 것이 좋습니다.

여러 레지스트리에 대한 인증 세부 정보를 지정하려면 ContainerImageRegistryCredentials의 각 레지스트리에 대해 여러 개의 키 쌍 값을 설정합니다.

parameter_defaults:
  ContainerImagePrepare:
  - push_destination: true
    set:
      namespace: registry.redhat.io/...
      ...
  - push_destination: true
    set:
      namespace: registry.internalsite.com/...
      ...
  ...
  ContainerImageRegistryCredentials:
    registry.redhat.io:
      myuser: 'p@55w0rd!'
    registry.internalsite.com:
      myuser2: '0th3rp@55w0rd!'
    '192.0.2.1:8787':
      myuser3: '@n0th3rp@55w0rd!'

자세한 내용은 Red Hat Container Registry Authentication 을 참조하십시오.

지정된 설정에 대해 push_destination이 구성되지 않은 경우 ContainerImageRegistryLogin을 true로 설정해야 합니다.

parameter_defaults:
  ContainerImagePrepare:
  - push_destination: false
    set:
      namespace: registry.redhat.io/...
      ...
  ...
  ContainerImageRegistryCredentials:
    registry.redhat.io:
      myuser: 'p@55w0rd!'
  ContainerImageRegistryLogin: true

하지만 오버클라우드 노드에서 ContainerImageRegistryCredentials에 정의된 레지스트리 호스트에 네트워크로 연결할 수 없고 ContainerImageRegistryLogin을 true로 설정하는 경우, 로그인할 때 배포에 실패할 수 있습니다. 오버클라우드 노드에서 ContainerImageRegistryCredentials에 정의된 레지스트리 호스트에 네트워크로 연결할 수 없고 push_destination을 true로 설정하고 ContainerImageRegistryLogin을 false로 설정하여 오버클라우드 노드가 언더클라우드에서 이미지를 가져오도록 합니다.

parameter_defaults:
  ContainerImagePrepare:
  - push_destination: true
    set:
      namespace: registry.redhat.io/...
      ...
  ...
  ContainerImageRegistryCredentials:
    registry.redhat.io:
      myuser: 'p@55w0rd!'
  ContainerImageRegistryLogin: false

ContainerImagePrepare 매개변수의 값은 YAML 목록입니다. 즉, 여러 항목을 지정할 수 있습니다.

다음 예제에서는 두 개의 항목을 보여줍니다. 여기서 director는 17.1-hotfix 로 태그된 버전을 사용하는 nova-api 이미지를 제외하고 모든 이미지의 최신 버전을 사용합니다.

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

includes 및 excludes 매개 변수는 정규식을 사용하여 각 항목에 대한 이미지 필터링을 제어합니다. includes 설정과 일치하는 이미지가 excludes와 일치하는 이미지보다 우선합니다. 일치하는 이미지로 간주되려면 이미지 이름이 includes 또는 excludes 정규식 값과 일치해야 합니다.

이미지 준비 과정에서 이미지를 수정한 다음, 수정된 이미지로 오버클라우드를 즉시 배포할 수 있습니다.

이미지 수정 시나리오는 다음과 같습니다.

준비 과정에서 이미지를 수정하려면, 수정할 각 이미지에 대해 Ansible 역할을 호출합니다. 이 역할은 소스 이미지를 가져와서 요청된 변경을 수행한 다음 그 결과를 태그합니다. prepare 명령으로 이미지를 대상 레지스트리로 푸시하고 수정된 이미지를 참조하도록 heat 매개변수를 설정할 수 있습니다.

Ansible 역할 tripleo-modify-image는 요청된 역할 인터페이스를 준수하고 수정 사용 사례에 필요한 작업을 수행합니다. ContainerImagePrepare 매개변수의 수정 관련 키를 사용하여 수정을 제어합니다.

tripleo-modify-image 역할에서 처리할 사용 케이스를 선택하려면 tasks_from 변수를 해당 역할에 필요한 파일로 설정합니다.

이미지를 수정하려면 ContainerImagePrepare 항목을 개발하고 테스트하는 동안 추가 옵션 없이 image prepare 명령을 실행하여 이미지가 예상대로 수정되는지 확인합니다.

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

RHOSP(Red Hat OpenStack Platform) 컨테이너의 컨테이너 이미지에서 기존 패키지를 업데이트할 수 있습니다.

컨테이너 이미지에 RPM 파일 디렉터리를 설치할 수 있습니다. 이 기능은 핫픽스, 로컬 패키지 빌드 또는 패키지 리포지토리를 통해 사용할 수 없는 패키지를 설치하는 데 유용합니다.

Dockerfile이 포함된 디렉터리를 지정하여 필요한 변경을 수행할 수 있습니다. tripleo-modify-image 역할을 호출하면 FROM 지시문을 변경하고 LABEL 지시문을 추가하는 Dockerfile.modified 파일이 생성됩니다.

Red Hat Satellite 6는 레지스트리 동기화 기능을 제공합니다. 이를 통해 여러 이미지를 Satellite 서버로 가져와 애플리케이션 라이프사이클의 일부로 관리할 수 있습니다. Satellite는 다른 컨테이너 활성화 시스템이 사용할 레지스트리 역할도 합니다. 컨테이너 이미지 관리 방법에 관한 자세한 내용은 Red Hat Satellite 6 Content Management Guide의 "Managing Container Images"를 참조하십시오.

다음 절차의 예제에서는 Red Hat Satellite 6용 hammer 명령행 툴과 ACME라는 조직을 사용합니다. 이 조직을 실제로 사용하는 Satellite 6 조직으로 대체하십시오.

다음 예제 환경 파일에는 Satellite별 매개변수가 포함되어 있습니다.

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

undercloud.conf 구성 파일에 containers-prepare-parameter.yaml 환경 파일을 정의해야 합니다. 그렇지 않으면 언더클라우드에서 기본값을 사용합니다.

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

director 설치 프로세스에는 director가 stack 사용자의 홈 디렉터리에서 읽어오는 undercloud.conf 구성 파일의 특정 설정이 필요합니다. 다음 단계에 따라 기본 템플릿을 복사하여 설정 기반으로 사용하십시오.

다음 목록에는 undercloud.conf 파일을 설정하기 위한 매개변수 정보가 나와 있습니다. 오류를 방지하려면 모든 매개변수를 관련 섹션에 보관합니다.

[ctlplane-subnet]
cidr = 192.168.24.0/24
dhcp_start = 192.168.24.5
dhcp_end = 192.168.24.24
inspection_iprange = 192.168.24.100,192.168.24.120
gateway = 192.168.24.1
masquerade = true

환경에 따라 필요한 만큼의 프로비저닝 네트워크를 지정할 수 있습니다.

이러한 매개변수의 값을 구성에 맞게 수정합니다. 완료되면 파일을 저장합니다.

다음 단계에 따라 director를 설치하고 몇 가지 기본적인 설치 후 작업을 수행합니다.

director 설치가 완료되었습니다. 이제 director 명령행 툴을 사용할 수 있습니다.

director는 언더클라우드 노드에서 기본 패키지를 업데이트하는 명령을 제공합니다. director를 사용하여 현재 RHOSP 환경에서 마이너 업데이트를 수행합니다.

다음 절차에서는 최소 구성으로 오버클라우드를 배포하는 방법을 보여줍니다. 결과적으로 기본 2-노드 오버클라우드(컨트롤러 노드 1개, 컴퓨팅 노드 1개)가 생성됩니다.

컨테이너화된 오버클라우드 업데이트에 대한 자세한 내용은 Red Hat OpenStack Platform 가이드의 마이너 업데이트 수행을 참조하십시오.

RHOSP(Red Hat OpenStack Platform)는 언더클라우드 및 오버클라우드 노드의 컨테이너에서 서비스를 실행합니다. 호스트의 개별 서비스를 제어해야 하는 경우도 있습니다. 이 섹션에서는 노드에서 실행하여 컨테이너화된 서비스를 관리할 수 있는 몇 가지 일반적인 명령에 대해 설명합니다.

$ sudo podman ps

중지되었거나 실패한 컨테이너를 명령 출력에 포함하려면 명령에 --all 옵션을 추가합니다.

$ sudo podman ps --all

컨테이너 이미지 목록을 표시하려면 다음 명령을 실행합니다.

$ sudo podman images

$ sudo podman inspect keystone

컨테이너 상태를 확인하려면 systemctl status 명령을 실행합니다.

$ sudo systemctl status tripleo_keystone
● tripleo_keystone.service - keystone container
   Loaded: loaded (/etc/systemd/system/tripleo_keystone.service; enabled; vendor preset: disabled)
   Active: active (running) since Fri 2019-02-15 23:53:18 UTC; 2 days ago
 Main PID: 29012 (podman)
   CGroup: /system.slice/tripleo_keystone.service
           └─29012 /usr/bin/podman start -a keystone

컨테이너를 중지하려면 systemctl stop 명령을 실행합니다.

$ sudo systemctl stop tripleo_keystone

컨테이너를 시작하려면 systemctl start 명령을 실행합니다.

$ sudo systemctl start tripleo_keystone

컨테이너를 다시 시작하려면 systemctl restart 명령을 실행합니다.

$ sudo systemctl restart tripleo_keystone

데몬이 컨테이너 상태를 모니터링하지 않으므로 Systemd는 다음 상황에서 대부분의 컨테이너를 자동으로 다시 시작합니다.

Systemd 서비스에 대한 자세한 내용은 systemd.service 문서를 참조하십시오.

모든 OpenStack Platform 컨테이너 타이머를 나열하려면 systemctl list-timers 명령을 실행하고 tripleo를 포함하는 행으로 출력을 제한합니다.

$ sudo systemctl list-timers | grep tripleo
Mon 2019-02-18 20:18:30 UTC  1s left       Mon 2019-02-18 20:17:26 UTC  1min 2s ago  tripleo_nova_metadata_healthcheck.timer            tripleo_nova_metadata_healthcheck.service
Mon 2019-02-18 20:18:34 UTC  5s left       Mon 2019-02-18 20:17:23 UTC  1min 5s ago  tripleo_keystone_healthcheck.timer                 tripleo_keystone_healthcheck.service
Mon 2019-02-18 20:18:35 UTC  6s left       Mon 2019-02-18 20:17:13 UTC  1min 15s ago tripleo_memcached_healthcheck.timer                tripleo_memcached_healthcheck.service
(...)

특정 컨테이너 타이머의 상태를 확인하려면 healthcheck 서비스에 대해 systemctl status 명령을 실행합니다.

$ sudo systemctl status tripleo_keystone_healthcheck.service
● tripleo_keystone_healthcheck.service - keystone healthcheck
   Loaded: loaded (/etc/systemd/system/tripleo_keystone_healthcheck.service; disabled; vendor preset: disabled)
   Active: inactive (dead) since Mon 2019-02-18 20:22:46 UTC; 22s ago
  Process: 115581 ExecStart=/usr/bin/podman exec keystone /openstack/healthcheck (code=exited, status=0/SUCCESS)
 Main PID: 115581 (code=exited, status=0/SUCCESS)

Feb 18 20:22:46 undercloud.localdomain systemd[1]: Starting keystone healthcheck...
Feb 18 20:22:46 undercloud.localdomain podman[115581]: {"versions": {"values": [{"status": "stable", "updated": "2019-01-22T00:00:00Z", "..."}]}]}}
Feb 18 20:22:46 undercloud.localdomain podman[115581]: 300 192.168.24.1:35357 0.012 seconds
Feb 18 20:22:46 undercloud.localdomain systemd[1]: Started keystone healthcheck.

컨테이너 타이머를 중지, 시작 또는 다시 시작하거나 상태를 표시하려면 .timer Systemd 리소스에 대해 관련 systemctl 명령을 실행합니다. 예를 들어 tripleo_keystone_healthcheck.timer 리소스의 상태를 확인하려면 다음 명령을 실행합니다.

$ sudo systemctl status tripleo_keystone_healthcheck.timer
● tripleo_keystone_healthcheck.timer - keystone container healthcheck
   Loaded: loaded (/etc/systemd/system/tripleo_keystone_healthcheck.timer; enabled; vendor preset: disabled)
   Active: active (waiting) since Fri 2019-02-15 23:53:18 UTC; 2 days ago

상태 확인 서비스가 비활성화되었지만 해당 서비스의 타이머가 있고 활성화되어 있는 경우 현재 점검이 시간 초과되어 있어도 타이머에 따라 실행됨을 의미합니다. 검사를 수동으로 시작할 수도 있습니다.

호스트는 이 디렉터리에 로그 회전을 적용하여 용량이 큰 파일 및 디스크 공간 관련 문제를 방지합니다.

컨테이너를 교체한 경우 podman은 컨테이너 ID 대신 컨테이너 이름을 사용하므로 새 컨테이너가 동일한 로그 파일에 출력됩니다.

podman logs 명령을 사용하여 컨테이너화된 서비스의 로그를 확인할 수도 있습니다. 예를 들어 keystone 컨테이너의 로그를 보려면 다음 명령을 실행합니다.

$ sudo podman logs keystone

$ sudo podman exec -it keystone /bin/bash

root 사용자로 keystone 컨테이너 쉘에 들어가려면 다음 명령을 실행합니다.

$ sudo podman exec --user 0 -it <NAME OR ID> /bin/bash

컨테이너를 종료하려면 다음 명령을 실행합니다.

# exit

오버클라우드 배포 중 또는 이후에 컨테이너화된 서비스가 실패하면 다음 권장 사항을 사용하여 실패의 근본 원인을 확인합니다.

$ sudo podman logs keystone

대부분의 경우 이 로그는 컨테이너 오류의 원인을 제공합니다.

$ sudo podman inspect keystone

이는 낮은 수준의 구성 데이터를 포함하는 JSON 오브젝트를 제공합니다. 출력을 jq 명령으로 전달하여 특정 데이터를 구문 분석할 수 있습니다. 예를 들어 keystone 컨테이너에 대한 컨테이너 마운트를 보려면 다음 명령을 실행합니다.

$ sudo podman inspect keystone | jq .[0].Mounts

또한 --format 옵션을 사용하여 단일 행에 대한 데이터를 구문 분석할 수 있으며 이는 컨테이너 데이터 세트에 대해 명령을 실행할 때 유용합니다. 예를 들어 keystone 컨테이너 실행에 사용된 옵션을 재생성하려면 --format 옵션과 함께 다음 inspect 명령을 사용합니다.

$ sudo podman inspect --format='{{range .Config.Env}} -e "{{.}}" {{end}} {{range .Mounts}} -v {{.Source}}:{{.Destination}}{{if .Mode}}:{{.Mode}}{{end}}{{end}} -ti {{.Config.Image}}' keystone

podman run 명령과 함께 이러한 옵션을 사용하면 문제 해결 목적으로 컨테이너를 재생성할 수 있습니다.

$ OPTIONS=$( sudo podman inspect --format='{{range .Config.Env}} -e "{{.}}" {{end}} {{range .Mounts}} -v {{.Source}}:{{.Destination}}{{if .Mode}}:{{.Mode}}{{end}}{{end}} -ti {{.Config.Image}}' keystone )
$ sudo podman run --rm $OPTIONS /bin/bash

$ sudo podman exec -ti keystone <COMMAND>

&lt ;COMMAND& gt;를 원하는 명령으로 바꿉니다. 예를 들어 각 컨테이너에는 서비스 연결을 확인하기 위한 상태 점검 스크립트가 있습니다. 다음 명령을 사용하여 keystone에 대해 상태 점검 스크립트를 실행할 수 있습니다.

$ sudo podman exec -ti keystone /openstack/healthcheck

컨테이너 쉘에 액세스하려면 명령으로 /bin/bash 를 사용하여 podman exec 를 실행합니다.

$ sudo podman exec -ti keystone /bin/bash

$ sudo podman export keystone -o keystone.tar

이 명령은 keystone.tar 아카이브를 생성하여 추출 및 확인할 수 있습니다.

다음 표는 Systemd 기반 서비스와 Systemd 서비스로 제어되는 podman 컨테이너 간의 상관 관계를 보여줍니다.

다음 표에서는 Systemd 기반 OpenStack 로그와 컨테이너에 해당하는 로그를 보여줍니다. 모든 컨테이너 기반 로그 위치는 물리적 호스트에서 사용할 수 있으며 컨테이너에 마운트됩니다.

다음 표에서는 Systemd 기반 OpenStack 구성과 컨테이너에 해당하는 구성을 보여줍니다. 모든 컨테이너 기반 구성 위치는 물리적 호스트에서 사용할 수 있으며 컨테이너에 마운트되며 각 컨테이너내의 구성에 병합됩니다.