Docker, şüphesiz son on yılın en etkili geliştirici teknolojilerinden biridir. Kapsayıcılar, uygulamaları izole etmek, fiziksel makineler arasında ölçeklendirmek ve ortamlar arasındaki farkları soyutlamak için bir çözüm sağlamıştır.
Docker’ı veya bitişik bir kapsayıcı teknolojisini benimseyen birçok kuruluş, bunun verimliliği artırdığını ve geliştirme sürecini hızlandırdığını düşünüyor. Docker, her sistemi sihirli bir şekilde geliştiren bir şey değil. Bu makalede, konteynerlere taşınmanın yardımdan çok bir engel olabileceği bazı senaryolara bakacağız.
Performans Kritik Olduğunda
Docker, performansın kritik olduğu sistemler için en iyi seçim olmayabilir. Kapsayıcılaştırmanın doğası, yazılım doğrudan bir ana makineye yüklendiğinde var olmayan genel giderler yaratır.
Elbette Docker, özellikle uygulamanızı yatay olarak ölçeklendirmeyi kolaylaştırarak performansı artırmaya da yardımcı olabilir. Bu nedenle, bu kararın sisteminizin gereksinimleri ve temeldeki işletim sistemiyle etkileşimleri bağlamında yapılması önemlidir.
Docker, bir VM’den çok daha az kaynak kullanır, ancak yine de ana bilgisayarda çalışması gereken başka bir işlemdir. Kaynak kısıtlı ortamlarda, kapsayıcı işlemlerinin veya Docker arka plan programının kendisinin, işletim sistemi bellek yetersiz katili tarafından hedeflendiğini ve uygulamanızın parçaları çıkarıldığında kademeli hatalara neden olduğunu görebilirsiniz.
Çok Sayıda Kalıcı Veri
Docker kapsayıcıları, varsayılan olarak geçici olacak şekilde tasarlanmıştır. Kalıcı veriler, birimlerin kullanımıyla desteklenir. Bunlar, ana bilgisayarda başka bir yerde veri depolamak için kaplara monte edilir.
Birim depolamanın performansı, seçilen sürücüye ve ana bilgisayar ortamına bağlı olarak değişir. En iyi senaryoda bile, ana bilgisayarın dosya sistemiyle doğrudan etkileşime kıyasla fazladan bir ek yük vardır. Bu, yüksek hacimli dosya okuma veya yazma işlemlerinin olduğu durumlarda önemli olabilir.
Birimlerde depolanan verilerin yönetimi ve bakımı zor olabilir. Birimlerinizle etkileşim kurmak için Docker komutlarını kullanmanız gerekir. Veri incelemeleri en iyi şekilde, kaba bir kabuk getirilerek ve birimin içeriği içeriden numaralandırılarak gerçekleştirilir.
Docker, depolama hakkında düşünmenizi ve kendi kalıcılık stratejinizi seçmenizi gerektirir. Bu, daha sonra nasıl yöneteceğiniz konusunda endişelenmeden herhangi bir dizinde verileri güvenle depolayabileceğiniz VM’ler ve işletim sistemi paketi kurulumundan farklıdır.
Yerel Araçlar ve Uygulamalar Geliştirme
Docker, her ortama yüklemek istemediğiniz bağımlılıklara sahip uzun ömürlü hizmetler oluştururken en mantıklı olanıdır. Yaygın bir örnek, bir NGINX web sunucusunun arkasında çalışan bir PHP web uygulaması olabilir: tek bir komuttan başlatmak istediğiniz bir arka plan sunucusu da dahil olmak üzere birden çok bileşen vardır.
Docker, masaüstü programları ve mobil uygulamalar gibi yerel kullanım için araçlar oluştururken daha az değer katar. Bu tür bir yazılım geliştirme, kapsayıcılarda çalıştırılamayan veya kullanıcılar tarafından yaygın olarak kapsanmayacak yapay öğeler üretme eğilimindedir.
Paketlemek için kullanarak bu durumlarda Docker’dan yine de yararlanabilirsiniz. alet zinciri, nihai çıktıdan ziyade. Örnek olarak, yeni geliştiricileri bu paketleri makinelerine eklemekten kurtarmak için Java ve Android Platform Araçlarını içeren bir Docker görüntüsü oluşturabilirsiniz.
Ancak bu, Android Studio, Visual Studio ve Xcode gibi IDE’ler tarafından yönlendirilen disiplinlerde daha fazla karmaşıklık ekleme eğilimindedir. Geliştiriciler, IDE’yi kurmaya ve ortamlarını yapılandırmasına izin vermeye alışkındır. Bu nedenle Docker, derlenmiş dil iş akışlarına, doğru yorumlayıcı sürümünün bir görüntüye dönüştürülebildiği yorumlanmış dillerden daha az değer katma eğilimindedir.
Güvenlik Önceliklidir
Liman işçisi Yapabilmek yığınınızın güvenliğini artırın, ancak kurulumunuzu düzgün bir şekilde sertleştirmek için çalışmanız gerekir. Çok sık yapılan bir hata, Docker’ın kullanıma hazır olduğunu varsaymaktır. Açıkça söylemek gerekirse: öyle değil.
Docker’ın yalnızca varlığının bir güvenlik riski olduğunu söylemiyoruz, çünkü durum böyle de değil. Yine de Docker’ın benzersiz riskler taşıdığını ve bu risklerin teknolojiyi kullanımınıza bağlı olarak değişeceğini bilmek önemlidir. Diğer tüm yazılım bileşenleri gibi, bu riskleri, sizin için önemli olan güvenlik standartlarına uygunluğunuzu nasıl etkilediğini ve bunları ele almak için ne yapmanız gerektiğini anlamak için zaman ayırmanız gerekir.
“Yalıtılmış uygulamalar” sesini duymak ve bunun sandbox düzeyinde güvenliği kapsadığını varsaymak çok kolay. Gerçekte standart bir Docker kurulumu, konteyner işlemlerini şu şekilde çalıştırır: root ve bir kapsayıcı kırılması, ana makinenizin güvenliğini tehlikeye atabilir.
Docker güvenliği, ana bilgisayar ortamını, Docker arka plan programını ve görüntülerinizi nasıl oluşturup koruyacağınızı düşünmenizi gerektiren çok yönlü bir konudur. Kapsayıcılar içinde çalışan koddaki riskli işlemleri en aza indirerek geliştiricilerin de oynayacağı bir rol vardır.
Tüm bunlar, Docker’ın güvenlik açısından kritik ayarlar için mükemmel bir seçenek olmayabileceği anlamına gelir. Docker güvenlik korumaları sağlayabilse de, ortaya çıkardığı yeni sorunları ele aldığınızdan emin olmak için yetenekli ekip üyelerine ve güvenlik bilincine sahip bir zihniyete sahip olmanız gerekir.
Kod Tabanınız Bir Monolittir
Muhtemelen kapsayıcıların mikro hizmetlerle el ele gittiğini okumuşsunuzdur. Bu zihniyet, sisteminizi kolayca kapsayabilecek bağımsız bileşenlere ayırma sürecini tanımlar. Hizmetlerinizi böldükten sonra, ayrı ayrı ölçeklenebilirler ve diğerlerini etkilemeden parçaları değiştirebilirsiniz.
Uygulamanız monolit olduğunda bu avantajları göremezsiniz. Ancak monolitik bir sistemi olduğu gibi kapsayıcı hale getirmek yanlış bir yaklaşım olabilir. Büyük bir eski uygulama, Docker imajınızı hızla şişirebilecek çok sayıda bağımlılık ve uzun bir oluşturma süreci edinme eğilimindedir. Bu, görüntü oluşturma sırasında sinir bozucu bekleme sürelerinin yanı sıra aşırı depolama ve bant genişliği maliyetleriyle sonuçlanır.
Her zaman olduğu gibi, bu madalyonun iki yüzü vardır: Bir monoliti kapsayıcı hale getirmek, yığınınızı modernize etmenin ve onu daha küçük hizmetlere ayırmanın ilk adımıdır. Bu, kod tabanını bağlı olduğu ortamdan ayırdığınız noktadır.
Yine de gelecekte yeniden düzenlemeye devam etme niyeti olmadan kapsayıcı hale getiriyorsanız, motivasyonlarınızı yeniden gözden geçirmeniz en iyisi olabilir. Birden çok işlevsel bileşen içeren büyük kapsayıcı resimleri, kapsayıcı en iyi uygulamalarını karşılamadığınızın iyi bir göstergesidir. Zamanla yaklaşımın sizi geride tuttuğunu ve sorunun bir parçası haline geldiğini görebilirsiniz.
Karmaşıklığı Azaltmaya Çalışıyorsunuz
Karmaşıklığı azaltmaya mı çalışıyorsunuz? Kapsayıcılaştırmanın geliştirme ve dağıtıma yeni bir basitlik getireceğini mi düşünüyorsunuz? Bir kez daha bu bir “bağlıdır” anıdır, ancak ana motivasyonunuz olarak basitlikle Docker çoğunluğuna atlamamaya karşı dikkatli oluruz.
Docker, yeni araçlar ve kavramlarla bir zihniyet değişimi ve aşinalık gerektirir. Geliştiricileriniz bununla rahat edecek mi ve işe alım süreçlerinizi nasıl etkileyecek? Bunlar kolayca gözden kaçabilecek, ancak erkenden düşünülmesi gereken sorulardır.
Docker birçok karmaşıklık biçimini ortadan kaldırsa da, farklı biçimlerde yeniden ortaya çıkma eğilimindedir. Yerel olarak geliştirici makinelerinde veya bir CI işlem hattının parçası olarak Docker görüntülerinizi yazmanız, belgelemeniz, bakımını yapmanız ve oluşturmanız gerekir. Geliştiricilerin Docker CLI’yi, kapsayıcıların ne olduğunun temellerini ve kapsayıcılaştırma için uygulamalar hazırlarken dikkat edilmesi gereken olası sorunları öğrenmesi gerekecektir.
Konteynerleri üretimde çalıştırmayı planlıyorsanız, başka düşünceleriniz de olacaktır. Ağ trafiği kapsayıcılara nasıl yönlendirilecek? Bir konteyner beklenmedik bir şekilde durursa sistem nasıl yanıt verir?
“Docker basittir” zihniyetinin savunucuları, zaten sahip olduğunuz görüntülerin örneklerini safça başlatabilme kolaylığına dar bir şekilde odaklanma eğilimindedir. Dizüstü bilgisayarınızda yeni bir MySQL veritabanı istiyorsanız, bunun sadece bir docker run -d mysql:8 uzak. Yine de, en iyi uygulamaları karşılarken ve yaygın tuzaklardan kaçınırken kendi yazılımınızı oluşturmak ve çalıştırmak için Docker’ı başarılı bir şekilde kullanmak istiyorsanız öğrenecek daha çok şey var.
Neden Kapsayıcı Olduğunuzdan Emin Değilsiniz
Konteynerler her yerde; yazılım geliştirmeyle ilgili birkaç makaleden fazlasını okumadan bunlara rastlayamazsınız ve destekçileri sesli ve coşkulu. Bu popüler çekicilik, Docker’ın başkalarının yararlı bulduğu “modern” bir araç olarak benimsenmesi için baskı yaratabilir.
Bu, kapsayıcı hale getirmek için iyi bir neden değil. “Geliştiriciler üretimi yerel olarak tam olarak kopyalayabilmeli” veya “hizmetlerimizin kopyalarını yatay olarak ölçekleyebilmemiz gerekiyor” gibi daha somut bir hedefe ihtiyacınız var. Docker için kesin bir kullanım durumu hissetmiyorsanız ve mevcut iş akışınızdan memnunsanız, en iyi seçenek neyin işe yaradığına bağlı kalmak olabilir. Sıkıcı bir seçim gibi görünebilir, ancak Docker kusursuz bir dönüştürücü güç değildir ve başarılı bir şekilde benimsenmesi garanti edilmez.
Süreçlerinize Docker eklemek, önemli miktarda ön yatırım gerektirebilir. Kod tabanınızı yeniden düzenlemeniz, Docker dosyalarınızı yazıp test etmeniz, geliştiricilere öğrenmeleri için zaman vermeniz ve bir güvenlik değerlendirmesini tamamlamanız gerekebilir. Ortaya çıkan faydalar belirsiz olduğunda – ve başarının nasıl görüneceğini belirlemediyseniz – çaba, sisteminizdeki üretken çalışmayı azaltan bir yük olabilir.
Çözüm
Docker haklı olarak popüler bir teknolojidir: birçok ekip ve geliştirici için, gerçek dünyadaki geliştirme süreçlerini basitleştirmesine olanak tanıyan ideal bir kullanım kolaylığı, esneklik ve performans dengesi sunar. Yine de Docker sihirli değil: Mevcut teknolojilerinize, süreçlerinize ve zihniyetinize bağlı olarak çalışamayacağı ve çalışmadığı başka durumlar da var.
Docker bugün projeleriniz için pek uygun olmasa bile, aşamalı olarak benimseyerek bazı avantajlar elde edebilirsiniz. Süreçlerinizdeki zorlukların neler olduğunu belirleyin, ardından Docker’ın bu belirli alanlarda yardımcı olup olamayacağını değerlendirin. Örnek olarak, geliştiriciler API’nizin hazırlama örneklerini döndürmek için çok fazla zaman harcıyorsa, yığınınızın bu bölümünü Dockerize etmek, üretimde kapsayıcıları çalıştıramıyor olsanız bile darboğazı çözebilir.
Kapsayıcıların tüm amacı, uygulamanızın parçalarını bağımsız olarak çalışan yalıtılmış bileşenler olarak paketleyebilmektir. Bu otomatik olarak paketlemeniz gerektiği anlamına gelmez Her kapsayıcı olarak bileşen. Objektif kalın, mantıklı olduğu yerde kapsayıcı fırsatlar arayın, ancak Docker’ın mevcut iş akışınıza değer katmadığı durumları tanımaya hazır olun.
