Stworzyliśmy serwer, który obsługuje infrastrukturę dla małego stowarzyszenia. Do tej pory próbowaliśmy zarządzać konfiguracją za pomocą Ansible, ale nie był to duży sukces. Być może robimy to źle.
Zasadniczo chodzi o to, że ten serwer pozostanie sam przez większość czasu, a ludzie będą dodawać lub zmieniać rzeczy raz na niebieskim księżycu. To sprawia, że ważne jest, aby wszystko, co jest skonfigurowane i działało na serwerze, było dobrze udokumentowane i przejrzyste, ponieważ osoby, które nie administrują często systemem, muszą stracić informacje ogólne (nie mówiąc już o szczegółach). Ponadto z czasem zmieni się skład grupy osób, które będą administrować tym serwerem (w miarę opuszczania i dołączania do „komitetu”).
Zaczęliśmy od czystej instalacji, dodając role w ansible, kiedy tylko chcieliśmy coś skonfigurować (nginx, phpfpm, postfix, firewall, sftp, munin, ..). Być może z powodu naszego braku doświadczenia, oczywiście nigdy nie jesteśmy w stanie wpisać zestawu odpowiadających zadań dokładnie tak, jak potrzebujemy, za jednym razem, również dlatego, że konfiguracja jest trochę procesem prób i błędów. Oznacza to, że w praktyce zwykle najpierw konfigurujemy dowolną usługę, którą chcemy uruchomić na serwerze , a następnie tłumaczymy na zadania odpowiadające. Możesz zobaczyć dokąd to zmierza. Ludzie zapominają następnie przetestować to zadanie lub boją się tego, ryzykując zepsucie rzeczy, lub gorzej: zapominamy lub zaniedbujemy dodawanie rzeczy do ansible.
Dzisiaj mamy bardzo małą pewność, że konfiguracja ansible faktycznie odzwierciedla konfigurację na serwerze.
Obecnie widzę trzy główne problemy:
- Trudno jest (czytać: nie mamy dobrego sposobu) testować wykonalnych zadań bez ryzyka zepsucia.
- Dodaje dodatkową pracę, aby najpierw ustalić pożądaną konfigurację, a następnie dowiedzieć się, jak przełożyć ją na zadania możliwe do wykonania.
- (Idealnie) nie używamy go wystarczająco często, aby budować znajomość i rutynę.
Ważną kwestią jest to, że dla wszystkiego, co skończymy, początkującym powinno być łatwo nauczyć się lin bez mnóstwa ćwiczeń.
Czy istnieje realna alternatywa, która nadal zapewnia pewne gwarancje i kontrole (porównywalne do łączenia plików Ansible z niektórymi master), które „nie konfigurują rzeczy i zapisują to, co zrobiłeś”?
EDYCJA: Rozważaliśmy zobowiązanie się /etcdo git. Czy istnieje rozsądny sposób na ochronę tajemnic (klucze prywatne itp.) W ten sposób, ale nadal ma jakieś repozytorium konfiguracji dostępne poza serwerem?
Chociaż istnieją inne problemy (takie jak brak środowiska testowego), możesz znacznie poprawić, nie robiąc tego .
Jednym z głównych celów projektu Ansible jest bycie idempotentnym , co oznacza, że wielokrotne uruchamianie twojego playbooka nie powinno niczego zmieniać (chyba że zmieniłeś gry). Tak więc, kiedy konfiguruję nowe oprogramowanie, moje kroki to:
Jeśli nie sądzisz, że po raz pierwszy napiszesz poprawną rzecz w Ansible, napisz to i tak i powtarzaj, aż będzie w porządku, tak jak każdy inny kod. To znacznie zmniejsza szansę zapomnienia o Ansiblize niektórych zmian, które wprowadziłeś, ponieważ każda zmiana, którą wprowadziłeś, była już w Ansible na pewnym etapie procesu rozwoju.
źródło
Ansible ma czas na rozruch, zanim przekroczysz swój poprzedni poziom produktywności, ale kiedy to zrobisz, stan systemu jest łatwy do zapewnienia. Twoje praktyki wydają się być niezsynchronizowane z celami końcowymi. Możesz być produktywny dzięki zestawowi narzędzi CM, zachowując solidne praktyki inżynieryjne, ale jego prawidłowe ułożenie zajmuje trochę czasu. Zasadniczo handlujesz wydajnością i łatwością wdrożenia, dla stabilności i skalowalności przedsiębiorstwa. Dokładnie tak samo, jak doświadczony profesjonalny programista nie pisze brzydkich hacków, konsekwencje zawsze przeważają nad korzyściami.
Na początek możesz mieć zbyt wielu kucharzy, bez wyraźnego prawa własności, jeśli tak, spodziewaj się tragedii społeczności. Każdy priorytet biznesowy przebije obawy związane z inżynierią systemu za każdym razem, chyba że zostanie on szeroko rozbrojony, a to, co pozostanie, odbije się bezpośrednio na odpowiedzialnym inżynierze.
Zestaw narzędzi CM nie może być zaprojektowany przez administratorów, właśnie to sobie uświadomiłem. Mogą ponownie wykorzystać istniejącą pracę lub MOŻLIWE rozciągać się na solidne podstawy, ale nawet wtedy wymagałoby to uciążliwej ilości egzekwowania praktyk. To, co może zrobić inżynier, to po prostu NIE to, co może zrobić administrator. Wiele pojęć w Ansible jest prawie takich samych, jak w bazie kodu, czy możesz nauczyć pytona administratora i oczekiwać właściwych wyników? Nie, z całą pewnością nie, spodziewałbym się włamania, więc musisz ustawić to zadanie na tyle, aby włamanie było możliwe.
Musisz więc przygotować rzeczy do sukcesu, opracować rozwiązania dla punktów niepotrzebnej administracji. Wymień złożoność systemów niskiego poziomu na rzeczy, które administrator może faktycznie z powodzeniem zrobić. Zestaw narzędzi CM NIE uchroni Cię przed niedopasowaniami architektonicznymi lub projektowymi.
Więc porządek podlega modyfikacji, oczywiście ponieważ implementacja zależy od tego, która ścieżka jest najmniej zakłócająca dla twojego obecnego stanu.
Przenieś dowolną pracę związaną z przepływem pracy związaną z biznesem do dedykowanego zestawu.
Rozdziel zadania na pudełku, możesz mieć teraz dwa lub więcej pudełek w jednym.
Reimplementuj swoje CM w bardziej uporządkowany sposób i postępuj zgodnie z lepszymi praktykami, podręczniki reprezentujące obiekty, NIE funkcje lub role. Każdy system powinien być opisany w jednej grze.
źródło