From 520070cc6a4ce9443c127100d1eda7bbcedbe124 Mon Sep 17 00:00:00 2001 From: "Eunice(Eunyoung) Shin" Date: Sat, 4 Jul 2026 13:20:40 +0900 Subject: [PATCH] fix: kure_retriever Lambda Docker build fails on numpy wheel + hash-pinning The two most recent ai-ecr-push CI runs (PR #79, #80 merges) both failed in the "Build and push KURE retriever Lambda image" job, so the ECR repo never actually got an image pushed - the Lambda/Gateway have nothing to point at yet despite the Terraform being merged. Root cause 1: numpy>=1.26.0 resolves to the latest 2.x (2.4.6 at lock time), which only ships manylinux wheels requiring glibc>=2.28. public.ecr.aws/lambda/python:3.11 is Amazon Linux 2 (glibc 2.26), so pip falls back to building numpy from source - which fails because that base image has no C compiler. Fix: use python:3.12 (Amazon Linux 2023, glibc 2.34) instead, for both the builder and runtime stage. Root cause 2: switching the base image surfaces a second failure - `uv export | pip install -r ... --target` puts pip in --require-hashes mode, which then rejects installing torch's build-time `setuptools` dependency because uv export only hash-pins runtime deps, not PEP 517 build deps. Fix: use `uv pip install --target` instead of plain pip, which resolves this correctly. Verified with a real `docker build` of the full Dockerfile (not just the dependency-install step) on --platform linux/amd64 to match the GitHub Actions runner architecture: model bake + all stages complete, image builds successfully. --- lambda/kure_retriever/Dockerfile | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/lambda/kure_retriever/Dockerfile b/lambda/kure_retriever/Dockerfile index ad87725..b82d219 100644 --- a/lambda/kure_retriever/Dockerfile +++ b/lambda/kure_retriever/Dockerfile @@ -5,21 +5,30 @@ # # KURE-v1 모델은 빌드 타임에 이미지에 베이킹한다. Lambda가 private subnet에서 # 30초 timeout으로 동작하므로 콜드스타트마다 HuggingFace에서 내려받지 않는다. +# +# python:3.11(Amazon Linux 2, glibc 2.26) 대신 3.12(Amazon Linux 2023, glibc 2.34)를 +# 쓴다 - numpy 2.3+는 glibc 2.28 이상을 요구하는 manylinux wheel만 배포해서, +# AL2에서는 wheel을 못 찾고 소스 빌드로 빠지는데 이 이미지엔 컴파일러가 없어 실패한다. -FROM public.ecr.aws/lambda/python:3.11 AS builder +FROM public.ecr.aws/lambda/python:3.12 AS builder RUN pip install --no-cache-dir uv WORKDIR /build COPY pyproject.toml uv.lock ./ -RUN uv export --frozen --no-dev --extra cpu --format requirements-txt --output-file requirements.txt \ - && pip install --no-cache-dir -r requirements.txt --target /opt/python-deps +# uv export + 순정 pip install --target을 쓰면 pip이 --require-hashes 모드로 +# 들어가는데, torch가 빌드 시점에 끌어오는 setuptools가 requirements.txt에 +# 해시 고정돼 있지 않아 실패한다 (uv export는 런타임 의존성만 해시 고정하고 +# PEP 517 빌드 의존성까지는 고정하지 않는다). uv pip install은 이 경우를 +# 정상 처리한다. +RUN uv pip install --target /opt/python-deps \ + -r <(uv export --frozen --no-dev --extra cpu --format requirements-txt) ENV HF_HOME=/opt/hf_cache ENV PYTHONPATH=/opt/python-deps RUN python3 -c "from sentence_transformers import SentenceTransformer; SentenceTransformer('nlpai-lab/KURE-v1')" -FROM public.ecr.aws/lambda/python:3.11 +FROM public.ecr.aws/lambda/python:3.12 COPY --from=builder /opt/python-deps ${LAMBDA_TASK_ROOT} COPY --from=builder /opt/hf_cache /opt/hf_cache