Kontenery vs maszyny wirtualne — rewolucja w deploymencie

Czy kiedykolwiek zastanawiałeś się, dlaczego firma Netflix może uruchomić tysiące usług jednocześnie, a Twoja aplikacja na serwerze firmy czasem "nie działa, bo środowisko inne"? Odpowiedź kryje się w rewolucji konteneryzacji, która zmieniła sposób, w jaki tworzymy i wdrażamy aplikacje.

Tradycyjne podejście — maszyny wirtualne

Wyobraź sobie, że chcesz uruchomić prostą aplikację webową w Node.js. Tradycyjnie tworzysz maszynę wirtualną, która musi zawierać:

Pełny system operacyjny (Ubuntu 22.04 = ~2.5 GB)
Wszystkie biblioteki systemowe i sterowniki
Runtime aplikacji (Node.js)
Twoją aplikację (~50 MB)

Efekt? Jedna aplikacja zajmuje 4+ GB miejsca i potrzebuje 3-5 minut na uruchomienie. Netflix musiałby mieć tysiące serwerów tylko na hosting systemu operacyjnego!

Tekst

┌─────────────────┐ ┌─────────────────┐
│   Node.js App   │ │   Python API    │
│   (50 MB)       │ │   (100 MB)      │
│   Ubuntu 22.04  │ │   Ubuntu 22.04  │
│   (2.5 GB)      │ │   (2.5 GB)      │
├─────────────────┤ ├─────────────────┤
│     VMware / VirtualBox (Hypervisor)     │
├──────────────────────────────────────────┤
│           Host OS (Windows/Linux)        │
└──────────────────────────────────────────┘

Rewolucja kontenerów

Kontener to jak wynajęcie mieszkania w apartamentowcu zamiast kupowania całego domu. Współdzielisz infrastrukturę (windę, ogrzewanie, wodę), ale masz własną przestrzeń życiową.

Ta sama aplikacja Node.js w kontenerze:

Obraz bazowy (node:18-alpine = 170 MB)
Twoja aplikacja (~50 MB)
Całość = 220 MB i uruchomienie w 2-3 sekundy!

Tekst

┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│  Node.js App │ │  Python API  │ │    Redis     │
│   (220 MB)   │ │   (280 MB)   │ │   (130 MB)   │
├──────────────┤ ├──────────────┤ ├──────────────┤
│          Docker Engine (Container Runtime)         │
├────────────────────────────────────────────────────┤
│              Host OS (Linux)                       │
└────────────────────────────────────────────────────┘

Magiczne mechanizmy Linuxa

Kontenery nie są magią — to sprytne wykorzystanie funkcji jądra Linux:

Namespaces — własny świat dla aplikacji

PID namespace: Twoja aplikacja myśli, że jest jedynym procesem (PID 1)
Network namespace: Ma własny interfejs sieciowy (172.17.0.2)
Mount namespace: Widzi tylko swoje pliki, nie cały dysk hosta

Cgroups — sprawiedliwy podział zasobów

Terminal

# Kontener może użyć max 512 MB RAM i 0.5 CPU
docker run -m 512m --cpus="0.5" nginx

Wskazówka: Sprawdź, jakie procesy widzą Twoje kontenery komendą docker exec -it [kontener] ps aux. Zobaczysz, że aplikacja myśli, że jest sama w systemie!

Praktyczne różnice w liczbach

Porównajmy wdrożenie e-commerce z 5 usługami (frontend, API, baza danych, cache, kolejka):

Maszyny wirtualne

Rozmiar całkowity: 15+ GB (5 × 3 GB każda VM)
Czas startu: 15-25 minut (wszystkie usługi)
Zużycie RAM: 8+ GB (po 1.5 GB na VM)
Koszt AWS: ~$200/miesiąc (5 instancji t3.medium)

Kontenery

Rozmiar całkowity: 2 GB (suma wszystkich obrazów)
Czas startu: 30-60 sekund
Zużycie RAM: 2-3 GB (tylko aplikacje)
Koszt AWS: ~$50/miesiąc (1 instancja t3.large)

Kiedy użyć kontenerów, a kiedy VM?

Kontenery wybierz gdy:

Budujesz mikrousługi
Potrzebujesz szybkie CI/CD
Chcesz oszczędzać zasoby
Wszystkie usługi działają na Linux

VM zachowaj gdy:

Potrzebujesz różnych systemów operacyjnych
Wymagana jest silna izolacja bezpieczeństwa
Uruchamiasz legacy aplikacje monolityczne

Podsumowanie:

Kontenery są 10x szybsze w uruchomieniu niż VM
Zajmują 5-10x mniej miejsca niż pełne maszyny wirtualne
Pozwalają uruchomić 10x więcej aplikacji na tym samym sprzęcie
Rozwiązują problem "u mnie działa" przez identyczne środowiska