# Arch Linux는 이제 bit-for-bit 재현 가능한 Docker 이미지를 제공함

> Clean Markdown view of GeekNews topic #28854. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=28854](https://news.hada.io/topic?id=28854)
- GeekNews Markdown: [https://news.hada.io/topic/28854.md](https://news.hada.io/topic/28854.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-04-25T02:33:17+09:00
- Updated: 2026-04-25T02:33:17+09:00
- Original source: [antiz.fr](https://antiz.fr/blog/archlinux-now-has-a-reproducible-docker-image/)
- Points: 1
- Comments: 1

## Topic Body

- **bit-for-bit 재현 가능성**을 갖춘 Arch Linux Docker 이미지가 제공되며, 몇 달 전 WSL 이미지에서 달성한 같은 이정표가 Docker까지 확장됨
- 이미지는 전용 **repro 태그**로 배포되고, 재현성을 보장하려고 pacman 키를 제거해 기본 상태에서는 pacman을 바로 사용할 수 없음
- 컨테이너 안에서 패키지를 설치하거나 업데이트하려면 **keyring 재생성**이 필요하며, `pacman-key --init && pacman-key --populate archlinux`로 초기화할 수 있음
- 재현성은 빌드 간 **digest 일치**와 `diffoci` 비교로 검증하고, rootFS 결정론적 빌드와 타임스탬프 정규화, `ldconfig` 보조 캐시 제거 같은 조정이 함께 적용됨
- 재현 절차는 `REPRO.md`에서 확인할 수 있고, 앞으로는 **rebuilder 서버**를 통한 자동 재빌드와 검증, 빌드 로그 및 결과 공개까지 이어질 수 있음

---

### 핵심 내용
- Arch Linux의 **Docker 이미지**가 이제 bit-for-bit **재현 가능**한 형태로 제공되며, 몇 달 전 WSL 이미지에서 달성한 같은 이정표를 Docker 쪽으로 확장함
- 이 이미지는 전용 [`repro` 태그](https://hub.docker.com/layers/archlinux/archlinux/repro)로 배포되며, 재현성을 보장하려면 **pacman 키**를 이미지에서 제거해야 해서 `pacman`을 바로 사용할 수 없음
  - 적절한 해결책이 마련될 때까지는 이 제약 때문에 별도 태그로 우선 제공됨
- 컨테이너 안에서 패키지 설치나 업데이트를 하려면 먼저 `pacman-key --init && pacman-key --populate archlinux`를 실행해 **keyring 재생성**이 필요함
  - 처음 실행 시 대화형으로 진행하거나, 이 이미지를 베이스로 쓰는 Dockerfile의 `RUN` 구문에서 실행할 수 있음
  - Distrobox에서는 `distrobox create -n arch-repro -i docker.io/archlinux/archlinux:repro --pre-init-hooks "pacman-key --init && pacman-key --populate archlinux"`처럼 pre-init hook으로 처리 가능함
- 이미지의 bit-for-bit 재현성은 빌드 간 **digest 일치**로 확인되며, `podman inspect --format '{{.Digest}}' <image>`와 [`diffoci`](https://github.com/reproducible-containers/diffoci) 비교로 검증함
- 이 Docker 이미지를 재현하는 방법은 [`REPRO.md`](https://gitlab.archlinux.org/archlinux/archlinux-docker/-/blob/master/REPRO.md)에서 확인할 수 있음

### 구현과 조정 사항
- Docker 이미지용 base **rootFS**를 결정론적으로 빌드하는 작업이 가장 큰 과제였고, rootFS 빌드 시스템을 공유하는 WSL 이미지와 **같은 과정**을 재사용함
  - 관련 WSL 커밋은 [여기](https://gitlab.archlinux.org/archlinux/archlinux-wsl/-/commit/7c0340e26358048f3f8ee03b3ab3aea666751712)에서 확인 가능함
- Docker 전용 조정 가운데 하나로 `SOURCE_DATE_EPOCH`를 설정하고, Dockerfile의 `org.opencontainers.image.created` LABEL도 이를 따르도록 맞춤
- 빌드된 이미지에서 **비결정성**을 유발하는 `ldconfig` 보조 캐시 파일 `var/cache/ldconfig/aux-cache`를 Dockerfile 단계에서 제거함
- `docker build` 또는 `podman build` 때 `--source-date-epoch=$SOURCE_DATE_EPOCH`와 `--rewrite-timestamp` 옵션을 사용해 **타임스탬프 정규화**를 적용함
  - 예시로 `etc/`, `etc/ld.so.cache`, `etc/os-release`, `sys/`, `var/cache/`, `var/cache/ldconfig/`, `proc/`, `dev/`의 시간이 서로 다르게 찍히던 문제가 제시됨
- 관련 변경 사항 전체는 [`archlinux-docker` 저장소의 merge request diff](https://gitlab.archlinux.org/archlinux/archlinux-docker/-/merge_requests/96/diffs)에서 더 자세히 확인 가능함
- 이후 단계로는 Docker 이미지와 [WSL 이미지](https://gitlab.archlinux.org/archlinux/archlinux-wsl/-/blob/main/REPRO.md), 그리고 앞으로의 재현 가능한 이미지들을 대상으로 **rebuilder**를 서버에 구축해 주기적 자동 재빌드, 재현성 검증, 빌드 로그와 결과 공개까지 고려하고 있음

## Comments



### Comment 56254

- Author: neo
- Created: 2026-04-25T02:33:19+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47871519) 
- 이런 **자신감**은 보기 좋음  
  거의 1년 동안 WSL 2에서 Arch Linux를 돌렸는데 아주 좋았고, 그다음엔 약 5개월간 네이티브 Arch를 썼는데 역시 만족스러웠음  
  지금도 네이티브 Arch를 계속 쓰고 있고, [dotfiles](https://github.com/nickjj/dotfiles)는 **Arch Docker image**로 깨끗한 파일시스템에서 테스트함  
  완전한 데스크톱 환경까지 세팅하는 종단 간 테스트가 필요할 때는 VM에서 Arch를 돌림  
  내게도 문제는 많지만 적어도 Arch 자체는 그중 하나가 아님
  - dotfiles 변경에도 **staged rollout**이나 롤백이 있나 궁금함  
    Prometheus 메트릭과 health probe까지 지원하는 엔터프라이즈급 dotfiles 세팅을 찾고 있었는데 딱 그런 느낌으로 들림
  - 다른 distro도 지원해줘서 고맙고, 공유해줘서도 고마움  
    지금껏 필요하다고 생각도 못 했는데 보자마자 필요해졌음
  - **NixOS**나 flakes도 써봤는지 궁금함  
    써봤다면 어떤 반응이었는지도 듣고 싶음

- 모든 Docker 컨테이너가 원래 **이런 식**이었어야 한다고 봄  
  docker build 단계에서 `apt-get update`를 돌리는 건 안티패턴에 가까움
  - 다만 [https://github.com/reproducible-containers/repro-sources-lis...](https://github.com/reproducible-containers/repro-sources-list.sh)를 쓰면 예외가 됨  
    직접 써봤는데 꽤 잘 동작했음
  - 어느 쪽이든 완전히 편하진 않음  
    업데이트를 안 하면 컨테이너에 알려진 **보안 이슈**가 쌓이고, 업데이트를 하면 **재현 가능성**이 깨짐  
    재현성은 분명 멋지고 보안상 이점도 있지만, 컨테이너가 한 달만 넘어가도 비목표처럼 느껴질 수 있고 최대 수명은 하루 단위가 더 적절할 수도 있음
  - 안티패턴인 건 알겠는데, 소프트웨어를 설치해야 할 때 대안이 뭔지 모르겠음  
    태그된 소스 코드를 받아서 gcc로 전부 직접 컴파일하라는 뜻인지 궁금함
  - 그걸 절대 규칙처럼 보는 데는 동의하지 않음  
    **재현 가능한 컨테이너**가 좋은 건 맞지만 항상 필요한 건 아니고, 컨테이너 안에서 `apt-get`을 돌리되 재현성은 신경 쓰지 않아도 되는 경우도 충분히 많음
  - distro들이 새 버전이 나오자마자 repo에서 **구버전**을 지워버리는 일이 많아서 더 어렵기도 함  
    물론 archive에서 가져오는 방법은 있긴 함

- **재현 가능한 이미지**는 평소엔 감정적 만족만 주는 기능처럼 느껴질 때가 많지만, 꼭 필요해지는 날이 옴  
  우리도 동일해야 할 두 이미지가 서로 다른 머신에서 타임스탬프 **3바이트 차이**를 냈고, 그 때문에 엉뚱한 방향에서 bisect하느라 오후를 통째로 날린 적이 있음  
  화려하진 않지만 분명히 값어치 있는 승리였음
  - 애초에 타임스탬프 차이가 어떻게 장애로 이어졌는지 궁금함

- 아마 **CI/CD 파이프라인**에 Arch를 쓴다는 사실을 모두에게 알려주는 뭔가를 꽂아 넣을 수 있을 것 같음  
  Crossfit 하는 사실도 함께 알려주겠지만 말임
  - 이런 koan이 떠오름  
    비건 크로스피터이면서 Arch 유저를 만나면, 그 사람이 제일 먼저 뭘 말해줄까
  - 왜 누군가가 **Slackware를 안 쓴다**는 사실을 자랑스럽게 여기는지 한 번도 이해한 적이 없음

- **Reproducible Builds**에 대한 정보는 여기서 볼 수 있음  
  [https://reproducible-builds.org/](https://reproducible-builds.org/)  
  밀접하게 관련된 **Bootstrappable Builds** 커뮤니티는 여기임  
  [https://bootstrappable.org/](https://bootstrappable.org/)

- 잘 설계된 **mutable 운영체제**인 Arch나 Alpine이 장기적으로는 NixOS 같은 시스템을 이길지도 궁금함  
  설치 스크립트는 선언형 설정 언어보다 표현력이 더 크고, 대체로 더 장황하지도 않기 때문임
  - 그렇다면 차라리 **Guix**를 쓰면 될 듯함  
    선언형 설정 언어도 있고, 동시에 튜링 완전하면서 쓰기 편한 프로그래밍 언어도 얻을 수 있음
  - **strictly more powerful**가 정확히 무슨 뜻인지 궁금함

- 글은 읽어봤고 꽤 멋져 보이는데, **Dockerfile**과 docker image를 섞어 말하는 느낌이 듦  
  Dockerfile 대신 nix 같은 걸로 이미지 tar 파일을 직접 빌드했으면 더 쉬웠을 것 같고, 물론 좀 매니악하긴 하겠지만 그래도 더 깔끔했을 듯함

- 사소한 지적이지만 **OCI Image**라는 용어를 쓰는 편이 더 맞다고 봄  
  podman에서도 아무 문제 없이 돌아감
  - 이 댓글 섹션에선 내가 좀 초보라 맥락을 다 따라가진 못하지만, 이 말은 꽤 **눈이 트이는 포인트**였음

- 이걸 실제로 가능하게 만든 사람들에게 정말 큰 존경을 보냄  
  이런 헤드라인 하나를 만들기 위해 들어가는 시간과 노력이 상상 이상임

- 완전히 별개 얘기지만 그 페이지에는 **애니메이션**이 하나 있어서, 1초 동안 페이지의 거의 모든 요소가 아래로 약 20픽셀씩 움직임  
  눈앞에서 레이아웃이 흔들리니 당연히 **CLS**를 박살낼 줄 알았는데 실제 CLS는 0이었음  
  그렇다면 CLS가 오해를 부르는 지표인 건지 궁금해짐
  - 그건 의도적인 애니메이션 때문에 일어나는 일임  
    CLS는 **초기 렌더링** 시점의 변화를 다루므로, 레이아웃 이동처럼 보여도 CLS로 잡히는 종류는 아님
  - 그건 레이아웃 시프트가 아님  
    **CSS transition**으로 인한 움직임이라 예상 가능한 변화이고, 그래서 layout shift로 계산되지 않음