볼륨과 마운트

이 실습은 진짜 VM 에서 돕니다

이 상자는 파드가 아니라 KubeVirt 가 띄운 가상머신입니다. 리눅스 커널이
따로 돌고 systemd 가 실제로 서비스를 관리하며, docker 는 흉내가 아니라
진짜 도커 엔진입니다. docker run 으로 띄운 컨테이너는 실제로 프로세스가
되고 docker exec 도 docker logs 도 그대로 동작합니다.

예전에는 이 실습이 파드 안에서 돌았습니다. 커널 권한을 전부 내려놓은 상자라
컨테이너를 띄우는 단계가 막혀 있었고, 그래서 이미지 아카이브를 직접 풀어
보는 우회로 배웠습니다. 이제 우회가 필요 없습니다.

알아 둘 것이 둘 있습니다.

처음 뜨는 데 1분 남짓 걸립니다. VM 이 부팅하고 도커를 설치하기

때문입니다. 파드 실습(보통 40초)보다 느립니다.

브라우저 미리보기가 없습니다. VM 으로 들어오는 연결은 채점 포트

하나만 열려 있습니다. 웹 서버를 띄웠다면 VM 안에서 curl 로 확인하세요.

목표

볼륨·바인드·읽기 전용 마운트를 직접 만들어 보고, 컨테이너를 지워도 데이터가
남는다는 것과 백업·복원이 왕복 가능하다는 것을 확인합니다.

왜 중요한가

"컨테이너는 상태를 갖지 않는다"는 말은 컨테이너가 상태를 다루지 못한다는
뜻이 아니라, 상태를 컨테이너 밖에 두라는 뜻입니다. 이 구분을 못 하면
재배포마다 데이터가 사라지거나, 반대로 볼륨이 눈덩이처럼 쌓여도 아무도
지우지 못하는 상태가 됩니다. 또 하나. 읽기 전용 마운트는 성능이 아니라
의도의 선언입니다. 이 컨테이너가 무엇을 쓰면 안 되는지 매니페스트에
적어 두면, 나중에 그 규칙을 어기는 코드가 배포되는 순간 조용히 넘어가지
않고 오류로 드러납니다.

단계

1. /root/ops1 을 만들고, dk-data 라는 이름 있는 볼륨을 만듭니다.
2. dk-writer 라는 컨테이너로 dk-data 를 /data 에 마운트해 /data/hello.txt 에 volume-alive 를 씁니다.
3. dk-writer 컨테이너를 삭제한 뒤, 새 컨테이너로 같은 볼륨을 읽어 내용이 남아 있는지 확인하고 그 출력을 /root/ops1/persist.txt 로 저장합니다.
4. /root/ops1/site/index.html 을 만들어 labhub-site 를 넣고, nginx:1.27-alpine 을 dk-site 라는 이름으로 띄우되 /root/ops1/site 를 /usr/share/nginx/html 에 바인드 마운트합니다.
5. dk-ro 컨테이너를 띄워 dk-data 를 /data 에 읽기 전용으로 마운트하고, 그 안에서 파일 쓰기를 시도해 나오는 오류 메시지를 /root/ops1/ro-error.txt 로 저장합니다.
6. dk-site2 컨테이너를 --mount 문법으로 띄워, 4단계와 같은 원본·대상으로 붙이되 읽기 전용으로 만듭니다.
7. dk-data 볼륨의 내용을 /root/ops1/dk-data.tgz 로 백업합니다. 아카이브 안에 hello.txt 가 들어 있어야 합니다.
8. dk-data-restore 라는 새 볼륨을 만들어 백업을 복원합니다. 원본과 내용이 같아야 합니다.

참고

임시 작업용 컨테이너는 docker run --rm 으로 띄우면 뒤처리가 필요 없습니다.
백업은 docker run --rm -v dk-data:/source:ro -v /root/ops1:/backup alpine:3.20 tar czf /backup/dk-data.tgz -C /source . 형태입니다.
흔한 실수 1: 5단계에서 컨테이너가 즉시 끝나 버리면 채점 대상이 남지 않습니다. 백그라운드로 계속 떠 있게 하세요.
흔한 실수 2: 7단계에서 -C 없이 절대 경로째로 담으면 복원 시 경로가 어긋납니다.

단계 8개

이름 있는 볼륨 만들기
볼륨에 파일 쓰기
컨테이너를 지워도 남는가
호스트 디렉터리를 그대로 붙이기
읽기 전용으로 붙이기
--mount 문법으로 다시 쓰기
볼륨 백업하기
새 볼륨으로 복원하기