Konfigurujemy VPS - część 12, aplikacje

Cykl Konfigurujemy VPS poświęciłem przygotowaniu małej maszynki linuksowej działającej w sieci. Opisałem proces podstawowej konfiguracji oraz trochę przydatnych narzędzi i konwencji administracyjnych. Chciałem, by te artykuły pomogły choć kilku osobom zacząć administrowanie własnym systemem.

No - ale system stawiamy po coś. Aby postawić bloga, CMS czy wiki, trzymać repozytorium kodu, serwować samodzielnie pisaną aplikację, uruchomić serwer jakiejś sieciowej usługi, ...

W dzisiejszym odcinku - luźniejsza z konieczności - dyskusja na temat wyboru aplikacji.

Ale najpierw kilka słów o cyklu jako całości.

Tak, to już (prawie) koniec

Jest to prawdopodobnie przedostatni odcinek cyklu. Z naprawdę ważnych rzeczy potrzebnych każdemu nie opisałem jeszcze tylko sposobów robienia backupu (i zaległość tą planuję uzupełnić).

Prawdziwy koniec to nie jest, pisać o konfigurowaniu użytecznych serwerowych aplikacji będę nadal (zresztą - już to robię), dodając w miarę możności uwagi o specyfice działania w środowiskach z ograniczeniami pamięciowymi. Nie będę już jednak prefiksował tych artykułów nazwą Konfigurujemy VPS.

Powód? Firewalla, nazwy domenowej, webserwera, możliwości logowania się - potrzebuje każdy. Dalej zaczyna się ocean różnorodności. Chętnie wspomnę o moim ulubionym wiki ale nie chcę robić wrażenia, że jest to idealny wybór dla każdego (i że każdy powinien tego typu aplikację uruchomić).

Co można postawić na VPS

Co możemy postawić na VPSie? Niemal wszystko - o ile tylko przewidywane obciążenie nie przekracza możliwości takiej maszyny.

Przy skalowaniu obciążenia mamy spory margines błędu, dobrzy dostawcy (jak moje Linode) pozwalają elastycznie upgradeować rozmiar RAM, ilość dysku czy pasmo, aż do poziomu zbliżonego do przyzwoitej maszyny dedykowanej. Przy tym upgrade nie wymaga reinstalacji - czasem wystarczy parę kliknięć i reboot, czasem potrzebne jest zgłoszenie do administratora i parę minut niedostępności. Dlatego popularne jest zaczynanie od najtańszej opcji i migrowanie jej w górę w miarę potrzeb.

Najczęstszymi zastosowaniami są dynamiczne serwisy webowe, od rozmaitych blogów, CMSów, forum, sklepów czy wiki po aplikacje pisane samodzielnie (na VPS-ach zaczynał niejeden startup). Trafiają się serwery pocztowe i list dyskusyjnych, różnego typu robaczki sieciowe, repozytoria kodu, bugtrackery, nawet serwery gier.

Oczywiście na jednym serwerze może też koegzystować kilka takich aplikacji.

Raczej nie stawiałbym na VPS aplikacji stricte obliczeniowych, przekodowywanie wideo czy wielogodzinną analizę pozycji szachowej lepiej uruchomić na dedykowanym CPU (albo na specjalizowanej wirtualizowanej ofercie - jak Amazonowe EC2 w wersji High-CPU).

Wybór aplikacji

Wybór najlepszego narzędzia może być bardzo nietrywialny, co chyba najłatwiej uświadomić sobie patrząc na kilkusetelementową listę CMSów z cmsmatrix.

Z premedytacją nie podam w tym artykule moich typów na - np. - najlepszy program blogowy albo najlepsze forum. Nawet na ten sam problem różne osoby mogą patrzeć bardzo, bardzo różnie.

