Ansible – wprowadzenie do automatyzacji sieci

Wpis powstał na podstawie cyklu Próba Połączenia, podcastu, w którym inżynierowie rozmawiają z inżynierami na tematy związane z sieciami, bezpieczeństwem i DevOps.

• Czym jest automatyzacja sieci?
• Czy wszystko da się zautomatyzować?
• Jak Ansible może w tym pomóc?
• Jakie są wady Ansible?

Słuchaj tam, gdzie lubisz

Ansible w automatyzacji sieci

Cześć witam w podcaście Próba Połączenia, w którym rozmawiamy o sieciach, bezpieczeństwie i kulturze DevOps. W dzisiejszym odcinku porozmawiamy o automatyzacji sieci i tym w jaki sposób można wykorzystać do tej sytuacji Ansible. Nazywam się Mateusz Buczkowski, a moim gościem jest Karol Piątek, System Engineer w Grandmetric

Czym jest automatyzacja?

Mateusz Buczkowski: Chciałbym zacząć od takiego podstawowego spojrzenia właśnie na to, czym jest ta automatyzacja i po co ją stosujemy. Jakie problemy rozwiązuje?

Karol Piątek: Wszystko zależy od tego, jak wykorzystamy tę automatyzację. Z jednej strony, jeżeli mamy np. sto urządzeń do skonfigurowania, to klepać konfigurację na każde urządzenie to jednak jest czasochłonne i pracochłonne. Staramy się unikać takich sytuacji i w tym momencie wchodzi np. Ansible.  Przykładowo dzięki Ansible możemy wgrać konfigurację na wielu urządzeniach jednocześnie nie popełniając błędu. Ale z drugiej strony, jeżeli gdzieś w procesie automatyzacji popełnimy jakiś błąd, to wówczas będziemy mieli ten błąd powielony na wielu urządzeniach. Także można powiedzieć, automatyzacja to jednocześnie dar i przekleństwo.

Mateusz: No ale nawet jeśli rozpropagujemy błąd w konfiguracji, to tak samo w automatyczny sposób można go poprawić na tych wszystkich urządzeniach.

Karol: Tak, jeżeli nie jest na tyle krytyczny że np. odetnie nam dostęp do urządzenia.

Mateusz: A czy np. urządzenia, które się w jakiś sposób różnią od siebie możemy skonfigurować automatycznie, czy najpierw musimy je skrupulatnie pogrupować na różne klasy czy wersje i w ten sposób podchodzić do automatyzacji?

Karol: Tutaj raczej w większości przypadków będzie tak, że będzie to zależało bardziej od producenta urządzenia niż od wersji urządzenia. Zazwyczaj moduły, z których korzysta Ansible są stworzone pod konkretnego producenta. Na przykład, jeśli mamy switche Cisco, wówczas będziemy mieli moduł do urządzeń Cisco. Wyjątkiem jest np. firewall. Na przykład firewall od Cisco ma swój osobny moduł. Jakbyśmy chcieli wykorzystać przełączniki Huawei, to z kolei byśmy musieli się rozglądać za odpowiednim modułem dla Huawei. Ale oczywiście możemy to zrobić w ten sposób, że sobie pogrupujemy te urządzenia. Zazwyczaj tworzy się taki plik z całym inventory i w tym inventory robimy nagłówki i grupujemy urządzenia. Wówczas możemy w jednym playbookiem załatwić wiele różnych urządzeń na różne sposoby. Możemy dane zadanie wykonać dla danej grupy albo nawet zrobić kilka playbooków, które będą się odpalać z innego playbooka. Taka incepcja.

Playbook to zestaw instrukcji, który chcemy zaaplikować w jakieś miejsce, np. na switch czy na jakiegoś hosta.

Praktyczna automatyzacja dla inżyniera systemów

Mateusz: No właśnie – mówimy tutaj o playbookach i o tym, czy możemy sobie coś zautomatyzować. Jakbyś mógł podać przykłady właśnie takich rzeczy w sieci, które możemy sobie automatyzować? Co jest dla ciebie najwygodniejszą automatyzacją, która ułatwia Ci pracę?

