Czy należy używać plików Docker lub obrazów zatwierdzonych?

Question

Jestem nieco zdezorientowany tymi dwiema opcjami. Wydają się być spokrewnieni. Jednak nie są one zgodne.

Na przykład, wydaje się, że używanie Dockerfiles oznacza, że ​​naprawdę nie powinieneś angażować się w obrazy, ponieważ naprawdę powinieneś po prostu śledzić Dockerfile in git i wprowadzać w nim zmiany. Wtedy nie ma dwuznaczności co do autorytatywności.

Jednak obrazy wydają się naprawdę ładne. Jest tak wspaniały, że możesz po prostu zmodyfikować kontener bezpośrednio i oznaczyć zmiany, aby utworzyć kolejny obraz. Rozumiem, że można nawet uzyskać coś w rodzaju diff systemu plików z historii zmian obrazu. Niesamowite. Ale wtedy nie powinieneś używać Dockerfiles. W przeciwnym razie, jeśli dokonasz zatwierdzenia obrazu, będziesz musiał wrócić do pliku Docker i wprowadzić pewne zmiany, które reprezentują to, co zrobiłeś.

Więc jestem rozdarty. Uwielbiam pomysł zatwierdzania obrazów: nie musisz reprezentować swojego stanu obrazu w pliku Dockerfile - możesz go po prostu śledzić bezpośrednio. Ale nie podoba mi się rezygnacja z pomysłu na jakiś plik manifestu, który daje szybki przegląd tego, co jest na obrazie. Jest też niepokojące widzieć dwie funkcje w tym samym pakiecie oprogramowania, które wydają się być niezgodne.

Czy ktoś ma jakieś przemyślenia na ten temat? Czy korzystanie z zatwierdzania obrazów jest uważane za złą praktykę? A może powinienem porzucić moje przywiązanie do plików manifestu z moich dni lalkowych? Co powinienem zrobić?

Aktualizacja:

Do wszystkich tych, którzy uważają, że jest to pytanie na podstawie opinii, nie jestem taki pewien. Jest w tym trochę subiektywnych cech, ale myślę, że to głównie obiektywne pytanie. Ponadto uważam, że dobra dyskusja na ten temat będzie miała charakter informacyjny.

Mam nadzieję, że każdy, kto przeczyta ten post, lepiej zrozumie, w jaki sposób pliki Dockerfiles i obrazy są ze sobą powiązane.

Aktualizacja - 18.07.2017:

Właśnie niedawno odkryto legalnego wykorzystania za obraz zobowiązuje. Właśnie utworzyliśmy rurociąg CI w naszej firmie i podczas jednego z etapów testów nasze testy aplikacji są przeprowadzane wewnątrz kontenera. Musimy pobrać wyniki pokrycia z opuszczonego kontenera po wygenerowaniu go przez proces testowego (w systemie plików kontenera) i kontener przestał działać. W tym celu korzystamy z zatwierdzania obrazów, zatwierdzając zatrzymany kontener, aby utworzyć nowy obraz, a następnie uruchamiając polecenia, które wyświetlają i zrzucają plik pokrycia na standardowe wyjście. Więc jest to wygodne. Poza tym bardzo konkretnym przypadkiem używamy Dockerfiles do definiowania naszych środowisk.

Answer 1

Dockerfiles to narzędzie używane do tworzenia obrazów.

Wynikiem działania docker build . jest obraz z zatwierdzeniem, więc nie można użyć pliku Dockerfile bez utworzenia zatwierdzenia. Pytanie brzmi, czy należy ręcznie aktualizować obraz za każdym razem, gdy coś się zmieni, a tym samym skazać się na klątwę złotego obrazu?

Przekleństwo złocistego wizerunku to straszne przekleństwo rzucone na ludzi, którzy muszą nadal żyć z zapchanym luką w zabezpieczeniach, aby uruchomić swoje oprogramowanie, ponieważ osoba, która go stworzyła, została dawno pochłonięta przez starożytnych (lub przeniosła się do nowej pracy) i nikt nie wie, skąd wzięli wersję imagemagic, która weszła w ten obraz.i jest jedyną rzeczą, która będzie łączyła się z modułem C++, który został dostarczony przez tego konsultanta syna szefa zatrudnionego trzy lata temu, a zresztą nie ma to znaczenia, ponieważ nawet jeśli zorientowałeś się, gdzie imagemagic pochodzi z wersji libstdC++ używanej przez JNI dzwoni do narzędzia wsparcia, które stażysta z długimi włosami stworzonym istnieje tylko w nieobsługiwanej wersji Ubuntu.

Answer 2

Znajomość obu rozwiązań, zalet i niedogodności, to dobry początek. Ponieważ mieszanka tych dwóch jest prawdopodobnie prawidłowym sposobem działania.

Con: uniknąć złoty obrazu ślepy zaułek:

Korzystanie tylko popełni jest źle, jeśli stracić jak odbudować swój wizerunek. Nie chcesz być w stanie, w którym nie możesz odbudować obrazu. Ten stan końcowy nazywa się tutaj złoty obraz, ponieważ obraz będzie jedynym punktem odniesienia, punktem początkowym i końcowym na każdym etapie. Jeśli go zgubisz, będziesz miał wiele kłopotów, ponieważ nie możesz go odbudować. Śmiertelnym ślepym zaułkiem jest to, że pewnego dnia będziesz musiał odbudować nowy (ponieważ wszystkie biblioteki systemowe są przestarzałe na przykład), a nie będziesz miał pojęcia, co zainstalować ... kończąc się dużą stratą czasu.

marginesie, to jest prawdopodobne, że za pomocą zobowiązuje ponad zobowiązuje byłby ładniejszy jeśli dziennik historia będzie łatwo użytkowej (skonsultować dyferencjału i powtórzyć je na inne obrazy), jak to jest w git: zauważysz ten git nie ma tego dylematu.

Pro: śliskie aktualizacje do dystrybucji

W drugiej strony, ma kilka warstw zobowiązuje znaczną przewagę w perspektywie rozproszonych modernizacje a tym samym przepustowość i czas wdrożenia. Jeśli zaczniesz manipulować obrazami w doku, ponieważ piekarz będzie obsługiwał naleśniki (co jest dokładnie tym, na co pozwala okno dokowane) lub chcesz wdrożyć wersję testową natychmiast, będziesz szczęśliwszy, wysyłając niewielką aktualizację w formie małego zatwierdzenia, a nie cały nowy obraz. Zwłaszcza w przypadku ciągłej integracji z klientami, gdzie poprawki błędów powinny być wdrażane wkrótce i często.

spróbować uzyskać najlepsze z dwóch światów:

W tego typu sytuacji, prawdopodobnie będziesz chciał, aby oznaczyć główną wersję swoich obrazów i powinny one pochodzić z Dockerfiles. Możesz również zapewnić ciągłe wersje integracji dzięki zatwierdzeniom opartym na wersji oznaczonej tagami. Ogranicza to zalety i niedogodności związane ze scenariuszami Docker i scenariuszem nakładania warstw. Kluczową sprawą jest to, że nigdy nie przestajesz śledzić swoich zdjęć, ograniczając liczbę zatwierdzeń, które możesz na nich wykonać.

Sądzę, że to zależy od twojego scenariusza i prawdopodobnie nie powinieneś próbować znaleźć jednej reguły. Jednak mogą istnieć pewne ślepe zaułki, których naprawdę należy unikać (jako kończące się scenariuszem "złotego obrazu") niezależnie od rozwiązania.