Docker kullanım durumum için uygun mu?

Şirketimin temelde Ubuntu 12.04 çalıştıran bir mini bilgisayar "Smartbox" dan oluşan sattığımız bir sistemi var. Bu kutu bir Django uygulaması ve bununla ilgili bir dizi farklı başlatma işlemi çalıştırır. Çok fazla değil. Sahada binlerce kutu var. Paket bağımlılıklarını, süreç kaydını vb. Değişen derecelerde bir deb paketi aracılığıyla yönetiyoruz.

Alandaki kullanıcılarımıza güncellemeleri etkili ve sağlam bir şekilde aktarmanın bir yoluna ihtiyacımız var. Ayrıca, işletim sistemini yükselttikçe (bir Ubuntu yükseltmesi için gecikmiş olduğumuz gibi) paketlerimiz "sadece çalışıyor" hakkında nispeten güvenli hissedebileceğimiz bir şeye ihtiyacımız var.

Docker hakkında fazla bir şey bilmiyorum, ama sorunumuzu ilk duyduğumda (yeni bir işe alım yapıyorum), Docker ilk düşüncemdi. Ama daha fazla düşündüğümde belki öyle değilmiş gibi hissettim, bu kutular bizim olduğu için Docker'ın değer teklifinin büyük bir kısmı olan işletim sistemini kontrol ediyoruz, ya da anlıyorum. Yani kutularımızı her zaman Ubuntu olacak ve temelde sadece bir Django uygulamamız ve çalışacak bazı süreçlerimiz varsa, Docker bir deb paketinden daha iyi midir?

TL; DR: Ubuntu'yu her zaman çalıştıracak dağıtılmış bir cihaz için Docker ve deb paketleri vs platform bağımsızlığı o kadar da önemli değil.

Sorudan anladığımdan% 100 emin değilim, ancak Docker çözümü, bir işletim sistemi ve uygulamanız yüklü bir (fiziksel?) Cihaza sahip olmaktan, bir işletim sistemi ve Docker, uygulamanızın bulunduğu tek bir kapsayıcı çalıştırıyor. Bu, ana makinedeki işletim sistemini güncelleme ihtiyacını ortadan kaldırmaz ve kolayca görünür bir fayda olmadan karmaşıklık katmanı (ve artık Docker ve OS'yi yamalı tutmak zorunda kalacağınız için daha fazla güncelleme) ekler. soruda belirtilen spesifik alanlar söz konusu olduğunda.

Bununla birlikte, sanal bir cihazdan bir Docker konteynerine gitmekten bahsediyorsanız , bu sizin için işleri düzene sokabilir, ancak Docker'ı ürününüz için bir bağımlılık olarak ekler; Docker kullanmayan ve yalnızca ürününüzü kullanmak için yığınlarına eklemek istemeyen herkesi kapatıyorsunuz. Docker'ı kullanmayan / kullanmayacak olanları (şimdi "eski") sanal cihazı daha önce olduğu gibi göndermeye devam ederek desteklemeye devam edebilirsiniz, ancak şimdi yerine yüklemek için iki dağıtımınız olduğu için iş yükünüzü iki katına çıkardınız. bir.

Docker ile uzun süre çalıştım. Platform bağımsızlığı güzel, ancak Docker hakkında en yararlı olduğunu düşündüğüm şey değil.

Her şeyden önce tekrarlanabilirlik elde edersiniz. Bir Dockerfile oluşturabilir, geliştirici makinenizdeki bir kapta hata ayıklayabilir, sürekli bir entegrasyon sunucusunda ve daha sonra son ürününüzde testler çalıştırabilirsiniz ve bunun tüm bu ortamlarda aynı şekilde davranacağını bilirsiniz. Bir geliştiricinin makinelerine yüklediği bir bağımlılığı unutmamak gerekir. Ayrıca, geliştiricilerinizin masalarında Ubuntu kullanmak zorunda değiller. Arch Linux kullanıcılarını mutlu etmemiz önemlidir :-)

İkinci olarak, yükseltme senaryosunuz için, bir kerede bir makineye birden fazla sürümün çekilmesini sağlayabilirsiniz. Bir docker pull myapp:2.0süre 1.0çalışıyorsa, 2.0çok hızlı bir şekilde değiştirebilirsiniz . Normalde tam bir OS yükseltmesi yapmaktan çok daha hızlıdır. Birden fazla mikro hizmet örneğine sahip bir orkestratör kullanıyorsanız, hizmeti hiç kesintiye uğratmayan yuvarlama yükseltmeleri bile yapabilirsiniz.