Karol: Można powiedzieć, że wszystko zależy od tego, jak bardzo kreatywni jesteśmy. Faktycznie, istnieją ograniczenia technologiczne, ale mimo wszystko tak jak już wspomniałem, przykładowo konfiguracja wielu urządzeń za pomocą playbooka. Jeszcze warto wspomnieć, że przy konfiguracji wielu urządzeń naraz, mimo wszystko te urządzenia muszą mieć jakąś bazową konfigurację. To podstawowa konfiguracja, która pozwala na wykorzystanie protokołu i dostanie się w ogóle na te urządzenia.

Ale to nie są tylko konfiguracje np. możemy robić też np. odpowiedź maszyny wirtualnej i tam wprowadzać po prostu szereg różnych parametrów i na tej bazie tworzyć maszynę wirtualną albo np. backup, żeby cyklicznie wykonywały się jakieś akcje. No i właśnie chyba taki to jest jakby coś z czym najwięcej siedziałem tzn. tworzenie automatycznych backupów, wrzucanie ich do gita i drugie to tworzenie maszyn wirtualnych.

Mateusz: Ok. Jeśli mówimy o automatyzacji i zwróceniu tych konfliktów zastanawiam się jeszcze nad jedną rzeczą. Czy wprowadzając taką automatyzacja można zmieniać jeszcze rzeczy ręcznie. Czy ręczne poprawki mogą prowadzi do konfliktu z tymi automatami?

Karol: Mamy trzy możliwe komunikaty tego co wyskoczy, jeżeli odpalimy takiego playbooka, czyli zestaw instrukcji który chcemy zaaplikować w jakieś miejsce czyli np. na switche czy na jakiegoś hosta. Jeden to jest, że się nie udało. Wówczas jest on oznaczany kolorem czerwonym. Drugi mamy żółty i to jest zazwyczaj taki, że już zostało coś wykonane i po prostu wymieniamy, i zielony, czyli że zostało wykonane zadanie. No więc możemy wpisywać, ale też bywają takie przypadki że np. widzisz, że coś już było dodane to on tego nie chce drugi raz dodać. To są jakby takie niuanse ze względu na to, że te moduły są też różne, przez różne osoby tworzone, niektóre są nieoficjalne. No i myślę że to że generalnie da się robić niezależnie.

Jeżeli chodzi o mnie, to zawsze moja procedura jest taka, że na początku robię coś ręcznie w całości, później staram się na jednym urządzeniu odpalić playbooka, żeby po prostu nie zepsuć czegoś na początek i sprawdzić, czy to zadziała. Jeżeli zadziała na jednym, to zwiększam liczbę od razu na wszystkie. Więc mimo wszystko zaczynamy od konfiguracji. Ale myślę że to jest bardziej taka moja praktyka i dla bezpieczeństwa raczej.

Mateusz: Na jak dużej lczbie urządzeń pracowałeś z automatyzacją? Czy są jakieś ograniczenia, czy możemy z automatu skonfgurować 10, 100 lub 1000 urządzeń?

Karol: Myślę, że 1000 też powinno pójść spokojnie, tylko że to też zależy od tego, jak korzystamy z Ansible. Jeśli korzystamy z sesji jako open source, poradziliśmy sobie z instalacją na jakiś Linuxie, to z praktyki wiem, że praca z dużą liczbą urządzeń nie zawsze wychodzi. Lepiej sobie rozbić to na kilka zadań, na kilka partii, ponieważ jak się puści np. sto urządzeń jednocześnie, to na co którymś może wyskoczyć błąd połączenia, nawet jeśli połączenie było możliwe.

To może być spowodowane oczekiwaniem na połączenie albo jakąś małą utratą pakietów gdzieś po drodze i Ansible stwierdza, że to nie jest to i omija. Dlatego ja bym to podzielił. Aczkolwiek jest jeszcze Ansible od Red Hata, ale to jest jeszcze inny temat. Ale tam ciężko powiedzieć, może jest to rozwiązane w jakiś sposób.

Ansible alternatywy

Mateusz: Ansible jako open source i Red Hat. Czym to się różni i jakie są wady i zalety tych rozwiązań?

