Arch Linux artık bit-for-bit yeniden üretilebilir Docker imajları sunuyor

• bit-for-bit yeniden üretilebilirlik, aynı kaynaktan derleme yapıldığında ne zaman, nerede ve kim tarafından derlenirse derlensin bayt düzeyine kadar tamamen aynı çıktının elde edilmesi anlamına gelir
  • Buna ulaşmak için, derleme ortamına göre küçük farklılıklar gösteren zaman damgaları, önbellekler ve metadata gibi tüm deterministik olmayan unsurların kaldırılması gerekir
• Docker imajını doğrudan derleyip resmi dağıtım imajıyla digest'in (hash) aynı olup olmadığını karşılaştırarak, yayımlanan imajın değiştirilmediği herkes tarafından bağımsız biçimde doğrulanabilir: bu, tedarik zinciri güvenliği açısından önemlidir
• Arch Linux'un Docker imajları artık bit-for-bit yeniden üretilebilir biçimde sunuluyor ve birkaç ay önce WSL imajında ulaşılan aynı kilometre taşı Docker tarafına da genişletiliyor
• Bu imaj, özel repro etiketi ile dağıtılıyor; yeniden üretilebilirliği garanti etmek için pacman anahtarlarının imajdan kaldırılması gerektiğinden pacman doğrudan kullanılamıyor
  • Uygun bir çözüm bulunana kadar bu kısıt nedeniyle şimdilik ayrı bir etiketle sunuluyor
• Konteyner içinde paket kurmak veya güncellemek için önce pacman-key --init && pacman-key --populate archlinux komutunu çalıştırarak keyring'i yeniden oluşturmak gerekiyor
  • İlk çalıştırmada etkileşimli olarak ilerleyebilir veya bu imajı temel alan bir Dockerfile içindeki RUN ifadesinde çalıştırabilirsiniz
  • Distrobox'ta bu işlem, distrobox create -n arch-repro -i docker.io/archlinux/archlinux:repro --pre-init-hooks "pacman-key --init && pacman-key --populate archlinux" örneğinde olduğu gibi bir pre-init hook ile yapılabilir
• İmajın bit-for-bit yeniden üretilebilirliği, derlemeler arasında digest eşleşmesi ile doğrulanıyor; bunun için podman inspect --format '{{.Digest}}' <image> ve diffoci karşılaştırması kullanılıyor
• Bu Docker imajının nasıl yeniden üretileceği REPRO.md içinde görülebilir

Uygulama ve yapılan ayarlamalar

• Docker imajı için temel rootFS'yi deterministik biçimde derlemek en büyük zorluktu; rootFS derleme sistemini paylaşan WSL imajıyla aynı süreç yeniden kullanıldı
  • İlgili WSL commit'ine buradan bakılabilir
• Docker'a özel ayarlamalardan biri olarak SOURCE_DATE_EPOCH tanımlandı ve Dockerfile içindeki org.opencontainers.image.created LABEL'ı da buna uyacak şekilde düzenlendi
• Derlenen imajda deterministik olmamaya yol açan ldconfig yardımcı önbellek dosyası var/cache/ldconfig/aux-cache, Dockerfile aşamasında kaldırıldı
• docker build veya podman build sırasında --source-date-epoch=$SOURCE_DATE_EPOCH ve --rewrite-timestamp seçenekleri kullanılarak zaman damgası normalizasyonu uygulandı
  • Örnek olarak etc/, etc/ld.so.cache, etc/os-release, sys/, var/cache/, var/cache/ldconfig/, proc/, dev/ zamanlarının birbirinden farklı yazılması sorunu gösteriliyor
• İlgili değişikliklerin tamamı, archlinux-docker deposundaki merge request diff içinde daha ayrıntılı görülebilir
• Sonraki adım olarak Docker imajı, WSL imajı ve gelecekteki yeniden üretilebilir imajlar için sunucuda bir rebuilder kurularak düzenli otomatik yeniden derleme, yeniden üretilebilirlik doğrulaması ve derleme günlükleri ile sonuçların yayımlanması planlanıyor

[GN⁺]

Hacker News yorumları

• Bu tür bir özgüven görmek güzel
  Yaklaşık 1 yıldır WSL 2 üzerinde Arch Linux kullandım ve çok iyiydi, ardından yaklaşık 5 ay yerel Arch kullandım ve ondan da memnun kaldım
  Hâlâ yerel Arch kullanıyorum ve dotfiles yapılandırmamı temiz bir dosya sistemi üzerinde Arch Docker image ile test ediyorum
  Tam bir masaüstü ortamını kuran uçtan uca testlere ihtiyaç duyduğumda VM üzerinde Arch çalıştırıyorum
  Hayatımda bolca sorun var ama en azından Arch bunlardan biri değil

  • dotfiles değişikliklerinde staged rollout ya da rollback de var mı merak ettim
    Prometheus metrikleri ve health probe desteği olan kurumsal seviye bir dotfiles kurulumu arıyordum, tam öyle bir hava veriyor
  • Başka distro'ları da desteklediğin için teşekkürler, paylaştığın için de ayrıca teşekkürler
    Şimdiye kadar buna ihtiyacım olduğunu hiç düşünmemiştim ama görür görmez lazım oldu
  • NixOS ya da flakes de denedin mi merak ettim
    Denediysen onlara dair görüşlerini de duymak isterim

