Python(Cuda) 기반 컨테이너 실행 안될때

시작

Python(Cuda) 이미지를 가져와 Whisper STT 서버 컨테이너를 Dockerfile에서 작성 후 docker-compose 에서 entrypoint 를 `python3 app.py --server_name 0.0.0.0` 로 지정하고 `docker-compose up` 명령어를 사용했을 때 로그에서 `Attaching to [컨테이너명]` 에서 멈추는 현상을 발견하였고 삽질을 했다.

 

`Attaching to [컨테이너명]` 에서 멈췄다.

그래서 `docker exec -itu 0 ` 명령어로 해당 컨테이너에 들어가보면 정상적으로 진입은 하였지만 애플리케이션이 실행되진 않았다.(entrypoint 명령어가 실행되지 않았다.)

삽질 #1

entrypoint 말고 command 로 설정

결과

실패(동일증상)

삽질 #2

Dockerfile 에서 entrypoint 및 cmd 설정

결과

실패(동일증상)

삽질 #3

Python 의 venv 를 생성하여 진입

결과

venv에 진입은 하지만, 진입 후 동일증상으로 실패

삽질 #4

`docker run` 명령어로 개별 실행

결과

동일 증상으로 실패

삽질 #5

다시 원래대로 돌아와서 docker-compose.yml 파일에서 entrypoint를 기존의`python3 app.py --server_name 0.0.0.0` 에서 `python3 -u app.py --server_name 0.0.0.0`으로 변경

결과

성공

python 의 `-u` 옵션?

Python은 많은 양의 데이터를 읽고 인쇄하는 데 최적화되어 있습니다. 이러한 최적화 중 하나는 Python 인터프리터의 표준 입력 및 출력이 버퍼링 된다는 것입니다 . 이는 프로그램이 해당 스트림 중 하나를 사용하려고 할 때마다 해석이 사용을 큰 청크로 차단한 다음 해당 청크를 한 번에 전송한다는 것을 의미합니다. 이는 각 개별 읽기/쓰기를 개별적으로 보내는 것보다 빠르지만 데이터가 중간에 '중지'될 수 있다는 단점이 있습니다. -u 플래그는 이 동작을 끕니다.

Python: significance of -u option?

결론

Python(cuda) 기반 컨테이너를 실행할 때 위와 같은 오류가 발생할 경우 `-u` 옵션을 사용하면 해결할 수 있다.

`python3 app.py --server_name 0.0.0.0` 에서 문제가 있다고 생각하지 않았었기 때문에 `-u` 옵션을 찾는데 한참걸렸다.

구글링해도 잘 안나와 있어서 야근까지 했었으나.. `-u` 옵션 하나 때문에 야근했다 생각하면 어이가 없다.

이렇게 하나 더 알아가는거지 뭐..