Nëse infrastruktura juaj e TI-së rritet shumë shpejt, herët a vonë do të përballeni me një zgjedhje: të rrisni në mënyrë lineare burimet njerëzore për ta mbështetur atë ose të filloni automatizimin. Deri në një moment, ne jetuam në paradigmën e parë, dhe më pas filloi rruga e gjatë drejt Infrastrukturës-as-Code.
Sigurisht, NSPK nuk është një startup, por një atmosferë e tillë mbretëroi në kompani në vitet e para të ekzistencës së saj, dhe ato ishin vite shumë interesante. Unë quhem , Unë kam mbështetur infrastrukturën Linux me kërkesa të larta disponueshmërie për më shumë se 10 vjet. Ai iu bashkua ekipit të NSPK në janar 2016 dhe, për fat të keq, nuk e pa fillimin e ekzistencës së kompanisë, por erdhi në një fazë ndryshimesh të mëdha.
Në përgjithësi, mund të themi se ekipi ynë furnizon 2 produkte për kompaninë. E para është infrastruktura. Posta duhet të funksionojë, DNS duhet të funksionojë dhe kontrolluesit e domenit duhet t'ju lejojnë të hyni në serverë që nuk duhet të prishen. Peizazhi IT i kompanisë është i madh! Këto janë sisteme kritike të biznesit dhe misionit, kërkesat e disponueshmërisë për disa janë 99,999. Produkti i dytë janë vetë serverët, fizikë dhe virtualë. Ato ekzistuese duhet të monitorohen dhe të rejat duhet t'u dorëzohen rregullisht klientëve nga shumë departamente. Në këtë artikull dua të fokusohem në mënyrën se si kemi zhvilluar infrastrukturën që është përgjegjëse për ciklin e jetës së serverit.
Fillimi i një udhëtimi
Në fillim të udhëtimit tonë, grupi ynë i teknologjisë dukej kështu:
OS CentOS 7
Kontrollorët e domenit FreeIPA
Automatizimi - Ansible(+Kulla), Këpucër
E gjithë kjo ishte e vendosur në 3 domene, të shpërndara në disa qendra të të dhënave. Në një qendër të dhënash ka sisteme zyre dhe vende testimi, në pjesën tjetër ka PROD.
Krijimi i serverëve në një moment dukej kështu:
Në shabllonin VM, CentOS është minimal dhe minimumi i kërkuar është si /etc/resolv.conf i saktë, pjesa tjetër vjen përmes Ansible.
CMDB - Excel.
Nëse serveri është fizik, atëherë në vend që të kopjoni makinën virtuale, OS u instalua në të duke përdorur Cobbler - adresat MAC të serverit të synuar shtohen në konfigurimin Cobbler, serveri merr një adresë IP përmes DHCP, dhe më pas OS shtohet.
Në fillim madje u përpoqëm të bënim një lloj menaxhimi të konfigurimit në Cobbler. Por me kalimin e kohës, kjo filloi të sjellë probleme me transportueshmërinë e konfigurimeve si në qendrat e tjera të të dhënave ashtu edhe në kodin Ansible për përgatitjen e VM-ve.
Në atë kohë, shumë prej nesh e perceptuan Ansible si një zgjatim të përshtatshëm të Bash dhe nuk kursenim në dizajne duke përdorur guaskë dhe sed. Në përgjithësi Bashsible. Kjo përfundimisht çoi në faktin se nëse libri i luajtjes për ndonjë arsye nuk funksionoi në server, ishte më e lehtë të fshish serverin, të rregulloje librin e luajtjes dhe ta ekzekutosh përsëri. Në thelb nuk kishte asnjë versionim të skripteve, asnjë transportueshmëri të konfigurimeve.
Për shembull, ne donim të ndryshonim disa konfigurime në të gjithë serverët:
- Ne ndryshojmë konfigurimin në serverët ekzistues në segmentin logjik / qendrën e të dhënave. Ndonjëherë jo në një ditë - kërkesat e aksesueshmërisë dhe ligji i numrave të mëdhenj nuk lejojnë që të gjitha ndryshimet të zbatohen menjëherë. Dhe disa ndryshime janë potencialisht shkatërruese dhe kërkojnë rifillimin e diçkaje - nga shërbimet në vetë OS.
- Rregullimi i tij në Ansible
- E rregullojmë në Këpucër
- Përsëriteni N herë për çdo segment logjik/qendër të dhënash
Në mënyrë që të gjitha ndryshimet të shkonin pa probleme, ishte e nevojshme të merren parasysh shumë faktorë dhe ndryshimet ndodhin vazhdimisht.
- Rifaktorimi i kodit të përgjithshëm, skedarëve të konfigurimit
- Ndryshimi i praktikave më të mira të brendshme
- Ndryshimet në bazë të rezultateve të analizës së incidenteve/aksidenteve
- Ndryshimi i standardeve të sigurisë, të brendshme dhe të jashtme. Për shembull, PCI DSS përditësohet me kërkesa të reja çdo vit
Rritja e infrastrukturës dhe fillimi i udhëtimit
Numri i serverëve/domeneve logjike/qendrave të të dhënave u rrit dhe bashkë me to edhe numri i gabimeve në konfigurime. Në një moment, arritëm në tre drejtime në të cilat duhet të zhvillohet menaxhimi i konfigurimit:
- Automatizimi. Gabimet njerëzore në operacionet e përsëritura duhet të shmangen sa më shumë që të jetë e mundur.
- Përsëritshmëria. Është shumë më e lehtë të menaxhosh infrastrukturën kur është e parashikueshme. Konfigurimi i serverëve dhe mjeteve për përgatitjen e tyre duhet të jetë i njëjtë kudo. Kjo është gjithashtu e rëndësishme për ekipet e produkteve - pas testimit, aplikacioni duhet të garantohet që të përfundojë në një mjedis prodhimi të konfiguruar në mënyrë të ngjashme me mjedisin e testimit.
- Thjeshtësia dhe transparenca e bërjes së ndryshimeve në menaxhimin e konfigurimit.
Mbetet për të shtuar disa mjete.
Ne zgjodhëm GitLab CE si depon tonë të kodit, jo më pak për modulet e tij të integruara CI/CD.
Kasaforta e sekreteve - Hashicorp Vault, përfshirë. për API-në e madhe.
Testimi i konfiguracioneve dhe roleve të mundshme – Molecule+Testinfra. Testet shkojnë shumë më shpejt nëse lidheni me mitogjen të paanshëm. Në të njëjtën kohë, ne filluam të shkruajmë CMDB dhe orkestruesin tonë për vendosjen automatike (në foton sipër Cobbler), por kjo është një histori krejtësisht e ndryshme, të cilën kolegu im dhe zhvilluesi kryesor i këtyre sistemeve do të tregojë në të ardhmen.
Zgjedhja jonë:
Molekula + Testinfra
Ansible + Kulla + AWX
World of Servers + DITNET (Zhvillimi vetanak)
këpucar
Gitlab + GitLab vrapues
Hashicorp Vault
Meqë ra fjala, për rolet e duhura. Në fillim ishte vetëm një, por pas disa rifaktorimeve ishin 17. Unë rekomandoj fuqimisht ndarjen e monolitit në role idempotente, të cilat më pas mund të lansohen veçmas; përveç kësaj, mund të shtoni etiketa. Ne i ndamë rolet sipas funksionalitetit - rrjeti, regjistrimi, paketat, pajisjet, molekulat etj. Në përgjithësi, ne kemi ndjekur strategjinë e mëposhtme. Unë nuk insistoj se kjo është e vetmja e vërtetë, por na funksionoi.
- Kopjimi i serverëve nga "imazhi i artë" është i keq!Disavantazhi kryesor është se ju nuk e dini saktësisht se në çfarë gjendje janë imazhet tani, dhe se të gjitha ndryshimet do të vijnë në të gjitha imazhet në të gjitha fermat e virtualizimit.
- Përdorni skedarët e konfigurimit të paracaktuar në minimum dhe pajtohuni me departamentet e tjera që jeni përgjegjës për skedarët kryesorë të sistemit, për shembull:
- Lëreni /etc/sysctl.conf bosh, cilësimet duhet të jenë vetëm në /etc/sysctl.d/. Parazgjedhja juaj në një skedar, e personalizuar për aplikacionin në një tjetër.
- Përdorni skedarë anashkalues për të modifikuar njësitë e sistemit.
- Modeloni të gjitha konfigurimet dhe përfshini ato tërësisht; nëse është e mundur, pa sed ose analoge të tij në librat e lojërave
- Rifaktorimi i kodit të sistemit të menaxhimit të konfigurimit:
- Ndani detyrat në entitete logjike dhe rishkruani monolitin në role
- Përdorni linja! Ansible-lint, yaml-lint etj
- Ndryshoni qasjen tuaj! Asnjë turp. Është e nevojshme të përshkruhet gjendja e sistemit
- Për të gjitha rolet e Ansible ju duhet të shkruani teste në molekulë dhe të gjeneroni raporte një herë në ditë.
- Në rastin tonë, pas përgatitjes së testeve (nga të cilat janë më shumë se 100), u gjetën rreth 70000 gabime. U deshën disa muaj për ta rregulluar atë.
Zbatimi ynë
Pra, rolet e dukshme ishin të gatshme, të modeluara dhe të kontrolluara me linja. Dhe madje edhe gits janë ngritur kudo. Por çështja e dërgimit të besueshëm të kodit në segmente të ndryshme mbeti e hapur. Ne vendosëm të sinkronizonim me skriptet. Duket kështu:
Pasi të arrijë ndryshimi, CI lëshohet, krijohet një server testimi, rolet hapen dhe testohen nga molekula. Nëse gjithçka është në rregull, kodi shkon në degën prod. Por ne nuk aplikojmë kod të ri në serverët ekzistues në makinë. Ky është një lloj tape që është i nevojshëm për disponueshmërinë e lartë të sistemeve tona. Dhe kur infrastruktura bëhet e madhe, ligji i numrave të mëdhenj hyn në lojë - edhe nëse jeni i sigurt se ndryshimi është i padëmshëm, ai mund të çojë në pasoja të tmerrshme.
Ekzistojnë gjithashtu shumë opsione për krijimin e serverëve. Ne përfunduam duke zgjedhur skriptet e personalizuara Python. Dhe për ansiblen CI:
- 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}}"Kjo është ajo që ne kemi ardhur, sistemi vazhdon të jetojë dhe të zhvillohet.
- 17 Role të mundshme për konfigurimin e serverit. Secili prej roleve është krijuar për të zgjidhur një detyrë të veçantë logjike (logimi, auditimi, autorizimi i përdoruesit, monitorimi, etj.).
- Testimi i roleve. Molekula + TestInfra.
- Zhvillimi i vet: CMDB + Orkestruesi.
- Koha e krijimit të serverit është ~30 minuta, e automatizuar dhe praktikisht e pavarur nga radha e detyrave.
- Gjendja/emërtimi i njëjtë i infrastrukturës në të gjitha segmentet - librat e lojërave, depot, elementët e virtualizimit.
- Kontrolli ditor i statusit të serverit me gjenerimin e raporteve për mospërputhjet me standardin.
Shpresoj se historia ime do të jetë e dobishme për ata që janë në fillim të udhëtimit të tyre. Çfarë grupi automatizimi përdorni?
Burimi: www.habr.com