Bir uygulamayı dağıtmak için bir kapsayıcı gibi bir deb paketini kullanmanın sakıncaları var mı?


15

Ekibim şu anda Nodejs uygulamamızı Docker gibi bir kapta çalıştırmak yerine bir deb paketi olarak dağıtmamız gerekip gerekmediğine karar vermeye çalışıyor.

Bu fikri burada bu blogu okuyarak aldım, bu da önceden mevcut bir python uygulaması için bir deb paketi kullanmak için bazı iyi argümanlar yapar. Bu blogdan bize hitap eden ana nokta, Docker ekosistemini (bağlantı noktası paylaşımı, izinler, Docker Görüntülerinin barındırılması vb.)

"Orijinal konteynırlar olarak dep-paketleri", liman çatışmalarıyla ilgili endişelerin olmadığı ve tüm bağımlılıkların sanal bir ortamda tutulduğu küçük hizmetler için çok mantıklı görünüyor.

Bununla birlikte, benim içgüdüm, deb paketleri iyi bir uyum olsaydı, daha yaygın olacağını ve docker'ın dile özgü bir çözüm olarak ilan edileceğini söylüyor. Docker gibi tam bir sistem kullanmak yerine, hizmetlerimizi dağıtmak için deb paketleri gibi bir şey kullanmanın bir sakıncası var mı?


1
Bunlar birbirini dışlayan değil, deb paketinizi bir Docker kapsayıcısına dağıtabilirsiniz. Belki de Microservices vs Virtual Machines hakkında sormalısın?
Chris

Hmm, hayır bu özellikle docker konteyneri yerine bir deb-paketi kullanmakla ilgili. Blogdan soruya daha fazla bilgi ekleyeceğim.
avi

3
"Çekirdeği daha hızlı kod göndermek için yükseltmenin aşırı bir çözüm olduğunu hissettik." bu bana yanlış geliyor. daha hızlı gönderim kodundan daha önemli ne olabilir?
Assaf Lavie

Yanıtlar:


16

İlk olarak, Docker bazen görülen ve bir olarak kullanılır geçici paketleme sisteminde, aslında tamamen farklı bir sorunu çözer: Docker hakkındadır çalışan programlar. Docker sistemi tanımlamak için izin verir hizmetleri edilebilir ölçekli iradesiyle ve kontrol etmek sürüleri konteynerlerin. Debian paketleri programları yüklemek içindir ve yazılım sürümleri arasındaki bağımlılıkları kaldırabilirler . Liman işçisi kesinlikle bir iniş paketleme sistemi olarak nitelendirilmemektedir: her “paket” in sadece bir bağımlılığı olabilir, sistemin “özyinelemeli derleme” seçeneği yoktur ve karmaşık sürüm kısıtlamalarını desteklemez!

Olası bir cevap , uygulamanız için bir Debian paketi yazmak istiyorsanız, uygulamanızı dağıtmak için Docker'ı da kullanabilirsiniz . Bu, aşağıdaki apt_setup.shgibi görünen bir yapılandırma komut dosyası ile gerçekleştirilebilir.

apt-key add - <<EOF
-----BEGIN PGP PUBLIC KEY BLOCK-----
<YOUR RELEASE OFFICER PGP KEY GOES HERE>
EOF

cat >> /etc/apt/sources.list <<EOF
deb https://my.organisation.org/repo debian-jessie main
apt-get update -y
apt-get upgrade -y
EOF

ve bir Dockerfileçizgi boyunca

ADD apt_setup.sh /root
RUN sh -ex /root/apt_setup.sh && rm /root/apt_setup.sh
RUN apt-get install -y my-node-js-package

(Özel durumunuzda, düğüm kaynağı depolarını ve apt-transport-https gibi bazı yardımcı paketleri apt_setup.shekleyerek daha karmaşık olurdu .)

Bu nedenle Debian paketleri ve Docker'ı aynı anda kullanmak gerçekten mümkün …

Bağırsaklarım […] bana deb paketleri iyi bir uyum olsaydı daha yaygın olacağını söylüyor

Bu, Docker'ın neden bir ad hoc ambalaj sistemi olarak popüler olduğunu kanıtlamasına neden olan doğru bir aksaklıktır , ancak bir tane olması amaçlanmamıştır. (Yukarıyı görmek.)

