Docker a aktualizacje systemowe - ogromne nakłady czsaowe?

0

Moje obecne rozumienie sytuacji:

  • Kontenery Dockera są immutable - wyjąwszy partycje danych nie wprowadza się zmian w raz opublikowanym kontenerze
  • W szczególności za anti-pattern uważa się robienie np. apt-get update && apt-get upgrade -qqy wewnątrz kontenera
  • Zamiast powyższego w sytuacji, gdy do upstreamowego oprogramowania używanego wewnątrz naszego kontenera zostaną opublikowane łatki buduje się nowy kontener zawierający nasz program + zaktualizowane oprogramowanie upstreamowe, testuje się to, jeśli wszystko działa OK to wdraża się ten nowy kontener zamiast starego

Z tego wynika, że za każdym razem, gdy do np takiego ubuntu pojawią się aktualizacje, trzeba przebudowywać kontenery nawet jeśli nie ma żadnej innej tego przyczyny?

Czy to nie zajmuje (zbyt) wielu roboczogodzin?

Aktualizacje do ubuntu pojawiają się dość często - co parę dni co najmniej. Zakładam, że:

  • Łatki bezpieczeństwa powinny zostać wdrożone możliwie szybko, najchętniej natychmiast po opublikowaniu, inaczej wystawiamy się na ew. zmasowane ataki;
  • Ubuntu w wersji LTS powinno być stabilne, z założenia nie powinno być tak, by aktualizacje systemowe coś nam rozwaliły - to samo z Windowsem.

Wobec wszystkiego powyższego sądziłbym, że aktualizacje powinny być ustawione tak, by odbywały się automatycznie, najchętniej bez dodatkowych nakładów czasowych i bez downtime'u (nie wiem, imaginuję sobie jakieś rozwiązanie w tym stylu, że gdy mamy dwie maszyny, na których uruchomiony jest ten sam serwis i mamy do wgrania łatki do OSa i/lub innego upsteamowego oprogramowania, to automatycznie odłączamy jedną maszynę, wgrywamy łatki, maszyna się restartuje, podłączamy ją a odłączamy drugą, aktualizujemy drugą)

A teraz dowiaduję się, że w state-of-the-art-owym rozwiązaniu Dockerowym tak się absolutnie nie robi? Nie rozumiem?

6
YetAnohterone napisał(a):

Moje obecne rozumienie sytuacji:

  • Kontenery Dockera są immutable - wyjąwszy partycje danych nie wprowadza się zmian w raz opublikowanym kontenerze

Hm, z tego co wiem w dobrym kontenerze nie ma czegoś takiego jak partycja danych. Dane są w podmontowanym katalogu żeby przetrwały restart

Z tego wynika, że za każdym razem, gdy do np takiego ubuntu pojawią się aktualizacje, trzeba przebudowywać kontenery nawet jeśli nie ma żadnej innej tego przyczyny?

Zwykle w kontenerach nie używa się ubuntu tylko Alpine bo najmniejszy i kontenery się szybciej budują. (A przynajmniej tak słyszałem)

Reszta tego co piszesz jest prawdą. Kontenerów się nie modyfikuje. Ubija je się i ściąga się nowe w nowszych wersjach. Jeśli to dla ciebie problem to może w ogóle nie potrzebujesz kontenerów?

Poza tym jak zrobisz apt-get update && apt-get upgrade -qq to nie masz żadnej pewności że twoja aplikacja w kontenerze dalej działa poprawnie. Taki zupgradowany kontener powinien ponownie przejść wszystkie testy

0
YetAnohterone napisał(a):

A teraz dowiaduję się, że w state-of-the-art-owym rozwiązaniu Dockerowym tak się absolutnie nie robi? Nie rozumiem?

Zadaj pytanie bo nie wiemy czego dotyczy? czego sie nie robi ? nie robi sie apt upgrade czy nie robi se podmiany kontenerow czy nie robi sie automatycznych aktualizacji o co pytasz ?

0

@KamilAdam:

Poza tym jak zrobisz apt-get update && apt-get upgrade -qq to nie masz żadnej pewności że twoja aplikacja w kontenerze dalej działa poprawnie.

No ale dlaczego? Jak pisałem, Ubuntu LTS powinno być stabilne? Aktualizacje systemowe nie powinny prowadzić do tego, że oprogramowanie zainstalowane w systemie nie działa.

Podbicie wersji Ubuntu to co innego, przy przejściu z np. 18.04 LTS do 20.04 LTS już bym rozumiał konieczność przepakowania naszego oprogramowania. Ale to się dzieje istotnie rzadziej.

Taki zupgradowany kontener powinien ponownie przejść wszystkie testy

Co zabiera roboczogodziny za każdym razem, gdy do Ubuntu są wydane aktualizacje.

@chomikowski:

Zadaj pytanie bo nie wiemy czego dotyczy?

