Menu

Zarządzanie konfiguracją w praktykach DevOps

  • Główny
  • Inny
  • Zarządzanie konfiguracją w praktykach DevOps

configuration management devops practices

Wypróbuj Nasz Instrument Do Eliminowania Problemów

Co to jest zarządzanie konfiguracją w praktykach DevOps?

Pojęcie Ciągłe testowanie w DevOps zostało szczegółowo wyjaśnione w naszym poprzednim samouczku.

Kluczową zaletą zarządzania konfiguracją w DevOps jest zapewnienie,

  1. Infrastruktura jako kod
  2. Konfiguracja jako kod

Należy przeczytać => Ekskluzywna seria samouczków DevOps

najlepsze oprogramowanie szpiegowskie dla telefonów komórkowych dla Androida

Zarządzanie konfiguracją w praktykach DevOps

„Infrastruktura jako kod” i „Konfiguracja jako kod” ma wiele zalet w praktyce DevOps.

    • Konfiguracje są kontrolowane przez wersję
    • Zautomatyzowane i znormalizowane
    • Usuwa zależność
    • Bezbłędne konfiguracje infra
    • Zwiększa współpracę między zespołem operacyjnym i deweloperskim
    • Korygowanie dryfu konfiguracji
    • Traktowanie infrastruktury jako zasobu elastycznego
    • Zautomatyzowane skalowanie infrastruktury
    • Utrzymanie spójności konfiguracji

WIDEO Część 4 Blok 1: Zarządzanie konfiguracją- 23 minuty 7 sekund

Transkrypcja:

W tej części dowiemy się o tym Zarządzanie konfiguracją, zarządzanie wersjami i monitorowanie wydajności aplikacji w DevOps.

Tutaj, w bloku 1, skupimy się na zarządzaniu konfiguracją i zrozumiemy, czym jest zarządzanie konfiguracją i czym się różni w DevOps od tradycyjnych metod.

Zacznijmy od tego, co to jest zarządzanie konfiguracją?

Zarządzanie konfiguracją, jak sama nazwa wyjaśnia, to nic innego jak zarządzanie wszystkimi konfiguracjami środowisk, w których działa aplikacja.

Jak wiemy, w całym SDLC w DevOps mamy różne środowiska, począwszy od testów jednostkowych, testów integracyjnych, testów systemowych, testów akceptacyjnych i testów użytkowników końcowych.

W moich wcześniejszych samouczkach wyjaśniłem również, że środowisko skonfigurowane na potrzeby tych testów będzie stopniowo stawać się bardziej złożone w miarę zbliżania się do środowiska przedprodukcyjnego i produkcyjnego.

Zasadniczo zarządzanie konfiguracją to zautomatyzowany proces zarządzania wszystkimi konfiguracjami każdego z tych środowisk.

Jaka jest zatem różnica między tradycyjnym zarządzaniem konfiguracją a zarządzaniem konfiguracją DevOps?

W naszych tradycyjnych metodach zarządzania konfiguracjami zespół zarządzał konfiguracjami różnych środowisk poprzez formalną dokumentację, przy czym każda z konfiguracji była wcześniej zapisywana w dokumentach oraz zespół konfiguracyjny lub menedżer obsługujący kontrolę wersji tych dokumentów.

A gdy ulegnie on zmianom, będzie on również odpowiadał za konfigurację środowiska i ręczne zarządzanie konfiguracjami

Obecnie w DevOps wszystkie te procesy zarządzania konfiguracją są dość dobrze zautomatyzowane, a konfiguracje są hermetyzowane w postaci kodu lub skryptów i kontrolowane za pomocą narzędzia do kontroli wersji.

W tym kontekście możemy powiedzieć, że zespół operacyjny jest zintegrowany z programistą w zarządzaniu środowiskami za pomocą narzędzia do kontroli wersji.

Tak więc kluczową zaletą zarządzania konfiguracją w DevOps jest zapewnienie,

      1. Infrastruktura jako kod
      2. Konfiguracja jako kod

