Przejdź do treści

Stawiamy własny serwer

Budujemy własny serwer do programowania w R i Pythonie, razem z serwerem WWW, PHP oraz bazami danych MySQL i PostgreSQL.

Tym razem więcej administrowana serwerami, a mniej programowania i analizowania danych. Zbudujemy własny serwer do programowania w R i Pythonie, razem z serwerem WWW (aby móc prezentować wynik swoich prac).

Opis środowiska

W niniejszym wpisie przygotujemy serwer zbudowany na linuxie w dystrybucji Ubuntu z działającym na nim (i dostępnym przez przeglądarkę z dowolnego miejsca z internetem) RStudio. Serwer pozwoli nam też na budowanie i publikowanie aplikacji napisanych w Shiny. Przy okazji zainstalujemy Pythona razem z Jupyter Notebook (oraz JupyterLab) do wygodnej pracy. Całości dopełni baza danych PostgreSQL. Aby móc publikować swoje dzieła w formie bloga zainstalujemy PHP oraz bazy MySQL – być może zechcesz zainstalować WordPressa, a on tego wymaga.

Do czego taka maszyna może się przydać? W zależności od wydajności:

  • Mały serwer swobodnie może posłużyć do nauki programowania (R, Python, PHP), prowadzenia własnego blogaska (na przykład o programowaniu).
  • Duża maszyna (dużo RAMu, dużo procesorów, wszystkiego dużo) to już kwestia wyobraźni. Ja na przykład wyobrażam sobie działający w PHP jakiś serwis udostępniający użytkownikom w czasie (prawie) rzeczywistym informacje zebrane przy pomocy Pythona z wielu miejsc sieci, przetworzone na przykład modelami opartymi o TensorFlow (też w Pythonie) i ubranymi w wykresy (narysowane w R + ggplot) wyeksportowane do statycznych plików, które później są pokazywane w ramach prezentacji treści (przez tego początkowego PHPa).
  • Wszystko jedno jaki serwer, ważne żeby był online przez 24h/dobę – wówczas nie musimy zostawiać komputera na noc (albo kilka dni) włączonego żeby się coś przeliczyło. Albo jeśli zbieramy każdego dnia jakieś dane z jakiegoś serwisu (zbierałem tak dane o Veturilo, teraz zbierają się dane o wycieczkach do Grecji) albo mamy jakieś boty (na przykład mój twitterowy rstatspl).

Wszystko jednak musi mieć swój początek. Najpierw

Zakupy

Kupujemy domenę

Skorzystałem z NameSilo bo chciałem dziwaczną domenę, a w dodatku jak najtaniej – być może tylko na potrzeby tego wpisu. Liczę się z tym, że zostanę przy niej przez kilka lat, stąd wybór po cenie odnowienia domeny, nie interesowały mnie domeny za 0 zł. W każdym razie domenę można kupi w dowolnym miejscu (w dowolnym sklepie z domenami rzecz jasna), ważne jest aby mieć dostęp do panelu konfiguracyjnego domeny, a ten w NameSilo umożliwia wiele chociaż jest mało intuicyjny. Na razie tylko kupujemy i niczego nie robimy. Mamy, cieszymy się.

Kupujemy VPSa

Tutaj sprawa jest już trudniejsza. Nie będę zbytnio zanudzał: trzeba znaleźć serwer odpowiedni do swoich potrzeb. Najlepiej z możliwością łatwej rozbudowy. Może być 1 procesor (core), 1 GB RAMu i 10 GB dysku (mniej według mnie nie ma sensu – to co instalujemy w dzisiejszym odcinku zjada jakieś 8 GB dysku, a jest to gołe środowisko pracy), może być i takie f1.16xlarge z Amazona (64 core, 976 GB pamięci i 4x 940 dysku). Może być z Azure czy Google (takie na przykład 96 core, 624 GB pamięci, 8 GPU Tesla V100 i 3x 375 GB dysku) – bagatelka, jakieś 13.5 tys. dolarów miesięcznie w Google Cloud). Może być z OVH, wszystko jedno. Jedyne czego trzymamy się w tym wpisie to publiczne stałe IP, prawa roota i dostęp przez SSH.

