To jest transkrypcja wystąpienia na i .
To jest historia projektu, w którym użyto autorskiego systemu zarządzania konfiguracją i dlaczego migracja do Ansible zajęła 18 miesięcy.
Dzień nr -XXX: Przed rozpoczęciem
Początkowo infrastruktura składała się z wielu oddzielnych hostów zarządzanych przez Hyper-V. Tworzenie maszyny wirtualnej wymagało wielu działań: umieszczenia dysków w odpowiednich miejscach, skonfigurowania DNS, zarezerwowania DHCP, umieszczenia konfiguracji VM w repozytorium git. Ten proces był częściowo zautomatyzowany, ale na przykład maszyny wirtualne były przydzielane między hostami manualnie. Na przykład programiści mogli edytować konfigurację VM w git i zastosować ją, restartując VM.
Custom Configuration Management Solution
Początkowo zakładałem, że pomysł był planowany jako IaC: wiele maszyn wirtualnych bezstanowych, które przy ponownym uruchomieniu resetowały swój stan. Jakie było zarządzanie konfiguracjami VM? Schematycznie wyglądało to prosto:
- Dla VM przypisywano statyczny adres MAC.
- Do VM podłączano ISO z CoreOS i dysk rozruchowy.
- CoreOS uruchamia skrypt dostosowujący, pobierając go z serwera WEB na podstawie swojego adresu IP.
- Skrypt pobiera przez SCP konfigurację VM na podstawie adresu IP.
- Uruchamiana jest sekwencja plików jednostek systemd oraz skryptów bash.
To rozwiązanie miało wiele oczywistych problemów:
- ISO w CoreOS zostało oznaczone jako przestarzałe.
- Wiele skomplikowanych zautomatyzowanych działań i magii podczas migracji/tworzenia VM.
- Problemy z aktualizacją i gdy potrzebne było oprogramowanie w konkretnej wersji. Jeszcze więcej problemów z modułami jądra.
- VM nie były tak zupełnie bezdane, to znaczy powstały VM z zamontowanym dodatkowym dyskiem z danymi użytkowników.
- Ktoś zawsze robił błąd z zależnościami jednostek systemd, przez co CoreOS się zawieszał podczas ponownego uruchamiania. Z używanych narzędzi w CoreOS, zdiagnozowanie tego było problematyczne.
- Zarządzanie sekretami.
- W zasadzie nie było CM. Był bash i konfiguracje YML w CoreOS.
Aby zastosować konfigurację VM, trzeba ją było zrestartować, ale mogła się nie uruchomić. Wydaje się to oczywistym problemem, ale brakowało trwałych dysków — nie było gdzie zapisywać logów. No dobrze, spróbujmy dodać opcje do ładowania jądra, żeby logi były przesyłane. Ale nie, to wszystko jest tak skomplikowane.
Dzień nr 0: Uznać problem
To była zwykła infrastruktura deweloperska: jenkins, środowiska testowe, monitorowanie, registry. CoreOS została zaprojektowana do hostowania klastrów k8s, więc problem polegał na tym, jak używano CoreOS. Pierwszym krokiem był wybór stacka. Zatrzymaliśmy się na:
- CentOS jako podstawowy dystrybucja, ponieważ to najbliższa dystrybucja do środowisk produkcyjnych.
- Ansible do zarządzania konfiguracjami, ponieważ była na ten temat obszerna ekspertyza.
- Jenkins jako framework automatyzacji istniejących procesów, ponieważ był już aktywnie wykorzystywany w procesach deweloperskich.
- Hyper-V jako platforma wirtualizacji. Istnieje wiele powodów, które wykraczają poza zakres tej historii, ale w skrócie - nie możemy korzystać z chmur, musimy korzystać ze swojego sprzętu.
Dzień nr 30: Utrwalamy istniejące umowy — Agreements as Code
Gdy stack stał się jasny, rozpoczęły się przygotowania do przeprowadzki. Utrwalenie istniejących umów w postaci kodu (Agreements as Code!). Przejście praca ręczna -> mechanizacja -> automatyzacja.
1. Konfiguracja VM
Ansible doskonale radzi sobie z tym zadaniem. Z minimalnym wysiłkiem można przejąć kontrolę nad konfiguracjami VM:
- Tworzymy repozytorium git.
- Umieszczamy listę VM w inventory, konfiguracje w playbookach i rolach.
- Konfigurujemy specjalnego slave'a jenkinsa, z którego można będzie uruchamiać ansible.
- Tworzymy job, konfigurujemy Jenkins.
Pierwszy proces gotowy. Umowy utrwalone.
2. Utworzenie nowej VM
Tutaj wszystko było dość niewygodne. Z linuksa niewygodnie jest tworzyć VM na Hyper-V. Jedną z prób zmechanizowania tego procesu było:
- Ansible łączy się przez WinRM z hostem windows.
- Ansible uruchamia skrypt powershell.
- Skrypt Powershell tworzy nową VM.
- Narzędzia Hyper-V/ScVMM przy tworzeniu VM w gościach ustawiają hostname.
- VM podczas aktualizacji DHCP lease wysyła swój hostname.
- Standardowa integracja ddns & dhcp po stronie Domain Controller konfiguruje rekord DNS.
- Można dodawać VM do inventory i konfigurować ją w Ansible.
3. Utworzenie szablonu VM
Tutaj nie wymyślono nic nowego - użyto packera.
- W repozytorium git umieszczamy konfigurację packera, kickstart.
- Konfigurujemy specjalnego slave'a jenkinsa z hyper-v i packerem.
- Tworzymy job, konfigurujemy Jenkins.
Jak działa ta współpraca:
- Packer tworzy pustą VM, podłącza ISO.
- VM uruchamia się, Packer wprowadza do bootloadera polecenie użycia naszego pliku kickstart z dyskietki lub http.
- Uruchamia się anaconda z naszym konfiguracją, przeprowadzana jest wstępna konfiguracja OS.
- Packer czeka na dostępność VM.
- Packer wewnątrz VM uruchamia ansible w trybie lokalnym.
- Ansible działa przy użyciu dokładnie tych samych ról, co w kroku nr 1.
- Packer eksportuje szablon VM.
Dzień nr 75: Refaktoryzujemy ustalenia, nie łamiąc = Test ansible + Testkitchen.
Utrwalenie ustaleń w kodzie może być niewystarczające. Jeśli w procesie w podłożu zechcesz coś zmienić — możesz coś zepsuć. Dlatego w przypadku infrastruktury pojawia się testowanie tej infrastruktury. Aby zsynchronizować wiedzę w ramach zespołu, zaczęliśmy testować role Ansible. Nie będę się zagłębiać, ponieważ jest artykuł opisujący zdarzenia w tamtym czasie. (spoilery, to nie była ostateczna wersja, a później wszystko stało się bardziej skomplikowane. ).
Dzień nr 130: A może CentOS + ansible nie jest potrzebne? Może openshift?
Trzeba rozumieć, że proces wprowadzania infrastruktury nie był jedynym, były również poboczne podprojekty. Na przykład, pojawił się wniosek o uruchomienie naszej aplikacji w openshift, co przełożyło się na badania trwające co najmniej tydzień. co spowolniło proces migracji. Okazało się, że openshift nie zaspokaja wszystkich potrzeb, potrzebny jest prawdziwy sprzęt lub przynajmniej możliwość zabawy z jądrem.
Dzień nr 170: Openshift nie pasuje, zaryzykujemy z Windows Azure Pack?
Hyper-V nie jest zbyt przyjazny, SCVMM nie poprawia sytuacji. Ale jest coś takiego jak Windows Azure Pack, które jest nakładką na SCVMM i imituje Azure. Jednak w rzeczywistości produkt wydaje się porzucony: dokumentacja z uszkodzonymi linkami i dość uboga. Ale w ramach badań nad uproszczeniem życia naszego chmury, przyglądaliśmy się również temu.
Dzień nr 250: Windows Azure Pack nie jest za dobry. Zostajemy przy SCVMM.
Windows Azure Pack wyglądał obiecująco, ale zdecydowano się nie wprowadzać WAP z jego złożonościami do systemu dla zbędnych funkcji i pozostać przy SCVMM.
Dzień nr 360: Jemy słonia kawałkami.
Dopiero po roku platforma była gotowa do migracji i rozpoczął się proces przenoszenia. W tym celu została postawiona zadanie S.M.A.R.T. Spisaliśmy wszystkie VMs i zaczęliśmy stopniowo zajmować się konfiguracją, opisywać ją w Ansible, pokrywać testami.
Dzień nr 450: Jaki system otrzymaliśmy?
Sam proces nie jest interesujący. Jest rutynowy; można zauważyć, że większość konfiguracji była stosunkowo prosta lub izomorficzna, a według zasady Pareto 80% konfiguracji w VM zajęło 20% czasu. Tym samym 80% czasu poszło na przygotowanie przeprowadzki, a tylko 20% na samą przeprowadzkę.
Dzień nr 540: Finał
Co się wydarzyło w ciągu ostatnich 18 miesięcy?
- Uzgodnienia stały się kodem.
- Praca ręczna -> Mechanizacja -> Automatyzacja.
Linki
Źródło: habr.com
