donghyeon.kang/llm-wiki
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
Files
7bcb54c4647589f64c703fd0de34b9c9ea759661
llm-wiki/raw/official-docs/container-alpine-java-musl-tradeoffs.md
T

8.3 KiB
Raw Blame History

title, source_type, url, archive_url, status, confidence, tags, related_projects, related_branches, created, last_reviewed
title source_type url archive_url status confidence tags related_projects related_branches created last_reviewed
Eclipse Temurin on Alpine (musl libc) — Trade-offs and Docker Hub Notes official-doc https://hub.docker.com/_/eclipse-temurin raw high
ca-skeleton
container
runtime
alpine
musl
temurin
base-image
official-doc
branch:feature-container-runtime-contract
ca-skeleton-operational-contract
feature-container-runtime-contract
2026-05-22 2026-05-27

Eclipse Temurin on Alpine (musl libc) — Trade-offs and Docker Hub Notes

Layer: raw/official-docs/ — Eclipse Temurin 공식 Docker Hub 페이지 + Adoptium musl support 페이지의 원문 발췌.

Parent / 활용 branch (필수)

Branch 이 자료가 정당화하는 결정
raw/branch-notes/feature-container-runtime-contract Group G-D container runtime 대안 2 (Alpine + Temurin musl) 의 baseline 사실 — image size 이점과 musl 호환성 risk 의 공식 출처

특정 branch 없이 foundational 조사로 수집한 경우:

컨텍스트 / 왜 저장했는지

ca-tmpl feature-container-runtime-contract 에서 Alpine + Java (musl libc) 는 대안 후보. ca-tmpl 결정은 Temurin JRE slim (glibc 기반 Debian slim) 이며, Alpine 변형은 image 크기는 더 작지만 musl libc 로 인한 호환성 risk 가 따른다.

출처 / Source

핵심 인용 / Key quotes (verbatim)

[§Image Variants — alpine] "it does use musl libc instead of glibc and friends"

[§Image Variants — alpine] "This variant is useful when final image size being as small as possible is your primary concern."

[§Image Variants — alpine] "Alpine Linux is much smaller than most distribution base images (~5MB), and thus leads to much slimmer images in general."

[§Image Variants — alpine — caveats] "software will often run into issues depending on the depth of their libc requirements/assumptions"

[§Image Variants — alpine — caveats] "it's uncommon for additional related tools (such as git or bash) to be included in Alpine-based images"

Claims Extracted / 추출된 주장

Claim ID Claim (이 자료가 직접 말하는 것) Evidence quote Strength Applies to Does not prove
CAJM-C1 Eclipse Temurin alpine variant 는 glibc 가 아닌 musl libc 를 사용한다 [§Image Variants — alpine] "it does use musl libc instead of glibc and friends" official-vendor-doc eclipse-temurin:*-alpine 태그 Temurin 의 musl 빌드가 모든 JDK 버전에서 동일 quality assurance 를 받는다는 뜻은 아님 — Adoptium 별도 페이지가 JDK 21+ 부터 first-party musl 빌드 제공 명시
CAJM-C2 Alpine variant 의 채택 명분은 "final image size 가 최우선일 때" 이다 (공식 docker hub 의 권고 조건) [§Image Variants — alpine] "This variant is useful when final image size being as small as possible is your primary concern." official-vendor-doc image size 최소화 워크로드 (edge / IoT / FaaS) Alpine 이 모든 production 환경에서 권장된다는 뜻은 아님 — 명시적으로 size-primary 조건부
CAJM-C3 Alpine Linux base image 는 약 5MB 로 대부분 distribution base image 보다 작아 최종 이미지가 전반적으로 더 작아진다 [§Image Variants — alpine] "Alpine Linux is much smaller than most distribution base images (~5MB), and thus leads to much slimmer images in general." official-vendor-doc Alpine base 기반 이미지 빌드 일반 "전반적 더 작음" 이 JRE 포함 시 정확히 얼마인지의 수치는 인용에 없음 — 최종 이미지 크기는 JRE size 가 지배적
CAJM-C4 Alpine 기반 이미지에서 software 는 libc 요구/가정의 depth 에 따라 종종 문제를 일으킨다 (musl 의 부분 호환성 한계) — 공식 경고 [§Image Variants — alpine — caveats] "software will often run into issues depending on the depth of their libc requirements/assumptions" official-vendor-doc native library 의존성이 있는 application 어떤 라이브러리가 문제인지의 구체 목록은 인용 범위 밖 — JNI / native compression / DB driver 등은 별도 검증 필요
CAJM-C5 Alpine 기반 이미지에는 git / bash 같은 부가 도구가 포함되지 않는 것이 일반적이다 [§Image Variants — alpine — caveats] "it's uncommon for additional related tools (such as git or bash) to be included in Alpine-based images" official-vendor-doc Alpine base 디버깅/CI 사용 시 apk 로 설치 가능 여부는 별개 사실 — 인용은 "기본 포함되지 않음" 만 주장

