25 kwietnia obchodzony jest Dzień Pingwina, czyli nietypowe święto, którego celem jest zwrócenie uwagi na znaczenie tych ptaków. Okazuje się, że pingwiny, chociaż oczywiście niebezpośrednio, doskonale sprawdzają się m.in. w administracji IT.

Na pewno wiele osób rozpoznaje pingwina nazwanego Tux, który jest „maskotką” rodziny systemów Linux. W zasadzie termin Linux odnosi się do samego kernela, czyli najważniejszego i podstawowego komponentu każdego systemu operacyjnego. Autorem Linuxa jest Linus Torvalds, który opublikował pełny kod źródłowy swojego rozwiązania. Dzięki temu podejściu powstało wiele różnych dystrybucji. Niektóre z nich (np. Debian, Arch Linux, Red Hat Linux) zyskały dużą popularność i stały się pewnym standardem, a następnie zostały bazowymi dystrybucjami dla innych systemów. Pojawiły się też wyspecjalizowane dystrybucje przeznaczone do bardzo konkretnych zastosowań (np. IoT), znane raczej wąskim grupom odbiorców.

W SOFTIQ wdrażamy i utrzymujemy głównie systemy Debian, Ubuntu i Red Hat Enterprise Linux (oraz pochodne takie jak AlmaLinux czy Rocky Linux). Właśnie te systemy są obecnie najczęstszym wyborem w zastosowaniach serwerowych i nic nie wskazuje, aby w najbliższych latach ten trend miałby ulec zmianie. Jako główne zalety Linuxa można wymienić dostępność typowego oprogramowania serwerowego, niższe w stosunku do systemów Windows Server wymagania sprzętowe oraz niższe koszty wdrożenia dla klienta – większość dystrybucji Linux jest bezpłatna. Jeśli wymagane jest wsparcie producenta, to z reguły stosowane są licencje na systemy RHEL.

Przedstawimy teraz szereg konkretnych zastosowań dla systemów Linux, którymi zarządzamy.

Serwery HTTP

Proces uzyskiwania przez użytkownika dostępu do dowolnego serwisu internetowego jest skomplikowanym zagadnieniem. Trzeba jednak mieć świadomość, że w komunikacji sieciowej jednym z podstawowych protokołów jest HTTP, który w ogólnym znaczeniu odpowiada za komunikację pomiędzy klientem (np. przeglądarką internetową) a serwerem WWW. Najbardziej znane serwery HTTP to NGINX i Apache.

Możliwości serwerów HTTP nie są do końca jednoznaczne. Dla prostych stron statycznych działanie serwera polega na odczytaniu pliku ze ścieżki zdefiniowanej w konfiguracji i przesłaniu jego zawartości do klienta. W przypadku bardziej złożonych serwisów, takich jak sklepy internetowe, portale informacyjne czy nawet blogi, konieczne jest wdrożenie dedykowanych aplikacji umożliwiających zarządzanie zawartością witryny. Same aplikacje mogą być napisane z wykorzystaniem różnych języków programowania. Serwery HTTP posiadają zwykle wbudowaną możliwość obsługi skryptów PHP, która jest powszechnie wykorzystywana w usługach hostingowych. Powstaje jednak coraz więcej aplikacji pisanych w innych technologiach. Do ich hostingu można zastosować rozwiązanie Phusion Passenger, które umożliwia obsługę skryptów Ruby, Node.js i Python. Nie zawsze jest to jednak wystarczające czy właściwe podejście.

Z tego powodu serwery HTTP bardzo często są stosowane w roli reverse proxy. Polega to na przekazywaniu ruchu do usług uruchomionych lokalnie na serwerze lub innych serwerach w sieci wewnętrznej, do których nie ma bezpośredniego dostępu z poziomu Internetu.

Serwery aplikacyjne

Część aplikacji internetowych w celu uruchomienia wymaga odpowiedniego serwera aplikacyjnego. Ta zasada dotyczy przede wszystkim języków Java i .NET.

W przypadku Java istnieje kilka serwerów aplikacyjnych, np. JBoss (WildFly) czy Tomcat. Do ich uruchomienia niezbędny jest wyłącznie pakiet JDK (Java Development Kit) i z tego powodu mogą działać w ramach dowolnego systemu operacyjnego. Ewentualne problemy z natywnym uruchomieniem występują dla aplikacji pisanych w technologii .NET. Do ich hostowania w systemach Linux służy rozwiązanie Mono, które pomimo ciągłego rozwoju wciąż nie zapewnia obsługi wybranych funkcji tego języka. Nie jest to jednak szczególny problem, ponieważ można wykorzystać kontenery Docker z oficjalnymi obrazami od Microsoft.

Serwery baz danych

Linux jest częstym wyborem jako system operacyjny przeznaczony do instalacji na serwerach bazodanowych. Sprawdza się przy pojedynczych instancjach uruchomionych na jednej maszynie z aplikacją, jak również w rozbudowanych klastrach stosowanych w projektach, gdzie kluczowa jest możliwe największa dostępność
i wydajność.

Przykładowe systemy baz danych, które można wdrożyć na serwerach Linux, to MySQL, PostgreSQL, MS SQL, MongoDB, Oracle Database.

Storage

Mniej zauważalnym, ale wciąż kluczowym aspektem pracy każdego systemu informatycznego jest przechowywanie danych. Dla małych projektów, w skład których wchodzi jedna maszyna, zwykle nie stosuje się dedykowanego serwera storage – dane aplikacji są zapisywane w odpowiednim katalogu. Trzeba jednak wspomnieć o dobrej praktyce korzystania z osobnego dysku (lub nawet kilku dysków ze skonfigurowanym LVM) przeznaczonego wyłącznie jako punkt montowania katalogu z danymi.

