As jou IT-infrastruktuur te vinnig groei, sal jy vroeër of later voor 'n keuse te staan kom – verhoog menslike hulpbronne lineêr om dit te ondersteun of begin outomatiseer. Tot op 'n stadium het ons in die eerste paradigma geleef, en toe het 'n lang reis na Infrastruktuur-as-kode begin.
Natuurlik is NSPK nie 'n begin nie, maar so 'n atmosfeer het in die eerste jare van sy bestaan in die maatskappy geheers, en dit was baie interessante jare. My naam is , Ek onderhou al meer as 10 jaar 'n Linux-infrastruktuur met hoë beskikbaarheidsvereistes. Hy het in Januarie 2016 by die NSPK-span aangesluit en het ongelukkig nie die heel begin van die maatskappy se bestaan gesien nie, maar het in 'n stadium van groot veranderinge gekom.
Oor die algemeen kan ons sê dat ons span 2 produkte vir die maatskappy verskaf. Die eerste is infrastruktuur. E-pos moet weggaan, DNS moet werk, en domeinbeheerders moet jou inlaat by bedieners wat nie moet val nie. Die maatskappy se IT-landskap is groot! Dit is sake- en missiekritieke stelsels, die toeganklikheidsvereistes vir sommige is 99,999 XNUMX. Die tweede produk is die bedieners self, fisies en virtueel. Bestaandes moet gemonitor word, en nuwes moet gereeld aan kliënte van baie departemente afgelewer word. In hierdie artikel wil ek fokus op hoe ons die infrastruktuur ontwikkel het wat verantwoordelik is vir die lewensiklus van bedieners.
Die begin van die pad
Aan die begin van die reis het ons tegnologiestapel soos volg gelyk:
OS CentOS 7
FreeIPA-domeinbeheerders
Outomatisering - Ansible(+Toring), Skoenmaker
Dit alles was geleë in 3 domeine versprei oor verskeie datasentrums. In een datasentrum - kantoorstelsels en toetswebwerwe, in die res - PROD.
Die skep van bedieners het een of ander tyd so gelyk:
Die CentOS VM-sjabloon is minimaal en die minimum is korrek /etc/resolv.conf, die res kom via Ansible.
CMDB - Excel.
As die bediener fisies is, dan is die bedryfstelsel, in plaas daarvan om die virtuele masjien te kopieer, daarop geïnstalleer met behulp van Cobbler - die MAC-adresse van die teikenbediener word by die Cobbler-konfigurasie gevoeg, die bediener ontvang 'n IP-adres via DHCP, en dan die bedryfstelsel word geskink.
Aanvanklik het ons selfs probeer om 'n soort konfigurasiebestuur in Cobbler te doen. Maar met verloop van tyd het dit probleme begin bring met die oordraagbaarheid van konfigurasies, beide na ander datasentrums en na Ansible-kode vir die voorbereiding van 'n VM.
Ansible op daardie tydstip is deur baie van ons as 'n gerieflike Bash-uitbreiding beskou en het nie gespaar op konstrukte met behulp van die dop, sed. In die algemeen, Bashsible. Dit het uiteindelik daartoe gelei dat as die speelboek om een of ander rede nie op die bediener gewerk het nie, dit makliker was om die bediener uit te vee, die speelboek reg te maak en dit weer te rol. Trouens, daar was geen weergawe van skrifte nie, ook oordraagbaarheid van konfigurasies.
Ons wou byvoorbeeld 'n paar konfigurasie op alle bedieners verander:
- Ons verander die konfigurasie op bestaande bedieners in die logiese segment / datasentrum. Soms nie op een dag nie - beskikbaarheidsvereistes en die wet van groot getalle laat jou nie toe om alle veranderinge gelyktydig toe te pas nie. En sommige veranderinge is potensieel vernietigend en vereis 'n herbegin van enigiets - van dienste tot die bedryfstelsel self.
- Regstelling in Ansible
- Regmaak in Cobbler
- Herhaal N keer vir elke logiese segment/datasentrum
Om al die veranderinge glad te laat verloop, moes baie faktore in ag geneem word, en veranderinge gebeur heeltyd.
- Refaktorering van moontlike kode, konfigurasielêers
- Verandering van interne beste praktyke
- Veranderinge na die ontleding van voorvalle/ongelukke
- Veranderende sekuriteitstandaarde, beide intern en ekstern. Byvoorbeeld, PCI DSS word elke jaar opgedateer met nuwe vereistes.
Die groei van infrastruktuur en die begin van die reis
Die aantal bedieners / logiese domeine / datasentrums het gegroei, en daarmee saam die aantal foute in die konfigurasies. Op 'n stadium het ons by drie rigtings gekom in die rigting waarvan ons konfigurasiebestuur moet ontwikkel:
- Outomatisering. Menslike foute in herhalende operasies moet sover moontlik vermy word.
- Herhaalbaarheid. Infrastruktuur is baie makliker om te bestuur wanneer dit voorspelbaar is. Die opstelling van bedieners en gereedskap vir hul voorbereiding moet oral dieselfde wees. Dit is ook belangrik vir produkspanne - na toetsing moet die toepassing gewaarborg word om in 'n produktiewe omgewing te kom wat soortgelyk is aan die toets een.
- Eenvoud en deursigtigheid van veranderinge in konfigurasiebestuur.
Dit bly om 'n paar gereedskap by te voeg.
Ons het GitLab CE as ons kodebewaarplek gekies, nie die minste vir sy ingeboude CI/CD-modules nie.
Vault of secrets - Hashicorp Vault, inkl. vir die groot API.
Toets konfigurasies en moontlike rolle - Molecule+Testinfra. Toetse gaan baie vinniger as jy aan moontlike mitogen koppel. Terselfdertyd het ons ons eie CMDB en 'n orkeseerder vir outomatiese ontplooiing begin skryf (foto bo Cobbler), maar dit is 'n heeltemal ander storie, waarvan my kollega en die hoofontwikkelaar van hierdie stelsels in die toekoms sal vertel.
Ons keuse:
Molekule + Testinfra
Ansible + Toring + AWX
World of Servers + DITNET (eie ontwikkeling)
skoenmaker
Gitlab + GitLab hardloper
Hashicorp Vault
Terloops, oor moontlike rolle. Aanvanklik was dit alleen, na verskeie herfaktorerings was daar 17. Ek beveel sterk aan om die monoliet in idempotente rolle op te breek, wat dan afsonderlik uitgevoer kan word, jy kan addisioneel etikette byvoeg. Ons het die rolle volgens funksionaliteit verdeel - netwerk, logboek, pakkette, hardeware, molekule ens. In die algemeen, voldoen aan die strategie hieronder. Ek dring nie daarop aan dat dit in 'n enkele geval die waarheid is nie, maar dit het vir ons gewerk.
- Om bedieners van die goue beeld af te kopieer, is boos!Van die belangrikste nadele - jy weet nie presies in watter toestand die beelde nou is nie, en dat alle veranderinge na alle beelde in alle virtualisasieplase sal kom.
- Hou verstekkonfigurasielêers tot 'n minimum en kom ooreen met ander departemente dat jy verantwoordelik is vir die hoofstelsellêers, byvoorbeeld:
- Laat /etc/sysctl.conf leeg, instellings moet slegs in /etc/sysctl.d/ wees. Jou verstek in een lêer, pasgemaak vir die toepassing in 'n ander.
- Gebruik ignoreer lêers om systemd eenhede te wysig.
- Sjabloon alle konfigurasies en plaas dit in hul geheel, indien moontlik, geen sed en sy analoë in speelboeke
- Herfaktorering van die konfigurasiebestuurstelselkode:
- Verdeel take in logiese entiteite en herskryf die monoliet in rolle
- Gebruik linters! Ansible-pluis, yaml-lint, ens
- Verander jou benadering! Geen bashible. Beskryf die toestand van die stelsel
- Vir alle Ansible-rolle moet jy toetse in molekule skryf en een keer per dag verslae genereer.
- In ons geval, na die voorbereiding van die toetse (waarvan daar meer as 100 is), is ongeveer 70000 XNUMX foute gevind. Vasgestel vir 'n paar maande.
Ons implementering
So, die moontlike rolle was gereed, sjabloon en deur linters nagegaan. En selfs die gits word oral opgehef. Maar die kwessie van betroubare kode-aflewering aan verskillende segmente het oop gebly. Ons het besluit om met skrifte te sinchroniseer. Lyk so:
Nadat die verandering aangebreek het, word CI geloods, 'n toetsbediener word geskep, rolle word gerol, getoets deur die molekule. As alles in orde is, gaan die kode na die pro-tak. Maar ons pas nie outomaties nuwe kode op bestaande bedieners toe nie. Dit is 'n soort stop, wat nodig is vir die hoë beskikbaarheid van ons stelsels. En wanneer die infrastruktuur groot word, kom die wet van groot getalle ter sprake – al is jy seker dat die verandering skadeloos is, kan dit tot hartseer gevolge lei.
Daar is ook baie opsies om bedieners te skep. Ons het uiteindelik pasgemaakte luislangskrifte gekies. En vir 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 waartoe ons gekom het, die stelsel bly leef en ontwikkel.
- 17 moontlike rolle vir die opstel van 'n bediener. Elkeen van die rolle is ontwerp om 'n aparte logiese taak op te los (logboek, ouditering, gebruikersmagtiging, monitering, ens.).
- Roltoetsing. Molekule + Toets Infra.
- Eie ontwikkeling: CMDB + Orchestrator.
- Die bedienerskeppingstyd is ~30 minute, dit is outomaties en hang feitlik nie af van die taakwaglys nie.
- Dieselfde toestand / benaming van die infrastruktuur in alle segmente - speelboeke, bewaarplekke, virtualisasie-elemente.
- Daaglikse kontrolering van die status van bedieners met die generering van verslae oor teenstrydighede met die standaard.
Ek hoop my storie sal nuttig wees vir diegene wat aan die begin van die reis is. Watter outomatiseringstapel gebruik jy?
Bron: will.com