Ger binesaziya IT-ya we pir zû mezin bibe, hûn ê zû an dereng bi vebijarkek re rû bi rû bimînin: bi rêkûpêk çavkaniyên mirovî zêde bikin da ku wê piştgirî bikin an dest bi otomatîkkirinê bikin. Heya hin xalan, em di paradîgmaya yekem de dijiyan, û dûv re riya dirêj a binesaziya-as-Code dest pê kir.
Bê guman, NSPK ne destpêkek e, lê di salên pêşîn ên hebûna xwe de atmosferek wusa di pargîdaniyê de hukum kir û ew salên pir balkêş bûn. Navê min , Zêdetirî 10 sal in ez binesaziya Linux-ê bi hewcedariyên hebûna bilind piştgirî dikim. Ew di Çile 2016 de beşdarî tîmê NSPK bû û, mixabin, destpêka hebûna pargîdaniyê nedît, lê hat qonaxek guhertinên mezin.
Bi gelemperî, em dikarin bêjin ku tîmê me 2 hilberan ji bo pargîdaniyê peyda dike. Ya yekem binesaziyê ye. Pêdivî ye ku e-name bixebite, DNS divê bixebite, û kontrolkerên domainê divê hûn bihêlin nav serverên ku nekevin. Pergala IT ya pargîdaniyê pir mezin e! Van pergalên krîtîk ên karsaziyê û mîsyonê ne, hewcedariyên hebûna hinan 99,999 in. Hilbera duyemîn server bixwe ne, fîzîkî û virtual. Pêdivî ye ku yên heyî bêne şopandin, û yên nû divê bi rêkûpêk ji xerîdarên ji gelek beşan re werin radest kirin. Di vê gotarê de ez dixwazim balê bikişînim ser ka me çawa binesaziya ku ji çerxa jiyana serverê berpirsiyar e pêş xist.
Destpêka rêwîtiyê
Di destpêka rêwîtiya me de, stûna teknolojiya me bi vî rengî xuya bû:
OS CentOS 7
Kontrolkerên Domainê yên FreeIPA
Otomasyon - Ansible (+ Tower), Cobbler
Hemî ev di 3 domanan de, li gelek navendên daneyê belav bûn. Di navendek daneyê de pergalên nivîsgehê û malperên ceribandinê hene, li yên mayî PROD hene.
Afirandina serveran di yek xalê de wiha xuya bû:
Di şablonê VM de, CentOS hindiktirîn e û hindiktirîna pêwîst mîna /etc/resolv.conf rast e, ya mayî bi Ansible ve tê.
CMDB - Excel.
Ger server fizîkî ye, wê hingê li şûna kopîkirina makîneya virtual, OS-ê bi karanîna Cobbler-ê li ser wê hate saz kirin - navnîşanên MAC-ên servera armanc li veavakirina Cobbler têne zêdekirin, server bi DHCP-ê navnîşek IP-yê distîne, û dûv re OS-ê. tê zêdekirin.
Di destpêkê de me tewra hewl da ku em di Cobbler de celebek rêveberiya vesazkirinê bikin. Lê bi demê re, vê yekê dest pê kir ku pirsgirêkên bi veguheztina mîhengan hem ji navendên daneyên din re û hem jî ji koda Ansible re ji bo amadekirina VM-an derxe.
Di wê demê de, gelek ji me Ansible wekî dirêjkirina hêsan a Bash-ê dihesiband û ji sêwiranên ku bi karanîna şêl û sed-ê bikar tînin guh nedan. Bi giştî Bashsible. Vê yekê di dawiyê de rê li ber vê yekê vekir ku ger pirtûka lîstikê ji ber hin sedeman li ser serverê nexebite, hêsantir bû ku serverê jê bibe, pirtûkê rast bike û wê dîsa bimeşîne. Di eslê xwe de guhertoya nivîsan, ne veguheztina mîhengan tune bû.
Mînakî, me xwest ku li ser hemî pêşkêşkeran hin mîhengan biguhezînin:
- Em veavakirina li ser pêşkêşkerên heyî yên di beşa mentiqî/navenda daneyê de diguhezînin. Carinan ne di yek rojê de - hewcedariyên gihîştinê û zagona hejmarên mezin nahêlin ku hemî guhertin bi yekcarî werin sepandin. Û hin guhertin potansiyel wêranker in û hewce ne ku tiştek ji nû ve bidin destpêkirin - ji karûbaran heya OS-ê bixwe.
- Di Ansible de rastkirin
- Em wê di Cobbler de rast bikin
- Ji bo her beşa mentiqî / navenda daneyê N caran dubare bikin
Ji bo ku hemî guhertin bi rêkûpêk bimeşin, hewce bû ku gelek faktor li ber çavan bihata girtin, û guhertin bi berdewamî çêdibin.
- Refaktorkirina koda ansible, pelên vesazkirinê
- Guhertina pratîkên çêtirîn ên navxweyî
- Guhertinên li ser bingeha encamên analîza bûyeran / qezayan
- Guhertina standardên ewlehiyê, hem hundur hem jî derveyî. Mînakî, PCI DSS her sal bi hewcedariyên nû tê nûve kirin
Mezinbûna binesaziyê û destpêka rêwîtiyê
Hejmara pêşkêşker / domainên mantiqî / navendên daneyê zêde bû, û bi wan re jî hejmara xeletiyên di veavakirinê de zêde bû. Di hin xalan de, em gihîştin sê rêgezên ku tê de pêdivî ye ku rêveberiya veavakirinê were pêşve xistin:
- Otomatîkî. Çewtiya mirovî ya di operasyonên dubarekirî de divê bi qasî ku pêkan were dûr xistin.
- Repeatability. Gava ku ew pêşbîn be, birêvebirina binesaziyê pir hêsantir e. Veavakirina server û amûrên ji bo amadekirina wan divê li her deverê yek be. Ev ji bo tîmên hilberê jî girîng e - piştî ceribandinê, pêdivî ye ku serîlêdan were garantî kirin ku di hawîrdorek hilberînê de ku bi hawîrdora ceribandinê ve hatî mîheng kirin.
- Sadebûn û zelaliya guherandinan di rêveberiya vesazkirinê de.
Ew dimîne ku meriv çend amûran zêde bike.
Me GitLab CE wekî depoya koda xwe hilbijart, nexasim ji bo modulên wê yên CI/CD-yê çêkirî.
Vault of razber - Hashicorp Vault, di nav de. ji bo API-ya mezin.
Veavakirinên ceribandinê û rolên berbiçav - Molecule + Testinfra. Ger hûn bi mîtojenê asîmîle ve girêdin ceribandin pir zûtir diçin. Di heman demê de, me dest bi nivîsandina CMDB û orkestratorê xwe ji bo bicîhkirina otomatîkî (di wêneya jorîn Cobbler de) kir, lê ev çîrokek bi tevahî cûda ye, ku hevkarê min û pêşdebirê sereke yê van pergalan dê di pêşerojê de vebêje.
Hilbijartina me:
Molekul + Testinfra
Ansible + Tower + AWX
World of Servers + DITNET (Pêşveçûna xwe)
Cobêr
Gitlab + GitLab runner
Hashicorp Vault
Bi awayê, li ser rolên berbiçav. Di destpêkê de tenê yek hebû, lê piştî çend vesazkirinan 17 ji wan hebûn, ez bi tundî pêşniyar dikim ku yekdestiyê bixin nav rolên bêhêz, ku dûv re dikarin ji hev veqetînin, hûn dikarin etîketan lê zêde bikin. Me rol ji hêla fonksiyonê ve dabeş kir - tora, têketin, pakêt, hardware, molekul hwd. Bi gelemperî, me stratejiya jêrîn şopand. Ez israr nakim ku ev tenê rastî ye, lê ew ji me re xebitî.
- Kopîkirina serverên ji "wêneya zêrîn" xirab e!Kêmasiya sereke ev e ku hûn bi rastî nizanin wêne di çi rewşê de ne, û ku hemî guhertin dê li hemî wêneyan di hemî zeviyên virtualîzasyonê de werin.
- Pelên mîhengê yên xwerû bi kêmanî bikar bînin û bi beşên din re bipejirînin ku hûn ji pelên pergalê yên sereke berpirsiyar in, wek nimûne:
- /etc/sysctl.conf vala bihêlin, divê mîheng tenê di /etc/sysctl.d/ de bin. Pêşniyara we di pelek de, ji bo serîlêdanê di pelek din de xwerû.
- Pelên binavkirî bikar bînin da ku yekîneyên pergalê biguherînin.
- Hemî konfigurasyonan şablon bikin û heke gengaz be, di pirtûkên lîstikê de sed an analogên wê tune
- Refaktorkirina koda pergala rêveberiya vesazkirinê:
- Karûbaran li hebûnên mentiqî veqetînin û monolîtê di rolan de ji nû ve binivîsin
- Linderan bikar bînin! Ansible-lint, yaml-lint, hwd
- Nêzîkatiya xwe biguherînin! Ne şêlandin. Pêwîst e rewşa sîstemê were vegotin
- Ji bo hemî rolên Ansible hûn hewce ne ku di molekulê de ceribandinan binivîsin û rojê carekê raporan çêbikin.
- Di rewşa me de, piştî amadekirina testan (yên ku ji 100î zêdetir in), nêzî 70000 xeletî hatin dîtin. Ji bo sererastkirina wê çend meh derbas bûn.
Pêkanîna me
Ji ber vê yekê, rolên bêkêmasî amade bûn, şablon û ji hêla lîberan ve hatin kontrol kirin. Û tewra git li her derê bilind dibin. Lê pirsa radestkirina koda pêbawer ji beşên cûda re vekirî ma. Me biryar da ku em bi senaryoyan re hevdeng bikin. Wisa xuya dike:
Piştî ku guhertin tê, CI tê destpêkirin, serverek ceribandinê tê afirandin, rol têne avêtin, û ji hêla molekulê ve têne ceribandin. Ger her tişt baş be, kod diçe şaxê prod. Lê em koda nû li ser serverên heyî yên di makîneyê de bicîh nakin. Ev celebek rawestgehek e ku ji bo hebûna bilind a pergalên me hewce ye. Û gava ku binesaziyek mezin dibe, qanûna hejmarên mezin tê lîstin - her çend hûn pê ewle bin ku guhertin bê zirar e, ew dikare bibe sedema encamên xirab.
Ji bo afirandina serveran jî gelek vebijark hene. Me dawî li bijarteyên xwerû yên Python anî. Û ji bo 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}}"Tişta ku em hatine vê yekê ye, pergal jiyana xwe didomîne û pêş dikeve.
- 17 Ji bo sazkirina serverê rolên berbiçav. Her yek ji rolan ji bo çareserkirina peywirek mentiqî ya cihêreng (têketin, vedîtin, destûrnameya bikarhêner, şopandin, hwd.) hatî çêkirin.
- Testkirina rola. Molekul + TestInfra.
- Pêşveçûna xwe: CMDB + Orkestrator.
- Dema afirandina serverê ~ 30 hûrdem e, otomatîk û bi pratîkî ji rêza peywirê serbixwe ye.
- Di hemî beşan de heman rewş / navê binesaziyê - pirtûkên lîstikê, depo, hêmanên virtualbûnê.
- Kontrolkirina rojane ya rewşa serverê bi hilberîna raporên li ser nakokiyên bi standard re.
Ez hêvî dikim ku çîroka min ji bo kesên ku di destpêka rêwîtiya xwe de ne bikêr be. Hûn çi staka otomatîkê bikar tînin?
Source: www.habr.com