Usage Boundaries / 적용 경계

  • 이 자료가 직접 증명하는 것:
    • CAJM-C1: Alpine variant 가 musl libc 를 사용한다는 정의
    • CAJM-C2: docker hub 공식 권고가 "size-primary 조건" 이라는 사실
    • CAJM-C3: Alpine base 의 ~5MB 크기 baseline
    • CAJM-C4: musl 호환성 risk 의 공식 경고
    • CAJM-C5: 기본 패키지에 git/bash 미포함
  • 이 자료가 증명하지 않는 것:
    • 어떤 구체 Java 라이브러리가 musl 에서 실패하는지의 카탈로그 (JNI 사용 라이브러리 별 호환성)
    • DNS resolver 차이 (musl 의 simpler resolver vs glibc) — 본 docker hub 페이지에는 명시 없음, ca-tmpl 의 본 메모의 DNS 관련 서술은 외부 출처 (musl FAQ / k8s 문서) 가 필요
    • JVM thread stack 기본값의 musl vs glibc 차이 (별도 OpenJDK 이슈 트래커 확인 필요)
    • Adoptium 의 musl JDK first-party 빌드 시작 버전 (JDK 21 LTS 명시는 adoptium.net 페이지에서 확인 필요)
  • 내 프로젝트에 적용하려면 추가 확인이 필요한 것:
    • ca-tmpl 에서 사용하는 native library (예: snappy, zstd-jni, BouncyCastle native, PostgreSQL JDBC native) 의 musl 호환성 매트릭스
    • Testcontainers 가 alpine + musl 환경에서 정상 동작하는지 (Docker-in-Docker 시나리오)
    • K8s 환경에서 search domain / ndots 옵션 해석 차이로 인한 service discovery 영향 검증

메모 / Notes (내 프로젝트 해석)

본 섹션은 자료 직접 인용 아님. ca-tmpl 결정 컨텍스트 해석.

  • 적용 시나리오: edge / IoT, 이미지 크기가 critical 한 환경.
  • 장점:
    • base 이미지 크기 ~5 MiB (Alpine) + JRE → 최종 이미지 ~150 MB 이하 가능.
    • apk 패키지 매니저로 추가 도구 설치 간단.
  • 단점:
    • musl libc 가 일부 native 라이브러리 (예: 일부 DB driver, native compression lib, OpenSSL 의존 라이브러리) 와 충돌 — CAJM-C4 의 공식 경고 일반화.
    • DNS resolver 동작이 glibc 와 미세하게 달라 search domain, ndots 옵션 해석 차이로 K8s 환경에서 디버깅 비용 발생 — 본 docker hub 인용 범위 밖, 별도 musl FAQ 출처 필요.
    • thread stack 기본값 차이로 일부 JVM 워크로드에서 StackOverflowError 가 다르게 발현 — 별도 출처 필요.
  • ca-tmpl 과의 차이: ca-tmpl 은 Temurin JRE slim (glibc/Debian slim) 을 default 로 둠. Alpine + Temurin 은 별도 검증 후 허용.
  • testability 영향: 중 — Testcontainers 등 native 의존 도구가 musl 에서 동작 검증 필요.
  • 보안 영향: 중상 — Alpine 의 보안 정책은 좋지만 musl 관련 미해결 issue 가 종종 보고됨.

Related / 관련

Reference in New Issue View Git Blame Copy Permalink