Cześć, nazywam się Robert Hryniewicz i jestem Inżynierem systemowym oraz DevOpsem w Comarch. Zajmuję się administracją systemami wewnętrznymi, wdrożeniem i administracją systemu Comarch OSS, a także w ostatnim czasie jestem współtwórcą procesu Continuous Integration i Continuous Delivery dla branży telekomunikacyjnej. Przygodę z Comarch rozpocząłem od stażu o profilu inżynier systemowy w 2016 roku. Dzisiaj opowiem Wam o drodze przez automatyzację. Postaram się nieco zdradzić, jak wprowadzenie automatyzacji wyglądało w moim dziale, jak się to zmieniło, jakich narzędzi użyliśmy kiedyś i jakich obecnie używamy. A także przybliżę, jak narzędzia do automatyzacji pomogły nam w monitoringu środowisk lokalnych czy systemów lokalnych, jak i aplikacji, którą administruje i wdrażam.

Czy jest automatyzacja i jak ją zaimplementować?

Automatyzacja to pojęcie dla nas informatyków bardzo bliskie ze względu na to, że ten proces ma ograniczyć lub zastąpić ingerencję ludzką i pracę fizyczną, lub umysłową ludzi na rzecz maszyn, które działają samoczynnie według pewnych schematów i na ogół są dużo szybsze niż ludzie.

Można się zastanawiać, czy w informatyce automatyzacja jest potrzebna, bo przecież wiele czynności np. instalacja dodatkowych pakietów czy kwestie konfiguracyjne Linux’a, można wykonać ręcznie. Wszystko byłoby w porządku, ale problem polega na tym, że wraz ze wzrostem tych czynności, prace te stają się bardzo absorbujące, a jednocześnie dla samego administratora są to dość nudne i mało rozwojowe zadania. Większość z nas chce się w pracy rozwijać, a nie powielać te same zadania, stąd automatyzacja jest tutaj wskazana i sprawia, że te monotonne czynności, stają się przyjemniejsze.

Z automatyzacją spotkałem się już na stażu, choć przyznam, że wówczas nie do końca byłem tego świadomy. Nie spodziewałem się również, że tak bardzo ten temat mi się spodoba. Zaczęło się, gdy pierwszym zadaniem było stworzenie skryptu do tworzenia kopii zapasowych baz danych Oracla. Mogłoby się wydawać, że to jest dość prosty skrypt, jednak ze względu na złożoność naszego systemu, miał być on jak najbardziej intuicyjny i możliwie zwinny tak, aby można było z niego korzystać w wielu sytuacjach i żeby, odbywało się to bez naszej ingerencji.

Było to też bardzo fajne doświadczenie dla początkującego stażysty, ponieważ mogliśmy się zapoznać z działaniem naszego systemu, jak nim administrować. Znaleźliśmy zależności, które zachodzą wewnątrz systemu. To była bardzo ważna lekcja, bo mogliśmy nauczyć się samej administracji Linux’em.

Narzędzia do automatyzacji: Crontab

Sam skrypt był dość ciężki ze względu na złożoność i ilość kopii, którą miał obsługiwać. W początkowej fazie robiliśmy wszystko jak najprościej. Chcieliśmy stworzyć dość prosty i łatwy skrypt, dlatego też skorzystaliśmy z narzędzia, jakie oferuje Linux. Jest nim Crontab. Zrobiliśmy to, żeby wyzwalać dane kopie zapasowe, żeby działo się to bez naszego udziału i najczęściej zachodzi to w nocy. Nikt z nas nie chciałby przychodzić do pracy nocą, aby tworzyć kopie zapasowe. Stąd właśnie automatyzacja w Crontabie nam pomogła.

Jednak wraz ze wzrostem ilości środowisk i chęciom ich sprawdzania, a także monitorowania stanu kopii zapasowych czy np. za dużo kopii nie odpala się w jednym czasie, żeby nie przeciążyć serwera bazy danych, jak i serwera backupu. Dlatego uznaliśmy, że musimy zmienić narzędzie. 

Narzędzia do automatyzacji: Jenkins

Po etapie poszukiwań i porównywania narzędzi najlepszym okazał się Jenkins. Dzięki niemu mogliśmy sprawdzać aktualny stan, zarządzać kolejkom, ilościom aktualnie wykonujących się kopii zapasowych. To nam bardzo uprzyjemniło pracę. Dzięki temu mieliśmy też możliwość sprawdzenia, ile aktualnie tworzy się kopii, ile jest odłożonych backupów. Jenkins dał nam też możliwość bardzo prostego zarządzania uprawnieniami. Cały proces był prosty i bardzo intuicyjny. W sumie od tego zaczęła się przygoda naszego działu z automatyzacją. Ze względu na to, że po jakimś czasie, same upgrade’y czy inne, bardzo często powtarzane przez nas czynności, przenosiliśmy do Jenkinsa. Dzięki temu pewne zadania mogliśmy odpalać za pomocą jednego kliknięcia.

