운영 체제 이미지 구축
OpenFactory는 정규화된 레시피를 이미지 아티팩트로 변환하고 요청 및 사용 가능한 경우 확인을 위해 해당 아티팩트를 부팅합니다. 정확한 빌더와 단계는 기본 이미지 제품군 및 배포에 따라 다릅니다.
레시피가 제어하는 것
| 면적 | 표준 위치 | 질문 검토 |
|---|---|---|
| 기본 및 하드웨어 의도 | base_image, hardware | 이것이 올바른 배포판, 릴리스, 아키텍처 및 최소 프로필입니까? |
| 기능 및 패키지 | os.features, os.packages | 요청된 기능이 이 기반에 존재하고 지원됩니까? |
| 서비스 및 계정 | os.services, os.users | 구성 및 최소 권한 액세스가 명시적입니까? |
| 데스크탑 및 브랜딩 | os.desktop_settings, os.branding | 선택한 데스크탑이 이러한 설정과 자산을 소유하고 있습니까? |
| 설치 프로그램 및 지속성 | os.installer, os.persistence | 디스크에 설치 및 지속성 요구 사항이 실제로 테스트됩니까? |
| 맞춤형 자동화 | os.startup_scripts, 첨부파일, 소스 패키지 | 입력이 고정되고 제한되어 있으며 선언된 사용자로 실행하기에 안전합니까? |
| 검증 | scenarios | 테스트는 부팅뿐만 아니라 모든 중요한 결과를 관찰합니까? |
전체 모양은 레시피 스키마을 참조하세요.
빌드 라이프사이클
공개 상태 스트림에는 계획, 구성, 소스 패키지 작업, 이미지 생성, 마무리 및 테스트가 포함될 수 있습니다. 모든 대상에 대해 동일한 이름의 단계로 나타나는 것은 보장되지 않습니다. 시작 요청에서 반환된 빌드 ID를 따르고 백엔드의 현재 상태를 신뢰할 수 있는 것으로 처리합니다.
다음 결과를 별도로 유지하세요.
validated은 인식된 레시피 형태가 승인되었음을 의미합니다.- 터미널 빌드 성공은 아티팩트가 마무리되었음을 의미합니다.
- 테스트 성공은 선택한 주장이 해당 환경에 대해 전달되었음을 의미합니다. 그리고
- 활성화된 경우 인증 또는 공개는 추후 정책 결정입니다.
조용한 진행은 중복 빌드를 만드는 이유가 아닙니다. 동일한 빌드 ID를 사용하여 빌드 콘솔 또는 상태 엔드포인트에 다시 연결합니다. 빌드가 최종적으로 실패한 경우 재시도하기 전에 단계, 오류, 로그를 보존하세요.
권장 워크플로
- 관찰 가능한 허용 기준을 작성합니다.
- 레시피를 생성하거나 편집합니다.
- 이를 검증하고 정규화된 결과를 전체 대화와 비교합니다.
- 추론된 기능, 외부 소스, 설치 프로그램 설정 및 시나리오를 검사합니다.
- 하나의 빌드를 시작하고 지속성 ID를 따릅니다.
- 아티팩트 다이제스트, 패키지 인벤토리, 경고 및 테스트 증거를 검토합니다.
- 요청에 적합한 일회용 환경에서 부팅하거나 설치합니다.
- 해당 승인 게이트를 통해서만 홍보하거나 게시하십시오.
주제 가이드
| 주제 | 다음 용도로 사용 |
|---|---|
| 기본 이미지 | 지원되는 빌드 제품군 선택 |
| 특징 | 등록된 기능 모듈 이해 |
| 서비스 | 서비스 구성 선언 |
| 맞춤형 소프트웨어 | 저장소 지원 패키지 입력 검토 |
| 사용자 | 이미지-로컬 계정을 안전하게 생성하기 |
| 데스크탑 | 데스크탑 설정 선택 및 확인 |
| 시작 스크립트 | 제한된 최초 부팅 단위 작성 |
가장 작은 유용한 이미지부터 시작하세요. 이전 아티팩트의 동작과 증거를 이해한 후에만 기능을 추가하세요.