Testler söz konusu olduğunda, iki seçenek düşünebilirim:

1. Hem testi hem de uygulamayı tek bir görüntüye koyun.
2. Resme yalnızca uygulama kodunu ekleyin. Ana görüntüden sonra oluşturulan ve ona bazı katmanlar (test kodu, bağımlılıklar vb.) Ekleyen sınama özel bir kap oluşturun.

İlk seçenekle, konteyneri test edebilir ve tam olarak test edildiği gibi gönderebilirim. Açık bir dezavantaj, gereksiz kod (ve potansiyel olarak test verileri) görüntüye dahil edilecektir.

İkinci seçenekte, gönderilen görüntü test edilenle tamamen aynı değildir.

Her ikisi de kötü stratejilere benziyor. Üçüncü, daha iyi bir strateji var mı?

Oluşturma süresi testleri için tercih edilen yol çok aşamalı bir yapı kullanmaktır . Çok Aşamalı Docker dosyaları, oluşturma ve test etme ile ilgili tüm bağımlılıklarla daha büyük bir aşamaya sahip olmanıza olanak tanır, ardından test ettiğiniz tam yapay nesneleri daha küçük bir çalışma zamanı görüntüsü için başka bir aşamaya kopyalar.

Ayrıca, kap içinde çalışmak yerine harici arabirimlerini kullanarak birden çok kapsayıcı için sistem düzeyinde testler de istersiniz. Bu testler hizmetler arasında koordinasyonu içerdiğinden, düzenlemenize erişim gibi farklı bağımlılıklar gerektirdiğinden, oluşturma süresi testleri kadar kapsamlı olmadığından ve genellikle tamamen farklı dillerde yazıldığından, bunları ayrı bir Docker'dan çalıştırmak önemli değildir. sadece sistem testine ayrılmış konteyner.

Dediğin gibi üçüncü bir yol var. Bence geliştirme, test etme ve konuşlandırmayı karıştırıyorsunuz. İlk olarak, ne elde etmeye çalıştığınızı anlamak için tüm SDLC'ye bir bütün olarak bakılmasını öneriyorum. Bu büyük bir konu ama özetlemek için elimden geleni yapacağım.

TL; DR;

Kısacası, ayırmanız gerekir:

• kodunuz
• uygulama yapılandırması,
• sistem ortamı yapılandırması.

Her birinin birbirinden bağımsız ve uygun olması gerekir:

• sürüm kontrollü
• test edilmiş
• konuşlandırılabilir

Daha Uzun Versiyon

İlk olarak, kod ve (ayrı ayrı) konfigürasyondan oluşan bir uygulamanız var. Bunun hem yapı hem de kasıtlı işlev için test edilmesi gerekir - buna sürekli entegrasyon (CI) denir. Bu hizmetin hem çevrimiçi hem de yerel olarak birçok sağlayıcısı vardır - örneğin deponuza bağlanan ve taahhüt ettiğiniz her seferde oluşturup test eden bir bulut sağlayıcısı için CircleCI . Deponuzu on-Prem ve benzeri bir bulut sağlayıcı, bir şeyler kullanamıyorsanız Jenkinseşdeğerdir. Uygulamanız oldukça standartsa, muhtemelen CI hizmetinin kullanabileceği bir Docker görüntüsü vardır. Değilse, uygulama kodunuzun ve yapılandırmanızın dağıtılabileceği bir tane veya böyle bir küme oluşturmanız gerekir. Doğru şekilde yapılandırıldığında, uygulama kodunuzun kalitesi hakkında çok sayıda istatistiğe sahip olacaksınız.