Kwestia storage w środowiskach high availability wygląda zupełnie inaczej. Przede wszystkim nie wszystkie aplikacje wymagają synchronizacji na poziomie plików, bo dane (w tym grafiki – służy do tego typ BLOB) mogą być zapisywane w bazie,
a parametry aplikacji (poświadczenia do bazy, ustawienia konfiguracyjne) niekoniecznie muszą być podane w plikach konfiguracyjnych. W tej sytuacji nie ma potrzeby stosowania synchronizacji plików.

Gdy jednak taka potrzeba zaistnieje, to najprostszym sposobem osiągnięcia synchronizacji danych pomiędzy wieloma serwerami aplikacyjnymi będzie zastosowanie NFS (Network File System). Konfiguracja jest bardzo łatwa i nie zajmuje wiele czasu. Niestety NFS nie zapewnia żadnej redundancji czy rozwiązania failover (przełączanie na działający serwer w chwili wykrycia niedostępności) – awaria serwera oznacza brak możliwości korzystania z tego zasobu przez aplikację, co nie powinno mieć miejsca w podejściu high availability.

Z tego powodu stosowany jest GlusterFS, czyli rozproszony system plików zapewniający replikację danych pomiędzy węzłami i automatyczny failover. To rozwiązanie dostępne jest wyłącznie dla systemów Linux.

W kontekście storage warto wspomnieć także o serwerach kopii zapasowych (backup). Z powodzeniem można wykorzystać np. Bareos, czyli bezpłatne narzędzie do wykonywania kopii wskazanych katalogów ze zdalnych klientów. Serwer Bareos działa jedynie w systemach Linux.

Load balancing

Jeszcze inne zastosowanie dla maszyn z zainstalowanym Linuxem to load balancing, czyli technika równoważenia obciążenia pomiędzy grupą serwerów. Wykorzystywane są różne algorytmy balansowania ruchu, od podstawowych typu round-robin po nieco bardziej skomplikowane jak IP hash czy least connection. Load balancer w sposób ciągły weryfikuje dostępność serwerów z puli i kieruje ruch sieciowy do odpowiednich hostów.

Jeden load balancer może być niewystarczający, ponieważ w tak dobranej konfiguracji stanowi on tzw. SPOF (single point of failure) – jego niedostępność spowoduje jednocześnie niemożność korzystania z usługi „ukrytej” za load balancerem. Można jednak zastosować klaster serwerów load balancer z wykorzystaniem narzędzi Corosync i Pacemaker. Jako load balancer w SOFTIQ stosujemy najczęściej sprawdzone rozwiązanie HAProxy.

Docker

W SOFTIQ w zdecydowanej większości projektów korzystamy z Docker do przeprowadzania wdrożeń oprogramowania. Umożliwia to nie tylko szybsze dostarczanie kolejnych wydań, ale też w dużym stopniu pozwala zachować przenośność – niezależnie od środowiska używany jest ten sam obraz. Dzięki zastosowaniu konteneryzacji oszczędzamy też czas podczas migracji środowisk pomiędzy maszynami, ponieważ znika problem konieczności instalacji różnych zależności (dependency hell).

Linux z pełnym przekonaniem można określić jako standardowe rozwiązanie dla konteneryzacji. Docker w systemach Linux działa bardzo stabilnie i nie wymaga żadnych opłat licencyjnych nawet w zastosowaniach komercyjnych. Nie można zapomnieć o systemach bazowych samych obrazów – z kilkoma wyjątkami są oparte na dystrybucjach Linuxa, głównie Debian i Alpine.

Elastic Stack

Jako Elastic Stack określa się stosowane wspólnie narzędzia Elasticsearch, Logstash
i Kibana, które zapewniają możliwość agregacji i przeglądania zebranych logów z różnych usług. Logi można zbierać chociażby z użyciem Filebeat (dostępne są gotowe moduły dla popularnych formatów, w innym wypadku trzeba zwykle przygotować własne reguły w Logstash). Dane prezentowane są w Kibana, gdzie można dodać przygotowane widoki (np. podgląd logów per środowisko i projekt) oraz ustawić uprawnienia dostępu dla poszczególnych użytkowników.

ELK świetnie sprawdza się w złożonych środowiskach, gdy przykładowo działa kilka serwerów aplikacyjnych. Oznacza to, że na każdej maszynie znajdują się logi, a niejednokrotnie plik logu z danego dnia ma rozmiar kilkudziesięciu gigabajtów. Wyszukiwanie konkretnych logów poprzez łączenie z każdym serwerem i ręczne wykonywanie polecenia grep nie jest efektywne. Wdrożony Elastic Stack w dużym stopniu przyspiesza ten proces, bo pozwala filtrować logi z poziomu jednego miejsca.

Proxmox

Dystrybucja Debian jest systemem bazowym dla popularnego hypervisora Proxmox. To rozbudowane oprogramowanie do wirtualizacji – na serwerach fizycznych (zwykle połączonych w klaster) o solidnych zasobach sprzętowych uruchamiane są maszyny wirtualne działające pod kontrolą właściwie dowolnego systemu operacyjnego. Wirtualizacja zapewnia m.in. możliwość zwiększenia zasobów „w locie” (np. pojemności dysku, ilości vCPU czy RAM), kontroli ich wykorzystania oraz łatwego sklonowania środowiska.