Bir mikro hizmet modeli kullanırsanız Docker, saldırganların bir istismar durumunda karşılaşabilecekleri hasar miktarını sınırlayabilen sanal alanlar da sağlar. Tüm bir makine üzerinde kontrol elde etmek yerine, sadece bir konteyner üzerinde kontrol kazanıyorlar.

Ana dezavantajı ana işletim sistemi ve bir çeşit düzenleme gerekir. Bunun için birçok seçenek var, ancak birini değerlendirmek, yerine koymak ve sürdürmek için gereken iş miktarını hafife almayın.

Büyük docker, hem geliştiriciler hem de operasyon personeli için birçok avantaj sağlar. Bazı uygulamalarım için docker kullanıyorum ve çok güvenilir ve sağlam bir yaklaşım olarak görüyorum.

Docker'ı benimsemeyle ilgili sorunum, doğru soruları sorduğunuzu duymuyorum ve en önemli gereksinimlerinizi ele almadan hayatınızı daha karmaşık hale getirebilirsiniz.

Sormanız gereken ilk soru (yeni olduğunuzu söylediniz), işletim sistemi ve uygulama güncellemeleri şimdi nasıl ele alınıyor? Mevcut metodoloji sizin için (şirketiniz) çalışıyor mu? İyi olan nedir? Neler geliştirilebilir? Alandaki hedef makinelerinizde doğru işletim sistemi yamalarına, uygulamalarına ve yetkisiz değişiklikler olduğunu doğrulamak için fiziksel bir yapılandırma denetimi yapabilir misiniz?

Docker'ı seviyorum, ancak şu anda neyin iyi çalıştığını ve neyin iyileştirilmesi gerektiğini de içeren nerede olduğunuzu değerlendirmeden docker bandwagonuna atlamam.

Çakışan bazı küçük bölgeler olsa da Docker ve Debian paketleme sistemleri aslında iki farklı sorunu çözüyor :

• Debian paketleme sistemi, yazılımı bir ana bilgisayara yüklemek ve mümkün olduğunca kolay bir şekilde yükseltmek için tasarlanmıştır. “Yazılım X sürüm A, sürüm B veya daha yeni bir sürüm yüklü Y yazılımı gerektirir” veya “yazılım X asla Z yazılımı C sürümüyle kurulmamalıdır” gibi yazılım bileşenleri arasında karmaşık bağımlılık ve kısıtlama kalıplarını işleyebilir.

• Docker sistemi, hizmetleri, özellikle mikro hizmetleri, muhtemelen birkaç ana bilgisayarda, örneğin bir Docker sürüsü veya bir Kubernetes kümesi gibi kolayca tanımlamak ve dağıtmak üzere tasarlanmıştır.

Bu iki problem aslında diktir, yani çözülecek konuşlandırma problemi göz önüne alındığında, çözümün bir parçası olarak bunlardan biri, her ikisi de, hatta hiçbiri kullanılabilir. Her ikisini de kullanırken, Debian paketi Docker görüntüsünün üretiminde kullanılır ve Dockerfile öğeniz (bir kapta “sanallaştırılmış sistemi” açıklayan Docker görüntüsünü hazırlamak için kullanılan tarifler) esasen Debian deponuzu Debian paketleme sisteminin kaynakları ve paketinizi kurun.

Bunu göz önünde bulundurarak, bana göre gerçekten aradığınız şey değişmez sunucu kalıbını uygulamak. Bulut teknolojilerindeki son gelişmeler, klasik yazılım yükseltme sistemini bir yazılım paket sisteminden (Debian paketleme sistemi gibi) kullanarak değil, tüm sunucuyu aynı anda değiştirerek yazılımın yükseltilmesini mümkün kıldı. (Bazı kişiler bu geliştirmeden önce, sunucuda üç işletim sistemi, iki cihazı çalıştırmak için alternatif olarak kullanılan ve cihaz değiştirme işlemini gerçekleştirmeye adanmış bir mini işletim sistemi kullanarak bunu yaptı. Aşırı karmaşık olmasa da, bu her zaman ) Bu teknik sizin için ilgi çekici olabilir, çünkü paket yöneticisini kullanarak sunucunuzdaki yazılımı yükseltmek için kullanılırsanız, sunucunun son durumu sunucunun "yükseltme geçmişine" bağlıdır - özellikle de hatalar oluşursa yükseltme işlemi. Bu heterojenlik kötüdür,

