Jeśli Twoja infrastruktura IT rozrasta się zbyt szybko, prędzej czy później staniesz przed wyborem: liniowo zwiększyć zasoby ludzkie do jej obsługi lub rozpocząć automatyzację. Do pewnego momentu żyliśmy w pierwszym paradygmacie, a potem rozpoczęła się długa droga do Infrastruktury jako Kodu.
Oczywiście NSPK nie jest startupem, ale taka atmosfera panowała w firmie w pierwszych latach jej istnienia i były to bardzo ciekawe lata. Nazywam się , Od ponad 10 lat wspieram infrastrukturę Linux o wymaganiach wysokiej dostępności. Do zespołu NSPK dołączył w styczniu 2016 roku i niestety nie widział samego początku istnienia firmy, ale wszedł na etap wielkich zmian.
Ogólnie można powiedzieć, że nasz zespół dostarcza firmie 2 produkty. Pierwszą z nich jest infrastruktura. Poczta powinna działać, DNS powinien działać, a kontrolery domeny powinny umożliwiać dostęp do serwerów, które nie powinny się zawieszać. Krajobraz IT firmy jest ogromny! Są to systemy o znaczeniu krytycznym dla biznesu i misji, wymagania dostępności dla niektórych wynoszą 99,999. Drugim produktem są same serwery, fizyczne i wirtualne. Istniejące wymagają monitorowania, a nowe muszą być regularnie dostarczane do klientów z wielu działów. W tym artykule chcę się skupić na tym jak opracowaliśmy infrastrukturę odpowiedzialną za cykl życia serwera.
Początku drogi
Na początku naszej podróży nasz stos technologii wyglądał następująco:
System operacyjny CentOS 7
Kontrolery domeny FreeIPA
Automatyka - Ansible(+Wieża), Szewc
Wszystko to znajdowało się w 3 domenach, rozmieszczonych w kilku centrach danych. W jednym data center znajdują się systemy biurowe i stanowiska testowe, w pozostałych PROD.
Tworzenie serwerów w pewnym momencie wyglądało tak:
W szablonie maszyny wirtualnej CentOS jest minimalny, a wymagane minimum jest takie jak poprawny plik /etc/resolv.conf, reszta przechodzi przez Ansible.
CMDB-Excel.
Jeśli serwer jest fizyczny, to zamiast kopiować maszynę wirtualną, zainstalowano na niej system operacyjny za pomocą Cobblera - adresy MAC docelowego serwera są dodawane do konfiguracji Cobblera, serwer otrzymuje adres IP przez DHCP, a następnie system operacyjny jest dodany.
Na początku próbowaliśmy nawet zarządzać konfiguracją w Cobblerze. Jednak z biegiem czasu zaczęło to powodować problemy z przenośnością konfiguracji zarówno do innych centrów danych, jak i do kodu Ansible do przygotowania maszyn wirtualnych.
W tamtym czasie wielu z nas postrzegało Ansible jako wygodne rozszerzenie Basha i nie oszczędzało na projektach wykorzystujących Shell i sed. Ogólnie Bashsible. Doprowadziło to ostatecznie do tego, że jeśli playbook z jakiegoś powodu nie działał na serwerze, łatwiej było usunąć serwer, naprawić playbook i uruchomić go ponownie. Zasadniczo nie było wersjonowania skryptów ani możliwości przenoszenia konfiguracji.
Na przykład chcieliśmy zmienić niektóre konfiguracje na wszystkich serwerach:
- Zmieniamy konfigurację na istniejących serwerach w segmencie logicznym/centrum danych. Czasem nie w jeden dzień – wymogi dostępności i prawo wielkich liczb nie pozwalają na wprowadzenie wszystkich zmian od razu. Niektóre zmiany są potencjalnie destrukcyjne i wymagają ponownego uruchomienia czegoś - od usług po sam system operacyjny.
- Naprawianie tego w Ansible
- Naprawiamy to w Cobblerze
- Powtórz N razy dla każdego segmentu logicznego/centrum danych
Aby wszystkie zmiany przebiegły sprawnie, trzeba było wziąć pod uwagę wiele czynników, a zmiany zachodzą nieustannie.
- Refaktoryzacja kodu ansible, pliki konfiguracyjne
- Zmiana wewnętrznych najlepszych praktyk
- Zmiany na podstawie wyników analizy incydentów/wypadków
- Zmieniające się standardy bezpieczeństwa, zarówno wewnętrzne, jak i zewnętrzne. Na przykład PCI DSS jest co roku aktualizowany o nowe wymagania
Rozwój infrastruktury i początek podróży
Wzrosła liczba serwerów/domen logicznych/centrów danych, a wraz z nimi liczba błędów w konfiguracjach. W pewnym momencie doszliśmy do trzech kierunków, w których należy rozwijać zarządzanie konfiguracją:
- Automatyzacja. Należy w miarę możliwości unikać błędów ludzkich podczas powtarzalnych operacji.
- Powtarzalność. Dużo łatwiej jest zarządzać infrastrukturą, gdy jest przewidywalna. Konfiguracja serwerów i narzędzi do ich przygotowania powinna być wszędzie taka sama. Ma to znaczenie także dla zespołów produktowych – trzeba mieć pewność, że po przetestowaniu aplikacja trafi do środowiska produkcyjnego skonfigurowanego podobnie jak środowisko testowe.
- Prostota i przejrzystość wprowadzania zmian w zarządzaniu konfiguracją.
Pozostaje dodać kilka narzędzi.
Na nasze repozytorium kodu wybraliśmy GitLab CE, zwłaszcza ze względu na wbudowane moduły CI/CD.
Skarbiec tajemnic - Skarbiec Hashicorp, m.in. za świetne API.
Testowanie konfiguracji i ról ansible – Molecule+Testinfra. Testy przebiegają znacznie szybciej, jeśli połączysz się z mitogenem ansible. W tym samym czasie zaczęliśmy pisać własny CMDB i orkiestratora do automatycznego wdrażania (na zdjęciu powyżej Cobbler), ale to już zupełnie inna historia, którą opowie w przyszłości mój kolega i główny programista tych systemów.
Nasz wybór:
Cząsteczka + Testinfra
Ansible + Wieża + AWX
Świat Serwerów + DITNET (opracowanie własne)
Szewc
Gitlab + biegacz GitLab
Skarbiec Hashicorp
Nawiasem mówiąc, o rolach anible. Na początku była tylko jedna, ale po kilku refaktoryzacjach było ich 17. Gorąco polecam rozbicie monolitu na role idempotentne, które można później uruchomić osobno, dodatkowo można dodać tagi. Role podzieliliśmy według funkcjonalności - sieć, logowanie, pakiety, sprzęt, molekuła itp. Ogólnie rzecz biorąc, postępowaliśmy zgodnie z poniższą strategią. Nie twierdzę, że to jedyna prawda, ale w naszym przypadku zadziałało.
- Kopiowanie serwerów ze „złotego obrazu” jest złem!Główną wadą jest to, że nie wiadomo dokładnie, w jakim stanie są obecnie obrazy i że wszystkie zmiany zostaną wprowadzone do wszystkich obrazów we wszystkich farmach wirtualizacji.
- Korzystaj z domyślnych plików konfiguracyjnych do minimum i uzgodnij z innymi działami, że jesteś odpowiedzialny za główne pliki systemowena przykład:
- Pozostaw plik /etc/sysctl.conf pusty, ustawienia powinny znajdować się tylko w /etc/sysctl.d/. Twój domyślny w jednym pliku, niestandardowy dla aplikacji w innym.
- Użyj plików zastępujących, aby edytować jednostki systemowe.
- Stwórz szablon wszystkich konfiguracji i uwzględnij je całkowicie; jeśli to możliwe, nie używaj sed ani jego analogów w podręcznikach
- Refaktoryzacja kodu systemu zarządzania konfiguracją:
- Podziel zadania na logiczne jednostki i przepisz monolit na role
- Używaj lintersów! Ansible-lint, yaml-lint itp
- Zmień swoje podejście! Nie do zdarcia. Konieczne jest opisanie stanu systemu
- Dla wszystkich ról Ansible musisz raz dziennie pisać testy w cząsteczce i generować raporty.
- W naszym przypadku po przygotowaniu testów (jest ich ponad 100) wykryto około 70000 XNUMX błędów. Naprawa tego zajęła kilka miesięcy.
Nasza realizacja
Tak więc role ansible były gotowe, szablonowe i sprawdzone przez lintersa. Wszędzie hoduje się nawet głupki. Jednak kwestia niezawodnego dostarczania kodu do różnych segmentów pozostała otwarta. Zdecydowaliśmy się na synchronizację ze skryptami. Na to wygląda:
Po nadejściu zmiany uruchamiany jest CI, tworzony jest serwer testowy, wdrażane są role i testowane przez cząsteczkę. Jeśli wszystko jest w porządku, kod trafia do gałęzi prod. Ale nie stosujemy nowego kodu do istniejących serwerów w maszynie. Jest to rodzaj zatyczki niezbędnej dla wysokiej dostępności naszych systemów. A kiedy infrastruktura staje się ogromna, w grę wchodzi prawo wielkich liczb – nawet jeśli masz pewność, że zmiana jest nieszkodliwa, może to prowadzić do tragicznych konsekwencji.
Istnieje również wiele opcji tworzenia serwerów. Skończyło się na wyborze niestandardowych skryptów w języku Python. A dla CI ansible:
- name: create1.yml - Create a VM from a template
vmware_guest:
hostname: "{{datacenter}}".domain.ru
username: "{{ username_vc }}"
password: "{{ password_vc }}"
validate_certs: no
cluster: "{{cluster}}"
datacenter: "{{datacenter}}"
name: "{{ name }}"
state: poweredon
folder: "/{{folder}}"
template: "{{template}}"
customization:
hostname: "{{ name }}"
domain: domain.ru
dns_servers:
- "{{ ipa1_dns }}"
- "{{ ipa2_dns }}"
networks:
- name: "{{ network }}"
type: static
ip: "{{ip}}"
netmask: "{{netmask}}"
gateway: "{{gateway}}"
wake_on_lan: True
start_connected: True
allow_guest_control: True
wait_for_ip_address: yes
disk:
- size_gb: 1
type: thin
datastore: "{{datastore}}"
- size_gb: 20
type: thin
datastore: "{{datastore}}"Do tego doszliśmy, system nadal żyje i rozwija się.
- 17 Role Ansible do konfiguracji serwera. Każda z ról przeznaczona jest do rozwiązywania odrębnego zadania logicznego (logowanie, audyt, autoryzacja użytkowników, monitorowanie itp.).
- Testowanie roli. Cząsteczka + TestInfra.
- Opracowanie własne: CMDB + Orchestrator.
- Czas utworzenia serwera wynosi ~30 minut, jest zautomatyzowany i praktycznie niezależny od kolejki zadań.
- Ten sam stan/nazewnictwo infrastruktury we wszystkich segmentach – playbooki, repozytoria, elementy wirtualizacji.
- Codzienna kontrola stanu serwera z generowaniem raportów o niezgodnościach ze standardem.
Mam nadzieję, że moja historia przyda się tym, którzy są na początku swojej drogi. Jakiego stosu automatyzacji używasz?
Źródło: www.habr.com