Równie dobrze może to być goły Linux (tutaj: Ubuntu) zainstalowany na przykład na komputerze stojącym gdzieś w naszej piwnicy albo nawet jako maszyna wirtualna na laptopie (działająca wtedy, kiedy jest włączona. Rozwiązanie do nauki w sam raz, do pracy już raczej nie bardzo).

Ja skorzystałem z webh, czytając raczej dobre opinie w sieci i widząc atrakcyjną cenę. Jeśli się zdecydujesz na tego dostawcę skorzystaj proszę przy zakupie z podanego linku albo kodu promocyjnego PROMO25475.

Konfigurujemy VPSa

Wyklikujemy więc u naszego dostawcy nasz serwer (jego parametry), płacimy i po kilku minutach maszyna powinna być gotowa. Dostawca napisze nam (w jakiś sposób, to zapewne zależy już od dostawcy) jak się do maszyny dostać (jej IP i hasło do roota).

Logowanie i SSH

W pierwszej kolejności potrzebujemy klienta SSH – dla Windows jest to na przykład PuTTy. Ściągamy, instalujemy, uruchamiamy, konfigurujemy połączenie do naszego serwera.

Tworzymy użytkownika o uprawnieniach roota

Tworzymy użytkownika, w przykładzie będzie to lemur.

Ubuntu zapyta nas przede wszystkim o hasło do nowego konta i kilka innych informacji.

W następnej kolejności dodajemy nowemu użytkownikowi prawa roota (a tak na prawdę pozwalamy mu korzystać z sudo czyli uruchamiać komendy z konsoli z prawami roota):

Teraz możemy się wylogować z konta roota (i już do niego nie wracać) i zalogować się na utworzone konto. To na nim działamy w dalszym ciągu.

Update serwera

Warto na początek sprawdzić czy Ubuntu jest aktualne, a jeśli trzeba – niech się zaktualizuje:

W zależności od dostawcy VPSa może coś się zaktualizować, ale nie musi. W przypadku mojego dostawcy system był aktualny. Warto co jakiś (na przykład raz w miesiącu, można to wrzucić w crona) czas powtarzać powyższe komendy.

Ze względów bezpieczeństwa dobrze jest wyłączyć dostęp do serwera przez SSH dla użytkownika root. Logujemy się więc na nasz serwer (nowo utworzonym kontem) i przechodzimy do konfiguracji SSH:

Może okazać, się że nie mamy zainstalowanego nano (to edytor tekstu wygodny i dla laików prostszy w obsłudze niż na przykład vi) – wówczas go instalujemy:

Po ewentualnej instalacji możemy przejść do edycji. Aby zablokować dostęp dla roota po SSH odnajdujemy w pliku /etc/ssh/sshd_config linię

i zmieniamy na

Zapisujemy plik i restartujemy serwer SSH:

To wszystko. Jeśli zajdzie potrzeba zalogowania się na konto roota poprzez SSH zawsze możemy powtórzyć powyższe kroki i umożliwić logowanie (zmieniając PermitRootLogin na yes w pliku /etc/ssh/sshd_config i restartując SSH).

DNS

Konfiguracja DNS to nadanie naszemu serwerowi konkretnej nazwy (na razie mamy tylko IP) i umożliwienie dotarcia do serwera (w internecie) poprzez nazwę a nie numerek. W panelu domeny wskazujemy adres IP naszego serwera, a firma rejestrująca domeny zapewni nam, że ktoś wpisując nasza.domena na przykład w przeglądarce trafi na odpowiedni serwer. A co będzie pod tym numerkiem to już nasza sprawa. Ta cześć konfiguracji zależy od konkretnego dostawcy domeny. Robimy to dla każdej subdomeny, wszystkie kierujemy na jeden adres – rozdzieleniem ruchu zajmiemy się po swojej stronie. W dużym uproszczeniu:

  • w rekord typu A wpisujemy nasz IP
  • w rekordy typu CNAME wpisujemy z jednej strony subdomenę, a z drugiej – domenę (czyli np. rstudio i nasza.domena)
  • w rekordy typy MX rzeczy związane z pocztą, ale można też (NameSilo to umożliwia) przekierować pocztę na poziomie DNSów, bez budowania serwera pocztowego

Wydelegowanie domeny na adres IP może trochę potrwać, więc nie przejmuj się jeśli kolejne kroki nie będą działać od razu. W NameSilo było to… kilkanaście minut (kiedyś to i dwa dni się czekało).