Dlaczego nie aktualizuje się oprogramowania w kontenerach, tylko buduje nowe kontenery zawierające zaktualizowane upstreamowe oprogramowanie? Czy to nie zabiera wielu roboczogodzin za każdym razem, gdy pojawiają się aktualizacje upstreamowego opgrogramowania?

3
  1. Tak jak ktoś tu napisał, zwykle korzysta się z minimalistycznych obrazów opartych np. o alpine.
  2. To, że masz aktualizację bezpieczeństwa w takim systemie to jeszcze nie znaczy, że oddziaływuje ona akurat na nginxa, z którego korzystasz.
  3. Często taki kontener (np. do podawania frontendu) to gotowiec (np. alpine + nginx) i wtedy nic nie budujesz tylko ubijasz kontener, zmieniasz cyferkę w docker-compose i uruchamiasz kontener (obraz jest zaciągany z Docker Hub).
  4. Jeżeli już zachodzi konieczność budowy obrazu to zazwyczaj tylko dokładasz warstwy do już istniejącego obrazu pobranego z Docker Hub, więc budujesz tylko cząstkę.
    Upgrade systemu niby spoko i działa to z każdym wydaniem lepiej i bezpieczniej, ale pomyśl sobie ile można skopać jeżeli masz kilka aplikacji na jednym serwerze działających na różnych wersjach środowiska uruchomieniowego i podczas upgrade coś nie zadziała tak jak powinno. W dockerze wracasz do poprzedniej wersji w kilka sekund, a prostowanie bibliotek i innych rzeczy w czystym systemie potrafi przyprawić siwych włosów.
1
YetAnohterone napisał(a):

@KamilAdam:

Poza tym jak zrobisz apt-get update && apt-get upgrade -qq to nie masz żadnej pewności że twoja aplikacja w kontenerze dalej działa poprawnie.

No ale dlaczego? Jak pisałem, Ubuntu LTS powinno być stabilne?

Zgoda, powinny. A dasz sobie za to rękę uciąć?

Aktualizacje systemowe nie powinny prowadzić do tego, że oprogramowanie zainstalowane w systemie nie działa.

Zgoda, nie powinny. A dasz sobie za to rękę uciąć?

Co zabiera roboczogodziny za każdym razem, gdy do Ubuntu są wydane aktualizacje.

Nie ma czegoś takiego jak robogodziny za aktualizację ubuntu. Zmienia się wersję ubuntu wersję ubuntu w dockerfile. Wysyła się zmiany do repo i pozwala się jenkinsowi to zbudować. W miedzyczasie robi się kolejne taski i czasem zerka się czy już się zbudowało. A jak się zbudowało to przechodzi testy automatycznie i potem może być wdrożenie czy przesłanie gdzieś dalej.

Nie chcę być wredny, ale twoja opowieść brzmi jakbyś za każdym razem, gdy budujesz nowego dockera musiał na to patrzeć jak się buduje i nie mógł robić nic innego

0
KamilAdam napisał(a):

A jak się zbudowało to przechodzi testy automatycznie i potem może być wdrożenie czy przesłanie gdzieś dalej.

Rozumiem, że testy automatyczne mają wystarczyć do stwierdzenia, że działa jak należy? Nie trzeba ręcznie uruchamiać aplikacji i sprawdzać, czy działa?

Z tego, co się orientuję, z założenia testy automatyczne mają testować moją aplikację. Antywzorcem jest pisanie testów automatycznych, które sprawdzają, czy działa jak należy framework, z którego korzystamy, runtime, na którym uruchamiamy aplikację, apache/nginx, który przekazuje requesty do aplikacji i odsyła odpowiedzi, OS, który zapewnia niskopoziomowe sockety, z których wszystko powyższe korzysta, itp, itd.

Tymczasem obawa przed apt-get update && apt-get upgrade polega dokładnie na tym, że boimy się, że to właśnie runtime, apache/nginx, OS, a nawet framework (jeśli został zainstalowany z apta) może przestać działać.

Rozumowałem więc, że wobec tego jest wymóg przeprowadzenia ręcznych (a więc zabierających czas) testów za każdym razem, gdy pojawiają się aktualizacje systemowe?

0
YetAnohterone napisał(a):
KamilAdam napisał(a):

A jak się zbudowało to przechodzi testy automatycznie i potem może być wdrożenie czy przesłanie gdzieś dalej.

Rozumiem, że testy automatyczne mają wystarczyć do stwierdzenia, że działa jak należy? Nie trzeba ręcznie uruchamiać aplikacji i sprawdzać, czy działa?

Z tego, co się orientuję, z założenia testy automatyczne mają testować moją aplikację. Antywzorcem jest pisanie testów automatycznych, które sprawdzają, czy działa jak należy framework, z którego korzystamy, runtime, na którym uruchamiamy aplikację, apache/nginx, który przekazuje requesty do aplikacji i odsyła odpowiedzi, OS, który zapewnia niskopoziomowe sockety, z których wszystko powyższe korzysta, itp, itd.

