엣지 이미지용 RHEL 컴파일, 설치 및 관리
Red Hat Enterprise Linux 9를 사용하여 에지 시스템 생성, 배포 및 관리
초록
Red Hat 문서에 관한 피드백 제공
문서에 대한 피드백에 감사드립니다. 어떻게 개선할 수 있는지 알려주십시오.
Jira를 통해 피드백 제출 (등록 필요)
- Jira 웹 사이트에 로그인합니다.
- 상단 탐색 모음에서 생성 을 클릭합니다.
- Summary (요약) 필드에 설명 제목을 입력합니다.
- Description (설명) 필드에 개선을 위한 제안을 입력합니다. 문서의 관련 부분에 대한 링크를 포함합니다.
- 대화 상자 하단에서 생성 을 클릭합니다.
1장. RHEL for Edge 이미지 소개
RHEL for Edge 이미지는RHEL for Edge 서버를 원격으로 설치하는 시스템 패키지가 포함된 rpm-ostree
이미지입니다.
시스템 패키지는 다음과 같습니다.
-
기본 OS
패키지 - Podman 컨테이너 엔진
- 추가 RPM 패키지 관리자(RPM) 콘텐츠
RHEL for Edge는 읽기 전용
루트 디렉터리가 포함된 변경 불가능한 운영 체제이며 다음과 같은 특징이 있습니다.
- 패키지는 루트 디렉터리에서 격리됩니다.
- 운영 체제의 각 버전은 별도의 배포입니다. 따라서 필요한 경우 시스템을 이전 배포로 롤백할 수 있습니다.
-
rpm-ostree
이미지는 네트워크를 통해 효율적인 업데이트를 제공합니다. - RHEL for Edge는 여러 운영 체제 분기 및 리포지토리를 지원합니다.
-
이미지에는 hybrid
rpm-ostree
패키지 시스템이 포함되어 있습니다.
RHEL 이미지 빌더 툴을 사용하여 사용자 지정 RHEL for Edge 이미지를 구성할 수 있습니다. Red Hat Hybrid Cloud Console 플랫폼의 엣지 관리 애플리케이션에 액세스하고 자동화된 관리를 구성하여 RHEL for Edge 이미지를 생성할 수도 있습니다.
에지 관리 애플리케이션을 사용하여 이미지 프로비저닝 및 등록을 단순화합니다. 에지 관리에 대한 자세한 내용은 RHEL for Edge 이미지 생성 및 자동 관리 설명서를 참조하십시오.
RHEL 이미지 빌더 온프레미스 버전을 사용하여 생성된 RHEL for Edge 사용자 지정 이미지를 사용하는 것은 엣지 관리 애플리케이션에서 지원되지 않습니다. Edge 관리 지원 기능을 참조하십시오.
엣지 관리 애플리케이션은 edge
-commit 및 edge-installer
이미지 유형만 빌드하고 관리할 수 있습니다.
또한 에지 관리 애플리케이션을 사용하여 생성한 이미지와 함께 FIDO Device Onboarding (FDO) 프로세스를 사용할 수 없습니다.
RHEL for Edge 이미지를 사용하면 다음과 같은 이점을 얻을 수 있습니다.
- Atomic 업그레이드
- 각 업데이트의 상태를 알고 시스템을 재부팅할 때까지 변경 사항이 표시되지 않습니다.
- 사용자 정의 상태 점검 및 지능형 롤백
- 사용자 정의 상태 점검을 생성할 수 있으며 상태 점검이 실패하면 운영 체제가 이전 안정된 상태로 롤백됩니다.
- 컨테이너 중심 워크플로
- 이미지 업데이트는 백그라운드에서 준비되어 시스템에 대한 워크로드 중단을 최소화합니다.
- 최적화된 Over-the-Air 업데이트
- 효율적인 OTA(Over-the-air) delta 업데이트 덕분에 간헐적인 연결이 있더라도 시스템을 최신 상태로 유지할 수 있습니다.
1.1. RHEL for Edge - 지원 아키텍처
현재 AMD 및 Intel 64비트 시스템에 RHEL for Edge 이미지를 배포할 수 있습니다.
RHEL for Edge는 일부 장치에서 ARM 시스템을 지원합니다. 지원되는 장치에 대한 자세한 내용은 Red Hat 인증 하드웨어를 참조하십시오.
1.2. RHEL for Edge 이미지 유형 및 해당 배포
RHEL for Edge 이미지에 대한 구성 및 배포에는 다음 두 단계가 포함됩니다.
-
RHEL 이미지 빌더 툴을 사용하여 RHEL
rpm-ostree
이미지 구성.composer-cli
툴의 명령줄 인터페이스를 통해 RHEL 이미지 빌더에 액세스하거나 RHEL 웹 콘솔에서 그래픽 사용자 인터페이스를 사용할 수 있습니다. - RHEL 설치 프로그램을 사용하여 이미지 배포.
이미지 유형은 콘텐츠 측면에서 다르며, 따라서 다양한 유형의 배포 환경에 적합합니다. RHEL for Edge 이미지를 빌드하는 동안 다음 이미지 유형을 선택할 수 있습니다.
- RHEL for Edge 커밋
-
이 이미지 유형은 시스템에 원자적이고 안전한 업데이트를 제공합니다.
Edge-commit
(.tar
) 이미지에는 전체 운영 체제가 포함되어 있지만 직접 부팅할 수는 없습니다.edge-commit
이미지 유형을 부팅하려면 다른 디스크 이미지 유형 중 하나를 사용하여 배포해야 합니다. 에지 관리 애플리케이션에서에지 커밋
이미지를 빌드할 수도 있습니다. - RHEL for Edge Container
-
이 이미지 유형은 통합 HTTP 서버를 사용하여 OSTree 커밋을 제공합니다.
edge-container
는OSTree
커밋을 생성하고 웹 서버를 사용하여 OCI 컨테이너에 포함합니다.edge-commit
이미지가 시작되면 웹 서버에서 해당 커밋을 OSTree 리포지토리로 제공합니다. - RHEL for Edge 설치 프로그램
-
edge-installer
이미지 유형은 설치 프로그램에 포함된 RHEL for Edge OSTree 커밋을 배포하는 Anaconda 기반 설치 프로그램 이미지입니다. RHEL 이미지 빌더 툴을 사용하여.iso
이미지를 빌드하는 것 외에도 에지 관리 애플리케이션에 RHEL for Edge 설치 프로그램( Edge-installer
)을 빌드할 수도 있습니다.edge-installer
이미지 유형은 설치 프로그램 이미지에 포함된 RHEL for Edge ostree 커밋을 배포하는 Anaconda 기반 설치 프로그램 이미지입니다. - RHEL for Edge Raw Image
-
하드 디스크에서 RHEL 원시 이미지를 플래시하거나 가상 머신에서 원시 이미지를 부팅하여 베어 메탈 플랫폼에 대해 를 사용합니다.
edge-raw-image
는 배포된 기존 OSTree 커밋이 있는 파티션 레이아웃이 포함된 파일로 구성된 압축된 원시 이미지입니다. - RHEL for Edge Simplified Installer
-
FDO 또는 Ignition을 통해 사용자 구성이 제공되는 자동 설치에
edge-simplified-installer
이미지 유형을 사용합니다.edge-simplified-installer
이미지는 Ignition을 사용하여 부팅 프로세스의 초기 단계에서 이미지에 사용자 구성을 삽입할 수 있습니다. 또한 FDO를 부팅 프로세스의 초기 단계에서 사용자 구성을 삽입하는 방법으로 사용할 수 있습니다. Edge Simplified Installer를 부팅한 후 삽입된 사용자 구성이 있는 장치에 RHEL for Edge 이미지를 프로비저닝합니다. - RHEL for Edge AMI
-
이 이미지를 사용하여 AWS 클라우드에서 EC2 인스턴스를 시작합니다.
edge-ami
이미지는 Ignition 툴을 사용하여 부팅 프로세스의 초기 단계에서 이미지에 사용자 구성을 삽입합니다..ami
이미지를 AWS에 업로드하고 AWS에서 EC2 인스턴스를 부팅할 수 있습니다. - RHEL for Edge VMDK
-
이 이미지를 사용하여 vSphere에 이미지를 로드하고 vSphere VM에서 이미지를 부팅합니다.
edge-vsphere
이미지는 Ignition 툴을 사용하여 부팅 프로세스의 초기 단계에서 이미지에 사용자 구성을 삽입합니다.
이미지 유형 | 파일 유형 | 네트워크 기반 배포에 적합 | 비 네트워크 기반 배포에 적합 |
---|---|---|---|
RHEL for Edge 커밋 |
| 있음 | 없음 |
RHEL for Edge Container |
| 없음 | 있음 |
RHEL for Edge 설치 프로그램 |
| 없음 | 있음 |
RHEL for Edge Raw Image | .raw.xz | 있음 | 있음 |
RHEL for Edge Simplified Installer |
| 있음 | 있음 |
RHEL for Edge AMI |
| 있음 | 있음 |
RHEL for Edge VMDK |
| 있음 | 있음 |
추가 리소스
1.3. 비 네트워크 기반 배포
RHEL 이미지 빌더를 사용하여 요구 사항에 맞게 유연한 RHEL rpm-ostree
이미지를 생성한 다음 Anaconda를 사용하여 환경에 배포합니다.
composer-cli
툴의 명령줄 인터페이스를 통해 RHEL 이미지 빌더에 액세스하거나 RHEL 웹 콘솔에서 그래픽 사용자 인터페이스를 사용할 수 있습니다.
네트워크 기반이 아닌 배포에서 RHEL for Edge 이미지를 구성 및 배포하려면 다음과 같은 상위 수준 단계를 수행해야 합니다.
- RHEL 시스템 설치 및 등록
- RHEL 이미지 빌더 설치
- RHEL 이미지 빌더를 사용하여 RHEL for Edge Container 이미지에 대한 사용자 지정으로 블루프린트를 생성
- RHEL 이미지 빌더에서 RHEL for Edge 블루프린트 가져오기
- OSTree 리포지토리로 커밋을 배포할 준비가 된 웹 서버와 함께 OCI 컨테이너에 포함된 RHEL for Edge 이미지를 생성합니다.
- RHEL for Edge Container 이미지 파일 다운로드
- RHEL for Edge Container 커밋을 위해 리포지토리를 제공하는 컨테이너 배포
- RHEL 이미지 빌더를 사용하여 RHEL for Edge 설치 프로그램 이미지에 대한 다른 블루프린트 생성
- RHEL for Edge Container 이미지가 포함된 실행 중인 컨테이너에서 커밋을 가져오도록 구성된 RHEL for Edge 설치 관리자 이미지 생성
- RHEL for Edge 설치 관리자 이미지 다운로드
- 설치 실행
다음 다이어그램은 RHEL for Edge 이미지 비 네트워크 배포 워크플로를 나타냅니다.
그림 1.1. 네트워크 이외의 환경에서 RHEL for Edge 배포
1.4. 네트워크 기반 배포
RHEL 이미지 빌더를 사용하여 요구 사항에 맞게 유연한 RHEL rpm-ostree
이미지를 생성한 다음 Anaconda를 사용하여 환경에 배포합니다. RHEL 이미지 빌더는 배포 설정의 세부 정보를 자동으로 식별하고 이미지 출력을 .tar
파일로 edge-commit
로 생성합니다.
composer-cli
툴의 명령줄 인터페이스를 통해 RHEL 이미지 빌더에 액세스하거나 RHEL 웹 콘솔에서 그래픽 사용자 인터페이스를 사용할 수 있습니다.
다음 고급 단계를 수행하여 RHEL for Edge 이미지를 작성하고 배포할 수 있습니다.
참여 중인 설치의 경우
- RHEL 시스템 설치 및 등록
- RHEL 이미지 빌더 설치
- RHEL 이미지 빌더를 사용하여 RHEL for Edge 이미지용 블루프린트 생성
- RHEL 이미지 빌더에서 RHEL for Edge 블루프린트 가져오기
-
엣지용 RHEL(
.tar
) 이미지 생성 - RHEL for Edge 이미지 파일 다운로드
- RHEL 이미지 빌더를 설치한 동일한 시스템에서 RHEL for Edge 커밋 콘텐츠를 제공하려는 웹 서버를 설치합니다. 자세한 내용은 NGINX 설정 및 구성을 참조하십시오.
-
RHEL for Edge Commit (
.tar
) 콘텐츠를 실행 중인 웹 서버에 추출합니다. - 실행 중인 웹 서버에서 OSTree 콘텐츠를 가져오는 Kickstart 파일을 만듭니다. OSTree 콘텐츠를 가져오도록 Kickstart를 수정하는 방법에 대한 자세한 내용은 RHEL for Edge 이미지 커밋 추출을참조하십시오.
- 에지 장치에서 RHEL 설치 프로그램 ISO를 부팅하고 Kickstart를 제공합니다.
무인 설치의 경우 RHEL 설치 ISO를 사용자 지정하고 Kickstart 파일을 여기에 포함할 수 있습니다.
다음 다이어그램은 RHEL for Edge 네트워크 이미지 배포 워크플로를 나타냅니다.
그림 1.2. 네트워크 기반 환경에서 RHEL for Edge 배포
1.5. RHEL RPM 이미지와 RHEL for Edge 이미지 간의 차이점
기존 패키지 기반 RPM 형식으로 RHEL 시스템 이미지를 생성하고 Edge용 RHEL(rpm-ostree
) 이미지로도 생성할 수 있습니다.
기존 패키지 기반 RPM을 사용하여 기존 데이터 센터에 RHEL을 배포할 수 있습니다. 그러나 RHEL for Edge 이미지를 사용하면 기존 데이터 센터 이외의 서버에 RHEL을 배포할 수 있습니다. 이러한 서버에는 데이터가 생성되는 소스인 에지 서버인 소스에 가장 근접하게 많은 양의 데이터를 처리하는 시스템이 포함됩니다.
RHEL for Edge(rpm-ostree
) 이미지는 패키지 관리자가 아닙니다. 개별 파일이 아닌 부팅 가능한 전체 파일 시스템만 지원합니다. 이러한 이미지에는 이러한 파일이 생성되는 방법 또는 원본과 관련된 항목과 같은 개별 파일에 대한 정보가 없습니다.
rpm-ostree
이미지에는 추가 애플리케이션을 /var
디렉터리에 설치하려면 별도의 메커니즘인 패키지 관리자가 필요합니다. 이를 통해 rpm-ostree
이미지는 /var
및 /etc
디렉터리의 상태를 유지하면서 운영 체제를 변경하지 않고 유지합니다. 원자 업데이트를 통해 롤백 및 업데이트의 백그라운드 스테이징이 가능합니다.
다음 표를 참조하여 RHEL for Edge 이미지의 패키지 기반 RHEL RPM 이미지와 다른지 확인하십시오.
키 속성 | RHEL RPM 이미지 | RHEL for Edge 이미지 |
| 패키지를 로컬로 어셈블하여 이미지를 구성할 수 있습니다. | 패키지는 시스템에 설치할 수 있는 OSTree로 어셈블됩니다. |
|
|
|
| 패키지에 DNF 리포지터리가 포함되어 있습니다 | 패키지에는 OSTree 원격 리포지토리가 포함되어 있습니다. |
| 읽기 쓰기 |
읽기 전용 ( |
|
이미지가 아닌 |
|
2장. RHEL 이미지 빌더 설정
RHEL 이미지 빌더를 사용하여 에지 이미지에 대해 사용자 지정 RHEL을 생성합니다. RHEL 시스템에 RHEL 이미지 빌더를 설치한 후 RHEL 이미지 빌더를 RHEL 웹 콘솔에서 애플리케이션으로 사용할 수 있습니다. composer-cli
툴의 명령줄 인터페이스를 통해 RHEL 이미지 빌더에 액세스할 수도 있습니다.
가상 머신에 RHEL 이미지 빌더를 설치하는 것이 좋습니다.
2.1. 이미지 빌더 시스템 요구 사항
RHEL 이미지 빌더가 실행되는 환경(예: 가상 머신)은 다음 표에 나열된 요구 사항을 충족해야 합니다.
컨테이너 내에서 RHEL 이미지 빌더를 실행하는 것은 지원되지 않습니다.
매개변수 | 최소 필수 값 |
시스템 유형 | 전용 가상 머신 |
프로세서 | 2개의 코어 |
메모리 | 4GiB |
디스크 공간 | 20GiB |
액세스 권한 | 관리자 수준(root) |
네트워크 | 인터넷 연결 |
20GiB 디스크 공간 요구 사항은 호스트에 RHEL 이미지 빌더를 설치하고 실행하는 데 충분합니다. 이미지 빌드를 빌드하고 배포하려면 추가 전용 디스크 공간을 할당해야 합니다.
2.2. RHEL 이미지 빌더 설치
전용 가상 머신에 RHEL 이미지 빌더를 설치하려면 다음 단계를 따르십시오.
사전 요구 사항
- 가상 시스템이 생성되어 전원이 켜집니다.
- RHEL을 설치하고 RHSM 또는 Red Hat Satellite에 등록되어 있습니다.
-
BaseOS
및AppStream
리포지토리를 활성화하여 RHEL 이미지 빌더 패키지를 설치할 수 있습니다.
절차
가상 시스템에 다음 패키지를 설치합니다.
- osbuild-composer
- composer-cli
- cockpit-composer
- bash-completion
- firewalld
# dnf install osbuild-composer composer-cli cockpit-composer bash-completion firewalld
RHEL 이미지 빌더는 RHEL 웹 콘솔에 애플리케이션으로 설치됩니다.
- 가상 머신 재부팅
웹 콘솔에 대한 액세스를 허용하도록 시스템 방화벽을 구성합니다.
# firewall-cmd --add-service=cockpit && firewall-cmd --add-service=cockpit --permanent
RHEL 이미지 빌더를 활성화합니다.
# systemctl enable osbuild-composer.socket cockpit.socket --now
osbuild-composer 및 cockpit 서비스는 첫 번째 액세스 시 자동으로 시작됩니다.
재부팅하지 않고
composer-cli
명령의 자동 완성 기능이 즉시 작동하도록 쉘 설정 스크립트를 로드합니다.$ source /etc/bash_completion.d/composer-cli
추가 리소스
3장. RHEL 이미지 빌더 리포지토리 구성
RHEL 이미지 빌더를 사용하려면 리포지토리가 구성되어 있는지 확인해야 합니다. RHEL 이미지 빌더에서 다음 유형의 리포지토리를 사용할 수 있습니다.
- 공식 리포지토리 덮어쓰기
- Red Hat CDN(Content Delivery Network) 공식 리포지토리(예: 네트워크의 사용자 지정 미러) 이외의 위치에서 기본 시스템 RPM을 다운로드하려는 경우 이를 사용합니다. 공식 리포지토리 덮어쓰기를 사용하면 기본 리포지토리가 비활성화되고 사용자 지정 미러에 필요한 모든 패키지가 포함되어야 합니다.
- 사용자 정의 타사 리포지토리
- 이를 사용하여 공식 RHEL 리포지토리에서 사용할 수 없는 패키지를 포함합니다.
3.1. RHEL 이미지 빌더에 사용자 지정 타사 리포지토리 추가
사용자 지정 타사 소스를 리포지토리에 추가하고 composer-cli
를 사용하여 이러한 리포지토리를 관리할 수 있습니다.
사전 요구 사항
- 사용자 지정 타사 리포지토리의 URL이 있습니다.
절차
/root/repo.toml
와 같은 리포지토리 소스 파일을 만듭니다. 예를 들어 다음과 같습니다.id = "k8s" name = "Kubernetes" type = "yum-baseurl" url = "https://server.example.com/repos/company_internal_packages/" check_gpg = false check_ssl = false system = false
type
필드에는yum-baseurl
,yum-mirrorlist
,yum-metalink
라는 유효한 값을 사용할 수 있습니다.- 파일을 TOML 형식으로 저장합니다.
RHEL 이미지 빌더에 새 타사 소스를 추가합니다.
$ composer-cli sources add <file-name>.toml
검증
새 소스가 성공적으로 추가되었는지 확인합니다.
$ composer-cli sources list
새 소스 콘텐츠를 확인합니다.
$ composer-cli sources info <source_id>
3.2. RHEL 이미지 빌더에 특정 배포판을 사용하여 타사 리포지토리 추가
선택 사항 필드 distro
를 사용하여 사용자 지정 타사 소스 파일에서 배포 목록을 지정할 수 있습니다. 리포지토리 파일은 이미지 빌드 중에 종속성을 확인하는 동안 배포 문자열 목록을 사용합니다.
rhel-9
를 지정하는 모든 요청에서는 이 소스를 사용합니다. 예를 들어 패키지를 나열하고 rhel-9
를 지정하는 경우 이 소스가 포함됩니다. 그러나 호스트 배포에 대한 패키지를 나열해도 이 소스는 포함되지 않습니다.
사전 요구 사항
- 사용자 지정 타사 리포지토리의 URL이 있습니다.
- 지정할 배포 목록이 있습니다.
절차
/root/repo.toml
와 같은 리포지토리 소스 파일을 만듭니다. 예를 들어 배포를 지정하려면 다음을 수행합니다.check_gpg = true check_ssl = true distros = ["rhel-9"] id = "rh9-local" name = "packages for RHEL" system = false type = "yum-baseurl" url = "https://local/repos/rhel9/projectrepo/"
- 파일을 TOML 형식으로 저장합니다.
RHEL 이미지 빌더에 새 타사 소스를 추가합니다.
$ composer-cli sources add <file-name>.toml
검증
새 소스가 성공적으로 추가되었는지 확인합니다.
$ composer-cli sources list
새 소스 콘텐츠를 확인합니다.
$ composer-cli sources info <source_id>
3.3. GPG를 사용하여 리포지토리 메타데이터 확인
손상된 패키지를 감지하고 방지하려면 DNF 패키지 관리자를 사용하여 RPM 패키지에서 GNU Privacy Guard(GPG) 서명을 확인하고, 리포지토리 메타데이터가 GPG 키로 서명되었는지 확인할 수 있습니다.
키 URL로 gpgkeys
필드를 설정하여 https
를 통해 확인할 gpgkey
를 입력할 수 있습니다. 또는 보안을 개선하기 위해 전체 키를 gpgkeys
필드에 삽입하여 URL에서 키를 가져오는 대신 직접 가져올 수도 있습니다.
사전 요구 사항
- 리포지토리로 사용할 디렉터리가 존재하고 패키지가 포함되어 있습니다.
절차
리포지토리를 생성할 폴더에 액세스합니다.
$ cd repo/
createrepo_c
를 실행하여 RPM 패키지에서 리포지토리를 생성합니다.$ createrepo_c .
repodata가 있는 디렉터리에 액세스합니다.
$ cd repodata/
repomd.xml
파일에 서명합니다.$ gpg -u <_gpg-key-email_> --yes --detach-sign --armor /srv/repo/example/repomd.xml
리포지토리에서 GPG 서명 검사를 활성화하려면 다음을 수행합니다.
-
리포지토리 소스에서
check_repogpg = true
를 설정합니다. 검사를 수행할
gpgkey
를 입력합니다.https
를 통해 키를 사용할 수 있는 경우 키 URL을 사용하여gpgkeys
필드를 설정합니다. 필요한 만큼 URL 키를 추가할 수 있습니다.다음은 예제입니다.
check_gpg = true check_ssl = true id = "signed local packages" name = "repository_name" type = "yum-baseurl" url = "https://local/repos/projectrepo/" check_repogpg = true gpgkeys=["https://local/keys/repokey.pub"]
또는
gpgkeys
필드에 직접 GPG 키를 추가합니다. 예를 들면 다음과 같습니다.check_gpg = true check_ssl = true check_repogpg id = "custom-local" name = "signed local packages" type = "yum-baseurl" url = "https://local/repos/projectrepo/" gpgkeys=["https://remote/keys/other-repokey.pub", '''-----BEGIN PGP PUBLIC KEY BLOCK----- … -----END PGP PUBLIC KEY BLOCK-----''']
테스트에서 서명을 찾을 수 없는 경우 GPG 툴에 다음과 유사한 오류가 표시됩니다.
$ GPG verification is enabled, but GPG signature is not available. This may be an error or the repository does not support GPG verification: Status code: 404 for http://repo-server/rhel/repodata/repomd.xml.asc (IP: 192.168.1.3)
서명이 유효하지 않은 경우 GPG 툴에 다음과 유사한 오류가 표시됩니다.
repomd.xml GPG signature verification error: Bad GPG signature
-
리포지토리 소스에서
검증
리포지토리의 서명을 수동으로 테스트합니다.
$ gpg --verify /srv/repo/example/repomd.xml.asc
3.4. RHEL 이미지 빌더 공식 리포지토리 덮어쓰기
RHEL 이미지 빌더 osbuild-composer
백엔드는 /etc/yum.repos.d/
디렉터리에 있는 시스템 리포지토리를 상속하지 않습니다. 대신 /usr/share/osbuild-composer/repositories
디렉터리에 정의된 고유한 공식 리포지토리 세트가 있습니다. 여기에는 추가 소프트웨어를 설치하거나 이미 설치된 프로그램을 최신 버전으로 업데이트하는 기본 시스템 RPM이 포함된 Red Hat 공식 리포지토리가 포함됩니다. 공식 리포지토리를 재정의하려면 /etc/osbuild-composer/repositories/
에서 재정의를 정의해야 합니다. 이 디렉터리는 사용자 정의 덮어쓰기를 위한 것이며 여기에 있는 파일은 /usr/share/osbuild-composer/repositories/
디렉터리에 있는 파일보다 우선합니다.
구성 파일은 /etc/yum.repos.d/
에 있는 파일에서 알려진 일반적인 DNF 리포지터리 형식이 아닙니다. 대신 JSON 파일입니다.
3.5. 시스템 리포지토리 덮어쓰기
/etc/osbuild-composer/repositories
디렉터리에서 RHEL 이미지 빌더에 대한 자체 리포지토리 덮어쓰기를 구성할 수 있습니다.
사전 요구 사항
- 호스트 시스템에서 액세스할 수 있는 사용자 지정 리포지토리가 있습니다.
절차
리포지토리 덮어쓰기를 저장할
/etc/osbuild-composer/repositories/
디렉터리를 만듭니다.$ sudo mkdir -p /etc/osbuild-composer/repositories
RHEL 버전에 해당하는 이름을 사용하여 JSON 파일을 생성합니다. 또는
/usr/share/osbuild-composer/
에서 배포할 파일을 복사하고 해당 콘텐츠를 수정할 수 있습니다.RHEL 9.3의 경우
/etc/osbuild-composer/repositories/rhel-93.json
을 사용합니다.JSON 파일에 다음 구조를 추가합니다. 문자열 형식으로 다음 속성 중 하나만 지정합니다.
-
baseurl
- 리포지토리의 기본 URL입니다. -
metalink
- 유효한 미러 리포지토리 목록이 포함된 metalink 파일의 URL입니다. mirrorlist
- 유효한 미러 저장소 목록이 포함된 미러 목록 파일의 URL입니다. 나머지 필드(예:gpgkey
) 및metadata_expire
는 선택 사항입니다.예를 들어 다음과 같습니다.
{ "x86_64": [ { "name": "baseos", "baseurl": "http://mirror.example.com/composes/released/RHEL-9/9.0/BaseOS/x86_64/os/", "gpgkey": "-----BEGIN PGP PUBLIC KEY BLOCK-----\n\n (…)", "check_gpg": true } ] }
또는
rhel-version.json
을 RHEL 버전으로 교체하여 배포에 대한 JSON 파일을 복사할 수 있습니다(예: rhel-9.json).$ cp /usr/share/osbuild-composer/repositories/rhel-version.json /etc/osbuild-composer/repositories/
-
선택 사항: JSON 파일을 확인합니다.
$ json_verify /etc/osbuild-composer/repositories/<file>.json
rhel-9.json
파일에서baseurl
경로를 편집하여 저장합니다. 예를 들어 다음과 같습니다.$ /etc/osbuild-composer/repositories/rhel-version.json
osbuild-composer.service
를 다시 시작하십시오.$ sudo systemctl restart osbuild-composer.service
검증
리포지토리가 올바른 URL을 가리키는지 확인합니다.
$ cat /etc/yum.repos.d/redhat.repo
리포지토리가
/etc/yum.repos.d/redhat.repo
파일에서 복사되는 올바른 URL을 가리키는 것을 확인할 수 있습니다.
추가 리소스
-
리포지토리에서 사용할 수 있는 최신 RPM 버전은
osbuild-composer
에 표시되지 않습니다. (Red Hat Knowledgebase)
3.6. 서브스크립션이 필요한 시스템 리포지토리 덮어쓰기
/etc/yum.repos.d/redhat.repo
파일에 정의된 시스템 서브스크립션을 사용하도록 osbuild-composer
서비스를 설정할 수 있습니다. osbuild-composer
에서 시스템 서브스크립션을 사용하려면 다음 세부 정보가 있는 리포지토리 덮어쓰기를 정의합니다.
-
/etc/yum.repos.d/redhat.repo
에 정의된 리포지토리와 동일한baseurl
입니다. JSON 오브젝트에 정의된
"rhsm": true
의 값입니다.참고osbuild-composer
는/etc/yum.repos.d/
에 정의된 리포지토리를 자동으로 사용하지 않습니다. 수동으로 시스템 리포지토리 덮어쓰기로 지정하거나composer-cli
를 사용하여 추가소스로
지정해야 합니다. "BaseOS" 및 "AppStream" 리포지토리는 일반적으로 시스템 리포지토리 덮어쓰기를 사용하지만 다른 모든 리포지토리는composer-cli
소스를 사용합니다.
사전 요구 사항
-
시스템에
/etc/yum.repos.d/redhat.repo
에 정의된 서브스크립션이 있습니다. - 리포지토리 덮어쓰기가 생성되어 있습니다. 시스템 리포지토리 덮어쓰기를 참조하십시오.
절차
/etc/yum.repos.d/redhat.repo
파일에서baseurl
을 가져옵니다.# cat /etc/yum.repos.d/redhat.repo [AppStream] name = AppStream mirror example baseurl = https://mirror.example.com/RHEL-9/9.0/AppStream/x86_64/os/ enabled = 1 gpgcheck = 0 sslverify = 1 sslcacert = /etc/pki/ca1/ca.crt sslclientkey = /etc/pki/ca1/client.key sslclientcert = /etc/pki/ca1/client.crt metadata_expire = 86400 enabled_metadata = 0
동일한
baseurl
을 사용하고rhsm
을 true로 설정하도록 리포지토리 덮어쓰기를 구성합니다.{ "x86_64": [ { "name": "AppStream mirror example", "baseurl": "https://mirror.example.com/RHEL-9/9.0/AppStream/x86_64/os/", "gpgkey": "-----BEGIN PGP PUBLIC KEY BLOCK-----\n\n (…)", "check_gpg": true, "rhsm": true } ] }
osbuild-composer.service
를 다시 시작하십시오.$ sudo systemctl restart osbuild-composer.service
추가 리소스
- 호스트가 Satellite 6에 등록된 경우 RHEL 이미지 빌더에서 CDN 리포지토리 사용 (Red Hat Knowledgebase)
3.7. Satellite CV를 콘텐츠 소스로 구성 및 사용
Satellite의 콘텐츠 뷰(CV)를 리포지토리로 사용하여 RHEL 이미지 빌더로 이미지를 빌드할 수 있습니다. 이를 위해 Satellite에 등록된 호스트에서 Red Hat CDN(Content Delivery Network) 공식 리포지토리 대신 Satellite 리포지토리에서 검색할 수 있도록 리포지토리 참조를 수동으로 구성합니다.
사전 요구 사항
- Satellite 6에 등록된 호스트에서 RHEL 이미지 빌더를 사용하고 있습니다.
절차
현재 구성된 리포지토리에서 리포지토리 URL을 찾습니다.
$ sudo yum -v repolist rhel-8-for-x86_64-baseos-rpms | grep repo-baseurl Repo-baseurl :
다음 출력은 예제입니다.
https://satellite6.example.com/pulp/content/YourOrg/YourEnv/YourCV/content/dist/rhel8/8/x86_64/baseos/os
하드 코딩된 리포지토리를 Satellite Server로 수정합니다.
0755
권한이 있는 리포지토리 디렉터리를 생성합니다.$ sudo mkdir -pvm 0755 /etc/osbuild-composer/repositories
/usr/share/osbuild-composer/repositories/*.json
의 콘텐츠를 생성한 디렉터리로 복사합니다.$ sudo cp /usr/share/osbuild-composer/repositories/*.json /etc/osbuild-composer/repositories/
/content/dist/*
행을 통해 Satellite URL 및 파일 콘텐츠를 업데이트합니다.$ sudo sed -i -e 's|cdn.redhat.com|satellite6.example.com/pulp/content/YourOrg/YourEnv/YourCV|' /etc/osbuild-composer/repositories/*.json
구성이 올바르게 교체되었는지 확인합니다.
$ sudo vi /etc/osbuild-composer/repositories/rhel-8.json
서비스를 다시 시작하십시오.
$ sudo systemctl restart osbuild-worker@1.service osbuild-composer.service
- Red Hat 이미지 빌더 구성에서 필요한 시스템 리포지토리를 재정의하고 Satellite 리포지토리의 URL을 baseurl로 사용합니다. 시스템 리포지토리 덮어쓰기를 참조하십시오.
추가 리소스
- Satellite에 여러 사용자 지정 리포지토리가 정의되면 Composer RHEL 이미지 빌더가 실패합니다 (Red Hat Knowledgebase)
3.8. RHEL 이미지 빌더에서 이미지를 빌드하는 데 Satellite CV를 리포지토리로 사용
Satellite의 content views(CV)를 리포지토리로 사용하여 사용자 정의 이미지를 빌드하도록 RHEL 이미지 빌더를 구성합니다.
사전 요구 사항
- RHEL 웹 콘솔과 Satellite를 통합했습니다. Satellite에서 RHEL 웹 콘솔 활성화를참조하십시오.
절차
- Satellite 웹 UI에서 콘텐츠 > 제품으로 이동하여 제품을 선택하고 사용할 리포지토리를 클릭합니다.
- 게시됨 필드에서 보안 URL(HTTPS)을 검색하고 복사합니다.
- Red Hat 이미지 빌더 리포지토리의 baseurl으로 복사한 URL을 사용합니다. RHEL 이미지 빌더에 사용자 지정 타사 리포지토리 추가 를 참조하십시오.
다음 단계
- 이미지를 빌드합니다. 웹 콘솔 인터페이스에서 RHEL 이미지 빌더를 사용하여 시스템 이미지 생성을 참조하십시오.
4장. RHEL 웹 콘솔에서 이미지 빌더를 사용하여 에지 이미지 작성
RHEL 이미지 빌더를 사용하여 사용자 지정 RHEL for Edge 이미지(OSTree 커밋)를 생성합니다.
RHEL 이미지 빌더에 액세스하고 사용자 지정 RHEL for Edge 이미지를 생성하려면 RHEL 웹 콘솔 인터페이스 또는 명령줄 인터페이스를 사용할 수 있습니다.
다음 고급 단계를 수행하여 RHEL 웹 콘솔에서 RHEL 이미지 빌더를 사용하여 RHEL for Edge 이미지를 구성할 수 있습니다.
- RHEL 웹 콘솔에서 RHEL 이미지 빌더에 액세스
- RHEL for Edge 이미지에 대한 블루프린트를 생성합니다.
RHEL for Edge 이미지를 만듭니다. 다음 이미지를 생성할 수 있습니다.
- 엣지 애플리케이션용 RHEL 이미지입니다.
- 엣지 컨테이너 이미지용 RHEL.
- RHEL for Edge Installer 이미지.
- RHEL for Edge 이미지 다운로드
4.1. RHEL 웹 콘솔에서 RHEL 이미지 빌더에 액세스
RHEL 웹 콘솔에서 RHEL 이미지 빌더에 액세스하려면 다음 사전 요구 사항을 충족했는지 확인한 다음 절차를 따르십시오.
사전 요구 사항
- RHEL 시스템이 설치되어 있어야 합니다.
- 시스템에 대한 관리 권한이 있습니다.
- RHEL 시스템을 RHSM(Red Hat Subscription Manager) 또는 Red Hat Satellite Server에 가입했습니다.
- 시스템 전원이 켜져 있고 네트워크를 통해 액세스할 수 있습니다.
- 시스템에 RHEL 이미지 빌더를 설치했습니다.
절차
- RHEL 시스템에서 웹 브라우저에서 https://localhost:9090/에 액세스합니다.
- RHEL 이미지 빌더에 원격으로 액세스하는 방법에 대한 자세한 내용은 RHEL 9 웹 콘솔을 사용하여 시스템 관리를 참조하십시오.
- 관리 사용자 계정을 사용하여 웹 콘솔에 로그인합니다.
- 웹 콘솔의 왼쪽 메뉴에서 을 클릭합니다.
오른쪽 창에서 RHEL 이미지 빌더 대시보드가 열립니다. 이제 RHEL for Edge 이미지에 대한 블루프린트를 생성할 수 있습니다.
4.2. 웹 콘솔에서 이미지 빌더를 사용하여 RHEL for Edge 이미지용 블루프린트 생성
RHEL 웹 콘솔에서 RHEL 이미지 빌더를 사용하여 RHEL for Edge 이미지에 대한 블루프린트를 생성하려면 다음 사전 요구 사항을 충족했는지 확인한 다음 절차를 따르십시오.
사전 요구 사항
- RHEL 시스템에서 RHEL 이미지 빌더 대시보드를 엽니다.
절차
RHEL 이미지 빌더 대시보드에서
을 클릭합니다.블루프린트 생성 대화 상자가 열립니다.
세부 정보
페이지에서 다음을 수행합니다.- 사용자 이름 및 선택적으로 해당 설명을 입력합니다. 을 클릭합니다.
선택 사항:
패키지
페이지에서 다음을 수행합니다.사용 가능한 패키지 검색에서 패키지
이름을 입력하고 > 버튼 클릭하여 C respectiven packages 필드로 이동합니다. 원하는 만큼 패키지를 검색하고 포함합니다. 을 클릭합니다.참고이러한 사용자 정의는 달리 지정하지 않는 한 모두 선택 사항입니다.
-
커널
페이지에서 커널 이름과 명령줄 인수를 입력합니다. -
파일 시스템
페이지에서자동 파티션 사용을
선택합니다. OSTree 이미지에는 읽기 전용과 같은 자체 마운트 규칙이 있으므로 OStree 시스템은 파일 시스템 사용자 지정을 지원하지 않습니다. 을 클릭합니다. 서비스
페이지에서 서비스를 활성화하거나 비활성화할 수 있습니다.- 활성화 또는 비활성화할 서비스 이름을 입력하거나 쉼표로, 공백으로 또는 키를 눌러 입력합니다. 을 클릭합니다.
방화벽
페이지에서 방화벽 설정을 설정합니다.-
포트
및 활성화 또는 비활성화하려는 방화벽 서비스를 입력합니다. - 버튼을 클릭하여 각 영역의 방화벽 규칙을 독립적으로 관리합니다. 을 클릭합니다.
-
사용자
페이지에서 단계에 따라 사용자를 추가합니다.- 클릭합니다.
-
사용자
이름
,암호
,SSH 키
를 입력합니다.서버 관리자
확인란을 클릭하여 사용자를 권한 있는 사용자로 표시할 수도 있습니다. 을 클릭합니다.
그룹
페이지에서 다음 단계를 완료하여 그룹을 추가합니다.-
그룹 이름과
를 입력합니다. 더 많은 그룹을 추가할 수 있습니다. 을 클릭합니다.그룹
ID
-
SSH 키 페이지에서 키
를 추가합니다.- SSH 키를 입력합니다.
-
사용자
를 입력합니다. 을 클릭합니다.
Timezone
페이지에서 시간대 설정을 설정합니다.Timezone
필드에 시스템 이미지에 추가할 시간대를 입력합니다. 예를 들어 다음 시간대 형식을 추가합니다. "US/E disastern".시간대를 설정하지 않으면 시스템은 UTC(Universal Time), Coordinated(UTC)를 기본값으로 사용합니다.
-
NTP
서버를 입력합니다. 을 클릭합니다.
로컬
페이지에서 다음 단계를 완료합니다.-
10.0.0.1
검색
필드에 시스템 이미지에 추가할 패키지 이름을 입력합니다. 예: [ "en_US.UTF-8"]. -
Languages
검색 필드에 시스템 이미지에 추가할 패키지 이름을 입력합니다. 예: "us". 을 클릭합니다.
-
10.0.0.1
기타
페이지에서 다음 단계를 완료합니다.-
Hostname
필드에 시스템 이미지에 추가할 호스트 이름을 입력합니다. 호스트 이름을 추가하지 않으면 운영 체제에서 호스트 이름을 결정합니다. -
Simplifier 설치 프로그램 이미지에만 필요합니다.
설치 장치
필드에 시스템 이미지에 유효한 노드를 입력합니다. 예:dev/sda
. 을 클릭합니다.
-
FIDO 이미지를 빌드할 때만 필수 사항:
FIDO 장치 온보딩
페이지에서 다음 단계를 완료하십시오.Manufacturing server URL
필드에 다음 정보를 입력합니다.-
DIUN 공개 키 비보안 필드에 비보안
공개 키를 입력합니다. -
DIUN 공개 키 해시
필드에 공개 키 해시를 입력합니다. -
DIUN 공개 키 루트 인증서
필드에 공개 키 루트 인증서를 입력합니다. 을 클릭합니다.
-
OpenSCAP
페이지에서 다음 단계를 완료합니다.-
데이터 스트림
필드에 시스템 이미지에 추가할datastream
수정 명령을 입력합니다. -
Profile ID
필드에 시스템 이미지에 추가할profile_id
보안 프로필을 입력합니다. 을 클릭합니다.
-
Ignition 이미지를 빌드할 때만 필수 항목입니다.
Ignition
페이지에서 다음 단계를 완료합니다.-
Firstboot URL
필드에 시스템 이미지에 추가할 패키지 이름을 입력합니다. -
VMDK
데이터
필드에서 파일을 드래그하거나 업로드합니다. 을 클릭합니다.
-
-
.
검토
페이지에서 청사진에 대한 세부 사항을 검토합니다. 을 클릭합니다.
RHEL 이미지 빌더 보기가 열리고 기존 블루프린트가 나열됩니다.
4.3. 웹 콘솔에서 이미지 빌더를 사용하여 RHEL for Edge 커밋 이미지 생성
RHEL 웹 콘솔에서 RHEL 이미지 빌더를 사용하여 "RHEL for Edge 커밋" 이미지를 생성할 수 있습니다. "RHEL for Edge Commit (.tar)" 이미지 유형에는 전체 운영 체제가 포함되어 있지만 직접 부팅할 수는 없습니다. ECDHE 이미지 유형을 부팅하려면 실행 중인 컨테이너에 배포해야 합니다.
사전 요구 사항
- RHEL 시스템에서 RHEL 이미지 빌더 대시보드에 액세스했습니다.
절차
- RHEL 이미지 빌더 대시보드에서 클릭합니다.
이미지 출력 페이지에서 다음 단계를 수행합니다.
- Select a Blueprint dropdown 메뉴에서 사용할 Blueprint를 선택합니다.
- 이미지 출력 유형 드롭다운 목록에서 "RHEL for Edge Commit (.tar)" 을 선택합니다.
- 을 클릭합니다.
OSTree 설정 페이지에서 다음을 입력합니다.
- 리포지토리 URL: 이미지에 포함할 커밋의 OSTree 리포지토리에 대한 URL을 지정합니다. 예: http://10.0.2.2:8080/repo/.
- parent commit: 이전 커밋을 지정하거나 현재 커밋이 없는 경우 비워 둡니다.
-
Ref 텍스트 상자에서 커밋을 생성할 위치에 대한 참조 경로를 지정합니다. 기본적으로 웹 콘솔은
rhel/9/$ARCH/edge
를 지정합니다. "$ARCH" 값은 호스트 시스템에 의해 결정됩니다. 을 클릭합니다.
검토 페이지에서 사용자 정의를 확인하고 클릭합니다.
RHEL 이미지 빌더는 사용자가 생성한 블루프린트에 대한 RHEL for Edge 커밋 이미지를 생성하기 시작합니다.
참고이미지 생성 프로세스를 완료하는 데 최대 20분이 걸립니다.
검증
RHEL에서 에지 Commit 이미지 생성 진행 상황을 확인하려면 다음을 수행합니다.
- 탭을 클릭합니다.
이미지 생성 프로세스가 완료되면 결과 "RHEL for Edge Commit(.tar)" 이미지를 다운로드할 수 있습니다.
추가 리소스
4.4. RHEL 웹 콘솔에서 RHEL 이미지 빌더를 사용하여 RHEL for Edge 컨테이너 이미지 생성
" .tar"을 선택하여 Edge 이미지에 RHEL을 생성할 수 있습니다. 에지 컨테이너(.tar) 이미지 유형의 RHEL 은 OSTree 커밋을 생성하여 웹 서버가 있는 OCI 컨테이너에 포함합니다. 컨테이너를 시작하면 웹 서버에서 OSTree 리포지토리로 커밋을 제공합니다.
다음 절차의 단계에 따라 RHEL 웹 콘솔에서 이미지 빌더를 사용하여 에지 컨테이너 이미지에 대한 RHEL을 생성합니다.
사전 요구 사항
- RHEL 시스템에서 RHEL 이미지 빌더 대시보드에 액세스했습니다.
- 네, 네게 만들었어.
절차
- RHEL 이미지 빌더 대시보드에서 클릭합니다.
- 이미지 출력 페이지에서 다음 단계를 수행합니다.
Select a Blueprint dropdown 메뉴에서 사용할 Blueprint를 선택합니다.
- 이미지 출력 유형 드롭다운 목록에서 "RHEL for Edge Container (.tar)" 를 선택합니다.
- 을 클릭합니다.
OSTree 페이지에서 다음을 입력합니다.
리포지토리 URL: 이미지에 포함할 커밋의 OSTree 리포지토리에 대한 URL을 지정합니다. 예: http://10.0.2.2:8080/repo/. 기본적으로 에지 컨테이너 이미지에 대한 RHEL의 리포지토리 폴더는 "/repo"입니다.
사용할 올바른 URL을 찾으려면 실행 중인 컨테이너에 액세스하여
nginx.conf
파일을 확인합니다. 사용할 URL을 찾으려면 실행 중인 컨테이너에 액세스하여nginx.conf
파일을 확인합니다.nginx.conf
파일 내에서/repo/
폴더 정보를 검색할루트
디렉터리 항목을 찾습니다. RHEL 이미지 빌더를 사용하여 RHEL for Edge 컨테이너 이미지(.tar)
를 생성할 때 리포지토리 URL을 지정하지 않으면nginx.conf
파일에 기본/repo/
항목이 생성됩니다.- parent commit: 이전 커밋을 지정하거나 현재 커밋이 없는 경우 비워 둡니다.
-
Ref 텍스트 상자에서 커밋을 생성할 위치에 대한 참조 경로를 지정합니다. 기본적으로 웹 콘솔은
rhel/9/$ARCH/edge
를 지정합니다. "$ARCH" 값은 호스트 시스템에 의해 결정됩니다. 을 클릭합니다.
- 검토 페이지에서 사용자 정의를 확인합니다. .
RHEL 이미지 빌더는 사용자가 생성한 블루프린트에 대한 RHEL for Edge 컨테이너 이미지를 생성하기 시작합니다.
참고이미지 생성 프로세스를 완료하는 데 최대 20분이 걸립니다.
검증
RHEL에서 에지 컨테이너 이미지 생성 진행 상황을 확인하려면 다음을 수행합니다.
- 탭을 클릭합니다.
이미지 생성 프로세스가 완료되면 결과 "RHEL for Edge Container (.tar)" 이미지를 다운로드할 수 있습니다.
추가 리소스
4.5. RHEL 웹 콘솔에서 이미지 빌더를 사용하여 RHEL for Edge 설치 프로그램 이미지 생성
RHEL for Edge Installer(.iso)
를 선택하여 RHEL for Edge 설치 프로그램 이미지를 생성할 수 있습니다. RHEL for Edge Installer(.iso)
이미지 유형은 RHEL for Edge 컨테이너 (.tar)
에서 제공하는 실행 중인 컨테이너에서 OSTree 커밋을 가져오고 포함된 OSTree 커밋을 사용하도록 구성된 Kickstart 파일로 설치 가능한 부팅 ISO 이미지를 생성합니다.
다음 절차의 단계에 따라 RHEL 웹 콘솔에서 이미지 빌더를 사용하여 에지 이미지에 대한 RHEL을 생성합니다.
사전 요구 사항
- RHEL 시스템에서 이미지 빌더 대시보드에 액세스했습니다.
- 사용자가 만든 것입니다.
- 에지 컨테이너 이미지를 위한 RHEL을 생성하여 실행 중인 컨테이너에 로드했습니다. 비 네트워크 기반 배포의 경우 에지 컨테이너 이미지의 RHEL 생성을 참조하십시오.
절차
- RHEL 이미지 빌더 대시보드에서 클릭합니다.
이미지 출력 페이지에서 다음 단계를 수행합니다.
- Select a Blueprint dropdown 메뉴에서 사용할 Blueprint를 선택합니다.
-
이미지 출력 유형 드롭다운 목록에서 Edge Installer(
.iso
) 이미지에 대해 RHEL 을 선택합니다. - 을 클릭합니다.
OSTree 설정 페이지에서 다음을 입력합니다.
- 리포지토리 URL: 이미지에 포함할 커밋의 OSTree 리포지토리에 대한 URL을 지정합니다. 예: http://10.0.2.2:8080/repo/.
-
Ref 텍스트 상자에서 커밋을 생성할 위치에 대한 참조 경로를 지정합니다. 기본적으로 웹 콘솔은
rhel/9/$ARCH/edge
를 지정합니다. "$ARCH" 값은 호스트 시스템에 의해 결정됩니다. 을 클릭합니다.
- 검토 페이지에서 사용자 정의를 확인합니다. .
RHEL 이미지 빌더는 사용자가 생성한 블루프린트에 대한 RHEL for Edge 설치 프로그램 이미지를 생성하기 시작합니다.
참고이미지 생성 프로세스를 완료하는 데 최대 20분이 걸립니다.
검증
RHEL에서 에지 설치 프로그램 이미지 생성 진행 상황을 확인하려면 다음을 수행합니다.
- 탭을 클릭합니다.
이미지 생성 프로세스가 완료되면 결과 RHEL for Edge Installer(.iso)
이미지를 다운로드하고 ISO 이미지를 장치로 부팅할 수 있습니다.
추가 리소스
4.6. 에지 이미지 RHEL 다운로드
RHEL 이미지 빌더를 사용하여 RHEL for Edge 이미지를 성공적으로 생성한 후 로컬 호스트에서 이미지를 다운로드합니다.
절차
이미지를 다운로드하려면 다음을 수행합니다.
추가 옵션 메뉴에서 클릭합니다.
RHEL 이미지 빌더 툴은 기본 다운로드 위치에서 파일을 다운로드합니다.
다운로드한 파일은 에지 Commit 및 에지 컨테이너 이미지용 RHEL용 RHEL용 OSTree 리포지토리가 있는 .tar
파일 또는 OSTree 리포지토리가 있는 RHEL용 RHEL용 .iso
파일로 구성됩니다. 이 리포지토리에는 리포지토리 콘텐츠에 대한 정보 메타데이터가 포함된 커밋 및 json
파일이 포함되어 있습니다.
4.7. 추가 리소스
5장. 이미지 빌더 명령줄을 사용하여 에지 이미지 작성
이미지 빌더를 사용하여 사용자 지정 RHEL for Edge 이미지(OSTree 커밋)를 생성할 수 있습니다.
이미지 빌더에 액세스하고 사용자 지정 RHEL for Edge 이미지를 생성하려면 RHEL 웹 콘솔 인터페이스 또는 명령줄 인터페이스를 사용할 수 있습니다.
네트워크 기반 배포의 경우 CLI를 사용하여 에지 이미지에 대한 RHEL을 구성하는 워크플로우에는 다음과 같은 상위 수준 단계가 포함됩니다.
- 에지 이미지 RHEL에 대한 devfile 생성
- Edge Commit 이미지에 대한 RHEL 생성
- Edge Commit 이미지용 RHEL 다운로드
비네트워크 기반 배포의 경우 CLI를 사용하여 에지 이미지에 대한 RHEL을 구성하는 워크플로우에는 다음과 같은 상위 수준 단계가 포함됩니다.
- 에지 이미지 RHEL에 대한 devfile 생성
- 에지 설치 프로그램 이미지용 RHEL에 대한 청사진 생성
- 에지 컨테이너 이미지용 RHEL 생성
- 엣지 설치 프로그램 이미지용 RHEL 생성
- RHEL for Edge 이미지 다운로드
단계를 수행하려면 composer-cli
패키지를 사용합니다.
root가 아닌 경우 composer-cli
명령을 실행하려면 weldr
그룹의 일부이거나 시스템에 대한 관리자 액세스 권한이 있어야 합니다.
5.1. 네트워크 기반 배포 워크플로
이는 OSTree
커밋을 빌드하는 방법에 대한 단계를 제공합니다. 이러한 OSTree
커밋에는 전체 운영 체제가 포함되어 있지만 직접 부팅되지는 않습니다. 부팅하려면 Kickstart 파일을 사용하여 배포해야 합니다.
5.1.1. 이미지 빌더 명령줄 인터페이스를 사용하여 EdgeECDHE 이미지용 RHEL 생성
CLI를 사용하여 에지 커밋 이미지에 대한 RHEL을 생성합니다.
사전 요구 사항
기존 이메일은 없습니다. 이를 확인하기 위해 기존 tekton를 나열하십시오.
$ sudo composer-cli blueprints list
절차
다음 콘텐츠를 사용하여 TOML 형식으로 일반 텍스트 파일을 생성합니다.
name = "blueprint-name" description = "blueprint-text-description" version = "0.0.1" modules = [ ] groups = [ ]
여기서,
- openjdk-name 은 name이며, director-text-description은 귀하의 인식에 대한 설명입니다.
- 0.0.1 은 Semantic Versioning scheme에 따른 버전 번호입니다.
모듈은 이미지에 설치할 패키지 이름 및 일치하는 버전 글러스트를 설명합니다. 예를 들어 패키지 이름 = "tmux"이고 일치하는 버전은 version = "2.9a"입니다.
현재는 패키지와 모듈간에 차이가 없습니다.
그룹은 이미지에 설치할 패키지 그룹입니다(예: 그룹 패키지 anaconda-tools).
이 시점에서 모듈과 그룹을 모르는 경우 비워 둡니다.
필요한 패키지를 포함시키고 귀하의 요구 사항에 맞게 director에 다른 세부 사항을 사용자 정의하십시오.
Makefile에 포함하려는 모든 패키지에 대해 파일에 다음 행을 추가합니다.
[[packages]] name = "package-name" version = "package-version"
여기서,
- package-name은 httpd, gdb-doc 또는 coreutils와 같은 패키지의 이름입니다.
package-version은 사용하려는 패키지의 버전 번호입니다.
package-version은 다음 dnf 버전 사양을 지원합니다.
- 특정 버전의 경우 9.0과 같은 정확한 버전 번호를 사용하십시오.
- 사용 가능한 최신 버전의 경우 별표 *를 사용하십시오.
- 최신 마이너 버전의 경우 9.*와 같은 형식을 사용하십시오.
블루프린트를 RHEL 이미지 빌더 서버로 푸시(가져오기)합니다.
# composer-cli blueprints push blueprint-name.toml
기존 Makefile을 나열하여 생성된 inventory가 성공적으로 푸시되고 있는지 확인합니다.
# composer-cli blueprints show BLUEPRINT-NAME
Makefile 및 해당 종속 항목에 나열된 구성 요소 및 버전이 유효한지 확인합니다.
# composer-cli blueprints depsolve blueprint-name
추가 리소스
5.1.2. 이미지 빌더 명령줄 인터페이스를 사용하여 EdgeECDHE 이미지용 RHEL 생성
RHEL 이미지 빌더 명령줄 인터페이스를 사용하여 RHEL for Edge 커밋 이미지를 생성하려면 다음 사전 요구 사항을 충족했는지 확인하고 절차를 따르십시오.
사전 요구 사항
- RHEL for Edge 커밋 이미지의 블루프린트를 생성했습니다.
절차
Edge Commit 이미지에 대한 RHEL을 만듭니다.
# composer-cli compose start blueprint-name image-type
여기서,
- Quarkus-name 은 에지 opportunity 이름을 위한 RHEL입니다.
image-type 은 네트워크 기반 배포의
edge-
commit 입니다.쓰기 프로세스가 큐에 추가되었음을 확인합니다. 또한 생성된 이미지에 대한 UUID(Universally Unique Identifier) 번호를 표시합니다. UUID 번호를 사용하여 빌드를 추적합니다. 또한 추가 작업을 위해 UUID 번호를 편리하게 유지합니다.
이미지 compose 상태를 확인합니다.
# composer-cli compose status
출력에는 다음 형식으로 상태가 표시됩니다.
<UUID> RUNNING date blueprint-name blueprint-version image-type
참고이미지 생성 프로세스를 완료하는 데 최대 20분이 걸립니다.
이미지 생성 프로세스를 중단하려면 다음을 실행합니다.
# composer-cli compose cancel <UUID>
기존 이미지를 삭제하려면 다음을 실행합니다.
# composer-cli compose delete <UUID>
이미지가 준비되면 이미지를 다운로드하여 네트워크 배포에서 사용할 수 있습니다.
5.1.3. RHEL 이미지 빌더 CLI를 사용하여 참조 커밋을 사용하여 RHEL for Edge 이미지 업데이트 생성
기존의 경우(예: 새 패키지를 추가한 경우) 새 패키지를 추가한 경우 --parent
인수를 사용하여 Edge Commit(.tar) 이미지에 업데이트된 RHEL을
생성할 수 있습니다. --parent
인수는 URL
인수로 지정된 리포지토리에 존재하는 참조
이거나 추출된 .tar
이미지 파일에서 찾을 수 있는 Commit ID
를 사용할 수 있습니다. ref
및 Commit ID
인수는 모두 빌드 중인 새 커밋에 대해 부모를 검색합니다. RHEL 이미지 빌더는 빌드 중인 새 커밋의 일부에 영향을 미치는 상위 커밋에서 정보를 읽을 수 있습니다. 결과적으로 RHEL 이미지 빌더는 상위 커밋의 사용자 데이터베이스를 읽고 패키지에서 생성한 시스템 사용자 및 그룹의 UID 및 GID를 유지합니다.
사전 요구 사항
- 에지 이미지용 RHEL의 기존 credential을 업데이트했습니다.
- 기존 RHEL for Edge 이미지(OSTree 커밋)가 있습니다. 에지 이미지 커밋용 RHEL 추출 을 참조하십시오.
-
빌드 중인
ref
는 URL로 지정된OSTree
리포지토리에서 사용할 수 있습니다.
절차
에지 커밋 이미지를 위한 RHEL을 만듭니다.
# composer-cli compose start-ostree --ref rhel/9/x86_64/edge --parent parent-OSTree-REF --url URL blueprint-name image-type
예를 들어 다음과 같습니다.
상위
및 새 참조를 기반으로 새 RHEL for Edge 커밋을 생성하려면 다음 명령을 실행합니다.# composer-cli compose start-ostree --ref rhel/9/x86_64/edge --parent rhel/9/x86_64/edge --url http://10.0.2.2:8080/repo rhel_update edge-commit
동일한
ref
를 기반으로 Edge 커밋을 위한 새 RHEL을 생성하려면 다음 명령을 실행합니다.# composer-cli compose start-ostree --ref rhel/9/x86_64/edge --url http://10.0.2.2:8080/repo rhel_update edge-commit
다음과 같습니다.
- --ref 인수는 OSTree 리포지토리를 빌드하는 데 사용한 것과 동일한 경로 값을 지정합니다.
-
--parent 인수는 상위 커밋을 지정합니다. 해결 및 가져올 수 있는 참조(예:
rhel/9/x86_64/edge
) 또는 추출된.tar
파일에서 찾을 수 있는커밋 ID
입니다. - Quarkus-name 은 에지 opportunity 이름을 위한 RHEL입니다.
-
--url
인수는 이미지에 포함할 커밋의 OSTree 리포지토리에 대한 URL을 지정합니다(예: http://10.0.2.2:8080/repo). image-type 은 네트워크 기반 배포의
edge-
commit 입니다.참고-
--parent
인수는RHEL for Edge Commit(.tar)
이미지 유형에만 사용할 수 있습니다.--url
및--parent
인수를 함께 사용하면RHEL for Edge Container(.tar)
이미지 유형이 오류가 발생합니다. -
상위 ref
인수를 생략하면 시스템은--ref
인수로 지정된ref
로 대체됩니다.
쓰기 프로세스가 큐에 추가되었음을 확인합니다. 또한 생성된 이미지에 대한 UUID(Universally Unique Identifier) 번호를 표시합니다. UUID 번호를 사용하여 빌드를 추적합니다. 또한 추가 작업을 위해 UUID 번호를 편리하게 유지합니다.
-
이미지 compose 상태를 확인합니다.
# composer-cli compose status
출력에는 다음 형식으로 상태가 표시됩니다.
<UUID> RUNNING date blueprint-name blueprint-version image-type
참고이미지 생성 프로세스를 완료하는 데 몇 분이 걸립니다.
(선택 사항) 이미지 생성 프로세스를 중단하려면 다음을 실행합니다.
# composer-cli compose cancel <UUID>
(선택 사항) 기존 이미지를 삭제하려면 다음을 실행합니다.
# composer-cli compose delete <UUID>
이미지 생성이 완료되면 기존 OSTree 배포를 업그레이드하려면 다음이 필요합니다.
- 리포지토리를 설정합니다. 에지 이미지용 RHEL 배포를 참조하십시오.
- 이 리포지토리를 원격, 즉 OSTree 콘텐츠를 호스팅하는 http 또는 https 엔드포인트로 추가합니다.
- 기존 실행 중인 인스턴스에 새 OSTree 커밋을 가져옵니다. 에지 이미지 업데이트용 RHEL 배포를 수동으로 참조하십시오.
5.1.4. 이미지 빌더 명령줄 인터페이스를 사용하여 에지 이미지용 RHEL 다운로드
RHEL 이미지 빌더 명령줄 인터페이스를 사용하여 RHEL for Edge 이미지를 다운로드하려면 다음 사전 요구 사항을 충족했는지 확인한 다음 절차를 따르십시오.
사전 요구 사항
- 에지 이미지용 RHEL을 생성했습니다.
절차
RHEL for Edge 이미지 상태를 검토합니다.
# composer-cli compose status
출력에 다음이 표시되어야 합니다.
$ <UUID> FINISHED date blueprint-name blueprint-version image-type
이미지를 다운로드합니다.
# composer-cli compose image <UUID>
RHEL 이미지 빌더는 이미지를
tar
파일로 현재 디렉터리에 다운로드합니다.UUID 번호와 이미지 크기가 함께 표시됩니다.
$ <UUID>-commit.tar: size MB
이미지에는 리포지토리 콘텐츠에 대한 정보 메타데이터가 포함된 커밋 및 json
파일이 포함되어 있습니다.
5.2. 비 네트워크 기반 배포 워크플로
"RHEL for Edge Container" 및 "RHEL for Edge Installer" 이미지를 사용하여 OSTree 기반 시스템을 설치하는 부팅 ISO 이미지를 빌드하려면 나중에 연결이 끊긴 환경에서 장치에 배포할 수 있는 단계를 따르십시오.
5.2.1. 이미지 빌더 CLI를 사용하여 RHEL for Edge 컨테이너 블루프린트 생성
에지 컨테이너 이미지에 대한 RHEL에 대한 청사진을 생성하려면 다음 단계를 수행합니다.
절차
다음 콘텐츠를 사용하여 TOML 형식으로 일반 텍스트 파일을 생성합니다.
name = "blueprint-name" description = "blueprint-text-description" version = "0.0.1" modules = [ ] groups = [ ]
여기서,
- openjdk-name 은 name이며, director-text-description은 귀하의 인식에 대한 설명입니다.
- 0.0.1 은 Semantic Versioning scheme에 따른 버전 번호입니다.
모듈은 이미지에 설치할 패키지 이름 및 일치하는 버전 글러스트를 설명합니다. 예를 들어 패키지 이름 = "tmux"이고 일치하는 버전은 version = "2.9a"입니다.
현재는 패키지와 모듈간에 차이가 없습니다.
그룹은 이미지에 설치할 패키지 그룹입니다(예: 그룹 패키지 anaconda-tools).
이 시점에서 모듈과 그룹을 모르는 경우 비워 둡니다.
필요한 패키지를 포함시키고 귀하의 요구 사항에 맞게 director에 다른 세부 사항을 사용자 정의하십시오.
Makefile에 포함하려는 모든 패키지에 대해 파일에 다음 행을 추가합니다.
[[packages]] name = "package-name" version = "package-version"
여기서,
-
package-name은
httpd
,gdb-doc
또는coreutils
와 같은 패키지 이름입니다. package-version은 사용하려는 패키지의 버전 번호입니다.
package-version은 다음
dnf
버전 사양을 지원합니다.- 특정 버전의 경우 9.0과 같은 정확한 버전 번호를 사용하십시오.
- 사용 가능한 최신 버전의 경우 별표 *를 사용하십시오.
- 최신 마이너 버전의 경우 9.*와 같은 형식을 사용하십시오.
-
package-name은
블루프린트를 RHEL 이미지 빌더 서버로 푸시(가져오기)합니다.
# composer-cli blueprints push blueprint-name.toml
기존 Makefile을 나열하여 생성된 inventory가 성공적으로 푸시되고 있는지 확인합니다.
# composer-cli blueprints show BLUEPRINT-NAME
Makefile 및 해당 종속 항목에 나열된 구성 요소 및 버전이 유효한지 확인합니다.
# composer-cli blueprints depsolve blueprint-name
추가 리소스
5.2.2. 이미지 빌더 CLI를 사용하여 에지 설치 관리자용 RHEL 생성
Edge Installer(.iso) 이미지를 위한 RHEL
을 빌드하고 설치 시 시스템에서 하나 이상의 사용자를 자동으로 생성하도록 사용자 계정을 지정할 수 있습니다.
customizations.user
사용자 지정으로 사용자를 생성하면 /usr/lib/passwd
디렉토리 및 암호 아래에 /usr/etc/shadow
디렉터리에 사용자를 생성합니다. OSTree
업데이트를 사용하여 실행 중인 시스템에서 추가 버전의 이미지의 암호를 변경할 수 없습니다. 생성된 시스템에 액세스하기 위해서만 사용자가 생성한 사용자를 사용해야 합니다. 시스템에 액세스한 후 useradd
명령을 사용하여 사용자를 생성해야 합니다.
에지 설치 프로그램 이미지용 RHEL에 대한 청사진을 생성하려면 다음 단계를 수행합니다.
절차
다음 콘텐츠를 사용하여 TOML 형식으로 일반 텍스트 파일을 생성합니다.
name = "blueprint-installer" description = "blueprint-for-installer-image" version = "0.0.1" [[customizations.user]] name = "user" description = "account" password = "user-password" key = "user-ssh-key " home = "path" groups = ["user-groups"]
여기서,
- openjdk-name 은 name이며, director-text-description은 귀하의 인식에 대한 설명입니다.
- 0.0.1 은 Semantic Versioning scheme에 따른 버전 번호입니다.
블루프린트를 RHEL 이미지 빌더 서버로 푸시(가져오기)합니다.
# composer-cli blueprints push blueprint-name.toml
기존 Makefile을 나열하여 생성된 inventory가 성공적으로 푸시되고 있는지 확인합니다.
# composer-cli blueprints show blueprint-name
Makefile 및 해당 종속 항목에 나열된 구성 요소 및 버전이 유효한지 확인합니다.
# composer-cli blueprints depsolve blueprint-name
추가 리소스
5.2.3. 이미지 빌더 CLI를 사용하여 RHEL for Edge 컨테이너 이미지 생성
RHEL 이미지 빌더 명령줄 인터페이스를 사용하여 RHEL for Edge 컨테이너 이미지를 생성하려면 다음 사전 요구 사항을 충족했는지 확인하고 절차를 따르십시오.
사전 요구 사항
- 에지 컨테이너 이미지용 RHEL에 대한 devfile을 생성했습니다.
절차
Edge 컨테이너 이미지에 대한 RHEL을 생성합니다.
# composer-cli compose start-ostree --ref rhel/9/x86_64/edge --url URL-OSTree-repository blueprint-name image-type
여기서,
-
--ref
는 고객이 OSTree 리포지토리를 빌드하는 데 사용한 값과 같습니다. --
URL은 이미지에 포함할 커밋의 OSTree 리포지토리의 URL입니다. 예: http://10.0.2.2:8080/repo/. 기본적으로 에지 컨테이너 이미지에 대한 RHEL의 리포지토리 폴더는 "/repo"입니다. Edge 이미지용 RHEL을 설치할 웹 서버 설정을 참조하십시오.사용할 올바른 URL을 찾으려면 실행 중인 컨테이너에 액세스하여
nginx.conf
파일을 확인합니다. 사용할 URL을 찾으려면 실행 중인 컨테이너에 액세스하여nginx.conf
파일을 확인합니다.nginx.conf
파일 내에서/repo/
폴더 정보를 검색할루트
디렉터리 항목을 찾습니다. RHEL 이미지 빌더를 사용하여 RHEL for Edge 컨테이너 이미지(.tar)
를 생성할 때 리포지토리 URL을 지정하지 않으면nginx.conf
파일에 기본/repo/
항목이 생성됩니다.- Quarkus-name 은 에지 opportunity 이름을 위한 RHEL입니다.
image-type 은 네트워크 기반이 아닌 배포의
edge-container
입니다.쓰기 프로세스가 큐에 추가되었음을 확인합니다. 또한 생성된 이미지에 대한 UUID(Universally Unique Identifier) 번호를 표시합니다. UUID 번호를 사용하여 빌드를 추적합니다. 또한 추가 작업을 위해 UUID 번호를 편리하게 유지합니다.
-
이미지 compose 상태를 확인합니다.
# composer-cli compose status
출력에는 다음 형식으로 상태가 표시됩니다.
<UUID> RUNNING date blueprint-name blueprint-version image-type
참고이미지 생성 프로세스를 완료하는 데 최대 20분이 걸립니다.
이미지 생성 프로세스를 중단하려면 다음을 실행합니다.
# composer-cli compose cancel <UUID>
기존 이미지를 삭제하려면 다음을 실행합니다.
# composer-cli compose delete <UUID>
이미지가 준비되면 비 네트워크 배포에 사용할 수 있습니다. 비 네트워크 기반 배포의 경우 에지 컨테이너 이미지의 RHEL 생성을 참조하십시오.
5.2.4. 네트워크 기반 배포에 명령줄 인터페이스를 사용하여 에지 설치 프로그램 이미지 생성
OSTree
커밋을 포함하는 RHEL for Edge 설치 프로그램 이미지를 생성하려면 RHEL 이미지 빌더 명령줄 인터페이스를 사용하여 다음 사전 요구 사항을 충족했는지 확인한 다음 절차를 따르십시오.
사전 요구 사항
- 에지 설치 프로그램 이미지용 RHEL에 대한 청사진을 생성했습니다.
- RHEL for Edge 컨테이너 이미지를 생성하고 웹 서버를 사용하여 배포했습니다.
절차
에지 설치 프로그램 이미지용 RHEL 생성을 시작합니다.
# composer-cli compose start-ostree --ref rhel/9/x86_64/edge --url URL-OSTree-repository blueprint-name image-type
여기서,
- ref 는 고객이 OSTree 리포지토리를 빌드하는 데 사용한 값과 같습니다.
- URL-OSTree-repository 는 이미지에 포함할 커밋의 OSTree 리포지토리에 대한 URL입니다. 예: http://10.0.2.2:8080/repo. 네트워크 기반이 아닌 배포를 위한 RHEL for Edge 컨테이너 이미지 생성 을 참조하십시오.
- Blueprint-name 은 에지 설치 프로그램 청사진 이름에 대한 RHEL입니다.
image-type 은
edge-installer
입니다.쓰기 프로세스가 큐에 추가되었음을 확인합니다. 또한 생성된 이미지에 대한 UUID(Universally Unique Identifier) 번호를 표시합니다. UUID 번호를 사용하여 빌드를 추적합니다. 또한 추가 작업을 위해 UUID 번호를 편리하게 유지합니다.
이미지 compose 상태를 확인합니다.
# composer-cli compose status
명령 출력은 다음 형식으로 상태를 표시합니다.
<UUID> RUNNING date blueprint-name blueprint-version image-type
참고이미지 생성 프로세스를 완료하는 데 몇 분이 걸립니다.
이미지 생성 프로세스를 중단하려면 다음을 실행합니다.
# composer-cli compose cancel <UUID>
기존 이미지를 삭제하려면 다음을 실행합니다.
# composer-cli compose delete <UUID>
이미지가 준비되면 비 네트워크 배포에 사용할 수 있습니다. 네트워크 기반 배포가 아닌 경우 Edge 이미지의 RHEL 설치를 참조하십시오.
5.2.5. 이미지 빌더 CLI를 사용하여 에지 설치 관리자 이미지 다운로드
RHEL 이미지 빌더 명령줄 인터페이스를 사용하여 RHEL for Edge 설치 프로그램 이미지를 다운로드하려면 다음 사전 요구 사항을 충족했는지 확인한 다음 절차를 따르십시오.
사전 요구 사항
- 에지 설치 프로그램 이미지용 RHEL을 생성했습니다.
절차
RHEL for Edge 이미지 상태를 검토합니다.
# composer-cli compose status
출력에 다음이 표시되어야 합니다.
$ <UUID> FINISHED date blueprint-name blueprint-version image-type
이미지를 다운로드합니다.
# composer-cli compose image <UUID>
RHEL 이미지 빌더는 이미지를
.iso
파일로 현재 디렉터리에 다운로드합니다.UUID 번호와 이미지 크기가 함께 표시됩니다.
$ <UUID>-boot.iso: size MB
결과 이미지는 부팅 가능한 ISO 이미지입니다.
5.3. 지원되는 이미지 사용자 정의
다음과 같은 블루프린트에 사용자 지정을 추가하여 이미지를 사용자 지정할 수 있습니다.
- 추가 RPM 패키지 추가
- 서비스 활성화
- 커널 명령줄 매개 변수 사용자 정의.
다른 사람 사이입니다. 청사진 내에서 여러 이미지 사용자 정의를 사용할 수 있습니다. 사용자 지정을 사용하면 기본 패키지에서 사용할 수 없는 이미지에 패키지 및 그룹을 추가할 수 있습니다. 이러한 옵션을 사용하려면 블루프린트에서 사용자 지정을 구성하고 RHEL 이미지 빌더로 가져오기(push)합니다.
5.3.1. 배포 선택
distro
필드를 사용하여 이미지를 구성할 때 사용할 배포를 선택하거나 블루프린트의 종속성을 해결할 수 있습니다. distro
를 비워 두면 호스트 배포를 사용합니다. 배포를 지정하지 않으면 블루프린트에서 호스트 배포를 사용합니다. 호스트 운영 체제를 업그레이드하는 경우 새 운영 체제 버전을 사용하여 배포 세트 빌드 이미지가 없는 블루프린트입니다. RHEL 이미지 빌더 호스트와 다른 운영 체제 이미지를 빌드할 수 없습니다.
항상 지정된 RHEL 이미지를 빌드하도록 RHEL 배포를 사용하여 블루프린트를 사용자 지정합니다.
name = "blueprint_name" description = "blueprint_version" version = "0.1" distro = "different_minor_version"
예를 들어 다음과 같습니다.
name = "tmux" description = "tmux image with openssh" version = "1.2.16" distro = "rhel-8.5"
"different_minor_version"
을 교체하여 다른 마이너 버전을 빌드합니다. 예를 들어 RHEL 9.4 이미지를 빌드하려면 distro
= "rhel-94"를 사용합니다. RHEL 9.3 이미지에서 RHEL 9.3, RHEL 8.9 및 이전 릴리스와 같은 마이너 버전을 빌드할 수 있습니다.
5.3.2. 패키지 그룹 선택
패키지 그룹으로 블루프린트를 사용자 지정합니다. 그룹
목록은 이미지에 설치할 패키지 그룹을 설명합니다. 패키지 그룹은 리포지토리 메타데이터에 정의되어 있습니다. 각 그룹에는 주로 사용자 인터페이스에 표시하는 데 사용되는 설명적인 이름과 Kickstart 파일에서 일반적으로 사용되는 ID가 있습니다. 이 경우 ID를 사용하여 그룹을 나열해야 합니다. 그룹에는 필수, 기본값, 선택 사항 등 패키지를 분류하는 세 가지 방법이 있습니다. 필수 및 기본 패키지만 블루프린트에 설치됩니다. 선택적 패키지를 선택할 수 없습니다.
name
속성은 필수 문자열이며 리포지토리의 패키지 그룹 ID와 정확히 일치해야 합니다.
현재 osbuild-composer
의 패키지와 모듈 간에는 차이가 없습니다. 둘 다 RPM 패키지 종속성으로 취급됩니다.
패키지로 블루프린트를 사용자 지정합니다.
[[groups]] name = "group_name"
group_name
을 그룹 이름으로 교체합니다. 예:anaconda-tools
:[[groups]] name = "anaconda-tools"
5.3.3. 이미지 호스트 이름 설정
customization .hostname
은 최종 이미지 호스트 이름을 구성하는 데 사용할 수 있는 선택적 문자열입니다. 이 사용자 지정은 선택 사항이며 설정하지 않으면 블루프린트에서 기본 호스트 이름을 사용합니다.
블루프린트를 사용자 지정하여 호스트 이름을 구성합니다.
[customizations] hostname = "baseimage"
5.3.4. 추가 사용자 지정
이미지에 사용자를 추가하고 선택적으로 SSH 키를 설정합니다. 이 섹션의 모든 필드는 이름을
제외하고 선택 사항입니다.
절차
이미지에 사용자를 추가하도록 블루프린트를 사용자 지정합니다.
[[customizations.user]] name = "USER-NAME" description = "USER-DESCRIPTION" password = "PASSWORD-HASH" key = "PUBLIC-SSH-KEY" home = "/home/USER-NAME/" shell = "/usr/bin/bash" groups = ["users", "wheel"] uid = NUMBER gid = NUMBER
[[customizations.user]] name = "admin" description = "Administrator account" password = "$6$CHO2$3rN8eviE2t50lmVyBYihTgVRHcaecmeCk31L..." key = "PUBLIC SSH KEY" home = "/srv/widget/" shell = "/usr/bin/bash" groups = ["widget", "users", "wheel"] uid = 1200 gid = 1200 expiredate = 12345
GID는 선택 사항이며 이미지에 이미 있어야 합니다. 선택적으로 패키지가 생성되거나 블루프린트는
[customizations.group]
항목을 사용하여 GID를 생성합니다.PASSWORD-HASH 를 실제
암호 해시
로 바꿉니다.암호 해시
를 생성하려면 다음과 같은 명령을 사용합니다.$ python3 -c 'import crypt,getpass;pw=getpass.getpass();print(crypt.crypt(pw) if (pw==getpass.getpass("Confirm: ")) else exit())'
다른 자리 표시자를 적절한 값으로 바꿉니다.
name
값을 입력하고 필요하지 않은 행을 생략합니다.모든 사용자가 다음을 포함하도록 이 블록을 반복합니다.
5.3.5. 추가 그룹 지정
결과 시스템 이미지에 대한 그룹을 지정합니다. name
및 gid
속성은 모두 필수입니다.
그룹으로 블루프린트를 사용자 지정합니다.
[[customizations.group]] name = "GROUP-NAME" gid = NUMBER
모든 그룹에 대해 이 블록을 반복하여 포함합니다. 예를 들어 다음과 같습니다.
[[customizations.group]] name = "widget" gid = 1130
5.3.6. 기존 사용자를 위한 SSH 키 설정
custom .sshkey
를 사용하여 최종 이미지에 있는 기존 사용자의 SSH 키를 설정할 수 있습니다. 사용자
및 키
속성은 모두 필수입니다.
기존 사용자의 SSH 키를 설정하여 블루프린트를 사용자 지정합니다.
[[customizations.sshkey]] user = "root" key = "PUBLIC-SSH-KEY"
예를 들어 다음과 같습니다.
[[customizations.sshkey]] user = "root" key = "SSH key for root"
참고기존 사용자에 대한 customization
.sshkey 사용자
지정만 구성할 수 있습니다. 사용자를 생성하고 SSH 키를 설정하려면 추가 사용자 사용자 지정을 참조하십시오.
5.3.7. 커널 인수 추가
부트 로더 커널 명령줄에 인수를 추가할 수 있습니다. 기본적으로 RHEL 이미지 빌더는 기본 커널을 이미지에 빌드합니다. 그러나 블루프린트에서 커널을 구성하여 커널을 사용자 지정할 수 있습니다.
커널 부팅 매개변수 옵션을 기본값에 추가합니다.
[customizations.kernel] append = "KERNEL-OPTION"
예를 들어 다음과 같습니다.
[customizations.kernel] name = "kernel-debug" append = "nosmt=force"
5.3.8. 시간대 및 NTP 설정
블루프린트를 사용자 지정하여 시간대 및 NTP( Network Time Protocol )를 구성할 수 있습니다. timezone
및 ntpservers
속성은 모두 선택적 문자열입니다. 시간대를 사용자 지정하지 않으면 시스템은 UTC( Universal Time, Coordinated )를 사용합니다. NTP 서버를 설정하지 않으면 시스템은 기본 배포를 사용합니다.
시간대
및 원하는ntpservers
로 블루프린트를 사용자 지정합니다.[customizations.timezone] timezone = "TIMEZONE" ntpservers = "NTP_SERVER"
예를 들어 다음과 같습니다.
[customizations.timezone] timezone = "US/Eastern" ntpservers = ["0.north-america.pool.ntp.org", "1.north-america.pool.ntp.org"]
참고Google Cloud와 같은 일부 이미지 유형에는 이미 NTP 서버가 설정되어 있습니다. 이미지에 선택한 환경에서 NTP 서버를 부팅해야 하므로 재정의할 수 없습니다. 그러나 블루프린트에서 시간대를 사용자 지정할 수 있습니다.
5.3.9. 로케일 설정 사용자 정의
결과 시스템 이미지에 대한 로케일 설정을 사용자 지정할 수 있습니다. 언어
및 키보드
속성은 모두 필수입니다. 다른 많은 언어를 추가할 수 있습니다. 첫 번째 언어는 기본 언어이며 다른 언어는 보조 언어입니다.
절차
로케일 설정을 설정합니다.
[customizations.locale] languages = ["LANGUAGE"] keyboard = "KEYBOARD"
예를 들어 다음과 같습니다.
[customizations.locale] languages = ["en_US.UTF-8"] keyboard = "us"
언어에서 지원하는 값을 나열하려면 다음 명령을 실행합니다.
$ localectl list-locales
키보드에서 지원하는 값을 나열하려면 다음 명령을 실행합니다.
$ localectl list-keymaps
5.3.10. 방화벽 사용자 정의
결과 시스템 이미지에 대한 방화벽을 설정합니다. 기본적으로 방화벽은 sshd
와 같이 포트를 명시적으로 활성화하는 서비스를 제외하고 들어오는 연결을 차단합니다.
[customizations.firewall]
또는 [customizations.firewall.services]
를 사용하지 않으려는 경우 속성을 제거하거나 빈 목록 []으로 설정합니다. 기본 방화벽 설정만 사용하려는 경우 블루프린트에서 사용자 지정을 생략할 수 있습니다.
Google 및 OpenStack 템플릿은 해당 환경의 방화벽을 명시적으로 비활성화합니다. 블루프린트를 설정하여 이 동작을 재정의할 수 없습니다.
절차
다음 설정으로 블루프린트를 사용자 지정하여 다른 포트 및 서비스를 엽니다.
[customizations.firewall] ports = ["PORTS"]
여기서 port는 열 포트 또는 포트 및 프로토콜 범위를 포함하는 선택적 문자열 목록입니다.
port:protocol
형식을 사용하여 포트를 구성할 수 있습니다.portA-portB:protocol
형식을 사용하여 포트 범위를 구성할 수 있습니다. 예를 들어 다음과 같습니다.[customizations.firewall] ports = ["22:tcp", "80:tcp", "imap:tcp", "53:tcp", "53:udp", "30000-32767:tcp", "30000-32767:udp"]
숫자 포트 또는
/etc/services
의 해당 이름을 사용하여 포트 목록을 활성화하거나 비활성화할 수 있습니다.customization
.firewall.service 섹션에서 활성화 또는 비활성화할 방화벽 서비스를 지정합니다.
[customizations.firewall.services] enabled = ["SERVICES"] disabled = ["SERVICES"]
사용 가능한 방화벽 서비스를 확인할 수 있습니다.
$ firewall-cmd --get-services
예를 들어 다음과 같습니다.
[customizations.firewall.services] enabled = ["ftp", "ntp", "dhcp"] disabled = ["telnet"]
참고firewall.services
에 나열된 서비스는/etc/services
파일에서 사용할 수 있는 서비스이름과
다릅니다.
5.3.11. 서비스 활성화 또는 비활성화
부팅 시 활성화할 서비스를 제어할 수 있습니다. 일부 이미지 유형에는 이미지가 올바르게 작동하고 이 설정을 재정의할 수 없도록 서비스가 이미 활성화되어 있거나 비활성화되어 있습니다. 블루프린트의 [customizations.services]
설정은 이러한 서비스를 대체하지 않고 이미지 템플릿에 이미 있는 서비스 목록에 서비스를 추가합니다.
부팅 시 활성화할 서비스를 사용자 지정합니다.
[customizations.services] enabled = ["SERVICES"] disabled = ["SERVICES"]
예를 들어 다음과 같습니다.
[customizations.services] enabled = ["sshd", "cockpit.socket", "httpd"] disabled = ["postfix", "telnetd"]
5.3.12. 사용자 정의 파일 시스템 구성 지정
블루프린트에서 사용자 지정 파일 시스템 구성을 지정하고 기본 레이아웃 구성 대신 특정 디스크 레이아웃으로 이미지를 생성할 수 있습니다. 블루프린트에서 기본값이 아닌 레이아웃 구성을 사용하면 다음과 같은 이점을 얻을 수 있습니다.
- 보안 벤치마크 준수
- 디스크 부족 오류로부터 보호
- 성능 개선
- 기존 설정과의 일관성
OSTree 이미지에는 읽기 전용과 같은 자체 마운트 규칙이 있으므로 OSTree 시스템은 파일 시스템 사용자 정의를 지원하지 않습니다. 다음 이미지 유형은 지원되지 않습니다.
-
image-installer
-
edge-installer
-
edge-simplified-installer
또한 이러한 이미지 유형이 분할된 운영 체제 이미지를 생성하지 않기 때문에 다음 이미지 유형은 파일 시스템 사용자 정의를 지원하지 않습니다.
-
edge-commit
-
edge-container
-
tar
-
container
RHEL 8.10 및 9.4 이전의 릴리스 배포의 경우 블루프린트는 다음 마운트 지점
및 해당 하위 디렉터리를 지원합니다.
-
/
- 루트 마운트 지점 -
/var
-
/home
-
/opt
-
/srv
-
/usr
-
/app
-
/data
-
/tmp
RHEL 9.4 및 8.10 릴리스 이후 릴리스 배포에서는 운영 체제용으로 예약된 특정 경로를 제외하고 임의의 사용자 지정 마운트 지점을 지정할 수 있습니다.
다음 마운트 지점 및 해당 하위 디렉터리에 임의의 사용자 지정 마운트 지점을 지정할 수 없습니다.
-
/bin
-
/boot/efi
-
/dev
-
/etc
-
/lib
-
/lib64
-
/lost+found
-
/proc
-
/run
-
/sbin
-
/sys
-
/sysroot
-
/var/lock
-
/var/run
/usr
사용자 지정 마운트 지점의 블루프린트에서 파일 시스템을 사용자 지정할 수 있지만 하위 디렉터리는 허용되지 않습니다.
마운트 지점 사용자 지정은 CLI를 사용하여 RHEL 9.0 이후 버전에서만 지원됩니다. 이전 배포에서는 루트
파티션을 마운트 지점으로만 지정하고 size
인수를 이미지 크기의 별칭으로 지정할 수 있습니다.
사용자 지정 이미지에 두 개 이상의 파티션이 있는 경우 LVM에 사용자 지정 파일 시스템 파티션으로 이미지를 생성하고 런타임 시 해당 파티션의 크기를 조정할 수 있습니다. 이렇게 하려면 블루프린트에서 사용자 지정 파일 시스템 구성을 지정하고 필요한 디스크 레이아웃을 사용하여 이미지를 생성할 수 있습니다. 기본 파일 시스템 레이아웃은 변경되지 않은 상태로 유지됩니다. 파일 시스템 사용자 정의 없이 일반 이미지를 사용하고 cloud-init
는 루트 파티션의 크기를 조정합니다.
블루프린트는 파일 시스템 사용자 지정을 LVM 파티션으로 자동 변환합니다.
사용자 지정 파일 블루프린트 사용자 지정을 사용하여 새 파일을 생성하거나 기존 파일을 교체할 수 있습니다. 지정한 파일의 상위 디렉터리가 있어야 합니다. 그렇지 않으면 이미지 빌드가 실패합니다. [customizations.directories]
사용자 지정에 상위 디렉터리가 있는지 확인합니다.
파일 사용자 정의를 다른 블루프린트 사용자 정의와 결합하면 다른 사용자 정의 기능에 영향을 주거나 현재 파일 사용자 정의를 재정의할 수 있습니다.
5.3.12.1. 블루프린트에 사용자 지정 파일 지정
[customizations.files]
블루프린트 사용자 지정을 사용하면 다음을 수행할 수 있습니다.
- 새 텍스트 파일을 생성합니다.
- 기존 파일 수정. 경고: 기존 콘텐츠를 덮어쓸 수 있습니다.
- 생성 중인 파일에 대한 사용자 및 그룹 소유권을 설정합니다.
- 8진수 형식으로 모드 권한을 설정합니다.
다음 파일을 생성하거나 교체할 수 없습니다.
-
/etc/fstab
-
/etc/shadow
-
/etc/passwd
-
/etc/group
[customizations.files] 및
및 디렉터리를 생성할 수 있습니다. 이러한 사용자 지정은 [[customizations.directories]]
블루프린트 사용자 지정을 사용하여 이미지에 사용자 지정 파일/etc
디렉토리에서만 사용할 수 있습니다.
이러한 블루프린트 사용자 정의는 edge-raw-image
,edge-installer
, edge-simplified-installer
와 같은 OSTree 커밋을 배포하는 이미지 유형을 제외하고 모든 이미지 유형에서 지원됩니다.
이미 설정된 모드
,사용자
또는 그룹이
설정된 이미지에 이미 존재하는 디렉터리 경로에 custom .directories
를 사용하는 경우 이미지 빌드에서 기존 디렉터리의 소유권 또는 권한을 변경하지 못합니다.
5.3.12.2. 블루프린트에 사용자 지정 디렉터리 지정
[customizations.directories]
블루프린트 사용자 지정을 사용하면 다음을 수행할 수 있습니다.
- 새 디렉토리를 만듭니다.
- 생성 중인 디렉터리에 대한 사용자 및 그룹 소유권을 설정합니다.
- 8진수 형식으로 디렉터리 모드 권한을 설정합니다.
- 필요에 따라 상위 디렉터리가 생성되었는지 확인합니다.
[customizations.files]
블루프린트 사용자 지정을 사용하면 다음을 수행할 수 있습니다.
- 새 텍스트 파일을 생성합니다.
- 기존 파일 수정. 경고: 기존 콘텐츠를 덮어쓸 수 있습니다.
- 생성 중인 파일에 대한 사용자 및 그룹 소유권을 설정합니다.
- 8진수 형식으로 모드 권한을 설정합니다.
다음 파일을 생성하거나 교체할 수 없습니다.
-
/etc/fstab
-
/etc/shadow
-
/etc/passwd
-
/etc/group
다음 사용자 지정을 사용할 수 있습니다.
블루프린트에서 파일 시스템 구성을 사용자 지정합니다.
[[customizations.filesystem]] mountpoint = "MOUNTPOINT" minsize = MINIMUM-PARTITION-SIZE
MINIMUM- Cryostat-SIZE
값은 기본 크기 형식이 없습니다. 블루프린트 사용자 지정은 kB에서 TB로, KiB에서 TiB까지의 다음 값과 단위를 지원합니다. 예를 들어 마운트 지점 크기를 바이트 단위로 정의할 수 있습니다.[[customizations.filesystem]] mountpoint = "/var" minsize = 1073741824
단위를 사용하여 마운트 지점 크기를 정의합니다. 예를 들어 다음과 같습니다.
[[customizations.filesystem]] mountpoint = "/opt" minsize = "20 GiB"
[[customizations.filesystem]] mountpoint = "/boot" minsize = "1 GiB"
minsize
를 설정하여 최소 파티션을 정의합니다. 예를 들어 다음과 같습니다.[[customizations.filesystem]] mountpoint = "/var" minsize = 2147483648
[customizations.directories] :을 사용하여 이미지의
/etc
디렉터리에 사용자 지정 디렉토리를 만듭니다.[[customizations.directories]] path = "/etc/directory_name" mode = "octal_access_permission" user = "user_string_or_integer" group = "group_string_or_integer" ensure_parents = boolean
블루프린트 항목은 다음과 같이 설명되어 있습니다.
-
경로
- 필수 - 생성하려는 디렉터리의 경로를 입력합니다./etc
디렉토리 아래의 절대 경로여야 합니다. -
mode
- 선택 사항 - 디렉터리에 대한 액세스 권한을 8진수 형식으로 설정합니다. 권한을 지정하지 않으면 기본값은 0755입니다. 앞에 0은 선택 사항입니다. -
user
- 선택 사항 - 사용자를 디렉터리의 소유자로 설정합니다. 사용자를 지정하지 않으면 기본값은root
입니다. 사용자를 문자열 또는 정수로 지정할 수 있습니다. -
group
- 선택 사항 - 그룹을 디렉터리의 소유자로 설정합니다. 그룹을 지정하지 않으면 기본값은root
입니다. 그룹을 문자열 또는 정수로 지정할 수 있습니다. -
ensure_parents
- 선택 사항 - 필요에 따라 상위 디렉터리를 생성할지 여부를 지정합니다. 값을 지정하지 않으면 기본값은false
입니다.
-
[customizations.directories] :을 사용하여 이미지의
/etc
디렉터리에 사용자 지정 파일을 만듭니다.[[customizations.files]] path = "/etc/directory_name" mode = "octal_access_permission" user = "user_string_or_integer" group = "group_string_or_integer" data = "Hello world!"
블루프린트 항목은 다음과 같이 설명되어 있습니다.
-
path
- Mandatory - 생성하려는 파일의 경로를 입력합니다./etc
디렉토리 아래의 절대 경로여야 합니다. -
mode
Optional - 8진수 형식으로 파일에 대한 액세스 권한을 설정합니다. 권한을 지정하지 않으면 기본값은 0644입니다. 앞에 0은 선택 사항입니다. -
user
- Optional - 사용자를 파일의 소유자로 설정합니다. 사용자를 지정하지 않으면 기본값은root
입니다. 사용자를 문자열 또는 정수로 지정할 수 있습니다. -
group
- 선택 사항 - 그룹을 파일의 소유자로 설정합니다. 그룹을 지정하지 않으면 기본값은root
입니다. 그룹을 문자열 또는 정수로 지정할 수 있습니다. -
data
- 선택 사항 - 일반 텍스트 파일의 내용을 지정합니다. 콘텐츠를 지정하지 않으면 빈 파일이 생성됩니다.
-
5.4. RHEL 이미지 빌더에서 설치한 패키지
RHEL 이미지 빌더를 사용하여 시스템 이미지를 생성할 때 시스템은 기본 패키지 그룹 세트를 설치합니다.
블루프린트에 구성 요소를 추가할 때 추가한 구성 요소의 패키지가 다른 패키지 구성 요소와 충돌하지 않는지 확인합니다. 그렇지 않으면 시스템이 종속성을 해결하지 못하고 사용자 지정 이미지를 생성할 수 없습니다. 명령을 실행하여 패키지 간에 충돌이 없는지 확인할 수 있습니다.
# composer-cli blueprints depsolve BLUEPRINT-NAME
이미지 유형 | 기본 패키지 |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
추가 리소스
6장. 에지 이미지용 RHEL을 프로비저닝하기 위해 간소화된 설치 프로그램 이미지 빌드
장치에 역추적 설치에 최적화된 에지 Simplified 설치 프로그램 이미지용 RHEL을 빌드하고 Edge 이미지용 RHEL에 이미지를 프로비저닝할 수 있습니다.
6.1. 설치 프로그램 이미지 빌드 및 배포 단순화
edge-simplified-installer
이미지 유형을 사용하여 Edge Simplified Installer 이미지를 빌드합니다.
에지 간소화 설치 프로그램 이미지용 RHEL을 빌드하려면 기존 OSTree
커밋을 제공합니다. 결과 간소화된 이미지에는 OSTree 커밋이 배포된 원시 이미지가 포함되어 있습니다. 간소화된 설치 프로그램 ISO 이미지를 부팅한 후 하드 디스크 또는 가상 머신의 부팅 이미지로 사용할 수 있는 RHEL for Edge 시스템을 프로비저닝합니다. 간소화된 설치 관리자 이미지를 생성하는 데 사용한 사용자 이름 및 암호를 사용하여 배포된 시스템에 로그인할 수 있습니다.
RHEL for Edge Simplified Installer 이미지는 장치에 대한 무인 설치에 최적화되어 네트워크 기반 배포 및 비 네트워크 기반 배포를 모두 지원합니다. 그러나 네트워크 기반 배포의 경우 UEFI HTTP 부팅만 지원합니다.
에지 이미지용 간소화된 RHEL을 작성 및 배포하려면 다음과 같은 고급 단계가 포함됩니다.
- RHEL 시스템 설치 및 등록
- RHEL 이미지 빌더 설치
- RHEL 이미지 빌더를 사용하여 RHEL for Edge Container 이미지에 대한 사용자 지정으로 블루프린트를 생성
- RHEL 이미지 빌더에서 RHEL for Edge 블루프린트 가져오기
- 커밋을 OSTree 리포지토리로 배포할 준비가 된 웹 서버를 사용하여 OCI 컨테이너에 에지 이미지 embed를 만듭니다.
-
edge-simplified-installer
이미지에 대한 청사진 생성 - Edge 이미지용으로 간소화된 RHEL 빌드
- Edge 간소화된 이미지를 위한 RHEL 다운로드
-
edge-simplified-installer
virt-install을 사용하여 원시 이미지 설치
다음 다이어그램은 Edge Simplified 빌드 및 프로비저닝 워크플로용 RHEL을 나타냅니다.
그림 6.1. 네트워크 기반 환경에서 RHEL for Edge 빌드 및 프로비저닝
6.2. RHEL 이미지 빌더 CLI를 사용하여 간소화된 이미지용 블루프린트 생성
에지 이미지에 대한 간소화된 RHEL에 대한 청사진을 생성하려면 장치 파일
위치와 장치 자격 증명 교환을 수행할 URL과 URL
을 사용하여 사용자 지정해야 합니다. 또한 사용자 및 사용자 그룹을 hieradata에 지정해야 합니다. 이를 위해 단계를 따르십시오.
절차
다음 콘텐츠를 사용하여 Tom의 Obvious, Minimal Language(TOML) 형식으로 일반 텍스트 파일을 생성합니다.
name = "simplified-installer-blueprint" description = "blueprint for the simplified installer image" version = "0.0.1" packages = [] modules = [] groups = [] distro = "" [customizations] installation_device = "/dev/vda" [[customizations.user]] name = "admin" password = "admin" groups = ["users", "wheel"] [customizations.fdo] manufacturing_server_url = "http://10.0.0.2:8080" diun_pub_key_insecure = "true"
참고청사진의 FDO 사용자 지정은 선택 사항이며 오류 없이 Edge Simplified Installer 이미지를 위한 RHEL을 빌드할 수 있습니다.
- name 은 name이고 description 은 distribution에 대한 설명입니다.
- 0.0.1 은 Semantic Versioning scheme에 따른 버전 번호입니다.
- 모듈은 이미지에 설치할 패키지 이름 및 일치하는 버전 글러스트를 설명합니다. 예를 들어 패키지 이름 = "tmux"이고 일치하는 버전은 version = "2.9a"입니다. 현재는 패키지와 모듈간에 차이가 없습니다.
-
그룹은 이미지에 설치할 패키지 그룹입니다(예:
anaconda-tools
그룹 패키지). 모듈과 그룹을 모르는 경우 비워 두십시오. - 설치 장치는 장치에 자동 설치를 활성화하기 위한 사용자 지정입니다.
- manufacturing_server_url 은 초기 장치 인증 정보 교환을 수행하는 URL입니다.
- name 은 이미지에 로그인할 사용자 이름입니다.
- 암호는 선택한 암호입니다.
- 그룹은 "widget"과 같은 모든 사용자 그룹입니다.
블루프린트를 RHEL 이미지 빌더 서버로 푸시(가져오기)합니다.
# composer-cli blueprints push blueprint-name.toml
기존 Makefile을 나열하여 생성된 inventory가 성공적으로 푸시되고 있는지 확인합니다.
# composer-cli blueprints show blueprint-name
Makefile 및 해당 종속 항목에 나열된 구성 요소 및 버전이 유효한지 확인합니다.
# composer-cli blueprints depsolve blueprint-name
6.3. 이미지 빌더 CLI를 사용하여 Edge Simplified Installer 이미지 생성
RHEL 이미지 빌더 명령줄 인터페이스를 사용하여 RHEL for Edge Simplified 이미지를 생성하려면 다음 사전 요구 사항을 충족했는지 확인한 다음 절차를 따르십시오.
사전 요구 사항
- Edge Simplified 이미지에 대한 RHEL에 대한 청사진을 생성했습니다.
- 이미지에 포함할 커밋의 OSTree 리포지터리를 제공하셨습니다. 예: http://10.0.2.2:8080/repo. Edge 이미지용 RHEL을 설치할 웹 서버 설정을 참조하십시오.
절차
부팅 가능한 ISO 이미지를 생성합니다.
# composer-cli compose start-ostree \ blueprint-name \ edge-simplified-installer \ --ref rhel/9/x86_64/edge \ --url URL-OSTree-repository \
여기서,
-
representing-name
은 Edge의 이름이 RHEL입니다. -
edge-simplified-installer
는 이미지 유형입니다. -
--ref
는 커밋을 생성할 위치에 대한 참조입니다. --
URL은 이미지에 포함할 커밋의 OSTree 리포지토리의 URL입니다. 예: http://10.0.2.2:8080/repo/. Edge Container에 대한 RHEL을 시작하거나 웹 서버를 설정할 수 있습니다. 네트워크 기반이 아닌 배포를 위한 RHEL for Edge 컨테이너 이미지 생성 및 RHEL for Edge 이미지를 설치할 웹 서버 설정을 참조하십시오.쓰기 프로세스가 큐에 추가되었음을 확인합니다. 또한 생성된 이미지에 대한 UUID(Universally Unique Identifier) 번호를 표시합니다. UUID 번호를 사용하여 빌드를 추적합니다. 또한 추가 작업을 위해 UUID 번호를 편리하게 유지합니다.
-
이미지 compose 상태를 확인합니다.
# composer-cli compose status
출력에는 다음 형식으로 상태가 표시됩니다.
<UUID> RUNNING date blueprint-name blueprint-version image-type
참고이미지 생성 프로세스를 완료하는 데 최대 10분이 걸릴 수 있습니다.
이미지 생성 프로세스를 중단하려면 다음을 실행합니다.
# composer-cli compose cancel <UUID>
기존 이미지를 삭제하려면 다음을 실행합니다.
# composer-cli compose delete <UUID>
6.4. 이미지 빌더 명령줄 인터페이스를 사용하여 Edge 이미지에 대한 간소화된 RHEL 다운로드
RHEL 이미지 빌더 명령줄 인터페이스를 사용하여 RHEL for Edge 이미지를 다운로드하려면 다음 사전 요구 사항을 충족했는지 확인한 다음 절차를 따르십시오.
사전 요구 사항
- 에지 이미지용 RHEL을 생성했습니다.
절차
RHEL for Edge 이미지 상태를 검토합니다.
# composer-cli compose status
출력에 다음이 표시되어야 합니다.
$ <UUID> FINISHED date blueprint-name blueprint-version image-type
이미지를 다운로드합니다.
# composer-cli compose image <UUID>
RHEL 이미지 빌더는 명령을 실행하는 현재 디렉터리 경로에서 이미지를
.iso
파일로 다운로드합니다.UUID 번호와 이미지 크기가 함께 표시됩니다.
$ <UUID>-simplified-installer.iso: size MB
그 결과 Edge Simplified Installer ISO 이미지에 대한 RHEL을 다운로드했습니다. 부팅 ISO로 직접 사용하여 Edge 시스템에 RHEL을 설치할 수 있습니다.
6.5. 이미지 빌더 GUI를 사용하여 간소화된 이미지 RHEL용 블루프린트 생성
Edge Simplified Installer 이미지를 위한 RHEL을 생성하려면 다음을 사용하여 청사진을 생성하고 사용자 지정해야 합니다.
- 장치에 강제적으로 설치할 수 있는 장치 노드 위치입니다.
- 초기 장치 인증 정보 교환을 수행하는 URL입니다.
- 사용자 또는 사용자 그룹입니다.
이미지에 필요한 다른 사용자 정의도 추가할 수 있습니다.
RHEL 이미지 빌더 GUI에서 간소화된 RHEL for Edge 이미지에 대한 블루프린트를 생성하려면 다음 단계를 완료하십시오.
사전 요구 사항
- 브라우저에서 웹 콘솔에서 이미지 빌더 앱을 열었습니다. RHEL 웹 콘솔에서 RHEL 이미지 빌더 GUI 액세스를 참조하십시오.
절차
RHEL 이미지 빌더 앱의 오른쪽 상단에 있는 블루프린트 생성을 클릭합니다.
청사진 이름 및 설명에 대한 필드가 포함된 대화 상자 마법사가 열립니다.
세부 정보
페이지에서 다음을 수행합니다.- 사용자 이름 및 선택적으로 해당 설명을 입력합니다. 을 클릭합니다.
선택 사항: 패키지 페이지에서 다음 단계를 완료하십시오.
사용 가능한 패키지 검색에서 패키지
이름을 입력하고 > 버튼 클릭하여 C respectiven packages 필드로 이동합니다. 원하는 만큼 패키지를 검색하고 포함합니다. 을 클릭합니다.참고달리 지정하지 않는 한 사용자 정의는 모두 선택 사항입니다.
-
선택 사항:
커널
페이지에서 커널 이름과 명령줄 인수를 입력합니다. -
선택 사항: OSTree 이미지에 읽기 전용과 같은 자체 마운트 규칙이 있으므로
파일 시스템
페이지에서자동 파티션 사용을
선택합니다. OSTree 시스템에 파일 시스템 사용자 지정은 지원되지 않습니다. 을 클릭합니다. 선택 사항:
서비스
페이지에서 서비스를 활성화하거나 비활성화할 수 있습니다.- 활성화 또는 비활성화할 서비스 이름을 입력하거나 쉼표로, 공백으로 또는 키를 눌러 입력합니다. 을 클릭합니다.
선택 사항:
방화벽
페이지에서 방화벽 설정을 설정합니다.-
포트
및 활성화 또는 비활성화하려는 방화벽 서비스를 입력합니다. - 버튼을 클릭하여 각 영역의 방화벽 규칙을 독립적으로 관리합니다. 을 클릭합니다.
-
사용자
페이지에서 단계에 따라 사용자를 추가합니다.- 클릭합니다.
사용자
이름
,암호
,SSH 키
를 입력합니다.서버 관리자
확인란을 클릭하여 사용자를 권한 있는 사용자로 표시할 수도 있습니다.참고사용자 지정에서 사용자를 지정한 다음 해당에서 이미지를 생성하면, 설치 시
/usr/lib/passwd
디렉토리와 암호가/usr/etc/shadow
아래에 생성됩니다. 사용자가 생성한 사용자 이름과 암호를 사용하여 장치에 로그인할 수 있습니다. 시스템에 액세스한 후useradd
명령을 사용하여 사용자를 생성해야 합니다.
선택 사항:
그룹
페이지에서 다음 단계를 완료하여 그룹을 추가합니다.-
그룹 이름과
를 입력합니다. 더 많은 그룹을 추가할 수 있습니다. 을 클릭합니다.그룹
ID
-
선택 사항:
SSH 키 페이지에서 키
를 추가합니다.- SSH 키를 입력합니다.
-
사용자
를 입력합니다. 을 클릭합니다.
선택 사항:
Timezone
페이지에서 시간대 설정을 설정합니다.Timezone
필드에 시스템 이미지에 추가할 시간대를 입력합니다. 예를 들어 다음 시간대 형식을 추가합니다. "US/E disastern".시간대를 설정하지 않으면 시스템은 UTC(Universal Time), Coordinated(UTC)를 기본값으로 사용합니다.
-
NTP
서버를 입력합니다. 을 클릭합니다.
선택 사항:
로컬
페이지에서 다음 단계를 완료합니다.-
10.0.0.1
검색
필드에 시스템 이미지에 추가할 패키지 이름을 입력합니다. 예: [ "en_US.UTF-8"]. -
Languages
검색 필드에 시스템 이미지에 추가할 패키지 이름을 입력합니다. 예: "us". 을 클릭합니다.
-
10.0.0.1
필수:
기타
페이지에서 다음 단계를 완료합니다.-
Hostname
필드에 시스템 이미지에 추가할 호스트 이름을 입력합니다. 호스트 이름을 추가하지 않으면 운영 체제에서 호스트 이름을 결정합니다. -
필수:
설치 장치
필드에 시스템 이미지의 올바른 노드를 입력하여 장치에 대한 번거로움 설치를 활성화합니다. 예:dev/sda1
. 을 클릭합니다.
-
선택 사항:
FIDO 장치 온보딩
페이지에서 다음 단계를 완료하십시오.-
Manufacturing server URL
필드에서manufacturing 서버 URL
을 입력하여 초기 장치 인증 정보 교환을 수행합니다(예: "http://10.0.0.2:8080"). 청사진의 FDO 사용자 지정은 선택 사항이며 오류 없이 Edge Simplified Installer 이미지를 위한 RHEL을 빌드할 수 있습니다. -
DIUN 공개 키 비보안
필드에 인증 공개 키 해시를 입력하여 초기 장치 인증 정보 교환을 수행합니다. 이 필드는 "true"를 값으로 허용하므로 이는 제조 서버에 대한 비보안 연결임을 의미합니다. 예:manufacturing_server_url="http://${FDO_SERVER}:8080" diun_pub_key_insecure="true"
. "key insecure", "key hash", "key root certs" 세 가지 옵션 중 하나만 사용해야 합니다. DIUN 공개 키 해시
필드에 공개 키의 해시 버전을 입력합니다. 예를 들어 다음과 같습니다.17BD05952222C421D6F1BB1256E0C925310CED4CE1C4FFD6E5CB968F4B73BF73
. 제조 서버의 인증서에 따라 키 해시를 생성할 수 있습니다. 키 해시를 생성하려면 다음 명령을 실행합니다.# openssl x509 -fingerprint -sha256 -noout -in /etc/fdo/aio/keys/diun_cert.pem | cut -d"=" -f2 | sed 's/://g'
/etc/fdo/aio/keys/diun_cert.pem
은 제조 서버에 저장된 인증서입니다.DIUN 공개 키 루트 인증서
필드에 공개 키 루트 인증서를 입력합니다. 이 필드는 제조 서버에 저장된 인증 파일의 내용을 허용합니다. 인증서 파일의 내용을 가져오려면 다음 명령을 실행합니다.$ cat /etc/fdo/aio/keys/diun_cert.pem.
-
- 을 클릭합니다.
-
검토
페이지에서 청사진에 대한 세부 사항을 검토합니다. 을 클릭합니다.
RHEL 이미지 빌더 보기가 열리고 기존 블루프린트가 나열됩니다.
6.6. 이미지 빌더 GUI를 사용하여 Edge Simplified Installer 이미지용 RHEL 생성
RHEL 이미지 빌더 GUI를 사용하여 RHEL for Edge Simplified 이미지를 생성하려면 다음 사전 요구 사항을 충족했는지 확인한 다음 절차를 따르십시오.
사전 요구 사항
- 브라우저에서 웹 콘솔에서 RHEL 이미지 빌더 앱을 열었습니다.
- Edge Simplified 이미지에 대한 RHEL에 대한 청사진을 생성했습니다.
-
이미지에 포함할 커밋의 OSTree 리포지터리를 제공했습니다(예:
http://10.0.2.2:8080/repo
). RHEL for Edge 이미지를 설치할 웹 서버 설정을 참조하십시오. - FDO 제조 서버가 실행 중입니다.
절차
- mage 빌더 대시보드에 액세스합니다.
- 청사진 테이블에서 이미지를 빌드하려는 청사진을 찾습니다.
-
Images
(이미지) 탭으로 이동하여Create Image
(이미지 만들기)를 클릭합니다.이미지 생성
마법사가 열립니다. 이미지 출력
페이지에서 다음 단계를 완료합니다.-
Select aoctavia 목록에서
RHEL for Edge Simplified image를 위해 생성한 Blueprint를 선택합니다. -
이미지 출력 유형
목록에서Edge Simplified Installer(.iso)에 대해 RHEL
을 선택합니다. -
이미지 크기
필드에 이미지 크기를 입력합니다. 단순화된 설치 관리자 이미지에 필요한 최소 이미지 크기는 다음과 같습니다.
-
- 을 클릭합니다.
OSTree 설정
페이지에서 다음 단계를 완료합니다.-
리포지토리 URL
필드에 상위 OSTree 커밋을 가져올 리포지토리 URL을 입력합니다. -
Ref
필드에ref
분기 이름 경로를 입력합니다.ref
-
-
검토
페이지에서 이미지 사용자 지정을 검토하고 클릭합니다.
이미지 빌드가 시작되고 완료하는 데 최대 20분이 걸립니다. 빌드를 중지하려면
를 클릭합니다.6.7. 이미지 빌더 GUI를 사용하여 엣지 이미지용 간소화된 RHEL 다운로드
RHEL 이미지 빌더 GUI를 사용하여 RHEL for Edge 이미지를 다운로드하려면 다음 사전 요구 사항을 충족했는지 확인한 다음 절차를 따르십시오.
사전 요구 사항
- 에지 이미지에 대한 RHEL을 성공적으로 생성했습니다. 링크를 참조하십시오.
절차
- RHEL 이미지 빌더 대시보드에 액세스합니다. dashboard가 열립니다.
- Edge Simplified Installer 이미지를 위해 RHEL을 구축한 Blueprint를 확인하십시오.
-
Images
(이미지) 탭으로 이동합니다. 옵션 중 하나를 선택합니다.
- 이미지를 다운로드합니다.
- 이미지 로그를 다운로드하여 요소를 검사하고 문제가 있는지 확인합니다.
Edge 시스템용 RHEL을 부팅 ISO로 직접 다운로드한 Edge Simplified Installer ISO 이미지를 사용할 수 있습니다.
6.8. UEFI HTTP Boot 서버 설정
UEFI HTTP Boot 서버에 연결하여 네트워크를 통해 에지 가상 머신용 RHEL을 프로비저닝할 수 있도록 UEFI HTTP Boot 서버를 설정하려면 다음 단계를 따르십시오.
사전 요구 사항
- ISO 단순화된 설치 프로그램 이미지를 생성했습니다.
- ISO 콘텐츠를 제공하는 http 서버입니다.
절차
선택한 디렉터리에 ISO 이미지를 마운트합니다.
# mkdir /mnt/rhel9-install/ # mount -o loop,ro -t iso9660 /path_directory/installer.iso /mnt/rhel9-install/
/path_directory/installer.iso
를 에지 부팅 가능 ISO 이미지의 RHEL 경로로 교체합니다.마운트된 이미지의 파일을 HTTP 서버 루트에 복사합니다. 이 명령은 이미지 콘텐츠를 사용하여
/var/www/html/rhel9-install/
디렉터리를 생성합니다.# mkdir /var/www/html/httpboot/ # cp -R /mnt/rhel9-install/* /var/www/html/httpboot/ # chmod -R +r /var/www/html/httpboot/*
참고일부 복사 방법은 유효한 설치 소스에 필요한
.treeinfo
파일을 건너뛸 수 있습니다. 이 절차에 표시된 대로 전체 디렉토리에 대해cp
명령을 실행하면.treeinfo
가 올바르게 복사됩니다.다음을 교체하여
/var/www/html/EFI/BOOT/grub.cfg
파일을 업데이트합니다.-
coreos.inst.install_dev=/dev/sda
withcoreos.inst.install_dev=/dev/vda
-
linux /images/pxeboot/vmlinuz
withlinuxefi /images/pxeboot/vmlinuz
-
initrd /images/pxeboot/initrd.img
withinitrdefi /images/pxeboot/initrd.img
coreos.inst.image_file=/run/media/iso/disk.img.xz
withcoreos.inst.image_url=http://{IP-ADDRESS}/disk.img.xz
IP-ADDRESS 는 이 시스템의 IP 주소로 http 부팅 서버로 사용됩니다.
-
httpd 서비스를 시작합니다.
# systemctl start httpd.service
결과적으로 UEFI HTTP 부팅을 설정한 후 UEFI HTTP 부팅 을 사용하여 에지 장치에 대해 RHEL을 설치할 수 있습니다.
6.9. 가상 머신에 단순화된 ISO 이미지 배포
다음 설치 소스를 사용하여 Edge Simplified 이미지용 RHEL을 생성하여 생성한 Edge ISO 이미지에 대한 RHEL을 배포합니다.
- UEFI HTTP Boot
- virt-install
이 예에서는 네트워크 기반 설치의 ISO 이미지에서 virt-install 설치 소스를 생성하는 방법을 보여줍니다.
사전 요구 사항
- ISO 이미지를 생성했습니다.
- UEFI HTTP 부팅을 지원하는 네트워크 구성을 설정했습니다.
절차
- UEFI HTTP 부팅을 지원하기 위해 네트워크 구성을 설정합니다. libvirt를 사용하여 UEFI HTTP 부팅 설정을 참조하십시오.
virt-install
명령을 사용하여 UEFI HTTP Boot에서 Edge Virtual Machine용 RHEL을 생성합니다.# virt-install \ --name edge-install-image \ --disk path=” “, ,format=qcow2 --ram 3072 \ --memory 4096 \ --vcpus 2 \ --network network=integration,mac=mac_address \ --os-type linux --os-variant rhel9 \ --cdrom "/var/lib/libvirt/images/”ISO_FILENAME" --boot uefi,loader_ro=yes,loader_type=pflash,nvram_template=/usr/share/edk2/ovmf/OVMF_VARS.fd,loader_secure=no --virt-type kvm \ --graphics none \ --wait=-1 --noreboot
명령을 실행하면 가상 머신 설치가 시작됩니다.
검증
- 생성된 가상 머신에 로그인합니다.
6.10. USB 플래쉬 드라이브에서 Simplified ISO 이미지 배포
USB 설치를 사용하여 Edge Simplified 이미지용 RHEL을 생성하여 생성한 에지 ISO 이미지용 RHEL을 배포합니다.
이 예에서는 ISO 이미지에서 USB 설치 소스를 생성하는 방법을 보여줍니다.
사전 요구 사항
- ISO 이미지인 간소화된 설치 프로그램 이미지를 생성했습니다.
- 8GB USB 플래쉬 드라이브가 있습니다.
절차
- ISO 이미지 파일을 USB 플래쉬 드라이브에 복사합니다.
- USB 플래시 드라이브를 부팅하려는 컴퓨터의 포트에 연결합니다.
USB 플래쉬 드라이브에서 ISO 이미지를 부팅합니다. 부팅 메뉴는 다음 옵션을 보여줍니다.
Install Red Hat Enterprise Linux 9 Test this media & install Red Hat Enterprise Linux 9
- Choose Install Red Hat Enterprise Linux 9. 그러면 시스템 설치가 시작됩니다.
추가 리소스
6.11. FIPS 모드에서 RHEL for Edge 이미지 생성 및 부팅
FIPS가 활성화된 RHEL for Edge 이미지를 생성하고 부팅할 수 있습니다. 결과 이미지에서 FIPS 모드를 활성화할지 여부를 블루프린트에서 지정할 수 있습니다. 기본값은 false
입니다.
FIPS 모드에서 다음 이미지 유형을 빌드할 수 있습니다.
-
edge-installer
-
edge-simplified-installer
-
edge-raw-image
-
edge-ami
-
edge-vsphere
이미지 프로비저닝 프로세스 중에만 FIPS 모드를 활성화할 수 있습니다. FIPS 이미지 빌드가 시작된 후에는 FIPS 모드로 변경할 수 없습니다. FIPS 활성화된 이미지를 빌드하는 호스트가 FIPS가 활성화되지 않은 경우 이 호스트에서 생성한 모든 키는 FIPS와 호환되지 않지만 결과 이미지는 예상대로 FIPS와 호환됩니다.
사전 요구 사항
- Edge 컨테이너 OSTree 커밋을 위한 RHEL을 생성하고 다운로드했습니다.
- 시스템에 Podman이 설치되어 있어야 합니다. RHEL에서 Podman을 설치하는 방법을 참조하십시오.
절차
다음 콘텐츠를 사용하여 Tom의 Obvious, Minimal Language (TOML) 형식으로 일반 텍스트 파일을 만듭니다.
name = "system-fips-mode-enabled" description = "blueprint with FIPS enabled " version = "0.0.1" [ostree] ref= "example/edge" url= "http://example.com/repo" [customizations] installation_device = "/dev/vda" fips = true [[customizations.user]] name = "admin" password = "admin" groups = ["users", "wheel"] [customizations.fdo] manufacturing_server_url = "https://fdo.example.com" diun_pub_key_insecure = true
블루프린트를 RHEL 이미지 빌더 서버로 가져옵니다.
# composer-cli blueprints push blueprint-name.toml
기존 블루프린트를 나열하여 생성된 블루프린트를 성공적으로 가져오고 존재하는지 확인합니다.
# composer-cli blueprints show blueprint-name
Makefile 및 해당 종속 항목에 나열된 구성 요소 및 버전이 유효한지 확인합니다.
# composer-cli blueprints depsolve blueprint-name
- 이미지에 포함할 커밋의 OSTree 리포지토리를 제공합니다(예: http://10.0.2.2:8080/repo ). 자세한 내용은 UEFI HTTP Boot 서버 설정을 참조하십시오.
부팅 가능한 ISO 이미지를 생성합니다.
# composer-cli compose start-ostree \ blueprint-name \ edge-simplified-installer \ --ref rhel/8/x86_64/edge \ --url URL-OSTree-repository \
RHEL for Edge 이미지 상태를 확인합니다.
# composer-cli compose status … $ <UUID> FINISHED date blueprint-name blueprint-version image-type …
이미지를 다운로드합니다.
# composer-cli compose image <UUID>
RHEL 이미지 빌더는 명령을 실행하는 현재 디렉터리 경로에서 이미지를
.iso
파일로 다운로드합니다. UUID 번호와 이미지 크기가 다음과 같이 표시됩니다.$ <UUID>-simplified-installer.iso: size MB
UEFI HTTP Boot에서 RHEL for Edge 가상 머신을 생성합니다. 예를 들면 다음과 같습니다.
# virt-install \ --name edge-device --disk path="/var/lib/libvirt/images/edge-device.qcow2",size=5,format=qcow2 \ --memory 4096 \ --vcpus 2 \ --network network=default \ --os-type linux \ --os-variant rhel8.9 \ --cdrom /var/lib/libvirt/images/<UUID>-simplified-installer.iso \ --boot uefi,loader.secure=false \ --virt-type kvm \ --graphics none \ --wait=-1 \ --noreboot
명령을 실행하면 가상 머신 설치가 시작됩니다.
검증
- 블루프린트에서 구성한 사용자 이름과 암호를 사용하여 생성된 가상 머신에 로그인합니다.
FIPS 설정이 활성화되어 있는지 확인합니다.
$ fips-mode-setup –check … FIPS mode is enabled …
7장. 최소한의 원시 이미지 빌드 및 프로비저닝
최소-raw
이미지는 사전 패키지되고 부팅 가능한 최소 RPM 이미지이며 xz
형식으로 압축됩니다. 이미지는 배포된 기존 OSTree 커밋이 있는 파티션 레이아웃이 포함된 파일로 구성됩니다. RHEL 이미지 빌더를 사용하여 RHEL for Edge 최소 원시 이미지 유형을 빌드하고 최소 원시 이미지를 aarch64
및 x86
아키텍처에 배포할 수 있습니다.
7.1. 최소 원시 이미지 빌드 및 배포
최소 이미지 유형을 사용하여 RHEL for Edge 최소 원시
이미지를 빌드합니다. 이미지를 부팅하려면 압축을 풀고 SD 카드 또는 USB 플래시 드라이브와 같은 부팅 가능한 장치에 복사해야합니다. RHEL for Edge Minimal Raw 이미지를 생성하는 데 사용한 블루프린트에 지정한 사용자 이름 및 암호를 사용하여 배포된 시스템에 로그인할 수 있습니다.
RHEL for Edge Minimal Raw 이미지를 구성 및 배포하려면 다음과 같은 상위 수준 단계를 수행해야 합니다.
- RHEL 시스템 설치 및 등록
- RHEL 이미지 빌더 설치
- RHEL 이미지 빌더를 사용하여 RHEL for Edge Minimal Raw 이미지에 대한 사용자 지정으로 블루프린트를 생성
- RHEL 이미지 빌더에서 RHEL for Edge 블루프린트 가져오기
- RHEL for Edge 최소 원시 이미지 생성
- RHEL for Edge 최소 원시 이미지 다운로드 및 압축 해제
- 압축 해제된 원시 이미지에서 부팅 가능한 USB 드라이브를 생성
- RHEL for Edge 최소 원시 이미지 배포
7.2. RHEL 이미지 빌더 CLI를 사용하여 최소 원시 이미지용 블루프린트 생성
블루프린트를 생성하고 사용자 이름과 암호로 사용자 지정합니다. 결과 블루프린트를 사용하여 최소 원시 이미지를 생성하고 블루프린트에서 구성한 인증 정보를 사용하여 로그인할 수 있습니다.
절차
다음 콘텐츠를 사용하여 Tom의 Obvious, Minimal Language(TOML) 형식으로 일반 텍스트 파일을 생성합니다.
name = "minimal-raw-blueprint" description = "blueprint for the Minimal Raw image" version = "0.0.1" packages = [] modules = [] groups = [] distro = "" [[customizations.user]] name = "admin" password = "admin" groups = ["users", "wheel"]
- name은 이름이며 설명은 블루프린트에 대한 설명입니다.
- 0.0.1은 Semantic Versioning 체계에 따른 버전 번호입니다.
- 모듈은 이미지에 설치할 패키지 이름 및 일치하는 버전 glob를 설명합니다(예: 패키지 name = "tmux" 및 일치하는 버전 glob는 version = "2.9a"입니다. 현재는 패키지와 모듈 간에 차이가 없습니다.
- 그룹은 이미지에 설치할 패키지 그룹입니다(예: anaconda-tools 그룹 패키지). 모듈과 그룹을 모르는 경우 비워 두십시오.
custom
.user
에서 :-
이미지에 로그인할 사용자
이름입니다
. -
암호는
선택한 암호입니다. -
그룹은
"widget"과 같은 모든 사용자 그룹입니다.
-
이미지에 로그인할 사용자
블루프린트를 RHEL 이미지 빌더 서버로 가져옵니다.
# composer-cli blueprints push <blueprint_name>.toml
시스템에서 블루프린트를 사용할 수 있는지 확인합니다.
# composer-cli blueprints list
블루프린트에서 구성 요소, 버전 및 해당 종속 항목의 유효성을 확인합니다.
# composer-cli blueprints depsolve <blueprint_name>
7.3. RHEL 이미지 빌더 CLI를 사용하여 최소 원시 이미지 생성
RHEL 이미지 빌더 명령줄 인터페이스를 사용하여 RHEL for Edge 최소 원시 이미지를 생성합니다.
사전 요구 사항
- RHEL for Edge Minimal Raw 이미지에 대한 블루프린트를 생성했습니다.
절차
이미지를 빌드합니다.
# composer-cli compose start <blueprint_name> minimal-raw
-
<blueprint_name&
gt;은 RHEL for Edge 블루프린트 이름입니다. -
minimal-raw
는 이미지 유형입니다.
-
이미지 compose 상태를 확인합니다.
# composer-cli compose status
출력에는 다음 형식으로 상태가 표시됩니다.
# <UUID> RUNNING date <blueprint_name> blueprint-version minimal-raw
7.4. 최소 원시 이미지 다운로드 및 압축 해제
RHEL 이미지 빌더 명령줄 인터페이스를 사용하여 RHEL for Edge Minimal Raw 이미지를 다운로드한 다음, 부팅할 수 있도록 이미지의 압축을 풉니다.
사전 요구 사항
- RHEL for Edge 최소 원시 이미지를 생성했습니다.
절차
RHEL for Edge 최소 원시 이미지 구성 상태를 검토합니다.
# composer-cli compose status
출력에 다음 세부 정보가 표시되어야 합니다.
$ <UUID> FINISHED date <blueprint_name> <blueprint_version> minimal-raw
이미지를 다운로드합니다.
# composer-cli compose image <UUID>
이미지 빌더는 이미지를 작업 디렉터리에 다운로드합니다. 다음 출력은 예제입니다.
3f9223c1-6ddb-4915-92fe-9e0869b8e209-raw.img.xz
이미지의 압축을 풉니다.
$ xz -d <UUID>-raw.img.xz
다음
에지 최소 원시 이미지에 압축 해제된 부팅 가능한 RHEL을 사용하여 부팅 가능한 설치 미디어를 생성하고 부팅 장치로 사용합니다. 다음 문서에서는 ISO 이미지에서 USB 부팅 가능 장치를 생성하는 절차를 설명합니다. 그러나 RAW 이미지가 ISO 이미지와 동일하므로 동일한 단계가 RAW 이미지에 적용됩니다.
자세한 내용은 Linux에서 부팅 가능한 USB 장치 생성 을 참조하십시오.
7.5. USB 플래시 드라이브에서 최소 원시 이미지 배포
사용자 지정 RHEL for Edge Minimal Raw 이미지에서 부팅 가능한 USB 설치 미디어를 생성한 후 USB 플래시 드라이브에서 최소 원시 이미지를 배포하고 사용자 지정된 이미지를 부팅하여 설치 프로세스를 계속할 수 있습니다.
사전 요구 사항
- 8GB USB 플래쉬 드라이브가 있습니다.
- RHEL for Edge Minimal Raw 이미지에서 USB 드라이브로 부팅 가능한 설치 미디어를 생성했습니다.
절차
- USB 플래시 드라이브를 사용자 지정 이미지를 부팅하려는 컴퓨터에 연결합니다.
- 시스템의 전원을 켭니다.
USB 플래시 드라이브에서 RHEL for Edge 최소 원시 이미지를 부팅합니다. 부팅 메뉴에는 다음 옵션이 표시됩니다.
Install Red Hat Enterprise Linux 9 Test this media & install Red Hat Enterprise Linux 9
- Install Red Hat Enterprise Linux 9 를 선택합니다. 그러면 시스템 설치가 시작됩니다.
검증
블루프린트에 구성한 사용자 이름과 암호를 사용하여 이미지로 부팅합니다.
릴리스를 확인합니다.
$ cat /etc/os-release
시스템의 블록 장치를 나열합니다.
$ lsblk
8장. 엣지 간소화 설치 관리자 이미지에 RHEL용 Ignition 툴 사용
RHEL for Edge는 Ignition 도구를 사용하여 부팅 프로세스의 초기 단계에서 이미지에 사용자 구성을 삽입합니다. Ignition 툴이 삽입하는 사용자 구성은 다음과 같습니다.
- 사용자 구성입니다.
-
일반 파일 및
systemd
장치와 같은 파일 작성.
첫 번째 부팅 시 Ignition은 원격 URL 또는 간소화된 설치 프로그램 ISO에 포함된 파일에서 구성을 읽습니다. 그런 다음 Ignition이 해당 구성을 이미지에 적용합니다.
8.1. Ignition 구성 파일 생성
Butane
툴은 Ignition 구성 파일을 생성하는 데 선호되는 옵션입니다. Butane
은 Butane Config YAML
파일을 사용하고 JSON 형식으로 Ignition
구성을 생성합니다. JSON 파일은 첫 번째 부팅 시 시스템에서 사용됩니다. Ignition 구성은
사용자 생성 및 systemd
장치 설치와 같은 이미지의 구성을 적용합니다.
사전 요구 사항
Butane 툴 버전 v0.17.0을 설치했습니다.
$ sudo dnf/yum install -y butane
절차
Butane Config
파일을 생성하여.bu
형식으로 저장합니다. RHEL의 경우변형
항목을r4e
,version
항목을1.0.0
으로 지정해야 합니다. 버전 1.0.0의 butaner4e
변형은 Ignition 사양 버전3.3.0
을 대상으로 합니다. 다음은 Butane Config YAML 파일 예제입니다.variant: r4e version: 1.0.0 ignition: config: merge: - source: http://192.168.122.1:8000/sample.ign passwd: users: - name: core groups: - wheel password_hash: password_hash_here ssh_authorized_keys: - ssh-ed25519 some-ssh-key-here storage: files: - path: /etc/NetworkManager/system-connections/enp1s0.nmconnection contents: inline: | [connection] id=enp1s0 type=ethernet interface-name=enp1s0 [ipv4] address1=192.168.122.42/24,192.168.122.1 dns=8.8.8.8; dns-search= may-fail=false method=manual mode: 0600 - path: /usr/local/bin/startup.sh contents: inline: | #!/bin/bash echo "Hello, World!" mode: 0755 systemd: units: - name: hello.service contents: | [Unit] Description=A hello world [Install] WantedBy=multi-user.target enabled: true - name: fdo-client-linuxapp.service dropins: - name: log_trace.conf contents: | [Service] Environment=LOG_LEVEL=trace
다음 명령을 실행하여
Butane Config YAML
파일을 사용하고 JSON 형식으로 Ignition 구성을 생성합니다.$ ./path/butane example.bu {"ignition":{"config":{"merge":[{"source":"http://192.168.122.1:8000/sample.ign"}]},"timeouts":{"httpTotal":30},"version":"3.3.0"},"passwd":{"users":[{"groups":["wheel"],"name":"core","passwordHash":"password_hash_here","sshAuthorizedKeys":["ssh-ed25519 some-ssh-key-here"]}]},"storage":{"files":[{"path":"/etc/NetworkManager/system-connections/enp1s0.nmconnection","contents":{"compression":"gzip","source":"data:;base64,H4sIAAAAAAAC/0yKUcrCMBAG3/csf/ObUKQie5LShyX5SgPNNiSr0NuLgiDzNMPM8VBFtHzoQjkxtPp+ITsrGLahKYyyGtoqEYNKwfeZc32OC0lKDb179rfg/HVyPgQ3hv8w/v0WT0k7T+7D/S1Dh7S4MRU5h1XyzqvsHVRg25G4iD5kp1cAAAD//6Cvq2ihAAAA"},"mode":384},{"path":"/usr/local/bin/startup.sh","contents":{"source":"data:;base64,IyEvYmluL2Jhc2gKZWNobyAiSGVsbG8sIFdvcmxkISIK"},"mode":493}]},"systemd":{"units":[{"contents":"[Unit]\nDescription=A hello world\n[Install]\nWantedBy=multi-user.target","enabled":true,"name":"hello.service"},{"dropins":[{"contents":"[Service]\nEnvironment=LOG_LEVEL=trace\n","name":"log_trace.conf"}],"name":"fdo-client-linuxapp.service"}]}}
Butane Config YAML
파일을 실행하여Ignition 구성 JSON
파일을 확인하고 생성한 후 파티션과 같이 지원되지 않는 필드를 사용할 때 경고를 받을 수 있습니다. 예를 들면 다음과 같습니다. 해당 필드를 수정하고 검사를 다시 실행할 수 있습니다.
이제 청사진을 사용자 지정하는 데 사용할 수 있는 Ignition JSON 구성 파일이 있습니다.
8.2. Ignition에 대한 지원을 통해 GUI에서 청사진 생성
단순화된 설치 관리자 이미지를 빌드할 때, 다음 세부 정보를 청사진 페이지에 입력하여 사용자 지정할 수 있습니다.
-
firstboot URL - 첫 번째 부팅
중에 가져올 Ignition 구성을 가리키는 URL을 입력해야 합니다. 원시 이미지와 간소화된 설치 프로그램 이미지에 모두 사용할 수 있습니다. -
임베디드 데이터
-base64
로 인코딩된Ignition 구성
파일을 제공해야 합니다. 단순화된 설치 관리자 이미지에만 사용할 수 있습니다.
Ignition 청사진 사용자 지정을 사용하여 Ignition 구성을 지원하는 에지 이미지에 대한 간소화된 RHEL을 사용자 정의하려면 다음 단계를 따르십시오.
사전 요구 사항
- 브라우저에서 웹 콘솔에서 이미지 빌더 앱을 열었습니다. RHEL 웹 콘솔에서 이미지 빌더 GUI 액세스를 참조하십시오.
-
내장된 섹션을 완전히 지원하기 위해
coreos-installer-dracut
은 OSBuild의 파일이 있는지에 따라-ignition-url
|-ignition-file
을 정의할 수 있어야 합니다.
절차
오른쪽 상단에 있는
를 클릭합니다.청사진 이름 및 설명에 대한 필드가 포함된 대화 상자 마법사가 열립니다.
세부 정보
페이지에서 다음을 수행합니다.- 사용자 이름 및 선택적으로 해당 설명을 입력합니다. 을 클릭합니다.
Ignition
페이지에서 다음 단계를 완료합니다.-
Firstboot URL
필드에 첫 번째 부팅 중에 가져올 Ignition 구성을 가리키는 URL을 입력합니다. -
CloudEvent
Data 필드에서
base64
로 인코딩된Ignition 구성
파일을 드래그하거나 업로드합니다. 을 클릭합니다.
-
- 이미지 세부 정보를 검토하고 클릭합니다.
이미지 빌더 대시보드 보기가 열리고 기존 청사진이 나열됩니다.
다음
- 간단하게 만든 설치 관리자 이미지를 빌드하기 위해 만든 청사진을 사용할 수 있습니다. 이미지 빌더 CLI를 사용하여 Edge Simplified Installer 이미지에 대한 RHEL 생성을 참조하십시오.
8.3. CLI를 사용하여 Ignition에 대한 지원이 포함된 청사진 생성
간소화된 설치 프로그램 이미지를 빌드할 때 customizations.ignition
섹션을 추가하여 청사진을 사용자 지정할 수 있습니다. 이를 통해 간소화된 설치 프로그램 이미지 또는 베어 메탈 플랫폼에 사용할 수 있는 원시 이미지를 생성할 수 있습니다. 청사진의 사용자 지정.ignition
사용자 지정을 통해 edge-simplified-installer
ISO 및 edge-raw-image
이미지에서 구성 파일을 사용할 수 있습니다.
Edge-simplified-installer
ISO 이미지의 경우 ISO 이미지에 포함될 Ignition 구성 파일을 포함하도록 청사진을 사용자 지정할 수 있습니다. 예를 들어 다음과 같습니다.[customizations.ignition.embedded] config = "eyJ --- BASE64 STRING TRIMMED --- 19fQo="
base64
로 인코딩된 Ignition 구성 파일을 제공해야 합니다.Edge-simplified-installer
ISO 이미지와edge-raw-image
모두에서 첫 번째 부팅 시 Ignition 구성을 가져오기 위해 가져올 URL을 정의하여 청사진을 사용자 지정할 수 있습니다. 예를 들어 다음과 같습니다.[customizations.ignition.firstboot] url = "http://your_server/ignition_configuration.ig"
첫 번째 부팅 중에 가져올 Ignition 구성을 가리키는 URL을 입력해야 합니다.
Ignition 구성을 지원하여 에지 이미지에 대해 간단한 RHEL에 대한 청사진을 사용자 정의하려면 다음 단계를 따르십시오.
사전 요구 사항
-
[customizations.ignition.em incorporatedded]
사용자 지정을 사용하는 경우 Ignition 구성 파일을 생성해야 합니다. -
[customizations.ignition.firstboot]
사용자 지정을 사용하는 경우 첫 번째 부팅 중에 가져올 Ignition 구성을 가리키는 URL이 있는 컨테이너를 생성해야 합니다. -
사용자 지정
[customizations.ignition.em cutded]
섹션을 사용하면 osbuild 파일의 존재 여부에 따라coreos-installer-dracut
을-ignition-url
|-ignition-file
을 정의할 수 있습니다.
절차
다음 콘텐츠를 사용하여 Tom의 Obvious, Minimal Language(TOML) 형식으로 일반 텍스트 파일을 생성합니다.
name = "simplified-installer-blueprint" description = "Blueprint with Ignition for the simplified installer image" version = "0.0.1" packages = [] modules = [] groups = [] distro = "" [customizations.ignition.embedded] config = "eyJ --- BASE64 STRING TRIMMED --- 19fQo="
다음과 같습니다.
-
name
은 name 및description
입니다. -
버전
은 Semantic Versioning scheme에 따른 버전 번호입니다. -
모듈
과패키지는
이미지에 설치할 패키지 이름과 일치하는 버전 glob를 설명합니다. 예를 들어 패키지이름 = "tmux"
및 일치하는 버전 glob는version = "3.3a"
입니다. 현재는 패키지와 모듈간에 차이가 없습니다. 그룹은
이미지에 설치할 패키지 그룹입니다. 예:groups = "anaconda-tools"
group package. 모듈과 그룹을 모르는 경우 비워 두십시오.주의Ignition으로 사용자를 생성하려면 FDO 사용자 정의를 사용하여 동시에 사용자를 생성할 수 없습니다. Ignition을 사용하여 사용자를 생성하고 FDO를 사용하여 구성 파일을 복사할 수 있습니다. 그러나 사용자를 생성하는 경우 Ignition 또는 FDO를 사용하여 생성하지만 둘 다 동시에 생성하지는 않습니다.
-
이미지 빌더 서버로 푸시(import)합니다.
# composer-cli blueprints push blueprint-name.toml
기존 Makefile을 나열하여 생성된 inventory가 성공적으로 푸시되고 있는지 확인합니다.
# composer-cli blueprints show blueprint-name
Makefile 및 해당 종속 항목에 나열된 구성 요소 및 버전이 유효한지 확인합니다.
# composer-cli blueprints depsolve blueprint-name
다음
- 간단하게 만든 설치 관리자 이미지를 빌드하기 위해 만든 청사진을 사용할 수 있습니다. 이미지 빌더 CLI를 사용하여 Edge Simplified Installer 이미지에 대한 RHEL 생성을 참조하십시오.
9장. RHEL for Edge용 VMDK 이미지 생성
RHEL 이미지 빌더를 사용하여 RHEL for Edge용 .vmdk
이미지를 생성할 수 있습니다. Ignition 지원을 사용하여 edge-vsphere
이미지 유형을 생성하여 부팅 프로세스의 초기 단계에서 사용자 구성을 이미지에 삽입할 수 있습니다. 그런 다음 vSphere에 이미지를 로드하고 vSphere VM에서 이미지를 부팅할 수 있습니다. 이미지는 ESXi 7.0 U2, ESXi 8.0 이상과 호환됩니다. vSphere VM은 버전 19 및 20과 호환됩니다.
9.1. Ignition 구성으로 블루프린트 생성
.vmdk
이미지에 대한 블루프린트를 생성하고 customizations.ignition
섹션으로 사용자 지정합니다. 이렇게 하면 이미지를 생성하고 부팅 시 운영 체제가 사용자 구성을 이미지에 삽입할 수 있습니다.
사전 요구 사항
Ignition 구성 파일을 생성했습니다. 예를 들어 다음과 같습니다.
{ "ignition":{ "version":"3.3.0" }, "passwd":{ "users":[ { "groups":[ "wheel" ], "name":"core", "passwordHash":"$6$jfuNnO9t1Bv7N" } ] } }
절차
다음 콘텐츠와 함께 Tom의 Obvious, Minimal Language (TOML) 형식으로 블루프린트를 생성합니다.
name = "vmdk-image" description = "Blueprint with Ignition for the vmdk image" version = "0.0.1" packages = ["open-vm-tools"] modules = [] groups = [] distro = "" [[customizations.user]] name = "admin" password = "admin" groups = ["wheel"] [customizations.ignition.firstboot] url = http://<IP_address>:8080/config.ig
다음과 같습니다.
-
name
은 name 및description
입니다. -
버전
은 Semantic Versioning scheme에 따른 버전 번호입니다. -
모듈
과패키지는
이미지에 설치할 패키지 이름과 일치하는 버전 glob를 설명합니다. 예를 들어 패키지이름 = "open-vm-tools"
입니다. 현재는 패키지와 모듈간에 차이가 없습니다. -
그룹은
이미지에 설치할 패키지 그룹입니다. 예:groups = "anaconda-tools"
group package. 모듈과 그룹을 모르는 경우 비워 두십시오. -
custom
.user
는 VM에 로그인할 사용자 이름과 암호를 생성합니다. custom
.ignition.firstboot
에는 Ignition 구성 파일이 제공되는 URL이 포함되어 있습니다.참고기본적으로
open-vm-tools
패키지는edge-vsphere
이미지에 포함되어 있지 않습니다. 이 패키지가 필요한 경우 블루프린트 사용자 지정에 포함해야 합니다.
-
블루프린트를 이미지 빌더 서버로 가져옵니다.
# composer-cli blueprints push <blueprint-name>.toml
기존 블루프린트를 나열하여 생성된 블루프린트가 성공적으로 푸시되어 있는지 확인합니다.
# composer-cli blueprints show <blueprint-name>
Makefile 및 해당 종속 항목에 나열된 구성 요소 및 버전이 유효한지 확인합니다.
# composer-cli blueprints depsolve <blueprint-name>
다음 단계
-
생성한 블루프린트를 사용하여
.vmdk
이미지를 빌드합니다.
9.2. RHEL for Edge용 VMDK 이미지 생성
RHEL for Edge .vmdk
이미지를 생성하려면 RHEL 이미지 빌더 명령줄 인터페이스에서 'edge-vsphere' 이미지 유형을 사용합니다.
사전 요구 사항
-
.vmdk
이미지에 대한 블루프린트를 생성하셨습니다. -
이미지에 포함하기 위해 커밋의 OSTree 리포지토리를 제공했습니다. 예:
http://10.0.2.2:8080/repo
. 자세한 내용은 RHEL for Edge 이미지를 설치할 웹 서버 설정을 참조하십시오.
절차
.vmdk
이미지의 구성을 시작합니다.# composer-cli compose start start-ostree <blueprint-name> edge-vsphere --<url>
-- <url& gt;은 리포지터리의 URL입니다(예:
http://10.88.0.1:8080/repo
).쓰기 프로세스가 큐에 추가되었음을 확인합니다. 또한 생성된 이미지에 대한 UUID(Universally Unique Identifier) 번호를 표시합니다. UUID 번호를 사용하여 빌드를 추적합니다. 또한 추가 작업에 대해 UUID 번호를 편리하게 유지합니다.
이미지 작성 상태를 확인합니다.
# composer-cli compose status
출력에는 다음 형식으로 상태가 표시됩니다.
$ <UUID> RUNNING date <blueprint-name> <blueprint-version> edge-vsphere
작성 프로세스가 완료되면 결과 이미지 파일을 다운로드합니다.
# composer-cli compose image <UUID>
다음 단계
-
.vmdk
이미지를 vSphere에 업로드합니다.
9.3. vSphere에서 VMDK 이미지 업로드 및 RHEL 가상 머신 생성
govc import
CLI 툴을 사용하여 VMware vSphere에 .vmdk 이미지를 업로드하고 VM에서 이미지를 부팅합니다.
.vmdk
사전 요구 사항
-
RHEL 이미지 빌더를 사용하여
.vmdk
이미지를 생성하고 호스트 시스템에 다운로드합니다. -
govc import.vmdk
CLI 툴을 설치했습니다. govc import.vmdk
CLI 툴 클라이언트를 구성했습니다.환경에서 다음 값을 설정해야 합니다.
GOVC_URL GOVC_DATACENTER GOVC_FOLDER GOVC_DATASTORE GOVC_RESOURCE_POOL GOVC_NETWORK
절차
-
.vmdk
이미지를 다운로드한 디렉터리로 이동합니다. 다음 단계를 실행하여 vSphere에서 이미지를 시작합니다.
.vmdk
이미지를 vSphere로 가져옵니다.$ govc import.vmdk ./composer-api.vmdk foldername
전원을 켜지 않고 vSphere에서 VM을 생성합니다.
govc vm.create \ -net="VM Network" -net.adapter=vmxnet3 \ -disk.controller=pvscsi -on=false \ -m=4096 -c=2 -g=rhel9_64Guest \ -firmware=efi vm_name govc vm.disk.attach \ -disk=”foldername/composer-api.vmdk” govc vm.power -on\ -vm vm_name -link=false \ vm_name
VM의 전원을 켭니다.
govc vm.power -on vmname
VM IP 주소를 검색합니다.
HOST=$(govc vm.ip vmname)
블루프린트에 지정한 사용자 이름과 암호를 사용하여 VM에 SSH를 사용하여 로그인합니다.
$ ssh admin@HOST
10장. RHEL for Edge AMI 이미지 생성
RHEL 이미지 빌더를 사용하여 RHEL for Edge Edge
사용자 지정 이미지를 생성할 수 있습니다. RHEL for Edge edge-ami
에는 부팅 프로세스의 초기 단계에서 이미지에 사용자 구성을 삽입할 수 있는 Ignition 지원이 있습니다. 그런 다음 이미지를 AWS 클라우드에 업로드하고 AWS에서 EC2 인스턴스를 시작할 수 있습니다. AMD 또는 Intel 64비트 아키텍처에서 AMI 이미지 유형을 사용할 수 있습니다.
10.1. Edge AMI 이미지용 블루프린트 생성
edge-ami
이미지에 대한 블루프린트를 생성하고 customization .ignition 섹션으로 사용자
지정합니다. 이를 통해 이미지를 생성하고 이미지를 부팅할 때 사용자 구성을 삽입할 수 있습니다.
사전 요구 사항
Ignition 구성 파일을 생성했습니다. 예를 들어 다음과 같습니다.
{ "ignition":{ "version":"3.3.0" }, "passwd":{ "users":[ { "groups":[ "wheel" ], "name":"core", "passwordHash":"$6$jfuNnO9t1Bv7N" } ] } }
자세한 내용은 Ignition 구성 파일 생성을 참조하십시오.
절차
다음 콘텐츠와 함께 Tom의 Obvious, Minimal Language (TOML) 형식으로 블루프린트를 생성합니다.
name = "ami-edge-image" description = "Blueprint for Edge AMI image" version = "0.0.1" packages = ["cloud-init"] modules = [] groups = [] distro = "" [[customizations.user]] name = "admin" password = "admin" groups = ["wheel"] [customizations.ignition.firstboot] url = http://<IP_address>:8080/config.ig
다음과 같습니다.
-
name
은 name 및description
입니다. -
버전
은 Semantic Versioning scheme에 따른 버전 번호입니다. -
모듈
과패키지는
이미지에 설치할 패키지 이름과 일치하는 버전 glob를 설명합니다. 예를 들어 패키지이름 = "open-vm-tools"
입니다. 현재는 패키지와 모듈간에 차이가 없습니다. -
그룹은
이미지에 설치할 패키지 그룹입니다. 예를 들어groups = "wheel"
입니다. 모듈과 그룹을 모르는 경우 비워 두십시오. -
custom
.user
는 VM에 로그인할 사용자 이름과 암호를 생성합니다. custom
.ignition.firstboot
에는 Ignition 구성 파일이 제공되는 URL이 포함되어 있습니다.참고기본적으로
open-vm-tools
패키지는edge-vsphere
이미지에 포함되어 있지 않습니다. 이 패키지가 필요한 경우 블루프린트 사용자 지정에 포함해야 합니다.
-
블루프린트를 이미지 빌더 서버로 가져옵니다.
# composer-cli blueprints push <blueprint-name>.toml
기존 블루프린트를 나열하여 생성된 블루프린트가 성공적으로 푸시되어 있는지 확인합니다.
# composer-cli blueprints show <blueprint-name>
Makefile 및 해당 종속 항목에 나열된 구성 요소 및 버전이 유효한지 확인합니다.
# composer-cli blueprints depsolve <blueprint-name>
다음 단계
-
생성한 블루프린트를 사용하여
edge-ami
이미지를 빌드합니다.
10.2. RHEL for Edge AMI 이미지 생성
RHEL 이미지 빌더 명령줄 인터페이스에서 RHEL for Edge edge-ami
이미지를 생성합니다.
사전 요구 사항
-
edge-ami
이미지에 대한 블루프린트를 생성하셨습니다. -
이미지에 포함하기 위해 커밋의 OSTree 리포지토리를 제공했습니다. 예:
http://10.0.2.2:8080/repo
. 자세한 내용은 RHEL for Edge 이미지를 설치할 웹 서버 설정을 참조하십시오.
절차
edge-ami
이미지의 구성을 시작합니다.# composer-cli compose start-ostree <blueprint-name> edge-ami –ref rhel/9/x86_64/edge --url <ostree repo url>
-- <ostree repo url
>은 리포지터리의 URL입니다(예:http://10.88.0.1:8080/{ <blueprint-name> }/repo
).쓰기 프로세스가 큐에 추가되었음을 확인합니다. 또한 생성된 이미지에 대한 UUID(Universally Unique Identifier) 번호를 표시합니다. UUID 번호를 사용하여 빌드를 추적합니다. 또한 추가 작업에 대해 UUID 번호를 편리하게 유지합니다.
이미지 작성 상태를 확인합니다.
# composer-cli compose status
출력에는 다음 형식으로 상태가 표시됩니다.
$ <UUID> RUNNING date <blueprint-name> <blueprint-version> edge-ami
작성 프로세스가 완료되면 결과 이미지 파일을 다운로드합니다.
# composer-cli compose image <UUID>
다음 단계
-
AWS에
edge-ami
이미지를 업로드합니다.
10.3. AWS에 RHEL Edge AMI 이미지 업로드
CLI를 사용하여 Edge-ami
이미지를 Amazon AWS Cloud 서비스 공급자에 업로드합니다.
사전 요구 사항
절차
aws-cli
툴을 구성합니다.$ aws configure
프로필을 구성합니다. 명령을 실행하고 Access 키 ID 인증 정보, 시크릿 액세스 키, 기본 리전 이름 및 기본 출력 이름을 입력합니다.
$ aws configure --profile
기존 버킷을 나열합니다.
$ aws s3 ls
이미지를 S3에 업로드합니다.
$ aws s3 cp <path_to_image/image> s3://<your_bucket_name>
S3 버킷의 이미지를 나열합니다.
$ aws s3 ls s3://<your_bucket_name>
container-simple.json
파일을 생성합니다. "URL" 콘텐츠를 S3 버킷으로 교체합니다. 예:s3://rhel-edge-ami-us-west-2/2ba3c125-cc58-4cc0-861a-4cc78e892df6-image.raw
.{ "Description": "RHEL for Edge image", "Format": "edge-ami", "Url": "s3://rhel-edge-ami-us-west-2/UUID-image.raw" }
edge.ami
이미지를 S3 버킷에 EC2 스냅샷으로 가져옵니다.참고EC2 이미지는 S3 버킷을 생성한 동일한 리전에 있어야 합니다.
$ aws ec2 import-snapshot --description "RHEL edge" \ --disk-container file://container-simple.json --region us-west-2
다음 .
json
: 명령 출력의 예입니다.{ "Description": "RHEL for Edge image", "Format": "edge-ami", "Url": "s3://rhel-edge-ami-us-west-2/UUID-image.raw" }
-
json의 "ImportTaskId" 값을 기록해 둡니다. 이를 사용하여 가져오기 상태를 확인합니다. 이 예제에서 "ImportTaskId"는
import-snap-0f3055c4b7a454c85
입니다. 이전 단계의 출력 json 파일에서 "ImportTaskId" 값을 사용하여 스냅샷의 가져오기 상태를 확인합니다.
$ aws ec2 describe-import-snapshot-tasks \ --import-task-ids import-snap-0f3055c4b7a454c85 { "ImportSnapshotTasks": [ { "Description": "RHEL edge", "ImportTaskId": "import-snap-0f3055c4b7a454c85", "SnapshotTaskDetail": { "Description": "RHEL edge", "DiskImageSize": 10737418240.0, "Format": "RAW", "SnapshotId": "snap-001b267e752039eab", "Status": "completed", "Url": "s3://rhel-edge-ami-us-west-2/2ba3c125-cc58-4cc0-861a-4cc78e892df6-image.raw", "UserBucket": { "S3Bucket": "rhel-edge-ami-us-west-2", "S3Key": "2ba3c125-cc58-4cc0-861a-4cc78e892df6-image.raw" } }, "Tags": [] } ] }
"상태"가 "완료됨"으로 표시될 때까지 이 명령을 실행합니다. 그 후 EC2에 액세스하여 스냅샷에서 AMI 이미지를 생성하고 시작할 수 있습니다.
검증
이미지 업로드에 성공했는지 확인하려면 다음을 수행하십시오.
- 메뉴에서 EC2에 액세스하고 AWS 콘솔에서 올바른 리전을 선택합니다. 이미지가 성공적으로 업로드되었음을 나타내기 위해 사용 가능한 상태가 있어야 합니다.
대시보드에서 이미지를 선택하고 시작을 클릭합니다.
새 인스턴스를 시작할 때 부팅 모드로 UEFI를 선택하고 EC2 이미지에 대해 4GB 이상의 RAM을 선택해야 합니다.
-
Ignition 구성으로 생성한 사용자 이름과 암호를 사용하여 AWS의
에지
에 로그인할 수 있습니다.
추가 리소스
11장. FDO를 사용하여 에지 장치용 RHEL 자동 프로비저닝 및 온보딩
Edge Simplified 설치 프로그램 이미지용 RHEL을 빌드하고 Edge 이미지용 RHEL에 프로비저닝할 수 있습니다. FIDO Device Onboarding (FDO) 프로세스는 에지 장치를 자동으로 프로비저닝 및 온보딩하고 네트워크에 연결된 다른 장치 및 시스템과 데이터를 교환합니다.
Red Hat은 FDO
프로세스를 기술 프리뷰 기능으로 제공하며 보안 네트워크에서 실행해야 합니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다. 기술 프리뷰 기능의 지원 범위에 대한 정보는 Red Hat Customer Portal의 기술 프리뷰 기능 지원 범위를 참조하십시오.
11.1. FIDO Device Onboarding (FDO) 프로세스
FIDO Device Onboarding (FDO)은 다음과 같은 프로세스입니다.
- 장치를 프로비저닝하고 온보딩합니다.
- 이 장치에 대한 자격 증명을 자동으로 구성합니다. FDO 프로세스는 새 장치를 설치하여 트리거하는 자동 온보딩 메커니즘입니다.
- 이 장치가 네트워크에서 안전하게 연결 및 상호 작용할 수 있도록 합니다.
FIDO Device Onboarding (FDO)을 사용하면 IoT 아키텍처에 새 장치를 추가하여 보안 장치를 수행할 수 있습니다. 여기에는 신뢰할 수 있고 실행 중인 나머지 시스템과 통합해야 하는 지정된 장치 구성이 포함됩니다. FDO 프로세스는 새 장치를 설치하여 트리거하는 자동 온보딩 메커니즘입니다.
FDO 프로토콜은 다음 작업을 수행합니다.
- 규모에 따라 장치를 안전하게 온보딩하는 데 필요한 자동화와 함께 신뢰 및 소유권 체인을 해결합니다.
- 실제 사용을 위해 제조 단계 및 늦은 장치 바인딩에서 장치 초기화를 수행합니다. 즉, 장치를 관리 시스템에 실제로 바인딩하는 것은 장치에서 수동으로 구성하지 않고도 장치의 첫 번째 부팅 시 수행됩니다.
- 엣지 위치에 특수한 사람이 필요하지 않은 자동화된 보안 장치 온보딩, 즉 제로 터치 설치 및 온보딩을 지원합니다. 장치가 온보딩되면 관리 플랫폼에서 연결할 수 있으며 패치, 업데이트 및 롤백을 적용할 수 있습니다.
FDO를 사용하면 다음과 같은 이점을 누릴 수 있습니다.
- FDO는 장치를 관리 플랫폼에 등록하는 안전하고 간단한 방법입니다. Kickstart 구성을 이미지에 포함하는 대신 FDO는 장치를 먼저 ISO 이미지로 직접 부팅하는 동안 장치 자격 증명을 적용합니다.
- FDO는 지연 바인딩을 장치에 전달하여 중요한 데이터를 보안 FDO 채널을 통해 공유할 수 있도록 합니다.
- FDO는 구성 및 기타 시크릿을 시스템에 등록하고 전달하기 전에 시스템 ID와 소유권을 식별합니다. 이를 통해 비기술적 사용자가 시스템의 전원을 켜도록 할 수 있습니다.
Edge Simplified Installer 이미지용 RHEL을 빌드하고 자동으로 켜지려면 기존 OSTree 커밋을 제공합니다. 결과 간소화된 이미지에는 OSTree 커밋이 배포된 원시 이미지가 포함되어 있습니다. 간소화된 설치 프로그램 ISO 이미지를 부팅한 후 하드 디스크 또는 가상 머신의 부팅 이미지로 사용할 수 있는 RHEL for Edge 시스템을 프로비저닝합니다.
RHEL for Edge Simplified Installer 이미지는 장치에 대한 무인 설치에 최적화되어 네트워크 기반 배포 및 비 네트워크 기반 배포를 모두 지원합니다. 그러나 네트워크 기반 배포의 경우 UEFI HTTP 부팅만 지원합니다.
FDO 프로토콜은 다음 서버를 기반으로 합니다.
- 제조 서버
- 장치 자격 증명을 생성합니다.
- 나중에 프로세스의 소유권을 설정하는 데 사용되는 Ownership voucher를 만듭니다.
- 장치를 특정 관리 플랫폼에 바인딩합니다.
- 소유자 관리 시스템
- 제조 서버로부터 Ownership voucher를 수신하고 관련 장치의 소유자가 됩니다.
- 이 프로세스의 뒷부분에서 장치 인증 후 장치와 소유자 온보딩 서버 간에 보안 채널을 만듭니다.
- 보안 채널을 사용하여 온보딩 자동화에 필요한 파일 및 스크립트와 같은 필요한 정보를 장치로 보냅니다.
- service-info API 서버
- 클라이언트에서 사용 가능한 Service-info API 서버 구성 및 모듈을 기반으로 SSH 키 및 파일 복사, 명령 실행, 사용자 생성, 디스크 암호화 등과 같은 대상 클라이언트 장치에서 온보딩의 최종 단계를 수행합니다.
- rendezvous 서버
- 소유자 관리 시스템에서 Ownership voucher를 가져오고 장치 UUID를 소유자 서버 IP에 매핑합니다. 그런 다음 Rendezvous 서버는 대상 플랫폼과 장치 UUID와 일치하고 이 장치가 사용해야 하는 소유자 온보딩 서버 엔드포인트에 대해 장치에 알립니다.
- 첫 번째 부팅 과정에서 Rendezvous 서버는 장치의 연락처 지점이 되고 장치를 소유자로 지시하여 장치와 소유자가 보안 채널을 설정할 수 있도록 합니다.
- 장치 클라이언트
장치에 설치되어 있습니다. 장치 클라이언트는 다음 작업을 수행합니다.
- 온보딩 자동화가 실행될 여러 서버에 대한 쿼리를 시작합니다.
- TCP/IP 프로토콜을 사용하여 서버와 통신합니다.
다음 다이어그램은 FIDO 장치 온보딩 워크플로를 나타냅니다.
그림 11.1. 네트워크 이외의 환경에서 RHEL for Edge 배포
장치 초기화 에서 장치는 제조 서버에 연결하여 FDO 자격 증명, 일련의 인증서 및 키 집합을 Rendezvous 서버 엔드포인트(URL)를 사용하여 운영 체제에 설치합니다. 또한 소유자 할당을 변경해야 하는 경우 별도로 유지되는 Ownership Voucher를 가져옵니다.
- 장치가 제조 서버에 연결되어 있습니다.
- 제조 서버는 Ownership vucher 및 장치에 대한 장치 자격 증명을 생성합니다.
- Ownership polkitucher는 소유자 온보딩 서버로 전송됩니다.
온사이트 온보딩 에서 장치는 장치 자격 증명 및 연락처 서버 끝점에서 Rendezvous 서버 끝점(URL)을 가져와서 온보딩 프로세스를 시작하여 소유자 관리 시스템으로 리디렉션합니다. 이 엔드포인트는 소유자 온보딩 서버 및 서비스 정보 API 서버로 구성됩니다.
- 소유자 온보딩 서버는 소유자인 Shucher를 Rendezvous 서버로 전송하여 소유자에 대한 소유권을 매핑합니다.
- 장치 클라이언트는 장치 자격 증명을 읽습니다.
- 장치 클라이언트가 네트워크에 연결됩니다.
- 네트워크에 연결한 후 장치 클라이언트는 Rendezvous 서버에 연결합니다.
- Rendezvous 서버는 소유자 엔드포인트 URL을 장치 클라이언트에 전송하고 장치를 등록합니다.
- 장치 클라이언트는 Rendezvous 서버에서 공유하는 소유자 온보딩 서버에 연결합니다.
- 장치는 장치 키를 사용하여 문에 서명하여 올바른 장치임을 증명합니다.
- 소유자 온보딩 서버는 소유자인ucher의 마지막 키로 문에 서명하여 정확함을 증명합니다.
- 소유자 온보딩 서버는 장치의 정보를 서비스 정보 API 서버로 전송합니다.
- Service info API 서버는 장치에 대한 구성을 전송합니다.
- 장치가 온보딩되어 있습니다.
11.2. 에지 장치용 RHEL 자동 프로비저닝 및 온보딩
Edge Simplified Installer 이미지용 RHEL을 빌드하고 자동으로 켜지려면 기존 OSTree 커밋을 제공합니다. 결과 간소화된 이미지에는 OSTree 커밋이 배포된 원시 이미지가 포함되어 있습니다. 간소화된 설치 프로그램 ISO 이미지를 부팅한 후 하드 디스크 또는 가상 머신의 부팅 이미지로 사용할 수 있는 RHEL for Edge 시스템을 프로비저닝합니다.
RHEL for Edge Simplified Installer 이미지는 장치에 대한 무인 설치에 최적화되어 네트워크 기반 배포 및 비 네트워크 기반 배포를 모두 지원합니다. 그러나 네트워크 기반 배포의 경우 UEFI HTTP 부팅만 지원합니다.
에지 장치에 대한 RHEL의 자동 프로비저닝 및 온보딩에는 다음과 같은 고급 단계가 포함됩니다.
- RHEL 시스템 설치 및 등록
- RHEL 이미지 빌더 설치
RHEL 이미지 빌더를 사용하여
rhel-edge-container
이미지 유형에 대한 RHEL 사용자 지정으로 블루프린트를 생성합니다.name = "rhel-edge-container" description = "Minimal RHEL for Edge Container blueprint" version = "0.0.1"
- RHEL 이미지 빌더에서 RHEL for Edge 컨테이너 블루프린트 가져오기
- 에지 컨테이너 이미지용 RHEL 생성
- RHEL for Edge 컨테이너 이미지를 사용하여 나중에 RHEL for Edge Simplified Installer 이미지 유형을 빌드할 때 사용되는 OSTree 커밋 제공
스토리지 장치 경로 및 FDO 사용자 지정 사용자 지정으로 및
에지-simplified-installer
이미지 유형에 대한 블루프린트 생성name = "rhel-edge-simplified-installer-with-fdo" description = "Minimal RHEL for Edge Simplified Installer with FDO blueprint" version = "0.0.1" packages = [] modules = [] groups = [] distro = "" [customizations] installation_device = "/dev/vda" [customizations.fdo] manufacturing_server_url = "http://10.0.0.2:8080" diun_pub_key_insecure = "true"
- 에지 이미지용 간소화된 설치 프로그램 RHEL 빌드
- Edge용 RHEL 단순화 설치 프로그램 이미지 다운로드
-
이때 FDO 서버 인프라가 가동 및 실행되어야 하며 소유자 인프라의 일부인
service-info API
서버에서 처리하는 특정 온보딩 세부 정보가 구성되어 있어야 합니다. - 장치에 단순화된 설치 프로그램 ISO 이미지를 설치합니다. FDO 클라이언트는 Simplified Installer ISO에서 실행되며 UEFI 디렉터리 구조는 이미지를 부팅 가능하게 합니다.
- 네트워크 구성을 사용하면 장치는 제조 서버에 연결하여 초기 장치 자격 증명 교환을 수행할 수 있습니다.
- 시스템이 끝점에 도달하면 장치에 대한 장치 자격 증명이 생성됩니다.
- 장치는 장치 자격 증명을 사용하여 Rendezvous 서버에 도달합니다. 여기에서 Rendezvous 서버에 따라 암호화 자격 증명을 확인한 다음, Rendezvous 서버가 장치를 Owner 서버로 리디렉션합니다.
- 장치가 소유자 서버에 연결합니다. 이는 Service-info API 서버의 구성에 따라 상호 신뢰와 온보딩의 최종 단계를 설정합니다. 예를 들어 장치에 SSH 키를 설치하고, 파일을 전송하고, 사용자를 생성하고, 명령을 실행하고, 파일 시스템을 암호화하는 등의 작업을 수행합니다.
추가 리소스
11.3. 키 및 인증서 생성
FIDO Device Onboarding (FDO) 인프라를 실행하려면 키와 인증서를 생성해야 합니다. FDO는 이러한 키와 인증서를 생성하여 제조 서버를 구성합니다. FDO는 서비스를 설치할 때 인증서 및 .yaml
구성 파일을 자동으로 생성하고 다시 생성하는 것은 선택 사항입니다. 서비스를 설치하고 시작한 후에는 기본 설정으로 실행됩니다.
Red Hat은 fdo-admin-tool
툴을 기술 프리뷰 기능으로 제공하며 보안 네트워크에서 실행해야 합니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다. 기술 프리뷰 기능의 지원 범위에 대한 정보는 Red Hat Customer Portal의 기술 프리뷰 기능 지원 범위를 참조하십시오.
사전 요구 사항
-
fdo-admin-cli
RPM 패키지를 설치하셨습니다.
절차
/etc/fdo
디렉터리에 키와 인증서를 생성합니다.$ for i in "diun" "manufacturer" "device-ca" "owner"; do fdo-admin-tool generate-key-and-cert $i; done $ ls keys device_ca_cert.pem device_ca_key.der diun_cert.pem diun_key.der manufacturer_cert.pem manufacturer_key.der owner_cert.pem owner_key.der
/etc/fdo/keys
디렉터리에 생성된 키와 인증서를 확인합니다.$ tree keys
다음 출력을 볼 수 있습니다.
– device_ca_cert.pem – device_ca_key.der – diun_cert.pem – diun_key.dre – manufacturer_cert.pem – manufacturer_key.der – owner_cert.pem – owner_key.pem
추가 리소스
-
fdo-admin-tool generate-key-and-cert --help
매뉴얼 페이지를 참조하십시오.
11.4. 제조 서버 설치 및 실행
fdo-manufacturing-server
RPM 패키지를 사용하면 FDO 프로토콜의 Manufacturing Server 구성 요소를 실행할 수 있습니다. 또한 소유자 바우처, 제조 업체 키 및 제조 세션에 대한 정보와 같은 다른 구성 요소를 저장합니다. 장치 설치 중에 제조 서버는 GUID, ndezvous 정보 및 기타 메타데이터를 포함하여 특정 장치에 대한 장치 자격 증명을 생성합니다. 나중에 프로세스에서 장치는 이 잘못된 정보를 사용하여 Rendezvous 서버에 연결합니다.
Red Hat은 fdo-manufacturing-server
도구를 기술 프리뷰 기능으로 제공하며 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완료되지 않을 수 있으므로 보안 네트워크에서 실행해야 합니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다. 기술 프리뷰 기능의 지원 범위에 대한 정보는 Red Hat Customer Portal의 기술 프리뷰 기능 지원 범위를 참조하십시오.
manufacturing server
RPM 패키지를 설치하려면 다음 단계를 완료합니다.
절차
fdo-admin-cli
패키지를 설치합니다.# dnf install -y fdo-admin-cli
fdo-manufacturing-server
RPM 패키지가 설치되어 있는지 확인합니다.$ rpm -qa | grep fdo-manufacturing-server --refresh
파일이 올바르게 설치되었는지 확인합니다.
$ ls /usr/share/doc/fdo
다음 출력을 볼 수 있습니다.
Output: manufacturing-server.yml owner-onboarding-server.yml rendezvous-info.yml rendezvous-server.yml serviceinfo-api-server.yml
선택 사항: 각 파일의 내용을 확인합니다. 예를 들면 다음과 같습니다.
$ cat /usr/share/doc/fdo/manufacturing-server.yml
제조 서버를 구성합니다. 다음 정보를 제공해야 합니다.
- 제조 서버 URL
- Rendezvous 서버의 IP 주소 또는 DNS 이름
생성된 키와 인증서의 경로입니다. 키 및 인증서 생성을 참조하십시오.
제조 서버 구성 파일의 예는
/usr/share/doc/fdo/manufacturing-server.yml
디렉토리에서 찾을 수 있습니다. 다음은/etc/fdo
디렉터리에 생성되어 저장된제조 server.yml
예제입니다. 여기에는 디렉터리, 인증서, 생성한 키, Rendezvous 서버 IP 주소와 기본 포트에 대한 경로가 포함되어 있습니다.session_store_driver: Directory: path: /etc/fdo/stores/manufacturing_sessions/ ownership_voucher_store_driver: Directory: path: /etc/fdo/stores/owner_vouchers public_key_store_driver: Directory: path: /etc/fdo/stores/manufacturer_keys bind: "0.0.0.0:8080" protocols: plain_di: false diun: mfg_string_type: SerialNumber key_type: SECP384R1 allowed_key_storage_types: - Tpm - FileSystem key_path: /etc/fdo/keys/diun_key.der cert_path: /etc/fdo/keys/diun_cert.pem rendezvous_info: - deviceport: 8082 ip_address: 192.168.122.99 ownerport: 8082 protocol: http manufacturing: manufacturer_cert_path: /etc/fdo/keys/manufacturer_cert.pem device_cert_ca_private_key: /etc/fdo/keys/device_ca_key.der device_cert_ca_chain: /etc/fdo/keys/device_ca_cert.pem owner_cert_path: /etc/fdo/keys/owner_cert.pem manufacturer_private_key: /etc/fdo/keys/manufacturer_key.der
제조 서버를 시작합니다.
systemd 장치 파일이 서버에 있는지 확인합니다.
# systemctl list-unit-files | grep fdo | grep manufacturing fdo-manufacturing-server.service disabled disabled
제조 서버를 활성화하고 시작합니다.
# systemctl enable --now fdo-manufacturing-server.service
방화벽에서 기본 포트를 엽니다.
# firewall-cmd --add-port=8080/tcp --permanent # systemctl restart firewalld
서비스가 포트 8080에서 수신 대기 중인지 확인합니다.
# ss -ltn
- 간소화된 설치 프로그램을 사용하여 시스템에 에지용 RHEL을 설치합니다. 엣지 이미지에 대한 RHEL을 프로비저닝하기 위해 간소화된 설치 프로그램 이미지 빌드를 참조하십시오.
11.5. Rendezvous 서버 설치, 구성 및 실행
fdo-rendezvous-server
RPM 패키지를 설치하여 시스템이 첫 번째 장치 부팅 중에 제조 서버에서 생성한 바우처를 수신할 수 있도록 합니다. 그러면 Rendezvous 서버가 대상 플랫폼 또는 클라우드와 장치 UUID와 일치하고 장치가 사용해야 하는 소유자 서버 엔드포인트에 대해 장치에 알립니다.
사전 요구 사항
-
manufacturer_cert.pem
인증서를 생성하셨습니다. 키 및 인증서 생성을 참조하십시오. -
manufacturer_cert.pem
인증서를 Rendezvous 서버의/etc/fdo/keys
디렉터리에 복사했습니다.
절차
fdo-rendezvous-server
RPM 패키지를 설치합니다.# dnf install -y fdo-rendezvous-server
제조업체 인증서 경로를 포함하여
rendezvous-server.yml
구성 파일을 생성합니다./usr/share/doc/fdo/rendezvous-server.yml
에서 예를 찾을 수 있습니다. 다음 예제에서는/etc/fdo/rendezvous-server.yml
에 저장된 구성 파일을 보여줍니다.storage_driver: Directory: path: /etc/fdo/stores/rendezvous_registered session_store_driver: Directory: path: /etc/fdo/stores/rendezvous_sessions trusted_manufacturer_keys_path: /etc/fdo/keys/manufacturer_cert.pem max_wait_seconds: ~ bind: "0.0.0.0:8082"
Rendezvous 서버 서비스 상태를 확인합니다.
# systemctl list-unit-files | grep fdo | grep rende fdo-rendezvous-server.service disabled disabled
서비스가 중지 및 비활성화된 경우 활성화 및 시작합니다.
# systemctl enable --now fdo-rendezvous-server.service
서버가 기본 구성된 포트 8082에서 수신 대기 중인지 확인합니다.
# ss -ltn
이 서버에 방화벽을 구성한 경우 포트를 엽니다.
# firewall-cmd --add-port=8082/tcp --permanent # systemctl restart firewalld
11.6. 소유자 서버 설치, 구성 및 실행
fdo-owner-cli
및 fdo-owner-onboarding-server
RPM 패키지를 설치하여 시스템이 첫 번째 장치 부팅 중에 제조 서버에서 생성한 바우처를 수신할 수 있도록 합니다. 그러면 Rendezvous 서버가 대상 플랫폼 또는 클라우드와 장치 UUID와 일치하고 장치가 사용해야 하는 소유자 서버 엔드포인트에 대해 장치에 알립니다.
사전 요구 사항
- 서버가 배포되는 장치에는 디스크를 암호화할 신뢰할 수 있는 플랫폼 모듈(TPM) 장치가 있습니다. 그렇지 않은 경우 RHEL for Edge 장치를 부팅할 때 오류가 발생합니다.
-
키와 인증서가 있는
device_ca_cert.pem
,owner_key.der
,owner_cert.pem
을 생성한 후 해당 키를/etc/fdo/keys
디렉터리에 복사합니다.
절차
이 서버에 필요한 RPM을 설치합니다.
# dnf install -y fdo-owner-cli fdo-owner-onboarding-server
owner-onboarding-server.yml
구성 파일을 준비하여/etc/fdo/
디렉터리에 저장합니다. 이미 복사한 인증서의 경로와 이 파일에 Owner 서버 서비스를 게시할 위치에 대한 정보를 포함합니다.다음은
/usr/share/doc/fdo/owner-onboarding-server.yml
에서 사용할 수 있는 예입니다. URL 또는 인증 토큰과 같은 Service Info API에 대한 참조를 찾을 수 있습니다.--- ownership_voucher_store_driver: Directory: path: /etc/fdo/stores/owner_vouchers session_store_driver: Directory: path: /etc/fdo/stores/owner_onboarding_sessions trusted_device_keys_path: /etc/fdo/keys/device_ca_cert.pem owner_private_key_path: /etc/fdo/keys/owner_key.der owner_public_key_path: /etc/fdo/keys/owner_cert.pem bind: "0.0.0.0:8081" service_info_api_url: "http://localhost:8083/device_info" service_info_api_authentication: BearerToken: token: Kpt5P/5flBkaiNSvDYS3cEdBQXJn2Zv9n1D50431/lo= owner_addresses: - transport: http addresses: - ip_address: 192.168.122.149
Service Info API를 생성하고 구성합니다.
사용자 생성, 복사 또는 생성, 실행할 명령, 암호화할 디스크 등 온보딩을 위한 자동화된 정보를 추가합니다.
/usr/share/doc/fdo/serviceinfo-api-server.yml
의 Service Info API 구성 파일 예제를 템플릿으로 사용하여/etc/fdo/
에 구성 파일을 생성합니다.--- service_info: initial_user: username: admin sshkeys: - "ssh-rsa AAAA...." files: - path: /root/resolv.conf source_path: /etc/resolv.conf commands: - command: touch args: - /root/test return_stdout: true return_stderr: true diskencryption_clevis: - disk_label: /dev/vda4 binding: pin: tpm2 config: "{}" reencrypt: true additional_serviceinfo: ~ bind: "0.0.0.0:8083" device_specific_store_driver: Directory: path: /etc/fdo/stores/serviceinfo_api_devices service_info_auth_token: Kpt5P/5flBkaiNSvDYS3cEdBQXJn2Zv9n1D50431/lo= admin_auth_token: zJNoErq7aa0RusJ1w0tkTjdITdMCWYkndzVv7F0V42Q=
systemd 장치의 상태를 확인합니다.
# systemctl list-unit-files | grep fdo fdo-owner-onboarding-server.service disabled disabled fdo-serviceinfo-api-server.service disabled disabled
서비스가 중지 및 비활성화된 경우 활성화 및 시작합니다.
# systemctl enable --now fdo-owner-onboarding-server.service # systemctl enable --now fdo-serviceinfo-api-server.service
참고구성 파일을 변경할 때마다
systemd
서비스를 다시 시작해야 합니다.
서버가 기본 구성된 포트 8083에서 수신 대기 중인지 확인합니다.
# ss -ltn
이 서버에 방화벽을 구성한 경우 포트를 엽니다.
# firewall-cmd --add-port=8081/tcp --permanent # firewall-cmd --add-port=8083/tcp --permanent # systemctl restart firewalld
11.7. FDO 인증을 사용하여 에지 장치용 RHEL 자동 온보딩
RHEL for Edge 장치를 자동으로 온보드하고 설치 프로세스의 일부로 프로비저닝할 장치를 준비하려면 다음 단계를 완료합니다.
사전 요구 사항
-
Edge용으로 RHEL에 대한 OSTree 커밋을 빌드하고 이를 사용하여
edge-simplified-installer
아티팩트를 생성합니다. - 귀하의 장치가 조립됩니다.
-
fdo-manufacturing-server
RPM 패키지를 설치하셨습니다. manufacturing server 패키지 설치를 참조하십시오.
절차
- 장치에서 RHEL을 부팅한 에지 설치 프로그램 이미지를 부팅하여 설치 프로세스를 시작합니다. 예를 들어 CD-ROM 또는 USB 플래시 드라이브에서 설치할 수 있습니다.
터미널을 통해 장치가 초기 장치 자격 증명 교환을 수행하고 소유권 바우처를 생성하기 위해 제조 서비스에 도달했는지 확인합니다.
manufacturing-sever.yml
파일에서ownership_voucher_store_driver:
매개변수로 구성된 스토리지 위치에서 Owner voucher를 찾을 수 있습니다.디렉터리에는 올바른 장치 자격 증명이 장치에 추가되었음을 나타내는 GUID 형식의 이름이 있는
ownership_voucher
파일이 있어야 합니다.온보딩 서버는 장치 자격 증명을 사용하여 온보딩 서버에 대해 인증합니다. 그런 다음 구성을 장치에 전달합니다. 장치가 온보드 서버에서 구성을 수신한 후 SSH 키를 수신하고 장치에 운영 체제를 설치합니다. 마지막으로 시스템은 자동으로 재부팅되며 TPM에 저장된 강력한 키를 사용하여 암호화합니다.
검증
장치가 자동으로 재부팅되면 FDO 프로세스의 일부로 생성한 인증 정보를 사용하여 장치에 로그인할 수 있습니다.
- Service Info API에서 생성한 사용자 이름과 암호를 제공하여 장치에 로그인합니다.
12장. FDO를 사용하여 데이터베이스 백엔드와 함께 RHEL for Edge 장치 온보드
FDO 서버 - manufacturer-server
,onboarding-server
및 rendezvous
를 사용하여 파일 대신 SQLite 또는 PostgreSQL 데이터베이스와 같은 SQL 백엔드에서 소유자 vuchers 저장 및 쿼리를 지원할 수 있습니다. 이렇게 하면 자격 증명 및 기타 매개변수와 함께 FDO 서버 옵션에서 SQL 데이터 저장소를 선택하여 Owner Cryostatuchers를 SQL 데이터베이스에 저장하고 따라서 RHEL for Edge 장치를 온보딩할 수 있습니다. SQL 파일은 RPM에 패키지됩니다.
SQL 백엔드는 현재 모든 FDO 기능을 지원하지 않습니다.
12.1. FDO 데이터베이스를 사용하여 장치 온보딩
SQL 데이터베이스를 사용하여 에지 장치를 온보드합니다. 다음 예제에서는 디젤
도구를 사용하지만 SQLite 또는 PostgreSQL 데이터베이스를 사용할 수도 있습니다.
다른 서버에서 파일 시스템 스토리지가 있는 일부 서버에서 서로 다른 데이터베이스 스토리지를 사용할 수 있습니다(예: Manufacturing 서버용 파일 시스템 스토리지 온보딩 및 Rendezvous 및 Owner 서버에 Postgres).
사전 요구 사항
- FDO를 사용하여 제조 서버를 구성할 키와 인증서를 생성했습니다. [키 및 인증서 생성]에 대한 링크를 참조하십시오.
- 제조 서버를 설치하고 구성했습니다. 제조 서버 설치 및 실행을참조하십시오.
- rendezvous 서버를 설치하고 구성했습니다. Rendezvous 서버 설치, 구성 및 실행을참조하십시오.
- 소유자 서버를 설치 및 구성했습니다. 소유자 서버 설치, 구성 및 실행을참조하십시오.
-
/etc/fdo
에 서버 구성 파일이 있습니다. -
RHEL for Edge에 대한 OSTree 커밋을 빌드하고 Edge
-simplified-installer 아티팩트
를 생성하는 데 사용되었습니다. - 장치가 조립됩니다.
-
호스트에
디젤
도구 또는 SQL 데이터베이스를 설치했습니다. - 데이터베이스 시스템을 구성하고 테이블을 만들 수 있는 권한이 있습니다.
절차
다음 패키지를 설치합니다.
$ dnf install -y sqlite sqlite-devel libpq libpq-devel
-
/usr/share/doc/fdo/migrations/*
디렉터리에 액세스합니다. 이 파일에는 manufacturing, rendezvous 및 owner 서버의 RPM을 설치한 후 각 서버 및 유형 조합에 대한 데이터베이스를 생성해야 하는.sql
파일이 포함되어 있습니다. 데이터베이스 콘텐츠를 초기화합니다. SQLite 또는 PostgreSQL과 같은 SQL 데이터베이스 또는
디젤
툴을 사용하여 SQL을 실행할 수 있습니다.- SQL 데이터베이스를 사용하는 경우 사용자 생성, 액세스 관리 등 을 사용하여 데이터베이스 서버를 구성합니다. 예를 들면 다음과 같습니다. 데이터베이스 서버를 구성한 후 데이터베이스를 실행할 수 있습니다.
-
데이터베이스 시스템에서
.sql
파일을 실행하지 않으려면디젤
도구를 사용하여 sql을 실행할 수 있습니다.디젤
툴을 사용하는 경우 데이터베이스를 구성한 후디젤 마이그레이션 실행
명령을 사용하여 데이터베이스를 생성합니다.
DB 시스템을 구성한 후
/usr/share/doc/fdo/migrations/*
에 설치된 .sql 파일을 사용하여 각 서버 유형에 대한 데이터베이스를 생성할 수 있습니다.초기화 중인 서버 유형 및 데이터베이스 유형과 일치하는
.sql
파일을 사용해야 합니다. 예를 들어 PostgreSQL 데이터베이스에서 Owner Onboarding Server를 초기화할 때/usr/share/doc/fdo/migrations/migrations_owner_onboarding_server_postgres/up.sql
폴더를 사용해야 합니다. 마이그레이션 폴더의up.sql
파일은 데이터베이스를 생성하고down.sql
파일은 해당 데이터베이스를 삭제합니다.데이터베이스를 만든 후 특정 서버의 구성 파일을 변경하여 데이터베이스를 사용하도록 합니다.
각 서버에는 스토리지 구성 섹션이 있습니다.
-
제조업체 서버:
ownership_voucher_store_driver
-
소유자 서버:
ownership_voucher_store_driver
ndezvous 서버:
storage_driver
manufacturing-server.yml
파일의 경우 편집기에서 열고 store 데이터베이스를 변경합니다.$ sudo editor manufacturing-server.yml
Directory 섹션에서
ownership_voucher_store_driver
구성을 변경합니다.$ /home/rhel/fido-device-onboard-rs/aio-dir/stores/owner_vouchers
- 다음 세부 정보를 지정합니다.
- 사용 중인 데이터베이스 유형입니다. SQLite 또는 PostgreSQL
서버 유형: 예를 들어 PostgreSQL을 사용하는 경우 다음 구성을 설정합니다.
ownership_voucher_store_driver: Postgres: Manufacturer
- 단계를 반복하여 소유자 서버 및 Rendezvous 서버를 구성합니다.
-
제조업체 서버:
FDO 온보딩 서비스를 실행합니다. 자세한 내용은 FDO를 사용하여 RHEL for Edge 장치 자동 프로비저닝 및 온보딩을 참조하십시오. 제조 서버를 실행하여 FDO 온보딩 프로세스 장치 초기화를 시작합니다.
$ sudo LOG-LEVEL=debug SQLITE_MANUFACTURER-DATABASE_URL=./manufacturer-db.sqlite ./usr/libexec/fdo/fdo-manufacturing-server
온보딩 프로세스는 다음 두 단계로 수행됩니다.
- 제조 사이트에서 일반적으로 발생하는 장치 초기화 단계입니다.
장치의 최종 대상에서 발생하는 장치 온보딩 프로세스입니다.
결과적으로 Manufacturing Server의 데이터베이스에 저장된 Ownership Cryostat를 내보내 최종 소유자 데이터베이스로 전송해야 합니다.
Ownership voteuchers를 내보내려면 manufacturing-vouchers 데이터베이스 파일에서 Owner voteucher를 소유자에 복사하여 FDO 온보딩 프로토콜을 계속합니다.
폴더
내보내기
생성:$ mkdir export
명령에 필요한 모든 변수를 제공하여 제조 데이터베이스에 있는 Ownerucher를 내보냅니다.
$ fdo-owner-tool export-manufacturer-vouchers DB_TYPE DB_URL PATH [GUID]
- DB_TYPE
- Owner hearuchers를 보유하고 있는 제조 DB의 유형: sqlite, postgres
- DB_URL
- 데이터베이스 연결 URL 또는 데이터베이스 파일의 경로입니다.
- PATH
- Owner hearuchers를 내보낼 디렉터리의 경로입니다.
- GUID
- 소유자의 GUID는 내보낼 수 있습니다. GUID를 제공하지 않으면 모든 소유자가 내보내집니다.
OV는 최종 소유자의 데이터베이스로 전달되어야 합니다. 이를 위해
fdo-owner-tool
을 사용하여 소유자 바우처를 가져옵니다. owner 데이터베이스를 변경합니다. 다음 명령을 실행하여 Ownership polkituchers를 가져옵니다.$ fdo-owner-tool import-ownership-vouchers DB_TYPE DB_URL SOURCE_PATH
- DB_TYPE
- OV를 가져올 Owner DB 유형입니다. 가능한 값: sqlite, postgres
- DB_URL
- DB 연결 URL 또는 DB 파일의 경로
- SOURCE_PATH
- 가져올 OV의 경로 또는 가져올 모든 OV가 있는 디렉터리의 경로입니다.
명령은 <SOURCE_PATH>에 지정된 각 OV를 하나씩 한 번 읽고 해당 OV를 데이터베이스로 가져오려고 합니다. 명령에서 오류를 발견하면 결함이 있고 오류가 발생한 이유에 대한 정보로 지정된 OV의 GUID가 포함된 출력을 반환합니다. 치명적이 아닌 OV는 데이터베이스로 가져옵니다. 장치는 온보딩 서버에서 구성을 수신합니다. 그런 다음 장치는 SSH 키를 수신하고 장치에 운영 체제를 설치하기 시작합니다. 마지막으로 운영 체제는 장치에서 자동으로 재부팅되고 TPM에 저장된 강력한 키로 장치를 암호화합니다.
13장. 네트워크 기반 환경에서 RHEL for Edge 이미지 배포
RHEL 설치 프로그램 그래픽 사용자 인터페이스 또는 Kickstart 파일을 사용하여 에지용 RHEL을 배포할 수 있습니다. Edge 이미지에 RHEL을 배포하는 전체 프로세스는 배포 환경이 네트워크 기반인지 또는 비 네트워크 기반인지에 따라 다릅니다.
베어 메탈에 이미지를 배포하려면 Kickstart 파일을 사용합니다.
네트워크 기반 배포
네트워크 기반 환경에서 에지 이미지에 RHEL을 배포하려면 다음과 같은 상위 수준 단계를 수행해야 합니다.
- 이미지 파일 콘텐츠를 추출합니다.
- 웹 서버 설정
- 이미지 설치
13.1. RHEL for Edge 이미지 커밋 추출
커밋을 다운로드한 후 .tar
파일을 추출하고 ref 이름과 커밋 ID를 기록해 둡니다.
다운로드한 커밋 파일은 OSTree
리포지토리가 있는 .tar
파일로 구성됩니다. OSTree
리포지토리에 커밋과 compose.json
파일이 있습니다.
compose.json
파일에는 "Ref", 참조 ID 및 커밋 ID와 같은 정보가 포함된 커밋에 대한 정보 메타데이터가 있습니다. 커밋 ID에는 RPM 패키지가 있습니다.
패키지 콘텐츠를 추출하려면 다음 단계를 수행합니다.
사전 요구 사항
- Kickstart 파일을 만들거나 기존 파일을 사용합니다.
절차
다운로드한 이미지
.tar
파일을 추출합니다.# tar xvf <UUID>-commit.tar
.tar
파일을 추출한 디렉터리로 이동합니다.compose.json
파일과 OSTree 디렉터리가 있습니다.compose.json
파일에는 커밋 번호가 있으며OSTree
디렉터리에는 RPM 패키지가 있습니다.compose.json
파일을 열고 커밋 ID 번호를 기록해 둡니다. 웹 서버를 설정하려면 이 숫자가 필요합니다.jq
JSON 프로세서가 설치된 경우jq
툴을 사용하여 커밋 ID를 검색할 수도 있습니다.# jq '.["ostree-commit"]' < compose.json
커밋에 RPM 패키지를 나열합니다.
# rpm-ostree db list rhel/9/x86_64/edge --repo=repo
Kickstart 파일을 사용하여 RHEL 설치 프로그램을 실행합니다. 필요한 경우 기존 파일을 사용하거나 Kickstart 생성기 도구를 사용하여 하나를 만들 수 있습니다.
Kickstart 파일에서 파일 시스템을 프로비저닝하는 방법, 사용자 생성 및 에지용 RHEL을 가져오고 배포하는 방법에 대한 세부 정보가 포함되어 있는지 확인합니다. RHEL 설치 프로그램은 설치 프로세스 중에 이 정보를 사용합니다.
다음은 Kickstart 파일 예제입니다.
lang en_US.UTF-8 keyboard us timezone Etc/UTC --isUtc text zerombr clearpart --all --initlabel autopart reboot user --name=core --group=wheel sshkey --username=core "ssh-rsa AAAA3Nza…." rootpw --lock network --bootproto=dhcp ostreesetup --nogpg --osname=rhel --remote=edge --url=https://mirror.example.com/repo/ --ref=rhel/9/x86_64/edge
OStree 기반 설치에서는
ostreesetup
명령을 사용하여 구성을 설정합니다. 다음 플래그를 사용하여 OSTree 커밋을 가져옵니다.-
--nogpg
- GPG(GNU Privacy Guard) 키 확인을 비활성화합니다. -
--osname
- 운영 체제 설치를 위한 관리 루트입니다. -
--remote
- 운영 체제 설치를 위한 관리 루트 -
--URL
- 설치할 리포지토리의 URL입니다. -
--ref
- 설치에서 사용하는 저장소의 분기 이름입니다. --URL=http://mirror.example.com/repo/
- 에지 커밋을 추출하여nginx
를 통해 제공하는 호스트 시스템의 주소입니다. 주소를 사용하여 게스트 컴퓨터에서 호스트 시스템에 연결할 수 있습니다.예를 들어
/var/www/html
디렉터리에서 커밋 이미지를 추출하고 호스트 이름이www.example.com
인 컴퓨터에서nginx
를 통해 커밋을 제공하는 경우--url
매개변수의 값은http://www.example.com/repo
입니다.참고HTTP 프로토콜을 사용하여 Apache HTTP 서버에서 https가 활성화되어 있지 않기 때문에 커밋을 제공할 서비스를 시작합니다.
-
추가 리소스
13.2. 에지 이미지용 RHEL을 설치하기 위해 웹 서버 설정
RHEL for Edge 이미지 콘텐츠를 추출한 후 HTTP를 사용하여 RHEL 설치 프로그램에 이미지 커밋 세부 정보를 제공하도록 웹 서버를 설정합니다.
다음 예제에서는 컨테이너를 사용하여 웹 서버를 설정하는 단계를 제공합니다.
사전 요구 사항
- 시스템에 Podman이 설치되어 있어야 합니다. RHEL에 Podman을 설치하는 방법보기
절차
다음 지침을 사용하여
nginx
구성 파일을 생성합니다.events { } http { server{ listen 8080; root /usr/share/nginx/html; } } pid /run/nginx.pid; daemon off;
다음 명령을 사용하여 Dockerfile을 생성합니다.
FROM registry.access.redhat.com/ubi8/ubi RUN dnf -y install nginx && dnf clean all COPY kickstart.ks /usr/share/nginx/html/ COPY repo /usr/share/nginx/html/ COPY nginx /etc/nginx.conf EXPOSE 8080 CMD ["/usr/sbin/nginx", "-c", "/etc/nginx.conf"] ARG commit ADD ${commit} /usr/share/nginx/html/
여기서,
Kickstart.ks
는 RHEL for Edge 이미지의 Kickstart 파일의 이름입니다. Kickstart 파일에는 지시문 정보가 포함되어 있습니다. 나중에 이미지를 관리할 수 있도록 greenboot 검사에 대한 검사 및 설정을 포함하는 것이 좋습니다. 이를 위해 다음 설정을 포함하도록 Kickstart 파일을 업데이트할 수 있습니다.lang en_US.UTF-8 keyboard us timezone Etc/UTC --isUtc text zerombr clearpart --all --initlabel autopart reboot user --name=core --group=wheel sshkey --username=core "ssh-rsa AAAA3Nza…." ostreesetup --nogpg --osname=rhel --remote=edge --url=https://mirror.example.com/repo/ --ref=rhel/9/x86_64/edge %post cat << EOF > /etc/greenboot/check/required.d/check-dns.sh #!/bin/bash DNS_SERVER=$(grep nameserver /etc/resolv.conf | cut -f2 -d" ") COUNT=0 # check DNS server is available ping -c1 $DNS_SERVER while [ $? != '0' ] && [ $COUNT -lt 10 ]; do COUNT++ echo "Checking for DNS: Attempt $COUNT ." sleep 10 ping -c 1 $DNS_SERVER done EOF %end
모든 HTTP 서비스는 OSTree 리포지토리를 호스팅할 수 있으며 컨테이너를 사용하는 예제는 이 작업을 수행하는 방법에 대한 옵션일 뿐입니다. Dockerfile은 다음 작업을 수행합니다.
- 최신 UBI(Universal Base Image) 사용
- 웹 서버 설치(nginx)
- 서버에 Kickstart 파일 추가
- 서버에 에지 이미지 커밋을 위한 RHEL 추가
Docker 컨테이너 빌드
# podman build -t name-of-container-image --build-arg commit=uuid-commit.tar .
컨테이너 실행
# podman run --rm -d -p port:8080 localhost/name-of-container-image
결과적으로 서버는
commit.tar
리포지토리와 Kickstart 파일을 사용하여 RHEL Installer를 시작할 준비가 되었습니다.
13.3. Kickstart를 사용하여 에지 장치에 배치된 설치 수행
네트워크 기반 환경에서 설치하는 경우 RHEL 설치 관리자 ISO, Kickstart 파일 및 웹 서버를 사용하여 RHEL for Edge 이미지를 장치에 설치할 수 있습니다. 웹 서버는 RHEL for Edge 커밋과 Kickstart 파일을 제공하여 RHEL 설치 프로그램 ISO 이미지를 부팅합니다.
사전 요구 사항
- 웹 서버를 실행하여 RHEL for Edge 커밋을 사용할 수 있게 되었습니다. RHEL for Edge 이미지를 설치할 웹 서버 설정을 참조하십시오.
-
참여 중인 설치의 대상으로 사용할
.qcow2
디스크 이미지를 생성했습니다. qemu-img 를 사용하여 가상 디스크 이미지 생성 을 참조하십시오.
절차
Kickstart 파일을 만듭니다. 다음은
ostreesetup
지시문이 Anaconda 설치 프로그램에 커밋을 가져오고 배포하도록 지시하는 예입니다. 또한 사용자와 암호를 생성합니다.lang en_US.UTF-8 keyboard us timezone UTC zerombr clearpart --all --initlabel autopart --type=plain --fstype=xfs --nohome reboot text network --bootproto=dhcp user --name=core --groups=wheel --password=edge services --enabled=ostree-remount ostreesetup --nogpg --url=http://edge_device_ip:port/repo/ --osname=rhel --remote=edge --ref=rhel/9/x86_64/edge
libvirt virt-install
유틸리티를 사용하여 RHEL 운영 체제가 있는 VM(가상 머신)을 생성하여 RHEL Anaconda 설치 프로그램을 실행합니다. 참여 중인 설치의 대상 디스크로.qcow2
디스크 이미지를 사용합니다.virt-install \ --name rhel-edge-test-1 \ --memory 2048 \ --vcpus 2 \ --disk path=prepared_disk_image.qcow2,format=qcow2,size=8 \ --os-variant rhel9 \ --cdrom /home/username/Downloads/rhel-9-x86_64-boot.iso
설치 화면에서 다음을 수행합니다.
그림 13.1. Red Hat Enterprise Linux 부팅 메뉴
inst.ks=http://web-server_device_ip:port/kickstart.ks
kernel 매개변수는 RHEL 설치 프로그램에 포함된 RHEL 이미지가 아닌 Kickstart 파일을 사용하여 RHEL을 설치하도록 지정합니다.
커널 매개 변수를 추가한 후 Ctrl+X 를 눌러 Kickstart 파일을 사용하여 RHEL 설치를 부팅합니다.
RHEL Installer가 시작되고 서버(HTTP) 끝점에서 Kickstart 파일을 가져오고 HTTP 끝점에서 에지 이미지 커밋용 RHEL을 설치하는 명령을 포함하여 명령을 실행합니다. 설치가 완료되면 RHEL 설치 관리자에 로그인 세부 정보가 표시됩니다.
검증
- 로그인 화면에서 사용자 계정 자격 증명을 입력하고 를 클릭합니다.
에지 이미지의 RHEL이 성공적으로 설치되었는지 확인합니다.
$ rpm-ostree status
명령 출력은 이미지 커밋 ID를 제공하며 설치에 성공했는지 표시됩니다.
다음은 샘플 출력입니다.
State: idle Deployments: * ostree://edge:rhel/9/x86_64/edge Timestamp: 2020-09-18T20:06:54Z Commit: 836e637095554e0b634a0a48ea05c75280519dd6576a392635e6fa7d4d5e96
13.4. Kickstart를 사용하여 에지 장치에 자동 설치 수행
네트워크 기반 환경에서 무인 설치를 위해 Kickstart 파일 및 웹 서버를 사용하여 RHEL for Edge 이미지를 에지 장치에 설치할 수 있습니다. 웹 서버는 RHEL for Edge 커밋 및 Kickstart 파일을 제공하며 두 아티팩트 모두 RHEL 설치 프로그램 ISO 이미지를 시작하는 데 사용됩니다.
사전 요구 사항
-
qemu-img
유틸리티가 호스트 시스템에 설치되어 있습니다. -
생성한 커밋을 설치할
.qcow2
디스크 이미지를 생성했습니다. CLI에서 RHEL 이미지 빌더를 사용하여 시스템 이미지 생성을 참조하십시오. - 실행 중인 웹 서버가 있어야 합니다. 네트워크 기반이 아닌 배포를 위한 RHEL for Edge 컨테이너 이미지 생성 을 참조하십시오.
절차
- RHEL for Edge 컨테이너 이미지를 실행하여 웹 서버를 시작합니다. 서버는 RHEL for Edge 컨테이너 이미지에서 커밋을 가져와서 사용 가능하고 실행 가능하게 됩니다.
libvirt virt-install
:을 사용하여 사용자 지정.qcow2
디스크 이미지를 전달하여 RHEL Anaconda 설치 관리자를 실행합니다.virt-install \ --name rhel-edge-test-1 \ --memory 2048 \ --vcpus 2 \ --disk path=prepared_disk_image.qcow2,format=qcow2,size=8 \ --os-variant rhel9 \ --cdrom /home/username/Downloads/rhel-9-x86_64-boot.iso
설치 화면에서 다음을 수행합니다.
그림 13.2. Red Hat Enterprise Linux 부팅 메뉴
inst.ks=http://web-server_device_ip:port/kickstart.ks
kernel 매개변수는 RHEL 설치 프로그램에 포함된 RHEL 이미지가 아닌 Kickstart 파일을 사용하여 RHEL을 설치하도록 지정합니다.
커널 매개 변수를 추가한 후 Ctrl+X 를 눌러 Kickstart 파일을 사용하여 RHEL 설치를 부팅합니다.
RHEL 설치 프로그램이 시작되고 서버(HTTP) 끝점에서 Kickstart 파일을 가져오고, HTTP 끝점에서 RHEL for Edge 이미지 커밋을 설치하는 명령을 포함하여 명령을 실행합니다. 설치가 완료되면 RHEL 설치 관리자에 로그인 세부 정보가 표시됩니다.
검증
- 로그인 화면에서 사용자 계정 자격 증명을 입력하고 를 클릭합니다.
에지 이미지의 RHEL이 성공적으로 설치되었는지 확인합니다.
$ rpm-ostree status
명령 출력은 이미지 커밋 ID를 제공하며 설치에 성공했는지 표시됩니다.
다음은 샘플 출력입니다.
State: idle Deployments: * ostree://edge:rhel/9/x86_64/edge Timestamp: 2020-09-18T20:06:54Z Commit: 836e637095554e0b634a0a48ea05c75280519dd6576a392635e6fa7d4d5e96
14장. 네트워크 기반이 아닌 환경에서 RHEL for Edge 이미지 배포
RHEL for Edge Container(.tar
)와 함께 RHEL for Edge Installer(.iso
) 이미지 유형으로 ISO 이미지가 생성됩니다. ISO 이미지는 이미지를 장치에 배포하는 동안 연결이 끊긴 환경에서 사용할 수 있습니다. 그러나 네트워크 액세스에는 다른 아티팩트를 빌드하기 위해 네트워크 액세스가 필요할 수 있습니다.
비 네트워크 기반 환경에 엣지 이미지용 RHEL을 배포하려면 다음과 같은 상위 수준 단계가 포함됩니다.
- Edge 컨테이너용 RHEL을 다운로드합니다. 엣지용 RHEL 이미지를 다운로드하는 방법에 대한 자세한 내용은 Edge 용 RHEL 이미지 다운로드를 참조하십시오.
- Edge 컨테이너 이미지의 RHEL을 Podman에 로드
- Podman에서 Edge Container 이미지에 대한 RHEL을 실행합니다.
- Edge Installer용 RHEL 로드
- Edge 설치 프로그램 이미지용 RHEL 빌드
-
.qcow2
디스크 준비 - VM(가상 머신) 부팅
- 이미지 설치
14.1. 네트워크 기반이 아닌 배포를 위한 Edge 컨테이너 이미지용 RHEL 생성
Edge 컨테이너 OSTree 커밋을 위해 다운로드한 RHEL을 Podman에 로드하여 실행 중인 컨테이너를 빌드할 수 있습니다. 이를 위해 다음 단계를 수행합니다.
사전 요구 사항
- Edge 컨테이너 OSTree 커밋을 위한 RHEL을 생성하고 다운로드했습니다.
-
시스템에
Podman
이 설치되어 있어야 합니다. RHEL에 Podman을 설치하는 방법을 참조하십시오.
절차
- 에지 컨테이너 OSTree 커밋을 위해 RHEL을 다운로드한 디렉터리로 이동합니다.
에지 컨테이너 OSTree 커밋을 위한 RHEL을
Podman
에 로드합니다.$ sudo podman load -i UUID-container.tar
명령 출력은 이미지 ID를 제공합니다(예:
@8e0d51f061ff1a51d157804362bc875b649b27f2ae1e66566a15e7e6530cec63
).이전 단계에서 생성한 이미지 ID를 사용하여 에지 컨테이너 이미지의 새 RHEL에 태그를 지정합니다.
$ sudo podman tag image-ID localhost/edge-container
podman tag
명령은 로컬 이미지에 추가 이름을 할당합니다.edge-container
라는 컨테이너를 실행합니다.$ sudo podman run -d --name=edge-container -p 8080:8080 localhost/edge-container
podman run -d --name=edge-container
명령은localhost/edge-container
이미지를 기반으로 하는 컨테이너에 이름을 할당합니다.컨테이너를 나열합니다.
$ sudo podman ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 2988198c4c4b …./localhost/edge-container /bin/bash 3 seconds ago Up 2 seconds ago edge-container
결과적으로 Podman
은 에지 컨테이너 커밋을 위해 RHEL을 사용하여 OSTree 리포지토리를 제공하는 컨테이너를 실행합니다.
14.2. 네트워크 기반이 아닌 배포에 대한 엣지 설치 프로그램 이미지용 RHEL 생성
RHEL for Edge
컨테이너 커밋과 함께 리포지토리를 제공하도록 실행 중인 컨테이너를 빌드한 후 RHEL for Edge Installer(.iso)
이미지를 생성합니다. RHEL for Edge Installer(.iso)
는 RHEL for Edge Container(.tar)
에서 제공하는 커밋을 가져옵니다. Podman에 RHEL for Edge Container
커밋이 로드된 후 URL 형식으로 OSTree
를 노출합니다.
CLI에서 엣지 설치 관리자 이미지용 RHEL을 생성하려면 단계를 따르십시오.
사전 요구 사항
- 에지 이미지용 RHEL에 대한 청사진을 생성했습니다.
- RHEL for Edge 컨테이너 이미지를 생성하고 웹 서버를 사용하여 배포했습니다.
절차
에지 설치 프로그램 이미지용 RHEL 생성을 시작합니다.
# composer-cli compose start-ostree --ref rhel/9/x86_64/edge --url URL-OSTree-repository blueprint-name image-type
여기서,
- ref 는 고객이 OSTree 리포지토리를 빌드하는 데 사용한 값과 같습니다.
- URL-OSTree-repository 는 이미지에 포함할 커밋의 OSTree 리포지토리에 대한 URL입니다. 예: http://10.0.2.2:8080/repo/. 네트워크 기반이 아닌 배포를 위한 RHEL for Edge 컨테이너 이미지 생성 을 참조하십시오.
- Blueprint-name 은 에지 설치 프로그램 청사진 이름에 대한 RHEL입니다.
image-type 은
edge-installer
입니다.쓰기 프로세스가 큐에 추가되었음을 확인합니다. 또한 생성된 이미지에 대한 UUID(Universally Unique Identifier) 번호를 표시합니다. UUID 번호를 사용하여 빌드를 추적합니다. 또한 추가 작업을 위해 UUID 번호를 편리하게 유지합니다.
이미지 compose 상태를 확인합니다.
# composer-cli compose status
명령 출력은 다음 형식으로 상태를 표시합니다.
<UUID> RUNNING date blueprint-name blueprint-version image-type
참고이미지 생성 프로세스를 완료하는 데 몇 분이 걸립니다.
이미지 생성 프로세스를 중단하려면 다음을 실행합니다.
# composer-cli compose cancel <UUID>
기존 이미지를 삭제하려면 다음을 실행합니다.
# composer-cli compose delete <UUID>
RHEL 이미지 빌더는 이미지 빌드 중에 실행 중인 컨테이너에서 제공하는 커밋을 가져옵니다.
이미지 빌드가 완료되면 결과 ISO 이미지를 다운로드할 수 있습니다.
이미지를 다운로드합니다. Edge 이미지 다운로드를 참조하십시오.
이미지가 준비되면 비 네트워크 배포에 사용할 수 있습니다. 네트워크 기반 배포가 아닌 경우 Edge 이미지의 RHEL 설치를 참조하십시오.
14.3. 네트워크 기반이 아닌 배포를 위한 Edge 이미지용 RHEL 설치
Edge 이미지에 대한 RHEL을 설치하려면 다음 단계를 따르십시오.
사전 요구 사항
- Edge Installer ISO 이미지를 위한 RHEL을 생성했습니다.
- 실행 중인 컨테이너를 중지했습니다.
- 생성한 커밋을 설치할 디스크 이미지입니다.
-
edk2-ovmf
패키지가 설치되어 있습니다. -
virt-viewer
패키지가 설치되어 있어야 합니다. 사용자 계정을 사용하여 롤아웃을 사용자 지정할 수 있습니다. RHEL 웹 콘솔에서 RHEL 이미지 빌더를 사용하여 RHEL for Edge 이미지의 블루프린트 생성 을 참조하십시오.
주의용량에서 사용자 계정 사용자 지정을 정의하지 않으면 ISO 이미지에 로그인할 수 없습니다.
절차
qcow
VM 디스크 파일을 생성하여 (.iso
) 이미지를 설치합니다. 이는 VM(가상 머신)의 하드 디스크 드라이브 이미지입니다. 예를 들어 다음과 같습니다.$ qemu-img create -f qcow2 diskfile.qcow2 20G
virt-install
명령을 사용하여 디스크를 드라이브로 사용하고 설치 프로그램 ISO 이미지를 CD-ROM으로 부팅합니다. 예를 들어 다음과 같습니다.$ virt-install \ --boot uefi \ --name VM_NAME --memory 2048 \ --vcpus 2 \ --disk path=diskfile.qcow2 --cdrom /var/lib/libvirt/images/UUID-installer.iso \ --os-variant rhel9.0
이 명령은
virt-install
에 다음을 수행합니다.- BIOS 대신 UEFI를 사용하여 부팅하도록 VM에 지시합니다.
- 설치 ISO를 마운트합니다.
첫 번째 단계에서 생성된 하드 디스크 드라이브 이미지를 사용합니다.
Anaconda 설치 프로그램을 제공합니다. RHEL 설치 프로그램이 시작되고 ISO에서 Kickstart 파일을 로드하고 명령을 실행합니다(예: Edge 이미지 커밋용 RHEL 설치). 설치가 완료되면 RHEL 설치 프로그램에서 로그인 세부 정보를 묻는 메시지를 표시합니다.
참고Anaconda는 설치 중에 컨테이너 커밋을 사용하도록 사전 구성되어 있습니다. 그러나 디스크 파티션, 시간대 등의 시스템 구성을 설정해야 합니다.
virt-viewer
를 사용하여 Anaconda GUI에 연결하여 시스템 구성을 설정합니다.$ virt-viewer --connect qemu:///system --wait VM_NAME
- 시스템을 재부팅하여 설치를 완료합니다.
- 로그인 화면에서 사용자 계정 자격 증명을 지정하고 를 클릭합니다.
검증
에지 이미지의 RHEL이 성공적으로 설치되었는지 확인합니다.
$ rpm-ostree status
명령 출력은 이미지 커밋 ID를 제공하며 설치에 성공했는지 표시됩니다.
15장. 에지 이미지 RHEL 관리
에지 이미지의 RHEL을 관리하려면 다음 관리 작업을 수행할 수 있습니다.
- RHEL 웹 콘솔 또는 명령줄에서 이미지 빌더를 사용하여 RHEL for Edge 이미지 블루프린트 편집
- 이미지 빌더 명령줄을 사용하여 커밋 업데이트 빌드
- 에지 이미지의 RHEL 업데이트
-
노드 정책을 업데이트하도록 노드에서
rpm-ostree
원격 구성 - greenboot를 사용하여 RHEL for Edge 이미지를 수동 또는 자동으로 복원
15.1. 이미지 빌더를 사용하여 RHEL for Edge 이미지 블루프린트 편집
에지 이미지 options에 대한 RHEL을 다음과 같이 편집할 수 있습니다.
- 필요할 수 있는 추가 구성 요소 추가
- 기존 구성 요소의 버전 수정
- 기존 구성 요소 제거
15.1.1. RHEL 웹 콘솔에서 이미지 빌더를 사용하여 RHEL for Edge 블루프린트에 구성 요소 추가
RHEL for Edge 이미지 options에 구성 요소를 추가하려면 다음 사전 요구 사항을 충족했는지 확인한 후 절차에 따라 해당 devfile을 편집합니다.
사전 요구 사항
- RHEL 시스템에서 RHEL 이미지 빌더 대시보드에 액세스했습니다.
- RHEL for Edge 이미지용 블루프린트를 생성했습니다.
절차
RHEL 이미지 빌더 대시보드에서 편집할 블루프린트를 클릭합니다.
특정 청사진을 검색하려면 필터 텍스트 상자에 attributes 이름을 입력하고
를 클릭합니다.greater의 오른쪽 상단에서
을 클릭합니다.편집 마법사 가 열립니다.
- 세부 정보 페이지에서 10.0.0.1 이름을 업데이트하고 클릭합니다.
패키지 페이지에서 다음 단계를 수행합니다.
사용 가능한 패키지에서 필터 텍스트 상자에 추가할 패키지 이름을 입력하고 를 클릭합니다.
구성 요소 이름이 있는 목록이 표시됩니다.
- > >을 클릭하여 구성 요소를 10.0.0.1에 추가합니다.
검토 페이지에서 을 클릭합니다.
이제 새 패키지로 feature가 업데이트되었습니다.
15.1.2. 웹 콘솔에서 RHEL 이미지 빌더를 사용하여 블루프린트에서 구성 요소 제거
RHEL 이미지 빌더를 사용하여 생성한 블루프린트에서 원하지 않는 구성 요소를 하나 이상 제거하려면 다음 사전 요구 사항을 충족했는지 확인한 다음 절차를 따르십시오.
사전 요구 사항
- RHEL 시스템에서 RHEL 이미지 빌더 대시보드에 액세스했습니다.
- RHEL for Edge 이미지용 블루프린트를 생성했습니다.
- Edge leadership를 위해 RHEL에 하나 이상의 구성 요소를 추가했습니다.
절차
RHEL 이미지 빌더 대시보드에서 편집할 블루프린트를 클릭합니다.
특정 청사진을 검색하려면 필터 텍스트 상자에 attributes 이름을 입력하고
를 클릭합니다.greater의 오른쪽 상단에서
을 클릭합니다.편집 마법사 가 열립니다.
- 세부 정보 페이지에서 10.0.0.1 이름을 업데이트하고 클릭합니다.
패키지 페이지에서 다음 단계를 수행합니다.
- C piecesn 패키지에서 < 클릭하여 선택한 구성 요소를 제거합니다. 한 번에 모든 패키지를 제거하려면& ;-<를 클릭할 수도 있습니다.
검토 페이지에서 을 클릭합니다.
이제 해당 항목이 업데이트되었습니다.
15.1.3. 명령줄 인터페이스를 사용하여 에지 이미지 options를 위한 RHEL 편집
RHEL 이미지 빌더 명령줄을 사용하여 RHEL for Edge 이미지 블루프린트의 사양을 변경할 수 있습니다. 이렇게 하려면 다음 사전 요구 사항을 충족했는지 확인한 후 절차에 따라 해당1)을 편집합니다.
사전 요구 사항
- RHEL 이미지 빌더 명령줄에 액세스할 수 있습니다.
- 에지 이미지 options용 RHEL을 생성했습니다.
절차
배치를 로컬 텍스트 파일에 저장(export)합니다.
# composer-cli blueprints save BLUEPRINT-NAME
선택한 텍스트 편집기로
BLUEPRINT-NAME.toml
파일을 편집하고 변경합니다.편집 작업을 완료하기 전에 파일이 유효한인지 확인합니다.
버전 번호를 늘립니다.
Semantic Versioning scheme을 사용해야 합니다.
참고버전을 변경하지 않으면 버전의 패치 구성 요소가 자동으로 증가됩니다.
콘텐츠가 유효한 TOML 사양인지 확인합니다. 자세한 내용은 TOML 설명서를 참조하십시오.
참고TOML 문서는 커뮤니티 제품이며 Red Hat에서 지원하지 않습니다. 이 툴의 모든 문제는 https://github.com/toml-lang/toml/issues 에서 보고할 수 있습니다.
- 파일을 저장하고 편집기를 종료합니다.
블루프린트를 RHEL 이미지 빌더 서버로 다시 푸시(가져오기)합니다.
# composer-cli blueprints push BLUEPRINT-NAME.toml
참고블루프린트를 RHEL 이미지 빌더 서버로 다시 푸시할 때
.toml
확장자를 포함한 파일 이름을 제공합니다.RHEL 이미지 빌더에 업로드된 콘텐츠가 편집 내용과 일치하는지 확인합니다.
# composer-cli blueprints show BLUEPRINT-NAME
Makefile 및 해당 종속 항목에 나열된 구성 요소 및 버전이 유효한지 확인합니다.
# composer-cli blueprints depsolve BLUEPRINT-NAME
15.2. 에지 이미지 RHEL 업데이트
15.2.1. RHEL for Edge 이미지 업데이트 배포 방법
에지 이미지용 RHEL을 사용하면 수동으로 업데이트를 배포하거나 배포 프로세스를 자동화할 수 있습니다. 업데이트는 각 업데이트의 상태를 알 수 있는 원자성 방식으로 적용되며 업데이트는 준비되고 재부팅 시에만 적용됩니다. 장치를 재부팅할 때까지 변경 사항이 표시되지 않으므로 재부팅을 예약하여 최대한의 가동 시간을 유지할 수 있습니다.
이미지 업데이트 중에 업데이트된 운영 체제 콘텐츠만 네트워크를 통해 전송됩니다. 이렇게 하면 전체 이미지를 전송하는 것보다 배포 프로세스가 더 효율적입니다. /usr
의 운영 체제 바이너리와 라이브러리는 읽기 전용
이며 읽기 및 쓰기
상태는 /var
및 /etc
디렉터리에서 유지됩니다.
새 배포로 이동할 때 /etc
및 /var
디렉터리가 읽기 및 쓰기
권한이 있는 새 배포로 복사됩니다. /usr
디렉터리는 읽기 전용
권한이 있는 새 배포 디렉터리에 소프트 링크로 복사됩니다.
다음 다이어그램은 RHEL for Edge 이미지 업데이트 배포 프로세스를 보여줍니다.
기본적으로 새 시스템은 chroot
작업과 유사한 프로세스를 사용하여 부팅됩니다. 즉 시스템은 기본 서버 환경에 대한 노출을 제어하는 동안 파일 시스템에 대한 액세스를 제어할 수 있습니다. 새로운 /sysroot
디렉토리에는 주로 다음과 같은 부분이 있습니다.
-
/sysroot/ostree/repo
디렉터리에 있는 리포지토리 데이터베이스입니다. -
시스템 업데이트의 각 작업에서 생성되는
/sysroot/ostree/deploy/rhel/deploy
디렉터리의 파일 시스템 개정입니다. -
이전 시점에서 배포에 연결되는
/sysroot/ostree/boot
디렉터리입니다./ostree
는/sysroot/ostree
에 대한 소프트 링크입니다./sysroot/ostree/boot
디렉토리의 파일은 중복되지 않습니다. 배포 중에 변경되지 않은 경우 동일한 파일이 사용됩니다. 파일은/sysroot/ostree/repo/objects
디렉터리에 저장된 다른 파일에 하드 링크입니다.
운영 체제는 다음과 같은 방식으로 배포를 선택합니다.
-
dracut
툴은initramfs 루트
파일 시스템의ostree
커널 인수를 구문 분석하고/usr
디렉터리를읽기 전용
바인드 마운트로 설정합니다. -
/sysroot
의 배포 디렉터리를/
디렉터리에 바인딩합니다. -
MS_MOVE
마운트 플래그를 사용하여 이미 마운트된 운영 체제를 다시 마운트
문제가 발생하면 rpm-ostree
cleanup 명령으로 이전 배포를 제거하여 배포 롤백을 수행할 수 있습니다. 각 클라이언트 머신에는 /ostree/repo
에 저장된 OSTree
리포지토리와 /ostree/deploy/$STATEROOT/$CHECKSUM
에 저장된 배포 세트가 포함되어 있습니다.
RHEL for Edge 이미지의 배포 업데이트를 통해 여러 장치에 걸쳐 시스템 일관성이 향상되고 재현이 쉬워지고 사전 및 후 시스템 상태 변경 간의 격리를 개선할 수 있습니다.
15.2.2. 커밋 업데이트 빌드
다음과 같은 블루프린트를 변경한 후 커밋 업데이트를 빌드할 수 있습니다.
- 시스템에 필요한 추가 패키지 추가
- 기존 구성 요소의 패키지 버전 수정
- 기존 패키지를 제거합니다.
사전 요구 사항
- RHEL 이미지 빌더를 실행하는 시스템을 업데이트했습니다.
- 블루프린트 업데이트가 생성되어 있습니다.
- 이전에 OSTree 리포지토리를 생성하고 HTTP를 통해 제공했습니다. RHEL for Edge 이미지를 설치할 웹 서버 설정을 참조하십시오.
절차
새 커밋 이미지 작성을 시작합니다.
--url
,--ref
,블루프린트-name
,edge-commit
.# composer-cli compose start-ostree --ref rhel/9/x86_64/edge --url http://localhost:8080/repo <blueprint-name> edge-commit
명령은 작성 프로세스를 시작하기 전에 OStree 리포지터리에서 메타데이터를 가져오도록 지시합니다. 생성된 새 OSTree 커밋에는 상위 이미지로 원본 OSTree 커밋에 대한 참조가 포함되어 있습니다.
작성 프로세스가 완료되면
.tar
파일을 가져옵니다.# composer-cli compose image <UUID>
OSTree 리포지토리에 커밋 기록을 저장할 수 있도록 임시 디렉터리에 커밋을 추출합니다.
$ tar -xf UUID.tar -C /var/tmp
tar -xf
명령을 사용하여 결과 OSTree 리포지토리 커밋을 검사합니다. 생성된 OSTree 리포지터리를 검사할 수 있도록 tar 파일을 디스크에 추출합니다.$ ostree --repo=/var/tmp/repo log rhel/9/x86_64/edge commit d523ef801e8b1df69ddbf73ce810521b5c44e9127a379a4e3bba5889829546fa Parent: f47842de7e6859cee07d743d3c67949420874727883fa9dbbaeb5824ad949d91 ContentChecksum: f0f6703696331b661fa22d97358db48ba5f8b62711d9db83a00a79b3ae0dfe16 Date: 2023-06-04 20:22:28 /+0000 Version: 9
출력 예제에는 상위 커밋을 참조하는 리포지터리에 단일 OSTree 커밋이 있습니다. 상위 커밋은 이전에 작성한 원래 OSTree 커밋과 동일한 체크섬입니다.
ostree pull-local
명령을 사용하여 두 커밋을 병합합니다.$ sudo ostree --repo=/var/srv/httpd/repo pull-local /var/tmp/repo 20 metadata, 22 content objects imported; 0 bytes content written
이 명령은 디스크의 위치에서 모든 새 메타데이터 및 콘텐츠를
/var/
srv/httpd
검증
대상 OSTree 리포지터리를 검사합니다.
$ ostree --repo=/var/srv/httpd/repo log rhel/9/x86_64/edge commit d523ef801e8b1df69ddbf73ce810521b5c44e9127a379a4e3bba5889829546fa Parent: f47842de7e6859cee07d743d3c67949420874727883fa9dbbaeb5824ad949d91 ContentChecksum: f0f6703696331b661fa22d97358db48ba5f8b62711d9db83a00a79b3ae0dfe16 Date: 2023-06-04 20:22:28 /+0000 Version: 9 (no subject) commit f47842de7e6859cee07d743d3c67949420874727883fa9dbbaeb5824ad949d91 ContentChecksum: 9054de3fe5f1210e3e52b38955bea0510915f89971e3b1ba121e15559d5f3a63 Date: 2023-06-04 20:01:08 /+0000 Version: 9 (no subject)
대상 OSTree 리포지토리에 이제 논리적 순서로 리포지토리에 두 개의 커밋이 포함되어 있음을 확인할 수 있습니다. 성공적으로 확인한 후 RHEL for Edge 시스템을 업데이트할 수 있습니다.
15.2.3. 에지 이미지 업데이트를 위해 수동으로 RHEL 배포
엣지용 RHEL을 편집한 후 이미지 커밋을 업데이트할 수 있습니다. RHEL 이미지 빌더에서는 업데이트된 RHEL for Edge 이미지에 대한 새 커밋을 생성합니다. 이 새 커밋을 사용하여 최신 패키지 버전 또는 추가 패키지와 함께 이미지를 배포합니다.
에지 이미지 업데이트를 위해 RHEL을 배포하려면 사전 요구 사항을 충족해야 하며 절차를 따르십시오.
사전 요구 사항
- RHEL 시스템에서 RHEL 이미지 빌더 대시보드에 액세스했습니다.
- 에지 이미지 options용 RHEL을 생성했습니다.
- Edge 이미지용 RHEL을 편집했습니다.
절차
- RHEL 이미지 빌더 대시보드에서 클릭합니다.
이미지 생성 창에서 다음 단계를 수행합니다.
이미지 출력 페이지에서 다음을 수행합니다.
- Select a Blueprint dropdown 목록에서 편집한 청사진을 선택합니다.
-
이미지 출력 유형 드롭다운 목록에서
Edge Commit(.tar)에 대해 RHEL
을 선택합니다. 을 클릭합니다.
OSTree 설정 페이지에서 다음을 입력합니다.
- 리포지토리 URL 필드에 이미지에 포함할 커밋의 OSTree 리포지토리에 대한 URL을 입력합니다. 예: http://10.0.2.2:8080/repo/. RHEL for Edge 이미지를 설치할 웹 서버 설정을 참조하십시오.
- 이전에 생성된 상위 커밋 ID를 지정합니다. 에지 이미지 커밋용 RHEL 추출 을 참조하십시오.
-
Ref 필드에서 커밋의 이름을 지정하거나 비워 둘 수 있습니다. 기본적으로 웹 콘솔은
Ref
를rhel/9/arch_name/edge
로 지정합니다. 을 클릭합니다.
검토 페이지에서 사용자 정의를 확인하고 클릭합니다. RHEL 이미지 빌더가 업데이트된 블루프린트에 대한 RHEL for Edge 이미지를 생성하기 시작합니다. 이미지 생성 프로세스를 완료하는 데 몇 분이 걸립니다.
엣지 이미지 생성 진행 상황을 RHEL을 보려면 장외선에서 청사진 이름을 클릭한 다음 Images 탭을 클릭합니다.
결과 이미지에는 추가한 최신 패키지가 포함되어 있으며 원래
커밋 ID
를 상위로 사용합니다.
Edge Commit (
.tar
) 이미지를 위한 RHEL을 다운로드합니다.-
Images 탭에서 를 클릭하여 RHEL for Edge Commit(
.tar
) 이미지를 시스템에 저장합니다.
-
Images 탭에서 를 클릭하여 RHEL for Edge Commit(
OSTree 커밋(
.tar
) 파일을 추출합니다.# tar -xf UUID-commit.tar -C UPGRADE_FOLDER
OSTree 리포지터리를 업그레이드합니다.
# ostree --repo=/usr/share/nginx/html/repo pull-local UPGRADE_FOLDER # ostree --repo=/usr/share/nginx/html/repo summary -u
프로비저닝된 RHEL 시스템의 원래 에지 이미지에서 현재 상태를 확인합니다.
$ rpm-ostree status
새 커밋 ID가 없는 경우 다음 명령을 실행하여 사용 가능한 업그레이드가 있는지 확인합니다.
$ rpm-ostree upgrade --check
명령 출력은 현재 활성 OSTree 커밋 ID를 제공합니다.
OSTree를 업데이트하여 새로운 OSTree 커밋 ID를 사용할 수 있도록 합니다.
$ rpm-ostree upgrade
ostree에서 리포지토리에 업데이트가 있는지 확인합니다. yes인 경우 이 새 커밋 업데이트 배포를 활성화할 수 있도록 업데이트를 가져와서 시스템을 재부팅하도록 요청합니다.
현재 상태를 다시 확인합니다.
$ rpm-ostree status
이제 사용 가능한 두 개의 커밋이 있음을 확인할 수 있습니다.
- 활성 상위 커밋입니다.
- 활성 상태가 아니며 1개의 차이점이 포함된 새 커밋입니다.
새 배포를 활성화하고 새 커밋을 활성화하려면 시스템을 재부팅합니다.
# systemctl reboot
Anaconda 설치 프로그램이 새 배포로 재부팅됩니다. 로그인 화면에서 부팅할 수 있는 새 배포를 확인할 수 있습니다.
-
최신 배포(commit)로 부팅하려면
rpm-ostree
upgrade 명령에서 부팅 항목을 자동으로 주문하여 새 배포가 목록의 첫 번째가 되도록 합니다. 선택적으로 키보드의 화살표 키를 사용하여 GRUB 메뉴 항목을 선택하고 를 누릅니다. - 로그인 사용자 계정 자격 증명을 제공합니다.
OSTree 상태를 확인합니다.
$ rpm-ostree status
명령 출력은 활성 커밋 ID를 제공합니다.
변경된 패키지를 보려면 상위 커밋과 새 커밋 사이에 diff를 실행합니다.
$ rpm-ostree db diff parent_commit new_commit
업데이트는 설치한 패키지가 사용 가능하고 사용할 준비가 되었음을 보여줍니다.
15.2.4. 명령줄을 사용하여 에지 이미지 업데이트를 수동으로 위한 RHEL 배포
엣지용 RHEL을 편집한 후 이미지 커밋을 업데이트할 수 있습니다. RHEL 이미지 빌더에서는 업데이트된 RHEL for Edge 이미지에 대한 새 커밋을 생성합니다. 새 커밋을 사용하여 최신 패키지 버전 또는 CLI를 사용하는 추가 패키지와 함께 이미지를 배포합니다.
CLI를 사용하여 에지 이미지 업데이트를 위한 RHEL을 배포하려면 사전 요구 사항을 충족해야 하는 다음 절차를 따르십시오.
사전 요구 사항
- 에지 이미지 청사진용 RHEL을 만들었습니다.
- 에지 이미지 청사진을 위해 RHEL을 편집했습니다. 명령줄 인터페이스를 사용하여 에지 이미지 청사진용 RHEL 편집 을 참조하십시오.
절차
다음 인수를 사용하여 에지 커밋(
.tar
)의 RHEL 이미지를 만듭니다.# composer-cli compose start-ostree --ref ostree_ref --url URL-OSTree-repository -blueprint_name_ image-type
다음과 같습니다.
-
에지 컨테이너 커밋용 RHEL을 생성하는 동안 제공한 참조
입니다
. 예:rhel/9/x86_64/edge
. -
URL-OSTree-repository
는 이미지에 포함할 커밋의 OSTree 리포지토리의 URL입니다. 예: http://10.0.2.2:8080/repo/. Edge 이미지에 대해 RHEL을 설치하기 위해 웹 서버 설정을 참조하십시오. image-type
은edge-commit
입니다.RHEL 이미지 빌더는 업데이트된 블루프린트에 대한 RHEL for Edge 이미지를 생성합니다.
-
에지 컨테이너 커밋용 RHEL을 생성하는 동안 제공한 참조
RHEL에서 Edge 이미지 생성 진행 상황을 확인합니다.
# composer-cli compose status
참고이미지 생성 프로세스를 완료하는 데 최대 10~30분이 걸릴 수 있습니다.
결과 이미지에는 추가한 최신 패키지가 포함되어 있으며 원래
커밋 ID
가 상위 항목으로 포함되어 있습니다.- 에지 이미지에 대한 결과 RHEL을 다운로드합니다. 자세한 내용은 RHEL 이미지 빌더 명령줄 인터페이스를 사용하여 RHEL for Edge 이미지 다운로드를 참조하십시오.
OSTree 커밋을 추출합니다.
# tar -xf UUID-commit.tar -C upgrade_folder
- httpd를 사용하여 OSTree 커밋을 제공합니다. Edge 이미지용 RHEL을 설치할 웹 서버 설정을 참조하십시오.
OSTree 리포지터리를 업그레이드합니다.
# ostree --repo=/var/www/html/repo pull-local /tmp/ostree-commit/repo # ostree --repo=/var/www/html/repo summary -u
원래 에지 이미지에서 프로비저닝된 RHEL 시스템에서 현재 상태를 확인합니다.
$ rpm-ostree status
새 커밋 ID가 없는 경우 다음 명령을 실행하여 사용 가능한 업그레이드가 있는지 확인합니다.
$ rpm-ostree upgrade --check
명령 출력은 현재 활성 OSTree 커밋 ID를 제공합니다.
OSTree를 업데이트하여 새 OSTree 커밋 ID를 사용할 수 있도록 합니다.
$ rpm-ostree upgrade
ostree에서 리포지토리에 업데이트가 있는지 확인합니다. 예, 새 커밋 업데이트의 배포를 활성화할 수 있도록 업데이트를 가져와서 시스템을 재부팅하도록 요청합니다.
현재 상태를 다시 확인합니다.
$ rpm-ostree status
이제 사용 가능한 커밋이 두 개인지 확인해야 합니다.
- 활성 상위 커밋
- 새 커밋이 활성 상태가 아니며 하나의 추가 차이점이 포함되어 있습니다.
새 배포를 활성화하고 새 커밋을 활성화하려면 시스템을 재부팅합니다.
# systemctl reboot
Anaconda 설치 프로그램이 새 배포로 재부팅됩니다. 로그인 화면에서 부팅할 수 있는 새 배포를 확인할 수 있습니다.
-
최신 배포로 부팅하려는 경우
rpm-ostree upgrade
명령은 새 배포가 목록에 먼저 포함되도록 부팅 항목을 자동으로 주문합니다. 선택적으로 키보드의 화살표 키를 사용하여 GRUB 메뉴 항목을 선택하고 를 누릅니다. - 계정 자격 증명을 사용하여 로그인합니다.
OSTree 상태를 확인합니다.
$ rpm-ostree status
명령 출력은 활성 커밋 ID를 제공합니다.
변경된 패키지를 보려면 상위 커밋과 새 커밋 사이에 diff를 실행합니다.
$ rpm-ostree db diff parent_commit new_commit
업데이트는 설치한 패키지가 사용 가능하고 사용할 준비가 되었음을 보여줍니다.
15.2.5. 네트워크 기반이 아닌 배포를 위해 RHEL for Edge 이미지 업데이트를 수동으로 배포
RHEL for Edge 블루프린트를 편집한 후 해당 업데이트로 RHEL for Edge 커밋 이미지를 업데이트할 수 있습니다. 예를 들어 VM에 이미 배포된 RHEL for Edge 이미지를 업데이트하기 위해 RHEL 이미지 빌더를 사용하여 새 커밋을 생성합니다. 이 새 커밋을 사용하여 최신 패키지 버전 또는 추가 패키지와 함께 이미지를 배포합니다.
에지 이미지 업데이트를 위해 RHEL을 배포하려면 사전 요구 사항을 충족해야 하며 절차를 따르십시오.
사전 요구 사항
- 호스트에서 브라우저에서 웹 콘솔에서 RHEL 이미지 빌더 앱을 열었습니다.
- RHEL for Edge 시스템이 프로비저닝되어 실행 중입니다.
- HTTP를 통해 제공되는 OSTree 리포지토리가 있습니다.
- 이전에 생성된 RHEL for Edge 이미지 블루프린트를 편집했습니다.
절차
- 시스템 호스트에서 RHEL 이미지 빌더 대시보드에서 을 클릭합니다.
이미지 생성 창에서 다음 단계를 수행합니다.
이미지 출력 페이지에서 다음을 수행합니다.
- Select a Blueprint dropdown 목록에서 편집한 청사진을 선택합니다.
-
이미지 출력 유형 드롭다운 목록에서
에지 컨테이너(.tar)에 대해 RHEL
을 선택합니다. - 을 클릭합니다.
OSTree 설정 페이지에서 다음을 입력합니다.
- 리포지토리 URL 필드에 이미지에 포함할 커밋의 OSTree 리포지토리에 대한 URL을 입력합니다. 예: http://10.0.2.2:8080/repo/. RHEL for Edge 이미지를 설치할 웹 서버 설정을 참조하십시오.
- 이전에 생성된 상위 커밋 ID를 지정합니다. 에지 이미지 커밋용 RHEL 추출 을 참조하십시오.
-
Ref 필드에서 커밋의 이름을 지정하거나 비워 둘 수 있습니다. 기본적으로 웹 콘솔은
Ref
를rhel/9/arch_name/edge
로 지정합니다. - 을 클릭합니다.
검토 페이지에서 사용자 지정을 확인하고 을 클릭합니다.
RHEL 이미지 빌더는 업데이트된 블루프린트에 대한 RHEL for Edge 이미지를 생성합니다.
이미지 탭을 클릭하여 RHEL for Edge 이미지 생성의 진행 상황을 확인합니다.
참고이미지 생성 프로세스를 완료하는 데 몇 분이 걸립니다.
결과 이미지에는 추가한 최신 패키지가 포함되어 있으며 원래
커밋 ID
가 상위 항목으로 포함되어 있습니다.
호스트에서 결과 RHEL for Edge 이미지를 다운로드합니다.
-
이미지 탭에서 클릭하여 RHEL for Edge Container (
.tar
) 이미지를 호스트 시스템에 저장합니다.
-
이미지 탭에서 클릭하여 RHEL for Edge Container (
원래 엣지 이미지에서 프로비저닝된 RHEL 시스템에서 다음 단계를 수행합니다.
에지 컨테이너 이미지의 RHEL을 Podman에 로드하여 이번에 하위 커밋 ID를 제공합니다.
$ cat ./child-commit_ID-container.tar | sudo podman load
Podman
을 실행합니다.# sudo podman run -p 8080:8080 localhost/edge-test
OSTree 리포지터리를 업그레이드합니다.
# ostree --repo=/var/www/html/repo pull-local /tmp/ostree-commit/repo # ostree --repo=/var/www/html/repo summary -u
프로비저닝된 RHEL 시스템의 원래 에지 이미지에서 현재 상태를 확인합니다.
$ rpm-ostree status
새 커밋 ID가 없는 경우 다음 명령을 실행하여 사용 가능한 업그레이드가 있는지 확인합니다.
$ rpm-ostree upgrade --check
사용 가능한 업데이트가 있는 경우 명령 출력은 현재 활성 OSTree 커밋 ID와 같은 OSTree 리포지토리에서 사용 가능한 업데이트에 대한 정보를 제공합니다. 사용 가능한 업데이트가 없음을 알리는 메시지가 표시됩니다.
OSTree를 업데이트하여 새로운 OSTree 커밋 ID를 사용할 수 있도록 합니다.
$ rpm-ostree upgrade
ostree에서 리포지토리에 업데이트가 있는지 확인합니다. yes인 경우 이 새 커밋 업데이트 배포를 활성화할 수 있도록 업데이트를 가져와서 시스템을 재부팅하도록 요청합니다.
현재 시스템 상태를 확인합니다.
$ rpm-ostree status
이제 사용 가능한 두 개의 커밋이 있음을 확인할 수 있습니다.
- 활성 상위 커밋입니다.
- 활성 상태가 아니며 1개의 차이점이 포함된 새 커밋입니다.
새 배포를 활성화하고 새 커밋을 활성화하려면 시스템을 재부팅합니다.
# systemctl reboot
Anaconda 설치 프로그램이 새 배포로 재부팅됩니다. 로그인 화면에서 부팅할 수 있는 새 배포를 확인할 수 있습니다.
최신 커밋으로 부팅하려면 다음 명령을 실행하여 새 배포가 목록의 첫 번째 배포가 되도록 부팅 항목을 자동으로 정렬합니다.
$ rpm-ostree upgrade
선택적으로 키보드의 화살표 키를 사용하여 GRUB 메뉴 항목을 선택하고
키를 누를 수 있습니다.
- 로그인 사용자 계정 자격 증명을 제공합니다.
OSTree 상태를 확인합니다.
$ rpm-ostree status
명령 출력은 활성 커밋 ID를 제공합니다.
변경된 패키지를 보려면 상위 커밋과 새 커밋 사이에 diff를 실행합니다.
$ rpm-ostree db diff parent_commit new_commit
업데이트는 설치한 패키지가 사용 가능하고 사용할 준비가 되었음을 보여줍니다.
15.3. 에지 시스템을 위한 RHEL 업그레이드
15.3.1. RHEL 8 시스템을 RHEL 9로 업그레이드
rpm-ostree rebase
명령을 사용하여 RHEL 8 시스템을 RHEL 9로 업그레이드할 수 있습니다. 명령은 RHEL 8의 최신 업데이트에서 RHEL 9의 최신 업데이트로 부터 에지 업그레이드의 기본 패키지 세트를 완전히 지원합니다. 업그레이드에서 RHEL 9 이미지를 다운로드하여 백그라운드에서 설치합니다. 업그레이드가 완료되면 새 RHEL 9 이미지를 사용하려면 시스템을 재부팅해야 합니다.
업그레이드는 가능한 모든 rpm
패키지 버전과 포함 기능을 지원하지 않습니다. 이러한 패키지가 예상대로 작동하는지 확인하려면 패키지 추가를 테스트해야 합니다.
사전 요구 사항
- Edge 8 시스템용 RHEL이 실행 중입니다.
- HTTP를 통한 OSTree 리포지토리 서버
- 업그레이드할 Edge 9 이미지에 대해 RHEL에 대한 SPL을 생성했습니다.
절차
RHEL 이미지 빌더가 실행되는 시스템에서 RHEL for Edge 9 이미지를 생성합니다.
이미지 작성을 시작합니다.
$ sudo composer-cli compose start blueprint-name edge-commit
선택적으로 다음 명령을 사용하여 기존 OSTree 리포지토리를 사용하여 새 RHEL for Edge 9 이미지를 생성할 수도 있습니다.
$ sudo composer-cli compose start-ostree --ref rhel/8/x86_64/edge --parent parent-OSTree-REF --url URL blueprint-name edge-commit
- compose가 완료되면 이미지를 다운로드합니다.
다운로드한 이미지를
/var/www/html/
폴더에 추출합니다.$ sudo tar -xf image_file -C /var/www/html
httpd
서비스를 시작합니다.$ systemctl start httpd.service
Edge 장치의 RHEL에서 현재 원격 리포지토리 설정을 확인합니다.
$ sudo cat /etc/ostree/remotes.d/edge.conf
참고Kickstart 파일을 구성하는 방법에 따라
/etc/ostree/remotes.d
리포지토리를 비워 둘 수 있습니다. 원격 리포지토리를 구성한 경우 해당 구성을 확인할 수 있습니다.edge-installer
,raw-image
및simplified-installer
이미지의 경우 remote는 기본적으로 구성됩니다.현재 URL 리포지토리를 확인합니다.
$ sudo ostree remote show-url edge
edge 는 Ostree 저장소입니다.
원격 참조 분기를 나열합니다.
$ ostree remote refs edge
다음 출력을 볼 수 있습니다.
Error: Remote refs not available; server has no summary file
새 저장소를 추가하려면 다음을 수행합니다.
원격 리포지토리를 추가하도록 URL 키를 구성합니다. 예를 들어 다음과 같습니다.
$ sudo ostree remote add \ --no-gpg-verify rhel9 http://192.168.122.1/repo/
업그레이드할 RHEL 9 커밋을 가리키도록 URL 키를 구성합니다. 예를 들어 다음과 같습니다.
$ sudo cat /etc/ostree/remotes.d/edge.conf [remote "edge"] url=http://192.168.122.1/ostree/repo/ gpg-verify=false
URL이 새 원격 리포지토리로 설정되어 있는지 확인합니다.
$ sudo cat /etc/ostree/remotes.d/rhel9.conf [remote "edge"] url=http://192.168.122.1/repo/ gpg-verify=false
새 URL 저장소 보기:
$ sudo ostree remote show-url rhel9 http://192.168.122.1/ostree-rhel9/repo/
현재 원격 목록 옵션을 나열합니다.
$ sudo ostree remote list output: edge rhel9
시스템을 RHEL 9 버전으로 리베이스하여 RHEL 9 버전의 참조 경로를 제공합니다.
$ rpm-ostree rebase rhel9:rhel/9/x86_64/edge
시스템을 재부팅합니다.
$ systemctl reboot
- 사용자 이름과 암호를 입력합니다.
현재 시스템 상태를 확인합니다.
$ rpm-ostree status
검증
현재 실행 중인 배포의 현재 상태를 확인합니다.
$ rpm-ostree status
선택 사항: 커널에서 관리하는 프로세서 및 작업을 실시간으로 나열합니다.
$ top
업그레이드가 요구 사항을 지원하지 않는 경우 이전 안정 배포 RHEL 8 버전으로 수동으로 롤백할 수 있습니다.
$ sudo rpm-ostree rollback
시스템을 재부팅합니다. 사용자 이름과 암호를 입력합니다.
$ systemctl reboot
재부팅 후 시스템에서 RHEL 9를 성공적으로 실행합니다.
참고업그레이드가 성공했으며 이전 배포 RHEL 8 버전을 사용하지 않으려면 이전 리포지토리를 삭제할 수 있습니다.
$ sudo ostree remote delete edge
추가 리소스
- RPM-ostree 업데이트 및 리베이스 실패 커널 오류를 찾을 수 없음 (Red Hat Knowledgebase)
15.4. 에지 자동 이미지 업데이트를 위한 RHEL 배포
에지 장치에 에지 이미지의 RHEL을 설치한 후 사용 가능한 이미지 업데이트를 확인하고 자동 적용할 수 있습니다.
rpm-ostreed-automatic.service
(systemd 서비스) 및 rpm-ostreed-automatic.timer
(systemd 타이머)는 검사 및 업그레이드 빈도를 제어합니다. 사용 가능한 업데이트가 있는 경우 스테이징 배포로 표시됩니다.
자동 이미지 업데이트를 배포하려면 다음과 같은 상위 이미지 업데이트가 포함됩니다.
- 이미지 업데이트 정책 업데이트
- 자동 업데이트 다운로드 및 스테이징 활성화
15.4.1. 에지 이미지 업데이트 정책의 RHEL 업데이트 정책 업데이트
이미지 업데이트 정책을 업데이트하려면 Edge 장치의 /etc/rpm-ostreed.conf
위치에 있는 rpm-ostreed.conf
파일에서 AutomaticUpdatePolicy
및 IdleExitTimeout
설정을 사용합니다.
AutomaticUpdatePolicy
설정은 자동 업데이트 정책을 제어하고 다음과 같은 업데이트 확인 옵션이 있습니다.
-
제공되지 않음
: 자동 업데이트를 비활성화합니다. 기본적으로AutomaticUpdatePolicy
설정은none
으로 설정됩니다. -
확인
:rpm-ostree
상태로 사용 가능한 업데이트를 표시하는 충분한 메타데이터를 다운로드합니다. -
stage
: 재부팅 시 적용되는 업데이트를 다운로드하고 압축을 풉니다.
IdleExitTimeout
설정은 데몬 종료 전의 비활성 시간(초)을 제어하며 다음과 같은 옵션을 갖습니다.
- 0: auto-exit을 비활성화합니다.
-
60: 기본적으로
IdleExitTimeout
설정은60
으로 설정됩니다.
자동 업데이트를 활성화하려면 다음 단계를 수행합니다.
절차
/etc/rpm-ostreed.conf
파일에서 다음을 업데이트합니다.-
확인하려면
AutomaticUpdatePolicy
값을 변경합니다. -
업데이트 검사를 실행하려면
IdleExitTimeout
에 값을 초 단위로 지정합니다.
-
rpm-ostreed
서비스를 다시 로드하고systemd
타이머를 활성화합니다.# systemctl reload rpm-ostreed # systemctl enable rpm-ostreed-automatic.timer --now
rpm-ostree
상태를 확인하여 자동 업데이트 정책이 구성되고 시간이 활성화되었는지 확인합니다.# rpm-ostree status
명령 출력은 다음을 보여줍니다.
State: idle; auto updates enabled (check; last run <minutes> ago)
또한 출력에 사용 가능한 업데이트에 대한 정보도 표시됩니다.
15.4.2. RHEL for Edge 자동 다운로드 및 업데이트 스테이징 활성화
이미지 업데이트 정책을 업데이트하여 이미지 업데이트를 확인한 후 업데이트 세부 정보와 함께 해당 업데이트가 표시되는지 확인합니다. 업데이트를 적용하기로 결정하면 정책을 활성화하여 업데이트를 자동으로 다운로드하고 스테이징하십시오. 그런 다음 사용 가능한 이미지 업데이트가 다운로드되어 배포를 위해 준비됩니다. 업데이트가 적용되고 에지 장치를 재부팅할 때 적용됩니다.
업데이트 자동 다운로드 및 스테이징 정책을 활성화하려면 다음 업데이트를 수행합니다.
절차
-
/etc/rpm-ostreed.conf
파일에서 "AutomaticUpdatePolicy"를스테이징
으로 업데이트합니다. rpm-ostreed
서비스를 다시 로드합니다.# systemctl enable rpm-ostreed-automatic.timer --now
rpm-ostree
상태 확인# rpm-ostree status
명령 출력은 다음을 보여줍니다.
State: idle AutomaticUpdates: stage; rpm-ostreed-automatic.timer: last run <time> ago
업데이트를 시작하려면 타이머가 업데이트를 시작하도록 대기하거나 서비스를 수동으로 시작할 수 있습니다.
# systemctl start rpm-ostreed-automatic.service
업데이트가 시작되면
rpm-ostree
상태에 다음이 표시됩니다.# rpm-ostree status State: busy AutomaticUpdates: stage; rpm-ostreed-automatic.service: running Transaction: automatic (stage)
업데이트가 완료되면 배포 목록에 새 배포가 준비되고 원래 부팅된 배포는 그대로 유지됩니다. 새 배포를 사용하여 시스템을 부팅하거나 다음 업데이트를 기다릴 수 있는지 결정할 수 있습니다.
배포 목록을 보려면
rpm-ostree status
명령을 실행합니다.다음은 샘플 출력입니다.
# rpm-ostree status State: idle AutomaticUpdates: stage; rpm-ostreed-automatic.timer: last run <time> ago Deployments:
업데이트된 패키지 세부 정보를 사용하여 배포 목록을 보려면
rpm-ostree status -v
명령을 실행합니다.
15.5. 에지 이미지용 RHEL 롤백
RHEL for Edge는 운영 체제에 트랜잭션 업데이트를 적용하기 때문에 수동으로 또는 실패한 업데이트를 마지막 알려진 양호한 상태로 자동 롤백하여 업데이트 중에 시스템 실패를 방지할 수 있습니다. greenboot
프레임워크를 사용하여 확인 및 롤백 프로세스를 자동화할 수 있습니다.
greenboot
상태 점검 프레임워크는 rpm-ostree
를 활용하여 시스템 시작 시 사용자 정의 상태 점검을 실행합니다. 문제가 발생하면 시스템이 마지막 작동 상태로 롤백됩니다. rpm-ostree
업데이트를 배포할 때 스크립트를 실행하여 업데이트 후에도 중요한 서비스가 계속 작동할 수 있는지 확인합니다. 예를 들어 일부 실패한 패키지로 인해 시스템이 작동하지 않는 경우 시스템을 이전 안정된 시스템 버전으로 롤백할 수 있습니다. 이 프로세스를 통해 엣지 장치용 RHEL이 운영 상태에 있습니다.
이미지를 업데이트한 후 이전 이미지 배포를 유지하면서 새 이미지 배포를 생성합니다. 업데이트가 성공했는지 확인할 수 있습니다. 예를 들어 실패한 패키지로 인해 업데이트에 실패한 경우 시스템을 이전 안정 버전으로 롤백할 수 있습니다.
15.5.1. greenboot 검사 소개
Greenboot
는 rpm-ostree
기반 시스템에서 systemd
를 사용할 수 있는 일반 상태 점검 프레임워크입니다. 시스템에 설치할 수 있는 다음 RPM 패키지가 포함되어 있습니다.
greenboot
- 다음 기능이 포함된 패키지입니다.- 제공된 스크립트 확인
- 검사에 실패하면 시스템 재부팅
- 이전 배포로 롤백하면 재부팅 시 문제가 해결되지 않았습니다.
-
greenboot-default-health-checks
-녹색 부팅
시스템 유지 관리자가 제공하는 선택적 및 선택된 상태 점검 세트입니다.
Greenboot
는 시스템에서 실행되는 상태 점검 스크립트를 사용하여 시스템 상태를 평가하고 일부 소프트웨어가 실패하는 경우 마지막 정상 상태로 롤백을 자동화하여 RHEL for Edge 시스템에서 작동합니다. 이러한 상태 점검 스크립트는 /etc/greenboot/check/required.d
디렉토리에서 사용할 수 있습니다. Greenboot
는 상태 점검을 위해 쉘 스크립트를 지원합니다. 상태 점검 프레임워크가 있으면 소프트웨어 문제를 확인하고 직접 서비스 가능성이 제한되거나 존재하지 않는 에지 장치에서 시스템 롤백을 수행해야 하는 경우 특히 유용합니다. 상태 점검 스크립트를 설치하고 구성할 때 시스템이 시작될 때마다 상태 점검을 트리거합니다.
자체 상태 점검 스크립트를 생성하여 워크로드 및 애플리케이션의 상태를 평가할 수 있습니다. 이러한 추가 상태 점검 스크립트는 소프트웨어 문제 검사 및 자동 시스템 롤백의 유용한 구성 요소입니다.
OSTree를 사용하지 않는 시스템에서 상태 점검 실패의 경우 롤백을 사용할 수 없습니다.
15.5.2. RHEL for Edge 이미지가 greenboot로 롤백
에지 이미지용 RHEL을 사용하면 운영 체제에 트랜잭션 업데이트만 적용됩니다. 트랜잭션 업데이트는 atomic이므로 모든 업데이트가 성공적으로 수행되고 롤백이 지원되는 경우에만 업데이트가 적용됩니다. 트랜잭션 업데이트를 사용하면 실패한 업데이트를 마지막 알려진 양호한 상태로 쉽게 롤백하여 업데이트 중에 시스템 오류를 방지할 수 있습니다.
상태 점검을 수행하는 것은 소프트웨어 문제를 확인하고 직접 서비스 가능성이 제한되거나 존재하지 않는 에지 장치에서 시스템 롤백을 수행해야 하는 경우 특히 유용합니다.
상태 점검이 실행될 수 있더라도 OSTree를 사용하지 않는 시스템에서 롤백을 사용할 수 없습니다.
greenboot
상태 점검 프레임워크와 함께 지능형 롤백을 사용하여 시스템이 시작될 때마다 시스템 상태를 자동으로 평가할 수 있습니다. greenboot-default-health-checks
하위 패키지에서 사전 구성된 상태를 가져올 수 있습니다. 이러한 검사는 rpm-ostree
시스템의 /usr/lib/greenboot/check
읽기 전용 디렉터리에 있습니다.
Greenboot
는 rpm-ostree
를 활용하고 시스템 시작 시 실행되는 사용자 정의 상태 점검을 실행합니다. 문제가 발생하는 경우 시스템은 변경 사항을 롤백하고 마지막 작업 상태를 유지합니다. rpm-ostree
업데이트를 배포할 때 스크립트를 실행하여 업데이트 후에도 중요한 서비스가 계속 작동할 수 있는지 확인합니다. 시스템이 작동하지 않으면 업데이트가 시스템의 마지막 알려진 작업 버전으로 롤백됩니다. 이 프로세스를 통해 엣지 장치용 RHEL이 운영 상태에 있습니다.
greenboot-default-health-checks'subpackage에서 사전 구성된 상태를 가져올 수 있습니다. 이러한 검사는
읽기 전용 디렉터리에 있습니다. 쉘 스크립트를 다음 유형의 검사로 구성할 수도 있습니다.
rpm-ostree
시스템의 '/usr/lib/greenboot/check
예 15.1. greenboot 디렉터리 구조
etc
└─ greenboot
├─ check
| └─ required.d
| └─ init.py
└─ green.d
└─ red.d
- 필수 항목
-
실패하지 않아야 하는 상태 점검을 포함합니다. 필요한 쉘 스크립트를
/etc/greenboot/check/required.d
디렉토리에 배치합니다. 스크립트가 실패하면 greenboot에서 기본적으로 세 번 재시도합니다.GREENBOOT_MAX_BOOTS
매개변수를 원하는 재시도 횟수로 설정하여/etc/greenboot/greenboot.conf
파일에서 재시도 횟수를 구성할 수 있습니다.
모든 재시도에 실패한 후 greenboot
는 사용 가능한 경우 롤백을 자동으로 시작합니다. 롤백을 사용할 수 없는 경우 시스템 로그 출력에 수동 조작이 필요함이 표시됩니다.
- 원하는 경우
-
시스템이 롤백되지 않고 실패할 수 있는 상태 점검을 포함합니다.
/etc/greenboot/check/wanted.d
디렉토리에 쉘 스크립트를 배치합니다.Greenboot
는 스크립트가 실패하고 시스템 상태가 영향을 받지 않고 롤백을 수행하지 않음을 알려줍니다.
검사 후 실행할 쉘 스크립트를 지정할 수도 있습니다.
- 녹색
-
성공적으로 부팅된 후 실행할 스크립트가 포함되어 있습니다. 이 스크립트를
/etc/greenboot/green.d'directory
에 배치합니다.Greenboot
는 부팅이 성공했음을 알려줍니다. - 빨간색
-
부팅 실패 후 실행할 스크립트가 포함되어 있습니다. 이 스크립트를
/etc/greenboot/red.d
디렉토리에 배치합니다. 시스템은 세 번 부팅하려고 시도하며 오류가 발생하는 경우 스크립트를 실행합니다.Greenboot
는 부팅이 실패했음을 알려줍니다.
다음 다이어그램에서는 에지 이미지 롤백 프로세스를 위한 RHEL을 보여줍니다.
업데이트된 운영 체제를 부팅한 후 greenboot
는 required.d
및 wanted.d
디렉토리에서 스크립트를 실행합니다. required.d
디렉토리에서 스크립트가 실패하면 greenboot
는 빨간색.d
디렉터리에서 스크립트를 실행한 다음 시스템을 재부팅합니다.
Greenboot
를 사용하면 업그레이드된 시스템에서 2번 부팅을 더 시도합니다. 세 번째 부팅 중에 required.d 의 스크립트가 계속 실패하는 경우 greenboot
는 red.d 스크립트를 마지막으로 실행하여 문제를 해결하기 위한 수정 작업을 수행하려고 시도했으며 성공하지 못했습니다. 그런 다음 greenboot
는 현재 rpm-ostree
배포에서 이전 안정적인 배포로 시스템을 롤백합니다.
15.5.3. Greenboot 상태 점검 상태
업데이트된 시스템을 배포할 때 greenboot가 시스템을 이전 상태로 롤백하면 변경 사항이 손실되지 않도록 greenboot 상태 점검이 완료될 때까지 기다립니다. 구성을 변경하거나 애플리케이션을 배포하려면 greenboot 상태 점검이 완료될 때까지 기다려야 합니다. 이렇게 하면 greenboot가 rpm-ostree
시스템을 이전 상태로 롤백하면 변경 사항이 손실되지 않습니다.
greenboot-healthcheck
서비스는 한 번 실행한 다음 종료됩니다. 서비스 상태를 확인하여 다음 명령을 사용하여 서비스 상태를 확인하고 결과를 확인할 수 있습니다.
systemctl is-active greenboot-healthcheck.service
-
이 명령은 서비스가 종료되면
활성
상태를 보고합니다. 서비스가 실행되지 않은 경우비활성
상태로 표시됩니다. systemctl show --property=SubState --value greenboot-healthcheck.service
-
완료되면 보고서
가 종료되고 계속
되었습니다.실행되는
동안 보고서가 종료 systemctl show --property=Result --value greenboot-healthcheck.service
-
검사가 통과되었을 때
성공을
보고합니다. systemctl show --property=ExecMainStatus --value greenboot-healthcheck.service
- 0은 서비스의 숫자 종료 코드를 보고하며 0이 아닌 값은 실패가 발생했음을 의미합니다.
cat /run/motd.d/boot-status
- 에는 "Boot Status is GREEN - Health Check SUCCESS"와 같은 메시지가 표시됩니다.
15.5.4. greenboot 상태 점검 상태 확인
시스템을 변경하기 전 또는 문제 해결 중에 greenboot 상태 점검 상태를 확인합니다. 다음 명령을 사용하여 greenboot 스크립트 실행이 완료되었는지 확인할 수 있습니다.
다음 옵션 중 하나를 사용하여 상태를 확인합니다.
상태 점검 상태 보고서를 보려면 다음을 입력합니다.
$ systemctl show --property=SubState --value greenboot-healthcheck.service
다음 출력이 가능합니다.
-
start
는 greenboot 검사가 여전히 실행 중임을 의미합니다. -
exited
는 검사가 통과되었으며 greenboot가 종료되었음을 의미합니다. Greenboot는 시스템이 정상 상태인 경우green.d
디렉토리에서 스크립트를 실행합니다. -
실패
란 검사가 통과되지 않았음을 의미합니다. Greenboot는 시스템이 이 상태에 있을 때빨간색.d
디렉토리로 스크립트를 실행하고 시스템을 다시 시작할 수 있습니다.
-
서비스의 숫자 종료 코드를 표시하는 보고서를 보려면 0은 성공과
0
이 아닌 값이 실패했음을 의미합니다. 다음 명령을 사용합니다.$ systemctl show --property=ExecMainStatus --value greenboot-healthcheck.service
부팅 상태에 대한 메시지(예:
Boot Status is GREEN - Health Check SUCCESS
)를 표시하는 보고서를 보려면 다음을 입력합니다.$ cat /run/motd.d/boot-status
15.5.5. RHEL for Edge 이미지 수동 롤백
운영 체제를 업그레이드하면 새 배포가 생성되고 rpm-ostree
패키지도 이전 배포를 유지합니다. 업데이트된 버전의 운영 체제에 문제가 있는 경우 단일 rpm-ostree
명령을 사용하여 이전 배포로 또는 GRUB 부트 로더에서 이전 배포를 선택하여 수동으로 롤백할 수 있습니다.
이전 버전으로 수동으로 롤백하려면 다음 단계를 수행합니다.
사전 요구 사항
- 시스템을 업데이트하고 실패했습니다.
절차
선택 사항: 실패 오류 메시지가 있는지 확인합니다.
$ journalctl -u greenboot-healthcheck.service.
rollback
명령을 실행합니다.# rpm-ostree rollback
명령 출력은 이동 중인 커밋 ID에 대한 세부 정보를 제공하고 제거 중인 패키지의 세부 정보와 함께 완료된 트랜잭션을 나타냅니다.
시스템을 재부팅합니다.
# systemctl reboot
명령은 안정적인 콘텐츠를 사용하여 이전 커밋을 활성화합니다. 변경 사항이 적용되고 이전 버전이 복원됩니다.
15.5.6. 자동화된 프로세스를 사용하여 에지 이미지에 대해 RHEL 롤백
Greenboot
검사에서는 부팅 프로세스에 통합된 프레임워크를 제공하고 상태 점검에 실패할 때 rpm-ostree
롤백을 트리거할 수 있습니다. 상태 점검의 경우 상태 점검이 통과했는지 실패했는지 여부를 나타내는 사용자 정의 스크립트를 생성할 수 있습니다. 결과에 따라 롤백을 트리거해야 할 시기를 결정할 수 있습니다. 다음 절차에서는 상태 점검 스크립트 예제를 생성하는 방법을 보여줍니다.
절차
표준 종료 코드
0
을 반환하는 스크립트를 생성합니다.예를 들어 다음 스크립트는 구성된 DNS 서버를 사용할 수 있는지 확인합니다.
#!/bin/bash DNS_SERVER=$(grep ^nameserver /etc/resolv.conf | head -n 1 | cut -f2 -d" ") COUNT=0 # check DNS server is available ping -c1 $DNS_SERVER while [ $? != '0' ] && [ $COUNT -lt 10 ]; do ((COUNT++)) echo "Checking for DNS: Attempt $COUNT ." sleep 10 ping -c 1 $DNS_SERVER done
/etc/greenboot/check/required.d/
에서 상태 점검을 위해 실행 가능한 파일을 포함합니다.chmod +x check-dns.sh
다음 재부팅 중에 스크립트는 시스템이
boot-complete.target
유닛에 입력하기 전에 부팅 프로세스의 일부로 실행됩니다. 상태 점검이 성공하면 작업이 수행되지 않습니다. 상태 점검이 실패하면 업데이트를 실패로 표시하고 이전 업데이트로 롤백하기 전에 시스템을 여러 번 재부팅합니다.
검증
기본 게이트웨이에 연결할 수 있는지 확인하려면 다음 상태 점검 스크립트를 실행합니다.
표준 종료 코드
0
을 반환하는 스크립트를 생성합니다.#!/bin/bash DEF_GW=$(ip r | awk '/^default/ {print $3}') SCRIPT=$(basename $0) count=10 connected=0 ping_timeout=5 interval=5 while [ $count -gt 0 -a $connected -eq 0 ]; do echo "$SCRIPT: Pinging default gateway $DEF_GW" ping -c 1 -q -W $ping_timeout $DEF_GW > /dev/null 2>&1 && connected=1 || sleep $interval ((--count)) done if [ $connected -eq 1 ]; then echo "$SCRIPT: Default gateway $DEF_GW is reachable." exit 0 else echo "$SCRIPT: Failed to ping default gateway $DEF_GW!" 1>&2 exit 1 fi
/etc/greenboot/check/required.d/
디렉터리에서 상태 점검을 위한 실행 가능한 파일을 포함합니다.chmod +x check-gw.sh
16장. OSTree 이미지 업데이트 생성 및 관리
RHEL for Edge 시스템에 대한 OStree 이미지 업데이트를 쉽게 생성 및 관리하고 RHEL for Edge 장치에서 즉시 사용할 수 있습니다. OSTree에서는 이미지 빌더를 사용하여 OSTree 커밋이 포함된 .tar
파일로 RHEL for Edge 커밋 또는 RHEL for Edge 컨테이너 이미지를 생성할 수 있습니다. OSTree 업데이트 버전 시스템은 OSTree 커밋을 저장하고 버전을 저장하는 "Git 리포지토리"로 작동합니다. rpm-ostree
이미지 및 패키지 시스템은 클라이언트 장치에서 커밋을 어셈블합니다. RHEL 이미지 빌더로 새 이미지를 생성하여 업데이트를 수행하면 RHEL 이미지 빌더에서 이러한 리포지토리에서 업데이트를 가져옵니다.
16.1. OSTree의 기본 개념
이미지를 업데이트하는 동안 OSTree 및 rpm-ostree
가 사용하는 기본 용어입니다.
rpm-ostree
-
OSTree 커밋을 장치에서 어셈블하는 방법을 처리하는 에지 장치의 기술입니다. 이미지와 패키지 시스템 간의 하이브리드로 작동합니다.
rpm-ostree
기술을 사용하면 시스템의 원자 업그레이드 및 롤백을 수행할 수 있습니다. - ostree
- ostree는 커밋을 생성하고 부팅 가능한 파일 시스템 트리를 다운로드할 수 있는 기술입니다. 또한 이를 사용하여 트리를 배포하고 부트로더 구성을 관리할 수 있습니다.
- 커밋
- OSTree 커밋에는 직접 부팅할 수 없는 전체 운영 체제가 포함되어 있습니다. 시스템을 부팅하려면 RHEL 설치 가능 이미지와 같이 시스템을 배포해야 합니다.
- reference
이는
ref
라고도 합니다. OSTree ref는 Git 분기와 유사하며 이름입니다. 다음 참조 이름 예제가 유효합니다.-
rhel/9/x86_64/edge
-
ref-name
-
app/org.gnome.Calculator/x86_64/stable
-
ref-name-2
-
기본적으로 이미지 빌더는 rhel/9/$ARCH/edge
를 경로로 지정합니다. "$ARCH" 값은 호스트 시스템에 의해 결정됩니다.
- 상위
-
상위
인수는 이미지 빌더를 사용하여 새 커밋을 빌드하도록 제공할 수 있는 OSTree 커밋입니다.상위
인수를 사용하여 빌드 중인 새 커밋에 대한 상위 커밋을 검색하는 기존ref
를 지정할 수 있습니다. 부모 커밋을 확인하고 가져올 ref 값으로 지정해야 합니다(예:rhel/9/x86_64/edge
). RHEL for Edge Commit (.tar
) 및 RHEL for Edge Container (.tar
) 이미지 유형에 대해--parent
커밋을 사용할 수 있습니다. - 원격
- OSTree 콘텐츠를 호스팅하는 http 또는 https 끝점입니다. 이는 yum 리포지토리의 baseurl과 유사합니다.
- 정적 delta
- 정적 delta는 두 개의 OSTree 커밋 간에 생성된 업데이트 컬렉션입니다. 이를 통해 시스템 클라이언트는 크기가 더 큰 더 적은 양의 파일을 가져올 수 있습니다. ostree 기반 호스트를 업데이트할 때 시스템 클라이언트는 시스템에 존재하지 않는 새 OSTree 커밋에서 오브젝트만 가져오기 때문에 정적 deltas 업데이트가 더 효율적입니다. 일반적으로 새 OSTree 커밋에는 여러 TCP 연결이 필요한 많은 작은 파일이 포함되어 있습니다.
- 요약
- 요약 파일은 OSTree 저장소에서 참조, 체크섬 및 사용 가능한 정적 delta를 열거하는 간결한 방법입니다. Ostree 리포지터리에서 사용 가능한 모든 refs 및 static deltas의 상태를 확인할 수 있습니다. 그러나 새 ref, 커밋 또는 static-delta가 OSTree 리포지터리에 추가될 때마다 요약 파일을 생성해야 합니다.
16.2. OSTree 리포지토리 생성
RHEL for Edge Commit (.tar)
또는 RHEL for Edge Container (.tar)
이미지 유형을 사용하여 RHEL 이미지 빌더로 OSTree 리포지토리를 생성할 수 있습니다. 이러한 이미지 유형에는 단일 OSTree 커밋이 포함된 OSTree 리포지터리가 포함되어 있습니다.
-
웹 서버에서
RHEL for Edge Commit(.tar)
을 추출하면 제공할 준비가 되었습니다. -
RHEL for Edge 컨테이너(.tar)
를 로컬 컨테이너 이미지 스토리지로 가져오거나 이미지를 컨테이너 레지스트리로 푸시해야 합니다. 컨테이너를 시작한 후 통합nginx
웹 서버에 대한 커밋을 제공합니다.
Podman이 있는 RHEL 서버에서 RHEL for Edge Container(.tar)
를 사용하여 OSTree 리포지터리를 생성합니다.
사전 요구 사항
-
RHEL for Edge Container (.tar)
이미지가 생성되어 있습니다.
절차
이미지 빌더에서 컨테이너 이미지를 다운로드합니다.
$ composer-cli compose image _<UUID>
컨테이너를 Podman으로 가져옵니다.
$ skopeo copy oci-archive:_<UUID>_-container.tar containers-storage:localhost/ostree
컨테이너를 시작하고 포트
8080
을 사용하여 사용할 수 있도록 합니다.$ podman run -rm -p 8080:8080 ostree
검증
컨테이너가 실행 중인지 확인합니다.
$ podman ps -a
16.3. 중앙 집중식 OSTree 미러 관리
프로덕션 환경의 경우 모든 커밋을 제공하는 중앙 OSTree 미러를 보유하면 다음과 같은 몇 가지 이점이 있습니다.
- 디스크 스토리지 중복 및 최소화
- 정적 delta 업데이트를 사용하여 클라이언트에 대한 업데이트 최적화
- 배포 기간 동안 단일 OSTree 미러를 가리킵니다.
중앙 집중식 OSTree 미러를 관리하려면 이미지 빌더의 각 커밋을 사용자가 사용할 수 있는 중앙 집중식 리포지토리로 가져와야 합니다.
infra.osbuild
Ansible 컬렉션을 사용하여 OSTree 미러 관리를 자동화할 수도 있습니다. osbuild.infra Ansible 을 참조하십시오.
중앙 집중식 리포지토리를 생성하려면 웹 서버에서 직접 다음 명령을 실행할 수 있습니다.
절차
빈 블루프린트를 생성하고 "rhel-92"를 distro로 사용하도록 사용자 정의합니다.
name = "minimal-rhel92" description = "minimal blueprint for ostree commit" version = "1.0.0" modules = [] groups = [] distro = "rhel-92"
블루프린트를 서버로 푸시합니다.
# composer-cli blueprints push minimal-rhel92.toml
생성한 블루프린트에서 RHEL for Edge Commit (
.tar
) 이미지를 빌드합니다.# composer-cli compose start-ostree minimal-rhel92 edge-commit
.tar le
을 검색하여 디스크에 압축을 풉니다.# composer-cli compose image _<rhel-92-uuid> $ tar -xf <rhel-92-uuid>.tar -C /usr/share/nginx/html/
디스크의
/usr/share/nginx/html/repo
위치는 모든 참조 및 커밋에 대한 단일 OSTree 리포지토리가 됩니다.다른 빈 블루프린트를 생성하고 "rhel-87"을 distro로 사용하도록 사용자 정의합니다.
name = "minimal-rhel87" description = "minimal blueprint for ostree commit" version = "1.0.0" modules = [] groups = [] distro = "rhel-87"
블루프린트를 푸시하고 Edge Commit (
.tar
) 이미지를 위해 다른 RHEL을 생성합니다.# composer-cli blueprints push minimal-rhel87.toml # composer-cli compose start-ostree minimal-rhel87 edge-commit
.tar le
을 검색하여 디스크에 압축을 풉니다.# composer-cli compose image <rhel-87-uuid> $ tar -xf <rhel-87-uuid>.tar
커밋을 로컬 리포지터리로 가져옵니다.
ostree pull-local
을 사용하면 커밋 데이터를 로컬 리포지토리의 다른 로컬 리포지터리로 복사할 수 있습니다.# ostree --repo=/usr/share/nginx/html/repo pull-local repo
선택 사항: OSTree 리포지토리의 상태를 검사합니다. 다음은 출력 예입니다.
$ ostree --repo=/usr/share/nginx/html/repo refs rhel/8/x86_64/edge rhel/9/x86_64/edge $ ostree --repo=/usr/share/nginx/html/repo show rhel/8/x86_64/edge commit f7d4d95465fbd875f6358141f39d0c573df6a321627bafde68c73850667e5443 ContentChecksum: 41bf2f8b442a770e9bf03e096a46a286f5836e0a0702b7c3516ef4e0acec2dea Date: 2023-09-15 16:17:04 +0000 Version: 8.7 (no subject) $ ostree --repo=/usr/share/nginx/html/repo show rhel/9/x86_64/edge commit 89290dbfd6f749700c77cbc434c121432defb0c1c367532368eee170d9e53ea9 ContentChecksum: 70235bfb9cae82c53f856183750e809becf0b9b076122b19c40fec92fc6d74c1 Date: 2023-09-15 15:30:24 +0000 Version: 9.2 (no subject)
새 패키지를 포함하도록 RHEL 9.2 블루프린트를 업데이트하고 새 커밋을 빌드합니다. 예를 들면 다음과 같습니다.
name = "minimal-rhel92" description = "minimal blueprint for ostree commit" version = "1.1.0" modules = [] groups = [] distro = "rhel-92" [[packages]] name = "strace" version = "*"
업데이트된 블루프린트를 푸시하고 기존 OSTree 리포지터리 작성을 가리키는 새로운 RHEL for Edge Commit(
.tar
) 이미지를 생성합니다.# composer-cli blueprints push minimal-rhel92.toml # composer-cli compose start-ostree minimal-rhel92 edge-commit --url http://localhost/repo --ref rhel/9/x86_64/edge
.tar
le을 검색하여 디스크에 압축을 풉니다.# rm -rf repo # composer-cli compose image <rhel-92-uuid> # tar -xf <rhel-92-uuid>.tar
리포지토리로 커밋을 가져옵니다.
# ostree --repo=/usr/share/nginx/html/repo pull-local repo
선택 사항: OSTree 리포지토리 상태를 다시 검사합니다.
$ ostree --repo=/usr/share/nginx/html/repo refs rhel/8/x86_64/edge rhel/9/x86_64/edge $ ostree --repo=/usr/share/nginx/html/repo show rhel/8/x86_64/edge commit f7d4d95465fbd875f6358141f39d0c573df6a321627bafde68c73850667e5443 ContentChecksum: 41bf2f8b442a770e9bf03e096a46a286f5836e0a0702b7c3516ef4e0acec2dea Date: 2023-09-15 16:17:04 +0000 Version: 8.7 (no subject) $ ostree --repo=/usr/share/nginx/html/repo show rhel/9/x86_64/edge commit a35c3b1a9e731622f32396bb1aa84c73b16bd9b9b423e09d72efaca11b0411c9 Parent: 89290dbfd6f749700c77cbc434c121432defb0c1c367532368eee170d9e53ea9 ContentChecksum: 2335930df6551bf7808e49f8b35c45e3aa2a11a6c84d988623fd3f36df42a1f1 Date: 2023-09-15 18:21:31 +0000 Version: 9.2 (no subject) $ ostree --repo=/usr/share/nginx/html/repo log rhel/9/x86_64/edge commit a35c3b1a9e731622f32396bb1aa84c73b16bd9b9b423e09d72efaca11b0411c9 Parent: 89290dbfd6f749700c77cbc434c121432defb0c1c367532368eee170d9e53ea9 ContentChecksum: 2335930df6551bf7808e49f8b35c45e3aa2a11a6c84d988623fd3f36df42a1f1 Date: 2023-09-15 18:21:31 +0000 Version: 9.2 (no subject) commit 89290dbfd6f749700c77cbc434c121432defb0c1c367532368eee170d9e53ea9 ContentChecksum: 70235bfb9cae82c53f856183750e809becf0b9b076122b19c40fec92fc6d74c1 Date: 2023-09-15 15:30:24 +0000 Version: 9.2 (no subject) $ rpm-ostree db diff --repo=/usr/share/nginx/html/repo 89290dbfd6f749700c77cbc434c121432defb0c1c367532368eee170d9e53ea9 a35c3b1a9e731622f32396bb1aa84c73b16bd9b9b423e09d72efaca11b0411c9 ostree diff commit from: 89290dbfd6f749700c77cbc434c121432defb0c1c367532368eee170d9e53ea9 ostree diff commit to: a35c3b1a9e731622f32396bb1aa84c73b16bd9b9b423e09d72efaca11b0411c9 Added: elfutils-default-yama-scope-0.188-3.el9.noarch elfutils-libs-0.188-3.el9.x86_64 strace-5.18-2.el9.x86_64
부록 A. 용어 및 명령
rpm ostree
용어 및 명령에 대해 자세히 알아보십시오.
A.1. ostree 및 rpm-ostree
용어
다음은 OSTree 및 rpm-ostree
이미지 컨텍스트에서 사용되는 몇 가지 유용한 용어입니다.
용어 | 정의 |
---|---|
| Linux 기반 운영 체제 버전을 관리하는 데 사용되는 툴입니다. OSTree 트리 보기는 Git과 유사하며 유사한 개념을 기반으로 합니다. |
| 운영 체제 업데이트를 호스팅하는 하이브리드 이미지 또는 시스템 패키지. |
| 운영 체제의 릴리스 또는 이미지 버전입니다. RHEL 이미지 빌더에서는 RHEL for Edge 이미지에 대한 OSTree 커밋을 생성합니다. 이러한 이미지를 사용하여 에지 서버에 RHEL을 설치하거나 업데이트할 수 있습니다. |
|
OSTree의 분기를 나타냅니다. 항상 최신 커밋을 확인합니다. 예: |
| 특정 커밋에 대한 SHA-256 |
| OSTree 콘텐츠를 호스팅하는 http 또는 https 끝점입니다. 이는 dnf 리포지토리의 baseurl과 유사합니다. |
| OSTree 이미지에 대한 업데이트는 항상 delta 업데이트입니다. 에지 이미지용 RHEL의 경우 파일 수로 인해 TCP 오버헤드가 예상보다 클 수 있습니다. TCP 오버헤드를 방지하기 위해 특정 커밋 간에 static-delta를 생성하고 단일 연결로 업데이트를 보낼 수 있습니다. 이러한 최적화는 제한된 연결로 대규모 배포를 지원합니다. |
A.2. ostree 명령
다음 표에서는 OSTree 이미지를 설치하거나 관리할 때 사용할 수 있는 몇 가지 OSTree 명령을 제공합니다.
ostree pull |
|
ostree 요약 |
|
view refs |
|
리포지토리에서 커밋 보기 |
|
커밋 검사 |
|
리포지토리의 원격 나열 |
|
REV 해결 |
|
static-delta 생성 |
|
GPG 키를 사용하여 |
|
A.3. rpm-ostree
명령
다음 표에서는 OSTree 이미지를 설치하거나 관리할 때 사용할 수 있는 몇 가지 rpm-ostree
명령을 제공합니다.
명령 | 설명 |
---|---|
| 이 명령을 실행하면 <REV> 커밋에 있는 패키지가 리포지토리에 나열됩니다. |
|
ostree는 |
|
이 명령은 사용 중인 현재 배포에 대한 정보를 제공합니다. 목록의 첫 번째 배포가 부팅 시 기본값으로 설정되도록 가능한 모든 배포의 이름과 |
| 이 명령을 사용하여 커밋 또는 커밋 내에 있는 패키지를 확인합니다. 하나 이상의 커밋을 지정해야 하지만 하나 이상의 커밋 범위도 작동합니다. |
| 이 명령을 사용하여 두 개의 rev(revisions)의 트리 간에 패키지가 어떻게 다른지 보여줍니다. revs가 제공되지 않으면 부팅된 커밋이 보류 중인 커밋과 비교됩니다. 단일 rev만 제공되는 경우 부팅된 커밋을 해당 재v와 비교합니다. |
| 이 명령은 현재 트리의 최신 버전을 다운로드하여 배포하고, 현재 트리를 다음 부팅의 기본값으로 설정합니다. 이는 실행 중인 파일 시스템 트리에는 영향을 미치지 않습니다. 변경 사항을 적용하려면 재부팅해야 합니다. |
추가 리소스
-
시스템의
rpm-ostree
도움말 페이지
A.4. FDO 자동 온보딩 용어
FDO 용어에 대해 자세히 알아보십시오.
명령 | 설명 |
---|---|
FDO | FIDO 장치 온보딩. |
장치 | 모든 하드웨어, 장치 또는 컴퓨터 |
소유자 | 장치의 최종 소유자 - 회사 또는 IT 부서. |
제조업체 | 장치 제조업체입니다. |
제조업체 서버 | 장치의 장치 자격 증명을 만듭니다. |
제조업체 클라이언트 | 제조 서버의 위치를 알려줍니다. |
ownership Boucher (OV) | 개별 장치의 소유권 레코드. 다음 정보를 포함합니다.
* 소유자 (
* rendezvous Server - FIDO 서버(
* 장치 (한 가지 조합) ( |
장치 인증 정보 (DC) | 주요 인증 정보 및 rendezvous는 제조 장치에 저장됩니다. |
키 | 제조 서버를 구성하는 키 * key_path * cert_path * key_type * mfg_string_type: 장치 일련 번호 * allowed_key_storage_types: 사용 중인 장치를 인증하는 데 사용되는 데이터를 보호하는 파일 시스템 및 신뢰할 수 있는 플랫폼 모듈(TPM)입니다. |
rendezvous 서버 | 장치 소유자가 누구인지 확인하기 위해 프로세스에서 사용하는 서버에 대한 링크 |
추가 리소스
A.5. FDO 자동 온보딩 기술
다음은 FDO 자동 온보딩에 사용되는 기술입니다.
기술 | 정의 |
---|---|
UEFI | 통합 확장 펌웨어 인터페이스. |
RHEL | Red Hat® Enterprise Linux® 운영 체제 |
| 배경 이미지 기반 업그레이드. |
Greenboot |
|
Osbuild | 운영 체제 아티팩트를 위한 파이프라인 기반 빌드 시스템입니다. |
컨테이너 | Linux® 컨테이너는 나머지 시스템과 격리된 1개 이상의 프로세스 집합입니다. |
Coreos-installer | RHEL 이미지 설치를 지원하고 UEFI로 시스템을 부팅합니다. |
FIDO FDO | 구성 및 온보딩 장치를 프로비저닝하기 위한 규격 프로토콜입니다. |