Argo CD는 초록불인데 주문 화면은 500

목표

Git 동기화와 업무 성공을 구분하고, 설정 소비 시점까지 확인하며 Git으로 복구합니다.

왜 중요한가

원하는 설정이 배포됐어도 그 설정 자체가 잘못되거나 실행 중 프로세스가 읽지 않았을 수 있습니다.
실제 Argo CD·k3s·nginx를 쓰며, readiness는 200이고 업무 경로는 500인 합성 장애를 조사합니다.
외부 결제·사용자 데이터·운영 LabHub를 호출하거나 수정하지 않습니다.
개인 VM의 cgoa-business-health Namespace만 사용합니다. 전역 컨트롤러·보안·네트워크 설정을 바꾸지 마세요.
55분 실습입니다. 만료 전에 필요하면 시간을 연장하고 필요한 파일을 따로 보관하세요. 세션 종료 시 VM과 파일은 회수됩니다.

준비된 환경과 도우미

Git 작업 저장소는 /srv/cgoa-business-health, bare 저장소는 /srv/bare/cgoa-business-health.git입니다.
Argo CD는 VM 내부 gitd 서비스에서 main의 app 디렉터리를 읽습니다. 외부 Gitea나 운영 Git을 쓰지 않습니다.
실습 서버는 non-root, capability drop ALL, 읽기 전용 루트, RuntimeDefault, 서비스 계정 토큰 미마운트로 실행합니다.
nginx 이미지는 VM 준비 중 가져오며 첫 학습 단계에서 다운로드를 기다리지 않습니다.
학생 파일은 /root/cgoa-health에 둡니다. 과제의 key=value 표기는 설명이며 파일은 형식 예시처럼 JSON으로 작성하세요.
python3 /opt/fixtures/cgoa_health_lab.py observe는 현재 Git·API·마운트 파일·응답을 읽습니다.
complete N은 작성한 N단계 답안을 검증하고 실제 관측을 저장합니다. 4·6단계에서만 한정된 Git 변경을 수행합니다.
git show --stat 및 git show로 변경 내용을 직접 확인하세요. 직접 저장소를 수정했다면 도우미는 덮어쓰지 않고 멈춥니다.
solve N은 정답 보기와 동일하며 없는 현재 답안을 채웁니다. 기존 오답이나 부분 답안은 수정하지 않습니다.
prepare N은 없는 이전 단계만 준비합니다. 현재 N단계 답안은 만들지 않습니다. grade N은 파일·Git·쿠버네티스를 읽기만 합니다.

단계

1. 개인 VM의 /srv/cgoa-business-health에서 git rev-parse HEAD를 확인하세요. revision.json의 revision에 실제 SHA 문자열을 적고 complete 1을 실행하세요. observation-1.json의 로컬 Git·원격 main·Argo CD revision이 일치하고 리소스 신원이 보존됩니다.
2. observe로 /healthz와 업무 /의 응답을 읽으세요. http.json에 숫자 readiness=200, business=500을 적고 complete 2를 실행하세요. observation-2.json에 실제 HTTP 코드·본문 표본 세 쌍이 남습니다. Healthy를 업무 성공이라고 해석하지 마세요.
3. git show HEAD:app/resources.json의 nginx.conf와 실제 응답을 대조하세요. diagnosis.json에 cause=application-config, probe_scope=process, fix_source=git 문자열을 적고 complete 3을 실행하세요. 외부 API나 DNS를 실제 원인처럼 적지 않습니다.
4. config.json에 숫자 status=200과 문자열 body=checkout ready를 작성하고 complete 4를 실행하세요. 도우미가 ConfigMap만 수정한 Git 커밋을 만들어 main에 push합니다. observation-4.json에서 새 revision·새 ConfigMap이 반영됐지만 이전 Pod와 500 응답이 유지되는지 조사하세요. git show로 Deployment가 바뀌지 않았는지도 확인합니다.
5. observation-4.json의 configmap.data.nginx.conf와 mounted_config, 이전 Pod UID를 비교하세요. consumption.json에 mode=subPath 문자열, pod_replaced=false, restart_required=true 불리언을 적고 complete 5를 실행하세요. 이 실습의 새 Pod 교체 방식에서 필요한 동작을 답합니다. 단순 대기로 subPath 갱신을 기대하지 마세요.
6. observation-4.json의 configmap.data.nginx.conf 바이트를 UTF-8로 인코딩하여 SHA-256을 계산하세요. rollout.json의 checksum에 계산한 64자리 문자열을 적고 complete 6을 실행하세요. 두 번째 Git 커밋은 spec.template.metadata.annotations의 checksum/config만 바꿉니다. 새 Pod와 마운트 파일, 업무 200 응답을 observation-6.json에 보존합니다.
7. observation-6.json에서 git_revision과 pod.metadata.uid를 조사하세요. verification.json에 revision과 pod_uid를 해당 문자열로, business=200을 숫자로, deployment_replaced=false를 불리언으로 적고 complete 7을 실행하세요. 실제 응답 세 쌍을 다시 관측하고 Application·Deployment UID는 유지됐는지 확인합니다.
8. 앞 관측과 Git 계보를 근거로 decision.json에 recovered=true, availability_guaranteed=false 불리언과 config_strategy=versioned-rollout, next_check=external-path 문자열을 적으세요. complete 8로 최종 관측을 보존합니다. 내부 표본의 성공과 외부 DNS·TLS·인증 및 장기 가용성 보장을 구별하세요.

참고

Pod 이름뿐 아니라 UID, ConfigMap 데이터와 마운트된 파일, HTTP 코드와 본문을 함께 보세요.
Git 설정 커밋과 템플릿 커밋의 부모 관계는 관측의 git_parents에 남습니다. 성공한 관측은 편집하지 마세요.
checksum/config는 템플릿 변경을 위한 규약이지 자동으로 설정을 감시하는 쿠버네티스 내장 기능이 아닙니다.
3회의 내부 HTTP 응답은 학습용 표본입니다. 외부 사용자 경로와 장기간 가용성을 검증한 것은 아닙니다.
부분 입력은 보존합니다. 오답이 있으면 과제와 대조하여 본인이 수정한 뒤 complete를 다시 실행하세요.
Git 조작 도중 끊겨 pending 기록이 남으면 자동으로 과거 성공을 만들지 않습니다. 자료를 보관하고 새 실습에서 시작하세요.
해시는 실수로 기록을 덮어쓰는 것을 탐지하지만 같은 VM root의 전체 위조를 막는 보안 보증은 아닙니다.
채점 60초·이전 단계 준비 90초 예산을 지킵니다. 실제 수렴 대기는 채점이 아니라 complete에서 진행합니다.
[공식 ConfigMap](https://kubernetes.io/docs/concepts/configuration/configmap/) ·
[Argo CD health](https://argo-cd.readthedocs.io/en/stable/operator-manual/health/).

단계 8개

1. Git과 실제 동기화 커밋을 연결하기
2. 초록불과 업무 500을 동시에 관측하기
3. 원인과 수정할 원본을 구별하기
4. 설정만 Git으로 수정하기
5. subPath가 남긴 옛 파일을 증명하기
6. 설정 해시로 Pod 템플릿 갱신하기
7. 새 프로세스의 응답으로 복구 검증하기
8. 확인한 범위와 남은 검증 보고하기