Krajowa usługa informacji o środowisku satelitarnym (NESDIS) obniżyła koszty zarządzania konfiguracją Red Hat Enterprise Linux (RHEL) o 35% poprzez migrację z Puppet Enterprise do Ansible Tower. W tym filmie „Jak to zrobiliśmy” inżynier systemów Michael Rau wyjaśnia uzasadnienie tej migracji, dzieląc się przydatnymi wskazówkami i wnioskami wyciągniętymi z przejścia z jednego SCM do drugiego.
Z tego filmu dowiesz się:
- jak uzasadnić kierownictwu możliwość przejścia z Puppet Enterprise na Ansible Tower;
- jakie strategie zastosować, aby przejście było możliwie płynne;
- wskazówki dotyczące transkodowania manifestów PE do Ansible Playbook;
- Zalecenia dotyczące optymalnej instalacji Ansible Tower.
Witam wszystkich, nazywam się Michael Rau i jestem starszym inżynierem systemów w ActioNet, która pracuje dla usługi NESDIS National Oceanic and Atmospheric Administration (NOAA). Dzisiaj porozmawiamy o przycinaniu ciągów - moim własnym doświadczeniu migracji z Puppet Enterprise do Ansible Tower. Tematem tej prezentacji jest „spojrzenie na moje blizny” pozostałe po tym, jak dokonałem tej zmiany na początku roku. Chcę podzielić się tym, czego nauczyłem się podczas tego procesu. Jeśli więc podejmiesz się czegoś takiego, korzystając z mojego doświadczenia, możesz dokonać przejścia bez dodatkowej pracy.
Podobne slajdy widzisz na początku każdej prezentacji na Ansible Fest. Ten slajd przedstawia historię automatyzacji mojej firmy. Nie jestem w tym nowy, ponieważ używam Puppet/Puppet Enterprise od 2007 roku. Zacząłem pracować z Ansible w 2016 roku i podobnie jak wielu innych użytkowników tego produktu, pociągała mnie możliwość „sztuczek” z wykorzystaniem wiersza poleceń i prostych skryptów (playbooków). Pod koniec 2017 roku zwróciłem się do mojego kierownictwa w sprawie ważnych powodów przejścia do Ansible Tower. Za chwilę opowiem Wam o powodach, które skłoniły mnie do podjęcia tego kroku. Po otrzymaniu zgody kierownictwa ukończenie planu zajęło jeszcze kilka miesięcy, a przejścia dokonałem w styczniu-lutym tego roku. Dlatego całkowicie porzuciliśmy Puppet na rzecz Ansible i jest to świetna rzecz.
To, co najbardziej przemawia do mnie w Ansible, to możliwość pisania i korzystania z ról i podręczników. Role doskonale nadają się do tworzenia odrębnych, ale powiązanych zadań i umieszczania wszystkich danych związanych z tymi zadaniami w jednym miejscu. Playbook to składnia YAML, plik skryptu opisujący działania dla jednego lub większej liczby hostów. Mówię o tych funkcjach użytkownikom, przede wszystkim twórcom oprogramowania. Ansible Tower daje Ci możliwość powiedzenia: „nie, nie masz dostępu do powłoki, ale daję Ci możliwość uruchomienia wszystkich procesów Tower i ponownego uruchomienia usługi, kiedy tego potrzebujesz”. Opowiem Ci o środowisku pracy i sprzęcie jakiego używamy.
Jest to federalna sieć LAN, 7 lokalizacji fizycznych połączonych za pośrednictwem chmury MPLS, 140 serwerów RHEL, z czego 99% wirtualnych (vSphere), sprzęt SuperMicro, pamięć sieciowa NexentaStore, zestaw przełączników Cisco, Arista i Cumulus oraz ujednolicone zarządzanie zagrożeniami Fortinet UTM narzędzia w każdej witrynie.
Sieć federalna oznacza, że muszę korzystać ze wszystkich przewidzianych przez prawo środków bezpieczeństwa informacji. Należy pamiętać, że Puppet Enterprise nie obsługuje większości sprzętu, którego używamy. Jesteśmy zmuszeni korzystać ze sprzętu budżetowego, ponieważ agencje rządowe mają problemy z finansowaniem tej pozycji wydatków. Dlatego kupujemy sprzęt SuperMicro i składamy nasz sprzęt z pojedynczych części, których konserwacja jest gwarantowana kontraktami rządowymi. Używamy Linuksa i jest to jeden z ważnych powodów przejścia na Ansible.
Nasza historia z Puppet jest następująca.
W 2007 roku mieliśmy małą sieć składającą się z 20-25 węzłów, w której wdrożyliśmy Puppet. Zasadniczo te węzły były po prostu „pudełkami” RedHata. W 2010 roku rozpoczęliśmy korzystanie z interfejsu internetowego Puppet Dashboard dla 45 węzłów. W miarę ciągłego rozwoju sieci w 2014 r. przeszliśmy na wersję PE 3.3, dokonując pełnego przejścia z ponownym zapisaniem manifestu dla 75 węzłów. Trzeba było to zrobić, bo Puppet lubi zmieniać zasady gry, a w tym przypadku całkowicie zmienił język. Rok później, kiedy zakończyło się wsparcie dla wersji 3 Puppet Enterprise, zmuszeni byliśmy przeprowadzić migrację do PE 2015.2. Musieliśmy ponownie przepisać manifest dla nowych serwerów i zakupić licencję z rezerwą 100 węzłów, choć w tamtym czasie mieliśmy tylko 85 węzłów.
Minęły zaledwie 2 lata i znowu musieliśmy włożyć dużo pracy, aby migrować do nowej wersji PE 2016.4. Kupiliśmy licencję na 300 węzłów, mając zaledwie 130. Znów musieliśmy wprowadzić duże zmiany w manifeście, ponieważ nowa wersja języka miała inną składnię niż język wersji 2015. W rezultacie nasz SCM przeszedł z kontroli wersji SVN na Bitbucket (Git). Tak wyglądała nasza „relacja” z Puppetem.
Musiałem więc wyjaśnić kierownictwu, dlaczego musieliśmy przejść do innego SCM, używając następujących argumentów. Pierwszą z nich jest wysoka cena usługi. Rozmawiałem z chłopakami z RedHat i powiedzieli, że koszt utrzymania 300-węzłowej sieci za pomocą Ansible Tower to połowa kosztów Puppet Enterprise. Jeśli kupisz również Ansible Engine, koszt będzie mniej więcej taki sam, ale otrzymasz o wiele więcej funkcji niż PE. Ponieważ jesteśmy spółką państwową finansowaną z budżetu federalnego, jest to dość mocny argument.
Drugim argumentem jest wszechstronność. Puppet obsługuje tylko sprzęt z agentem Puppet. Oznacza to, że na wszystkich przełącznikach musi być zainstalowany agent i musi to być najnowsza wersja. A jeśli niektóre z Twoich przełączników obsługują jedną wersję, a inne inną, będziesz musiał zainstalować na nich nową wersję agenta PE, aby wszystkie mogły pracować w tym samym systemie SCM.
System Ansible Tower działa inaczej, ponieważ nie ma żadnych agentów, ale ma moduły obsługujące przełączniki Cisco i wszystkie inne przełączniki. Ten SCM obsługuje Qubes OS, Linux i 4.NET UTM. Ansible Tower obsługuje także kontrolery sieciowej pamięci masowej NexentaStore oparte na jądrze Illumos, systemie operacyjnym typu open source opartym na systemie Unix. To bardzo małe wsparcie, ale Ansible Tower i tak to robi.
Trzecim argumentem, który jest bardzo ważny zarówno dla mnie, jak i dla naszej administracji, jest łatwość obsługi. Spędziłem 10 lat na doskonaleniu modułów Puppet i kodu manifestu, ale nauczyłem się Ansible w ciągu tygodnia, ponieważ praca z tym SCM jest znacznie łatwiejsza. Jeśli oczywiście uruchamiasz pliki wykonywalne, chyba że robisz to niepotrzebnie, wówczas działają z nimi inteligentne i responsywne programy obsługi. Podręczniki oparte na YAML są łatwe do nauczenia i szybkie w użyciu. 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 utrudnia pracę programisty, ponieważ opiera się na korzystaniu z Puppet Master. Jest to jedyna maszyna, która może komunikować się z agentami Puppet. Jeśli dokonałeś jakichkolwiek zmian w manifeście i chcesz przetestować swój kod, musisz przepisać kod dla Puppet Master, czyli skonfigurować plik Puppet Master /etc/hosts, aby połączyć wszystkich klientów i uruchomić usługę Puppet Server. Dopiero po tym będziesz mógł przetestować działanie sprzętu sieciowego na jednym hoście. Jest to dość bolesny zabieg.
W Ansible wszystko jest znacznie prostsze. Wszystko, co musisz zrobić, to opracować kod dla maszyny, która będzie mogła komunikować się poprzez SSH z testowanym hostem. Dużo łatwiej się z tym pracuje.
Kolejną dużą zaletą Ansible Tower jest możliwość wykorzystania istniejącego systemu wsparcia i utrzymania istniejącej konfiguracji sprzętowej. Ten SCM wykorzystuje wszystkie dostępne informacje o Twojej infrastrukturze i sprzęcie, maszynach wirtualnych, serwerach itp. bez żadnych dodatkowych kroków. Może komunikować się z serwerami RH Satellite, jeśli je posiadasz, i zapewnia integrację, jakiej nigdy nie uzyskasz w przypadku Puppet.
Kolejną ważną rzeczą jest szczegółowa kontrola. Wiesz, że Puppet to system modułowy, jest to aplikacja klient-serwer, dlatego musisz zdefiniować istniejące aspekty wszystkich swoich maszyn w jednym długim manifeście. W takim przypadku stan każdego pojedynczego elementu systemu należy sprawdzać co pół godziny – jest to okres domyślny. Tak działa Marionetka.
Wieża Cię przed tym uchroni. Można bez ograniczeń uruchamiać różnorodne procesy na różnym sprzęcie, wykonywać podstawowe prace, uruchamiać inne ważne procesy, konfigurować system zabezpieczeń i pracować z bazami danych. W Puppet Enterprise możesz zrobić wszystko, co jest trudne. Jeśli więc skonfigurujesz go na jednym hoście, minie trochę czasu, zanim zmiany zaczną obowiązywać na pozostałych hostach. W Ansible wszystkie zmiany obowiązują jednocześnie.
Na koniec spójrzmy na moduł bezpieczeństwa. Ansible Tower realizuje to po prostu niesamowicie, z niezwykłą precyzją i starannością. Możesz przyznać użytkownikom dostęp do określonych usług lub do określonych hostów. Robię to z moimi pracownikami, którzy są przyzwyczajeni do pracy w systemie Windows, ograniczając im dostęp do powłoki Linux. Zapewniam im dostęp do Tower, aby mogli wykonywać tylko pracę i uruchamiać tylko te usługi, które są dla nich istotne.
Przyjrzyjmy się, co musisz zrobić z wyprzedzeniem, aby ułatwić przejście na Ansible Tower. Przede wszystkim należy przygotować sprzęt. Jeśli jakichś elementów Twojej infrastruktury nie ma jeszcze w bazie, musisz je tam dodać. Istnieją systemy, które nie zmieniają swojej charakterystyki i dlatego nie ma ich w bazie Puppet, ale jeśli nie dodasz ich tam przed przeprowadzką do Tower, stracisz szereg korzyści. Może to być „brudna”, wstępna baza danych, ale powinna zawierać informacje o całym sprzęcie, jaki posiadasz. Dlatego powinieneś napisać dynamiczny skrypt sprzętowy, który automatycznie wypchnie wszystkie zmiany w infrastrukturze do bazy danych, dzięki czemu Ansible będzie wiedział, które hosty powinny być obecne w nowym systemie. Nie będziesz musiał informować SCM, które hosty dodałeś, a które już nie istnieją, ponieważ będzie to wiedział 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.
Poświęć trochę czasu na zapoznanie się z wierszem poleceń w Ansible. Uruchom kilka niestandardowych poleceń, aby przetestować skrypt sprzętowy, napisz i uruchom kilka prostych, ale przydatnych skryptów podręcznika, użyj szablonów Jinja2, jeśli to konieczne. Spróbuj napisać rolę i skrypt dla złożonego, wieloetapowego procesu, korzystając z typowej, często spotykanej konfiguracji sprzętowej. Pobaw się tymi rzeczami, przetestuj, jak to działa. W ten sposób nauczysz się korzystać z narzędzi do tworzenia bibliotek używanych w Tower. Mówiłem już, że przygotowania do przejścia zajęły mi około 3 miesięcy. Myślę, że bazując na moim doświadczeniu, uda Ci się to zrobić szybciej. Nie uważaj tego czasu za stracony, bo później odczujesz wszystkie korzyści płynące z wykonanej pracy.
Następnie musisz zdecydować, czego oczekujesz od Ansible Tower, co dokładnie ten system powinien dla Ciebie zrobić.
Czy potrzebujesz wdrożyć system na gołym sprzęcie, na gołych maszynach wirtualnych? A może chcesz zachować oryginalne warunki pracy i ustawienia istniejącego sprzętu? Jest to bardzo ważny aspekt dla spółek publicznych, dlatego musisz mieć pewność, że będziesz w stanie przeprowadzić migrację i wdrożenie Ansible na istniejącej konfiguracji. Zidentyfikuj rutynowe procesy administracyjne, które chcesz zautomatyzować. Dowiedz się, czy musisz wdrożyć określone aplikacje i usługi w nowym systemie. Zrób listę tego, co chcesz zrobić i ustal priorytety.
Następnie zacznij pisać kod skryptu i role, które umożliwią wykonanie zadań, które planujesz wykonać. Połącz je w projekty, logiczny zbiór odpowiednich podręczników. Każdy projekt będzie należeć do osobnego repozytorium Git lub innego repozytorium, w zależności od tego, jakiego menedżera kodu używasz. Możesz zarządzać skryptami podręczników i katalogami podręczników, ręcznie umieszczając je w ścieżce podstawowej projektu na serwerze Tower lub umieszczając podręcznik w dowolnym systemie zarządzania kodem źródłowym (SCM) obsługiwanym przez wieżę, w tym Git, Subversion, Mercurial i Red Hat Spostrzeżenia. W ramach jednego Projektu możesz umieścić dowolną liczbę skryptów. Na przykład stworzyłem jeden podstawowy projekt, w którym umieściłem skrypt dla podstawowych elementów RedHat, skrypt dla rdzenia Linuksa i skrypty dla pozostałych linii bazowych. Zatem w jednym projekcie istniało wiele ról i scenariuszy, którymi zarządzano z jednego repozytorium Git.
Uruchomienie wszystkich tych rzeczy za pomocą wiersza poleceń to dobry sposób na przetestowanie ich funkcjonalności. To przygotuje Cię do instalacji Tower.
Porozmawiajmy trochę o transkodowaniu manifestu Puppet, ponieważ spędziłem nad tym dużo czasu, dopóki nie zorientowałem się, co właściwie należy zrobić.
Jak powiedziałem wcześniej, Puppet przechowuje wszystkie ustawienia i opcje sprzętowe w jednym długim manifeście, a ten manifest przechowuje wszystko, co powinien zrobić ten SCM. Dokonując przejścia, nie musisz upychać wszystkich zadań na jednej liście, zamiast tego zastanów się nad strukturą nowego systemu: rolami, skryptami, tagami, grupami i tym, co powinno się tam znaleźć. Część autonomicznych elementów sieci należy pogrupować w grupy, dla których można tworzyć skrypty. Bardziej złożone elementy infrastruktury, które obejmują dużą liczbę zasobów, w tym samodzielne klasy, można łączyć w role. Przed migracją musisz o tym zdecydować. Jeśli tworzysz duże role lub scenariusze, które nie mieszczą się na jednym ekranie, powinieneś użyć tagów, aby móc uchwycić określone części infrastruktury.
18:00
Kilka reklam 🙂
Dziękujemy za pobyt z nami. Podobają Ci się nasze artykuły? Chcesz zobaczyć więcej ciekawych treści? Wesprzyj nas składając zamówienie lub polecając znajomym, , unikalny odpowiednik serwerów klasy podstawowej, który został przez nas wymyślony dla Ciebie: (dostępne z RAID1 i RAID10, do 24 rdzeni i do 40 GB DDR4).
Dell R730xd 2 razy taniej w centrum danych Equinix Tier IV w Amsterdamie? Tylko tutaj w Holandii! Dell R420 — 2x E5-2430 2.2 GHz 6C 128 GB DDR3 2x960 GB SSD 1 Gb/s 100 TB — od 99 USD! Czytać o
Źródło: www.habr.com