Ardından, uygulamanızın işlevselliğinden ve doğruluğundan memnun olduğunuzda, kod tabanı belirli bir sürüm için uygun şekilde etiketlenmelidir. Bu yapı daha sonra bir test ortamına dağıtılmalıdır. Kodun, CI'nizde test edilenle aynı olacağını unutmayın (muhtemelen bunu doğru yaptıysanız), ancak yapılandırmanız farklı olabilir. Yine bazı CI sağlayıcıları bu adımı sunabilir, böylece paketlenmiş bir uygulama ve ayrık yapılandırmanın dağıtımını test edebilirsiniz. Bu aşama tipik olarak kullanıcı işlev testlerini (yeni işlevler için) ve otomatik testleri (bilinen işlevler için) içerir. Sürüm bu aşamayı geçerse, entegrasyon testi için bir sürüm adayınız vardır. Otomasyon testlerini başka bir Docker konteynerinden çalıştırabilir,Kodlama çabası için 1: 1 olduğunu belirten bazı ölçümler (buna rağmen emin değilim).

Nihayetinde, bir sonraki adım (sistem) ortamınızı üretimdeymiş gibi inşa ettiğiniz yerdir. Üretimde Docker kullanıyorsanız, burası güvenlik sertleştirme, ağ ve sunucu optimizasyonu vb. , söylediğim gibi. Şimdiye kadar uygulamanın fonksiyonel testi tamamlanmalıdır, güvenlik ve performansla daha fazla ilgilenirsiniz. İşlevsel testlere göre, buradaki testleriniz diğer Docker görüntülerinden geliştirilebilir, dağıtılabilir ve çalıştırılabilir. Bu adım eskiden çok pahalıydı ve nadiren yapıldığı için, üretimi yeniden üreten özel bir donanıma ihtiyacınız vardı. Bugün, bu talep üzerine hemen hemen her ölçekte tüm ortamı ayağa kaldırabileceğiniz için tamamen uygulanabilir.

Son olarak, entegrasyon testinizin (IP adresleri, veritabanı URI'leri, şifreler vb.) Sadece küçük bir yapılandırma deltası seti ile üretime hazır olması gereken bir sürümünüz var. Kod tabanınız en az üç farklı ortamda test edildi noktası ve sistem yapılandırmasının çoğunluğu en az bir kez.

Farklı test türlerini karıştırdığınızı düşünüyorum. Temel olarak kendinize şunu sormanız gerekir: Burada test edilen birim nedir?

Bir geliştirici olarak çalışırken en sık karşılaşılan senaryo, üzerinde çalıştığınız kod parçası için birim / entegrasyon testleri yazmaktır; burada kod parçası test edilen birimdir. Bu testleri yerel olarak ve / veya CI'de gerçekleştirirsiniz.

Yeni bir liman işçisi resmi oluşturduğunuzda, test edebileceğiniz yeni bir birim haline gelir. Bu görüntü için ne tür şeyleri test etmek istersiniz? Sağladığı API nedir? Bunu nasıl test edersin?

Bir web uygulamasıysa, görüntüye dayalı bir kapsayıcı başlatabilir ve bazı HTTP istekleri yapabilir ve yanıtların beklediğiniz gibi olup olmadığını kontrol edebilirsiniz. Yaşadığınızı düşündüğüm sorun, uygulama koduna bağlanan test çerçevesine çok alışmış olmanız. Bu geliştirme sırasında sorun değil, ancak şimdi bir liman işçiliği imajını test etmek istiyorsunuz ve bu yüzden bunu yapabilen ve uygulama koduna bağlı olmayan yeni bir tür test çerçevesine ihtiyacınız var.

Bu yüzden aradığınız 3. seçenek:

• Docker görüntüsü oluşturmadan önce birim / entegrasyon testlerinizi yapın.
• Yalnızca dağıtmak istediğiniz uygulamayı içeren bir liman işçisi görüntüsü oluşturun.
• Uygulama görüntüsünün üstüne ek katmanlar eklemek yerine, belirli parametrelerle çalıştırarak olduğu gibi test edersiniz ve beklenen çıktılarınızı onaylarsınız.

CI / CD adımları şöyle olur:

Kurulum geliştirme ortamı -> Test kodunda çalıştır -> Son görüntü oluştur -> Görüntü üzerinde test çalıştır -> Görüntüyü dağıt.