DevOps

Zapytanie, które trwa 200ms w twojej bazie danych, nadal trwa 200ms za milionowym razem, gdy ktoś je uruchamia, a każde takie uruchomienie rywalizuje o te same połączenia, ten sam I/O dysku i ten sam procesor. Redis trzyma odpowiedź w pamięci, na serwerze, który nie robi niczego innego, więc milionowy odczyt kosztuje tyle co jeden przeskok sieciowy, a nie plan zapytania. Co Redis naprawdę robi jako cache Redis to key-value store działający w pamięci. Wartości żyją w RAM, więc odczyty i zapisy mierzy się w czasie poniżej milisekundy zamiast dziesiątek czy setek milisekund, które kosztuje zapytanie relacyjne, gdy w grę wchodzą joiny, obciążone indeksy albo zajęty connection pool. Redis stoi obok twojej bazy danych, nie zamiast niej: aplikacja pyta najpierw Redis i sięga do bazy dopiero, gdy Redis nie ma odpowiedzi. ...

Co stoi między przeglądarką a twoją aplikacją Wpisz w przeglądarce example.com, a żądanie nigdy nie dotrze bezpośrednio do procesu, który uruchamia twój kod. Najpierw trafia na coś innego: serwer, który odczytuje żądanie, decyduje, który backend ma odpowiedzieć, przekazuje je tam i odsyła odpowiedź tak, jakby sam ją wygenerował. Ten serwer to reverse proxy. Nginx, Caddy, Traefik i HAProxy robią dokładnie to samo, podobnie jak load balancer stojący przed klastrem Kubernetes. Układ się nie zmienia: klienci rozmawiają wyłącznie z proxy. Prawdziwe serwery zostają za nim, niezależnie od tego, ile ich jest i gdzie działają. ...

Robisz pull najnowszego main, a Git zatrzymuje się z CONFLICT (content): Merge conflict in checkout.js. Rozwiązujesz konflikt, a w logu pojawia się commit o nazwie Merge branch 'main' into feature/checkout, leżący na trzech commitach, które faktycznie napisałeś. Cztery commity, jedna prawdziwa zmiana. Kolega, który za miesiąc przeczyta tę historię, nie ma szans rozpoznać, który jest który. git merge i git rebase odpowiadają na to samo pytanie: jak zaktualizować swój branch o zmiany zrobione gdzieś indziej. Zostawiają za sobą bardzo różne ślady, a wybranie złego na wspólnym branchu robi realną szkodę. ...

docker build && docker push z własnego laptopa działa dopóki ktoś inny nie musi opublikować tego samego obrazu albo dopóki nie trzeba tego robić przy każdym merge’u bez ciebie przy klawiaturze. GitHub Actions wykonuje ten sam build na serwerach GitHub, nadaje obrazowi tag na podstawie tego, co uruchomiło workflow, i publikuje go w registry, z którego twój krok deploy może zrobić pull. Nic nie dzieje się lokalnie. Co jest potrzebne, żeby zbudować i opublikować obraz Docker z poziomu CI Pięć elementów musi być na miejscu, zanim runner będzie mógł opublikować obraz: ...

Uruchom kubectl run nginx --image=nginx:1.27, a Kubernetes utworzy dokładnie jeden Pod o nazwie nginx. Usuń go poleceniem kubectl delete pod nginx i zniknie na dobre — nikt tego nie zauważy, nikt go nie zastąpi. Pod to najmniejsza jednostka wdrożeniowa w Kubernetes: jeden lub więcej kontenerów dzielących namespace sieciowy i zestaw wolumenów, zaplanowanych razem na jednym Node. Taki pojedynczy Pod to ślepy zaułek w produkcji. Jeśli kontener w nim się wywali, kubelet uruchomi go ponownie w tym samym miejscu. Jeśli Node się zrestartuje albo ktoś usunie Pod, nic go nie odtworzy. Goły Pod nie wie, że w ogóle powinien istnieć. ...