Belirli bir dağıtımın “resmi” paketleme sistemi, diğer bilgisayarların arasında bazı bilgi işlem ortamlarına yazılım yükleme olasılığıdır. Gibi toplum özgü paket yöneticileri gibi pek çok diğer kaynaklar vardır NPM veya opam, gibi liman ağaçları pkgsrc ve düz kaynak kod dağıtımı. Bu açıdan Docker'ı geçici bir paketleme sistemi olarak başarısını anlamak kolaydır :

  • Docker özellikleri bir kabuk komut dosyasına çok yakın ve nereden gelirse gelsin, kabuğu kullanarak yazılım yüklüyoruz.

  • Docker , ürettiği artefaktları barındıran “yerleşik” (ücretli) bir hizmet olan Docker Hub'a sahiptir .

Şimdi Debian paketlerinin Docker görüntüleri üzerindeki bir paket sistemi olarak gücü nedir? Kurulum sırasında bağımlılıklar üzerinde sıkı kontrol. (Yükseltme ve eski sürüme geçme olasılığı da mevcuttur, ancak desenini uyguluyorsak pratik bir önemi yoktur .)

Sonuç

Tek bir sürümde (SaaS için tipik olan) dağıtılan tek bir ürününüz varsa, sürüm yönetimi ihtiyaçlarınız çok basittir ve Docker'ı geçici bir paket yöneticisi olarak kullanmanın herhangi bir dezavantajı olmamalıdır. Tek bir ürünün veya birkaç ürünün çeşitli sürümleriyle çalışırken, çözmeniz gereken sürüm kısıtlamaları sorununun karmaşıklığı artar ve bunun için Debian paketleri veya bazı yapılandırma yönetim sistemi olabilecek uygun bir araca ihtiyacınız vardır. farklı kökenlerden karıştırma yazılımı.


6

Evet, sakıncaları var.

Bir .deb paketiyle aynı uygulamanın aynı ana bilgisayarda iki sürümüne sahip olamazsınız. Uygulamanız örneğin nodejs'e bağlıysa, mevcut dağıtım paketlerine güvenmeniz gerekecek, ya dağıtım sürümüne bağlı kalacaksınız ya da kendiniz yüklemeniz gerekecek.

