„Poprawka gotowa!” …a co z wdrożeniem?
Trzy miesiące po dołączeniu do firmy, kiedy kończył się mój okres próbny, po raz pierwszy dostałem prawdziwe zadanie z produkcji. Była to tylko bardzo prosta poprawka funkcji, ale i tak byłem jednocześnie zdenerwowany i podekscytowany, kiedy kończyłem zmiany w kodzie i wszystkie testy na swojej własnej maszynie, na localhost.
„Szefie, wszystkie testy lokalnie przeszły!”
Team leader skinął głową i kazał mi to wdrożyć. „Dobra robota. Zrób commit do GitLaba, repozytorium kodu jak GitHub, a potem wdroż to na serwer produkcyjny.”
Wdrożyć? W pośpiechu zacząłem przeglądać dokument przekazania obowiązków, który dostałem podczas wdrożenia do firmy. Był pełen nieznanych mi terminów.
Najpierw wrzuciłem kod zgodnie z poleceniem. Został już tylko ostatni krok: połączenie z serwerem produkcyjnym. Naprawdę zacząłem już wstawać od biurka. Jak w serialach, myślałem, że muszę wejść do lodowato zimnej serwerowni, IDC, i pisać bezpośrednio na klawiaturze podłączonej do serwera.
Mój opiekun to zobaczył i roześmiał się. „Dokąd idziesz? Usiądź po prostu i połącz się przez SSH.”
Moje pierwsze spotkanie z czarnym ekranem
Uruchomiłem program o nazwie SSH(Secure Shell), wpisałem adres IP i hasło, które podał mi opiekun, i nacisnąłem Enter. Gdyby to był Windows, przywitałby mnie kolorowy pulpit. Na monitorze pojawił się jednak tylko migający kursor na czarnym tle.
ubuntu@ip-172-31-0-1:~$ _
Nie było żadnych ikon do kliknięcia myszą ani menu pod prawym przyciskiem, żeby utworzyć nowy folder. Spanikowany wciskałem przypadkowe klawisze, a potem wpisałem ls, po czym na ekranie pojawiła się lista plików w czystym tekście.
„A więc to jest ta CLI(Command Line Interface), o której tylko słyszałem.”
Ale prawdziwy strach przyszedł, kiedy próbowałem uruchomić plik. Odpaliłem skrypt update zapisany w instrukcji, a coś, co w Windowsie byłoby zwykłym podwójnym kliknięciem, tutaj wróciło jako czerwony komunikat błędu.
Permission denied (odmowa dostępu)
To był mój własny serwer, a mimo to nie mogłem nic uruchomić. Dlaczego Linux był tak mało przyjazny?
Magazynier cyfrowego centrum logistycznego
Wróćmy do naszej metafory „cyfrowego centrum logistycznego”. Jeśli mój laptop z Windowsem to wygodne prywatne biuro, to serwer Linux jest wielkim magazynem zbudowanym wyłącznie do obsługi logistyki. W tym magazynie leżą dziesiątki tysięcy pudeł, czyli plików.
Gdyby magazynier musiał chodzić i sprawdzać każde pudełko po kolei, GUI, a potem otwierać każde drzwi kluczem, klik po kliku, praca byłaby zdecydowanie zbyt wolna. Dlatego Linux używa krótkofalówki zwanej poleceniami.
„Wyświetl pełną listę pudeł ze strefy 1!” (ls) „Przenieś pudełko 3 do strefy 5!” (mv) „Uruchom to pudełko!” (./start.sh)
To nie jest niewygodne dlatego, że nie ma myszy. Grafika została usunięta celowo, bo kiedy już się przyzwyczaisz, możesz sterować tysiącami plików sto razy szybciej niż za pomocą myszy.
[Code Verification] Absolutne prawo uprawnień
To, co najbardziej dręczy początkujących użytkowników Linuxa, to właśnie problem uprawnień. W Windowsie jedno kliknięcie w „Uruchom jako administrator” rozwiązuje prawie wszystko. Linux za to rygorystycznie sprawdza dla każdego pliku osobno, kto i co może zrobić.
Aby przetrwać, trzeba umieć czytać ten pozornie kosmiczny zapis z ls -l w terminalu.
$ ls -l myscript.sh
-rwxr-xr-- 1 owner group 1024 Jan 1 12:00 myscript.sh
Analiza: klucz tkwi w -rwxr-xr-- na samym początku. Pomijając pierwszy znak -, oznaczający plik, resztę trzeba czytać w grupach po trzy.
Skrypt, który napisałeś, się nie uruchamia? Dziewięć razy na dziesięć brakuje mu po prostu prawa wykonania, czyli x. W tym momencie początkujący często, sfrustrowani, wypowiadają zakazane zaklęcie chmod 777.
# Czego nigdy nie wolno robic
$ chmod 777 myscript.sh
777 oznacza: „Ja, ty i nawet każdy przypadkowy pies na ulicy może modyfikować i wykonywać ten plik.” To odpowiednik szerokiego otwarcia bramy bezpieczeństwa. W prawdziwej pracy to absolutnie zakazane. Trzeba wyrobić sobie nawyk nadawania tylko minimalnie potrzebnych uprawnień, na przykład chmod +x.
chmod 777 jest wygodne, ale równie wygodne robi życie atakującym.Praktyczna rada: pokonać lęk przed terminalem
Kiedy zaczynałem pracę w firmie, mój opiekun kazał mi używać PuTTY jako narzędzia do łączenia się z serwerem. Ale po poszukaniach w internecie znalazłem lepsze narzędzie: MobaXterm. Ten program po połączeniu przez SSH pokazywał po lewej stronie listę plików przez SFTP, niemal jak eksplorator plików na moim własnym komputerze.
Dzięki temu nawet bez znajomości komend terminala mogłem otwierać pliki podwójnym kliknięciem, edytować je i zapisywać. Ale jeśli polegasz tylko na takich skrótach, nigdy naprawdę nie zaprzyjaźnisz się z Linuxem. W awaryjnej sytuacji na produkcji nie ma czasu czekać, aż uruchomi się narzędzie GUI.
Na koniec: ten, kto panuje nad środowiskiem
Opuszczenie szklarni zwanej Windows i przystosowanie się do dziczy zwanej Linuxem jest bolesne. Ale kiedy przejdziesz przez ten ból, zyskujesz poziom kontroli, jakiego myszką nigdy nie osiągniesz.
Linux nie jest już nieznanym terytorium. Ale pozostaje jeszcze jeden podstawowy problem. Co jeśli na moim laptopie, czyli w środowisku developerskim, jest Java 17, a na serwerze Linux, czyli w środowisku deployowym, tylko Java 8? Albo jeśli jakaś biblioteka istnieje na Linuxie, ale nie ma jej na moim Windowsie?
Wymówka „Ale u mnie działa” bierze się z różnic między systemami operacyjnymi i wersjami bibliotek. Czy nie dałoby się całkowicie wyeliminować tej różnicy środowisk? Czy nie można by zamrozić środowiska mojego laptopa i przenieść go wprost na serwer?
Istnieje technologia, która zamieniła tę pozornie absurdalną wizję w rzeczywistość. Następnym razem porozmawiajmy o Dockerze, technologii, która wyszła poza wirtualizację i wywołała rewolucję kontenerową.