Gdzie kończą zmienne środowiskowe kontenera Uruchamiasz kontener poleceniem -e DB_PASSWORD=hunter2 i sprawdzasz go docker inspect: 1 2 docker run -d --name api -e DB_PASSWORD=hunter2 nginx:alpine docker inspect --format '{{json .Config.Env}}' api 1 ["DB_PASSWORD=hunter2","PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"] Hasło leży tam jawnym tekstem, czytelne dla każdego z dostępem do socketa Docker, dla docker exec api env i dla każdego procesu działającego w kontenerze. To nie jest błąd — dokładnie do tego służą zmienne środowiskowe. Problem pojawia się, gdy używasz ich do wartości, które nigdy nie powinny być aż tak widoczne. ...

Dlaczego obraz Docker waży dziesięć razy więcej niż aplikacja Usługa Node z kilkuset kilobajtami kodu źródłowego kończy jako obraz ważący ponad 1 GB. To normalny wynik działającego builda, nie błąd w jakiejś konkretnej linii. Waga bierze się z obrazu bazowego, który dźwiga cały system operacyjny, z toolchaina do builda, którego działająca aplikacja nigdy nie wywołuje, i z cache menedżera pakietów, o którego usunięcie nikt builda nie poprosił. Płacisz za to przy każdym deployu: docker pull działa wolniej, a skaner podatności ma kilkaset dodatkowych pakietów do zgłoszenia. Miejsce na dysku też się kumuluje, na każdym tagu, jaki kiedykolwiek wypchnąłeś. Naprawienie tego oznacza przepisanie Dockerfile, nie aplikacji. ...

Ile kosztuje źle napisany Dockerfile 1 2 3 4 5 6 FROM node:latest COPY . . RUN npm install CMD ["node", "server.js"] Cztery linijki, a każda coś kosztuje. docker build uruchamia npm install od nowa przy każdej zmianie kodu, bo COPY . . psuje cache warstw, zanim krok instalacji w ogóle dostanie szansę na ponowne użycie. Finalny obraz niesie ze sobą całą bazę Debiana, cały katalog node_modules razem z zależnościami deweloperskimi i wszystkimi narzędziami budowania, które npm install ściągnął do kompilacji modułów natywnych. Nic nie jest odrzucane. Kontener działa jako root, bo nikt mu nie kazał inaczej, a node:latest oznacza, że obraz bazowy może się zmienić między jedną a drugą buildą, bez żadnego śladu tego, co faktycznie wypuściłeś. ...

Dlaczego dwa kontenery na tym samym hoście domyślnie się nie widzą Uruchamiasz Postgresa i swoje API zwykłym docker run, a API nie potrafi połączyć się z bazą danych, mimo że oba kontenery działają na tej samej maszynie. 1 2 docker run -d --name db postgres:16 docker run -d --name api myapp Oba trafiają na domyślną sieć bridge, do której Docker podłącza każdy kontener Docker, jeśli nie skonfigurujesz tego inaczej. Dostają adresy IP, ale nie dostają sposobu na odnalezienie się po nazwie — API musiałoby mieć na sztywno wpisany wewnętrzny adres IP bazy danych, który zmienia się przy każdym restarcie kontenera. ...

Problem, który rozwiązuje Compose Prawdziwa aplikacja rzadko jest jednym kontenerem. Web API potrzebuje bazy danych, baza potrzebuje wolumenu, żeby jej dane przetrwały restart, a potem dochodzi jeszcze cache Redis i worker w tle. To cztery polecenia docker run, każde z własnymi flagami dla portów, wolumenów, zmiennych środowiskowych i wspólnej sieci. W odpowiedniej kolejności. Za każdym razem, gdy siadasz do pracy. Docker Compose zastępuje te polecenia jednym plikiem i jednym poleceniem. Opisujesz kontenery i to, jak się łączą, w pliku o nazwie compose.yaml, a docker compose up uruchamia je wszystkie. Jeśli obrazów i docker run jeszcze nie znasz, przeczytaj najpierw czym jest Docker i jak działają kontenery. ...