Zbliżał się Nowy Rok. Dzieci w całym kraju już wysłały listy do Mikołaja lub wymyśliły sobie prezenty, a główny wykonawca ich życzeń — jeden z dużych detalistów — przygotowywał się do szczytu sprzedaży. W grudniu obciążenie jego centrum danych wzrasta wielokrotnie. Dlatego firma postanowiła zmodernizować data center i wprowadzić do użytku kilka dziesięcioletnich nowych serwerów zamiast sprzętu, którego okres eksploatacji dobiegał końca. Na tym kończy się wprowadzenie w tle wirujących płatków śniegu, a zaczyna się thriller.
Sprzęt dotarł na miejsce kilka miesięcy przed szczytem sprzedaży. Służba eksploatacyjna wie, jak i co skonfigurować na serwerach, aby wprowadzić je do środowiska produkcyjnego. Musieliśmy jednak zautomatyzować ten proces i wyeliminować czynnik ludzki. Ponadto serwery zastępowały przed migracją zestaw systemów SAP, które były krytyczne dla firmy.
Wprowadzenie nowych serwerów było ściśle związane z ostatecznym terminem. Przesunięcie go oznaczałoby zagrożenie dla wysyłki miliarda prezentów oraz migracji systemów. Zmiana daty nie byłaby możliwa, nawet dla zespołu w składzie Mikołaja, Św. Mikołaja — przeniesienie systemu SAP do zarządzania magazynem można wykonać tylko raz w roku. Od 31 grudnia do 1 stycznia ogromne magazyny detalisty, zajmujące powierzchnię równą 20 boiskom piłkarskim, wstrzymują swoją działalność na 15 godzin. I to jest jedyny czas na przeniesienie systemu. Nie mieliśmy marginesu błędu przy wprowadzaniu serwerów.
Wyjaśnię od razu: moja opowieść odzwierciedla narzędzia i proces zarządzania konfiguracjami, które stosuje nasz zespół.
Kompleks zarządzania konfiguracjami składa się z kilku poziomów. Kluczowym komponentem jest system CMS. W przypadku eksploatacji przemysłowej brak jednego z poziomów nieuchronnie prowadziłby do nieprzyjemnych niespodzianek.
Zarządzanie instalacją systemu operacyjnego
Pierwszy poziom to system zarządzania instalacją systemów operacyjnych na fizycznych i wirtualnych serwerach. Tworzy podstawowe konfiguracje systemu operacyjnego, eliminując czynnik ludzki.
Dzięki temu systemowi otrzymywaliśmy typowe i gotowe do dalszej automatyzacji modele serwerów z systemem operacyjnym. Podczas "rozlewu" otrzymywały one minimalny zestaw lokalnych użytkowników oraz publicznych kluczy SSH, a także zgodną konfigurację systemu operacyjnego. Mogliśmy zagwarantować zarządzanie serwerami za pośrednictwem CMS i byliśmy pewni, że "na dole", na poziomie systemu operacyjnego, nie ma niespodzianek.
Zadanie "maksimum" dla systemu zarządzania instalacją polega na automatycznym konfigurowaniu serwerów od poziomu BIOS/Firmware do systemu operacyjnego. Wiele zależy tutaj od sprzętu i zadań konfiguracyjnych. Dla heterogenicznego sprzętu można rozważyć . Jeśli cały "hardware" pochodzi od jednego dostawcy, często wygodniej jest używać gotowych narzędzi do zarządzania (na przykład HP ILO Amplifier, DELL OpenManage itd.).
Do instalacji systemu operacyjnego na fizycznych serwerach używaliśmy znanego wszystkim Cobblera, w którym określono zestaw profili instalacji zgodnych z usługą operacyjną. Podczas dodawania nowego serwera do infrastruktury inżynier przypisywał adres MAC serwera do wymaganego profilu w Cobblerze. Przy pierwszym rozruchu przez sieć serwer otrzymywał tymczasowy adres oraz nowy system operacyjny. Następnie przenoszono go do docelowej VLAN/adresacji IP i kontynuowano pracę już tam. Tak, zmiana VLAN zajmuje czas i wymaga uzgodnienia, ale zapewnia dodatkową ochronę przed przypadkową instalacją serwera w środowisku produkcyjnym.
Wirtualne serwery tworzyliśmy na podstawie szablonów przygotowanych za pomocą HashiCorp Packer. Powód był ten sam: aby zapobiec możliwym błędom ludzkim podczas instalacji systemu operacyjnego. Jednak w przeciwieństwie do fizycznych serwerów, Packer pozwala na niestosowanie PXE, bootowania przez sieć i zmiany VLAN. Ułatwiło to i uprościło tworzenie wirtualnych serwerów.
Rys. 1. Zarządzanie instalacją systemów operacyjnych.
Zarządzanie sekretami
Każdy system zarządzania konfiguracjami zawiera dane, które powinny być ukryte przed zwykłymi użytkownikami, ale są potrzebne do przygotowania systemów. Są to hasła lokalnych użytkowników i kont serwisowych, klucze certyfikatów, różnego rodzaju tokeny API itd. Zwykle nazywa się je "sekretami".
Jeśli od samego początku nie określimy, gdzie i jak przechowywać te sekrety, to w zależności od surowości wymagań w zakresie bezpieczeństwa informacji, prawdopodobne są takie metody przechowywania:
- bezpośrednio w kodzie zarządzania konfiguracją lub w plikach w repozytorium;
- w wyspecjalizowanych narzędziach do zarządzania konfiguracją (np. Ansible Vault);
- w systemach CI/CD (Jenkins/TeamCity/GitLab itd.) lub w systemach zarządzania konfiguracją (Ansible Tower/Ansible AWX);
- ponadto sekrety można przekazywać w trybie „ręcznym”. Na przykład umieszczają je w umówionym miejscu, a następnie wykorzystują je systemy zarządzania konfiguracją;
- różne kombinacje powyższych.
Każda metoda ma swoje wady. Główna z nich to brak polityki dostępu do sekretów: nie można lub trudno określić, kto może korzystać z danych sekretów. Kolejnym minusem jest brak audytu dostępu i pełnego cyklu życiowego. Jak szybko wymienić na przykład klucz publiczny, który jest zapisany w kodzie i w kilku powiązanych systemach?
Używaliśmy scentralizowanego magazynu sekretów HashiCorp Vault. Umożliwiło nam to:
- bezpieczne przechowywanie sekretów. Są one zaszyfrowane, a nawet jeśli ktoś uzyska dostęp do bazy danych magazynu Vault (na przykład przywracając ją z kopii zapasowej), nie będzie mógł odczytać przechowywanych tam sekretnych informacji;
- organizację polityk dostępu do sekretów. Użytkownicy i aplikacje mają dostęp tylko do „przydzielonych” im sekretów;
- przeprowadzanie audytu dostępu do sekretów. Wszystkie działania na sekretach są rejestrowane w dzienniku audytu Vault;
- organizację pełnego „cyklu życia” pracy z sekretami. Można je tworzyć, cofać, ustalać daty ważności itd.
- łatwą integrację z innymi systemami, którym potrzebny jest dostęp do sekretów;
- a także stosowanie szyfrowania end-to-end, jednorazowych haseł do OS i DB, certyfikatów autoryzowanych centrów itd.
Teraz przejdźmy do centralnego systemu uwierzytelniania i autoryzacji. Można było się bez niego obejść, ale administrowanie użytkownikami w wielu powiązanych systemach jest zbyt skomplikowane. Skonfigurowaliśmy uwierzytelnianie i autoryzację przez usługę LDAP. W przeciwnym razie w tym samym Vault musielibyśmy stale wydawać i śledzić tokeny uwierzytelniające dla użytkowników. A usuwanie i dodawanie użytkowników przerodziłoby się w quest „czy wszędzie stworzyłem/usunąłem ten identyfikator?”
Dodajemy jeszcze jeden poziom do naszej systemu: zarządzanie sekretami oraz centralne uwierzytelnianie/autoryzacja:
Rys. 2. Zarządzanie sekretami.
Zarządzanie konfiguracjami
Dotarliśmy do sedna — do systemu CMS. W naszym przypadku to połączenie Ansible i Red Hat Ansible AWX.
Zamiast Ansible mogą występować Chef, Puppet, SaltStack. Wybraliśmy Ansible z kilku powodów.
- Po pierwsze, to uniwersalność. Zestaw gotowych modułów do zarządzania . A jeśli go brakuje, można poszukać na GitHub i Galaxy.
- Po drugie, nie trzeba instalować i utrzymywać agentów na zarządzanym sprzęcie, udowadniać, że nie zakłócają obciążenia i potwierdzać brak 'backdoorów'.
- Po trzecie, Ansible ma niski próg wejścia. Zrozumiały inżynier napisze działający playbook dosłownie w pierwszy dzień pracy z produktem.
Ale sam Ansible w środowisku przemysłowym nie wystarczył. W przeciwnym razie pojawiłoby się wiele problemów z ograniczeniem dostępu i audytem działań administratorów. Jak zdefiniować dostęp? Przecież trzeba było, aby każde działanie zarządzało (czytaj — uruchamiało Ansible playbook) swoim 'własnym' zestawem serwerów. Jak pozwolić na uruchamianie konkretnych Ansible playbook tylko określonym pracownikom? Jak śledzić, kto uruchamiał playbook, nie tworząc wielu lokalnych kont użytkowników na serwerach i sprzęcie zarządzanym przez Ansible?
Znaczną część takich pytań rozwiązuje Red Hat , lub jego open-source'owy projekt upstreamowy . Dlatego wybraliśmy go dla klienta.
I jeszcze jeden element do portretu naszego systemu CMS. Ansible playbook musi być przechowywany w systemach zarządzania repozytoriami kodu. U nas to .
Więc same konfiguracje zarządzane są przez połączenie Ansible/Ansible AWX/GitLab (zob. Rys. 3). Oczywiście, AWX/GitLab są zintegrowane z jednolitym systemem uwierzytelniania, a Ansible playbook z HashiCorp Vault. Konfiguracje trafiają do środowiska produkcyjnego tylko przez Ansible AWX, w którym określone są wszystkie 'zasady gry': kto i co może konfigurować, skąd brać kod zarządzania konfiguracjami dla CMS itp.
Rys. 3. Zarządzanie konfiguracjami.
Zarządzanie testowaniem
Nasza konfiguracja przedstawiona jest w formie kodu. Dlatego musimy grać według tych samych zasad, co deweloperzy oprogramowania. Musieliśmy zorganizować procesy rozwoju, ciągłego testowania, dostarczania i wdrażania kodu konfiguracyjnego na serwery produkcyjne.
Jeśli nie zrobisz tego od razu, to napisane role do konfiguracji mogą przestać być wspierane i modyfikowane lub przestaną działać w środowisku produkcyjnym. Lekarstwo na ten problem jest znane i sprawdziło się w tym projekcie:
- każda rola jest pokryta testami modułowymi;
- testy są automatycznie uruchamiane przy każdej zmianie w kodzie zarządzającym konfiguracjami;
- zmiany w kodzie zarządzającym konfiguracjami trafiają do środowiska produkcyjnego tylko po pomyślnym przejściu wszystkich testów i przeglądzie kodu.
Rozwój kodu oraz zarządzanie konfiguracjami stały się spokojniejsze i bardziej przewidywalne. Do organizacji ciągłego testowania użyliśmy narzędzi GitLab CI/CD, a jako framework do organizacji testów wybraliśmy .
Przy każdej zmianie w kodzie zarządzającym konfiguracjami GitLab CI/CD wywołuje Molecule:
- sprawdza składnię kodu,
- uruchamia kontener Docker,
- aplikuje zmodyfikowany kod w stworzonym kontenerze,
- sprawdza rolę pod kątem idempotentności i uruchamia testy dla tego kodu (granularność jest na poziomie roli ansible, zob. Rys. 4).
Konfiguracje w środowisku produkcyjnym dostarczaliśmy z użyciem Ansible AWX. Odpowiedzialni za eksploatację inżynierowie wprowadzali zmiany w konfiguracji przez wcześniej zdefiniowane szablony. AWX samodzielnie przy każdym zastosowaniu "pobierał" najnowszą wersję kodu z gałęzi master GitLab. W ten sposób wykluczaliśmy używanie niezweryfikowanego lub przestarzałego kodu w środowisku produkcyjnym. Oczywiście, kod do gałęzi master trafiał tylko po przetestowaniu, przeglądzie i zatwierdzeniu.
Rys. 4. Automatyczne testowanie ról w GitLab CI/CD.
Jest jeszcze problem związany z eksploatacją systemów produkcyjnych. W rzeczywistości bardzo trudno jest wprowadzać zmiany w konfiguracji wyłącznie przez kod CMS. Pojawiają się sytuacje awaryjne, kiedy inżynier musi zmienić konfigurację "tu i teraz", nie czekając na poprawki kodu, testy, zatwierdzenia itp.
W rezultacie z powodu ręcznych zmian pojawiają się rozbieżności w konfiguracji na jednorodnym sprzęcie (na przykład na węzłach klastra HA różne konfiguracje ustawień sysctl). Albo rzeczywista konfiguracja na sprzęcie różni się od tej, która jest określona w kodzie CMS.
Dlatego, oprócz ciągłego testowania, sprawdzamy środowiska produkcyjne pod kątem różnic w konfiguracji. Wybraliśmy najprostsze rozwiązanie: uruchomienie kodu konfiguracji CMS w trybie „dry run”, czyli bez stosowania zmian, ale z powiadomieniem o wszelkich różnicach między planowaną a rzeczywistą konfiguracją. Zrealizowaliśmy to za pomocą okresowych uruchomień wszystkich playbooków Ansible z opcją „—check” na serwerach produkcyjnych. Za uruchomienie i aktualność playbooków jak zawsze odpowiada Ansible AWX (zob. Rys. 5):
Rys. 5. Kontrola różnic w konfiguracjach w Ansible AWX.
Po testach AWX wysyła raport o różnicach do administratorów. Badamy problematyczną konfigurację, a następnie poprawiamy ją przy użyciu skorygowanych playbooków. W ten sposób utrzymujemy konfigurację w środowisku produkcyjnym, a CMS zawsze jest w aktualnym i zsynchronizowanym stanie. To eliminuje nieprzyjemne „cuda”, gdy kod CMS jest stosowany na serwerach „żywych”.
Teraz mamy ważny poziom testowania, składający się z Ansible AWX/GitLab/Molecule (Rys. 6).
Rys. 6. Zarządzanie testowaniem.
Trudne? Nie zaprzeczam. Ale taki kompleks zarządzania konfiguracjami stał się wyczerpującą odpowiedzią na wiele pytań związanych z automatyzacją konfiguracji serwerów. Teraz detalista ma zawsze ściśle określoną konfigurację typowych serwerów. CMS, w przeciwieństwie do inżyniera, nie zapomni dodać niezbędnych ustawień, utworzyć użytkowników i wykonać dziesiątki lub setki wymaganych ustawień.
W ustawieniach serwerów i środowisk dzisiaj brakuje „tajemnej wiedzy”. Wszystkie niezbędne cechy są odzwierciedlone w playbookach. Koniec z jakąkolwiek twórczością i niejasnymi instrukcjami: „stawiaj jak zwykły Oracle, ale tam trzeba kilka ustawień sysctl wpisać i dodać użytkowników z odpowiednim UID. Zapytaj chłopaków z eksploatacji, oni wiedzą.».
Możliwość wykrywania różnic w konfiguracjach i ich wcześniejszego korygowania daje spokój. Bez systemu zarządzania konfiguracjami zazwyczaj wygląda to inaczej. Problemy gromadzą się, aż pewnego dnia „wystrzelą” w produkcji. Następnie przeprowadza się analizę błędów, sprawdza i koryguje konfiguracje. I cykl powtarza się znowu.
Oczywiście przyspieszyliśmy uruchomienie serwerów w eksploatacji z kilku dni do kilku godzin.
A w samą nową noc, kiedy dzieci radośnie rozpakowywały prezenty, a dorośli składali życzenia pod dźwięk wybijających godzin, nasi inżynierowie migrowali system SAP na nowe serwery. Nawet Święty Mikołaj powie, że najlepsze cuda to te dobrze przygotowane.
P.S. Nasz zespół często spotyka się z tym, że klienci chcą jak najszybciej rozwiązać problem zarządzania konfiguracjami. Najlepiej, aby było to jak za sprawą magii — jednym narzędziem. Ale w życiu wszystko jest trudniejsze (tak, znów nie dostarczyli srebrnych pocisków): musimy tworzyć cały proces przy pomocy wygodnych narzędzi dla zespołu klienta.
Autor: Sergey Artemov, architekt działu „Infosystemy Jet”
Źródło: habr.com
