Soru Docker kapsayıcılarında güvenlik güncelleştirmeleri nasıl kullanılır?


Uygulamaları sunuculara dağıtırken, uygulamanın kendisi ile birlikte ne ürettiği ile platformdan ne beklediği (işletim sistemi ve kurulu paketler) arasında bir ayrım vardır. Bunun bir noktası, platformun uygulamadan bağımsız olarak güncellenebilmesidir. Bu, örneğin, tüm uygulamanın yeniden oluşturulmadan, platform tarafından sağlanan paketlere güvenlik güncellemelerinin acilen uygulanması gerektiğinde yararlıdır.

Geleneksel olarak güvenlik güncellemeleri, paketlerin güncellenmiş sürümlerini işletim sistemine yüklemek için bir paket yöneticisi komutu yürütmek suretiyle uygulanmıştır (örneğin, RHEL'de "yum güncelleme"). Ancak, konteyner görüntülerinin esasen her ikisini de bir araya getirdiği Docker gibi konteyner teknolojisinin gelişiyle ve platform, bir sistemi güncel olarak kapsayıcı bir sistemle tutmanın kanonik yolu nedir? Ev sahibi ve kapsayıcıların, ana bilgisayar üzerinde güncellenmesi ve güncellenmesi gereken kendi bağımsız paket paketleri, kapların içindeki herhangi bir paketi güncelleştirmeyecektir. Docker konteynerlerinin özellikle öne çıkarıldığı RHEL 7'nin piyasaya sürülmesiyle, Redhat'in konteynerlerin güvenlik güncellemelerini ele almanın önerdiği yolu bilmek ilginç olurdu.

Seçeneklerden bazılarında düşünceler:

  • Paket yöneticisinin paketleri ana bilgisayarda güncellemesine izin vermek, kapların içindeki paketleri güncellemeyecektir.
  • Güncelleştirmeleri uygulamak için tüm kapsayıcı görüntüleri yeniden oluşturmak, uygulama ve platform arasındaki ayrımı kesmek gibi görünüyor (platformun güncellenmesi, Docker görüntülerini oluşturan uygulama oluşturma işlemine erişim gerektirir).
  • Çalışan konteynırların her birinin içinde manuel komutların çalıştırılması hantal gibi görünmektedir ve değişiklikler, uygulama serbest bırakma araçlarından bir sonraki sefer güncellendiğinde üzerine yazma riski vardır.

Yani bu yaklaşımların hiçbiri tatmin edici görünmüyor.


103
2017-07-08 21:54


Menşei


Şimdiye kadar gördüğüm en iyi fikir şu: Proje Atomik. Sanmıyorum oldukça ama asal zamanı için hazır. - Michael Hampton♦
Valko, hangi iş akışını yaptın? Uzun vadeli konteynerler (örneğin php-cgi'yi) çalıştırıyorum ve şu ana kadar bulduğum şey şu: docker pull debian/jessie görüntüyü güncellemek, sonra mevcut resimlerimi yeniden oluşturmak, daha sonra kapları durdurmak ve tekrar çalıştırmak (yeni görüntü ile). Oluşturduğum görüntüler, öncekilerle aynı ada sahip, bu yüzden başlangıç, komut dosyasıyla gerçekleştiriliyor. Sonra "adsız" görüntüleri kaldırırım. Daha iyi bir iş akışını takdir ediyorum. - miha
Miha: Yaptığım şeye benziyor. Temel olarak sürekli olarak yeni sürümler oluşturmanın bir parçası olarak tüm görselleri günceller ve yeniden oluşturur. Yeni görüntüleri kullanarak kapları yeniden başlatın. - Markus Hallmann
En iyi cevap İşte Johannes Ziemke'nin tam olarak ne söylediğini yapmak için ana komut satırlarını içeren bir betik olduğu için çok yardımcı oluyor: - Hudson Santos


Cevaplar:


Bir Docker resmi, uygulamayı ve "platform" ı paketler, bu doğrudur. Ancak genellikle görüntü, temel bir görüntü ve gerçek uygulamadan oluşur.

Güvenlik güncellemelerini ele almanın kurallı yolu, temel resmi güncellemek ve ardından uygulama resminizi yeniden oluşturmaktır.


43
2017-08-12 11:41



Teşekkürler, bu mantıklı geliyor. Sadece platformun güncellenmesini dilemek, böylece tüm uygulamanın yeniden paketlenmesini tetiklememekti (örneğin, tek bir temel imajın güncellenmesi nedeniyle 100 farklı uygulama görüntüsünü yeniden inşa etmeyi düşünün). Ama belki de bu, Docker'ın tek bir görüntü içinde her şeyi bir araya getirme felsefesiyle kaçınılmazdır. - Markus Hallmann
@ValkoSipuli Her zaman işlemi otomatikleştirmek için bir komut dosyası yazabilirsiniz. - dsljanus
Neden yükseltme-yükseltme, dnf yükseltme, pacman -syu, vb konteynır içinde eşdeğer değil? Bunu yapan bir kabuk betiği bile oluşturabilirsiniz. ve sonra uygulamayı çalıştırır, daha sonra kapsayıcı giriş noktası olarak kullanın, böylece kap başlatıldığında / yeniden başlatıldığında tüm paketlerini yükseltir. - Arthur Kay
@ArthurKay İki nedenden dolayı: 1) Konteynır büyüklüğünü havaya uçurursunuz, çünkü güncellenmiş tüm paketler, güncel olmayan paketi görüntüde tutarken kap katmanına eklenecektir. 2) (kapsayıcı) görüntülerin en büyük avantajını yener: Çalıştırdığınız görüntü, çalışma zamanında paketleri değiştirdiğinizden, yaptığınız / sınamadığınızla aynı değildir. - Johannes 'fish' Ziemke
Anlamadığım bir şey var: Bir şirket bir docker konteyneri olarak sevk edilen bir yazılım parçasını satın alıyorsanız, bir güvenlik sorunu ortaya çıktığında yazılımın üreticisinin uygulama paketini yeniden oluşturmasını beklemeniz gerekiyor mu? ? Açık kırılganlıkların kontrolünü bu şekilde hangi şirket bırakacak? - Sentenza