Możemy zmienić też nazwę hosta, czyli to pod jaką nazwą system widzi sam siebie. Wystarczy edycja pliku

Wpisana tam nazwa serwera nie powinna zawierać kropki – najlepiej niech będą to same literki i ewentualnie cyferki. Aby zmiany odniosły skutek resetujemy usługę hostname:

Serwer WWW – konfiguracja

Zaczynamy od zainstalowania serwera WWW – w tym przypadku będzie to Nginx.

Po chwili wpisanie w przeglądarce http://nasza.domena (o ile DNSy już kierują na nasz serwer – jeśli nie podaj numer IP) powinno wyświetlić coś na kształt:

Sam serwer jeszcze będziemy konfigurować, więc na razie przechodzimy dalej i instalujemy serwer MySQL, który będzie potrzebny na przykład WordPressowi. Sprawa znowu jest prosta:

To trochę większa rzecz, potrwa więc dłużej. Po drodze zostaniemy poproszeni na przykład o hasło roota dla bazy danych. Zapisz je sobie, bo zapomnisz i będzie problem. Ogólnie wszystkie hasła sobie zapisuj i niech każde będzie inne, mocno skomplikowane (z 15 znaków, duże i małe litery, cyfry i znaki specjalne).

Ostatni krok to PHP, w którym napisana jest duża cześć stron. Nginx nie posiada wewnętrznego procesora PHP trzeba więc zainstalować php-fpm. Przy okazji zainstalujemy dodatkowy pakiet dla PHP do komunikacji z MySQL oraz kilka innych przydatnych bibliotek.

Instalacja była prosta, z konfiguracją trochę więcej pracy. Przede wszystkim musimy skonfigurować PHP. W pliku /etc/php/7.0/fpm/php.ini potrzebujemy ustawić parametr cgi.fix_pathinfo na 0, co z poziomu konsoli robimy:

i znajdujemy odpowiednią linię w edytorze (będzie zakomentować średnikiem i z wartością ustawioną na 1), a później zapisujemy plik. Po poprawce resetujemy serwer PHP:

Teraz jeszcze musimy serwerowi WWW (nasz Nginx) powiedzieć co ma robić z plikami *.php. Najważniejsza cześć pliku /etc/nginx/sites-available/default (po usunięciu komentarzy) wygląda tak:

Na szczęście wszystko czego potrzebujemy jest wpisane w konfiguracji i wystarczy zdjąć komentarze. Docelowo interesujące nas fragmenty powinny wyglądać tak:

Restartujemy serwer Nginx (nie ostatni raz):

i PHP działa! Jak to sprawdzić? Stworzymy prosty plik info.php, który umieścimy w folderze serwera www, czyli /var/www/html (to wynika z konfiguracji wyżej)

Możemy wejść na http://nasza.domena/info.php i powinniśmy dostać informacje o PHP:

To co widać na stronie (wynik PHPowego phpinfo()) lepiej ukryć przed niepowołanymi osobami, zatem skasujmy ten plik:

R, RStudio i Shiny

Czas na najbardziej oczekiwany kawałek – przygotowanie środowiska do programowania w R razem z Shiny.

Instalujemy R

Postępujemy zgodnie z instrukcją na CRANie:

  • generujemy klucz szyfrujący

  • dodajemy repozytorium dla apt-get

jeśli dostaniemy informację, że to polecenie nie jest znane trzeba doinstalować mały pakiecik:

i powtórzyć

A dalej już tylko pozostaje instalacja R – identyczna jak właściwie każdego programu na Ubuntu:

Teraz w konsoli możemy po prostu wpisać nasze ukochane R i…

Gotowe!

Instalujemy RStudio

RStudio nie znajdziemy w repozytoriach Ubuntu, musimy więc pobrać pakiet instalacyjny ze strony RStudio:

Po tych czterech linijkach możemy w przeglądarce wpisać http://nasza.domena:8787 i cieszyć się świeżym RStudio na własnym serwerze. Fragment rstudio-server-1.1.453-amd64.deb to odpowiednia wersja, która może się z czasem zmieniać – warto sprawdzi na stronie RStudio.com co tam jest aktualnie. To samo odnosi się do Shiny. Możemy również użyć wersji beta dziennych – linki znajdziecie na odpowiedniej stronie.

