Se via IT-infrastrukturo kreskas tro rapide, vi pli aŭ malpli frue alfrontos elekton: linie pliigi homajn rimedojn por subteni ĝin aŭ komenci aŭtomatigon. Ĝis iu punkto, ni vivis en la unua paradigmo, kaj tiam la longa vojo al Infrastrukturo-kiel-Kodo komenciĝis.
Kompreneble, NSPK ne estas starto, sed tia etoso regis en la kompanio en la unuaj jaroj de ĝia ekzisto, kaj tiuj estis tre interesaj jaroj. Mia nomo estas , Mi subtenas Linuksan infrastrukturon kun altaj haveblecaj postuloj dum pli ol 10 jaroj. Li aliĝis al la teamo de NSPK en januaro 2016 kaj, bedaŭrinde, ne vidis la komencon de la ekzisto de la kompanio, sed venis en etapo de grandaj ŝanĝoj.
Ĝenerale, ni povas diri, ke nia teamo provizas 2 produktojn por la kompanio. La unua estas infrastrukturo. Poŝto devus funkcii, DNS devus funkcii, kaj domajnaj regiloj devus enlasi vin en servilojn kiuj ne devus kraŝi. La IT-pejzaĝo de la kompanio estas grandega! Ĉi tiuj estas komercaj kaj misiaj kritikaj sistemoj, la haveblecaj postuloj por iuj estas 99,999. La dua produkto estas la serviloj mem, fizikaj kaj virtualaj. Ekzistantaj devas esti monitoritaj, kaj novaj devas esti regule liveritaj al klientoj de multaj fakoj. En ĉi tiu artikolo mi volas koncentriĝi pri kiel ni disvolvis la infrastrukturon, kiu respondecas pri la servila vivociklo.
La komenco de la vojo
Komence de nia vojaĝo, nia teknologia stako aspektis jene:
OS CentOS 7
FreeIPA Domajnregiloj
Aŭtomatigo - Ansible(+Tower), Cobbler
Ĉio ĉi situis en 3 domajnoj, disvastigitaj tra pluraj datumcentroj. En unu datumcentro estas oficejaj sistemoj kaj testejoj, en la ceteraj estas PROD.
Krei servilojn en unu momento aspektis jene:
En la ŝablono VM, CentOS estas minimuma kaj la bezonata minimumo estas kiel la ĝusta /etc/resolv.conf, la resto venas per Ansible.
CMDB - Excel.
Se la servilo estas fizika, tiam anstataŭ kopii la virtualan maŝinon, la OS estis instalita sur ĝi uzante Cobbler - la MAC-adresoj de la cela servilo estas aldonitaj al la Cobbler-agordo, la servilo ricevas IP-adreson per DHCP, kaj poste la OS. estas aldonita.
Komence ni eĉ provis fari ian agordan administradon en Cobbler. Sed kun la tempo, ĉi tio komencis alporti problemojn kun la porteblo de agordoj kaj al aliaj datumcentroj kaj al la Ansible-kodo por prepari VMs.
Tiutempe, multaj el ni perceptis Ansible kiel oportuna etendo de Bash kaj ne ŝparis pri dezajnoj uzante shell kaj sed. Ĝenerale Bashsible. Ĉi tio finfine kondukis al la fakto, ke se la ludlibro ial ne funkciis en la servilo, estis pli facile forigi la servilon, ripari la ludlibron kaj ruli ĝin denove. Ekzistis esence neniu versio de skriptoj, neniu porteblo de agordoj.
Ekzemple, ni volis ŝanĝi iujn agordojn en ĉiuj serviloj:
- Ni ŝanĝas la agordon sur ekzistantaj serviloj en la logika segmento/datumcentro. Kelkfoje ne en unu tago - alireblaj postuloj kaj la leĝo pri grandaj nombroj ne ebligas apliki ĉiujn ŝanĝojn samtempe. Kaj iuj ŝanĝoj estas eble detruaj kaj postulas rekomenci ion - de servoj ĝis la OS mem.
- Ripari ĝin en Ansible
- Ni riparas ĝin en Cobbler
- Ripetu N fojojn por ĉiu logika segmento/datumcentro
Por ke ĉiuj ŝanĝoj iru glate, estis necese konsideri multajn faktorojn, kaj ŝanĝoj okazas konstante.
- Refactoring ansible kodo, agordaj dosieroj
- Ŝanĝante internajn plej bonajn praktikojn
- Ŝanĝoj bazitaj sur la rezultoj de analizo de okazaĵoj/akcidentoj
- Ŝanĝante sekurecnormojn, kaj internajn kaj eksterajn. Ekzemple, PCI DSS estas ĝisdatigita kun novaj postuloj ĉiujare
Infrastruktura kresko kaj la komenco de la vojaĝo
La nombro da serviloj/logikaj domajnoj/datumcentroj kreskis, kaj kun ili la nombro da eraroj en agordoj. Iam ni venis al tri direktoj en kiuj agorda administrado devas esti evoluigita:
- Aŭtomatigo. Homa eraro en ripetaj operacioj devus esti evitita kiel eble plej multe.
- Ripeteblo. Estas multe pli facile administri infrastrukturon kiam ĝi estas antaŭvidebla. La agordo de serviloj kaj iloj por ilia preparado devus esti la sama ĉie. Ĉi tio ankaŭ estas grava por produktteamoj - post testado, la aplikaĵo devas esti garantiita finiĝi en produktadmedio agordita simile al la testa medio.
- Simpleco kaj travidebleco fari ŝanĝojn al agorda administrado.
Restas aldoni kelkajn ilojn.
Ni elektis GitLab CE kiel nian koddeponejon, ne laste pro ĝiaj enkonstruitaj CI/KD-moduloj.
Volbo de sekretoj - Hashicorp Vault, inkl. por la bonega API.
Testado de agordoj kaj aneblaj roloj - Molecule+Testinfra. Testoj iras multe pli rapide se vi konektas al ansible mitogeno. Samtempe, ni komencis verki nian propran CMDB kaj orkestratoro por aŭtomata deplojo (en la bildo supre Cobbler), sed ĉi tio estas tute alia historio, kiun mia kolego kaj la ĉefa programisto de ĉi tiuj sistemoj rakontos estonte.
Nia elekto:
Molekulo + Testinfra
Ansible + Turo + AWX
Mondo de Serviloj + DITNET (Propra evoluo)
Flikisto
Gitlab + GitLab-kuristo
Hashicorp Volbo
Cetere, pri ansible roloj. Komence estis nur unu, sed post pluraj refaktorigoj estis 17. Mi forte rekomendas rompi la monoliton en idempotentajn rolojn, kiuj poste povas esti lanĉitaj aparte; aldone oni povas aldoni etikedojn. Ni dividis la rolojn laŭ funkcieco - reto, protokolado, pakaĵoj, aparataro, molekulo ktp. Ĝenerale, ni sekvis la strategion sube. Mi ne insistas, ke ĉi tio estas la sola vero, sed ĝi funkciis por ni.
- Kopii servilojn de la "ora bildo" estas malbona!La ĉefa malavantaĝo estas, ke vi ne scias precize en kiu stato estas la bildoj nun, kaj ke ĉiuj ŝanĝoj venos al ĉiuj bildoj en ĉiuj virtualigaj bienoj.
- Uzu defaŭltajn agordajn dosierojn minimume kaj konsentu kun aliaj fakoj, ke vi respondecas pri la ĉefaj sistemdosierojekzemple:
- Lasu /etc/sysctl.conf malplena, la agordoj estu nur en /etc/sysctl.d/. Via defaŭlta en unu dosiero, kutimo por la aplikaĵo en alia.
- Uzu anstataŭigajn dosierojn por redakti sistemajn unuojn.
- Ŝablonu ĉiujn agordojn kaj inkludu ilin tute; se eble, neniu sed aŭ ĝiaj analogoj en ludlibroj
- Refaktorigi la agordan administradsistemkodon:
- Malkonstruu taskojn en logikaj entoj kaj reverku la monoliton en rolojn
- Uzu linters! Ansible-lint, yaml-lint, ktp
- Ŝanĝu vian aliron! Neniu bashsible. Necesas priskribi la staton de la sistemo
- Por ĉiuj Ansible-roloj vi devas skribi testojn en molekulo kaj generi raportojn unufoje tage.
- En nia kazo, post preparado de la testoj (el kiuj estas pli ol 100), oni trovis ĉirkaŭ 70000 XNUMX erarojn. Necesis pluraj monatoj por ripari ĝin.
Nia efektivigo
Do, la ansibaj roloj estis pretaj, ŝablonitaj kaj kontrolitaj de linters. Kaj eĉ gits estas levitaj ĉie. Sed la demando pri fidinda livero de kodo al malsamaj segmentoj restis malfermita. Ni decidis sinkronigi kun skriptoj. Aspektas tiel:
Post kiam la ŝanĝo alvenas, CI estas lanĉita, testa servilo estas kreita, roloj estas lanĉitaj kaj testitaj per la molekulo. Se ĉio estas en ordo, la kodo iras al la prod-branĉo. Sed ni ne aplikas novan kodon al ekzistantaj serviloj en la maŝino. Ĉi tio estas speco de ŝtopilo, kiu estas necesa por alta havebleco de niaj sistemoj. Kaj kiam la infrastrukturo fariĝas grandega, la leĝo de grandaj nombroj ekludas - eĉ se vi certas, ke la ŝanĝo estas sendanĝera, ĝi povas konduki al teruraj sekvoj.
Estas ankaŭ multaj ebloj por krei servilojn. Ni finfine elektis kutimajn Python-skriptojn. Kaj por 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}}"Jen kion ni venis, la sistemo daŭre vivas kaj disvolviĝas.
- 17 Eblaj roloj por agordi la servilon. Ĉiu el la roloj estas desegnita por solvi apartan logikan taskon (dehakado, revizio, uzantrajtigo, monitorado ktp.).
- Roltestado. Molekulo + TestInfra.
- Propra evoluo: CMDB + Orchestrator.
- Servila krea tempo estas ~30 minutoj, aŭtomatigita kaj preskaŭ sendependa de la taskovico.
- La sama stato/nomado de la infrastrukturo en ĉiuj segmentoj - ludlibroj, deponejoj, virtualigaj elementoj.
- Ĉiutaga kontrolo de servila stato kun generado de raportoj pri diferencoj kun la normo.
Mi esperas, ke mia rakonto estos utila al tiuj, kiuj estas en la komenco de sia vojaĝo. Kian aŭtomatigan stakon vi uzas?
fonto: www.habr.com