Karol: Osobiście nie korzystałem z płatnej wersji tej redhatowej, ale wiem że jest dość rozbudowana. To znaczy, tak jak mówiłem moduły są różne w Ansible. Osobiście spotkałem się chociażby z jednym, który nie do końca działał tak jak powinien. Red Hat z tego co wiem szczyci się właśnie tym, że tam ma oficjalne moduły – to jest po pierwsze. Po drugie – to jest cała platforma Red Hat Ansible Automation Platform. Jak go można wykorzystać? Choćby do planowania i automatycnego odpalania playbooków. Jeżeli teraz bym chciał np. robić backupy raz w miesiącu na jakiejś określonej liczbie urządzeń, dzięki platformie nie musiałbym skorzystać z dodatkowego narzędzia np. Jenkinsa, żeby ustawić akcję na dany dzień i godzinę.

Mateusz: Alternatywy jakieś jeszcze są dla Ansible? Jakieś inne narzędzia, z których możemy korzystać do automatyzacji? Czy jesteśmy ograniczeni do tego Ansible open source i redhatowego?

Karol: Jest więcej takich narzędzi. Te, które mi przychodzą do głowy to jest Puppet, Chef i Saltstack, jeśli dobrze pamiętam. Różnią się one w ten sposób, że jeśli mówimy o samych podstawach, no to Ansible bazuje w głównej mierze na jamlach i na Pythonie. Saltstack działa podobnie to znaczy, Saltstack też opiera się na Pythonie, a z kolei Chef i Puppet działają na Ruby. I to jest zasadnicza różnica. Oprócz tego Ansible jest bezagentowy. Nie potrzebujemy niczego na hoście, wystarczy, że podłączamy się do urządzenia i wykonujemy jakieś operacje. Saltstack może zarówno agentowo i bez agentowo działać, a Chef jest typowo agentowy.

Mateusz: Rozumiem, że tobie Ansible w zupełności wystarczy. Spodziewasz się, że gdzieś może być granica możliwości Ansible, że czegoś nie będziesz mógł zrobić?

Karol: Jeszcze do niej nie dotarłem, ale jestem w stanie uwierzyć że gdzieś tam jest granica. Ale wydaje mi się, że mimo wszystko dałoby się ją jakoś przeskoczyć korzystając z samego Pythona, czyli dopisując sobie jakiś moduł.

Mateusz: Jeśli to jest open source, to faktycznie można sobie rozszerzyć to narzędzie.

Karol: Więc myślę że da się dopisać. Dla chcącego nic trudnego. Jeśli ktoś chciał sobie to w Pythonie rozwinąć na swój sposób, to na pewno jest to realne.

Ansible playbook a monitoring sieci

Mateusz: A powiedz jeszcze, czy automatyzację można w jakiś sposób powiązać z monitoringiem, czy te dwa obszary mogą jakoś się przenikają. Czyli czy możemy wykorzystywać Ansible do tego żeby polepszyć nasz monitoring, poprawić jakość tych usług?

Karol: Myślę, że tak ze względu na to, że np. wyobraźmy sobie taki mechanizm, w którym na jakieś zdarzenie na urządzeniu otrzymujemy alert, bo ustawimy threshold konkretny na jakiś port albo na jakąś przepustowość. Jeżeli przekroczy – spływa alert. Można sobie ustawić coś takiego, że pojawienie się alertu spowoduje uruchomienie komendy na konkretnym hoście. Jeżeli taką komendą mieliśmy ogranego np. playbooka gotowego, który wówczas jakoś tam zadziała np. jeżeli wykryje Error Disable na porcie na switchu,to zrestartuje ten port.  Więc wyobraźmy sobie sytuację, że lokator w akademiku nieprawidłowo podłączył router, czym spowodował wyłączenie portu. Dzięki automatyzacji, możemy od razu taki stan wykryć i podnieść port. Robimy to, co zrobiłby inżynier po otrzymaniu zgłoszenia, czyli sprawdzamy stan portu i decydujemy o wykonaniu akcji.

Mateusz: Czy pisząc playbooki czujesz się bardziej inżynierem sieci czy bardziej programistą?