Sahada binlerce kutu var. Paket bağımlılıklarını, süreç kaydını vb. Değişen derecelerde bir deb paketi aracılığıyla yönetiyoruz.

bununla ilgili olabilir. Değişmez sunucu modeli bu hata kaynağını “yükseltme geçmişi” kavramını problemden yok ederek siler.

Şimdi değiştirilemeyen sunucu desenini uygulamak için çeşitli seçenekler var, iki popüler seçenek Docker görüntülerini, görüntülerini kullanmak veya bulut sağlayıcınızdan “ana örnek görüntüleri” kullanmaktır (bunlara AWS'de AMI'ler ve Google Compute Engine'de yalnızca Özel Görüntüler denir) . Kullanım durumunuz bulut tabanlı tekniklerin kullanımını yasaklar, bu nedenle Docker görüntülerini tek uygun seçenek olarak kabul edeceğim. (Tamamlama uğruna Docker'a alternatif olarak Virtual Box veya benzeri bir sanallaştırma çözümü kullanmak gibi diğer yaklaşımları kullanmak kesinlikle mümkündür.)

Değişmez sunucu modeli tekniğini kullanırken, sunucunuzu temsil eden yeni bir artefakt (Docker görüntüsü) sunarsınız ve bu artefakt da test edilebilir ve servis yükünün yanı sıra üretim ayarlarınızı doğru bir şekilde kopyalayan bir kurulum elde etmek çok kolaydır.

Şimdi açıkladığınız somut problemi düşünmek için, Docker ile değişmez sunucu desenini uyguladığınızı varsayalım. Docker sistemi ve Debian paketleme sistemi birbirini dışlayan (cf. intro) yerine tamamlayıcı olduklarından, yazılımınız için bir Debian paketi hazırlamanız gerekip gerekmediğini sormak zorundayız.

Yazılımınızı yüklemek için bir Debian paketi kullanmanın uygunluğu (Docker görüntüsünde veya bir ana bilgisayarda) çözmeniz gereken sürüm oluşturma sorununun karmaşıklığında yatar. Aynı anda yazılımınızın çeşitli sürümlerini çalıştırıyorsanız, zaman zaman sürüm düşürmeniz ve dikkatle belgelemeniz gereken karmaşık sürüm gereksinimleriniz varsa, Debian paketine sahip olmak şarttır. Aksi takdirde, bu adım atlanabilir - ancak bu paketleri üretmek ve dağıtmak için zaten çaba harcadığınızdan, işinizi atmanın gerçek bir değeri yoktur. Bu nedenle Debian paketlerinizi üretmeye devam etmenizi öneririm.

Bence iyi bir seçenek olabilir (daha fazla test gerekli)

Yaptığınız kapsayıcının tüm etiketlerini / sürümlerini içeren bir URL sağlayabilirsiniz ve istemciler kapsayıcının yeni bir sürümünün olup olmadığını görmek için bu URL'yi okuyacaktır.

Kişisel dosyalarınızı / ayarlarınızı yerel olarak depolayabilirsiniz ve bu bilgileri yükseltmelerde asla kaybetmezsiniz ve yaptığınız ve test ettiğiniz şeyin herkes için aynı şekilde çalışmasını sağlarsınız.

Hatta kullanıcılara mevcut olandan hangi sürümü kullanmak istediklerini seçme imkanı verebilirsiniz (bu olanağı vermek istiyorsanız).

Debian paketleri ile uğraşmaktan çok daha iyi, sadece konteynerin yeni bir sürümünü almak hakkında konuşmak, "" sadece bir paket yükseltme "" gibi olacak;)

Docker benim için makul geliyor, çünkü evde kapta değişiklikler yapabilir ve test edebilirsiniz ve daha sonra serbest bırakma işleminize bağlı olarak, her zaman çeken kapları yeniden başlatın: en son veya test edilmiş bir yükseltme sağlayacak benzer bir şey.

Kapsayıcılar yeniden başlatma sırasında değişiklikleri korumadığından veri depolama alanını içerir, bu nedenle bir veri hacmi istersiniz. Muhtemelen içine girdiğinizde çok daha fazla düşünmeniz gerekir. Şu anda birlikte çalıştığım sistem (tüm liman işçisi tabanlı) bir yıldan uzun bir süredir geliştirilmektedir ve hala konteynerde, yapılandırmalarda vb. Değişiklik yapmamız gereken alanlar buluyoruz.