Kapların hafif ve değiştirilebilir olması gerekiyordu. Kapsayıcınızda bir güvenlik sorunu varsa, yeni kabı yamayacak ve yeni kapsayıcıyı dağıtacak bir kapsayıcı sürümünü yeniden oluşturursunuz. (birçok kapsayıcı, bağımlılıklarını kurmak için apt-get gibi standart paket yönetim araçlarını kullanan standart bir temel görüntü kullanır, yeniden yapılandırmalar depolardan gelen güncellemeleri çeker)

Konteynırların içine serilebilirken, bu iyi ölçeklenmeyecek.


6
2017-10-03 19:44





Bu, SUSE Enterprise Linux'ta zypper-docker kullanarak otomatik olarak işlenir (1)

SUSE / zypper-docker

Docker Hızlı Başlangıç


1
2018-05-08 17:05





Her şeyden önce, geleneksel olarak geçmişte yaptığınız güncellemelerin çoğu, kapsayıcının içinde olmayacaktır. Kap, geçmişte görmeye alışkın olduğunuz tam dosya sisteminin oldukça hafif ve küçük bir alt kümesi olmalıdır. Güncellemek zorunda olduğunuz paketler DockerFile'ınızın bir parçası olacak ve DockerFile'a sahip olduğunuzdan, güncellemeye ihtiyaç duyan paketleri ve konteyner kimliklerini takip edebilmeniz gerekir. Kısa bir süre sonra piyasaya sürülecek olan Cloudstein Kullanıcı Arabirimi, bu DockerFile bileşenlerini sizin için takip eder ve böylece konteynerleri için en uygun güncelleme planını oluşturabilir. Bu yardımcı olur umarım


0
2017-07-08 23:23