Krajowa Służba Informacyjna Danych Satelitarnych o Środowisku (NESDIS) zmniejszyła swoje wydatki na zarządzanie konfiguracją systemu Red Hat Enterprise Linux (RHEL) o 35% przechodząc z Puppet Enterprise na Ansible Tower. W tym filmie z kategorii „jak to zrobiliśmy” inżynier systemowy Michael Rau uzasadnia tę migrację, dzieli się cennymi wskazówkami oraz doświadczeniem zdobytym podczas przejścia z jednego SCM na drugie.
Z tego filmu dowiesz się:
- jak uzasadnić kierownictwu zasadność przejścia z Puppet Enterprise na Ansible Tower;
- jakie strategie zastosować, aby zapewnić jak najbardziej płynne przejście;
- wskazówki dotyczące transkodyfikacji manifestów PE do Ansible Playbook;
- zalecenia dotyczące optymalnej instalacji Ansible Tower.
Witam wszystkich, nazywam się Michael Rau, jestem starszym inżynierem systemowym w firmie ActioNet, która współpracuje z Krajowym Urzędem ds. Oceanicznych i Atmosferycznych (NOAA) w ramach służby NESDIS. Dziś porozmawiamy o „skrótach” – moim osobistym doświadczeniu migracji z Puppet Enterprise na Ansible Tower. Tematem tej prezentacji jest „zerknąć na moje blizny”, które pozostały po dokonaniu tej migracji na początku roku. Chcę opowiedzieć, czego się nauczyłem w tym procesie. Tak więc, gdy zabierzesz się za coś podobnego, korzystając z mojego doświadczenia, będziesz mógł wykonać to przejście bez zbędnego wysiłku.
Widzisz slajdy podobne do tego na początku każdej prezentacji na Ansible Fest. Na tym slajdzie przedstawiono historię automatyzacji mojej firmy. Nie jestem nowicjuszem w tej dziedzinie, ponieważ korzystam z Puppet/Puppet Enterprise od 2007 roku. Zacząłem pracować z Ansible od 2016 roku i, podobnie jak wielu innych użytkowników tego produktu, przyciągnęła mnie możliwość „sztuczek” za pomocą wiersza poleceń i prostych skryptów (playbooków). Pod koniec 2017 roku zwróciłem się do swojego kierownictwa z poważnymi argumentami przemawiającymi za przejściem na Ansible Tower. Za chwilę opowiem o powodach, które skłoniły mnie do tego kroku. Po uzyskaniu zgody kierownictwa zajęło jeszcze kilka miesięcy zrealizowanie planu, a ja zrealizowałem migrację w styczniu-lutym tego roku. Tak więc całkowicie zrezygnowaliśmy z Puppet na rzecz Ansible, co jest wielką sprawą.
Najbardziej fascinującą cechą Ansible jest możliwość pisania i używania ról oraz scenariuszy. Role idealnie nadają się do tworzenia różnych, ale powiązanych zadań i gromadzenia wszystkich danych związanych z tymi zadaniami w jednym miejscu. Playbook to składnia YAML, plik skryptowy opisujący akcje dla jednego lub kilku hostów. Informuję o tych możliwościach użytkowników, przede wszystkim programistów. Ansible Tower umożliwia stwierdzenie: „nie, nie masz dostępu do powłoki, ale daję ci możliwość uruchomienia wszystkich procesów Tower i ponownego uruchomienia usługi, kiedy będziesz tego potrzebować”. Opowiem o naszym środowisku pracy i używanym sprzęcie.
To federalna sieć LAN, 7 fizycznych lokalizacji połączonych przez chmurę MPLS, 140 serwerów RHEL, z czego 99% to serwery wirtualne (vSphere), sprzęt SuperMicro, pamięć sieciowa NexentaStore, zestaw przełączników Cisco, Arista i Cumulus, a także zintegrowane systemy zarządzania zagrożeniami Fortinet UTM w każdej lokalizacji.
Sieć federalna oznacza, że muszę stosować wszystkie środki ochrony informacji przewidziane ustawodawstwem. Należy pamiętać, że Puppet Enterprise nie obsługuje większości używanego przez nas sprzętu. Jesteśmy zmuszeni korzystać z budżetowego sprzętu, ponieważ organy rządowe mają problemy z finansowaniem tej pozycji wydatków. Dlatego kupujemy sprzęt klasy SuperMicro i składamy nasze urządzenia z osobnych komponentów, których serwisowanie jest gwarantowane przez kontrakty rządowe. Używamy Linuxa, i to jedna z ważnych przyczyn przejścia na Ansible.
Nasza historia pracy z Puppet jest następująca.
W 2007 roku mieliśmy małą sieć liczącą 20-25 węzłów, w której wdrożyliśmy Puppet. Głównie te węzły przedstawiały proste „pudełka” RedHat. W 2010 roku zaczęliśmy korzystać z interfejsu webowego Puppet Dashboard dla 45 węzłów. W miarę jak sieć się rozwijała, w 2014 roku przeszliśmy na PE 3.3, dokonując pełnego przejścia z przepisaniem manifestu dla 75 węzłów. Konieczność ta wynikała z tego, że Puppet lubi zmieniać zasady gry, a w tym przypadku całkowicie zmieniono język. Rok później, gdy wsparcie dla 3. wersji Puppet Enterprise zostało zakończone, byliśmy zmuszeni do migracji na PE 2015.2. Musieliśmy ponownie przepisać manifest na nowe serwery i zakupić licencję z zapasem na 100 węzłów, mimo że w tym czasie mieliśmy tylko 85 węzłów.
Minęły zaledwie 2 lata i znów byliśmy zmuszeni do przeprowadzenia dużej pracy związanej z przejściem na nową wersję PE 2016.4. Kupiliśmy licencję na 300 węzłów, mając jedynie 130. Ponownie musieliśmy wprowadzić poważne zmiany w manifeście, ponieważ nowa wersja języka miała składnię różniącą się od składni wersji 2015. W efekcie nasza SCM przeszła z systemu kontroli wersji SVN na Bitbucket (Git). Takie były nasze „relacje” z Puppet.
Musiałem więc wyjaśnić kierownictwu, dlaczego musimy przejść na inny SCM, używając następujących argumentów. Pierwszy - wysoka cena usługi. Rozmawiałem z chłopakami z RedHat i powiedzieli, że koszt utrzymania sieci 300 węzłów za pomocą Ansible Tower wynosi połowę kosztów Puppet Enterprise. Jeśli kupisz jeszcze Ansible Engine, koszty będą mniej więcej takie same, ale otrzymasz znacznie więcej funkcji niż w PE. Jako że jesteśmy państwową firmą finansowaną z budżetu federalnego, to dość mocny argument.
Drugim argumentem jest wszechstronność. Puppet obsługuje tylko to wyposażenie, na którym zainstalowany jest agent Puppet. Oznacza to, że na wszystkie przełączniki trzeba zainstalować agenta, a on musi być najnowszej wersji. A jeśli część Twoich przełączników obsługuje jedną wersję, a część inną, będziesz musiał zainstalować na nich nową wersję agenta PE, aby wszystkie mogły działać w jednym systemie SCM.
System Ansible Tower działa inaczej, ponieważ nie ma żadnych agentów, ale posiada moduły wspierające przełączniki Cisco oraz inne przełączniki. Ten SCM wspiera Qubes OS, Linux oraz 4.NET UTM. Ansible Tower obsługuje także kontrolery sieciowych magazynów NexentaStore, oparte na jądrze Illumos – systemie operacyjnym open-source bazującym na Unixie. To bardzo ograniczone wsparcie, ale Ansible Tower i tak je oferuje.
Trzeci argument, bardzo ważny zarówno dla mnie, jak i dla naszej administracji, to łatwość nauki. Przez 10 lat uczyłem się modułów i kodu manifestów Puppet, ale Ansible opanowałem w ciągu tygodnia, ponieważ z tym SCM dużo łatwiej się pracuje. W przypadku uruchamiania plików wykonywalnych, o ile nie robisz tego bez potrzeby, współpracują z nimi rozsądne i responsywne procesory. Skrypty playbooków oparte na YAML charakteryzują się łatwością nauki i szybkością użycia. Ci, którzy nigdy wcześniej nie słyszeli o YAML, mogą po prostu przeczytać skrypty i łatwo zrozumieć, jak to działa.
Szczerze mówiąc, Puppet znacznie komplikuje twoją pracę jako dewelopera, ponieważ opiera się na użyciu Puppet Master. To jedyna maszyna, która ma prawo komunikować się z agentami Puppet. Jeśli wprowadzisz jakieś zmiany w manifeście i chcesz przetestować swój kod, musisz przepisać kod dla Puppet Mastera, czyli skonfigurować plik Puppet mastera /etc/hosts do połączenia wszystkich klientów i uruchomić usługę Puppet Server. Dopiero po tym możesz przetestować działanie sprzętu sieciowego na jednym hoście. To dość bolesna procedura.
W Ansible wszystko jest znacznie prostsze. Wszystko, co musisz zrobić, to opracować kod dla maszyny, która ma możliwość połączenia się za pomocą protokołu SSH z testowanym hostem. Z tym pracuje się dużo łatwiej.
Kolejną dużą zaletą Ansible Tower jest możliwość wykorzystania już istniejącego systemu wsparcia i zachowania istniejącej konfiguracji sprzętu. Ten SCM bez żadnych dodatkowych działań wykorzystuje wszystkie dostępne informacje o twojej infrastrukturze i sprzęcie, maszynach wirtualnych, serwerach itd. Może komunikować się z twoimi serwerami RH Satellite, jeśli takie są dostępne, i zapewnia integrację, jakiej nigdy nie otrzymasz, pracując z Puppet.
Kolejną istotną kwestią jest szczegółowa kontrola. Wiesz, że Puppet to system modułowy, jest to aplikacja klient-serwer, więc musisz określić istniejące aspekty działania wszystkich swoich maszyn w jednym długim manifeście. Przy tym stan każdego poszczególnego elementu systemu należy testować co pół godziny – to domyślny okres. Tak działa Puppet.
Tower uwalnia cię od tego problemu. Możesz swobodnie wykonywać różnorodne procesy na różnych urządzeniach, możesz wykonywać podstawowe zadania, uruchamiać inne ważne procesy, konfigurować system zabezpieczeń, pracować z bazami danych. Możesz robić wszystko, co w Puppet Enterprise wiąże się z pewnymi trudnościami. Na przykład, jeśli skonfigurowałeś na jednym hoście, potrzebujesz czasu, aby zmiany weszły w życie na pozostałych hostach. W Ansible wszystkie zmiany wchodzą w życie jednocześnie.
Na koniec omówmy moduł zabezpieczeń. W Ansible Tower został on zrealizowany w sposób niesamowity, z dużą precyzją i starannością. Możesz przyznawać użytkownikom dostęp do konkretnych usług lub do konkretnych hostów. Postępuję tak z moimi pracownikami, którzy są przyzwyczajeni do pracy na Windows, ograniczając ich dostęp do powłoki Linuxa. Zapewniam im taki dostęp do Tower, aby mogli wykonywać tylko te zadania i uruchamiać tylko te usługi, które należą do ich kompetencji.
Przyjrzyjmy się kwestiom, które należy rozwiązać wcześniej, aby ułatwić przejście na Ansible Tower. Przede wszystkim musisz przygotować swoje urządzenia. Jeśli jakieś elementy twojej infrastruktury nie znajdują się jeszcze w bazie danych, musisz je tam dodać. Są systemy, które nie zmieniają swoich właściwości i dlatego brakuje ich w bazie danych Puppet, ale jeśli nie dodasz ich przed przejściem na Tower, stracisz wiele korzyści. Może to być „brudna”, wstępna baza danych, ale musi zawierać informacje o całym posiadanym przez ciebie sprzęcie. Dlatego warto napisać dynamiczny skrypt sprzętowy, który automatycznie wprowadzi wszelkie zmiany infrastruktury do bazy danych, dzięki czemu Ansible będzie wiedział, które hosty powinny znajdować się w nowym systemie. Nie będziesz musiał informować tego SCM, które hosty dodałeś i których hostów już nie ma, ponieważ wszystko to pozna automatycznie. Im więcej danych będzie w bazie danych, tym bardziej użyteczny i elastyczny będzie Ansible. Działa tak, jakby po prostu odczytywał kod kreskowy stanu sprzętu z bazy danych.
Spędź trochę czasu na zapoznaniu się z działaniem wiersza poleceń w Ansible. Uruchom kilka specjalnych poleceń, aby sprawdzić działanie skryptu sprzętowego, napisz i uruchom kilka prostych, ale przydatnych scenariuszy playbook, skorzystaj z szablonów Jinja2 tam, gdzie to stosowne. Spróbuj napisać rolę i skrypt dla złożonego wieloetapowego procesu, używając standardowej, często spotykanej konfiguracji sprzętu. Pobaw się tymi rzeczami, przetestuj, jak to działa. W ten sposób nauczysz się pracować z narzędziami do tworzenia bibliotek używanych w Tower. Już mówiłem, że przygotowanie do przejścia zajęło mi około 3 miesięcy. Myślę, że na podstawie mojego doświadczenia uda ci się to zrobić szybciej. Nie traktuj tego czasu jako straconego, ponieważ później odczujesz wszystkie korzyści z wykonanej pracy.
Następnie należy zdecydować, czego oczekujesz od Ansible Tower, co konkretnie ten system ma dla ciebie zrobić.
Czy potrzebujesz wdrożenia systemu na pustym sprzęcie lub na pustych maszynach wirtualnych? Czy chcesz zachować oryginalne warunki pracy i ustawienia istniejącego sprzętu? To bardzo ważny aspekt dla działalności firm rządowych, dlatego musisz mieć pewność, że uda ci się przeprowadzić migrację i wdrożyć Ansible w istniejącej konfiguracji. Zidentyfikuj rutynowe procesy administracyjne, które chcesz zautomatyzować. Dowiedz się, czy potrzebujesz wdrożyć na nowym systemie specyficzne aplikacje i usługi. Sporządź listę działań, które chcesz podjąć, i nadaj im priorytety.
Następnie przystąp do pisania kodu skryptów i ról, które zapewnią wykonanie zaplanowanych zadań. Połącz je w Projekty, logiczną kolekcję odpowiednich skryptów playbooków. Każdy Projekt będzie odnosił się do oddzielnego repozytorium Git lub innego repozytorium w zależności od używanego menedżera kodu. Możesz zarządzać skryptami playbooków i katalogami playbooków, umieszczając je ręcznie w Project Base Path na serwerze Tower lub umieszczając playbook w dowolnym systemie zarządzania kodem źródłowym (SCM) wspieranym przez Tower, w tym Git, Subversion, Mercurial i Red Hat Insights. W ramach jednego Projektu możesz umieścić tyle skryptów, ile chcesz. Na przykład stworzyłem jeden podstawowy Projekt, w którym umieściłem skrypt dla podstawowych elementów RedHat, skrypt dla podstawy Linux oraz skrypty dla pozostałych podstawowych wskaźników. W ten sposób w jednym projekcie znajdowały się różnorodne role i skrypty, którymi zarządzano z jednego repozytorium Git.
Uruchamiaj wszystkie te elementy przez wiersz poleceń, to dobry sposób na sprawdzenie ich działania. Dzięki temu przygotujesz się do instalacji Tower.
Porozmawiajmy trochę o transkodowaniu manifestu Puppet, ponieważ poświęciłem na to dużo czasu, zanim zdałem sobie sprawę, co tak naprawdę należy zrobić.
Jak już wspomniałem, Puppet przechowuje wszystkie ustawienia i parametry sprzętowe w jednym długim manifeście, a w tym manifeście znajduje się wszystko, co ta SCM powinna robić. Podczas migracji nie musisz wrzucać wszystkich swoich zadań na jedną listę, zamiast tego pomyśl o strukturze nowego systemu: rolach, scenariuszach, tagach, grupach i tym, co powinno się w nie wpisać. Niektóre z autonomicznych elementów sieci powinny być połączone w grupy, dla których można stworzyć scenariusze. Bardziej złożone elementy infrastruktury, które angażują dużą ilość zasobów, w tym autonomiczne klasy, można połączyć w rolach. Przed migracją musisz to ustalić. Jeśli tworzysz obszerne role lub scenariusze, które nie mieszczą się na jednym ekranie, powinieneś użyć tagów, aby móc uchwycić poszczególne części infrastruktury.
18:00
Trochę reklamy 🙂
Dziękujemy, że jesteś z nami. Podobają Ci się nasze artykuły? Chcesz zobaczyć więcej interesujących materiałów? Wspieraj nas składając zamówienie lub polecając nas znajomym, , unikatowy odpowiednik serwerów entry-level, który został stworzony przez nas dla Ciebie: (dostępne opcje z RAID1 i RAID10, do 24 rdzeni i do 40GB DDR4).
Dell R730xd dwa razy tańszy w centrum danych Equinix Tier IV w Amsterdamie? Tylko u nas w Holandii! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — od 99 dolarów! Czytaj o tym
Źródło: habr.com
