Po co mi to?
Jesteś deweloperem. Początkujący czy nie, nie ma to znaczenia. Piszesz aplikację, ale ona wymaga środowiska do uruchomienia. No właśnie, środowisko to nie coś, co uruchomisz na odpierdol, a coś nad czym będziesz pełnił kontrolę w pełni. Choćby po to, aby nie było zrobione na odpierdol. Po co?
Powody są dość proste
Tworząc aplikację potrzebujesz stabilnego środowiska do testów, uruchamiania i kontrolowanego psucia. No i troubleshootingu, ale nie bądźmy aż tak bardzo wredni. I tak wszyscy wiemy, że aplikacja w trakcie tworzenia składa się w 98% z generatora logów z przedrostkiem Warning albo Error
Jeśli jednak nie wybrałeś metody bruteforce, polegającej na robieniu wszystkiego, co znajdziesz w internecie albo podpowie AI, to prawdopodobnie jednak czytasz te logi. Dobrze jest mieć pewność, że logi dotyczą aplikacji, a nie źle skonfigurowanego środowiska. Jako administrator nie zliczę, ile razy taka sytuacja miała miejsce, gdzie zespół deweloperski dokonywał rzezi niewiniątek w zespole, podczas gdy brakowało jedynie jakiejś biblioteki. Stabilne środowisko może mocno ograniczyć takie historie.
Środowisko w liczbie sztuk równej jeden jest dość proste do zrobienia.
Oddzielny komputer, maszyna wirtualna, własny PC. No… da się. I nawet to może działać. Ale co w przypadku, gdy chcesz przetestować swoją aplikację w pięciu wersjach Apache (bo tak, nie wnikaj). I pod czterema OS (bo część maszyn lata na Ubuntu, część na Debianie 12, część na Debianie 13, a ta jedna zapomniana na Alpine). Matematyka jest prosta, pięć razy cztery to dwadzieścia. Można próbować równolegle uruchamiać różne wersje Apache (czy czego tam potrzebujesz) ale to nadal duże prawdopodobieństwo wypierdolki. Oczywiście znajdzie się ktoś, kto stwierdzi że się da i on tak od 29 lat adminuje i działa i dobrze. Ale nie każdy musi powielać patologię. Mamy więc 20 środowisk, w każdej trzeba przeprowadzić testy aplikacji. 20 maszyn wirtualnych? Czyli 20 OS, 20 Apache, 20 razy zmarnowane zasoby. AWS? Spoko, korpo zapłaci, ale co jeśli jednak nie masz pod sobą wiadra dolarów na przepalenie w chmurze? Przygotowanie 20 kontenerów ogranicza zużyte zasoby i daje pewność, że zadziałają dokładnie tak samo, niezależnie czy uruchomisz z Dockera w Windowsie czy Ubuntu. Pozwala to skupić się na zrządzaniu aplikacją i jej problemami, a nie dłubaniu i naprawianiu serwera. Dobrze przygotowany obraz kontenera jest na wagę złota.
Skalowalność.
Powyższy przykład daje jeszcze jeden aspekt, jakim jest możliwość wielokrotnego uruchamiania kontenera z tego samego obrazu. I nie ma znaczenia czy uruchomisz 10 różnych, czy 10 tych samych, nie uruchamiasz 10 razy systemu operacyjnego, nie udajesz 10 razy hardware, nie zabezpieczasz 10 razy OS. Robisz to raz i czas poświęcasz na coś znacznie bardziej produktywnego. Oglądanie gorących mamusiek w okolicy czy coś… I tak, można przygotować golden image i z niego startować maszyny. Ale nadal to cały stack, od udawanego hardware po system operacyjny!
Bezpieczeństwo.
Oczywiście to rzecz bardzo względna. Zależy wszak od tego, jak ktoś przyłoży się do hardeningu danego środowiska. Niemniej spora część zabezpieczania kontenerów jest oparta na bezpieczeństwie hosta, na którym stawiane są kontenery. I to miecz obosieczny, bo błędy popełnione na hoście mogą (ale nie muszą!) ugryźć w dupę w kontenerach, ale z drugiej strony miejsce problemu jest jedno: host. Dodatkowo ze względu na fakt izolacji kontenerów od hosta i to, że kontener ma dostęp jedynie do kontenerzanych zasobów (biblioteki, software…) to prawdopodobieństwo wykorzystania takiego kontenera do innych celów, niż został zaprojektowany, jest znacząco niższe.
Upraszczanie.
Wirtualizacja całego peceta na początku może wydawać się dość oczywista i dość przystępna. Wszak łatwiej wyobrazić sobie całego, działającego PC, niż twór tak abstrakcyjny jak kontener. Jednak nie bez powodu dużo usług działa w kontenerach. Mój domowy homelab, który dźwiga naprawdę dużo usług, jest oparty na kontenerach, nie ma dużych zasobów. 16GB ram? No tak, i wystarcza. Nie jest już przestronnie, ale nadal daleko od zasypania się pod korek. Uruchamiając ten sam stack aplikacji w VM musiałbym poświęcić zdecydowanie więcej, niż 16GB (licząc na piechotkę, jakieś 50GB w samych maszynach). Jest różnica, co? A same kontenery i ich współdzielenie zasobów łatwo zrozumieć na przykładzie smartfona. Smartfon to Twój serwer (host). Kiedyś potrzebowałeś osobnego urządzenia (czyli osobnej maszyny fizycznej) do robienia zdjęć, osobnego do słuchania muzyki i osobnej latarki. Teraz masz jednego hosta (mydelniczkę), na którym odpalasz różne, odizolowane od siebie „kontenery” (aplikacje). Apka do zdjęć skupia się na fotografii, apka bankowa uwierzytelnia Cię na podstawie geometrii ryjca, a apka do gorących mamusiek robi to, do czego została stworzona. Wszystkie te apki (kontenery) korzystają z tego samego, wspólnego sprzętu (kamery, głośnika, kernela systemu), nie wchodzą sobie w paradę i nie musisz taszczyć ze sobą całego plecaka dedykowanych urządzeń (maszyn wirtualnych). Forma pozostaje ta sama, zasoby są współdzielone. Nie taszczysz ze sobą drugiego aparatu, kompletu stereo z salonu czy też latarni morskiej, a właśnie taką mydelniczkę.
Uniwersalność i inne podejście.
Kontenery możesz wykorzystywać zarówno do uruchamiania aplikacji ciągłych, które działają cały czas i wykonują jakieś zadanie cały czas. Nie wiem, koparka krypto: kopie, kopie i końca nie widać. Ale nic nie stoi na przeszkodzie, aby kontener wykonał zadanie raz i zniknął. Na zawsze. Puff i nie ma. Zapytasz się: po cholerę? A ja odpowiem: bo jesteśmy wygodni. Dobrym przypadkiem jest Ansible. Nie stoi nic na przeszkodzie, aby wrzucić takiego gagatka w kontener i przygotować mu playbook z aktualizacją systemu. I listę hostów, nie wiem, serwery produkcyjne dajmy na to. No, i ten, tego, zamiast zatrudniać stażystę do klepania tego z łapki, wrzucamy takie uruchomienie w crontab i zrobi się samo w określonym czasie. Kontener uruchomi się o zadanej porze z określonego obrazu, wykona zadanie, jeśli poprosisz to może i nawet logi zapisze, a po wszystkim zniknie, nie marnując zasobów na mielenie się na CPU w idle. Spróbuj to zrobić z maszynami wirtualnymi i nie ocipieć. Czas start.
Jej Klockowa Mość.
Tak długo, jak nie próbujesz zrobić kontenera do wszystkiego, tak długo można mówić o zachowywaniu prostego podejścia 1 kontener = 1 funkcja. Chodzi o to, aby kontener z serwerem WWW nie robił równolegle za model językowy i AI. Chcesz robić takie potworki? Odpal sobie maszynę wirtualną, serio. Albo zobacz na Docker Compose i napisz compose który uruchomi i zepnie te klocki w jedną działającą aplikację. Zachowasz wszystkie zalety i pełną elastyczność, a w razie potrzeby zmieniając jeden klocek (zmiana Apache na Nginx? Pestka w compose!) nie zawalisz całej budowli.
Jej Klastrowalna Mość.
Przejście z kontenerów na jednej maszynie na klaster w Kubernetes na paru node jest dość prosty. W znakomitej większości przypadków wyjęty kontener z klastra i odpalony jako stand-alone zadziała i będzie spoko. Teraz spróbuj to samo z Windows serwerem i klastrem wysokiej dostępności. Rozpinanie, drenowanie, pilnowanie świadka, czekanie na wypłynięcie śmietnika z kolejki a po wszystkim pewnie i tak walniesz restart. W międzyczasie doklej update i masz rzeczywistość milionów adminów po patch tuesday. Jeśli tylko jest taka możliwość, to dobry klaster kontenerów może to wszystko uprościć i pomóc zachować higienę takiego środowiska.
Robienie głupich rzeczy.
Chcesz uruchomić równolegle piętnaście wersji wordpressa i siedemnaście reverse proxy na jednym pc? A proszę, kontenery nie będą się bić tak długo, jak pilnujesz portów. I tak to zostawię, bo opalenie tego w przypadku gołego PC to droga przez mękę. Jeden nie lubi nowszej biblioteki, inny ma jakiś port ustawiony w kodzie i choćby skały srały, nie odpali się na innym bo nie. W kontenerze pyk pyk jako tako i fajrant bo masz nad tym pełną kontrolę. WordPress w wersji 21.37 nie zobaczy starej biblioteki, która jest wymagana dla wersji 4.20, bo są odizolowane.
Źródła
- PTSD
- Dyżury weekendowe
- On Call
0 komentarzy