Weźmy kluczowy przykład edytowalnego website z odrobiną dynamiki. Wojna CMSów jest niesłychanie zażarta (Joomla, Drupal, XOOPS, SilverStripe, MODx, Expression Engine, Plone, Midgard, ... - każdy ma mniejsze lub większe grono zakochanych użytkowników, a lista jest bardzo dalece niepełna) ale i tak znajdą się osoby preferujące dostrojenie do tych zastosowań silnika blogowego albo maszynki wiki. Inni będą generować serwisy offline przy pomocy NetObjects Fusion czy Dreamweavera. Jeszcze inni złożą własną aplikację z gotowych klocków przychodzących z Django, RoR lub innym frameworkiem. I tak dalej.

Jak wybierać? Dłuższy artykuł na ten temat napisałem parę miesięcy temu, tu chciałbym podkreślić tylko tyle: zwykle nie ma jednego najlepszego produktu, a coś dobrego dla autora czytanego artykułu nie musi być dobre dla mnie.

Uwarunkowanie nr 1 - baza danych

Nawet jeśli korzystamy z kilku aplikacji, powinniśmy się ograniczyć do jednego silnika bazy danych (w ramach którego może w razie potrzeby działać wiele baz). Chodzi tu o oczywiste względy pamięciowe ale też o efektywniejszy dostęp do dysku.

Możliwości są tu dwie - MySQL lub PostgreSQL.

Inna ciekawa baza open-source to Firebird (dawne InterBase), znany zresztą z dbałości o przyzwoite działanie na małych systemach. Jest jednak znacznie mniej popularny, co owocuje zarówno małą liczbą aplikacji oficjalnie go supportujących, jak kłopotliwszą instalacją (mniej dopracowane pakiety w dystrybucjach albo w ogóle ich brak, brak wsparcia przy różnych formach autokonfiguracji itd).

Osobiście bardzo lubię PostgreSQL i gdy tylko mogę, wykorzystuję tą bazę danych (i jestem zadowolony z tego jak działa na VPSie). Niestety - wiele aplikacji wymaga MySQL.

Problem dotyczy głównie systemów pisanych w PHP. Perl, Python, Ruby czy Java od bardzo dawna mają dobre biblioteki uniezależniające kod aplikacji od używanej bazy danych, nawet jeśli autorzy aplikacji oficjalnie jakiejś bazy nie supportują, zazwyczaj działa ona poprawnie. W PHP dla masy programistów dostęp do bazy danych to ciągle funkcje mysql_*.

No i - WordPress wymaga MySQL,
Drupal wymaga MySQL, Joomla wymaga MySQL, ExpressionEngine wymaga MySQL, ModX wymaga MySQL, SilverStripe wymaga MySQL ... Gdy wybierałem sobie oprogramowanie do bloga, z bodaj dwudziestu PHPowych rozwiązań po dołożeniu warunku działania na PostgreSQL pozostały mi Habari i Serendipity.

Cóż - i tak wolę PostgreSQL. Ale ostrzegałem.

Strojenie baz pod VPS

Skoro zacząłem pisać o bazach danych, wtręt praktyczny o ich konfiguracji do działania na małej maszynie.

Kluczowym elementem jest sensowne ograniczenie liczby równoczesnych połączeń. Aby to oszacować, sumujemy ilość procesów lub wątków otwierających własne połączenia bazodanowe (np. procesy FastCGI), rozmiary ewentualnych pul w samodzielnych serwerach aplikacyjnych itp. Do tego dochodzi ograniczenie struktur pamięciowych takich jak cache czy obszary robocze.

Dla PostgreSQL wszystkie istotne ustawienia znajdują się w pliku /etc/postgresql/8.3/main/postgresql.conf (zamiast main może być używana inna nazwa). Plik jest obszernie skomentowany, więc objaśnień znaczenia poszczególnych parametrów nie będę powielał. Przykład nieco zmniejszonych wartości paru istotnych dla zużycia pamięci parametrów:

