소개
유용한 릴리스는 실제로 검사를 통과한 버전이어야 합니다. 패키지에 다른 이미지가 들어 있거나 스테이징이 이전 버전을 실행한다면 "통과"라고 적힌 보고서로는 충분하지 않습니다.
이 누적 DeskLite 기준 환경에는 앞선 소스, 자격 증명, 의존성, 컨테이너, 로그, 관문 제어가 이미 적용되어 있습니다. 현재 소스 커밋, 실제 검사된 이미지, 생성된 보고서, 패키지 바이트, 실행 중인 로컬 스테이징을 연결합니다. 새로 배우는 작업은 제공된 릴리스 작업 흐름, tar 패키징, 체크섬 검증뿐입니다.
정상 동작하는 누적 기준 환경 검토하기
이 단계에서는 릴리스할 소스 버전과 정상 동작하는 기준 환경을 파악합니다.
cd /home/labex/project/ticket-release
git status
작업 트리는 깨끗해야 합니다. git rev-parse HEAD는 현재 커밋의 전체 식별자를 출력합니다. HEAD는 현재 체크아웃된 버전을 가리킵니다.
git rev-parse HEAD
식별자는 세션마다 다릅니다. 나중에 릴리스 매니페스트 및 실행 중인 애플리케이션 버전과 일치해야 합니다.
cat Dockerfile
업무 파일의 명시적 복사, 오프라인 의존성 설치, USER nobody를 찾으세요. 캐시된 Python 기본 이미지와 wheel이 준비되어 있습니다. 이미지 구성 중 패키지를 빌드하는 것은 최종 애플리케이션이 실행될 때의 비 root 계정과는 별개입니다.
.venv/bin/python -m pip show requests
2.32.4가 예상됩니다. 같은 고정 요구 사항이 후보 이미지에 설치됩니다.
bash /srv/ticket-release-client/sender.sh
HTTP 200과 원래 티켓이 예상됩니다. 이 전용 클라이언트는 이미 보호된 대체 토큰 파일을 읽으며 이전 토큰은 폐기되어 있습니다. 어느 값도 릴리스 메타데이터에 복사하지 마세요.
실제 관문과 부정 대조군 실행하기
이 단계에서는 패키징 전에 후보 버전과 관문이 모두 동작함을 확인합니다.
bash gate.sh
준비된 단계 래퍼는 실제 비밀 정보/이력, 의존성, 소스 검사를 실행하고 커밋된 애플리케이션을 Docker 이미지로 빌드한 다음 해당 실제 후보 버전을 시작합니다. 기능 테스트는 소스 버전, Requests 2.32.4, 실제 비 root UID 65534, 원래 티켓, 이전 토큰/토큰 누락/잘못된 토큰의 거부를 확인합니다.
관문은 아직 최종 패키지를 게시하지 않습니다. 검사와 테스트가 같은 소스 및 이미지에 일치한 뒤에만 승인된 후보 버전을 기록합니다.
이제 신뢰할 수 있는 부정 대조군을 실행하세요.
course-release gate-test
이 도우미는 같은 관문에 실제 고정 규칙 자격 증명 탐지 결과를 적용하고, 이어서 실제 입력 누락 검사기 오류를 적용합니다. 둘 다 빌드/테스트 전에 각각 상태 1과 2로 차단되어야 합니다. 이후 정상 제어 모드로 복원하며 실행 중인 스테이징은 변경하지 않습니다.
검사는 여전히 교육 과정의 고정 연습용 토큰/SQL 규칙과 선택된 의존성 보안 권고 두 개를 다룹니다. 완전한 운영 환경 검토는 아닙니다.
검사된 이미지에 연결된 메타데이터 생성하기
이 단계에서는 통과 주장을 입력하는 대신 실제 승인된 결과에서 릴리스 증거를 생성합니다.
course-release manifest
도우미는 실제 검사된 Docker 이미지를 내보내고 release 아래에 image.tar, checks.json, manifest.json 파일 세 개를 만듭니다. 이는 엔지니어링 전달 입력이며 별도의 학습자 조사 보고서가 아닙니다.
cat release/manifest.json
source_commit은 git rev-parse HEAD와 같아야 합니다. image_id는 옮길 수 있는 태그가 아니라 정확히 빌드된 이미지를 식별합니다. checks_sha256은 민감한 값이 가려진 실제 검사 보고서를 연결하고, image_sha256은 내보낸 이미지 바이트를 연결합니다. run_id는 기록을 실제 승인된 이 검사 실행과 연결합니다.
cat release/checks.json
상태 0, 개별 검사 상태, 도구 버전, 같은 소스 커밋이 예상됩니다. 자격 증명 값이 들어가면 안 됩니다. 매니페스트는 자동으로 생성됩니다. 다른 산출물이 통과했다고 주장하려고 필드를 편집하지 마세요.
릴리스 바이트 패키징하고 검사하기
이 단계에서는 실제 아카이브와 체크섬을 만듭니다.
tar는 파일을 아카이브로 묶습니다. -c는 아카이브를 만들고, -f는 출력 파일 이름을 지정하며, -C release는 내용을 읽을 디렉터리를 선택합니다. 마지막 .은 해당 디렉터리의 모든 내용을 의미합니다.
tar -cf release.tar -C release .
아카이브는 입력 디렉터리 밖에 있으므로 자신을 포함하지 않습니다. -t는 기존 아카이브의 내용을 나열하며 -f는 그 이름을 지정합니다.
tar -tf release.tar
생성된 파일 세 개와 디렉터리 항목이 예상됩니다. 파일 앞에 ./가 붙을 수도 있습니다.
SHA-256은 파일 바이트에서 다이제스트를 계산합니다. sha256sum은 다이제스트와 파일 이름을 출력합니다. 익숙한 > 리다이렉션은 결과를 저장합니다.
sha256sum release.tar > release.tar.sha256
-c는 저장된 체크섬 기록을 읽고 실제 파일과 비교합니다.
sha256sum -c release.tar.sha256
release.tar: OK가 예상됩니다. 이는 바이트가 기록된 다이제스트와 일치함을 입증합니다. 체크섬 자체로는 누가 파일을 게시했는지 또는 검사가 유효했는지 입증하지 못합니다.
보고서와 산출물의 연결 검증하기
이 단계에서는 패키지가 스스로 제시한 체크섬 이상의 내용을 확인합니다.
course-release verify release.tar
릴리스 도우미는 실제 아카이브를 읽고, 예상하지 못했거나 중복된 항목을 거부하며, 매니페스트를 실제 검사된 내보내기 결과와 비교하고, 원래 보고서를 확인하며, 포함된 이미지 바이트를 해싱합니다. 현재 소스 커밋도 일치해야 합니다.
소스, 보고서, 이미지, 전체 패키지 다이제스트를 연결하는 PASS가 예상됩니다. 이는 교육 과정의 로컬 릴리스 작업 흐름에 정확히 이 패키지 바이트에 대한 승인을 등록합니다. checks.json을 통과라고 편집하거나 변경된 이미지의 체크섬을 다시 계산해도 일치하는 승인된 검사 실행이 만들어지지는 않습니다.
이것은 보호된 로컬 기록을 사용하는 교육용 작업 흐름입니다. 학습자에게 sudo 접근 권한이 있으므로 이 VM은 운영 환경의 신뢰 경계가 아닙니다. 제공된 릴리스 절차를 테스트하는 것이며 게시자 서명이나 외부 권한 기관을 구현한다고 주장하지 않습니다.
정확히 그 패키지 배포하고 실행 상태 확인하기
이 단계에서는 승인된 바이트를 배포하고 실제 동작을 생성된 기록과 비교합니다.
course-release deploy release.tar
도우미는 패키지를 다시 검증하고 포함된 이미지를 불러온 다음 정확히 해당 이미지 ID로 로컬 스테이징을 시작합니다. 로컬 서비스 포트와 필요한 읽기 전용 발급자 등록 정보만 노출하며, 비공개 자격 증명은 이미지에 내장되지 않습니다.
course-release state
상태에는 같은 소스/이미지 식별자와 전체 패키지 다이제스트가 포함됩니다. 이제 애플리케이션 자체를 확인하세요.
curl http://127.0.0.1:8080/health
같은 source_commit, Requests 2.32.4, UID 65534가 예상됩니다.
bash /srv/ticket-release-client/sender.sh
HTTP 200과 원래 티켓이 예상됩니다. 인증 없는 접근을 확인하세요.
curl -i http://127.0.0.1:8080/tickets
401이 예상됩니다. 후보 버전 관문은 이전 토큰과 잘못된 토큰도 테스트했습니다. 매니페스트가 일치한다는 사실만으로는 이러한 실제 실행 동작을 입증할 수 없었습니다.
바이트가 바뀐 패키지 거부하기
이 단계에서는 실행 중인 서비스를 변경하지 않고 무결성 강제를 테스트합니다.
cp는 파일을 복사합니다. 유효한 패키지의 바이트 단위로 동일한 백업을 유지하세요.
cp release.tar release-original.tar
printf는 알려진 이 표시 문자열을 출력합니다. >>는 파일에 덧붙이고 >는 덮어씁니다. 이 연습의 패키지에만 몇 바이트를 덧붙이세요.
printf 'changed' >> release.tar
sha256sum -c release.tar.sha256
release.tar: FAILED와 0이 아닌 종료 코드가 예상됩니다. tar 읽기 도구가 뒤에 붙은 데이터를 무시하더라도 전체 패키지 바이트는 바뀌었습니다.
course-release deploy release.tar
정확히 이 바이트는 승인되지 않았으므로 RELEASE BLOCKED가 예상됩니다. 0이 아닌 이 결과는 의도된 것입니다. 사용자가 새로 작성한 체크섬으로는 작업 흐름의 소스/보고서/이미지 연결이나 원래 패키지에 대한 승인을 대체할 수 없습니다.
curl http://127.0.0.1:8080/health
이전에 승인된 버전은 계속 실행됩니다. 다음 단계에서는 최종 검증 전에 유효한 패키지를 복원합니다.
복원하고 최종 전달 확인하기
이 단계에서는 원래 검증된 패키지와 정상 동작하는 스테이징을 그대로 유지한 상태로 마무리합니다.
cp release-original.tar release.tar
sha256sum -c release.tar.sha256
다시 release.tar: OK가 예상됩니다.
course-release verify release.tar
course-release state
복원된 패키지는 실제 검사된 소스/이미지와 이미 실행 중인 스테이징에 일치합니다. 교육 과정의 검증은 관문의 실패 대조군을 독립적으로 테스트하고, 바뀐 바이트를 거부하며, 실제 이미지 계층에서 대상 자격 증명을 확인하고, 실제 정상/거부 동작을 검증합니다.
릴리스 아카이브, 체크섬, 생성된 매니페스트와 실제 보고서, 일치하는 실행 버전을 갖추었습니다. 수동으로 작성한 조사는 필요하지 않습니다. 운영 환경 전달에는 게시자 신원, 외부 인가, 더 넓은 보안 범위 등의 제어도 필요합니다. 이 교육 과정은 로컬 체크섬으로 그러한 속성까지 입증했다고 주장하지 않습니다.
요약
실제 검사된 소스 커밋, 테스트된 비 root 이미지, 원래 생성된 보고서, 릴리스 패키지 바이트, 실제 실행 중인 로컬 스테이징 버전을 연결했습니다. 정상 및 거부 동작은 올바르게 유지되었으며 수정된 바이트는 거부되었습니다. 체크섬은 무결성을 뒷받침합니다. 이 로컬 작업 흐름이 게시자 서명이나 외부 운영 환경 인가를 제공한다고 주장하는 것은 아닙니다.
