Python을 Alpine 이미지로 안이하게 움직이는 문제점

요약

Alpine × Python의 문제점에 대해서는 종종 지적되고 있습니다 🤔

Using Alpine can make Python Docker builds 50× slower

경량 Docker 이미지에 안이하게 Alpine을 사용하는 것은 그만두는 것이 좋다는 이야기

대부분의 원인은 Alpine과 함께 제공되는 C 라이브러리 "musl (근육)"에서 파생됩니다.

빌드 시간이 지연되거나 수수께끼 버그를 밟습니다.

Alpine 이미지의 Python을 안락하게 도입 한 결과, 그 모든 문제를 살짝 슬퍼서 공유합니다 👶

사건①: 비정상적으로 빌드 시간이 걸린다 😨

일어난 일

Docker 이미지를 빌드하는 데 시간이 걸렸습니다.
빌드 로그를 보면 gRPC 관련 라이브러리 1 의 pip install에 30분 정도 시간이 걸리는 것을 확인할 수 있었습니다🤔

원인

앞서 언급한 이 기사에 대답이 있었습니다.
Using Alpine can make Python Docker builds 50× slower

Standard PyPI wheels don’t work on Alpine

간단히 정리하면,

PyPI는 C 확장 라이브러리 바이너리를 호스팅합니다.

다만 이 바이너리는 Alpine 비대응을 위해서 사용할 수 없다. C 코드를 Ichi에서 컴파일해야하는 개미

라는 것입니다.
통상의 라이브러리라면 Alpine에서도 문제 없습니다만, C확장 라이브러리의 경우는 매번 열심히 컴파일하게 되어, 결과적으로 귀신처럼 빌드 시간이 걸려 버린 것입니다.

여기 의 기사에도 같은 설명이 있었습니다.

PyPI는 리눅스를 위해 manylinux1 형식으로 바이너리를 제공하며, 데비안이나 RedHat에서 빠르게 설치할 수 있습니다. 그러나, 이 형식은 Alpine에는 대응하고 있지 않기 때문에, C 확장을 사용하는 라이브러리를 사용하면, Docker 이미지의 빌드 시간이 늘어나고 있는 것입니다.

그래도, 아무래도, PurePython에서 처리 속도는 아무래도 좋다/돈이 많이 있다, 혹은 C확장을 사용하는 경우라도 인생을 희생해도, 이미지 사이즈를 아무래도 줄이고 싶은 것 같은 선택자는 Alpine를 사용하는 느낌으로 아무쪼록.

사건②: Segmentation Fault가 일어난다 😨

일어난 일

Alpine 이미지의 Python을 Cloud Run에 배포하고 놀고 있었습니다만, pip install 되는 에러를 토해 Cloud Run군이 승천하는 것이 다발했습니다.Uncaught signal: 11 는 Segmentation Fault 을 나타냅니다.
여담이지만 어색했던 것은 로컬에서는 재현하지 않았던 것과 Cloud Run에서도 몇 번에 한 번 밖에 재현하지 않았다는 것입니다.

원인

musl의 스레드 스택 크기에 문제가있는 것 같습니다.


golang binary hacks

· musl은 스레드에 극단적으로 적은 스택을 할당합니다.
(중략)
· Ruby · Python을 포함한 다양한 프로젝트가 musl의 스택 오버플로에 신산을 핥아지고있다

스택 오버플로는 세그포의 원인이 될 수 있으므로 이쪽의 영향을 받았을 가능성이 높습니다.

결론

여분의 일이 없다면 Python이라면 Alpine 이외를 사용합시다.
(보충이지만 사용법에 따라 Alpine 이미지에서도 Python은 문제없이 움직입니다. 모든 것을 부정하는 것은 아닙니다 🙅‍♂️)



grpcio  ↩