As jo IT-ynfrastruktuer te fluch groeit, sille jo ier of letter foar in kar stean: lineêr fergrutsje fan minsklike middels om it te stypjen of automatisearring te begjinnen. Oant op in stuit libbe wy yn it earste paradigma, en doe begon it lange paad nei Infrastructure-as-Code.
Fansels is NSPK gjin startup, mar sa'n sfear hearske yn it bedriuw yn de earste jierren fan syn bestean, en dat wiene tige nijsgjirrige jierren. Ik hyt , Ik haw stipe foar Linux-ynfrastruktuer mei hege beskikbere easken foar mear as 10 jier. Hy kaam yn jannewaris 2016 by it NSPK-team en seach spitigernôch it begjin fan it bestean fan it bedriuw net, mar kaam yn in stadium fan grutte feroaringen.
Yn 't algemien kinne wy sizze dat ús team 2 produkten foar it bedriuw leveret. De earste is ynfrastruktuer. Mail moat wurkje, DNS moat wurkje, en domeincontrollers moatte jo yn servers litte dy't net moatte crashe. It IT-lânskip fan it bedriuw is enoarm! Dit binne bedriuws- en missykrityske systemen, de beskikberenseasken foar guon binne 99,999. It twadde produkt is de servers sels, fysyk en firtueel. Besteande moatte wurde kontrolearre, en nije moatte geregeld wurde levere oan klanten út in protte ôfdielings. Yn dit artikel wol ik rjochtsje op hoe't wy de ynfrastruktuer ûntwikkele hawwe dy't ferantwurdlik is foar de libbenssyklus fan 'e server.
Start fan 'e reis
Oan it begjin fan ús reis seach ús technologystap der sa út:
OS CentOS 7
FreeIPA Domain Controllers
Automatisearring - Ansible (+Toer), Cobbler
Dit alles wie yn 3-domeinen, ferspraat oer ferskate datasintra. Yn ien datasintrum binne d'r kantoarsystemen en testsites, yn 'e rest is d'r PROD.
Servers oanmeitsje op ien punt seach der sa út:
Yn it VM-sjabloan is CentOS minimaal en it fereaske minimum is lykas de juste /etc/resolv.conf, de rest komt fia Ansible.
CMDB - Excel.
As de tsjinner fysyk is, dan ynstee fan it kopiearjen fan 'e firtuele masine, waard it OS derop ynstalleare mei Cobbler - de MAC-adressen fan' e doeltsjinner wurde tafoege oan 'e Cobbler-konfiguraasje, de tsjinner krijt in IP-adres fia DHCP, en dan it OS wurdt tafoege.
Earst hawwe wy sels besocht in soarte fan konfiguraasjebehear te dwaan yn Cobbler. Mar yn 'e rin fan' e tiid begon dit problemen te bringen mei de portabiliteit fan konfiguraasjes sawol nei oare datasintra as nei de Ansible-koade foar it tarieden fan VM's.
Op dat stuit, in protte fan ús ûnderfûn Ansible as in handige útwreiding fan Bash en net besparje op ûntwerpen mei help fan shell en sed. Overall Bashsible. Dit late úteinlik ta it feit dat as it playbook om ien of oare reden net op 'e server wurke, it makliker wie om de server te wiskjen, it playbook te reparearjen en it opnij út te fieren. D'r wie yn wêzen gjin ferzje fan skripts, gjin portabiliteit fan konfiguraasjes.
Wy woenen bygelyks wat konfiguraasje feroarje op alle servers:
- Wy feroarje de konfiguraasje op besteande tsjinners yn de logyske segment / data sintrum. Soms net yn ien dei - tagonklikheidseasken en de wet fan grutte oantallen litte net alle wizigingen tagelyk tapasse. En guon feroarings binne potinsjeel destruktyf en fereaskje it opnij begjinnen fan wat - fan tsjinsten oant it OS sels.
- Fixearje it yn Ansible
- Wy reparearje it yn Cobbler
- Werhelje N kear foar elke logyske segmint / datacenter
Om alle feroarings soepel te gean, wie it nedich om rekken te hâlden mei in protte faktoaren, en feroaringen komme konstant.
- Refactoring ansible koade, konfiguraasje triemmen
- Feroarje ynterne best practices
- Feroarings basearre op de resultaten fan analyze fan ynsidinten / ûngemakken
- Feroarje feiligens noarmen, sawol ynterne as eksterne. Bygelyks, PCI DSS wurdt bywurke mei nije easken alle jierren
Ynfrastruktuer groei en it begjin fan 'e reis
It oantal servers/logyske domeinen/datasintra groeide, en dêrmei it oantal flaters yn konfiguraasjes. Op in stuit kamen wy by trije rjochtingen wêryn konfiguraasjebehear ûntwikkele wurde moat:
- Automatisearring. Minske flaters yn repetitive operaasjes moatte safolle mooglik foarkommen wurde.
- Repeatabiliteit. It is folle makliker om ynfrastruktuer te behearjen as it foarsisber is. De konfiguraasje fan servers en ark foar har tarieding moat oeral itselde wêze. Dit is ek wichtich foar produktteams - nei testen moat de applikaasje garandearre wurde te einigjen yn in produksjeomjouwing dy't fergelykber is konfigureare as de testomjouwing.
- Ienfâld en transparânsje fan feroarings oan konfiguraasjebehear.
It bliuwt om in pear ark ta te foegjen.
Wy keas GitLab CE as ús koade repository, net yn it minst foar syn ynboude CI / CD modules.
Vault of secrets - Hashicorp Vault, incl. foar de grutte API.
Testen fan konfiguraasjes en mooglike rollen - Molecule + Testinfra. Tests gean folle flugger as jo ferbine mei ansible mitogen. Tagelyk begûnen wy ús eigen CMDB en orkestrator te skriuwen foar automatyske ynset (op 'e foto boppe Cobbler), mar dit is in folslein oar ferhaal, dat myn kollega en de haadûntwikkelder fan dizze systemen yn 'e takomst sille fertelle.
Us kar:
Molecule + Testinfra
Ansible + Tower + AWX
World of Servers + DITNET (Eigen ûntwikkeling)
Skoeier
Gitlab + GitLab runner
Hashicorp Vault
Trouwens, oer oanwêzige rollen. Yn it earstoan wie d'r mar ien, mar nei ferskate refactorings wiene d'r 17. Ik advisearje sterk om de monolyt te brekken yn idempotinte rollen, dy't dan apart kinne wurde lansearre; boppedat kinne jo tags tafoegje. Wy hawwe de rollen ferdield troch funksjonaliteit - netwurk, logging, pakketten, hardware, molekule ensfh. Yn 't algemien folgen wy de strategy hjirûnder. Ik stean der net op dat dit de ienige wierheid is, mar it wurke foar ús.
- Servers kopiearje fan 'e "gouden ôfbylding" is kwea!It wichtichste neidiel is dat jo net krekt witte yn hokker steat de ôfbyldings no binne, en dat alle feroarings komme nei alle ôfbyldings yn alle virtualisaasjebuorkerijen.
- Brûk standert konfiguraasje triemmen ta in minimum en iens mei oare ôfdielings dat jo binne ferantwurdlik foar de wichtichste systeem triemmenbygelyks:
- Lit /etc/sysctl.conf leech litte, de ynstellings moatte allinich yn /etc/sysctl.d/ wêze. Jo standert yn ien bestân, oanpast foar de applikaasje yn in oar.
- Brûk oerskriuwbestannen om systemd-ienheden te bewurkjen.
- Sjabloan alle konfiguraasjes en befetsje se folslein; as it mooglik is, gjin sed of syn analogen yn playbooks
- Refactoring fan de konfiguraasjebehearsysteemkoade:
- Brek taken op yn logyske entiteiten en skriuw de monolith yn rollen
- Brûk linters! Ansible-lint, yaml-lint, ensfh
- Feroarje jo oanpak! Gjin bashsible. It is needsaaklik om de steat fan it systeem te beskriuwen
- Foar alle Ansible rollen moatte jo tests skriuwe yn molekule en ien kear deis rapporten generearje.
- Yn ús gefal, nei it tarieden fan de tests (dêr't der mear as 100 fan binne), binne der sa'n 70000 flaters fûn. It duorre ferskate moannen om it te reparearjen.
Us útfiering
Dat, de oanwêzige rollen wiene klear, sjabloan en kontrolearre troch linters. En sels gits wurde oeral grutbrocht. Mar de fraach fan betroubere levering fan koade oan ferskate segminten bleau iepen. Wy besletten om te syngronisearjen mei skripts. It liket sa:
Nei't de feroaring oankomt, wurdt CI lansearre, in testtsjinner wurdt makke, rollen wurde útrôle en testen troch de molekule. As alles goed is, giet de koade nei de prod branch. Mar wy tapasse gjin nije koade op besteande tsjinners yn 'e masine. Dit is in soarte fan stopper dy't nedich is foar hege beskikberens fan ús systemen. En as de ynfrastruktuer enoarm wurdt, komt de wet fan grutte oantallen yn spiel - sels as jo der wis fan binne dat de feroaring harmless is, kin it liede ta skriklike gefolgen.
D'r binne ek in protte opsjes foar it meitsjen fan servers. Wy hawwe úteinlik keazen foar oanpaste Python-skripts. En foar 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 wêr't wy ta kommen binne, it systeem bliuwt libje en ûntwikkelje.
- 17 Ansible rollen foar it ynstellen fan de tsjinner. Elk fan 'e rollen is ûntworpen om in aparte logyske taak op te lossen (logge, kontrôle, brûkersautorisaasje, tafersjoch, ensfh.).
- Roltesten. Molecule + TestInfra.
- Eigen ûntwikkeling: CMDB + Orchestrator.
- Tsjinner oanmeitsjen tiid is ~ 30 minuten, automatisearre en praktysk ûnôfhinklik fan de taak wachtrige.
- Deselde steat / nammejouwing fan 'e ynfrastruktuer yn alle segminten - playbooks, repositories, virtualisaasje-eleminten.
- Deistich kontrôle fan serverstatus mei generearjen fan rapporten oer ôfwikingen mei de standert.
Ik hoopje dat myn ferhaal nuttich sil wêze foar dyjingen dy't oan it begjin fan har reis binne. Hokker automatisearringstack brûke jo?
Boarne: www.habr.com