Instalacja przydatnych pakietów

Na początek warto zainstalować wszystkie przydatne pakiety. Kilka z tych, które instaluję zazwyczaj:

  • stringi
  • stringr
  • tidyverse
  • readr
  • readxl
  • XML
  • jsonlite
  • tidytext
  • forecast
  • caret
  • e1071
  • odbc
  • xts
  • zoo

Czyli odpalamy z konsoli R (wpisując po prostu R), a potem to co już doskonale znamy:

Idziemy na piwo. Ale zanim to zrobimy trzeba zainstalować kilka bibliotek systemowych, gdyż instalacja kilku pakietów się nie uda. Instalujemy zatem:

Warto też zainstalować Javę:

I dopiero teraz instalujemy co potrzebne z poziomu R:

Instalujemy Shiny

W pierwszej kolejności musimy zainstalować pakiet shiny w R na prawach roota, zatem:

w drugiej kolejności – zainstalować sam serwer, znowu ściągając instalkę:

Po instalacji wchodzimy na http://nasza.domena:3838 i sprawdzamy czy wszystko działa. Jeśli nie działa – patrzymy w logi z folderu /var/log/shiny-server/ i zastanawiamy się co zrobić. Najczęściej przyczyną problemów są uprawnienia do folderów lub brak bibliotek. Serwer Shiny działa na użytkowniku shiny, ale możemy to zmienić w jego konfiguracji, w pliku /etc/shiny-server/shiny-server.conf

i zmieniamy

na naszego użytkownika:

gdzie lemur to nasz użytkownik. Ja używam sam swojego serwera, więc mogę sobie na to pozwolić. Ale jeśli mamy wielu użytkowników R, każdy z własnym kontem to musimy się na jakieś zdecydować. Albo zainstalować odpowiednie pakiety R-a dla użytkownika shiny. To jest niestety upierdliwe w systemach linuxowych.

Po zmianach w konfiguracji serwera trzeba go zrestartować, aby załapał nowe ustawienia:

Konfiguracja serwera Shiny

Gdzie będą trzymane aplikacje? Standardowo w folderze /srv/shiny-server/ co wynika z wpisu w pliku /etc/shiny-server/shiny-server.conf. Jeśli potrzebujemy – możemy to zmienić. Możemy zmienić również port na którym działa serwer. Pamiętać jednak należy, żeby później odpowiednio dostosować konfigurację subdomen w Nginxie (o tym za chwilę). Ja u siebie zostawiłem bez zmian.

Ale nie samym R żyje człowiek, przyda się też

Python i Jupyter

Instalujemy Pythona

a może jest zainstalowany? Ubuntu 16.04 na dzień dobry przychodzi z Pythonem 2.7 oraz Pythonem 3.5 (w odpowiednich podwersjach):

Jeśli chcemy Pythona 3.6 to wykonujemy trzy kolejne linie:

W tym momencie mamy w systemie trzy wersje Pythona:

  • python – uruchomi nam wersję 2.7,
  • python3 – wersję 3.5,
  • a python3.6 – 3.6

Jeśli chcemy móc wybierać z której wersji (3.5 czy 3.6) korzystać będzie polecenie python3 wykonujemy dwa polecenia:

Teraz możemy się przełączać między wersjami z użyciem

Ja wybrałem jako domyślną wersję 3.5, więc po

widzę Python 3.5.2. Uwaga – na wybranej wersji zainstalowany zostanie za kilka chwil Jupyter, więc wybierz mądrze :)

Instalujemy pip dla Pythona 3:

Kilka bibliotek systemowych może być koniecznych, zatem zainstalujmy je już teraz (podobnie jak w przypadku instalowania pakietów do R):

Biblioteki Pythona

Warto na początek zainstalować kilka podstawowych:

  • numpy
  • pandas
  • nltk
  • matplotlib
  • SciPy
  • Seaborn
  • SciKit-Learn
  • Statsmodels
  • TensorFlow
  • Keras

Pytanie tylko czy od razu, dla własnego użytkownika czy też tworzyć środowiska wirtualne Pythona? To już pozostawiam Wam do decyzji. Tutaj jedziemy po bandzie, bez żadnych środowisk wirtualnych i wszystkie kolejne biblioteki instalujemy przez

