Als uw IT-infrastructuur te snel groeit, komt u vroeg of laat voor de keuze te staan: lineair de personele middelen uitbreiden om deze te ondersteunen, of beginnen met automatisering. Tot een bepaald punt leefden we in het eerste paradigma, en toen begon het lange pad naar Infrastructure-as-Code.
Natuurlijk is NSPK geen startup, maar zo'n sfeer heerste in het bedrijf in de eerste jaren van zijn bestaan, en dat waren zeer interessante jaren. Mijn naam is , Ik ondersteun al meer dan 10 jaar de Linux-infrastructuur met hoge beschikbaarheidsvereisten. Hij kwam in januari 2016 bij het NSPK-team en maakte helaas niet het allereerste begin van het bestaan van het bedrijf mee, maar kwam in een fase van grote veranderingen.
Over het algemeen kunnen we stellen dat ons team 2 producten levert voor het bedrijf. De eerste is infrastructuur. Mail zou moeten werken, DNS zou moeten werken en domeincontrollers zouden je toegang moeten geven tot servers die niet mogen crashen. Het IT-landschap van het bedrijf is enorm! Dit zijn bedrijfs- en bedrijfskritische systemen, de beschikbaarheidsvereisten voor sommige zijn 99,999. Het tweede product zijn de servers zelf, fysiek en virtueel. Bestaande moeten worden gemonitord en nieuwe moeten regelmatig worden geleverd aan klanten vanuit vele afdelingen. In dit artikel wil ik me concentreren op hoe we de infrastructuur hebben ontwikkeld die verantwoordelijk is voor de levenscyclus van de server.
Begin van een reis
Aan het begin van onze reis zag onze technologiestapel er als volgt uit:
Besturingssysteem CentOS 7
GratisIPA-domeincontrollers
Automatisering - Ansible(+Tower), Schoenmaker
Dit alles bevond zich in 3 domeinen, verspreid over verschillende datacenters. In het ene datacenter staan kantoorsystemen en testlocaties, in de rest is PROD.
Het maken van servers zag er op een gegeven moment als volgt uit:
In de VM-sjabloon is CentOS minimaal en het vereiste minimum is als het juiste /etc/resolv.conf, de rest komt via Ansible.
CMDB-Excel.
Als de server fysiek is, is het besturingssysteem daarop geïnstalleerd met Cobbler, in plaats van de virtuele machine te kopiëren. De MAC-adressen van de doelserver worden toegevoegd aan de Cobbler-configuratie, de server ontvangt een IP-adres via DHCP en vervolgens het besturingssysteem is toegevoegd.
In eerste instantie probeerden we zelfs een soort configuratiebeheer in Cobbler te doen. Maar na verloop van tijd begon dit problemen te veroorzaken met de overdraagbaarheid van configuraties, zowel naar andere datacenters als met de Ansible-code voor het voorbereiden van VM's.
In die tijd zagen velen van ons Ansible als een handige uitbreiding van Bash en beknibbelen niet op ontwerpen met behulp van shell en sed. Over het algemeen Bashsible. Dit leidde er uiteindelijk toe dat als het draaiboek om de een of andere reden niet werkte op de server, het gemakkelijker was om de server te verwijderen, het draaiboek te repareren en het opnieuw uit te voeren. Er was in wezen geen versiebeheer van scripts, geen overdraagbaarheid van configuraties.
We wilden bijvoorbeeld een configuratie op alle servers wijzigen:
- Wij wijzigen de configuratie op bestaande servers in het logische segment/datacenter. Soms niet in één dag. De toegankelijkheidseisen en de wet van de grote aantallen staan niet toe dat alle wijzigingen in één keer worden toegepast. En sommige veranderingen zijn potentieel destructief en vereisen dat er iets opnieuw moet worden opgestart - van services tot het besturingssysteem zelf.
- Het probleem wordt opgelost in Ansible
- Wij repareren het in Cobbler
- Herhaal N keer voor elk logisch segment/datacenter
Om alle veranderingen soepel te laten verlopen, was het noodzakelijk om rekening te houden met veel factoren, en er vinden voortdurend veranderingen plaats.
- Refactoring van anible-code, configuratiebestanden
- Het veranderen van interne best practices
- Wijzigingen op basis van de resultaten van de analyse van incidenten/ongevallen
- Veranderende beveiligingsnormen, zowel intern als extern. PCI DSS wordt bijvoorbeeld elk jaar bijgewerkt met nieuwe vereisten
Groei van de infrastructuur en het begin van de reis
Het aantal servers/logische domeinen/datacenters groeide, en daarmee ook het aantal fouten in configuraties. Op een gegeven moment kwamen we op drie richtingen waarin configuratiemanagement ontwikkeld moet worden:
- Automatisering. Menselijke fouten bij repetitieve handelingen moeten zoveel mogelijk worden vermeden.
- Herhaalbaarheid. Het is veel eenvoudiger om infrastructuur te beheren als deze voorspelbaar is. De configuratie van servers en tools voor hun voorbereiding moet overal hetzelfde zijn. Ook voor productteams is dit belangrijk: na het testen moet de applicatie gegarandeerd in een productieomgeving terechtkomen die vergelijkbaar is ingericht als de testomgeving.
- Eenvoud en transparantie bij het aanbrengen van wijzigingen in configuratiebeheer.
Er moeten nog een paar hulpmiddelen worden toegevoegd.
We kozen GitLab CE als onze coderepository, niet in de laatste plaats vanwege de ingebouwde CI/CD-modules.
Kluis der geheimen - Hashicorp kluis, incl. voor de geweldige API.
Configuraties en weerwerende rollen testen – Molecule+Testinfra. Tests gaan veel sneller als je verbinding maakt met ansible mitogeen. Tegelijkertijd begonnen we onze eigen CMDB en orkestrator te schrijven voor automatische implementatie (op de foto hierboven Cobbler), maar dit is een heel ander verhaal, dat mijn collega en de belangrijkste ontwikkelaar van deze systemen in de toekomst zal vertellen.
Onze keus:
Molecuul + Testinfra
Ansible + Toren + AWX
World of Servers + DITNET (Eigen ontwikkeling)
Schoenmaker
Gitlab + GitLab-loper
Hashicorp-kluis
Trouwens, over weerwortrollen. In eerste instantie was er maar één, maar na verschillende refactorings waren het er 17. Ik raad ten zeerste aan om de monoliet op te splitsen in idempotente rollen, die vervolgens afzonderlijk kunnen worden gestart; bovendien kun je tags toevoegen. We hebben de rollen verdeeld op basis van functionaliteit: netwerk, loggen, pakketten, hardware, moleculen enz. Over het algemeen volgden we de onderstaande strategie. Ik beweer niet dat dit de enige waarheid is, maar het werkte voor ons.
- Het kopiëren van servers van het “gouden beeld” is slecht!Het grootste nadeel is dat je niet precies weet in welke staat de afbeeldingen zich nu bevinden, en dat alle wijzigingen zullen plaatsvinden op alle afbeeldingen in alle virtualisatiefarms.
- Gebruik standaard configuratiebestanden tot een minimum en spreek met andere afdelingen af dat jij verantwoordelijk bent voor de hoofdsysteembestanden, bijvoorbeeld:
- Laat /etc/sysctl.conf leeg, de instellingen mogen alleen in /etc/sysctl.d/ staan. Uw standaard in het ene bestand, aangepast voor de toepassing in een ander bestand.
- Gebruik overschrijvingsbestanden om systeemeenheden te bewerken.
- Maak een sjabloon van alle configuraties en neem ze volledig op; indien mogelijk geen sed of zijn analogen in draaiboeken
- Herstructurering van de configuratiebeheersysteemcode:
- Breek taken op in logische entiteiten en herschrijf de monoliet in rollen
- Gebruik linters! Ansible-lint, yaml-lint, enz
- Verander uw aanpak! Geen bashsible. Het is noodzakelijk om de toestand van het systeem te beschrijven
- Voor alle Ansible-rollen moet je tests in moleculen schrijven en één keer per dag rapporten genereren.
- In ons geval werden na het voorbereiden van de tests (waarvan er meer dan 100 zijn) ongeveer 70000 fouten gevonden. Het duurde enkele maanden om het te repareren.
Onze implementatie
De weerwortrollen waren dus klaar, gesjabloneerd en gecontroleerd door linters. En zelfs gits worden overal gekweekt. Maar de kwestie van betrouwbare codelevering aan verschillende segmenten bleef open. We besloten om te synchroniseren met scripts. Ziet eruit als:
Nadat de wijziging is doorgevoerd, wordt CI gelanceerd, wordt een testserver gemaakt, worden rollen uitgerold en door het molecuul getest. Als alles in orde is, gaat de code naar de prod-tak. Maar we passen geen nieuwe code toe op bestaande servers in de machine. Dit is een soort stop die nodig is voor een hoge beschikbaarheid van onze systemen. En wanneer de infrastructuur gigantisch wordt, gaat de wet van de grote aantallen een rol spelen. Zelfs als je er zeker van bent dat de verandering onschadelijk is, kan deze tot ernstige gevolgen leiden.
Er zijn ook veel opties voor het maken van servers. Uiteindelijk hebben we gekozen voor aangepaste Python-scripts. En voor 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}}"Dit is waar we naartoe zijn gekomen: het systeem blijft leven en ontwikkelen.
- 17 Ansible-rollen voor het instellen van de server. Elk van de rollen is ontworpen om een afzonderlijke logische taak op te lossen (logboekregistratie, auditing, gebruikersautorisatie, monitoring, enz.).
- Rol testen. Molecuul + TestInfra.
- Eigen ontwikkeling: CMDB + Orchestrator.
- De aanmaaktijd van de server bedraagt ~30 minuten, geautomatiseerd en vrijwel onafhankelijk van de takenwachtrij.
- Dezelfde status/naamgeving van de infrastructuur in alle segmenten: playbooks, repositories, virtualisatie-elementen.
- Dagelijkse controle van de serverstatus met het genereren van rapporten over afwijkingen met de standaard.
Ik hoop dat mijn verhaal nuttig zal zijn voor degenen die aan het begin van hun reis staan. Welke automatiseringsstack gebruik je?
Bron: www.habr.com