Siedzisz w ciemnym pokoju, klepiesz kod. Czasem działa. Czasem nie. Testujesz lokalnie, coś śmiga, wrzucasz na serwer, i już nie śmiga. Nic nie działa. Brzmi znajomo? No właśnie. W którymś momencie możesz zacząć czuć dwie rzeczy. Albo że kupno działki i sadzenie marchwi mogłoby być lepszym wyborem te kilka lat temu, albo, że samo „programowanie” to za mało. Jeśli to drugie to następną myślą mogłoby być, że warto ogarnąć więcej. Trochę backendu. Trochę chmury. A może DevOps?
Ten wpis to nie żaden coachingowy manifest ani tutorial na 200 slajdów. To lekko uchylone drzwi, dzięki którym możesz zerknąć za zasłonę tego świata i poznać tajemnice, jak możesz, jako programista, zrobić pierwszy sensowny krok w stronę świata DevOps. I dlaczego warto zacząć od... kontenerów.
Po co w ogóle ten cały DevOps?
Jeśli DevOps kojarzy Ci się z jakimś dziwnym adminem, który wszystko umie i wszystko automatyzuje — to dobrze. Bo mniej więcej o to chodzi. Tyle że zamiast kabli i śrubokrętów mamy dziś YAML-a, Dockera i skrypty, które robią za nas całą brudną robotę.
DevOps to nie stanowisko. To podejście. Można by rzec, że to filozofia życia. To umiejętność myślenia o systemie jako całości: od kodu, przez testy, aż po infrastrukturę i monitoring. A im więcej ogarniasz, tym większy spokój ducha — bo nie musisz po raz czwarty debugować czemu Twoja apka nie działa na serwerze produkcyjnym, skoro „u mnie działa”.
Okej, ale od czego zacząć, żeby nie spłonąć?
Możesz próbować od razu wejść w Kubernetes i terraformować świat niczym w świecie Gwiezdnych Wojen, ale... po co się męczyć? Najlepszy pierwszy krok to Docker. Serio. Taki mały wielki kontenerek, który zmieni sposób, w jaki patrzysz na swoje aplikacje.
Nie musisz znać wszystkich komend i flag. Wystarczy, że ogarniesz podstawy. A efekt? Twoja apka w kontenerze. Działa wszędzie. Przestajesz się martwić o zależności. I nagle świat jest trochę bardziej przewidywalny.
Dlaczego warto odpalić Dockera?
- Bo raz działa – i działa wszędzie
- Bo pakujesz apkę razem z całym jej bałaganem
- Bo wdrożenia stają się nudne (czyli dobre)
- Bo od tego zaczyna się droga do Kubernetes, CI/CD i innych mądrych skrótów
Co dobrze ogarnąć na początek?
Żeby nie przedobrzyć — oto lista rzeczy, które naprawdę warto poznać zanim zaczniesz rzucać Dockery na produkcję jak ninja.
- Napisz prosty
Dockerfile– np. dla Node, PHP, czy nawet statycznego HTML-a - Zbuduj obraz i uruchom kontener (
docker build,docker run) - Połącz kilka usług przez
docker-compose(np. app + baza danych) - Rozróżniaj: obraz ≠ kontener. I że wolumen to nie wolumin
A przykład?
Spokojnie, przykład będzie. Tylko nie wszystko na raz. Ten tekst to wstęp, nie encyklopedia. Ale jeśli Ci się spieszy to niżej masz prostego gotowca.
# Używamy oficjalnego obrazu PHP z wbudowanym serwerem
FROM php:8.2-cli
# Kopiujemy projekt do kontenera
COPY . /app
# Ustaw domyślny katalog
WORKDIR /app
# Odpalamy komende wewnątrz kontenera
CMD ["php", "-S", "0.0.0.0:8000"]
Co dalej, jeśli Docker już nie robi na Tobie wrażenia?
- CI/CD (zacznij od GitHub Actions, serio)
- Kubernetes (np. przez Minikube – działa lokalnie i nie gryzie)
- Terraform – czyli jak opisać infrastrukturę jak kod
- Monitoring (żeby wiedzieć, że coś się sypie zanim zadzwoni klient)
Na koniec
Można kodzić całe życie i nie interesować się tym, co dzieje się z apką po jej wysłaniu na serwer. Ale można też pójść dalej. Zrozumieć więcej. Zautomatyzować rzeczy, które Cię męczą. I przestać słuchać, że „na prodzie nie działa”.
Nie musisz rzucać wszystkiego i terraformować Marsa. Ale możesz zrobić pierwszy krok. Jeden kontener. Jedna usługa. I nagle wszystko zaczyna się układać w całość.
