Pewnego dnia postanowiłem napisać artykuł o dostawie w postaci kontenerów Docker i pakietów deb, ale kiedy zacząłem, jakoś przeniosłem się w odległe czasy pierwszych komputerów osobistych, a nawet kalkulatorów. W rezultacie, zamiast suchych porównań Dockera i deb, powstały takie oto rozważania na temat ewolucji, które przedstawiam pod Państwa osąd.
Każdy produkt, nieważne jaki, musi jakoś dotrzeć do serwerów produkcyjnych, musi być skonfigurowany i uruchomiony. O tym właśnie będzie ten artykuł.
Będę rozważał to w kontekście historycznym, "co widzę – o tym śpiewam", co widziałem, gdy dopiero zaczynałem pisać kod i co obserwuję teraz, co sami obecnie używamy i dlaczego. Artykuł nie aspiruje do bycia całościowym badaniem, niektóre aspekty zostały pominięte, to mój osobisty pogląd na to, co było i co jest teraz.
Więc, w dawnych, dobrych czasach… najwcześniejszym sposobem dostawy, który pamiętam, były taśmy magnetofonowe. Miałem komputer BK-0010.01...
Era kalkulatorów
Nie, był jeszcze wcześniejszy moment, był jeszcze kalkulator i .
Tak więc, kiedy miałem , sposobem przenoszenia programów była zwykła kartka w kratkę, na której zapisana była program, który w razie potrzeby musiał być ręcznie wpisywany do kalkulatora. Chcesz zagrać (tak, tak, nawet na tym prehistorycznym kalkulatorze były gry) – siadasz i wpisujesz program do kalkulatora. Oczywiście, przy wyłączeniu kalkulatora program znikał. Oprócz ręcznie spisanych kodów kalkulatora, programy publikowane były w czasopismach „Radio” i „Technika Młodzieży”, a także drukowane w książkach tamtego okresu.
Następną modyfikacją był kalkulator , który już miał jakieś podobieństwo do pamięci nieulotnej. Teraz nie trzeba było ręcznie wpisywać gry lub programu, a po wykonaniu pewnych magicznych ruchów przyciskami, ładował się sam.
Wielkość największego programu w kalkulatorze wynosiła 105 kroków, a rozmiar pamięci stałej w MK-52 to 512 kroków.
Swoją drogą, jeśli są fani tych kalkulatorów, którzy czytają ten artykuł – w trakcie pisania tekstu znalazłem emulator kalkulatora dla Androida oraz programy dla niego. Wyruszamy w przeszłość!
Małe wprowadzenie do MK-52 (z Wikipedii)
MK-52 leciał w kosmos na statku 'Sojuz TM-7'. Miał być używany do obliczania trajektorii lądowania w przypadku awarii komputera pokładowego.
MK-52 z modułem rozszerzenia pamięci 'Elektronika-Astro' od 1988 roku był dostarczany na statki Marynarki Wojennej w składzie pokładowego systemu obliczeniowego.
Pierwsze komputery osobiste
Wróćmy do czasów . Oczywiście pamięci tam było więcej, a wprowadzanie kodu z papieru przestało być praktyczne (choć przez jakiś czas tak robiłem, bo nie miałem innego nośnika). Głównym środkiem przechowywania i dostarczania oprogramowania stały się kasety audio dla magnetofonów.
Przechowywanie na kasecie zazwyczaj polegało na jednym lub dwóch plikach binarnych, reszta była wewnątrz. Niezawodność była bardzo niska, trzeba było mieć 2-3 kopie programu. Czas ładowania również nie był zadowalający, entuzjaści eksperymentowali z różnym kodowaniem częstotliwości, aby przezwyciężyć te wady. Sam w tym czasie nie zajmowałem się profesjonalnym tworzeniem oprogramowania (pomijając proste programy w Basicu), więc niestety nie opowiem o szczegółach, jak wszystko było zorganizowane w środku. Sam fakt posiadania na komputerze głównie pamięci RAM w dużej mierze określał prostotę schematu przechowywania danych.
Pojawienie się niezawodnych i dużych nośników danych
Później pojawiają się dyskietki, ułatwiając proces kopiowania, zwiększa się niezawodność.
Jednak sytuacja radykalnie zmienia się dopiero, gdy pojawiają się wystarczająco duże lokalne magazyny w postaci HDD.
Zasadniczo zmienia się sposób dostarczania: pojawiają się programy instalacyjne, które zarządzają procesem konfigurowania systemu, a także czyszczeniem po usunięciu, ponieważ programy nie są już tylko ładowane do pamięci, ale kopiowane do lokalnego magazynu, z którego należy umieć również usuwać niepotrzebne w razie potrzeby.
Jednocześnie zwiększa się złożoność dostarczanego oprogramowania.
Liczba plików w dostawie rośnie z jednego do setek i tysięcy, zaczynają się konflikty wersji bibliotek i inne radości, gdy różne programy korzystają z tych samych danych.
W tamtych czasach nie wiedziałem jeszcze o istnieniu Linuxa, żyłem w świecie MS DOS i później Windows, a pisałem w Borland Pascal i Delphi, czasami zerkając w stronę C++. W tamtych czasach do dostarczania produktów wielu używało InstallShield , który z powodzeniem rozwiązywał wszystkie postawione zadania związane z wdrażaniem i konfiguracją oprogramowania.
Era internetu
Stopniowo złożoność systemów oprogramowania jeszcze bardziej wzrastała, przechodziło się od monolitycznych aplikacji desktopowych do systemów rozproszonych, cienkich klientów i mikrousług. Teraz trzeba było konfigurować nie jedną aplikację, ale ich zestaw, tak, by wszystkie współpracowały.
Kompletnie zmieniła się koncepcja, nastał Internet, zaczęła się era usług chmurowych. Na razie w początkowej fazie, w postaci stron internetowych, nikt szczególnie nie marzył o usługach, ale to był przełomowy moment w branży zarówno w kontekście rozwoju, jak i samego dostarczania aplikacji.
Dla mnie był to moment, w którym nastąpiła zmiana pokoleń programistów (lub to tylko w moim otoczeniu), i miałem wrażenie, że wszystkie stare dobre metody dostarczania zostały zapomniane w jednej chwili, a wszystko zaczęło się od nowa: całe dostarczanie zaczęto robić skryptami na kolanie, nazywając to dumnie „Continuous delivery”. W praktyce rozpoczął się jakiś okres chaosu, kiedy stare zostało zapomniane i nie było używane, a nowego po prostu nie było.
Pamiętam czasy, kiedy w naszej firmie, w której wtedy pracowałem (nie będę podawać nazwy), zamiast budować projekt przez ant (maven nie był wtedy jeszcze popularny lub w ogóle nie istniał), ludzie po prostu budowali jar w IDE i beztrosko commitowali go do SVN. Odpowiednio, wdrożenie polegało na wyciągnięciu pliku z SVN i skopiowaniu go przez SSH na odpowiednią maszynę. Tak prosto i prymitywnie.
W tym samym czasie dostarczanie prostych stron na PHP odbywało się w bardzo prymitywny sposób, przez zwykłe kopiowanie poprawionego pliku przez FTP na docelową maszynę. Czasami nie było nawet takiego luksusu — kod poprawiano na żywo na serwerze produkcyjnym, a szczególnym szczytem była sytuacja, gdy gdzieś były kopie zapasowe.
Pakiety RPM i DEB
Z drugiej strony, wraz z rozwojem internetu, systemy podobne do UNIX zyskiwały na popularności, a szczególnie w tym czasie odkryłem RedHat Linux 6, około 2000 roku. Oczywiście istniały tam również pewne narzędzia do 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 system dostarczany jest w postaci pakietów RPM i z powodzeniem istnieje oraz rozwija się do dziś.
Dystrybucje rodziny Debian podążyły podobną drogą i zrealizowały dostarczanie w postaci pakietów deb, co również utrzymuje się do dziś.
Menedżery pakietów umożliwiają dostarczanie samych produktów programowych, konfigurację ich w trakcie instalacji, zarządzanie zależnościami między różnymi pakietami, a także usuwanie produktów i czyszczenie zbędnych elementów w trakcie deinstalacji. Więc w większości to wszystko, co jest potrzebne, dlatego też przetrwały one przez kilka dziesięcioleci praktycznie bez zmian.
Chmura dodała do menedżerów pakietów instalację nie tylko z fizycznych nośników, ale i z chmurowych repozytoriów, ale zasadniczo niewiele się zmieniło.
Warto zauważyć, że obecnie istnieją pewne trendy w kierunku odejścia od deb i przejścia na pakiety snap, ale o tym później.
Tak więc, nowe pokolenie twórców chmurowych, które nie znało ani DEB, ani RPM, również stopniowo rosło, zdobywało doświadczenie, produkty stawały się coraz bardziej złożone i potrzebne były bardziej rozsądne sposoby dostarczania niż FTP, skrypty bash i podobne studenckie wynalazki.
I tutaj na scenę wchodzi Docker, swoisty mix wirtualizacji, izolacji zasobów i sposobu dostarczania. To teraz modne, młodzieżowe, ale czy jest potrzebne wszędzie? Czy to panaceum?
Z moich obserwacji wynika, że Docker często jest proponowany nie jako rozsądny wybór, a po prostu dlatego, że mówi się o tym w społeczności, a ci, którzy go proponują, znają tylko to. Z drugiej strony, o starych dobrych systemach pakowania w większości milczy się — istnieją i robią swoje cicho i niepozornie. W takiej sytuacji nie ma innego wyboru — wybór jest oczywisty — Docker.
Spróbuję podzielić się doświadczeniem, jak wprowadzaliśmy Docker, i co w rezultacie osiągnęliśmy.
Własne skrypty
Początkowo były to skrypty bash, które wdrażały archiwa jar na odpowiednie maszyny. Proces ten był zarządzany przez Jenkins. Działało to pomyślnie, ponieważ samo w sobie archiwum jar jest już budowlą, zawierającą klasy, zasoby, a nawet konfigurację. Jeśli wszystko zebrać, to rozłożenie go za pomocą skryptu nie jest najtrudniejszym zadaniem.
Jednak skrypty mają kilka wad:
- skrypty zazwyczaj pisane są w pośpiechu, dlatego są tak prymitywne, że zawierają tylko jeden, najbardziej udany scenariusz. Sprzyja temu fakt, że programista jest zainteresowany jak najszybszym dostarczeniem, a normalny skrypt wymaga zainwestowania odpowiedniej ilości zasobów.
- w wyniku poprzedniego punktu, skrypty nie zawierają procedury deinstalacji.
- brak ustalonej procedury aktualizacji.
- po pojawieniu się nowego produktu trzeba pisać nowy skrypt.
- brak wsparcia dla zależności.
Oczywiście, można napisać rozbudowany skrypt, ale, jak pisałem wcześniej — to wymaga czasu na opracowanie, a czasu, jak wiadomo, zawsze brakuje.
To wszystko oczywiście ogranicza zastosowanie tej metody wdrażania tylko do najprostszych systemów. Nastał czas, aby to zmienić.
Docker
W pewnym momencie zaczęli do nas przychodzić nowi mid-level developerzy, pełni pomysłów i marzący o Dockerze. Cóż, flagę w ręce — działamy! Były dwie próby. Obie nieudane — powiedzmy, z powodu dużych ambicji, ale niewystarczającego doświadczenia. Czy trzeba było przyspieszać i kończyć za wszelką cenę? Raczej nie — zespół powinien ewolucyjnie dorosnąć do odpowiedniego poziomu, zanim będzie mógł korzystać z odpowiednich narzędzi. Co więcej, korzystając z gotowych obrazów Dockera, często napotykaliśmy problemy z działaniem sieci (co być może było związane z niedoskonałościami samego Dockera) lub trudności w rozszerzaniu cudzych kontenerów.
Z jakimi problemami się spotkaliśmy?
- Problemy z siecią w trybie bridge.
- Nieporęcznie przegląda się logi w kontenerze (jeśli nie zostały przeniesione oddzielnie do systemu plików maszyny-host).
- Okresowe dziwne zawieszanie się ElasticSearch wewnątrz kontenera, przyczyny nie ustalono, kontener był oficjalny.
- Nieporęcznie korzysta się z powłoki wewnątrz kontenera — wszystko jest znacznie ograniczone, brakuje znajomych narzędzi.
- Duże rozmiary zbieranych kontenerów – kosztownie przechowywać.
- Z powodu dużych rozmiarów kontenerów trudno jest utrzymać wiele wersji.
- Dłuższy czas budowy w porównaniu do innych metod (skrypty lub pakiety deb).
Z drugiej strony, czemu serwis Spring w postaci archiwum jar jest gorszy do wdrożenia przez ten sam deb? Czy naprawdę potrzebna jest izolacja zasobów? Czy warto rezygnować z wygodnych narzędzi systemu operacyjnego, pakując serwis w mocno okrojonym kontenerze?
Jak pokazuje praktyka – w rzeczywistości nie jest to potrzebne, pakiet deb wystarcza w 90% przypadków.
Kiedy jednak stary dobry deb nie działa i kiedy naprawdę potrzebny nam był Docker?
Dla nas to było wdrożenie serwisów w Pythonie. Wiele bibliotek potrzebnych do uczenia maszynowego, które nie były obecne w standardowej dostawie systemu operacyjnego (a to, co tam było – nie tych wersji), triki z konfiguracjami, potrzeba różnych wersji dla różnych serwisów działających na tym samym systemie gospodarza doprowadziły do tego, że jedynym rozsądnym sposobem dostarczenia tej mieszanki okazał się Docker. Pracochłonność budowy kontenera Docker okazała się niższa niż pomysł zapakowania tego wszystkiego w osobne pakiety deb z zależnościami, a tak naprawdę nikt w zdrowym zmyśle by się za to nie zabrał.
Drugi moment, w którym planowane jest użycie Dockera – do wdrażania serwisów w schemacie blue-green deploy. Ale tutaj chcemy uzyskać stopniowe zwiększanie złożoności: najpierw budowane są pakiety deb, a następnie na ich podstawie budowany jest kontener Docker.
Snap-pakiety.
Wróćmy do snap-pakietów. Po raz pierwszy pojawiły się oficjalnie w Ubuntu 16.04. W przeciwieństwie do znanych pakietów deb i rpm, snap zawiera wszystkie zależności. Z jednej strony pozwala to uniknąć konfliktów bibliotek, z drugiej strony – skutkuje to większymi rozmiarami rezultatu pakietu. Ponadto może to wpłynąć na bezpieczeństwo systemu: w przypadku dostarczania snap za wszystkie zmiany włączonych bibliotek musi czuwać sam programista, który tworzy pakiet. Ogólnie rzecz biorąc, nie wszystko jest jednoznaczne, a powszechne szczęście z ich użycia nie nadchodzi. Niemniej jednak jest to całkiem rozsądna alternatywa, jeśli ten sam Docker jest używany tylko jako środek pakowania, a nie wirtualizacji.
W rezultacie obecnie w rozsądnej proporcji wykorzystujemy zarówno pakiety deb, jak i kontenery Docker, które być może w niektórych przypadkach zastąpimy pakietami snap.
Tylko zarejestrowani użytkownicy mogą brać udział w ankiecie. , proszę.
A czego używacie do dostarczania?
Własne skrypty
Kopiujemy ręcznie na FTP
pakiety deb
pakiety rpm
pakiety snap
obrazy Docker
Obrazy maszyn wirtualnych
Klonujemy cały HDD
puppet
ansible
Inne
Zagłosowało 109 użytkowników. 32 użytkowników wstrzymało się.
Źródło: habr.com
