NĂ«se infrastruktura juaj IT po rritet shumĂ« shpejt, pĂ«r njĂ« moment ose tjetĂ«r do tĂ« pĂ«rballeni me zgjedhjen â tĂ« rrisni burimet njerĂ«zore pĂ«r mbĂ«shtetje linjare ose tĂ« filloni automatizimin. Deri nĂ« njĂ« farĂ« momenti, ne jetuam nĂ« parimin e parĂ«, dhe pastaj filloi njĂ« rrugĂ« e gjatĂ« drejt Infrastructure-as-Code.
Natyrisht, NSPK nuk është një startup, por një atmosferë e tillë mbizotëronte në kompani në vitet e para të ekzistencës së saj, dhe ato ishin vite shumë interesante. Më quajnë , për më shumë se 10 vjet mbështes infrastrukturën Linux me kërkesa të larta për disponueshmëri. I kam bashkuar ekipit të NSPK në janar 2016, dhe fatkeqësisht nuk e kam përjetuar fillimin e ekzistencës së kompanisë, por kam ardhur në një fazë të madhe ndryshimi.
Në përgjithësi, mund të themi se ekipi ynë ofron dy produkte për kompaninë. E para është infrastruktura. Posta duhet të funksionojë, DNS të punojë, dhe kontrolluesit e domainit duhet të ju lejojnë të hyni në serverat që nuk duhet të bien. Peizazhi IT i kompanisë është i madh! Këto janë sisteme kritike për biznesin dhe misionin, kërkesat për disponueshmërinë e disa prej tyre janë 99,999. Produkti i dytë janë vetë serverat, fizikë dhe virtualë. Duhet të monitorojmë ata ekzistues, dhe të sjellim rregullisht të rinj nga shumë njesi. Në këtë artikull dua të theksoj se si zhvilluam infrastrukturën që përgjigjet për ciklin e jetës. serverësh.
Fillimi i rrugës
Në fillim të rrugës, stoku ynë i teknologjisë dukej kështu:
OS CentOS 7
Kontrollues të domainit FreeIPA
Automatizimi â Ansible(+Tower), Cobbler
E gjitha kjo ishte e vendosur në 3 domain, të shpërndara në disa DC. Në një DC ndodheshin sistemet zyrtare dhe poligonet testuese, 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 një /etc/resolv.conf të saktë, pjesa tjetër vjen përmes Ansible.
CMDB â Excel.
NĂ«se serveri Ă«shtĂ« fizik, atĂ«herĂ« nĂ« vend tĂ« kopjimit tĂ« makinĂ«s virtuale, OS instalohej me ndihmĂ«n e Cobbler â nĂ« konfigurimin e Cobbler shtohen adresat MAC tĂ« serverit tĂ« synuar, ŃĐ”ŃĐČĐ”ŃĐž merr njĂ« adresĂ« IP pĂ«rmes DHCP-sĂ«, dhe pastaj instalon sistemin operativ.
Në fillim përpiqeshim të bënim ndonjë menaxhim konfigurimi në Cobbler. Por me kalimin e kohës, kjo filloi të sillte probleme me portabilitetin e konfigurimeve si në DC të tjerë ashtu edhe në kodin Ansible për përgatitjen e VM.
Ansible në atë kohë shumë prej nesh e përjetonin si një zgjerim të lehtë të Bash dhe nuk kursenim në ndërtimet me përdorimin e shell, sed. Në përgjithësi Bashsible. Kjo në fund sillte në atë që, nëse playbook-u për ndonjë arsye nuk funksiononte në server, ishte më e lehtë të fshije serverin, të rregulloje playbook-un dhe ta riktheje atë përsëri. Nuk kishte përfundimisht versionim të skripteve, as përshkueshmëria e konfigurimeve.
Për shembull, ne dëshiruam të ndryshonim një konfigurim në të gjitha serverat:
- NdryshojmĂ« konfigurimin nĂ« serverat ekzistues nĂ« segmentin logjik/CPD. NdonjĂ«herĂ« jo brenda njĂ« dite â kĂ«rkesat pĂ«r disponueshmĂ«ri dhe ligji i numrave tĂ« mĂ«dhenj nuk lejojnĂ« pĂ«rdorimin e tĂ« gjitha ndryshimeve njĂ«herĂ«sh. Disa ndryshime janĂ« potencialisht destruktive dhe kĂ«rkojnĂ« ripĂ«rshtatjen e diçkaje â nga shĂ«rbimet deri te vetĂ« sistemi operativ.
- Rregullojmë në Ansible
- Rregullojmë në Cobbler
- Përsërisim N herë për çdo segment logjik/CPD
Për të bërë që të gjitha ndryshimet të kalojnë pa probleme, ishte e nevojshme të merreshin parasysh shumë faktorë, dhe ndryshimet ndodhin vazhdimisht.
- Rikonstruksioni i kodit ansible, skedarëve të konfigurimit
- Ndryshimi i praktikave më të mira të brendshme
- Ndryshimet si rezultat i analizës së incidenteve/aksidenteve
- Ndryshimi i standardeve të sigurisë, si të brendshme ashtu edhe të jashtme. Për shembull, PCI DSS përditësohet çdo vit me kërkesa të reja
Rritja e infrastrukturës dhe fillimi i udhëtimit
Numri i serverëve/domainave logjikë/CPD rritej, ashtu si numri i gabimeve në konfigurime. Në një moment të caktuar arritëm në tre drejtime, në drejtim të të cilave duhet të zhvillojmë menaxhimin e konfigurimeve:
- Automatizimi. Sa më shumë që të jetë e mundur, duhet të shmangim faktorët njerëzorë në operacione të përsëritura.
- Përsëritshmëria. Të menaxhosh infrastrukturën është shumë më e lehtë kur është e parashikueshme. Konfigurimi i serverëve dhe mjeteve për përgatitjen e tyre duhet të jetë kudo njësoj. Kjo është po aq e rëndësishme për ekipet produktive - aplikacioni duhet me siguri pas testimit të kalojë në mjedisin prodhues, i konfiguruar në mënyrë të ngjashme me testimin.
- Thjeshtësia dhe transparenca e ndryshimeve në menaxhimin e konfigurimeve.
Mbetet të shtojmë disa mjete.
Si një depo kodin ne zgjodhëm GitLab CE, jo në radhë të vogël për shkak të pranisë së moduleve të integruara CI/CD.
Depoja e sekretëve - Hashicorp Vault, po ashtu për shkak të API-së së mrekullueshme.
Testimi i konfigurimeve dhe roleve ansible â Molecule + Testinfra. Testet shkojnĂ« shumĂ« mĂ« shpejt nĂ«se e lidhni ansible me mitogen. PĂ«rveç kĂ«saj, filluam tĂ« shkruajmĂ« njĂ« CMDB tĂ« vetĂ«n dhe njĂ« orkestrator pĂ«r implementimin automatike (nĂ« imazh mbi Cobbler), por kjo Ă«shtĂ« njĂ« histori krejt tjetĂ«r, pĂ«r tĂ« cilĂ«n nĂ« tĂ« ardhmen do tĂ« flasĂ« kolegu im dhe kryeprogramuesi 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
PĂ«r rolet ansible. Fillimisht ishte vetĂ«m njĂ«, pas disa refaktorimeve u bĂ«nĂ« 17. Rekomandoj me ngulm ndarjen e monolitit nĂ« role idempotente, tĂ« cilat mund tĂ« ekzekutohen veçmas, dhe mund tĂ« shtoni etiketa. Ne i ndamĂ« rolet sipas funksionalitetit â rrjeti, regjistrimi, paketat, hardware, molecule etj. E pĂ«rgjithshmja, ndoqĂ«m strategjinĂ« mĂ« poshtĂ«. Nuk po insistoj se kjo Ă«shtĂ« e vĂ«rteta universale, por pĂ«r ne funksionoi.
- Kopjimi i serverĂ«ve nga "imazhi i artĂ«" â e keqe!Nga disavantazhet kryesore â nuk e dini me siguri nĂ« çfarĂ« gjendjeje janĂ« imazhet tani, dhe se tĂ« gjitha ndryshimet do tĂ« vijnĂ« nĂ« tĂ« gjitha imazhet nĂ« tĂ« gjitha fermat e virtualizimit.
- Përdorni skedarë konfigurimi default sa më pak që të jetë e mundur dhe rregulloni me njësitë e tjera që për skedarët kryesorë sistematikë përgjigjeni ju., për shembull:
- Lëreni /etc/sysctl.conf bosh, konfigurimet duhet të qëndrojnë vetëm në /etc/sysctl.d/. Defaulti juaj në një skedar, personalizimi për aplikacionin në një tjetër.
- Përdorni skedarë override për redaktimin e njësive systemd.
- Templatezoni të gjitha konfigurimet dhe ngjiteni në tërësi, sa më shumë që të jetë e mundur, pa sed dhe analoget e tij në playbook.
- Duke refaktorizuar kodin e sistemit të menaxhimit të konfigurimeve:
- Ndani detyrat në entitete logjike dhe rishkruani monolitin në role.
- PĂ«rdorni linters! Ansible-lint, yaml-lint, etj.
- Ndryshoni qasjen! Asnjë bashsible. Duhet të përshkruani gjendjen e sistemit.
- Për të gjitha rolet Ansible duhet të shkruani teste në molecule dhe një herë në ditë të gjeneroni raporte.
- Në rastin tonë, pas përgatitjes së testeve (më shumë se 100), u gjetën rreth 70000 gabime. Korrigjimi mori disa muaj.
Implementimi ynë
Pra, rolet ansible ishin të gatshme, të templatezura dhe të verifikuara nga linters. Edhe gitët ishin ngritur në çdo vend. Por pyetja për dorëzimin e sigurt të kodit në segmente të ndryshme mbeti e hapur. Vendosëm të sinkronizojmë me skriptet. Duket kështu:
Pas pas azhurnuar e ndryshimi, CI fillon, krijohet njĂ« server testues, rrotullohen rolet, dhe testohet me molekulĂ«n. NĂ«se gjithçka Ă«shtĂ« nĂ« rregull, kodi shkon nĂ« degĂ«n e prodhimit. Por ne nuk aplikojmĂ« kodin e ri nĂ« serverĂ«t ekzistues automatikisht. 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, hyjnĂ« gjithashtu ligjet e numrave tĂ« mĂ«dhenj â edhe nĂ«se jeni tĂ« sigurt se ndryshimi Ă«shtĂ« i padĂ«mshĂ«m, ai mund tĂ« sjellĂ« pasoja tĂ« hidhura.
Ka shumë mënyra për të krijuar serverë. Ne përfundimisht zgjedhim skriptet e personalizuara në Python. Dhe për CI, ansible:
- emri: create1.yml - Krijo një VM nga një templatë
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}}"Ky është rezultati ynë, sistemi vazhdon të jetojë dhe të zhvillohet.
- 17 rolet ansible pĂ«r konfigurimin e serverit. Ădo rol Ă«shtĂ« i dedikuar pĂ«r zgjidhjen e njĂ« detyre logjike tĂ« veçantĂ« (shtimi i logeve, auditimi, autorizimi i pĂ«rdoruesve, monitorimi, etj.).
- Testimi i roleve. Molecule + TestInfra.
- Zhvillimi ynë i brendshëm: CMDB + Orkestruesi.
- Koha e krijimit të serverit është rreth 30 minuta, e automatizuar dhe praktikisht nuk varet nga radhët e detyrave.
- Gjendje/pĂ«rshkrim tĂ« njĂ«jtĂ« tĂ« infrastrukturĂ«s nĂ« tĂ« gjitha segmentet â playbook, depo, elemente virtualizimi.
- Kontroll i përditshëm i gjendjes së serverëve me gjenerimin e raportëve të diferencave nga standardi.
Shpresoj se rrëfimi im do të jetë i dobishëm për ata që janë në fillim të rrugës. Dhe çfarë grupi automatizimi po përdorni ju?
Burimi: habr.com