Co właściwie oznacza „infrastruktura jako kod”? Definiuje całą definicję środowiska w postaci kodu lub skryptu zamiast zapisywania w formalnym dokumencie.

Więc co obejmuje definicja środowiska? Definicja środowiska ogólnie obejmuje konfigurację serwerów, konfigurację sieci i konfigurację innych zasobów obliczeniowych, które są częścią skonfigurowanej infrastruktury IT. Tak więc wszystkie te szczegóły zostałyby zapisane jako plik lub w postaci kodu i wpisane do narzędzia kontroli wersji.

Ten skrypt lub kod, który jest sprawdzany w kontroli wersji, stałby się jedynym źródłem definiowania środowiska, a nawet aktualizowania tych środowisk.

Po prostu dać proste Przykład jeśli musimy dodać serwer do określonego środowiska, wszystko, co zrobilibyśmy, to zaktualizować te informacje do skryptów środowiska i uruchomić potok dostarczania, zamiast ręcznie przechodzić i uruchamiać nowe środowisko z dodanym serwerem lub szukać pomoc administratorów systemu w tym celu.

Piękno polega więc na tym, że programista lub tester nie musi być ekspertem od administratorów systemu, aby skonfigurować swoje serwery pod kątem działań programistycznych lub testowych.

Tak więc infrastruktura skonfigurowana w DevOps będzie całkowicie zautomatyzowana i zasadniczo podąża za skryptem, który jest sprawdzany do kontroli wersji, począwszy od zainstalowania serwerów, skonfigurowania ich, zainstalowania systemu operacyjnego, aż do ustanowienia kanałów komunikacyjnych tych instancji z wdrożonymi oprogramowanie.

Jaka jest konfiguracja jako kod?

Konfiguracja jako kod to nic innego jak zdefiniowanie wszystkich konfiguracji serwerów lub innych zasobów jako kodu lub skryptu i sprawdzenie ich pod kątem kontroli wersji.

Te skrypty konfiguracyjne, które są wpisywane do kontroli wersji, są uruchamiane jako część potoku wdrażania w celu skonfigurowania infrastruktury i jej konfiguracji w sposób zautomatyzowany.

Cóż, definiowanie konfiguracji obejmuje parametry definiujące zalecane ustawienia umożliwiające pomyślne działanie oprogramowania. Lub zestaw poleceń do uruchomienia na początku w celu skonfigurowania aplikacji. Lub nawet mogą to być konfiguracje każdego z komponentów oprogramowania, które mają być ustawione, lub określone role użytkownika, uprawnienia użytkownika itp.,

Prosty Przykład byłoby ustawienie przełączników funkcji, gdzie domyślne wartości są ustawiane jako część parametru konfiguracyjnego.

Dodanie kolejnego portu do firewalla byłoby innym Przykład , który można zaktualizować w skrypcie, a później te skrypty są uruchamiane jako część potoku dostarczania.

Dostępnych jest kilka narzędzi do automatyzacji infrastruktury na rynku. Niewiele z nich to Chef, Puppet, Terraform itp., Chef i Puppet to narzędzia do zarządzania konfiguracją oparte na języku Ruby, natomiast Terraform to narzędzie do obsługi administracyjnej.

Ponadto obecnie, ponieważ prawie wszystkie aplikacje będą hostowane w chmurze, AWS, one same zapewniają RESTAPI, które można wykorzystać do tego celu.

Mam ogromną listę zalet zarządzania konfiguracją w DevOps, zamiast definiowania infrastruktury i konfiguracji w postaci kodu.

Przejrzyjmy je jeden po drugim.

Wszystkie konfiguracje i szczegóły infrastruktury są kontrolowane pod kątem wersji, co jest dużą zaletą we wdrażaniu DevOps.

