7.8. Source-to-Image 프로세스 문제 해결
7.8.1. Source-to-Image 문제 해결을 위한 전략
Source-to-Image (S2I)를 사용하여 재현 가능한 Docker 형식의 컨테이너 이미지를 빌드합니다. 컨테이너 이미지에 애플리케이션 소스 코드를 삽입하고 새 이미지를 어셈블하여 바로 실행할 수있는 이미지를 만들 수 있습니다. 새 이미지는 기본 이미지 (빌더)와 빌드된 소스를 결합합니다.
S2I 프로세스에서 오류가 발생한 위치를 확인하기 위해 다음 S2I 단계 관련 Pod의 상태를 확인할 수 있습니다.
- 빌드 구성 단계에서 빌드 Pod는 기본 이미지 및 애플리케이션 소스 코드에서 애플리케이션 컨테이너 이미지를 만드는 데 사용됩니다.
- 배포 구성 단계에서 배포 Pod는 빌드 구성 단계에서 빌드된 애플리케이션 컨테이너 이미지에서 애플리케이션 Pod를 배포하는 데 사용됩니다. 배포 Pod는 서비스 및 경로와 같은 다른 리소스도 배포합니다. 배포 구성은 빌드 구성이 성공한 후에 시작됩니다.
-
배포 Pod에서 애플리케이션 Pod를 시작한 후 실행 중인 애플리케이션 Pod 내에서 애플리케이션 오류가 발생할 수 있습니다. 예를 들어 애플리케이션 Pod가
Running
상태인 경우에도 애플리케이션이 예상대로 작동하지 않을 수 있습니다. 이 시나리오에서는 실행 중인 애플리케이션 Pod에 액세스하여 Pod 내의 애플리케이션 오류를 조사할 수 있습니다.
S2I 문제를 해결할 때 다음 전략을 따르십시오.
- 빌드, 배포 및 애플리케이션 Pod 상태 모니터링
- 문제가 발생한 S2I 프로세스 단계 확인
- 실패한 단계에 해당하는 로그 확인
7.8.2. Source-to-Image 진단 데이터 수집
S2I 툴은 빌드 Pod와 배포 Pod를 순서대로 실행합니다. 배포 Pod는 빌드 단계에서 생성된 애플리케이션 컨테이너 이미지를 기반으로 애플리케이션 Pod를 배포합니다. 빌드, 배포 및 애플리케이션 Pod 상태를 모니터링하여 S2I 프로세스에서 오류가 발생하는 위치를 확인합니다. 다음은 이에 따라 진단 데이터를 수집합니다.
사전 요구 사항
-
cluster-admin
역할의 사용자로 클러스터에 액세스할 수 있어야 합니다. - API 서비스가 작동하고 있어야 합니다.
-
OpenShift CLI(
oc
)가 설치되어 있습니다.
프로세스
S2I 프로세스 전체에서 Pod의 상태를 확인하고 오류가 발생하는 단계를 확인합니다.
$ oc get pods -w 1
- 1
Ctrl+C
를 사용하여 명령을 종료할 때까지-w
를 사용하여 Pod의 변경 사항을 모니터링합니다.
실패한 Pod 로그에서 오류가 있는지 확인합니다.
빌드 Pod가 실패하면 빌드 Pod의 로그를 검토합니다.
$ oc logs -f pod/<application_name>-<build_number>-build
참고또는
oc logs -f bc/<application_name>
을 사용하여 빌드 구성의 로그를 확인할 수 있습니다. 빌드 구성의 로그에는 빌드 Pod의 로그가 포함됩니다.배포 Pod가 실패하면 배포 Pod의 로그를 검토합니다.
$ oc logs -f pod/<application_name>-<build_number>-deploy
참고또는
oc logs -f dc/<application_name>
을 사용하여 배포 구성의 로그를 확인할 수 있습니다. 이렇게 하면 배포 Pod가 성공적으로 완료될 때까지 배포 Pod의 로그가 출력됩니다. 이 명령을 배포 Pod가 완료된 후 실행하면 애플리케이션 Pod에서 로그를 출력합니다. 배포 Pod가 완료된 후에도oc logs -f pod/<application_name>-<build_number>-deploy
를 실행하여 로그에 계속 액세스할 수 있습니다.애플리케이션 Pod가 실패하거나 애플리케이션이 실행 중인 애플리케이션 Pod 내에서 예상대로 작동하지 않으면 애플리케이션 Pod의 로그를 확인합니다.
$ oc logs -f pod/<application_name>-<build_number>-<random_string>
7.8.3. 애플리케이션 오류 조사를 위한 애플리케이션 진단 데이터 수집
실행 중인 애플리케이션 Pod 내에서 애플리케이션 오류가 발생할 수 있습니다. 이러한 상태에서 다음 전략을 사용하여 진단 정보를 검색할 수 있습니다.
- 애플리케이션 Pod와 관련된 이벤트를 검토합니다.
- OpenShift Logging 프레임워크에서 수집하지 않는 애플리케이션별 로그 파일을 포함하여 애플리케이션 Pod의 로그를 검토합니다.
- 애플리케이션 기능을 대화 형으로 테스트하고 애플리케이션 컨테이너에서 진단 도구를 실행합니다.
사전 요구 사항
-
cluster-admin
역할의 사용자로 클러스터에 액세스할 수 있어야 합니다. -
OpenShift CLI(
oc
)가 설치되어 있습니다.
프로세스
특정 애플리케이션 Pod와 관련된 이벤트를 나열합니다. 다음 예에서는
my-app-1-akdlg
라는 애플리케이션 Pod의 이벤트를 검색합니다.$ oc describe pod/my-app-1-akdlg
애플리케이션 Pod에서 로그를 검토합니다.
$ oc logs -f pod/my-app-1-akdlg
실행 중인 애플리케이션 Pod 내에서 특정 로그를 쿼리합니다. stdout으로 전송되는 로그는 OpenShift Logging 프레임 워크에서 수집되며 위의 명령의 출력에 포함됩니다. 다음 쿼리는 stdout으로 전송되지 않은 로그에만 필요합니다.
Pod 내에서 루트 권한 없이 애플리케이션 로그에 액세스할 수 있는 경우 다음과 같이 로그 파일을 연결합니다.
$ oc exec my-app-1-akdlg -- cat /var/log/my-application.log
애플리케이션 로그를 보기 위해 root 액세스가 필요한 경우 root 권한으로 디버그 컨테이너를 시작한 다음 컨테이너 내에서 로그 파일을 볼 수 있습니다. 프로젝트의
DeploymentConfig
개체에서 디버그 컨테이너를 시작합니다. 일반적으로 Pod 사용자는 루트 이외의 권한으로 실행되지만 임시 루트 권한으로 문제 해결 Pod를 실행하면 문제 해결에 유용할 수 있습니다.$ oc debug dc/my-deployment-configuration --as-root -- cat /var/log/my-application.log
참고-- <command>
를 추가하지 않고oc debug dc/<deployment_configuration> --as-root
를 실행하면 디버그 Pod에서 루트 액세스 권한으로 대화형 쉘에 액세스할 수 있습니다.
대화형 쉘이 있는 애플리케이션 컨테이너에서 대화형으로 애플리케이션 기능을 테스트하고 진단 도구를 실행합니다.
애플리케이션 컨테이너에서 대화형 쉘을 시작합니다.
$ oc exec -it my-app-1-akdlg /bin/bash
- 쉘에서 대화형으로 애플리케이션 기능을 테스트합니다. 예를 들어 컨테이너의 엔트리 포인트 명령을 실행하고 결과를 확인할 수 있습니다. 그런 다음 S2I 프로세스를 통해 소스 코드를 업데이트하고 애플리케이션 컨테이너를 다시 빌드하기 전에 명령 줄에서 직접 변경 사항을 테스트합니다.
컨테이너에서 사용 가능한 진단 바이너리를 실행합니다.
참고일부 진단 바이너리를 실행하려면 root 권한이 필요합니다. 이러한 상황에서는
oc debug dc/<deployment_configuration> --as-root
를 실행하여 문제가 있는 Pod의DeploymentConfig
개체에 따라 루트 액세스 권한으로 디버그 Pod를 시작할 수 있습니다. 그런 다음 디버그 Pod 내에서 루트로 진단 바이너리를 실행할 수 있습니다.
컨테이너 내에서 진단 바이너리를 사용할 수 없는 경우
nsenter
를 사용하여 컨테이너의 네임 스페이스에서 호스트의 진단 바이너리를 실행할 수 있습니다. 다음 예제는 호스트의IP
바이너리를 사용하여 컨테이너의 네임 스페이스에서ip ad
를 실행합니다.대상 노드에서 디버그 세션으로 들어갑니다. 이 단계는
<node_name>-debug
라는 디버그 Pod를 인스턴스화합니다.$ oc debug node/my-cluster-node
디버그 쉘 내에서
/host
를 root 디렉터리로 설정합니다. 디버그 Pod는 Pod 내의/host
에 호스트의 루트 파일 시스템을 마운트합니다. root 디렉토리를/host
로 변경하면 호스트의 실행 경로에 포함된 바이너리를 실행할 수 있습니다.# chroot /host
참고RHCOS(Red Hat Enterprise Linux CoreOS)를 실행하는 OpenShift Container Platform 4.15 클러스터 노드는 변경할 수 없으며 Operator를 사용하여 클러스터 변경 사항을 적용합니다. SSH를 사용하여 클러스터 노드에 액세스하는 것은 권장되지 않습니다. 그러나 OpenShift Container Platform API를 사용할 수 없거나 kubelet이 대상 노드에서 제대로 작동하지 않는 경우
oc
작업이 영향을 받습니다. 이러한 상황에서 대신ssh core @ <node>.<cluster_name>.<base_domain>
을 사용하여 노드에 액세스할 수 있습니다.대상 컨테이너 ID를 확인합니다.
# crictl ps
컨테이너의 프로세스 ID를 확인합니다. 이 예에서 대상 컨테이너 ID는
a7fe32346b120
입니다.# crictl inspect a7fe32346b120 --output yaml | grep 'pid:' | awk '{print $2}'
호스트의
ip
바이너리를 사용하여 컨테이너의 네임 스페이스에서ip ad
를 실행합니다. 이 예에서는 컨테이너의 프로세스 ID로31150
을 사용합니다.nsenter
명령은 대상 프로세스의 네임 스페이스를 입력하고 네임 스페이스에서 명령을 실행합니다. 이 경우 대상 프로세스는 컨테이너의 프로세스 ID이므로ip ad
명령은 호스트의 컨테이너 네임 스페이스에서 실행됩니다.# nsenter -n -t 31150 -- ip ad
참고컨테이너의 네임 스페이스 에서 호스트의 진단 바이너리를 실행하는 것은 디버그 노드와 같은 권한 있는 컨테이너를 사용하는 경우에만 가능합니다.
7.8.4. 추가 리소스
- S2I 빌드 전략에 대한 자세한 내용은 S2I(Source-to-Image) 빌드를 참조하십시오.