Instalujemy Jupyter

Jupyter to taka zubożona wersja RStudio. Lepsze to niż Python z konsoli – widać przynajmniej krok po kroku co się dzieje w kodzie. Poza tym wszyscy z niego korzystają ;)

Pierwszy krok przygotowania do normalnego funkcjonowania to zbudowanie domyślnego pliku konfiguracyjnego:

Teraz wygenerujemy hasło dostępu do Jupytera:

Uruchamiamy Jupytera

Wystarczy w tym momencie przejść na stronę http://nasza.domena:8888, zalogować się utworzonym hasłem i możemy działać w Pythonie!

Zamknijmy go jednak i zainstalujemy JupyterLab. Zamknąć można z konsoli (Ctrl-C) lub z przeglądarki (guzik Quit).

instalujemy JupyterLab

Po instalacji uruchamiamy JupyterLab:

Teraz po wejściu na http://nasza.domena:8888 powinien uruchomić się JupyterLab, a po wejściu na http://nasza.domena:8888/tree – Jupyter. Możemy ponownie zamknąć Jupytera i uruchomić go w tle:

Zwróć uwagę na & na końcu linii.

To jednak wymaga uruchamiania Jupytera ręcznie, po każdym restarcie serwera. Możemy to zmienić dopisując do pliku /etc/rc.local następującą linijkę (odpowiednio zmieniając ścieżki plików):

Ważne: to musi być dopisane przed linijką z exit 0. Dodanie tej linii spowoduje, że http://jupyter.nasza.domena otworzy Jupytera – aby korzystać z JupyterLab uruchamiamy http://jupyter.nasza.domena/lab. W miejsce wpisujemy oczywiście naszego użytkownika.

Subdomeny – konfiguracja

  • nasza.domena oraz www.nasza.domena – strona WWW na standardowym porcie 80
  • rstudio.nasza.domena – RStudio, na porcie 8787
  • shiny.nasza.domena – serwer Shiny, na porcie 3838
  • jupyter.nasza.domena – Jupyter Notebook, na porcie 8888

Całość opiera się na konfiguracji Nginxa. Dobrym dla nas jest to, że wszystkie usługi działają na oddzielnych portach – będzie bardzo łatwo przekierować je na subdomeny.

W folderze /etc/nginx/sites-enabled tworzymy sobie pliki dla każdej subdomeny. Różnić będą się w trzech miejscach:

  • linii czwartej podajemy subdomenę
  • w liniach 7 i 8 odpowiedni port

Przykład dla RStudio (plik /etc/nginx/sites-enabled/rstudio.conf):

Co to robi? Nasłuchuje portu 80 na adresie rstudio.nasza.domena i przekierowuje ruch na port 8787 (czyli RStudio).

Dla Shiny (plik shiny.conf):

Dla Jupytera jest nieco inaczej:

Po przygotowaniu wszystkich plików konfiguracyjnych restartujemy serwer Nginx:

Teraz wpisując w przeglądarce http://rstudio.nasza.domena powinniśmy trafić do RStudio, zaś http://shiny.nasza.domena – do głównego folderu z aplikacjami Shiny. Nadal zadziała http://nasza.domena:8787 dla RStudio (serwer obsłuży to bez przekierowania). Dla Jupytera mamy http://jupyter.nasza.domena, dla JupyterLab http://jupyter.nasza.domena/lab.

Kolejne aplikacje umieszczamy w folderach /srv/shiny-server/, np. /srv/shiny-server/nasza_apka i poprzez http://shiny.nasza.domena/nasza_apka trafimy tam gdzie trzeba, uruchamiając aplikację. Jeśli nie posprzątaliśmy folderu /srv/shiny-server/ to http://shiny.nasza.domena/sample-apps/hello/ uruchomi przykładową.

Dodatki

GitHub

Przyda nam się git chociażby po to, aby na GitHubie trzymać swoje pliki źródłowe.

gita musimy też skonfigurować:

W “user_name” i “email_id” wprowadzamy dane swojego konta na GitHubie.

PostgerSQL

Mamy zainstalowaną bazę MySQL, ale możemy z różnych powodów chcieć korzystać z PostgreSQL.

Instalacja jest prosta i analogiczna do wszystkich wcześniejszych:

