Zbliżał się Nowy Rok. Dzieci w całym kraju wysłały już listy do Świętego Mikołaja lub zrobiły sobie prezenty, a ich główny wykonawca, jeden z największych detalistów, przygotowywał się do apoteozy wyprzedaży. W grudniu obciążenie centrum danych wzrasta kilkukrotnie. Dlatego też firma podjęła decyzję o modernizacji centrum danych i uruchomieniu kilkudziesięciu nowych serwerów zamiast sprzętu, który dobiegał końca. Na tym kończy się opowieść na tle wirujących płatków śniegu i rozpoczyna się thriller.
Sprzęt dotarł na miejsce na kilka miesięcy przed szczytem sprzedaży. Obsługa operacyjna oczywiście wie jak i co skonfigurować na serwerach, aby wprowadzić je do środowiska produkcyjnego. Musieliśmy to jednak zautomatyzować i wyeliminować czynnik ludzki. Dodatkowo wymieniono serwery przed migracją zestawu systemów SAP, które były dla firmy krytyczne.
Uruchomienie nowych serwerów było ściśle powiązane z terminem. Przeniesienie go oznaczało zagrożenie zarówno dla wysyłki miliarda prezentów, jak i dla migracji systemów. Nawet ekipa złożona z Ojca Mrozu i Świętego Mikołaja nie była w stanie zmienić terminu – przeniesienie systemu SAP do obsługi magazynu można przenieść tylko raz w roku. Od 31 grudnia do 1 stycznia ogromne magazyny detalisty, łącznie o powierzchni 20 boisk piłkarskich, wstrzymują pracę na 15 godzin. I to jest jedyny okres czasu na przeniesienie systemu. Przy wprowadzaniu serwerów nie mieliśmy miejsca na błędy.
Wyjaśnię to jasno: moja historia odzwierciedla narzędzia i proces zarządzania konfiguracją, z których korzysta nasz zespół.
Kompleks zarządzania konfiguracją składa się z kilku poziomów. Kluczowym elementem jest system CMS. W warunkach przemysłowych brak jednego z poziomów nieuchronnie doprowadziłby do nieprzyjemnych cudów.
Zarządzanie instalacją systemu operacyjnego
Pierwszy poziom to system zarządzający instalacją systemów operacyjnych na serwerach fizycznych i wirtualnych. Tworzy podstawowe konfiguracje systemu operacyjnego, eliminując czynnik ludzki.
Korzystając z tego systemu otrzymaliśmy standardowe instancje serwerowe z systemem operacyjnym nadającym się do dalszej automatyzacji. Podczas „wylewania” otrzymali minimalny zestaw użytkowników lokalnych i publicznych kluczy SSH, a także spójną konfigurację systemu operacyjnego. Mieliśmy gwarancję zarządzania serwerami poprzez CMS i byliśmy pewni, że „na dole” nie będzie żadnych niespodzianek na poziomie systemu operacyjnego.
„Maksymalnym” zadaniem systemu zarządzania instalacją jest automatyczna konfiguracja serwerów od poziomu BIOS/Firmware do systemu operacyjnego. Wiele tutaj zależy od sprzętu i zadań konfiguracyjnych. W przypadku sprzętu heterogenicznego można rozważyć . Jeśli cały sprzęt pochodzi od jednego dostawcy, często wygodniej jest skorzystać z gotowych narzędzi do zarządzania (na przykład HP ILO Amplifier, DELL OpenManage itp.).
Do instalacji systemu operacyjnego na serwerach fizycznych wykorzystaliśmy dobrze znany Cobbler, który definiuje zestaw profili instalacyjnych uzgodnionych z obsługą operacyjną. Dodając nowy serwer do infrastruktury, inżynier powiązał adres MAC serwera z wymaganym profilem w Cobblerze. Podczas pierwszego uruchomienia przez sieć serwer otrzymał adres tymczasowy i nowy system operacyjny. Następnie przeniesiono go na docelową adresację VLAN/IP i tam kontynuowano pracę. Tak, zmiana VLANu wymaga czasu i koordynacji, ale zapewnia dodatkowe zabezpieczenie przed przypadkową instalacją serwera w środowisku produkcyjnym.
Stworzyliśmy wirtualne serwery w oparciu o szablony przygotowane przy użyciu HashiСorp Packera. Powód był ten sam: aby zapobiec możliwym błędom ludzkim podczas instalacji systemu operacyjnego. Jednak w przeciwieństwie do serwerów fizycznych Packer eliminuje potrzebę środowiska PXE, uruchamiania sieciowego i zmian w sieci VLAN. Ułatwiło to i uprościło tworzenie serwerów wirtualnych.
Ryż. 1. Zarządzanie instalacją systemów operacyjnych.
Zarządzanie tajemnicami
Każdy system zarządzania konfiguracją zawiera dane, które powinny być ukryte przed zwykłymi użytkownikami, a są potrzebne do przygotowania systemów. Są to hasła do lokalnych użytkowników i kont usług, klucze certyfikatów, różne tokeny API itp. Zwykle nazywane są „tajemnicami”.
Jeśli od samego początku nie określisz, gdzie i jak przechowywać te tajemnice, wówczas, w zależności od surowości wymogów bezpieczeństwa informacji, prawdopodobne są następujące metody przechowywania:
- bezpośrednio w kodzie sterującym konfiguracją lub w plikach w repozytorium;
- w wyspecjalizowanych narzędziach do zarządzania konfiguracją (np. Ansible Vault);
- w systemach CI/CD (Jenkins/TeamCity/GitLab/etc.) lub w systemach zarządzania konfiguracją (Ansible Tower/Ansible AWX);
- sekrety można również przenosić „ręcznie”. Na przykład są one rozmieszczane w określonej lokalizacji, a następnie wykorzystywane przez systemy zarządzania konfiguracją;
- różne kombinacje powyższych.
Każda metoda ma swoje wady. Najważniejszym z nich jest brak polityki dostępu do tajemnic: niemożliwe lub trudne jest określenie, kto może korzystać z określonych tajemnic. Kolejną wadą jest brak audytu dostępu i pełnego cyklu życia. Jak szybko zastąpić np. klucz publiczny zapisany w kodzie i w szeregu powiązanych systemów?
Korzystaliśmy ze scentralizowanego tajnego magazynu HashiCorp Vault. Pozwoliło nam to:
- chroń tajemnice. Są one szyfrowane i nawet jeśli ktoś uzyska dostęp do bazy Vault (np. przywracając ją z kopii zapasowej), nie będzie mógł odczytać przechowywanych tam sekretów;
- organizować zasady dostępu do sekretów. Tylko „przydzielone” im sekrety są dostępne dla użytkowników i aplikacji;
- kontrolowanie dostępu do tajemnic. Wszelkie działania związane z sekretami są rejestrowane w dzienniku kontrolnym Vault;
- zorganizuj pełnoprawny „cykl życia” pracy z tajemnicami. Można je utworzyć, odwołać, ustawić termin wygaśnięcia itp.
- łatwa integracja z innymi systemami wymagającymi dostępu do sekretów;
- a także stosuj szyfrowanie end-to-end, hasła jednorazowe do systemu operacyjnego i bazy danych, certyfikaty autoryzowanych ośrodków itp.
Przejdźmy teraz do centralnego systemu uwierzytelniania i autoryzacji. Dało się obejść bez tego, jednak administrowanie użytkownikami w wielu pokrewnych systemach jest zbyt nietrywialne. Skonfigurowaliśmy uwierzytelnianie i autoryzację poprzez usługę LDAP. W przeciwnym razie Vault musiałby stale wydawać i śledzić tokeny uwierzytelniające dla użytkowników. A usuwanie i dodawanie użytkowników zamieniłoby się w zadanie „czy wszędzie utworzyłem/usunąłem to konto użytkownika?”
Do naszego systemu dodajemy kolejny poziom: zarządzanie sekretami i centralne uwierzytelnianie/autoryzacja:
Ryż. 2. Zarządzanie tajemnicami.
Zarządzanie konfiguracją
Dotarliśmy do sedna – systemu CMS. W naszym przypadku jest to połączenie Ansible i Red Hat Ansible AWX.
Zamiast Ansible można użyć Chef, Puppet, SaltStack. Wybraliśmy Ansible na podstawie kilku kryteriów.
- Po pierwsze, jest to wszechstronność. Zestaw gotowych modułów do sterowania . A jeśli nie masz go dość, możesz poszukać na GitHubie i Galaxy.
- Po drugie, nie ma potrzeby instalowania i wspierania agentów na zarządzanym sprzęcie, udowadniania, że nie zakłócają obciążenia i potwierdzania braku „zakładek”.
- Po trzecie, Ansible ma niską barierę wejścia. Kompetentny inżynier napisze działający poradnik dosłownie pierwszego dnia pracy z produktem.
Jednak sam Ansible w środowisku produkcyjnym nie był dla nas wystarczający. W przeciwnym razie powstałoby wiele problemów z ograniczaniem dostępu i kontrolowaniem działań administratorów. Jak ograniczyć dostęp? W końcu każdy dział musiał zarządzać (czytaj: uruchamiać podręcznik Ansible) „własnym” zestawem serwerów. Jak zezwolić tylko niektórym pracownikom na uruchamianie określonych podręczników Ansible? Albo jak śledzić, kto uruchomił podręcznik, bez konieczności konfigurowania dużej ilości lokalnej wiedzy na temat serwerów i sprzętu, na którym działa Ansible?
Lwią część takich problemów rozwiązuje Red Hat lub jego projekt typu open source . Dlatego woleliśmy to dla klienta.
I jeszcze jeden akcent do portretu naszego systemu CMS. Podręcznik Ansible powinien być przechowywany w systemach zarządzania repozytorium kodu. mamy to .
Zatem same konfiguracje są zarządzane przez kombinację Ansible/Ansible AWX/GitLab (patrz rys. 3). Oczywiście AWX/GitLab jest zintegrowany z jednym systemem uwierzytelniania, a podręcznik Ansible jest zintegrowany z HashiCorp Vault. Konfiguracje trafiają do środowiska produkcyjnego jedynie poprzez Ansible AWX, w którym określone są wszystkie „reguły gry”: kto może co konfigurować, skąd zdobyć kod zarządzający konfiguracją dla CMS-a itp.
Ryż. 3. Zarządzanie konfiguracją.
Zarządzanie testami
Nasza konfiguracja jest przedstawiona w formie kodu. Dlatego jesteśmy zmuszeni grać według tych samych zasad, co twórcy oprogramowania. Musieliśmy zorganizować procesy rozwoju, ciągłego testowania, dostarczania i aplikacji kodu konfiguracyjnego na serwery produkcyjne.
Jeśli nie zostanie to zrobione natychmiast, role zapisane dla konfiguracji albo przestaną być obsługiwane i modyfikowane, albo przestaną być uruchamiane w środowisku produkcyjnym. Lek na ten ból jest znany i sprawdził się w tym projekcie:
- każda rola objęta jest testami jednostkowymi;
- testy są uruchamiane automatycznie za każdym razem, gdy nastąpi jakakolwiek zmiana w kodzie zarządzającym konfiguracjami;
- zmiany w kodzie zarządzającym konfiguracją są wypuszczane do środowiska produkcyjnego dopiero po pomyślnym przejściu wszystkich testów i przeglądu kodu.
Tworzenie kodu i zarządzanie konfiguracją stały się spokojniejsze i bardziej przewidywalne. Aby zorganizować ciągłe testy, skorzystaliśmy z zestawu narzędzi GitLab CI/CD i wzięliśmy .
Ilekroć nastąpi zmiana w kodzie zarządzającym konfiguracją, GitLab CI/CD wywołuje Molecule:
- sprawdza składnię kodu,
- podnosi kontener Docker,
- stosuje zmodyfikowany kod do utworzonego kontenera,
- sprawdza rolę pod kątem idempotencji i uruchamia testy dla tego kodu (szczegółowość jest tutaj na poziomie roli ansible, patrz rys. 4).
Dostarczyliśmy konfiguracje na środowisko produkcyjne przy użyciu Ansible AWX. Inżynierowie operacyjni zastosowali zmiany konfiguracji za pomocą predefiniowanych szablonów. AWX niezależnie „żądało” najnowszej wersji kodu z głównej gałęzi GitLab za każdym razem, gdy był używany. W ten sposób wykluczyliśmy użycie nieprzetestowanego lub nieaktualnego kodu w środowisku produkcyjnym. Naturalnie kod wszedł do gałęzi master dopiero po przetestowaniu, przejrzeniu i zatwierdzeniu.
Ryż. 4. Automatyczne testowanie ról w GitLab CI/CD.
Istnieje również problem związany z pracą systemów produkcyjnych. W prawdziwym życiu bardzo trudno jest dokonać zmian w konfiguracji za pomocą samego kodu CMS. Sytuacje awaryjne powstają, gdy inżynier musi zmienić konfigurację „tu i teraz”, nie czekając na edycję kodu, testowanie, zatwierdzenie itp.
W rezultacie, w wyniku ręcznych zmian, pojawiają się rozbieżności w konfiguracji na sprzęcie tego samego typu (na przykład ustawienia sysctl są inaczej konfigurowane na węzłach klastra HA). Lub rzeczywista konfiguracja sprzętu różni się od określonej w kodzie CMS.
Dlatego oprócz ciągłych testów sprawdzamy środowiska produkcyjne pod kątem rozbieżności konfiguracyjnych. Wybraliśmy najprostszą opcję: uruchomienie kodu konfiguracyjnego CMS-a w trybie „dry run”, czyli bez nanoszenia zmian, ale z powiadomieniem o wszelkich rozbieżnościach pomiędzy planowaną a rzeczywistą konfiguracją. Wdrożyliśmy to, okresowo uruchamiając wszystkie podręczniki Ansible z opcją „-sprawdź” na serwerach produkcyjnych. Jak zawsze, Ansible AWX jest odpowiedzialny za uruchomienie i aktualizację podręcznika (patrz rys. 5):
Ryż. 5. Sprawdza rozbieżności konfiguracyjne w Ansible AWX.
Po sprawdzeniu AWX przesyła administratorom raport o rozbieżnościach. Badają problematyczną konfigurację, a następnie naprawiają ją za pomocą dostosowanych podręczników. W ten sposób utrzymujemy konfigurację w środowisku produkcyjnym, a CMS jest zawsze aktualny i zsynchronizowany. Eliminuje to nieprzyjemne „cuda”, gdy kod CMS jest używany na serwerach „produkcyjnych”.
Mamy teraz ważną warstwę testową składającą się z Ansible AWX/GitLab/Molecule (rysunek 6).
Ryż. 6. Zarządzanie testami.
Trudny? Nie kłócę się. Ale taki kompleks zarządzania konfiguracją stał się kompleksową odpowiedzią na wiele pytań związanych z automatyzacją konfiguracji serwerów. Obecnie standardowe serwery sprzedawcy detalicznego mają zawsze ściśle określoną konfigurację. CMS w przeciwieństwie do inżyniera nie zapomni dodać niezbędnych ustawień, stworzyć użytkowników i wykonać dziesiątki lub setki wymaganych ustawień.
Nie ma dziś „tajemnej wiedzy” w ustawieniach serwerów i środowisk. Wszystkie niezbędne funkcje znajdują odzwierciedlenie w podręczniku. Koniec z kreatywnością i niejasnymi instrukcjami: „Zainstaluj go jak zwykłą Oracle, ale musisz określić kilka ustawień sysctl i dodać użytkowników z wymaganym UID. Zapytaj chłopaków w pracy, oni wiedzą".
Możliwość wykrywania rozbieżności w konfiguracji i proaktywnego korygowania ich zapewnia spokój ducha. Bez systemu zarządzania konfiguracją zwykle wygląda to inaczej. Problemy kumulują się, aż pewnego dnia „wystrzeliwują” w produkcję. Następnie przeprowadzany jest odprawa, sprawdzane i korygowane są konfiguracje. I cykl się powtarza
No i oczywiście przyspieszyliśmy uruchomienie serwerów z kilku dni do godzin.
Otóż w samą noc sylwestrową, kiedy dzieci z radością rozpakowywały prezenty, a dorośli składali życzenia przy biciu kurantów, nasi inżynierowie przeprowadzili migrację systemu SAP na nowe serwery. Nawet Święty Mikołaj powie, że najlepsze cuda to te dobrze przygotowane.
PS Nasz zespół często spotyka się z faktem, że klienci chcą rozwiązywać problemy związane z zarządzaniem konfiguracją w możliwie najprostszy sposób. Idealnie, jak za dotknięciem czarodziejskiej różdżki – za pomocą jednego narzędzia. Ale w życiu wszystko jest bardziej skomplikowane (tak, znowu nie padły złote kulki): trzeba stworzyć cały proces, korzystając z narzędzi wygodnych dla zespołu klienta.
Autor: Siergiej Artemow, architekt wydziału „Systemy informacyjne odrzutowca”
Źródło: www.habr.com