# 1) Pomaga to zespołowi w zarządzaniu zmianami na serwerach i konfiguracji w sposób zautomatyzowany i pomaga w szybkim debugowaniu, jeśli coś się nie powiedzie, w krótkim czasie, a także pozwala na szybkie przywrócenie poprzedniej wersji, nie powodując żadnych zakłóceń dla klientów.

#dwa) Ponieważ te skrypty znajdują się na serwerze centralnym i każdy w zespole wie, co jest w każdym z tych skryptów i jakie są zmiany wprowadzone w każdej z tych wersji. Umożliwia to również zespołowi powrót do starszej wersji, jeśli wystąpi jakiś problem w najnowszych wersjach.

Wyobraź sobie, że w przypadku awarii serwera, ile czasu zajęłoby ręczne przywrócenie go. A teraz definiując infrastrukturę jako skrypt i kontrolę wersji, możemy natychmiast przywrócić, przechodząc do wcześniejszej wersji.

# 3) Zarządzanie konfiguracjami jako kodem zapobiega również przypadkowemu wprowadzaniu zmian w systemie i zapobiega uszkodzeniom spowodowanym później w produkcji.

Ponieważ zarządzanie konfiguracją jest całkowicie zautomatyzowane, ręczne interwencje w celu skonfigurowania lub aktualizacji są całkowicie wyeliminowane.

Wyobraź sobie wpływ na koszty, jakość i czas, kiedy wcześniej ludzie polegali na zasobach ludzkich przy ręcznym wykonywaniu tych konfiguracji i kiedy pewne konfiguracje były pomijane lub nie były ustawione zgodnie z wymaganiami.

Tak więc automatyzacja zarządzania konfiguracją przyniosła korzyści nie tylko w postaci oszczędności czasu, ale także eliminacji takich błędów ludzkich i poprawy jakości. Ponadto standard kodowania pomógł zespołowi w przestrzeganiu określonego standardu kodowania i automatyzacji, zamiast podążać za fantazjami każdej osoby, która pisze przewodnik po konfiguracji.

Jak wspomniano wcześniej, konfiguracje dostarczane jako kod usunęły zależność od pojedynczej osoby lub zespołu zwanego menedżerem konfiguracji lub zespołem konfiguracyjnym. Zespół programistów nie musi czekać na przybycie zespołu konfiguracyjnego i naprawienie jakichkolwiek problemów z infrastrukturą lub konfiguracją.

Lub nawet do ustawiania infra i konfiguracji, które są całkowicie zautomatyzowane i kontrolowane wersjami. Tak więc każdy w zespole, czy to programista, czy tester, może obrócić serwer i przeprowadzić konfiguracje do celów programistycznych i testowych. Stąd konfiguracja serwera i konfiguracji stała się niezależna od osoby.

Zapewnia to również, że te same serwery nie są używane przez zespoły programistyczne i QA do ich działań, co zwykle miało miejsce wcześniej.

Infrastruktura i konfiguracje zdefiniowane jako wspólny kod wraz z automatyzacją i kontrolą wersji standaryzują wszystkie środowiska i konfiguracje. Tak więc to nie tylko ułatwia programistom zadanie debugowania, ale także eliminuje ludzkie błędy powodujące bezbłędne konfiguracje infra, które w przeciwnym razie spowodowałyby ogromne szkody, jeśli nie zostałyby wykryte wcześnie.

Tutaj wyraźnie widać wyraźną współpracę między deweloperami i operatorami, gdzie obaj polegają na jednym źródle do przeprowadzania konfiguracji infra, a oba zespoły są aktywnie zaangażowane w automatyzację i konfigurowanie całego zarządzania konfiguracją.

Współpraca w celu osiągnięcia wspólnego celu wzmacnia współpracę między zespołami, działami rozwoju i operacjami.

Korygowanie dryfu konfiguracji

Co to jest Configuration Drift?

Niewielkie różnice i niespójności między serwerami, które czasami zdarzają się z powodu ręcznej aktualizacji, która gromadzi się przez pewien okres czasu, nazywane są dryfem konfiguracji.

