“Gerçekten tekrarlanabilir yapılar” tam olarak nedir?


9

Tam olarak nedir? Sürekli Teslimat alanında neden önemlidirler?

Bağlam: (Sanırım reddit) 'in yorumlarından birinde, Gerçekten Tekrar Üretilebilir yapıların hala araştırma altında bir teknoloji olduğunu ve oluşturulması çok zor olduğunu gördüm.

Peki, neden bu kadar yaratıldıklarını bilmek istedim.


belki de atıfta bulunulan bağlamın bir göstergesi (leri)?
Dan Cornilescu

@DanCornilescu Elbette. Ayrıntılar eklendi :)
Dawny33

@ Pierre.Vriens Çekerek, demek istediğim, make possible:) qn da düzenleme!
Dawny33

1
Düzenleme için Merci, ama bakmak, sadece "oluşturmak" demek istediğini düşünüyorum ...
Pierre.Vriens

1
Kendi deneyimimden 90'lı yılların başından itibaren başka bir örnekle cevabımı geliştirmek (veya başka bir cevap eklemek) için tereddüt ediyorum ... (kelimenin tam anlamıyla) dünyanın diğer tarafına uçmakla ilgili bir 3 , 5 inç disket (okuma hataları durumunda 2 kopya ...), yazılımımızı (devasa) bir şirkete teslim etmek için ... ve burada yürütülebilir dosyaları (ana bilgisayarda) yeniden oluşturmak zorunda kaldım. DevOps-avant-la-lettre ...
Pierre.Vriens

Yanıtlar:


8

Tam olarak nedir?

İşte reproducible-builds.org bir alıntı :

Tekrarlanabilir derlemeler, insan tarafından okunabilir kaynak kodundan bilgisayarlar tarafından kullanılan ikili koda doğrulanabilir bir yol oluşturan bir dizi yazılım geliştirme uygulamasıdır.

Neden önemlidir?

IMO'nun önemini açıklamanın en kolay yolu, bunları bir yedekleme prosedürünün bir varyasyonu olarak değerlendirmektir.

Örnek olarak:

  • Bazı yazılım satıcılarından lisanslanan bazı yazılım paketlerini kullanan (ona bağlı) bir işletmeyi varsayalım. İşletme ise yalnızca yürütülebilir dosyaları alırken, bu yürütülebilir dosyaları oluşturmak için kullanılan kaynakları vb. Almaz.

  • Her şey yolunda gidiyor, ama bir noktada yazılım satıcısında bir şeyler ters gidiyor, örneğin işten çıkıyorlar (örneğin iflas).

  • Bu, işletme için uzun bir risk oluşturabilir. Yani, işletmelerin çalıştırılabilir yazılımların (tarafından kullanılan) yazılım sağlayıcısından (günler içinde) kullanılan herhangi bir şeyle ilgili gerekli tüm kaynaklara, belgelere, yapım prosedürlerine vb. oluşturuldu (ve işletmeye gönderildi).

  • Bu " Yazılım Escrow " kurtarmaya geliyor: yerinde böyle bir anlaşma varsa, bir üçüncü taraf aracılığıyla, işletmenin çoğalmak için " kullanılan ne olursa olsun " erişim elde etmek mümkün olacağını düşünürdüm çalıştırılabilirler, böylece işletme o yazılımı kullanmaya devam etme şansına sahip olabilir ve uygun olan yerlerde kendilerini korumaya başlar (yalnızca kendi işlerini yürütmek için).

  • Ancak, önceki madde işaretinde " ne kullanılmışsa kullanılsın " bu işi yapmanın en zor kısmıdır. Üçüncü tarafın önceden uygun doğrulamalar yapmasını gerektirir. Ve bana güvenin, bağlantı tarihi dışında (örn.) Yazılım satıcısının yazılım aracısına sağladığı şeyle mükemmel bir uyum olduğunu kanıtlayabileceğiniz bir yürütülebilir dosyayı yeniden oluşturabilmeniz biraz zaman alır.

Ve yaratmak neden bu kadar zor?

Yukarıdaki örnek hala yeterince net değilse, yazılım emanet acentem olduğunuzu hayal edin, müşterim tarafından lisanslanan yazılımın bir kopyasını yeniden oluşturmak için girdi olarak neye ihtiyacınız olduğunu söyleyin. Anla? Derleyicimin hangi sürümünün, belki de işletim sistemimin, derleme / bağlantı seçeneklerinin, yeniden kullanılabilir bileşenlerin (dahil) sürümlerinin, kitaplıkların vb.


4

Gerçekten tekrarlanabilir bir yapı oluşturma girişiminin pratik bir örneğini sağlamak için aşağıdakileri göz önünde bulundurun -

Hiçbir kullanıcının geçmişi yeniden yazamayacağı veya birleştirilmemiş dalları silemeyeceği git deposuyla başlayan bir derleme hattı.

Kaynak kodunu kontrol ettikten sonraki ilk "derleme" adımı, tüm derleme süresi bağımlılıklarını içeren bir kabı döndürmektir.

Çalışan derleme süresi kabının çıktısı, derlenmiş ikiliyi içeren bir kaptır.

Yapının tekrarlanabilirliği için daha önemli olan son etiketler son konteynere eklenir:

  • Orijinal depodaki kaynak kodun tam karması ve bir artefakt deposuna yüklenen kodun hem git repo'sunun hem de katran topunun anlık görüntüsünün URL'si.
  • Derlemeyi çalıştırmak için kullanılan derleme kabının tam sürümü.
  • İkilinin yüklendiği orijinal temel görüntünün tam sürümü.
  • İkili oluşturmak için kullanılan tüm oluşturma zamanı değişkenlerinin değerleri.
  • Üç konteynerin de birlikte oluşturulduğu docker sürümü ve inşa ettikleri yerde çalıştıkları sürüm.

Tüm bu meta verileri ekleyerek, gelecekte herhangi bir noktada tam yapı bağımlılıkları kümesini (yapı kapsayıcısı aracılığıyla) dışarı çekebilmemizi, ikili dosyayı tam olarak bilinen bir dizi adımla derleyebilmemizi sağlayabiliriz (yapı kapsayıcısında yer alır) ) ve bunu tüm çalışma zamanı bağımlılıklarıyla (temel resim etiketini kullanarak) bilinen başka bir temel resme paketleyin ve bunların tümü, kapsayıcıdaki etikete dayalı olarak kaynak kodunun tam doğru sürümüne dayanabilir.

Teorik olarak bu bize bir derleme sürümünü tam olarak üretebilme yeteneğini vermelidir.

Bunun önemi, üretimde neyin çalıştığına bakmamıza izin veriyor ve her şey önemli ölçüde ilerlemiş olsa bile, geri dönüp orijinal olarak kullanılan kodun, temel görüntünün ve inşa konteynerinin sürümünü çekelim, örneğin, , tam olarak daha önce olduğu gibi yeniden oluşturmadan önce bu sürüme bir düzeltme uygulayın, böylece tek düzeltme düzeltmesi olan tek delta ile tam olarak aynı yapı olduğunu bilerek yeniden konuşlayabiliriz.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.