Karol: Dobre pytaie. Na początku byłem trochę uprzedzony. Nie przepadam za pisaniem kodu. Ale siłą rzeczy w końcu przeszedłem no niego i okazało się że to nie jest takie trudne. To nie jest właśnie takie typowe programowanie. To jest bardziej listowanie konkretnych poleceń. Pracuję w sieciach, ale jednocześnie wkraczam chwilami w świat DevOpsowy. Myślę że pomiędzy nimi kluczę. No ale mimo wszystko to jest łatwe. Raczej uważam że to bardzo przystępny język, łatwo te polecenia wydawać. Składnia nie jest skomplikowana, ale trzeba się z nią zapoznać. Przykładowo: dwukropek oddziela nam klucze od wartości. Albo jeżeli chcielibyśmy oddzielić jakieś polecenie nadrzędne i podrzędne, to też trzeba je rozdzielić odpowiednio spacjami, a nie tabulatorami Jest kilka takich niuansów. Tak samo playbooka zaczyna się trzema myślnikami, a powinno się kończyć trzema kropkami. Mało kto kończy tymi trzema kropkami, aczkolwiek taka jest praktyka.

Mateusz: A pamiętasz swoją pierwszą automatyzację? Swojego pierwszego playbooka? Co on robił?

Karol: Miał robić cykliczne backupy urządzeń. Pamiętam, że dosyć długo siedziałem nad tym problemem, mimo że nie był jakiś bardzo skomplikowany. Okazało się, że tam właśnie moduł nie do końca spełnił swoje zadanie. Czy teoretycznie powinien to robić, ale nie robi. To taki blocker, aż w końcu się zdecydowałem jeszcze zapakować trochę batcha do tego playbooka no i wówczas to zadziałało. Ale trochę na nim siedziałem, mimo że nie był jakiś bardzo ambitny. Ale to pierwsze kroki, to też nawet nie starałem się jakby za bardzo wgryźć w ten temat, tylko raczej spontanicznie pisać kod.

Wady Ansible

Mateusz: A jakbyś miał mi powiedzieć, jaka jest największa wada albo trudność z Ansible? Jest wolny, słaba dokumentacja, źle raportuje błędy? Czy radzi sobie z obsługą błędów, jak coś pójdzie nie tak na urządzeniu?

Karol: To, co mi przychodzi do głowy jako pierwsze to uważam, że słabo wskazuje miejsce, w którym jest błąd. Mimo, że ma możliwość sprawdzenia, czy playbook zadziała i ma też wbudowaną możliwość sprawdzenia składni i kilka poziomów debuggingu – cztery poziomy debuggingu. Mimo wszystko jeżeli już wskazuje jakiś błąd składniowy czy literówkę, to nie wskazuje dokładnie. No raczej tak mniej więcej pokazuje, że to jest gdzieś w tym miejscu. A czasami to takie niuanse jak spacja za mało. Czasami to faktycznie literówki. Tak miałem do czynienia z oprogramowaniem w C++ czy C#, tam debugger pokazuje konkretnie miejsce błędu. Ansible tego nie ma. No i rzeczywiście to nie jest demon szybkości. Czyli spełni swoje zadanie, ale czasami trzeba trochę poczekać zanim on zbierze dane z powiedzmy stu jakichś urządzeń sieciowych. No to trochę trwa.

Mateusz: Dalej szybciej niż ręcznie.

Karol: Oczywiście – szybciej niż ręcznie, tyle że nadal ta prędkość nie jest jego głównym atutem. Jak byśmy sobie chcieli zbudować np. drzewo połączeń to też trochę by to trwało, bo on musiałby sobie jednak poskakać po tych urządzeniach, wylistować, a to już grubsza sprawa.

Mateusz: Dzięki w takim razie za tę rozmowę. Naszym gościem był Karol Piątek, Systems Engineer w Grandmetric. W dzisiejszym odcinku rozmawialiśmy o Ansible – o tym jak wykorzystać go do automatyzacji sieci. Czy to musi być Ansible? Jakie są alternatywy, bo jak widać też, że te narzędzia potrafią mieć pewne wady, zalety, także warto rozpoznać tutaj swoje opcje i z jakich narzędzi skorzystać.