Şimdi birden çok uygulamayı aynı ana bilgisayarda barındırmak istediğinizde, aynı şeye bağlı olduklarında (burada nodejs'i burada tutalım) iki farklı versiyonda çok hızlı bir şekilde duvara çarpacaksınız.

Docker'ın temel amacı, her uygulamayı barındırma sisteminden ve aynı ana bilgisayardaki diğer uygulamalardan ayırmaktır. Bu izolasyonu yapmak için iki nedeni vardır: 1. uygulamanın ana bilgisayar devralmak veya başka bir uygulama etki edebilmesi tehlikesini önlemek için 2. uygulamaya kesin bağımlılıkları vermek ve bir sistem güncellemesi veya başka bir uygulama tarafından etkilenmesini önlemek için bağımlılık.


Uh, hiç kimse dağıtımın yakut, düğüm, python vb. Kullanılmasını önermedi. Bunların paketlerini de yaparsınız ve / opt içine koyarsınız. Paketleriniz bunlara bağlı olacaktır. Uygulamanızın deb paketleri ile yüklü birden fazla sürümüne sahip olabilirsiniz, Debian'ın kendisinde birçok örnek vardır. Aslında, birden fazla sürümü yönetmenin en iyi yoludur. Bu cevap tamamen yanlış.
figtrap

1
@figtrap TAMAM resmi elastik.co repo'yu kullanmaya çalışın ve elasticsearch v. 2.3 ve v.5.6'yı aynı anda kurun. Açıkladığınız şey, uygun .deb paketleri yapıyorsanız iki farklı paket yüklemek ve ağır ayar yapmaktır. Bu, yığınların derinliklerinde bir yerde iki farklı libc sürümüne ihtiyacınız olduğunda, yapı bağımlılıkları ve bakım açısından bir kabus.
Tensibai

5

Uygulamaları yüklemek için bir Debian (veya RedHat) paketi doğru bir şekilde yapıldığında iyi bir uygulama olmuştur. Paketler, nadiren değiştirilen uygulamaları dağıtmak amacıyla kullanılır. Debian paketleri, sürüm yönetimi, bağımlılık yönetimi, kurulum öncesi ve sonrası komut dosyaları gibi bazı ek yükleri içerir ...

Birçok durumda, bazı eski sürümlerden yeni bir sürüme yükseltme, komut dosyalarının dikkatli bir şekilde yazılmasını, sürümdeki ayrıntılara dikkat etmeyi vb. Gerektirir. Çünkü mevcut durumu değiştirmek çok zordur. Mevcut durumu hiçbir şey değiştirmeden yeni bir durumla değiştirmek çok daha kolay olurdu.

Her dağıtımda yapılandırmanızı veya bağımlılıklarınızı veya uygulamanızı tamamen değiştirmeye karar verdiğinizde, daha kolay ve daha az hataya eğilimlidir. Çoğu kuruluş (eskiden) tamamen yeni bir VM veya bulut örneğine geçer. Bu, paketin yüklenmesinin "temiz" bir sunucuda yapılacağı ve sunucudaki dosyaların ve yapılandırmanın değiştirilmesinin artık sorun olmadığı anlamına gelir.

Paketler oluşturan ve mutasyonlardaki yanlışlığı ve karmaşıklığı anlamayan geliştiriciler, sonuç olarak oldukça zorluklar yaşadı.

VM'leri değiştirmek, ihtiyacınız olan tek şey bir uygulamayı değiştirmek olduğunda en uygunudur, bu nedenle hafif kaplar bir cevap olarak tanıtıldı. Docker'ı (veya başka bir LWC) kullanarak sunucunun kendisini değiştirmeden tüm bağımlılıklar dahil olmak üzere kullanıcı tabanını değiştirebilirsiniz. Aynı uygulamanın farklı bağımlılıklara sahip birden çok sürümünü aynı sunucuda barındırabilir ve yalnızca gelen ağ trafiğini yükseltme sırasında değiştirebilirsiniz. Ağ trafiğini geri dönüşte (mavi-yeşil) değiştirmenin yanı sıra, dağıtımları paketler aracılığıyla yönetme durumunda oldukça zor olan bir şey.

Kapsayıcılar, tüm uygulama kodunu, bağımlılıkları ve yapılandırmayı bir görüntüye bir araya getirmenin bir yolunu sunar. Bu görüntü, geleneksel işletim sistemi paketlerinden çok daha iyi olmasını sağlayan birden fazla özelliğe sahiptir. Örneğin, sürüm oluşturmayı sağlayan etiketler içerir, ancak yerden tasarruf sağlayan katmanlar da vardır. Bir kayıt defteri kullanarak bu görüntüleri sunuculara ve geliştirme ortamlarına göndermenin kolay bir yoludur. Ve bu görüntüler neredeyse aynı şekilde herhangi bir ortamda ve herhangi bir sunucuda kapsayıcı olarak yürütülebilir. Bu, geliştiricinin dizüstü bilgisayarını ve üretim ortamını içerir. Yine, VM'ler ve / veya yazılımın paket tabanlı sürümleri ile çok daha zor olan bir şey. Aynı görüntünün geliştiricinin dizüstü bilgisayarında test edilmesi ve aynı bitlerin ve baytların üretimde kalması "


Şimdiye kadar, "makinemde çalışıyor" ifadesinin "makinemde çalışıyor, ancak garip olarak Docker'da davrandığını" değiştirdiğini görüyorum.
Matt Moran

1

Özellikle Docker'ın görüntü paketleme parçasından bahsetmişken, konteyner çalışma zamanından değil birkaç küçük bit var. En büyüğü, bir Docker görüntüsünün daha çok bir chroot'a benzemesi, yani bir sistem paketi sizin yapmadığınız dinamik bağlantıları alabilirken, kullanılan her dosyanın görüntüye açıkça dahil edilmesi gerektiğinden, paylaşılan sistem durumuna bağlı olarak yanlışlıkla engellenmeniz anlamına gelir. diğer paketlerle daha fazla iç içe geçmeyi bekler ya da başka türlü yapar. Bu, karmaşık C bağımlılıklarının sizin haberiniz olmadan yüklenmesine neden olabilir, örneğin OpenSSL. Ayrıca deb paketleri kullanıldığında, Docker'ın depolama sistemindeki paylaşılan bitlerin çoğaltılmaz. Bazıları için bu iyi bir şey, daha iyi G / Ç performansı ve daha az hareketli parça olabilir, ancak diğerleri için bu bir sorun olabilir.

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.