Narzędzia do automatyzacji: Ansible

Wraz ze wzrostem liczby środowisk, coraz większym wyzwaniem było zarządzanie serwerami w sposób manualny. Instalacja dodatkowego pakietu wiązała się z tym, że musieliśmy się zalogować na każdą z kilkudziesięciu maszyn wirtualnych, sprawdzić, uaktualnić, sprawdzić kompatybilność i to było bardzo nieprzyjemne, toporne, czasochłonne i nużące. Z pomocą przyszedł nam Ansible.

Kiedy przychodziłem na staż, nie był on dość powszechny. W tej chwili jest to jedno z najbardziej popularnych narzędzi, które ma dość sporą społeczność fanów.

Odkąd w 2015 roku Ansible’a przejął Redhat, bardzo dużo czasu i sił włożył w to narzędzie. Dzięki temu odbywają się całe konferencje na temat Ansible’a. Sam Redhat wydał do tego narzędzia dodatkowo bardzo przyjazne Ansible Tower, a w wersji darmowej AWX.

Właśnie z AWX’a zaczęliśmy niedawno korzystać ze względu na prostą możliwość zarządzania wieloma serwerami. Osobiście przekonałem się do tego narzędzia. Jest ono bardzo wygodne, bardzo proste w użyciu, ale o tym za chwilę.

Narzędzia do monitoring: Icinga2

Przejdę teraz do części, w której chciałbym opowiedzieć o monitoringu środowisk wewnętrznych. Aby móc monitorować wszystkie środowiska, wymagało to od nas sporo nakładu pracy. Było ich bardzo dużo. Musieliśmy sprawdzać, czy nie brakuje RAM-u, czy dysk się nie zapycha, czy wystarczająca jest ilość procesów. Wraz z tym wymagało to od nas kolejnej pracy, żebyśmy cały czas sprawdzali, a nie czekali na sytuację, gdy system po prostu nagle sam przestanie działać.

Chcieliśmy wiedzieć wcześniej, że coś może pójść nie tak, aby szybko zareagować. Na stażu mogliśmy zainstalować oprogramowanie do monitoringu - Icinga2. Wybraliśmy to oprogramowanie, ponieważ mieliśmy już w nim doświadczenie. Nasz kierownik instalował ten tool u jednego z naszych niemieckich klientów, więc poszliśmy za ciosem i również wybraliśmy je do instalacji lokalnej.

Korzystaliśmy z niego około dwóch, trzech lat. Jednak w pewnym momencie zaczęło ono być niewystarczające i nieprzyjemne ze względu na konfigurację. Niestety Icinga jest konfigurowana przez linie w plikach konfiguracyjnych, co jest oczywiście zgodne z przyjętym standardem „infrastructure as a code”. Jednak przez tę toporność i brak przyjaznego gui, które pozwala łatwo tą konfiguracją zarządzać, zdecydowaliśmy się na zmianę oprogramowania do monitoringu.

Narzędzia do monitoring: Zabbix

Wybór padł na Zabbix ze względu na dużo większe community, większą społeczność fanów i znacznie większą liczbę automatycznych tooli. Zaczęliśmy go sprawdzać. Wyzwaniem była instalacja Zabbix’a na większej liczbie maszyn. Mogliśmy to robić po kolei i instalować narzędzie, wbijając się na każdą maszynę przez SSH, żeby tam odpalić komendy, przeklepać konfigurację, ale nikt z nas nie lubi robić rzeczy powtarzalnych.

Tutaj z pomocą przyszedł Ansible, którego pokochałem. Wystarczyło ściągnąć skrypty, które były gotowe do Ansible’a, stworzone przez społeczność i dostępne na publicznym repozytorium. Potem wystarczyło podać zmienne i Ansible wszystko zrobił za nas. Sama przesiadka z jednego toola do drugiego zajęła dwa dni wraz z konfiguracją kilkudziesięciu serwerów. To było bardzo proste i bardzo fajne doświadczenie.

Podsumowując, droga przez automatyzację w naszym dziale na początku była dość niemrawa i ciężka. Jednak z czasem wszyscy zauważyliśmy potrzebę używania automatyzacji ze względu na prostotę i łatwość. No i oczywiście z lenistwa. Powiedzmy sobie szczerze – dobry informatyk musi być leniwy, żeby zrobić coś, co ma działać dobrze, szybko i sprawnie.