• Bence tüm Docker konteynerleri baştan beri böyle olmalıydı
  docker build aşamasında apt-get update çalıştırmak neredeyse bir antipattern

  • Yalnız https://github.com/reproducible-containers/repro-sources-lis... kullanırsan istisna olabilir
    Ben kullandım ve oldukça iyi çalıştı
  • Hangisini seçersen seç tam anlamıyla rahat değil
    Güncelleme yapmazsan konteynerde bilinen güvenlik sorunları birikiyor, güncelleme yaparsan da yeniden üretilebilirlik bozuluyor
    Yeniden üretilebilirlik kesinlikle havalı ve güvenlik açısından da avantajları var ama konteyner bir ayı geçince artık hedef dışı gibi hissettirebiliyor; belki de uygun azami ömür gün bazında, hatta bir gün seviyesinde olmalı
  • Bunun antipattern olduğunu anlıyorum ama yazılım kurmak gerektiğinde alternatifin ne olduğunu bilmiyorum
    Etiketlenmiş kaynak kodu indirip her şeyi gcc ile elle derlememiz mi kastediliyor diye merak ediyorum
  • Buna mutlak bir kural gibi bakılmasına katılmıyorum
    Yeniden üretilebilir konteynerler güzel ama her zaman gerekli değil; konteyner içinde apt-get çalıştırıp yeniden üretilebilirliği umursamamanın da gayet makul olduğu pek çok durum var
  • Distro'ların yeni sürüm çıkar çıkmaz repo'dan eski sürümleri silmesi de işi zorlaştırıyor
    Tabii archive'dan çekmenin yolları var

• Yeniden üretilebilir image'lar çoğu zaman günlük hayatta sadece duygusal tatmin sağlayan bir özellik gibi görünüyor ama bir gün gerçekten lazım oluyor
  Bizde de aynı olması gereken iki image, farklı makinelerde zaman damgasında 3 baytlık bir fark üretmişti; bu yüzden tamamen yanlış yönde bisect yaparak bir öğleden sonrayı çöpe attık
  Gösterişli değildi ama kesinlikle değerli bir kazanımdı

  • Zaman damgası farkının nasıl olup da en başta bir arızaya yol açtığını merak ettim

• Sanırım CI/CD pipeline'ında Arch kullandığını herkese duyuracak bir şey ekleyebilirsin
  Crossfit yaptığını da söylemiş olursun tabii

  • Bu bana şöyle bir koan'ı hatırlattı
    Vegan bir crossfitter ve Arch kullanıcısıyla karşılaşırsan, sana ilk önce hangisini söyler
  • Birinin Slackware kullanmıyor oluşunu neden gururla anlattığını hiç anlayamadım

• Reproducible Builds hakkında bilgi burada var
  https://reproducible-builds.org/
  Yakından ilişkili Bootstrappable Builds topluluğu da burada
  https://bootstrappable.org/

• Arch ya da Alpine gibi iyi tasarlanmış mutable işletim sistemleri uzun vadede NixOS benzeri sistemleri geçebilir mi diye merak ediyorum
  Çünkü kurulum script'leri, deklaratif yapılandırma dillerine göre daha ifade gücü yüksek ve çoğu zaman daha az ayrıntılı oluyor

  • O zaman doğrudan Guix kullanmak daha mantıklı olabilir
    Deklaratif bir yapılandırma dili de var, aynı zamanda Turing-complete ve kullanımı rahat bir programlama dili de sunuyor
  • strictly more powerful ile tam olarak ne kastedildiğini merak ettim

• Yazıyı okudum ve oldukça havalı görünüyor ama sanki Dockerfile ile docker image kavramlarını biraz birbirine karıştırıyor
  Dockerfile yerine nix benzeri bir şeyle image tar dosyasını doğrudan oluştursalardı daha kolay olurdu diye düşünüyorum; evet biraz daha niş olurdu ama daha temiz de olurdu

• Küçük bir düzeltme ama bence OCI Image terimini kullanmak daha doğru
  podman ile de sorunsuz çalışıyor

  • Bu yorum bölümünde biraz acemiyim, o yüzden bağlamın tamamını takip edemiyorum ama bu söz gerçekten ufuk açıcı bir nokta oldu

• Bunu gerçekten mümkün kılan insanlara büyük saygı duyuyorum
  Böyle bir başlığı gerçeğe dönüştürmek için gereken zaman ve emek tahmin edilenden çok daha fazla

• Tamamen ayrı bir konu ama o sayfada bir animasyon var ve yaklaşık 1 saniye boyunca sayfadaki neredeyse tüm öğeler aşağı doğru yaklaşık 20 piksel kayıyor
  Gözümün önünde düzen sallandığı için doğal olarak CLS'yi mahvedeceğini düşündüm ama gerçek CLS 0 çıktı
  Bu da bana CLS'nin yanıltıcı bir metrik olup olmadığını düşündürdü

  • Bu, kasıtlı animasyon yüzünden oluyor
    CLS, ilk render sırasındaki değişimleri ele alır; dolayısıyla layout shift gibi görünse de CLS'ye dahil edilen türden bir durum değil
  • Bu bir layout shift değil
    CSS transition kaynaklı bir hareket, yani beklenen bir değişim; bu yüzden layout shift olarak sayılmıyor