To jest zapis przemówienia и .
Oto historia projektu, w którym wykorzystano samodzielnie napisany system zarządzania konfiguracją i dlaczego przejście na Ansible zajęło 18 miesięcy.
Dzień nr -ХХХ: Przed początkiem
Początkowo infrastruktura składała się z wielu oddzielnych hostów z uruchomioną funkcją Hyper-V. Stworzenie maszyny wirtualnej wymagało wielu kroków: umieszczenia dysków we właściwym miejscu, zarejestrowania DNS, zarezerwowania DHCP, umieszczenia konfiguracji VM w repozytorium git. Proces ten był częściowo zmechanizowany, ale na przykład maszyny wirtualne były dystrybuowane między hostami ręcznie. Ale na przykład programiści mogą poprawić konfigurację maszyny wirtualnej w git i zastosować ją, ponownie uruchamiając maszynę wirtualną.
Niestandardowe rozwiązanie do zarządzania konfiguracją
Podejrzewam, że pierwotny pomysł został pomyślany jako IaC: wiele bezstanowych maszyn wirtualnych, które po ponownym uruchomieniu resetują swój stan do zera. Na czym polegało zarządzanie konfiguracją maszyn wirtualnych? Schematycznie wygląda to prosto:
- Dla maszyny wirtualnej przypisano statyczny adres MAC.
- Do maszyny wirtualnej podłączono obraz ISO z systemem CoreOS i dysk rozruchowy.
- CoreOS uruchamia skrypt dostosowywania, pobierając go z serwera WWW na podstawie jego adresu IP.
- Skrypt pobiera konfigurację maszyny wirtualnej poprzez SCP na podstawie adresu IP.
- Uruchamiana jest część plików jednostek systemowych i część skryptów bash.
To rozwiązanie miało wiele oczywistych problemów:
- CoreOS ISO jest przestarzały.
- Wiele skomplikowanych zautomatyzowanych działań i magii podczas migracji/tworzenia maszyn wirtualnych.
- Trudności z aktualizacją i koniecznością posiadania określonej wersji oprogramowania. Jeszcze więcej zabawy z modułami jądra.
- Nie uzyskano maszyn wirtualnych bez danych, tj. Maszyny wirtualne pojawiły się z dyskiem, na którym zamontowano dodatkowe dane użytkownika.
- Ktoś ciągle psuł zależności jednostek systemowych i CoreOS zawieszał się podczas ponownego uruchamiania. Trudno było to wyłapać za pomocą narzędzi dostępnych w CoreOS.
- Zarządzanie tajemnicami.
- Nie było CM. Były konfiguracje bash i YML dla CoreOS.
Aby zastosować konfigurację maszyny wirtualnej, należy ją ponownie uruchomić, ale ponowne uruchomienie może się nie powieść. Wydaje się to oczywistym problemem, ale nie ma dysków stałych - nie ma gdzie zapisywać logów. No dobrze, spróbujmy dodać opcję ładowania jądra, aby logi zostały wysłane. Ale nie, jakie to wszystko jest skomplikowane.
Dzień nr 0: Rozpoznaj problem
Była to zwykła infrastruktura programistyczna: Jenkins, środowiska testowe, monitorowanie, rejestr. CoreOS został zaprojektowany z myślą o hostingu klastrów k8s, tj. problemem był sposób wykorzystania CoreOS. Pierwszym krokiem był wybór stosu. Ustaliliśmy:
- CentOS jako dystrybucja podstawowa, ponieważ Jest to dystrybucja najbliższa środowiskom produkcyjnym.
- Wiarygodne do zarządzania konfiguracją, ponieważ przeprowadzono szczegółowe badania w tej sprawie.
- Jenkins jako framework do automatyzacji istniejących procesów, ponieważ został już aktywnie wykorzystany w procesach rozwojowych
- Hyper-V jako platforma wirtualizacyjna. Powodów jest wiele, wykraczających poza zakres fabuły, ale w skrócie – nie możemy korzystać z chmur, musimy korzystać z własnego sprzętu.
Dzień nr 30: Naprawa istniejących umów – Umowy jako Kodeks
Kiedy stos się oczyścił, rozpoczęły się przygotowania do ruchu. Naprawa istniejących umów w formie kodu (Umowy jako kodeks!). Przemiana Praca fizyczna -> mechanizacja -> automatyzacja.
1. Skonfiguruj maszyny wirtualne
Ansible radzi sobie z tym znakomicie. Przy minimalnej liczbie ruchów ciała możesz przejąć kontrolę nad konfiguracjami maszyn wirtualnych:
- Utwórz repozytorium git.
- Listę maszyn wirtualnych umieszczamy w inwentarzu, konfiguracje w playbookach i rolach.
- Tworzymy specjalnego niewolnika Jenkinsa, z którego można uruchomić Ansible.
- Tworzymy zadanie i konfigurujemy Jenkinsa.
Pierwszy proces jest gotowy. Umowy są stałe.
2. Utwórz nową maszynę wirtualną
Wszystko tutaj nie było zbyt wygodne. Tworzenie maszyn wirtualnych na Hyper-V z Linuksa nie jest zbyt wygodne. Jedną z prób mechanizacji tego procesu było:
- Ansbile łączy się poprzez WinRM z hostem Windows.
- Ansible uruchamia skrypt PowerShell.
- Skrypt PowerShell tworzy nową maszynę wirtualną.
- Przy użyciu funkcji Hyper-V/ScVMM podczas tworzenia maszyny wirtualnej w systemie gościa konfigurowana jest nazwa hosta.
- Podczas aktualizacji dzierżawy DHCP maszyna wirtualna wysyła swoją nazwę hosta.
- Standardowa integracja ddns i dhcp po stronie kontrolera domeny konfiguruje rekord DNS.
- Możesz dodać maszynę wirtualną do swojego ekwipunku i skonfigurować ją za pomocą Ansible.
3. Utwórz szablon maszyny wirtualnej
Nic tu nie wymyślili - wzięli pakowacz.
- Dodaj paker i konfigurację kickstart do repozytorium git.
- Konfigurowanie specjalnego niewolnika Jenkinsa z Hyper-V i Packerem.
- Tworzymy zadanie i konfigurujemy Jenkinsa.
Jak działa ten link:
- Packer tworzy pustą maszynę wirtualną i pobiera ISO.
- Maszyna wirtualna uruchamia się, Packer wprowadza polecenie do programu ładującego, aby użyć naszego pliku kickstart z dyskietki lub http.
- Anaconda zostaje uruchomiona z naszą konfiguracją i początkowa konfiguracja systemu operacyjnego jest zakończona.
- Packer czeka, aż maszyna wirtualna stanie się dostępna.
- Program pakujący wewnątrz maszyny wirtualnej uruchamia ansible w trybie lokalnym.
- Ansible używa dokładnie tych samych ról, co w kroku 1.
- Packer eksportuje szablon maszyny wirtualnej.
Dzień #75: Refaktoryzacja umowy bez łamania = Test ansible + Testkitchen
Przechwytywanie konwencji w kodzie może nie wystarczyć. W końcu, jeśli na każdym etapie procesu chcesz coś zmienić, możesz coś zepsuć. Dlatego w przypadku infrastruktury pojawia się testowanie tej właśnie infrastruktury. Aby zsynchronizować wiedzę w zespole, rozpoczęliśmy testowanie ról Ansible. Nie będę się zagłębiał, bo… istnieje artykuł opisujący wydarzenia w tamtym momencie (spoiler, to nie była wersja ostateczna, później wszystko się skomplikowało ).
Dzień #130: Może CentOS+ansible nie jest potrzebny? może openshift?
Musimy zrozumieć, że proces wprowadzania infrastruktury nie był jedyny i istniały podprojekty poboczne. Na przykład przyszła prośba o uruchomienie naszej aplikacji w systemie openshift, co zaowocowało badaniami trwającymi ponad tydzień co spowolniło proces przenoszenia. W rezultacie okazało się, że openshift nie pokrywa wszystkich potrzeb, potrzebny jest prawdziwy sprzęt lub przynajmniej możliwość zabawy z jądrem.
Dzień #170: Openshift nie jest odpowiedni, zaryzykujmy z Windows Azure Pack?
Hyper-V nie jest zbyt przyjazny, SCVMM nie czyni go dużo lepszym. Istnieje jednak coś takiego jak Windows Azure Pack, który jest dodatkiem do SCVMM i naśladuje Azure. Ale w rzeczywistości produkt wygląda na porzucony: dokumentacja zawiera uszkodzone linki i jest bardzo skąpa. Ale w ramach badania możliwości uproszczenia życia naszej chmury również się temu przyjrzeli.
Dzień #250: Pakiet Windows Azure nie jest zbyt dobry. Pozostajemy na SCVMM
Pakiet Windows Azure Pack wyglądał obiecująco, ale zdecydowano się nie wprowadzać protokołu WAP ze względu na jego złożoność do systemu ze względu na niepotrzebne funkcje i pozostawiono SCVMM.
Dzień #360: Jedzenie słonia kawałek po kawałku
Zaledwie rok później platforma do przeprowadzki była gotowa i rozpoczął się proces przeprowadzki. W tym celu ustawiono zadanie SMART. Sprawdziliśmy wszystkie maszyny wirtualne i zaczęliśmy po kolei wymyślać konfigurację, opisać ją w Ansible i objąć testami.
Dzień #450: Jaki rodzaj systemu otrzymałeś?
Sam proces nie jest interesujący. Jest to rutynowe, można zauważyć, że większość konfiguracji była stosunkowo prosta lub izomorficzna i zgodnie z zasadą Pareto 80% konfiguracji maszyn wirtualnych wymagało 20% czasu. Na tej samej zasadzie 80% czasu poświęcono na przygotowanie przeprowadzki, a tylko 20% na samą przeprowadzkę.
Dzień #540: Finał
Co wydarzyło się w ciągu 18 miesięcy?
- Umowy stały się kodeksem.
- Praca fizyczna -> Mechanizacja -> Automatyzacja.
Linki
Źródło: www.habr.com