max_connections = 50
shared_buffers = 8MB  
temp_buffers =  64MB      
work_mem = 512kB
max_stack_depth = 1MB

Po edycji konieczny jest restart serwera bazodanowego (/etc/init.d/postgresql-8.3 restart).

W przypadku MySQL edycji wymaga /etc/my.cnf a inspiracją (dla solidnego VPS - przesadną) może być /usr/share/doc/mysql-server-5.0/examples/my-small.cnf albo my-medium.cnf z tego samego katalogu. Kluczowe parametry znajdują się w sekcji [mysqld], gdzie można np. napisać

key_buffer = 64K
max_allowed_packet = 1M
max_connections = 50 
table_cache = 8
query_cache_limit = 512K
query_cache_size  = 8M

Uwaga: powyższe wartości podaję jako przykład, głównie dla wskazania szczególnie wartych uwagi pól. Zdecydowanie zachęcam do przeczytania fragmentów dokumentacji poświęconych fizycznej konfiguracji serwera. A także do ... wersjonowania konfiguracji i testowania działania aplikacji po zmianach parametrów bazy danych.

Uwarunkowanie nr 2 - język

W miarę możności ograniczamy się do jednego środowiska językowego. Ta sama pula procesów FastCGI może obsłużyć kilka aplikacji w PHP ale aplikacji pythonowej czy perlowej już nie (i na odwrót). Nawet gdy odpowiednie procesy uruchamiane są niezależnie, jeśli korzystają z tego samego runtime, system operacyjny potrafi reużyć załadowane biblioteki dzielone czy same programy. Itd itp.

Nie jest to dogmat, na mekk.waw.pl z powodzeniem mieszam aplikacje PHP i Pythonowe - ale warto się tu ograniczać.

Strojenie runtime języka

Używając PHP warto zwrócić uwage na parametr memory_limit w php.ini (dla uruchamiania jako FastCGI - /etc/php5/cgi/php.ini, dla uruchamiania pod Apache - /etc/php5/apache2/php.ini). Mapuje się on bezpośrednio na rozmiar pamięci wykorzystywanych przez procesy PHP. Odpowiednia wartość zależy od używanych aplikacji (i często jest dokumentowana), heurystycznie można zacząć od

memory_limit = 8M

i powiększać w razie występowania błędów. Te ostatnie częściej pojawiają się na ekranach edycyjnych/administracyjnych niż przy generowaniu treści.

W innych językach taka konfiguracja zwykle nie występuje ale można rozważać użycie ulimit do ograniczenia wielkości pamięci czy stosu.

W czym developować?

Jakie środowisko wybrać do pisania własnych aplikacji?

Też nie odpowiem. Znane, lubiane, samodzielnie wybrane. Python, Perl, PHP, Ruby, Java...

Ale koniecznie z jakimś gotowym frameworkiem i pakietem bibliotek!

Problemy takie jak utrzymywanie sesji, cacheowanie, mapowanie urli na procedury obsługowe, obsługa błędów, zarządzanie połączeniem bazodanowym, tworzenie zapytań SQL, generowanie stron HTML z szablonów - powinny być już rozwiązane. Reużywalne komponenty (choćby obsługa komentarzy, rejestracji czy edycji tekstów przez uprawnionych użytkownków) także mogą się przydać.

Podsumowanie

Zdaję sobie sprawę, jak zdawkowy jest ten artykuł na tle wcześniejszych szczegółowych propozycji. Będę w przyszłości opisywał niektóre konkretne aplikacje, chciałem jednak wywiesić tego typu manifest. Nikt nie wybierze za Ciebie.

Wszystkim, którzy czytali cykl Konfigurujemy VPS dziękuję za uwagę i zachęcam do zadawania uzupełniających pytań. A jeśli komuś cykl pomógł dojść do użytecznego serwisu, chętnie bym się o tym dowiedział (publicznie w komentarzu albo prywatnie).