Slackware & Qemu - Część 2: Rust vs Ansible

Ciekawy tytuł, czyż nie ? Jak Rust może być porównywany do Ansible ? Język systemowy kontra narzędzie do konfiguracji infrastruktury ? Cóż, może być porównywany, tak długo, jak jest używany w ten sam sposób. I uwierz, może być używany w ten sam sposób. Skąd zatem pomysł, żeby używać Rusta jako narzędzia do konfiguracji systemu ? Tak naprawdę wszystko zaczęło się od używania Ansible'a od kilku już lat. Ansible to naprawdę dobre narzędzie z dobrym pomysłem, ale ma swoje wady. Pomimo tego został uznany przez lata i jeszcze będzie na rynku przez najbliższe lata. Niestety, jedną z rzeczy która mi się nie podoba, bo brak kompatybilności wstecznej, głównie przez szybko zmieniające się moduły. Jednym z prawdopodobnych powodów, może być to, że Ansible jako taki jest oparty na Pythonie, który przez ostatnie lata rozwija się bardzo szybko, więc naturalnie nie sposób sprawić, żeby wszystko było ze sobą kompatybilne. Wracając do meritum - był taki rok, kiedy używałem Ansible'a do konfiguracji Zabbixa. Całkiem sprawnie to działało, poza tym, że nie było modułu do konfiguracji itemów (wielka szkoda). Ale nawet pomimo tego braku, zkonfigurowałem to co mogłem/chciałem, tak jak chciałem, więc o to chodziło. Po czym przyszedł czas, że moduł itemowy został dodany - co za rewelacja pomyślałem. Prawie mnie tym kupili. Skonfigurowałem zatem to czego mi brakowało i zająłem się swoimi pozostałymi zadaniami na polu DevOpsowym. Kilka miesięcy później został zatrudniony kolega i pyta mnie, czy używamy Ansible'a. Jasne, odpowiadam na to, bardzo proszę, tutaj są playbooki. Jakież było moje zdziwienie, kiedy okazało się, że Ansible zmienił jeden z podstawowych modułów do logowania do Zabbixa ! I w ten sposób wszystkie playbooki zostały skazane na przepisanie. Nie była to dobra wiadomość, ale jak trzeba to trzeba. Takie "suboptymalne" rozwiązanie. Jak chodzi o sam moduł Ansible do Zabbixa, to podjęto nie do końca dobrą decyzję - trzeba się zalogować przez SSH, żeby robić zapytania do Zabbix API na poziomie localhost (?!). Zabbix API to jedna z lepszych rzeczy w tym narzędziu, zwłaszcza, że można generować token używająć swoich danych i tego tokena używać do konkretnych zapytań API. Do tego ten token nie jest przechowywany, więc ogólnie rzecz biorąc, to dobry model. Sesja SSH dodaje tylko kolejną warstwę i czas wykonania. 
    Po jakimś czasie, poznając Rusta nieco lepiej, doszedłem do pytania - dlaczego nie użyć Rusta do konfiguracji serwerów ? Powinien być szybszy i bardziej kompatybilny z tym co się pisze. Pomyślałem, że warto spróbować. Najpierw musiałem znaleźć bibliotekę, która radzi sobie z absolutnymi podstawami pracy SysOps - czyli SSH. Całe szczęście jest kilka do wyboru, ale sam wybrałem russh. Jest to biblioteka obecnie utrzymywana, i ma potrzebną cechę - obsługa interaktywnych sesji. Nie jest to napewno najłatwiejsza biblioteka do obsługi, ale po kilku testach i błędach udało się jej użyć tak jak chciałem. 
    Do testów przygotowałem 10 VM (info w innym poście) - 1 CPU / 512 MR Ram. Oto rezultaty:
1) Wykonanie 3 prostych komend (ls -la, df -h, touch file.test) w jednej sesji:
    a) Ansible (usunięcie niepotrzebnych opcji) - ~45s
    b) Rust (binarka debug - bez optymalizacji) - ~16s
2) Wykonanie 3 prostych komend (ls -la, df -h, touch file.test) w 3 sesjach:
    a) Ansible - ~1m40s,
    b) Rust - ~45s
Jak widać, Rust ma zdecydowaną przewagę w czasie wykonywania, sięgającą ~50% - ~60% nad Ansible. I to są testy wykonane w sieci lokalnej, przy pingu poniżej 0.1ms ! Więcej testów wkrótce. 
    Podsumowując, oczywiście Rust ma dużo większy "próg wejścia" i wymaga więcej nauki na początku, ale to nie będzie zmarnowany czas. Rust jest zbudowany z myślą o szybkości i modułowości, co może okazać się kluczowe wraz z rozwojem infrastruktury. Możesz spróbować jak to działa, wystarczy pobrać bibliotekę z crates.io - devops-armory, która korzysta z pliki TOML, jako źródła informacji.