PostgreSQL działa w oparciu o role, a po instalacji istnieje tylko rola postgres. Warto stworzyć nową – uruchamiamy psql dla istniejącej roli:

A następnie tworzymy bazę danych, użytkownika (razem z hasłem) i nadajemy mu uprawnienia do stworzonej bazy:

Teraz (działając na naszym standardowym loginie) możemy uruchomi psql łącząc się z nową bazą (na razie pustą):

Po połączeniu się z bazą, już z poziomu pqsl możemy utworzyć sobie stosowne tabele, od dla przykładu (z jakiegoś tutoriala):

Czy tabela powstała? Będąc nadal w psql sprawdzamy to wpisując \d co powinno dać wynik typu:

Wpisując \q możemy wyjść z PostgreSQL. Wcześniej możemy usunąć testową tabelę:

Oczywiście na bazę danych możemy mieć inny serwer niż na resztę – oszczędzamy wówczas miejsce na aplikacje. Podobnie z plikami statycznymi. Ale to już robi się małą farma ;)

Serwer FTP

Po co nam serwer FTP? Chociażby po to, aby w prosty sposób przekazywać pliki na serwer (lub z niego je pobierać). Konfiguracja jest szybka i dość prosta. Najpierw oczywiście instalacja:

Serwer już działa. Warto jeszcze ograniczyć dostęp dla użytkowników tylko do ich domowych folderów oraz pozwolić im na zapis plików, zatem zdejmujemy komentarz z linii:

oraz dodać

w pliku /etc/vsftpd.conf. Po zmianach oczywiście restart serwera:

Ograniczenie dostępu do folderów to zwiększenie bezpieczeństwa (na przykład żeby nikt nie skasował przez przypadek produkcyjnych plików z serwera www albo Shiny). Zawsze można pliki przerzucić do folderu w domku użytkownika, a następnie – już z konsoli – podmienić pliki.

Serwer działa w trybie passive – to może być istotne w konfiguracji klienta FTP.

rgdal

Jeśli chcemy wykorzystywać mapy i pliki SHP to przyda nam się biblioteka rgdal (w R). Ta zaś łatwo się nie zainstaluje bo najnowsza wersja wymaga gdal w wersji >= 1.11.4, a domyślnie w repozytoriach mamy wersję niższą. Podobnie jak wcześniej – trzeba zainstalować coś w systemie zanim zainstalujemy pakiet w R:

Teraz już rdgal uda się zainstalować – skorzystaliśmy z innego repozytorium, gdzie jest nowsza wersja biblioteki systemowej gdal. Przy okazji instalując co trzeba dla Pythona.

LaTeX/Pandoc

Jeśli chcesz generować raporty w plikach PDF korzystając z rmarkdown to potrzebujesz LaTeXa i pandoc. Do renderowania plików LaTeXa polecam xetex

W konfiguracji RStudio trzeba wybrać “Typeset LaTeX info PDF using: XaLaTeX”. Powinno zadziałać.

Teraz taki hint – rozwiązanie problemu, z którym walczyłem pół dnia próbując renderowac raporty skryptami odpalanymi cyklicznie z crona. W przypadku renderingu plików do LaTeXa/PDFa uruchamianych z konsoli (np. przez Rscript) odpowiednio musimy ustawić zmienną środowiskową RSTUDIO_PANDOC (domyślnie ma wartośc /usr/lib/rstudio-server/bin/pandoc). Zatem na początku skryptu R uruchamianego z konsoli wpisujemy:

i sprawa załatwiona – rmarkdown::render() działa jak należy.

WordPress

Przygotowane środowisko gotowe jest na przyjęcie na przykład WordPressa (na którym można postawić stronę www). Proces instalacji świetnie opisuje post w serwisie Hostovia.pl – całość jest prosta i sprowadza się do kilku (może dziesięciu) kroków.

Hugo

Zamiast pisać blogaska w WordPressie możemy zechcieć skorzystać np. z Hugo, czyli silnika do generowania stron statycznych, których całą treść można trzymać w plikach Markdown i renderować całe serwisy. To bardzo popularne w środowisku użytkowników R. Szczegóły instalacji znajdziecie na stronie GoHugo.io.

Koniec

