Nëse infrastruktura juaj IT po rritet shumë shpejt, një ditë do të përballeni me zgjedhjen - të rritni në mënyrë lineare burimet njerëzore për mbështetje ose të filloni automatizimin. Deri në një pikë, ne e kemi jetuar paradigmën e parë, dhe pastaj filloi një rrugë e gjatë drejt Infrastructure-as-Code.
Sigurisht, NSPK nuk është një startup, por një atmosferë e tillë ka mbizotëruar në kompani vitet e para të ekzistencës, dhe këto ishin shumë vite interesante. Emri im është , më shumë se 10 vjet kam mbështetur infrastrukturën Linux me kërkesa të larta për disponueshmëri. Kam mishëruar ekipit NSPK në janar 2016 dhe, fatkeqësisht, nuk isha prezent në fillimin e ekzistencës së kompanisë, por erdha në një fazë të ndryshimeve të mëdha.
Në përgjithësi, mund të thuhet se ekipi ynë ofron për kompaninë 2 produkte. E para - infrastruktura. E-mail duhet të funksionojë, DNS të operojë, dhe kontrolluesit e domenit të lejojnë qasjen në serverët, të cilët nuk duhet të mbeten jashtë funksioni. Peizazhi IT i kompanisë është i madh! Këto janë sisteme të rëndësishme për biznesin dhe misionin, me kërkesa për disponueshmëri disa prej tyre - 99,999. Produkti i dytë - vetë serverët, fizikë dhe virtualë. Duhet të kujdesemi për ato ekzistuese, ndërsa të reja duhet të ofrohen rregullisht për klientët nga shumë divizione. Në këtë artikull dua të theksoj se si ne zhvilluam infrastrukturën, e cila është përgjegjëse për ciklin e jetës. servera.
Fillimi i rrugës
Në fillim të rrugës, steku ynë i teknologjisë dukej kështu:
OS CentOS 7
Kontrolluesit e domenit FreeIPA
Automatizimi - Ansible(+Tower), Cobbler
E gjithë kjo ishte e shpërndarë në 3 domain, të shtrira në disa qendra të të dhënave. Në një qendër të të dhënave - sistemet zyrtare dhe poligonet testuese, ndërsa në të tjerat PROD.
Krijimi i serverëve në një moment dukej kështu:
Në shabllonin VM CentOS minimal dhe minimumin e nevojshëm siç është një /etc/resolv.conf i saktë, e gjithë pjesa tjetër vjen përmes Ansible.
CMDB - Excel.
Nëse serveri është fizik, atëherë në vend të kopjimit të makinës virtuale mbi të instalohej OS me ndihmën e Cobbler - në konfigurimin e Cobbler shtohen adresat MAC të serverit të synuar, serveri merr adresën IP përmes DHCP, dhe më pas instalohet OS.
Fillimisht ne madje përpiqeshim të bënim ndonjë menaxhim konfiguracionesh në Cobbler. Por me kalimin e kohës, kjo filloi të sillte probleme me portabilitetin e konfigurimeve si në qendrat e tjera të të dhënave ashtu edhe në kodin Ansible për përgatitjen e VM-ve.
Ansible në atë kohë shumë prej nesh e perceptonin si një zgjerim të rehatshëm të Bash dhe nuk ishim të kursyer mbi ndërtimet që përdorin shell, sed. Në përgjithësi, Bashsible. Kjo në fund sillte në fakt se, nëse një playbook për ndonjë arsye nuk punonte në server, ishte më e lehtë të fshije serverin, të riparosh playbook-un dhe ta drejtoje përsëri. Nuk kishte ndonjë versionim të skenareve, në thelb, as portabilitet të konfigurimeve.
Për shembull, ne dëshiruam të ndryshonim ndonjë konfigurim në të gjithë serverët:
- Ndryshojmë konfigurimin në serverët ekzistues në segmentin logjik/qendrat e të dhënave. Ndonjëherë jo për një ditë - kërkesat për disponueshmëri dhe ligji i numrave të mëdhenj nuk lejojnë zbatimin e të gjithë ndryshimeve njëherësh. Disa ndryshime janë potencialisht shkatërruese dhe kërkojnë rinisjen e diçkaje - nga shërbimet deri te vetë OS.
- Korrigjojmë në Ansible
- Korrigjojmë në Cobbler
- Përsërisim N herë për çdo segment logjik/qendrat e të dhënave
Për që të gjitha ndryshimet të kalojnë pa probleme, duhet të merret parasysh shumë faktorë, ndërsa ndryshimet ndodhin vazhdimisht.
- Rrjedha e kodit anbil dhe skedarëve të konfigurimit
- Ndryshimi i praktikave më të mira të brendshme
- Ndryshimet nga analiza e incidenteve/aksidenteve
- Ndryshimi i standartëve të sigurisë, si të brendshme ashtu edhe të jashtme. Për shembull, PCI DSS çdo vit plotësohet me kërkesa të reja
Rritja e infrastrukturës dhe fillimi i rrugës
Numri i serverëve/domainëve logjikë/qendrave të të dhënave po rritej, dhe me ta shfaqeshin gjithashtu numri i gabimeve në konfigurime. Në një moment ne arritëm në tri drejtime, drejt të cilave duhej zhvilluar menaxhimi i konfigurimeve:
- Automatizimi. Sa më shumë të jetë e mundur, duhet shmangur faktori njeri në operacionet e përsëritura.
- Përsëritshmëria. Të menaxhosh infrastrukturën është shumë më e lehtë kur ajo është e parashikueshme. Konfigurimi i serverëve dhe mjeteve për përgatitjen e tyre duhet të jetë gjithandej i njëjtë. Kjo është gjithashtu e rëndësishme për ekipet produktive - aplikacioni duhet garantuar pas testimit që të kalojë në ambientin produktiv, i konfiguruar njësoj si testi.
- Thjeshtësia dhe transparenca në bërjen e ndryshimeve në menaxhimin e konfigurimeve.
Ishte e nevojshme të shtonim disa mjete.
Si depo për kodin zgjodhëm GitLab CE, jo në vend të fundit për shkak të moduleve të integruara CI/CD.
Depo për sekretet - Hashicorp Vault, gjithashtu për shkak të API-së së shkëlqyeshme.
Testimi i konfigurations dhe ansible rolëve – Molecule+Testinfra. Testet zhvillohen shumë më shpejt nëse lidhni mitogen me ansible. Paralelisht, kemi filluar të shkruajmë CMDB tonë dhe orkestruesin për deploy automatik (në imazh mbi Cobbler), por kjo është një histori krejt tjetër, për të cilin në të ardhmen do të flasë kolegu im dhe zhvilluesi kryesor i këtyre sistemeve.
Zgjedhja jonë:
Molecule + Testinfra
Ansible + Tower + AWX
Bota e Serverëve + DITNET (Zhvillim i brendshëm)
Cobbler
Gitlab + GitLab runner
Hashicorp Vault
Dhe për ansible rolët. Fillimisht kishte një, pas disa refaktorizimeve janë bërë 17. Rekomandoj kategorikisht të ndahen monolitët në role idempotente, të cilat mund të çiklohen më vonë veçmas, mund të shtoni etiketa gjithashtu. Ne ndamë rolet sipas funksionalitetit – network, logging, packages, hardware, molecule etj. Përndryshe, kemi ndjekur strategjinë e mëposhtme. Nuk insistoj që kjo është e vetmja e vërtetë, por për ne e ka funksionuar.
- Kopjimi i serverëve nga 'imazhi i artë' është një e keqe!Nga mangësitë kryesore – ju nuk e dini ndonjëherë se në çfarë gjendje janë imazhet aktualisht, dhe se çdo ndryshim do të shkojë në të gjitha imazhet në të gjitha fermat e virtualizimit.
- Përdorni skedarët e konfigurimit në minimum dhe dakordoni me njësitë e tjera që ju jeni përgjegjës për skedarët e sistemit kryesor., për shembull:
- Lëreni /etc/sysctl.conf bosh, konfigurimet duhet të jenë vetëm në /etc/sysctl.d/. Default-i juaj në një skedar, personalizimi për aplikacionin në një tjetër.
- Përdorni skedarë override për redaktimin e njësive systemd.
- Bëni skemë të gjitha konfigurimet dhe vendosni ato tërësisht, sa më shumë që të jetë e mundur, pa asnjë sed dhe të ngjashme në playbook.
- Duke refaktorizuar kodin e sistemit të menaxhimit të konfigurimeve:
- Ndani detyrat në entitete logjike dhe ripërkufizoni monolit në role.
- Përdorni linters! Ansible-lint, yaml-lint, etj.
- Ndryshoni qasjen! Pa bashsible. Duhet të përshkruani gjendjen e sistemit.
- Për të gjitha rolet Ansible duhet të shkruhen teste në molecule dhe çdo ditë të gjenerohen raportet.
- Në rastin tonë, pas përgatitjes së testeve (të cilat ishin më shumë se 100) u gjetën rreth 70000 gabime. Kemi korrigjuar për disa muaj.
Implementimi ynë
Pra, rolet ansible ishin gati, të skemuar dhe të verifikuara me linters. Dhe madje git-ët u ngritën në të gjitha anët. Por çështja e dorëzimit të sigurt të kodit në segmente të ndryshme mbeti e hapur. Vendosëm të sinkronizojmë me skriptet. Duket kështu:
Pas mbërritjes së ndryshimit, aktivizohet CI, krijohet një server testimi, skenohen rolet, testohet me molecule. Nëse gjithçka është në rregull, kodi shkon në degën prodhuese. Por ne nuk e aplikojmë kodin e ri automatikisht në serverët ekzistues. Kjo është një lloj ndalese, që është e nevojshme për disponueshmërinë e lartë të sistemeve tona. Dhe kur infrastruktura bëhet e madhe, hyn në lojë ligji i numrave të mëdhenj – madje edhe nëse jeni të sigurt se ndryshimi është i padëmshëm, ai mund të çojë në pasojat të pakëndshme.
Ka shumë mundësi për krijimin e serverëve. Ne, përfundimisht, zgjodhëm skriptet e personalizuara në Python. Dhe për CI ansible:
- name: create1.yml - Krijoni një VM nga një 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 ku kemi mbërritur, sistemi vazhdon të jetojë dhe të zhvillohet.
- 17 ansible-rolësh për konfigurimin e serverit. Çdo rol është i dedikuar për të zgjidhur një detyrë logjike të veçantë (logimi, auditi, autorizimi i përdoruesve, monitorimi, etj.).
- Testimi i rolëve. Molecule + TestInfra.
- Zhvillim i brendshëm: CMDB + Orkestrues.
- Koha e krijimit të serverit ~30 minuta, automatizuar dhe pothuajse nuk varet nga radhët e detyrave.
- Gjashtë të njëjta e të emërtimit të infrastrukturës në të gjitha segmentet – playbook, repository, elemente virtualizimi.
- Kontroll i përditshëm i gjendjes së serverëve me gjenerimin e raporteve për diferencat me standardet.
Shpresoj që historia ime të jetë e dobishme për ata që janë në fillim të rrugës. Cili është steki i automatizimit që përdorni ju?
Burimi: habr.com
