로그로 원인 좁히기

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

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

예전에는 이 실습이 파드 안에서 돌았고, 커널 권한을 전부 내려놓은 상자라
컨테이너를 띄우는 단계가 전부 막혀 있었습니다. 이제 막힌 단계가 없습니다.

알아 둘 것이 둘 있습니다.

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

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

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

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

목표

살아 있는 컨테이너와 죽은 컨테이너를 각각 진단해, 로그·종료코드·상태
필드 세 가지로 원인을 좁히는 순서를 몸에 익힙니다.

왜 중요한가

컨테이너 진단이 어려운 이유는 정보가 없어서가 아니라 **어디를 볼지
순서가 없어서**입니다. 순서가 있으면 대부분 3분 안에 끝납니다. 로그를
먼저 보는 이유는 앱이 스스로 남긴 마지막 말이기 때문이고, 그다음
종료코드를 보는 이유는 로그가 비어 있을 때(=신호로 즉사했을 때) 그것만이
유일한 단서이기 때문입니다. 이 순서는 나중에 쿠버네티스에서도 그대로
씁니다. 도구 이름만 바뀔 뿐입니다.

단계

1. /root/dk3 을 만들고, dk-noisy 컨테이너가 line-1 부터 line-50 까지 출력한 뒤 마지막에 done-50 을 출력하고 끝나게 합니다.
2. dk-noisy 로그의 마지막 5줄만 /root/dk3/tail5.txt 로 저장합니다.
3. dk-err 컨테이너를 만들어 표준 출력에 to-stdout, 표준 오류에 to-stderr 를 내보내게 한 뒤, 표준 출력만 /root/dk3/out.txt 로, 표준 오류만 /root/dk3/err.txt 로 분리 저장합니다.
4. dk-noisy 로그에 타임스탬프를 붙여 첫 줄만 /root/dk3/ts.txt 로 저장합니다.
5. nginx:1.27-alpine 으로 dk-web2 를 띄우고, 그 안에서 nginx 버전을 확인해 /root/dk3/nginx-version.txt 로 저장합니다.
6. dk-crash 컨테이너를 만들어 starting 을 출력한 뒤 없는 경로를 읽어 실패하게 합니다. 그리고 /root/dk3/crash.txt 에 exit=<실제 종료코드> 한 줄을 적습니다.
7. dk-noisy 로그에서 line- 이 몇 번 나오는지 세어 /root/dk3/count.txt 에 숫자만 적습니다.
8. /root/dk3/triage.md 에 dk-noisy, dk-crash, dk-web2 세 컨테이너를 한 줄씩 적되, 각 줄에 컨테이너 이름과 현재 상태를 함께 넣고 dk-crash 줄에는 종료코드도 넣습니다.

참고

• docker logs --tail N, docker logs -t 를 씁니다.
• nginx 버전은 표준 오류로 나옵니다. 2>&1 로 받아야 파일에 담깁니다.
• 흔한 실수 1: 1단계에서 --rm 을 붙이면 로그를 볼 컨테이너가 남지 않습니다.
• 흔한 실수 2: 7단계에서 done-50 도 line- 을 포함하는지 확인하세요. 채점은 실제 로그를 다시 세어 대조합니다.

단계 8개

1. 로그를 뿜는 컨테이너 만들기
2. 마지막 몇 줄만 보기
3. 표준 출력과 표준 오류 분리하기
4. 언제 찍힌 로그인지 알아내기
5. 돌고 있는 컨테이너 안 확인하기
6. 실패한 컨테이너 진단하기
7. 로그에서 패턴 세기
8. 세 컨테이너 상태 정리