Podczas wdrażania aplikacji na serwerach zwykle występuje oddzielenie między tym, co aplikacja łączy ze sobą, a tym, czego oczekuje od platformy (system operacyjny i zainstalowane pakiety). Jednym z nich jest to, że platformę można aktualizować niezależnie od aplikacji. Jest to przydatne na przykład, gdy aktualizacje zabezpieczeń muszą być pilnie stosowane do pakietów dostarczanych przez platformę bez przebudowywania całej aplikacji.
Tradycyjnie aktualizacje zabezpieczeń były stosowane po prostu przez wykonanie polecenia menedżera pakietów, aby zainstalować zaktualizowane wersje pakietów w systemie operacyjnym (na przykład „yum update” na RHEL). Ale wraz z pojawieniem się technologii kontenerów, takich jak Docker, w której obrazy kontenerów zasadniczo obejmują zarówno aplikację, jak i platformę, jaki jest kanoniczny sposób aktualizowania systemu z kontenerami? Zarówno host, jak i kontenery mają własne, niezależne zestawy pakietów, które wymagają aktualizacji, a aktualizacja na hoście nie aktualizuje żadnych pakietów w kontenerach. Wraz z wydaniem RHEL 7, w którym szczególnie polecane są kontenery Docker, ciekawie byłoby usłyszeć zalecany przez Redhat sposób obsługi aktualizacji zabezpieczeń kontenerów.
Myśli na temat kilku opcji:
- Zezwolenie menedżerowi pakietów na aktualizację pakietów na hoście nie zaktualizuje pakietów w kontenerach.
- Konieczność ponownego wygenerowania wszystkich obrazów kontenera w celu zastosowania aktualizacji wydaje się przerywać separację między aplikacją a platformą (aktualizacja platformy wymaga dostępu do procesu kompilacji aplikacji, który generuje obrazy Docker).
- Uruchamianie ręcznych poleceń w każdym z uruchomionych kontenerów wydaje się kłopotliwe, a zmiany mogą zostać zastąpione przy następnej aktualizacji kontenerów z artefaktów wydania aplikacji.
Żadne z tych podejść nie wydaje się zadowalające.
docker pull debian/jessiezaktualizować obraz, następnie odbudować moje istniejące obrazy, a następnie zatrzymać pojemniki i uruchomić je ponownie ( z nowym obrazem). Obrazy, które buduję, mają taką samą nazwę jak poprzednie, więc uruchamianie odbywa się za pomocą skryptu. Następnie usuwam „nienazwane” obrazy. Z pewnością doceniłbym lepszy przepływ pracy.Odpowiedzi:
Obraz Dockera zawiera aplikację i „platformę”, to prawda. Ale zwykle obraz składa się z obrazu podstawowego i rzeczywistej aplikacji.
Tak więc kanonicznym sposobem obsługi aktualizacji zabezpieczeń jest aktualizacja obrazu podstawowego, a następnie odbudowanie obrazu aplikacji.
źródło
Pojemniki powinny być lekkie i wymienne. Jeśli Twój kontener ma problem z bezpieczeństwem, odbuduj wersję łatanego kontenera i wdróż nowy kontener. (wiele kontenerów używa standardowego obrazu podstawowego, który używa standardowych narzędzi do zarządzania pakietami, takich jak apt-get, aby zainstalować swoje zależności, przebudowanie spowoduje pobranie aktualizacji z repozytoriów)
Chociaż można wstawiać wewnątrz pojemników, nie będzie to dobrze skalować.
źródło
Jest to obsługiwane automatycznie w SUSE Enterprise Linux za pomocą zypper-docker (1)
SUSE / zypper-docker
Docker Szybki start
źródło
Przede wszystkim wiele aktualizacji, które tradycyjnie uruchamiano w przeszłości, po prostu nie będzie w samym pojemniku. Kontener powinien być dość lekkim i małym podzbiorem pełnego systemu plików, do którego przyzwyczaiłeś się w przeszłości. Pakiety, które powinieneś zaktualizować, to te, które są częścią DockerFile, a ponieważ masz DockerFile, powinieneś być w stanie śledzić te pakiety i identyfikatory kontenerów, które wymagają aktualizacji. Wkrótce zostanie udostępniony interfejs użytkownika Cloudstein, który śledzi składniki DockerFile, dzięki czemu można zbudować schemat aktualizacji najlepiej pasujący do ich pojemników. Mam nadzieję że to pomoże
źródło
ogólnie jest nawet gorszy niż trzy opcje, które podałeś. Większość obrazów dokerów nie ma wbudowanych menedżerów pakietów, dlatego nie można po prostu powlekać obrazu dokera i wydać aktualizacji. Będziesz musiał odbudować lub ponownie uzyskać obraz dokera.
Fakt, że musisz przebudować lub oczekujesz od innych, aby przebudowali łaty bezpieczeństwa, wydaje się w większości przypadków nieuzasadniony.
Zastanawiałem się nad wdrożeniem sonarr i radarr w kontenerach dokerów, ale wiedząc, że nie będą otrzymywać regularnych aktualizacji bezpieczeństwa, które otrzymam mój kontener, jest przełomowy. Zarządzanie aktualizacjami zabezpieczeń dla mojego kontenera jest dość kłopotliwe bez konieczności ręcznego stosowania aktualizacji zabezpieczeń do każdego obrazu dokera osobno.
źródło