Na koniec tego wszystkiego możemy zresetować serwer, zobaczyć czy ruszy i czy wszystkie nasze usługi działają poprawnie. Aby zresetować maszynę wpisujemy w konsoli:

Jeśli nie – szukamy w sieci dlaczego nie działa i co trzeba poprawić ;). Co warto sprawdzić?

  • czy RStudio uruchamia się w przeglądarce?
  • czy można zainstalować nowe pakiety z poziomu RStudio?
  • czy pliki RMarkdown renderują się do HTMLa i PDFa?
  • czy Jupyter i JupyterLab otwierają się w przeglądarce?
  • czy kernele w obu Jupyterach działają (czy działa Python)?
  • w jakiej wersji jest Python w Jupyterach? Do tego wystarczy wpisać w nowym notatniku Jupytera/JupyterLaba:

  • czy FTP działa – czy można się do niego dostać, ściągnąć i zapisać pliki?
  • czy można połączyć się z bazami danych – MySQL i PostgreSQL? Najlepiej też z poziomu R i Pythona
  • jeśli instalowaliśmy WordPressa – czy działa sama strona oraz panel administracyjny?
  • czy działa Git? Też z poziomu RStudio (bo to wygodne)?
  • czy działa PHP i odpowiednie biblioteki (jak działa WordPress to raczej tak)

U mnie działa, chociaż było trochę klikania i szukania. Ale uzupełniałem też niniejszy wpis, więc powinien być kompletny.

Mam nadzieję, że zebranie wszystkiego w jednym miejscu ułatwi Wam przygotowanie środowiska. Jeśli jednak napotkacie na jakieś problemy – szukajcie sami. Nie jestem administratorem serwerów i w sumie nie zamierzam nim być. Uważam jednak, że data scientist powinien potrafić zrobić kilka rzeczy w systemie Linuxowym, coś w konsoli bazy danych czy też proste rzeczy związane z konfiguracją serwera WWW (domeny, przekierowania). Do nauki tego typu rzeczy własny serwer (lub komputer w piwnicy jak wspomniałem na początku) jest najlepszym rozwiązaniem.

Przy pisaniu tego postu posiłkowałem się cennymi źródłami wiedzy, przede wszystkim serią Konfigurujemy VPS z Notatnika Marcina Kasperskiego.

13 komentarzy do “Stawiamy własny serwer”

  1. Dobry wpis! Zastanawiam się czy 1vCPU (plan mini) na początek zabawy z danymi wystarczy. Na chwilę obecną przerabiam podstawowe zagadnienia uczenia maszynowego w pythonie, póki co GPU nie używam. Masz może jakieś info o wydajności na webh?

    1. Nie badałem wydajności. Na pewno na początek zabawy z danymi 1 CPU daje radę. Jeśli coś pójdzie znośnie na laptopie i3 z 4 GB RAM to pójdzie też na takim serwerze.

  2. Bardzo ciekawy wpis, natomiast jest to droga dla prawdziwych twardzieli czyli budowanie środowiska z ustawień od zera. A masz może wiedzę gdzie można skorzystać z gotowej chmurowej platformy do tworzenia / deployment’u typu Heroku ale bardziej w Europie/ PL ?

  3. Tak jeszcze pomyślałem, do pythona i dodatków można dołączyć skrypt jaki proponuje Vladimir. Wtedy to już bedzie kosmos.

      1. Dziękuję, lata temu dodawałem subdomeny, a ta opcja na OVH jest nieźle schowana.

  4. Pingback: Google Analytics w R | Łukasz Prokulski

  5. Spoko blog!

    Co do uruchamiania demow polecam uzyc tego https://webinsider.pl/linux-autostart/

    co do ftp, to ja bym go calkiem wylaczyl/skasowal i dane wysylal na serwer scp a pobieral przez www, zamiast putty polecam MobaXterm

    dodatkowo polecam zainstalwac fail2ban tak na wszelki wypadek lepiej miec, niz nie miec

    ps. i czy nie zastanawiales sie na opakowaniem tego calego srodowiska w technologie docker?

    pozdro i czekam na kolejne wisy :)

    1. Dockera „macam” dopiero na lokalnych maszynach, więc to potrwa. Ale może zakończyć się serią wpisów na ten temat (no, może jednym dużym – dobra seria jest tutaj).

Skomentuj Łukasz Anuluj pisanie odpowiedzi

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *