Helm chart'ları, Bitnami'nin bitnamilegacy'ye geçişinin ardından eski exporter imajlarını kullanmaya devam etti

Ne oldu

dev.to'da yayınlanan bir yazı, Bitnami'nin imaj taşınmasından kaynaklanan ve kolayca gözden kaçabilecek bir hata modunu ele alıyor: PostgreSQL ve Redis'in Helm ile kurulumları, bir taşıma işleminin ardından çalışmaya devam ederken metrics exporter'ları hâlâ terk edilmiş kaynağı gösterebiliyor.

Yazıya göre Bitnami'nin duyurusu, geçmiş imajları docker.io/bitnamilegacy adresine taşıdı; bu depo hiçbir güncelleme veya destek almıyor ve yalnızca bir geçiş deposu olarak düşünülüyor. Yazının yazarının dağıtımları Helm chart'ları kullanıyordu ve bu chart'lar yalnızca veritabanı container'ını değil, aynı zamanda bir metrics exporter'ı ve isteğe bağlı olarak volume izinlerini ayarlayan bir init container'ı da bağlıyor — hepsi Bitnami varsayılanlarından.

Yazar, ana imaj deposunu bitnamilegacy'ye yönlendirerek mevcut sürümlerin çalışmaya devam etmesini sağladı, taşımayı tamamlanmış saydı ve daha sonra ek bir düzeltmenin hâlâ gerekli olduğunu fark etti: PostgreSQL ve Redis metrics exporter'ları değiştirilmemişti. Nihai yama, her chart'ın values dosyasında birer tane olacak şekilde iki küçük ayardı; metrics.image.repository ayarı legacy exporter imajına çevriliyordu. Belirtilen ders: values dosyasını düzenlemek, chart'ın ürettiği her container'ın değiştiğini garanti etmiyor.

Render edilmiş çıktıyla doğrulama

Hatayı yeniden kontrol etmek için yazar, yerelde tuttuğu PostgreSQL chart 16.4.1 ve Redis chart 20.6.2 ile durumu yeniden üretti; bunların yeni dağıtımlar için öneri değil, geçmişe ait yeniden üretim koşulları olduğunun altını çizdi.

Values dosyası global.security.allowInsecureImages ayarını true yapmıştı. Yazıya göre bu chart sürümü, tanımadığı yedek imajları reddediyor ve bu ayar kaynak doğrulama denetimini atlıyor. Bu bir güvenlik beyanı değil ve hiçbir güvenlik açığını gidermiyor.

Chart'ı helm template ile render edip imaj satırları için çıktıyı grep'lemek açığı net biçimde gösterdi. Yalnızca ana imaj değiştirildiğinde, PostgreSQL container'ı bitnamilegacy/postgresql'e çözümlenirken metrics exporter hâlâ bitnami/postgres-exporter'a, izinleri düzenleyen init container ise bitnami/os-shell'e çözümleniyordu. Values düzeltildikten sonra üçü de bitnamilegacy'yi gösteriyordu. Redis chart'ına da ana container, exporter ve init container düzeyinde aynı işlem uygulandı — render edilip kontrol edildi ama runtime'da test edilmedi.

Yazar ayrıca nelerin gerçekte değiştiğini yalıtmak için chart sürümlerini ve imaj etiketlerini sabit tutup yalnızca depoları değiştirdi — ve bu etiketlerin Docker Hub'dan hâlâ soğuk çekimle (cold-pull) indirilip indirilemediğinin yeniden test edilmediğini belirtti.

Aynı taban üzerine pgvector ekleme

Ayrı bir gereksinim olan PostgreSQL için pgvector eklentisi, özel bir derlemeye yol açtı. Yazar, giriş noktasını, ortam değişkenlerini, veri dizinini ve chart'ın beklediği çalıştırma kullanıcısını yeniden doğrulamayı gerektirecek şekilde başka bir PostgreSQL dağıtımına geçmek yerine, değişikliği küçük tutmak için aynı Bitnami tabanı üzerine derledi.

Dockerfile iki aşamalı bir derleme. Bir derleme aşaması derleme araçlarını ve git'i kuruyor, pgvector v0.8.6'yı klonluyor ve PG_CONFIG'i Bitnami PostgreSQL kurulumunu gösterecek şekilde ayarlayarak derliyor; OPTFLAGS boşaltılıyor ki -march=native, derleme makinesinin CPU talimatları eklentiye işlenmesin — bunun pgvector'ın kendi taşınabilirlik önerisi olduğu, çapraz mimari garantisi olmadığı belirtiliyor. Son aşama aynı tabandan başlıyor ve yalnızca derlenen eklenti dosyalarını kopyalıyor; böylece araç zinciri teslim edilen imaja hiç ulaşmıyor.

Doğrulama, ağdan yalıtılmış bir container'da, temiz bir test volume'ü üzerinde çalıştı: özgün imajın yazdığı veriler okunabilir kaldı, SHOW data_directory değişmedi ve eklenti, iki dik test vektörü arasında 1.000 kosinüs mesafesiyle sürüm 0.8.6 bildirdi. Yazar sınırlar hakkında açık: çapraz ana sürüm taşıması veya üretim verisi söz konusu değildi ve sonuç, rastgele PostgreSQL imajlarının birbirinin yerine geçebileceği anlamına gelmiyor.

Kendi imajını derlemek neyi çözmez

Yazının kapanışındaki tartışma en keskin nokta: bir derleme aşamasında apt-get update çalıştırmak, nihai imajda hiçbir şey yamalamıyor; çünkü son aşama yine bakımsız legacy tabandan başlıyor. Özel imaj bir yetenek ekliyor; bakımı geri getirmiyor. Kalan işler arasında taban ve eklenti sürümlerini takip etmek, chart'ın başlatma kurallarına uymak ve imaj saklama ile sabitlemeyi yönetmek var — yeniden üretilebilir derlemelere yaklaşmak için digest'ler, kaynak commit'leri ve derleme bağımlılıkları gerekiyor. Gerçekten bakımı yapılan bir imaja geçmek ise, başarılı bir başlatmanın tamamlamadığı ayrı bir görev olarak duruyor.

Neden önemli

Bitnami imajları sayısız Helm chart'ının varsayılan temeli olduğu için, yukarı akıştaki bir katalog değişikliği aşağı akışta sessiz bir operasyonel işe dönüşüyor. İki pratik uyarı öne çıkıyor. Birincisi, bir chart birden fazla imaj deposu içerir — ana container, exporter'lar, init container'lar — ve kısmi bir taşıma, olmadığı ana kadar başarılı görünür; düzenlenmiş values dosyaları yerine render edilmiş çıktıyı doğrulayın. İkincisi, bitnamilegacy açıkça desteklenmiyor; üzerine özellik derlemek dağıtımları yamalanmamış bir tabanda bırakıyor ve "düzgün başlıyor" ile "bunu biri bakımda tutuyor" aynı şey değil.