Mam okazję pracować na kilku różnych komputerach. W domu jest to całkiem potężna maszyna z procesorem i7-6700k i 16GB RAM (mało, ale na razie OutOfMoneyError) oraz mocno przedpotopowy laptop (i5-430M 8GB RAM). W pracy mam desktopa, który próbuje działać i laptopa, który nawet nie próbuje. W domu Ubuntu, w biurze Win7. Problem komputerów biurowych jest nienaprawialny, ale na domowym laptopie postanowiłem trochę się pobawić.

Problem

Wraz z upływem czasu instalujemy różne oprogramowanie. A to potrzebny jest mySQL, a to Postgres, a to Tomcat7 albo jakiś Glassfish. Nie wspominając już o wszelakich MongoDB, Jenkinsach itp. wynalazkach. Po prostu nasza codzienna praca wymaga pewnych narzędzi na lokalnej maszynie. Po pewnym czasie ilość narzędzi i dodatków drastycznie wzrasta, a services mówi nam, że nie jest dobrze:

Listing 1. Aktywne serwisy na moim laptopie (wycinek)

$ services --status-all
 [ + ]  jenkins
 [ + ]  mongodb
 [ + ]  mysql
 [ + ]  postgresql
 [ + ]  virtualbox

A teraz niech jeszcze się okaże, że taki postgres potrzebny jest w kilku wersjach, bo coś tam, albo potrzebujemy bazę Oracle. O ile na dużej maszynie, to jeszcze jakoś zadziała, to na starym laptopie będzie już kiepsko. Co więcej serwisów tych potrzebujemy tylko wtedy, gdy pracujemy. Cały pozostały czas, to zapychacze pamięci i procesora. Co prawda skala problemu może nie być duża, bo takie mongo pochłania 1% CPU na 5 sekund. Przy ośmiu rdzeniach to tyle co nic, ale to jest puste mongo…

Rozwiązania

Zastanówmy się zatem, jak można rozwiązać ten problem – działania zbędnych serwisów. Od razu mówię, że rozwiązań jest kilka i wybór konkretnego jest mocno uzależniony od konkretnej sytuacji. Rozwiązanie preferowane przeze mnie nie musi być najlepsze dla ciebie. Choć w 95% przypadków i tak je wybierzesz 🙂

Nie uruchamianie serwisów przy starcie systemu

Pozwolę sobie to podsumować obrazkowo:

image

Jeżeli coś instalujemy jako serwis, to chcemy mieć serwis, ze wszystkimi konsekwencjami. Oczywiście, nie jest to takie proste. Jeżeli chcemy mieć kilka wersji postgresa, to możemy wybrać jedną, która będzie „tą główną”, a reszta będzie startować na żądanie. Jednak jak już mamy kilka wersji postgresa, to raczej będziemy chcieli inaczej zarządzać tym majdanem.

Delegacja

Delegacja jest chyba pierwszym pomysłem, jaki przychodzi do głowy wielu osobom, gdy mówimy o pracy z wieloma instancjami baz danych albo z CI. Polega na użyciu zdalnego rozwiązania. Tyle tylko, że my chcemy mieć serwis lokalnie. Takie rozwiązanie ma swoje zalety, bo uniezależnia nas od naszego komputera. Musimy zmienić komputer, nie ma problemu, bo dane są „gdzieś w sieci”. Tyle tylko, że brak sieci, to brak dostępu do danych. Zazwyczaj to prowadzi nas do instalacji lokalnych.

Pełna wirtualizacja

Pod pojęciem pełnej wirtualizacji rozumiem wykorzystanie na przykład VirtualBoxa. Tworzymy maszynę wirtualną, na niej instalujemy jakiś system operacyjny i następnie instalujemy interesujące nas oprogramowanie. Wszystko ładnie i pięknie działa. To rozwiązanie stosowałem już w kilku miejscach i zazwyczaj świetnie się sprawdzało. Ma ono jedynie tę wadę, że wymaga dość dużo zasobów. Narzut jest na tyle duży, że do naszej maszyny wirtualnej powinny trafić różne rzeczy, co oczywiście jest OK, ale w pewnym momencie mamy ten sam problem. Tyle że na wirtualce. Możemy jednak pójść w to rozwiązanie, jeżeli chcemy pracować z technologiami z innego systemu operacyjnego. Na przykład mamy jakiegoś UX-a, a musimy skorzystać ze sraczyka… znaczy się z IIS+MSSQLa.

Konteneryzacja

I to jest oczywiste rozwiązanie 🙂 Bierzemy Dockera i przygotowujemy sobie kilka obrazów. Jak potrzeba nam jakiegoś konkretnego softu, to uruchamiamy taki obraz i działa. Ale… no właśnie jest jedno, a w zasadzie dwa, ale. Pierwsze dotyczy uruchamiania oprogramowania, które nie jest przeznaczone dla naszego systemu operacyjnego. W tym przypadku się nie da, względnie takie oprogramowanie wymaga kombinowania. Drugim jest konieczność odpowiedniego, dodatkowego skonfigurowania oprogramowania. Przykładowo, jeżeli chcemy mieć kilka instancji postgresa, to niezbyt dobrym pomysłem jest składowanie danych w domyślnym katalogu. Po prostu będzie się to gryźć samo ze sobą. Dlatego musimy odpowiednio przygotować własny obraz albo skrypt, który uruchomi nam obraz z odpowiednimi parametrami. Zaletą jest stosunkowo niewielki narzut po stronie dockera (w sumie zerowy, bo wykorzystujemy istniejące mechanizmy jądra) oraz łatwość w użyciu.
Co więcej, jeżeli koniecznie chcemy całość odizolować, to możemy naszego dockera zamknąć w jakimś vagrancie, ale to już sztuka dla sztuki… choć użytkownicy maców często tak robią. Może wpływ opiatów?

Podsumowanie

Mojego prywatnego laptopa powoli przestawiam na model z dockerem. Jest to o tyle ważne, że ma on już kilka dobrych lat i po prostu nie działa już tak szybko, jak bym chciał. Wyczerpałem też możliwości rozbudowy zarówno jeśli chodzi o RAM, jak i dysk ssd. Pozostaje zatem kombinowanie z oprogramowaniem. Docker wydaje się odpowiednią ścieżką. Będzie działać z Ubuntu 14.04. Zapewnia znaczną elastyczność i łatwość w migrowaniu. Będzie dobrze 🙂