w Praktyce
10 godz. 44 min · Node.js · Full-stack i Programowanie
Piotr PalarzWeb DeveloperW kursie tym poznasz platformę Node.js od podstaw, aż po bardziej zaawansowane koncepcje. Zaczniemy od omówienia czym jest Node, a także jakie może być zastosowanie tej technologii. Następnie przejdziemy przez proces instalacji i napisanie swojego pierwszego skryptu. Już na samym początku dokładnie omówimy tworzenie własnych modułów, gdyż jest to wiedza niezbędna, by dobrze zrozumieć funkcjonowanie Node. Następnie dowiesz się czym są zdarzenia, jak działa model “publish / subscribe”, a także czym jest “event-driven development”. Chwilę później omówimy pracę z buforami, stream’ami, a także ze standardowym wejściem i wyjściem. Ta wiedza pozwoli Ci zrozumieć jak tworzone aplikacje mogą otrzymywać od użytkownika dane oraz jak je wyświetlają.
Niezwykle ważnym rozdziałem będzie ten, poświęcony pracy z systemem plików. Szczególnie dla dewelopera, pracującego dotychczas z językiem JavaScript wyłącznie w środowisku przeglądarki internetowej. Node pozwala bowiem tworzyć nowe pliki, zapisywać w nich dane oraz odczytywać i usuwać pliki i katalogi. Przy wszystkich tych operacjach, niezwykle ważna jest jednak asynchroniczna natura Node. Dowiesz się jak działa, a także jakie są jej zalety. Na tym etapie nie zabraknie oczywiście praktycznego projektu, którym będzie aplikacja typu CLI (Command Line Interface). Pozwoli nam ona grupowo zmienić nazwy wielu plików, według podanego wzorca.
W kolejnym rozdziale poruszymy fundamentalną dla Node kwestię, mianowicie tworzenie serwerów sieciowych. Zaczniemy od najniższego poziomu, tworząc prosty serwer bazujący na protokole TCP/IP. Wiedza w jaki sposób Node radzi sobie z takim zadaniem, pozwoli później lepiej zrozumieć wyższe warstwy, takie jak np. HTTP czy WebSockets. Chwilę później stworzymy swój pierwszy serwer HTTP, do którego będzie można wysyłać zapytania wprost z przeglądarki internetowej. Omówimy również jak w Node wykorzystać bezpieczne szyfrowanie HTTPS.Na tym etapie będziesz już miał solidną wiedzę jak pracować z Node, jednak zanim przejdziemy dalej, zatrzymamy się, by omówić jak dokładnie działa Node.js, a także jak ta platforma została zbudowana. Dwie dość obszerne lekcje, będą być może jednymi z najważniejszych w tym kursie. Dowiesz się w nich czym jest, a także jak działa jednowątkowa pętla zdarzeń, czym jest proces i wątek, a także zobaczysz kod źródłowy Node.js i wszystkie bloki budulcowe, z jakich Node się składa. To naszym zdaniem niezwykle ważny temat, często jednak pomijany w wielu materiałach. Dzięki dogłębnemu zrozumieniu jednowątkowej natury języka JavaScript i asynchroniczności Node, będziesz mógł tworzyć dużo lepsze aplikacje.
Node.js posiada kilkanaście wbudowanych modułów, z których w dowolnej chwili można skorzystać. Wszystkie jednak dają nam dużą, niskopoziomową kontrolę, ale czasami sporo kodu należy napisać, by zrealizować jakieś zadanie. Jest to jednak świadomy wybór twórców Node, gdyż całą resztę świetnych rozwiązań, dopisuje nieustannie ogólnoświatowa społeczność deweloperów. Zdecydowana większość z modułów ląduje w rejestrze npm. Jest to genialny package manager, który pozwoli nam wyszukiwać, pobierać i aktualizować niezliczoną ilość modułów. Dowiesz się zatem jak korzystać z npm, a chwilę później zaczniemy wykorzystywać zgromadzone tam moduły w dalszej pracy.Jednym z najpopularniejszych modułów jest express.js, który pozwala w bardzo prosty sposób tworzyć serwery HTTP. Grzechem byłoby zatem z niego nie skorzystać. Dowiesz się wszystkiego co niezbędne, by zacząć tworzyć własne aplikacje bazujące na protokole HTTP z użyciem express.js, a także kilku dodatków do tego systemu. Zobaczysz jak routować zapytania, jak korzystać z middleware czy serwować statyczne pliki. Następnie omówimy współpracę z bazą danych MongoDB i z jej wykorzystaniem stworzymy API typu REST. Stworzona aplikacja pozwoli odczytywać dane z bazy i przesyłać je do klienta w formacie JSON, a także dodawać nowe dane, aktualizować i usuwać je. Wszystko to zgodnie z dobrymi praktykami pracy z REST.
Chwilę później czeka Cię kolejny praktyczny projekt - skracacz linków. Stworzymy wspólnie aplikację, która pozwoli skrócić dowolny adres URL do krótkiej formy. Oczywiście będzie działać również w drugą stronę! Kiedy przejdziemy pod skrócony adres, przekieruje nas do odpowiedniej witryny. Node.js to platforma wręcz stworzona do tworzenia aplikacji typu real-time, dlatego w kolejnym rodziale podejmiemy temat technologii WebSockets. Dowiesz się jakie są jej zalety, a także jak pracować z nią po stronie serwera i klienta. Tutaj czeka nas kolejny praktyczny, niezwykle ciekawy projekt. Wykonamy bowiem czat grupowy. Aplikacja ta pozwoli dowolnej ilości użytkowników podłączyć się do czatu podając swój nick, a następnie wysyłać widoczne dla wszystkich wiadomości. Zaimplementujemy nawet takie rozwiązania jak wyświetlanie statusów o dołączeniu kogoś do czatu, a także o jego opuszczeniu.W przedostatnim rodziale tego kursu podejmiemy tematykę dobrych praktyk pracy z Node.js. Na początku omówimy najważniejsze konstrukcje nowej specyfikacji EcmaScript 2015, które są znakomicie wspierane w Node. Chwilę później omówimy jak korzystanie z Promises uprości, a także ulepszy nasz kod. Wśród dobrych praktyk nie zabraknie również informacji o debugowaniu aplikacji. Zobaczysz sprawdzone sposoby, by znaleźć błędy lub lepiej, krok po kroku, zrozumieć jak działa napisany wcześniej kod. Dowiesz się również jak pracować z błędami, by Twoje aplikacje działały w sposób przewidywalny.
Ostatni rozdział w całości został poświęcony temu, co zwykle jest pomijane w innych materiałach, mianowicie wdrażaniu aplikacji do produkcji. Przez cały ten kurs pracować będziemy lokalnie, lecz kiedy aplikacje są już gotowe, wypadałoby udostępnić je światu. Wdrażanie aplikacji napisanych z użyciem Node.js nie jest jednak tak oczywiste, jak np. wgrywanie WordPress’a u wybranego hostingodawcy. Ty będziesz miał jednak możliwość zobaczyć, jak wdrożyć napisany przez nas grupowy czat na platformie Heroku. Jest to bardzo popularny serwis działający jako PaaS (Platform as a Service). Za darmo będziesz mógł w ciągu kilku chwil uruchomić swoją aplikację.Zobaczysz o co należy zadbać, by wszystko poszło gładko. Serwisy typu PaaS dbają o bardzo wiele aspektów wdrażania i serwowania naszych aplikacji, takich jak bezpieczeństwo oraz nieustanną dostępność. Mają jednak pewne ograniczenia. Z tego powodu, dowiesz się również jak wdrożyć swoją aplikację na serwerze wirtualnym VPS z systemem Ubuntu Server. Takie rozwiązanie daje nam całkowitą kontrolę, ale także obarczone jest większą odpowiedzialnością. Zaczniemy od instalacji na serwerze platformy Node.js, systemu kontroli wersji GIT, a także innych niezbędnych modułów
Następnie zobaczysz jak skonfigurować swoje lokalne środowisko tak, by za pomocą GIT’a wysyłać kod do zdalnego serwera, a potem jednym poleceniem wdrażać go do produkcji. Dowiesz się również jak jednocześnie serwować wersję produkcyjną oraz developmencką. W rodziale tym poruszymy również inne kwestie, takie jak procesy potomne czy tworzenie klastrów. Dzięki tej wiedzy, będziesz mógł maksymalnie wykorzystać dostępne zasoby serwera. Na sam koniec tego kursu rzucimy okiem również na inne, nie przedstawione wcześniej zastosowania Node, a także nakreślimy dalszą drogę nauki w tym zakresie.
Kurs ten jest dla wszystkich osób, które dobrze czują się w technologiach frontendowych, tj. HTML, CSS i JavaScript, a teraz chcą rozpocząć swoją przygodę z back-endem. Im zatem lepiej znasz język JavaScript, tym więcej wyciśniesz z Node, natomiast nie jest wymagana bardzo zaawansowana wiedza z zakresu tego języka.
W tej lekcji pokażę ci, w jakiś sposób naszą aplikację czata umieścić na serwerze produkcyjnym, a będzie to
nasz własny serwer VPS, który jest uruchomiony we Francji na systemie Ubuntu Server.
Jeżeli nie masz takiego VPS-a, po prostu obejrzyj sobie tę lekcję, aby zobaczyć, jak to wszystko mniej
więcej działa. Natomiast możesz również lokalnie zainstalować sobie za darmo taki system, pobierając program
VirtualBox. I w tym programie możesz stworzyć nową maszynę wirtualną, pobierając sobie również obraz
Ubuntu Server - także za darmo. I wtedy taki serwer sobie lokalnie zainstalujesz i możesz się z nim łączyć,
robić dokładnie to samo, co robiłem ja, ale nie będzie to wykonywane gdzieś we Francji, ale u ciebie na
komputerze. W lekcji poprzedniej pokazałem ci, jak umieścić aplikację na Heroku, czyli w takim systemie,
który nazywa się Platform as a Service.
Oni tam dbają o bardzo dużo rzeczy, m.in. o łatwy deployment,
o to, aby to wszystko było bezpieczne i szybkie. Natomiast w przypadku własnego serwera VPS musimy posiadać
dużo większą wiedzę z zakresu zarządzania serwerem Linuxa.
Po pierwsze to my bierzemy odpowiedzialność za wszystkie błędy, które mogą się pojawić, za to, że serwer
się wyłoży, a także za bezpieczeństwo. Dlatego jest to dużo trudniejsze i obarczone większą odpowiedzialnością.
Być może jako developer Node.js, jeżeli kiedyś będziesz gdzieś pracował w jakiejś firmie albo już to robisz,
nie będziesz musiał tak naprawdę robić deploymentu, bo ktoś to zrobi za ciebie. Ty będziesz tylko pisał dobry
kod. Ale chcę ci w tej lekcji pokazać, jak to wszystko można zrobić na własnym serwerze VPS,
abyś miał pojęcie, gdyby kiedyś okazało się to dla ciebie przydatne lub chciałbyś swoją aplikację umieścić
na takim serwerze.
Zanim przejdziemy dalej, to jedna bardzo ważna informacja. Wszystko będę pokazywał od zera.
Natomiast trzeba już wcześniej mieć serwer i potrafić się do niego podłączyć. Ja skonfigurowałem sobie
już klucze SSH,
czyli mogę do serwera się podłączać i nie będę tego wszystkiego dokładnie tłumaczył.
Natomiast za pomocą SSH można się podłączyć do serwera, wpisując nazwę użytkownika, następnie adres swojego
serwera - w tym przypadku będzie to taki serwer. W momencie, kiedy ten kurs oglądasz, już nie będzie on poprawnie
działał, dlatego proszę, nie próbuj się do niego logować.
I teraz jeżeli wcisnę Enter, to zalogowaliśmy się i jesteśmy na tym serwerze.
Teraz wszystko, co tutaj wpiszę, jest wykonywane na serwerze wirtualnym, który tak jak wspomniałem, jest
zlokalizowany we Francji. Czyli tutaj już nie będą działać polecenia, które działały u mnie w terminalu.
Gdybyś był na Windowsie, to też nie będą windowsowe działać, ale tutaj będę wykonywał polecenia, które
działają w Shellu Ubuntu Server, czyli właśnie tam, gdzie jesteśmy teraz podłączeni. Wyczyszczę sobie ten ekran
i musimy na serwerze zacząć od tego, żeby zainstalować sobie Node.
Wspominałem w lekcji poprzedniej, że czasami trudno jest znaleźć dobrych, polskich dostawców hostingu Node.js,
a np. w PHP możemy już znaleźć ich bardzo wielu.
Jeżeli chodzi o serwer VPS,
tutaj możemy zainstalować, co chcemy.
Jeżeli chcę mieć Ruby, to sobie zainstaluję. Jeżeli chcę Node czy PHP - nie ma problemu.
Mógłbym nawet postawić tutaj serwer Counter Strike - też nie ma żadnego problemu.
To jest po prostu komputer, do którego mamy dostęp i możemy na nim zrobić dowolne rzeczy.
Zaczniemy od instalacji Node.js. Będzie to wyglądać dokładnie tak samo jak w lekcji na samej górze tego
kursu, na samym początku, gdzie pokazywałem, jak na Linuksie zainstalować Node. Czyli wpiszemy coś takiego.
W ten sposób pobierzemy sobie odpowiedni skrypt, który za moment pozwoli nam zainstalować Node.
Ok.
Udało się. Jeżeli piszę ls, to mamy taki skrypt i teraz go po prostu uruchomię.
Wpiszę sudo bash i nodesource_setup.sh.
Muszę podać hasło na serwerze.
Wciskam Enter i chwilę sobie poczekamy.
I teraz będę mógł już wpisać sudo apt-get install nodejs.
W ten sposób Node nam się zainstaluje, również npm. Będziemy to już mieli na serwerze. Zaraz sobie to zweryfikujemy.
Ok. Możemy wpisać node version, tak jak to robiliśmy wcześniej. Została zwrócona, podobnie npm, a to oznacza,
że na serwerze już wszystko jest w porządku.
Teraz druga rzecz, jakiej potrzebujemy, to zainstalować sobie Gita.
Więc wpiszę sudo apt-get install git.
Git nam się również pobierze, instalacja jak widzisz na Linuksie jest bardzo prosta.
Mamy już Gita, sprawdźmy jaką wersję. W porządku. I teraz będziemy chcieli sobie utworzyć puste repozytorium
w miejscu, do którego będziemy robić za moment deployment.
Jeżeli obejrzałeś lekcję poprzednią, tam pokazywałem, jak łatwo możemy robić deployment na Heroku i chciałbym
coś podobnego pokazać ci w przypadku VPS. Bo mógłbym tutaj oczywiście zainstalować serwer FTP i za
pomocą jakiegoś klienta FTP wszystkie nasze pliki wysłać, później zalogować się do tego serwera, tak jak
to zrobiłem tutaj, przejść do odpowiedniego katalogu i wpisać node i np. index.js, tak jak to robiliśmy.
Ale ja chcę ci pokazać, jak to robić w sposób taki podobny jak na Heroku, abyśmy mogli Gitem coś wysłać i następnie
odpowiednio to uruchomić.
Przejdziemy do katalogu, który nazywa się srv. Jest taki katalog w Linuksie i najlepiej do niego
umieścić serwer. Natomiast żeby mój użytkownik Piotr miał do niego dostęp i za moment kiedy z mojego
Maca będziemy tam coś wysyłać Gitem, abyśmy nie mieli błędów, musimy tutaj dla Piotra przypisać odpowiednie
uprawnienia.
Jest to bardzo ważny krok, dlatego wpiszę sobie sudo chown -R i następnie nazwa użytkownika,
drukropek, nazwa użytkownika i ścieżka do katalogu.
W ten sposób będę miał do niego już dostęp.
Jak widzisz, wszystko się udało i teraz będąc w tym katalogu, wpiszemy sobie
git init,
czyli tworzymy nowe repozytorium, --bare -
w ten sposób tworzymy nowe repozytorium, które będzie puste. I może nawet podam tutaj pełną ścieżkę, czyli
wtedy nie ma znaczenia, gdzie jestem. Chcę utworzyć pod tym katalogiem srv katalog git i w nim chat.git.
Tak będzie się nazywać repozytorium.
Jak widzimy, wszystko się udało i teraz do niego z mojego Maca, czyli z lokalnej maszyny, będziemy mogli
już wysyłać sobie gity.
Jak to można zrobić? Otworzę nowe okno terminala i to nowe okno jest już otwarte u mnie na Macu. Czyli
to, co będę wpisywał, jest lokalne, a to, co wpisuję tutaj, wykonuje się na serwerze VPS. Czyli teraz jesteśmy
w katalogu 46.
Mamy tutaj nasz czat, więc utworzę sobie Gitem, który mam u mnie na komputerze z kolei, lokalne repozytorium
git init.
Ok.
Teraz git - plik ignore w zasadzie będę chciał utworzyć - czyli .gitignore. W Sublime Text chciałbym do niego
wpisać node_modules.
Czyli nie chcę tego wysyłać. Ok.
I teraz jeżeli wpiszę git status, to będziemy widzieć wszystkie pliki oprócz katalogu node_modules. Jego nie będziemy
wysyłać. Będziemy to instalować na serwerze.
Teraz napiszę git add. Dodamy sobie wszystko. Git status pokaże nam, że zostało to faktycznie dodane i teraz
możemy zrobić git commit. I napiszemy tutaj Initial message.
A w zasadzie Initial commit.
Nie wiem, czy oglądałeś lekcję poprzednią.
Jeżeli nie, to jeśli chodzi o Gita,
na eduweb.pl znajdziesz warsztat na ten temat.
Ok. Udało się i teraz chciałbym móc wysłać to wszystko za pomocą git push na serwer.
Nie chcę się bawić w żadne FTP, chcę to wysyłać Gitem. Abyśmy to mogli zrobić, musimy sobie dodać remote dla
Gita. Czyli wpiszę git remote add origin i muszę podać ścieżkę.
Natomiast ta ścieżka będzie z użyciem ssh. Czyli ssh i następnie nazwa użytkownika piotr@vps.eduweb.pl, czyli
ścieżka na lokalny serwer /srv, czyli dokładnie ten katalog, który mieliśmy tutaj. I w tym katalogu
będziemy mieli katalog git, bo już go tam utworzyłem, i repozytorium chat.git.
Wpiszemy sobie to w ten sposób. I teraz mój lokalny Git już wie, że jeżeli będę chciał coś wysyłać,
to ma to wysłać na taki serwer. SSH mamy już skonfigurowane, tak jak mówiłem wcześniej, więc przyjmie to wszystko
i powinno to zostać tutaj umieszczone.
Gdybym tutaj wcześniej nie wpisał chown, czyli nie nadał odpowiednich uprawnień Piotrowi, to mielibyśmy
błędy.
Natomiast w przeciwnym wypadku powinno to wszystko działać, dlatego spróbujmy sobie teraz zrobić git
push origin master, czyli na tego origina, którego przed momentem dodałem, chcę to wysłać. Po chwili widzimy, że
to się udało, dlatego przejdę do karty, gdzie jesteśmy na serwerze. Zobaczę ls.
Przejdę do katalogu git, który się tutaj znajduje, i mamy chat.git.
I tutaj zostało to wszystko odpowiednio przesłane.
Czyli mamy na naszym serwerze już naszą aplikację i w zasadzie mógłbym ją tutaj uruchomić i prawie wszystko
działałoby poprawnie.
Natomiast ja chcę ją wysyłać i monitorować za pomocą specjalnego programu,
czy w zasadzie modułu Node, który, jak widzisz, można globalnie zainstalować, który nazywa się PM2.
Zaraz zobaczysz, jak go zainstalować. Będziemy go potrzebowali lokalnie, a także na serwerze.
Dlatego może najpierw tutaj będąc na serwerze, wpiszę sudo npm, bo npm już mamy zainstalowany,
install -g pm2. Zainstaluje nam się ten PM2 manager na serwerze i teraz w tym samym czasie w zasadzie
mogę go również zainstalować u siebie, lokalnie w systemie. Czyli npm install -g pm2. Również chcę sobie
go pobrać. Ok. Mamy go lokalnie i teraz będąc w tym katalogu, gdzie jesteśmy, chcę wpisać pm2. Mogę z niego
korzystać. On pozwala uruchamiać aplikacje. Ale wpiszemy ecosystem
i utworzył nam się tutaj taki plik.
Jeżeli przejdziemy do edytora Sublime Text, to zobaczymy, że plik ecosystem.json się tutaj utworzył.
On nie jest do końca poprawnym json-em, bo to powinno być w cudzysłowach.
Dlatego zmienię sobie jego syntaks na ten plain text.
Będzie to dla nas trochę lepiej wyglądać.
No i tutaj możemy go odpowiednio skonfigurować.
Mamy tutaj first application i second - ja drugą usunę.
Tutaj skrypt przestawimy sobie na index, bo nasz nazywa się index - jest to ważne.
Pozostałe rzeczy tutaj nie są istotne, można je usunąć,
aby to wszystko było tutaj czyste.
Teraz przejdziemy niżej.
To jest ważne. Mamy tutaj deploy, mamy production oraz development. Będziemy mogli sobie wysłać ten kod i uruchomić
jako wersję development, a także production i teraz odpowiednio będę chciał to skonfigurować.
Tutaj gdzie mamy host, będę musiał podać adres do mojego serwera VPS, czyli vps.eduweb.pl, następnie
ref: origin/master - standardowo.
I tutaj możemy podać adres do repozytorium Gita, z którego będzie pobierane to wszystko. Dlatego wcześniej
skonfigurowałem Gita na serwerze i możemy już na serwer wysyłać kod, że kiedy ten kod wyślemy, to wtedy
będziemy PM2 uruchamiać i chcę mu powiedzieć, skąd ma pobrać sobie takie repozytorium.
I w tym przypadku chcę, żeby nie pobierał go gdzieś z internetu, tylko właśnie z katalogu srv, który
ma już na serwerze, bo to będzie na serwerze,
następnie git i tam było chat.git.
Coś takiego chcę tutaj wpisać.
A to zmienimy sobie również na srv/www/production.
Czyli w katalogu srv będziemy mieli git, a także www, z którego będzie serwowana wersja
produkcyjna.
To jest pierwsza rzecz. I tutaj chcemy zrobić rzecz taką samą, więc to uzupełnię.
Ok.
Gotowe.
I zauważ, że tutaj jeszcze w tym dev mamy coś takiego jak env.
Tutaj możemy podawać zmienne środowiskowe, które będą dla naszego skryptu przekazywane, więc w przypadku
development mamy tutaj NODE_ENV: "dev".
Z tego będzie można skorzystać jako process.env.NODE_ENV. I teraz to, co jest super ważne, to zauważ,
że mamy coś takiego jak post-deploy.
I tutaj jest jakby skrypt do wykonania.
Chodzi o to, że kiedy wykonamy sobie za moment pm2 deploy, to zostanie na serwer jakby to wszystko wysłane.
Gitem musimy to wysłać wcześniej, ale na serwerze zostanie to uruchomione i później zostanie uruchomione
to, co jest wpisane tutaj.
Czyli tak jakbym przeszedł na serwer i ręcznie sobie wpisał npm install.
Więc zauważ, że będzie to tak jak w przypadku Heroku z lekcji poprzedniej. Wszystko nam zostanie zainstalowane
i kiedy to się uda, to takim znaczkiem możemy kolejny proces wykonać. Wykonamy na serwerze pm2
startOrRestart ecosystem.json --env production. Czyli to jest takie polecenie, które na serwerze możemy
wykonać, ale ono wykona się automatycznie. Zaraz zobaczysz, w jaki sposób.
Ok. Zapisałem sobie ten plik i teraz możemy go zamknąć. I będąc tutaj lokalnie na Macu, mogę sobie wpisać
coś takiego: pm2 deploy.
Zauważ, że kod już wysłaliśmy za pomocą Gita.
Podajemy nazwę pliku ecosystem, czyli ten, który jest w tym katalogu. I teraz czy chcemy production czy development?
Wpiszę dev. Może ja ten plik otworzę, żeby ci pokazać jeszcze, co tam się dzieje. Zmienię go na plain, żeby był czytelny.
Tutaj mieliśmy coś takiego jak production, a tutaj dev. Czyli to dev jeżeli podaję tutaj, to jest dokładnie to.
Jeżeli wpisałbym production, to będzie wykonane jakby kod czy settings, które są wpisane w tym miejscu.
I teraz jeszcze musimy dopisać setup, dlatego że gdybyśmy na serwerze sobie zerknęli... Jesteśmy w Git,
ale przejdźmy jeden katalog wyżej.
Ls - mamy tutaj git, ale nie mamy tej ścieżki, którą podaliśmy, np. www/production. Dlatego chcemy to zrobić.
I tutaj wpisując u siebie w systemie coś takiego, zostanie to wszystko odpowiednio wysłane i ustawione,
jeśli się uda.
Jak widzisz, coś poszło nie tak.
Zerknijmy sobie do pliku ecosystem. Ok. Widzę, że użytkownika nie wpisałem poprawnie.
Tutaj ten użytkownik node to musi być piotr. Czyli tak jak się logowałem
piotr add vps itd.
Spróbujmy to zrobić raz jeszcze. Teraz powinno się już udać.
Jak widzimy, udało się i cała nasza aplikacja została tam jakby załadowana.
Podawaliśmy tutaj, że repozytorium Gita, które ma sobie wyszukiwać, ma taką jakby lokalną ścieżkę, czyli na serwerze.
Przed momentem wysłaliśmy Gitem tam cały kod, a teraz PM2 wysłał tam to, co miał wysłać. I za pomocą setup sobie to
ustawił, m.in. klonując to repozytorium.
Czyli teraz gdybyśmy sobie tutaj zerknęli, ls, pojawił się katalog www.
Przejdźmy do niego. I w tym katalogu mamy development.
Wszystko jest w porządku, a do tego katalogu development jeśli byśmy przeszli i do source, to znajdziesz
tutaj aplikację naszego czata, która została skopiowana właśnie z Gita, a tego Gita mamy troszeczkę
wyżej. Przejdźmy sobie kilka katalogów wyżej.
W tym miejscu właśnie mamy Gita. Czyli tu będziemy wysyłać Gitem, a PM2 będzie stąd sobie kopiował do katalogu
www.
I teraz pokażę ci, jak tę aplikację możemy uruchomić.
Natomiast zanim to zrobimy, to przejdziemy sobie najpierw w miejsce, które mamy w public > js.
Nie wiem, czy pamiętasz, ale w czacie wpisywaliśmy coś takiego: io.connect. Chciałbym sobie to usunąć i ustawić
na taki pusty parametr, żeby tutaj nic nie podawać. Wtedy io automatycznie połączy się tam, gdzie powinno. Będzie wszystko w
porządku. W pliku index z kolei mamy tutaj port 8080. Na moim serwerze VPS
jest on odblokowany, to bez problemu powinno działać.
Tylko że teraz musimy raz jeszcze wysłać ten kod. Wpiszemy git status.
Zobaczymy, że coś się zmieniło, więc będę chciał zrobić git commit, dodać wszystko, czyli -am. Mamy taką możliwość.
I wpiszemy sobie tutaj powiedzmy:
dodano ecosystem.
Ok i zrobimy git push origin master, aby to wszystko wysłać na serwer.
W porządku. I teraz wpiszemy znowu pm2 deploy ecosystem.json dev. Natomiast teraz już nie będę dopisywał setup. Zobaczymy.
W ten sposób nasza aplikacja powinna zostać już uruchomiona. Ok. Zobaczmy. Gdzieś tam po drodze zostanie uruchomiony
skrypt, który był w tym ecosystemie tutaj zdefiniowany. Jesteśmy w dev, czyli w tym miejscu. A więc npm install,
czyli wszystko powinno zostać zainstalowane. O, i nawet to zobaczyliśmy. Działa to podobnie jak w Heroku. I później
na serwerze wykona się pm2.startOrRestart.
O tych rzeczach, czyli o tych komendach, możesz sobie poczytać na stronie właśnie pm2. To zostanie tam zrobione
i wykonany zostanie odpowiedni plik. Możemy go również ręcznie wykonywać - takie polecenie na serwerze.
Czyli teoretycznie powinno to teraz działać.
Widzimy jednak, że coś poszło nie tak, bo mamy tutaj kolejny błąd.
Jak widzisz, nie jest to aż tak proste, że wszystko wpiszemy, od razu zadziała. File ecosystem.json not found.
No to zobaczmy, co tutaj się stało.
Po pierwsze przypomnę ci, że mamy tutaj zainstalowany na serwerze PM2. I PM2 pozwala nam wpisać list
i zobaczyć wszystkie uruchomione aplikacje. Widzimy - nie ma tutaj żadnej aplikacji póki co, więc wyczyszczę
ekran.
Jesteśmy w srv.
Przejdźmy sobie do www. Przejdziemy do development, do source i widzimy, że faktycznie brakuje tutaj pliku ecosystem.
Prawdopodobnie Git mi go tutaj nie dodał.
Więc będąc tutaj na lokalnej maszynie, wpiszmy git status. Widzimy, że właśnie ten plik się nie dodał,
jeżeli wpisałem wcześniej commit. Dlatego muszę wpisać git add.
W ten sposób - ręcznie. Teraz git status. Ok.
Ten plik się dodał.
I raz jeszcze powtórzę wszystkie kroki, czyli commit, message:
poprawiony ecosystem. I teraz zrobimy git push origin master. Ok. Wszystko się wysłało i teraz zrobimy pm2
deploy ecosystem i dev.
Teraz już powinno się udać. Poczekajmy.
Ok. I teraz zobaczyliśmy, że mamy success, czyli jeżeli przejdę na serwer i wpiszę sobie tutaj pm2 list, to
powinniśmy mieć jakąś uruchomioną aplikację.
Okazuje się, że jest. Zróbmy sobie tutaj więcej miejsca.
Mamy aplikację, która znalazła się w tym oto miejscu.
No i możemy sobie z niej skorzystać. Ma ona nazwę API, dlatego że jeszcze tutaj zapomniałem zmienić tę nazwę na
chat, ale to zrobimy sobie za moment. Nie jest to tak istotne.
Czyli teraz jeżeli przejdę sobie na port 8080 na stronie vps.eduweb.pl,
to nasz czat powinien działać.
No i jak widzisz, dokładnie tak się stało.
Nasza aplikacja została poprawnie wgrana na serwer.
Za moment pokażę ci jeszcze, jak ją można uruchomić na porcie 80.
Może zróbmy sobie to od razu. Przejdziemy sobie u nas tutaj w Sublime Text do miejsca, gdzie mieliśmy deploy. I mieliśmy coś
takiego jak zmienne środowiskowe tutaj.
Więc dlaczego by sobie nie dodać tutaj takich zmiennych.
Możemy to zrobić.
Jedną z takich zmiennych, którą chcę wstawić, będzie port i napiszę tutaj 80.
W ten sposób w naszym index tutaj będziemy mogli się odwołać do process.env.port.
Jeżeli został podany, a jeżeli nie, to będzie 8080.
Czyli jeżeli będziemy uruchamiać wersję dev, to on nie jest podany. Jeszcze jedna ważna uwaga - to mówiłem ci,
że ten post-deploy jest uruchamiany na serwerze, więc PM2 na serwerze się uruchamia w ten sposób - z
ecosystemem i w miejscu, w którym dodaję sobie env production. To znaczy, że ma uruchomić to, co znajduje
się tutaj, czyli z katalogu srv/www/production.
Natomiast jeżeli będziemy wysyłać to, co jest tutaj, to uruchomi się z tego jakby katalogu development.
Dlaczego ci to chcę pokazać?
Może zatrzymam aplikację, która jest na serwerze. Można wpisać pm2 stop i następnie podać nazwę tej aplikacji,
czyli API.
Ona się zatrzyma i przestanie działać, gdybyśmy w przeglądarce sprawdzili. Ale chcę przejść sobie dwa
katalogi wyżej i pokazać ci, że nie mamy tutaj katalogu production, a chciałbym ten katalog również sobie
utworzyć.
Więc jak możemy to zrobić?
Tutaj musimy wpisać to, co wpisywaliśmy wcześniej, czyli pm2 deploy ecosystem i następnie production.
Czyli jakby podajemy ten klucz, który jest tutaj.
I wtedy to wszystko zostanie na serwerze ustawione.
I dopiszmy setup. To nam się ustawi i na serwerze powinno działać. Sklonuję sobie repozytorium.
Jest w porządku. I teraz będziemy mogli uruchamiać. Natomiast znowu chcę sobie tam wysłać te zmiany, których
dokonałem tutaj.
Więc git add wszystko, git commit dodany port powiedzmy, git push origin master. Wysłało się na serwer
i teraz zrobimy pm2 deploy ecosystem production. Czyli teraz chcę uruchomić wersję produkcyjną,
więc ona uruchomi się z innego katalogu, mianowicie z srv/www/production.
Teoretycznie na porcie 80.
Zobaczmy, czy nam się to uda.
Teoretycznie się udało, ale aplikacja i tak się nie uruchomi. Przechodząc tutaj na serwer, mogę wpisać
pm2 list, żeby zobaczyć.
Okazuje się, że obydwie są zatrzymane. Z prostego powodu.
Kiedy uruchamiamy jedną, to druga jest zatrzymywana.
A po drugie ani jedna nam teraz nie działa, bo nie możemy uruchamiać na porcie 80 domyślnie żadnych aplikacji.
Abyśmy mogli to zrobić, to musimy sobie tutaj na serwerze dla Node nadać jeszcze odpowiednie uprawnienia.
I można to zrobić w taki sposób.
Nie będę już tłumaczył, w jaki sposób to działa.
Ważne, że to dla procesu node pozwoli wykonywać go na porcie 80.
Wpisałem hasło, wciskam Enter i teraz już się powinno udać.
Więc będąc tutaj bezpośrednio już na serwerze, jesteśmy w katalogu www.
Przejdźmy do production i do source.
I tutaj mamy to wszystko. Spróbuję sobie uruchomić ten ecosystem takim samym poleceniem, jak mam tutaj. Bo ono
też jest przecież na serwerze później wykonywane, więc bezpośrednio na serwerze mogę go wpisać. I widzimy,
że teraz się udało, aplikacja się uruchomiła na porcie 80, bo tam przekazaliśmy to sobie tutaj jako
port 80.
I to w tym miejscu się pojawiło.
Spróbujmy przejść bezpośrednio pod vps.eduweb.pl. I jak widzisz, czat działa poprawnie, możemy się do niego podłączyć
W taki sposób możemy sobie zrobić deployment aplikacji, ale to jeszcze nie wszystko, co chciałbym ci pokazać w tej lekcji.
Dlatego że jeżeli teraz będę chciał sobie dokonać jakichś zmian w tych plikach, czyli np. napiszę sobie tutaj:
czat grupowy v2, bo go testuję, i będę chciał to wysłać,
no to standardowo tutaj wpiszemy git commit am v2. Ok.
Coś zrobiłem źle. Jeszcze raz.
Wyślemy to: git push origin master.
Wysłałem to na serwer i teraz jeżeli wpiszę tutaj lokalnie pm2 deploy ecosystem dev, to powinno to zostać
wysłane na serwer i tam skopiowane z Gita i uruchomiona aplikacja właśnie, którą mieliśmy tutaj. Wydaje
się, że jest ok.
Więc przejdźmy teraz do przeglądarki. Spróbujmy tę naszą aplikację produkcyjną, która jest na porcie 80
odświeżyć.
Jak widzisz, ona nam padła. A na porcie 8080 mamy aplikację Czat grupowy v2. Natomiast teraz chcę ci pokazać, jak
można zrobić tak, żeby uruchomić obie te aplikacje.
Czyli chcę mieć produkcyjną, bo ludzie z niej korzystają, ale równocześnie móc uruchomić sobie drugą aplikację.
Jest to dosyć proste, chociaż chwilę zajęło mi kiedyś znalezienie tego, aby to ustawić.
Otóż musimy sobie zrobić jakby dwie aplikacje. Czyli tutaj na górze, gdzie mieliśmy chat, skopiujemy to sobie.
I drugą aplikację nazwiemy chat-dev.
Ważne, żeby tutaj nie korzystać ze spacji, tylko właśnie robić to w ten sposób. I tyle nam wystarczy.
Ale ten skrypt, który jest uruchamiany na serwerze po tym, jak to wszystko się wyśle, czyli w zasadzie
ta komenda, musimy ją troszkę zmienić. I na stronie dokumentacji PM2 mógłbyś sobie to znaleźć.
Mianowicie tutaj, gdzie uruchamiamy sobie ecosystem, to dopiszemy taką flagę --only - czyli chcemy uruchomić tylko
jedną aplikację - chat, to znaczy, że jeśli jesteśmy w produkcji, to uruchamiamy tylko tę aplikację.
Natomiast w drugiej napiszemy sobie only chat dev. Czyli to, co mamy w tym miejscu, tutaj napiszemy.
Ok. To nam teoretycznie powinno wystarczyć. Tutaj na lokalnej maszynie teraz musimy to dodać do Gita, czyli git add,
git status dla pewności, że zostało to dodane i git commit message. Napiszemy sobie tutaj
dodano only.
Git push origin master - wysyłam to na serwer. Ok.
Teraz na serwerze jeszcze muszę zrobić jedną rzecz. Mianowicie będąc tutaj, możemy wpisać pm2 list, żeby
zobaczyć, co jest uruchomione.
Zatrzymamy sobie to wszystko. Wpiszemy pm2 kill. To wszystko się zatrzyma. Ten krok nie był konieczny, ale czasem
dobrze jest to zresetować. I teraz będąc tutaj, będziemy mogli na serwerze jeszcze raz to wszystko uruchomić.
Czyli teraz żadna aplikacja nie działa.
Ok. Ale wpiszemy sobie tutaj pm2 deploy i pokażę ci sztuczkę. Nie musimy wpisywać ecosystem. Cały czas
to wpisywaliśmy,
ale jeśli jesteśmy w tym katalogu, gdzie on jest, to nie musimy. Więc wystarczy pm2 deploy dev. Ok. I teraz
executing post-deploy.
Zauważ ecosystem only chat dev, czyli chat dev został uruchomiony. Na serwerze możemy wpisać pm2 list
i to zobaczyć.
Czyli nasza aplikacja powinna tutaj działać.
Okazuje się, że bez problemu działa. I teraz będziemy mogli tutaj zrobić to samo, czyli wysłać sobie wersję
produkcyjną, wpisując pm2 deploy production.
Prosta sprawa. Trzy wyrazy wystarczy wpisać, zostanie to wysłane i powinno zostać uruchomione tak, że będziemy
mieli uruchomione dwie aplikacje.
Zobaczmy. Wydaje się, że tak jest, pm2 list.
Mamy dwie na zielono.
A to oznacza, że druga aplikacja powinna działać na porcie 80.
I tak też się dzieje.
Czyli gdybyśmy teraz znowu chcieli sobie coś zmienić tylko w tej aplikacji deweloperskiej, mogę to zmienić
tutaj. Lokalnie na Macu zrobimy git commit am,
czyli chcę to dodać, i napiszę sobie v3. Wysyłam git push origin master. I teraz robię sobie pm2 deploy dev.
Wciskam.
To zostanie wysłane i ta aplikacja powinna zostać zresetowana.
Zobaczymy, czy ta na porcie 80 cały czas będzie działać, kiedy to się wykona. Zobaczmy. Działa.
Czyli ludzie normalnie mogą z niej korzystać, a ja mogę przejść sobie pod specjalny port 8080 i korzystać
z aplikacji v3.
Gdybyśmy się tutaj podłączyli, oczywiście czatownik, to jak najbardziej wszystko będzie działać. Możemy otworzyć
nową przeglądarkę. Tutaj sobie przejdziemy w ten sposób, np. Tomasz, i zauważ, że bez problemu to wszystko działa.
Możemy między sobą wysyłać wiadomości.
W ten prosty sposób tak naprawdę wdrożyliśmy sobie swoją aplikację do produkcji na własnym serwerze VPS z
Linuksem, a także pokazałem ci, w jaki sposób możemy zarządzać dwoma wersjami: produkcyjną i deweloperską.
Już całkowicie na koniec tej lekcji pokażę ci tylko jeszcze jedną rzecz. Mianowicie gdybyśmy ten serwer
zresetowali, czyli wpiszę sobie tutaj sudo reboot,
podałem hasło, wciskam Enter, to przestanie nam działać nasza aplikacja. To jest zrozumiałe, bo serwer leży. Ale
on za kilkanaście sekund się wznowi i nasza aplikacja tak czy siak nie będzie działać.
Dlatego chciałbym ci teraz pokazać, w jaki sposób możemy zrobić tak, aby pm2 uruchamiał wszystkie aplikacje
zaraz po tym, jak uruchomi się serwer. Będziemy to mogli zrobić.
Sprawa jest dosyć prosta. Otóż będę chciał wykonać na serwerze pewien kod.
Musimy do niego się od nowa zalogować.
Ssh piotr, wchodzę na serwer. Ok. Jesteśmy na serwerze i teraz wpiszemy pm2 startup. I on automatycznie
wygeneruje nam to, co mamy wpisać po to, aby uruchamiać przy starcie systemu właśnie pm2. Czyli to skopiowałem.
Wklejam to tutaj. Muszę podać hasło.
Ok.
I teraz powinno to teoretycznie działać. Aby jednak nie uruchamiać obydwu aplikacji, czyli aplikacji produkcyjnej
i deweloperskiej od razu, to możemy sobie tutaj uruchomić te, które chcemy i wpisać później save. Sprawdźmy, czy
coś jest uruchomione.
Jak widzimy - nie.
Dlatego przejdę teraz do srv, czyli do serve > ls.
Przejdziemy sobie niżej, czyli do www i do production. Następnie do source i tutaj będziemy chcieli ten ecosystem
uruchomić.
Przejdziemy do Sublime Text i pokażę ci, skąd możemy to wziąć.
Mianowicie wpiszemy sobie ten oto ciąg, tutaj będąc na serwerze. Czyli uruchomimy sobie tę aplikację. Ona jest uruchomiona.
I teraz, kiedy jest uruchomiona, mogę wpisać pm2 i następnie save.
W ten sposób zapisze nam jakby aktualny stan.
I teraz za każdym razem, kiedy zresetuję sobie system, możemy to oczywiście sprawdzić - wpiszmy sobie
sudo reboot - to owszem, padnie to tutaj wszystko na porcie 80, bo system operacyjny nie jest uruchomiony,
ale za moment kiedy on się uruchomi, poczekamy sobie jeszcze chwilkę, będę mógł się po pierwsze do niego zalogować
po ssh.
Udało się. Powitało nas na serwerze. Wyczyszczę sobie ekran i jeżeli tutaj odświeżę, to powinno to działać. Musimy
wrócić
do portu 80.
Jak widzisz, aplikacja nasza działa na porcie 80. A więc teraz nieważne, czy nasz system się zresetuje z jakiegoś
powodu, czy nie,
za każdym razem nasza aplikacja będzie działać poprawnie. A kiedy będę chciał uruchomić wersję deweloperską,
to tutaj będąc u siebie lokalnie, wpiszę sobie pm2 deploy i następnie dev i zostanie ona uruchomiona poprawnie.
Jak zatem widzisz, możemy tutaj dokonywać zmian, jakich tylko chcemy.
Później robimy git push origin master, a następnie wpisujemy pm2 deploy dev albo pm2 deploy production.
No i na tym zakończymy tę lekcję.
Nawet jeżeli teraz tego nie wdrożyłeś na własnym serwerze, to mam nadzieję, że zobaczyłeś, że również
jest to możliwe i nie musimy w jakiś dziwny sposób tego wszystkiego wysyłać.
Możemy korzystać z Gita i ze świetnego managera PM2, który jest bardzo zaawansowany. Polecam ci zerknąć
na jego dokumentację, bo możesz z niego jak najbardziej korzystać, uruchamiając swoje skrypty również
lokalnie i widzieć, ile np. zużywają pamięci czy czasu procesora.