Jakoś w pewnym momencie zdecydowałem się napisać artykuł o dostarczaniu w postaci kontenerów Dockera i pakietów deb, ale kiedy zaczynałem, z jakiegoś powodu przeniesiono mnie w odległe czasy pierwszych komputerów osobistych, a nawet kalkulatorów. Ogólnie rzecz biorąc, zamiast suchych porównań dockera i deba, otrzymaliśmy te przemyślenia na temat ewolucji, które przedstawiam pod rozwagę.
Każdy produkt, niezależnie od tego, jaki jest, musi w jakiś sposób dostać się na serwery produktu, musi zostać skonfigurowany i uruchomiony. O tym właśnie będzie ten artykuł.
Pomyślę w kontekście historycznym: „to, co widzę, jest tym, o czym śpiewam”, co widziałem, kiedy zaczynałem pisać kod i co obserwuję teraz, czego sami używamy w tej chwili i dlaczego. Artykuł nie udaje pełnoprawnego opracowania, pominięto w nim pewne punkty, to jest mój osobisty pogląd na to, co było i co jest teraz.
Tak więc, za starych dobrych czasów... najwcześniejszą metodą dostawy, jaką znalazłem, były kasety magnetofonowe. Miałem komputer BK-0010.01...
Era kalkulatorów
Nie, był jeszcze wcześniejszy moment, był też kalkulator и .
Więc kiedy to zrobiłem , wówczas sposobem przeniesienia programu była zwykła kartka papieru w pudełku, na którym napisano program, który w razie potrzeby, aby uruchomić go ręcznie, wpisano do kalkulatora. Jeśli chcesz pograć (tak, nawet ten przedpotopowy kalkulator miał gry) - siadasz i wpisujesz program do kalkulatora. Naturalnie, gdy kalkulator został wyłączony, program zniknął w zapomnienie. Oprócz własnoręcznie wypisanych na papierze kodów kalkulatora, audycje ukazywały się w czasopismach „Radio” i „Technologia dla Młodzieży”, a także publikowano w ówczesnych książkach.
Następną modyfikacją był kalkulator , ma już pewne pozory nieulotnego przechowywania danych. Teraz gra lub program nie musiał być wprowadzany ręcznie, ale po wykonaniu kilku magicznych kroków za pomocą przycisków, ładował się sam.
Rozmiar największego programu w kalkulatorze wynosił 105 kroków, a rozmiar pamięci stałej w MK-52 wynosił 512 kroków.
Nawiasem mówiąc, jeśli są fani tych kalkulatorów, którzy czytają ten artykuł, w trakcie pisania artykułu znalazłem zarówno emulator kalkulatora dla Androida, jak i programy do niego. Przejdź do przeszłości!
Krótka dygresja na temat MK-52 (z Wikipedii)
MK-52 poleciał w kosmos na statku kosmicznym Sojuz TM-7. Miał on służyć do obliczania trajektorii lądowania na wypadek awarii komputera pokładowego.
Od 52 roku MK-1988 z modułem rozszerzenia pamięci Elektronika-Astro dostarczany jest na okręty Marynarki Wojennej w ramach zestawu obliczeniowego nawigacyjnego.
Pierwsze komputery osobiste
Wróćmy do czasów . Widać, że było tam więcej pamięci i wpisywanie kodu z kartki papieru nie wchodziło już w grę (chociaż na początku tak właśnie zrobiłem, bo innego medium po prostu nie było). Kasety audio do magnetofonów stają się głównym sposobem przechowywania i dostarczania oprogramowania.
Zapis na kasecie miał zwykle formę jednego lub dwóch plików binarnych, cała reszta znajdowała się w środku. Niezawodność była bardzo niska, musiałem zachować 2-3 kopie programu. Czasy ładowania również były rozczarowujące, a entuzjaści eksperymentowali z różnymi kodowaniami częstotliwości, aby przezwyciężyć te niedociągnięcia. Ja sam nie zajmowałem się wówczas jeszcze profesjonalnym tworzeniem oprogramowania (nie licząc prostych programów w BASIC-u), więc niestety nie opowiem szczegółowo, jak wszystko było w środku ułożone. Już sam fakt, że komputer posiadał tylko pamięć RAM, w dużej mierze decydował o prostocie schematu przechowywania danych.
Pojawienie się niezawodnych i dużych nośników danych
Później pojawiły się dyskietki, proces kopiowania został uproszczony i wzrosła niezawodność.
Jednak sytuacja zmienia się radykalnie dopiero wtedy, gdy pojawią się wystarczająco duże magazyny lokalne w postaci dysków twardych.
Rodzaj dostawy zasadniczo się zmienia: pojawiają się programy instalacyjne, które zarządzają procesem konfiguracji systemu, a także czyszczeniem po usunięciu, ponieważ programy nie są tylko wczytywane do pamięci, ale są już kopiowane do pamięci lokalnej, z której należy w razie potrzeby być w stanie usunąć niepotrzebne rzeczy.
Jednocześnie wzrasta złożoność dostarczanego oprogramowania.
Liczba dostarczanych plików wzrasta od kilku do setek i tysięcy, konflikty pomiędzy wersjami bibliotek i inne radości zaczynają się, gdy różne programy korzystają z tych samych danych.
W tamtym czasie istnienie Linuksa nie było jeszcze dla mnie odkryte, żyłem w świecie MS DOS, a później Windowsa i pisałem w Borland Pascal i Delphi, czasami spoglądając w stronę C++. Wiele osób korzystało wówczas z programu InstallShield do dostarczania produktów. , który całkiem skutecznie rozwiązał wszystkie przydzielone zadania związane z wdrażaniem i konfiguracją oprogramowania.
Era Internetu
Stopniowo złożoność systemów oprogramowania staje się jeszcze bardziej złożona; od aplikacji monolitycznych i stacjonarnych następuje przejście do systemów rozproszonych, cienkich klientów i mikrousług. Teraz musisz skonfigurować nie tylko jeden program, ale ich zestaw, tak aby wszystkie działały razem.
Koncepcja uległa całkowitej zmianie, przyszedł Internet, nadeszła era usług chmurowych. Póki co, jedynie w początkowej fazie, w postaci stron internetowych, nikt specjalnie nie marzył o usługach. był to jednak punkt zwrotny zarówno w rozwoju, jak i dostarczaniu aplikacji.
U siebie zauważyłem, że w tym momencie nastąpiła zmiana pokoleń programistów (albo tylko w moim środowisku) i pojawiło się poczucie, że w pewnym momencie zapomniano o wszystkich starych, dobrych metodach dostarczania i wszystko zaczęło się od samego początku początek: wszystkie dostawy zaczęto realizować według scenariuszy kolanowych i dumnie nazywano to „Dostawą ciągłą”. Tak naprawdę rozpoczął się okres chaosu, kiedy stare zostaje zapomniane i nieużywane, a nowego po prostu nie ma.
Pamiętam czasy, gdy w naszej firmie, w której wtedy pracowałem (nie będę tego nazywać), zamiast budować przez ant (maven nie był jeszcze popularny lub w ogóle nie istniał), ludzie po prostu zbierali słoiki w IDE i spokojnie się angażowali to w SVN. W związku z tym wdrożenie polegało na pobraniu pliku z SVN i skopiowaniu go przez SSH na żądaną maszynę. To takie proste i niezdarne.
Jednocześnie dostarczanie prostych stron w PHP odbywało się w bardzo prymitywny sposób, po prostu kopiując poprawiony plik przez FTP na maszynę docelową. Czasami tak nie było - kod był edytowany na żywo na serwerze produktu i było to szczególnie eleganckie, jeśli gdzieś znajdowały się kopie zapasowe.
Pakiety RPM i DEB
Z drugiej strony wraz z rozwojem Internetu systemy typu UNIX zaczęły zyskiwać coraz większą popularność, w szczególności wtedy odkryłem RedHat Linux 6, około 2000 roku. Naturalnie istniały także pewne sposoby dostarczania oprogramowania – według Wikipedii RPM jako główny menedżer pakietów pojawił się już w 1995 roku, w wersji RedHat Linux 2.0. I od tego czasu do dziś system dostarczany jest w formie pakietów RPM i z powodzeniem istnieje i rozwija się.
Dystrybucje rodziny Debiana poszły podobną drogą i wprowadziły dostarczanie w postaci pakietów deb, co pozostało niezmienione do dziś.
Menedżerowie pakietów umożliwiają samodzielne dostarczanie oprogramowania, konfigurowanie ich podczas procesu instalacji, zarządzanie zależnościami między różnymi pakietami, usuwanie produktów i czyszczenie niepotrzebnych elementów podczas procesu dezinstalacji. Te. w większości to wszystko, czego potrzeba, dlatego przetrwały kilka dekad praktycznie w niezmienionym stanie.
Przetwarzanie w chmurze dodało instalację do menedżerów pakietów nie tylko z nośników fizycznych, ale także z repozytoriów w chmurze, ale zasadniczo niewiele się zmieniło.
Warto zauważyć, że obecnie są pewne ruchy w kierunku odejścia od deb i przejścia na pakiety snap, ale o tym później.
Tak więc nowa generacja programistów zajmujących się chmurą, którzy nie znali ani DEB, ani RPM, również powoli się rozwijała, zdobywała doświadczenie, produkty stały się bardziej złożone i potrzebne były bardziej rozsądne metody dostarczania niż FTP, skrypty bash i podobne rzemiosło studenckie.
I tu pojawia się Docker, rodzaj połączenia wirtualizacji, delimitacji zasobów i metody dostarczania. To teraz modne i młodzieżowe, ale czy potrzebne do wszystkiego? Czy to jest panaceum?
Z moich obserwacji wynika, że bardzo często Docker jest proponowany nie jako rozsądny wybór, ale po prostu dlatego, że z jednej strony w społeczności się o nim mówi, a ci, którzy go proponują, tylko o tym wiedzą. Z drugiej strony w większości milczą na temat starych, dobrych systemów pakowania - istnieją i wykonują swoją pracę po cichu i niezauważenie. W takiej sytuacji naprawdę nie ma innego wyjścia – wybór jest oczywisty – Docker.
Spróbuję podzielić się swoimi doświadczeniami na temat tego, jak wdrożyliśmy Dockera i co się w rezultacie wydarzyło.
Skrypty napisane samodzielnie
Początkowo istniały skrypty bash, które wdrażały archiwa jar na wymaganych komputerach. Procesem tym zarządzał Jenkins. To zadziałało pomyślnie, ponieważ samo archiwum jar jest już zestawem zawierającym klasy, zasoby, a nawet konfigurację. Jeśli włożysz w to wszystko maksymalnie, to rozwinięcie tego w skrypt nie jest najtrudniejszą rzeczą, jakiej potrzebujesz
Skrypty mają jednak kilka wad:
- skrypty są zwykle pisane w pośpiechu i dlatego są tak prymitywne, że zawierają tylko jeden najlepszy scenariusz. Ułatwia to fakt, że deweloperowi zależy na szybkiej dostawie, a normalny skrypt wymaga inwestycji przyzwoitej ilości zasobów
- w związku z poprzednim punktem skrypty nie zawierają procedur dezinstalacyjnych
- brak ustalonej procedury aktualizacji
- Kiedy pojawi się nowy produkt, musisz napisać nowy skrypt
- brak obsługi zależności
Można oczywiście napisać wyrafinowany scenariusz, ale tak jak pisałem powyżej, jest to czas rozwoju, a nie najmniej, a jak wiemy, czasu zawsze jest za mało.
Wszystko to w oczywisty sposób ogranicza zakres zastosowania tej metody wdrażania jedynie do najprostszych systemów. Nadszedł czas, aby to zmienić.
Doker
W pewnym momencie zaczęły do nas przychodzić świeżo wybite środeczki, kipiące od pomysłów i zachwycone dokerem. No cóż, z flagą w ręku – do dzieła! Były dwie próby. Obydwa się nie powiodły – powiedzmy, ze względu na duże ambicje, ale brak realnego doświadczenia. Czy trzeba było to wymusić i zakończyć w jakikolwiek możliwy sposób? Jest to mało prawdopodobne – zespół musi ewoluować do wymaganego poziomu, zanim będzie mógł korzystać z odpowiednich narzędzi. Dodatkowo, korzystając z gotowych obrazów Dockera, często spotykaliśmy się z tym, że sieć nie działała poprawnie (co mogło być spowodowane zawilgoceniem samego Dockera) lub trudno było rozbudowywać kontenery innych osób.
Jakie niedogodności napotkaliśmy?
- Problemy z siecią w trybie mostu
- Przeglądanie logów w kontenerze jest niewygodne (jeśli nie są przechowywane oddzielnie w systemie plików hosta)
- ElasticSearch czasami dziwnie zawiesza się w pojemniku, przyczyna nie została ustalona, pojemnik jest oficjalny
- Konieczne jest użycie muszli wewnątrz pojemnika - wszystko jest bardzo uproszczone, nie ma zwykłych narzędzi
- Duże rozmiary zebranych pojemników - drogie w przechowywaniu
- Ze względu na duże rozmiary kontenerów trudno jest obsługiwać wiele wersji
- Dłuższy czas kompilacji, w przeciwieństwie do innych metod (skrypty lub pakiety deb)
Z drugiej strony, dlaczego gorsze jest wdrożenie usługi Spring w postaci archiwum jar za pośrednictwem tego samego debu? Czy izolacja zasobów jest naprawdę konieczna? Czy warto tracić wygodne narzędzia systemu operacyjnego na rzecz upchania usługi w znacznie zmniejszonym pojemniku?
Jak pokazała praktyka, w rzeczywistości nie jest to konieczne, pakiet deb wystarczy w 90% przypadków.
Kiedy stary, dobry deb zawodzi i kiedy naprawdę potrzebujemy okna dokowanego?
Dla nas było to wdrażanie usług w Pythonie. Wiele bibliotek potrzebnych do uczenia maszynowego, a nie uwzględnionych w standardowej dystrybucji systemu operacyjnego (a co tam było, to były błędne wersje), hacki z ustawieniami, potrzeba różnych wersji dla różnych usług działających na tym samym systemie hosta doprowadziły do tego to, że jedynym rozsądnym sposobem dostarczenia tej mieszaniny nuklearnej był doker. Pracochłonność montażu kontenera dokowanego okazała się niższa niż pomysł spakowania tego wszystkiego w osobne pakiety deb z zależnościami i tak naprawdę nikt o zdrowych zmysłach by się tego nie podjął.
Drugim punktem, w którym planujemy użyć Dockera, jest wdrożenie usług przy użyciu niebiesko-zielonego schematu wdrażania. Ale tutaj chcę uzyskać stopniowy wzrost złożoności: najpierw budowane są pakiety deb, a następnie budowany jest z nich kontener dokujący.
Przyciągaj paczki
Wróćmy do pakietów snap. Po raz pierwszy oficjalnie pojawiły się w Ubuntu 16.04. W przeciwieństwie do zwykłych pakietów deb i pakietów RPM, snap przenosi wszystkie zależności. Z jednej strony pozwala to uniknąć konfliktów bibliotek, z drugiej strony powstały pakiet jest większy. Ponadto może to również mieć wpływ na bezpieczeństwo systemu: w przypadku dostawy typu snap wszystkie zmiany w dołączonych bibliotekach muszą być monitorowane przez programistę tworzącego pakiet. Generalnie nie wszystko jest takie proste i powszechne szczęście nie wynika z ich stosowania. Niemniej jednak jest to całkowicie rozsądna alternatywa, jeśli ten sam Docker jest używany tylko jako narzędzie do pakowania, a nie do wirtualizacji.
W rezultacie używamy teraz zarówno pakietów deb, jak i kontenerów dokowanych w rozsądnej kombinacji, które być może w niektórych przypadkach zastąpimy pakietami snap.
W ankiecie mogą brać udział tylko zarejestrowani użytkownicy. , Proszę.
Czego używasz do dostawy?
-
Skrypty napisane samodzielnie
-
Skopiuj ręcznie na FTP
-
pakiety debowe
-
pakiety obr/min
-
pakiety zatrzaskowe
-
Obrazy Dockera
-
Obrazy maszyn wirtualnych
-
Sklonuj cały dysk twardy
-
marionetka
-
ansible
-
Inny
Głosowało 109 użytkowników. 32 użytkowników wstrzymało się od głosu.
Źródło: www.habr.com