To nie jest dobra sytuacja, ponieważ ta niespójność na serwerach powoduje, że niektóre pliki programów, takie jak manifest, playbook, nie działają niezawodnie na wszystkich serwerach, co prowadzi do awarii automatyzacji. Dlatego należy tego unikać, aby zespół mógł efektywnie wykorzystywać automatyzację konfiguracji.

Zarządzanie infra i konfiguracją jako kodem i wersją kontrolującą je pomogło zespołowi uniknąć lub skorygować wszelkiego rodzaju dryfy konfiguracyjne między różnymi środowiskami lub między ustawieniami deweloperskimi i produkcyjnymi dzięki konsekwentnemu utrzymywaniu konfiguracji na wszystkich serwerach.

W ten sposób zespół może być najlepiej pewny podobnych konfiguracji konfiguracji na etapie rozwoju, jak w przypadku produkcji. Pomaga im to również w symulowaniu problemów produkcyjnych w środowisku deweloperskim.

Pomaga to więc zapobiec wszelkim nieoczekiwanym zmianom, które którykolwiek z członków zespołu może próbować wprowadzić w infra, co może zepsuć konfigurację, a także zmusić zespół do wprowadzania żadnych zmian w konfiguracji, chyba że są zalogowani jako kod do repozytorium.

Dostarczenie infrastruktury i jej konfiguracja w postaci kodu umożliwiło zespołowi zarządzanie nią jako elastycznym zasobem spełniającym dynamiczne potrzeby biznesowe klienta.

Teraz jest to rodzaj plug and play. Zespół może konkretnie dostać się do określonego serwera lub sieci i wprowadzić w nich zmiany. Może to być po prostu aktualizacja serwera obsługi administracyjnej lub dodanie lub modyfikacja magazynu w określonej sieci, a nawet aktualizacja systemu operacyjnego, a wszystko może być niezależnie aktualizowane jako elastyczny zasób.

Wcześniej zmiana jednego parametru konfiguracyjnego zajmowała naprawdę dużo czasu, zwłaszcza gdy aktualizacja była wymagana na wszystkich serwerach, ale teraz jest to tylko jedno podejście. Zaktualizuj skrypt, prześlij go do narzędzia kontroli wersji i gotowe.

Istnieje możliwość całkowitego zlikwidowania istniejącej infrastruktury i całkowitego przywrócenia innej. Tak więc zarządzanie infrastrukturą i konfiguracjami stało się teraz dość łatwe. Cóż, rozwiązania oparte na chmurze umożliwiły infrastrukturze automatyczne skalowanie w górę poprzez dodawanie dodatkowych zasobów obliczeniowych lub pamięci masowej zgodnie z wymaganiami i skalowanie w dół, gdy nie są potrzebne.

Umożliwiło to optymalizację wykorzystania zasobów w oparciu o zapotrzebowanie. Jeśli chcemy skalować infrastrukturę, zwiększając rozmiar maszyny, możemy to zrobić od razu. Podobnie, jeśli chcemy skalować w poziomie lub może dodać inną konfigurację lub dodać więcej interfejsów, możemy to zrobić w kilka sekund, po prostu aktualizując kod w kodzie i uruchamiając automatyczny potok.

Wreszcie infrastruktura, dostarczanie jako kod w kontrolowanym środowisku pomaga w utrzymaniu spójności środowisk w różnych konfiguracjach. Pomaga to również w debugowaniu problemu. Ten punkt, do pewnego stopnia, omówiłem wcześniej, mówiąc o dryfcie konfiguracji.

To wszystko i na tym kończy się nasza rozmowa o zarządzaniu konfiguracją w DevOps, czyli o tym, czym jest infrastruktura i konfiguracje jako kod i jakie są jego zalety.

W naszym nadchodzącym samouczku omówimy aspekty zarządzania wersjami w DevOps.

POPRZEDNIA samouczek | NEXT Tutorial

rekomendowane lektury

^