No ale jak testujesz swoją aplikację testami integracyjnymi/akceptacyjnymi to przecież że testujesz przy okazji fragmenty frameworka które używasz oraz fragmenty systemu operacyjnego którego używasz i te wszystkie zależności które chcesz podnosić za pomocą apt. Oczywiście kolejnym etapem może być ręczne przeklikanie. Tego przecież nikt nie broni

4
YetAnohterone napisał(a):

Z tego, co się orientuję, z założenia testy automatyczne mają testować moją aplikację. Antywzorcem jest pisanie testów automatycznych, które sprawdzają, czy działa jak należy framework, z którego korzystamy, runtime, na którym uruchamiamy aplikację, apache/nginx, który przekazuje requesty do aplikacji i odsyła odpowiedzi, OS, który zapewnia niskopoziomowe sockety, z których wszystko powyższe korzysta, itp, itd.

Mylisz chyba testy jednostkowe z integracyjnymi/E2E. Jednostkowo nie ma sensu testować cudzego kodu (frameworka, biblioteki). A integracyjnie/E2E testujesz aplikacje, czy cały system, i nie da się tego zrobić bez rzeczywistego uruchamiania go. Test sprawdziający endpointy Twojego API, mimo że jest hostowane na jakimś serwerze, za jakimś nginxem, na jakimś systemie operacyjnym nadal testuje Twoje API, a nie infrastrukturę - mimo, że z niej korzysta.

Tymczasem obawa przed apt-get update && apt-get upgrade polega dokładnie na tym, że boimy się, że to właśnie runtime, apache/nginx, OS, a nawet framework (jeśli został zainstalowany z apta) może przestać działać.

Tak, bo może. To są przecież zewnętrzne elementy nad którymi nie masz kontroli.

Rozumowałem więc, że wobec tego jest wymóg przeprowadzenia ręcznych (a więc zabierających czas) testów za każdym razem, gdy pojawiają się aktualizacje systemowe?

Ręcznie testuje się tyko to, czego nie da się przetestować automatycznie.

0

Realistycznie: Jak często (zakładając stabilną dystrybucję, taką jak Ubuntu LTS) apt-get update && apt-get upgrade (lub analogiczna komenda) prowadzi do problemów?

Raz na 5 lat? 2 lata? pół roku? miesiąc?

1

Budujesz kontener, wrzucasz do repozytorium artefaktów i można w każdym momencie postawić go w dowolnym miejscu i mieć pewność, ze to ten sam kontener. Jeżeli zrobisz to tak, że co jakiś czas władujesz się do jego wnętrza i puścić jakiś apt-get update to wynikowo nie masz pojęcia co jest w twoim kontenerze na produkcji. Przykład:

  • robisz sobie nową aplikację, ładujesz ją w kontener i wrzucasz na środowisko stage
  • podczas testów akceptacyjnych wychodzijakaś poprawka błędu 0 stage, więc robisz upgrade wewnątrz działającego kontenera
  • testy przechodzą, więc łubudu na produkcję, ale bez poprawek, które zrobiłeś na stage

Drugi przykład - restart kontenera na dowolnym środowisku - wszystkie poprawki idą się paść na łączce, bo po restarcie wracasz do stanu pierwotnego.

YetAnohterone napisał(a):

Raz na 5 lat? 2 lata? pół roku? miesiąc?

Co za różnica? Jak można zrobić dobrze i przetestować na konkretnym kontenerze, co jest głównym profitem z konteneryzacji, to po co robić źle i się jeszcze ty, niepotrzebnie zmęczyć, bo przecież masz gotowe obrazy z aktualizacjami systemu, które wystarczy wskazać w dockerfile.

0

Hmm, wobec tego zapytam inaczej.

Czy można / czy praktykuje się jakoś automatyzację podnoszenia obrazów systemu (i puszczenia tego na testy i jeśli przechodzą to na produkcję)? czy zawsze się ręcznie edytuje dockerfile?

3

Nie jestem ekspertem w temacie, ale się wypowiem :)

Ten apt-get upgrade przy starcie kontenera wydłuża start kontenera (fanfary :) oczywista oczywistość). Przy automatycznym skalowaniu i nagłych skokach ruchu to może być znaczący problem.

Ponadto apt-get update && apt-get upgrade nie zaktualizuje zależności mojego projektu, bo przecież w moim programie nie ograniczam się tylko i wyłącznie do podprogramów, bibliotek i interfejsów wbudowanych w mój system. Jeśli np. używam frameworka, który jest dziurawy, to apt-get nic z nim nie zrobi.

2

Każda aktualizacja nie jest bezpieczna nie ważne czego. Zawsze jest to zmiana nad która nie masz kontroli i trzeba przetestowac wszystko od 0.
Dom też się nie pali co miesiąc a jakos wszyscy ubezpieczają od pożaru.

1 użytkowników online, w tym zalogowanych: 0, gości: 1