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

• 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 태그로 배포되며, 재현성을 보장하려면 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 비교로 검증함
• 이 Docker 이미지를 재현하는 방법은 REPRO.md에서 확인할 수 있음

구현과 조정 사항

• Docker 이미지용 base rootFS를 결정론적으로 빌드하는 작업이 가장 큰 과제였고, rootFS 빌드 시스템을 공유하는 WSL 이미지와 같은 과정을 재사용함
  • 관련 WSL 커밋은 여기에서 확인 가능함
• 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에서 더 자세히 확인 가능함
• 이후 단계로는 Docker 이미지와 WSL 이미지, 그리고 앞으로의 재현 가능한 이미지들을 대상으로 rebuilder를 서버에 구축해 주기적 자동 재빌드, 재현성 검증, 빌드 로그와 결과 공개까지 고려하고 있음

[GN⁺]

Hacker News 의견들

• 이런 자신감은 보기 좋음
  거의 1년 동안 WSL 2에서 Arch Linux를 돌렸는데 아주 좋았고, 그다음엔 약 5개월간 네이티브 Arch를 썼는데 역시 만족스러웠음
  지금도 네이티브 Arch를 계속 쓰고 있고, 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...를 쓰면 예외가 됨
    직접 써봤는데 꽤 잘 동작했음
  • 어느 쪽이든 완전히 편하진 않음
    업데이트를 안 하면 컨테이너에 알려진 보안 이슈가 쌓이고, 업데이트를 하면 재현 가능성이 깨짐
    재현성은 분명 멋지고 보안상 이점도 있지만, 컨테이너가 한 달만 넘어가도 비목표처럼 느껴질 수 있고 최대 수명은 하루 단위가 더 적절할 수도 있음
  • 안티패턴인 건 알겠는데, 소프트웨어를 설치해야 할 때 대안이 뭔지 모르겠음
    태그된 소스 코드를 받아서 gcc로 전부 직접 컴파일하라는 뜻인지 궁금함
  • 그걸 절대 규칙처럼 보는 데는 동의하지 않음
    재현 가능한 컨테이너가 좋은 건 맞지만 항상 필요한 건 아니고, 컨테이너 안에서 apt-get을 돌리되 재현성은 신경 쓰지 않아도 되는 경우도 충분히 많음
  • distro들이 새 버전이 나오자마자 repo에서 구버전을 지워버리는 일이 많아서 더 어렵기도 함
    물론 archive에서 가져오는 방법은 있긴 함

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

  • 애초에 타임스탬프 차이가 어떻게 장애로 이어졌는지 궁금함

• 아마 CI/CD 파이프라인에 Arch를 쓴다는 사실을 모두에게 알려주는 뭔가를 꽂아 넣을 수 있을 것 같음
  Crossfit 하는 사실도 함께 알려주겠지만 말임

  • 이런 koan이 떠오름
    비건 크로스피터이면서 Arch 유저를 만나면, 그 사람이 제일 먼저 뭘 말해줄까
  • 왜 누군가가 Slackware를 안 쓴다는 사실을 자랑스럽게 여기는지 한 번도 이해한 적이 없음

• Reproducible Builds에 대한 정보는 여기서 볼 수 있음
  https://reproducible-builds.org/
  밀접하게 관련된 Bootstrappable Builds 커뮤니티는 여기임
  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로 계산되지 않음