Kung masyadong mabilis na lumago ang iyong imprastraktura ng IT, maaga o huli ay haharap ka sa isang pagpipilian: linearly taasan ang human resources upang suportahan ito o simulan ang automation. Hanggang sa isang punto, nabuhay kami sa unang paradigm, at pagkatapos ay nagsimula ang mahabang landas patungo sa Infrastructure-as-Code.
Siyempre, ang NSPK ay hindi isang startup, ngunit ang gayong kapaligiran ay naghari sa kumpanya sa mga unang taon ng pagkakaroon nito, at ang mga iyon ay napaka-kagiliw-giliw na mga taon. Ang pangalan ko ay , Sinusuportahan ko ang imprastraktura ng Linux na may mataas na mga kinakailangan sa pagkakaroon ng higit sa 10 taon. Sumali siya sa koponan ng NSPK noong Enero 2016 at, sa kasamaang-palad, ay hindi nakita ang pinakadulo simula ng pagkakaroon ng kumpanya, ngunit dumating sa isang yugto ng malalaking pagbabago.
Sa pangkalahatan, masasabi nating nagsusuplay ang aming team ng 2 produkto para sa kumpanya. Ang una ay imprastraktura. Dapat gumana ang mail, dapat gumana ang DNS, at dapat kang hayaan ng mga controller ng domain sa mga server na hindi dapat mag-crash. Napakalaki ng IT landscape ng kumpanya! Ito ay mga sistemang kritikal sa negosyo at misyon, ang mga kinakailangan sa pagkakaroon para sa ilan ay 99,999. Ang pangalawang produkto ay ang mga server mismo, pisikal at virtual. Ang mga dati ay kailangang subaybayan, at ang mga bago ay dapat na regular na maihatid sa mga customer mula sa maraming departamento. Sa artikulong ito gusto kong tumuon sa kung paano namin binuo ang imprastraktura na responsable para sa ikot ng buhay ng server.
Simula ng isang paglalakbay
Sa simula ng aming paglalakbay, ganito ang hitsura ng aming stack ng teknolohiya:
OS CentOS 7
Mga Kontroler ng Domain ng FreeIPA
Automation - Ansible(+Tower), Cobbler
Ang lahat ng ito ay matatagpuan sa 3 mga domain, na kumalat sa ilang mga sentro ng data. Sa isang data center mayroong mga sistema ng opisina at mga site ng pagsubok, sa iba ay mayroong PROD.
Ang paglikha ng mga server sa isang punto ay ganito ang hitsura:
Sa template ng VM, ang CentOS ay minimal at ang kinakailangang minimum ay tulad ng tamang /etc/resolv.conf, ang iba ay dumaan sa Ansible.
CMDB - Excel.
Kung ang server ay pisikal, pagkatapos ay sa halip na kopyahin ang virtual machine, ang OS ay na-install dito gamit ang Cobbler - ang mga MAC address ng target na server ay idinagdag sa Cobbler config, ang server ay tumatanggap ng isang IP address sa pamamagitan ng DHCP, at pagkatapos ay ang OS Ay dinagdag.
Noong una sinubukan pa naming gumawa ng ilang uri ng pamamahala ng pagsasaayos sa Cobbler. Ngunit sa paglipas ng panahon, nagsimula itong magdala ng mga problema sa portability ng mga configuration sa iba pang data center at sa Ansible code para sa paghahanda ng mga VM.
Sa oras na iyon, marami sa amin ang nag-isip ng Ansible bilang isang maginhawang extension ng Bash at hindi nagtipid sa mga disenyo gamit ang shell at sed. Pangkalahatang Bashsible. Ito sa huli ay humantong sa katotohanan na kung ang playbook sa ilang kadahilanan ay hindi gumana sa server, mas madaling tanggalin ang server, ayusin ang playbook at patakbuhin itong muli. Talagang walang bersyon ng mga script, walang portability ng mga configuration.
Halimbawa, gusto naming baguhin ang ilang config sa lahat ng mga server:
- Binabago namin ang configuration sa mga umiiral nang server sa lohikal na segment/data center. Minsan hindi sa isang araw - ang mga kinakailangan sa accessibility at ang batas ng malalaking numero ay hindi pinapayagan ang lahat ng mga pagbabago na mailapat nang sabay-sabay. At ang ilang mga pagbabago ay potensyal na mapanira at nangangailangan ng pag-restart ng isang bagay - mula sa mga serbisyo hanggang sa OS mismo.
- Pag-aayos nito sa Ansible
- Inaayos namin ito sa Cobbler
- Ulitin ang N beses para sa bawat lohikal na segment/data center
Upang maging maayos ang lahat ng pagbabago, kailangang isaalang-alang ang maraming salik, at patuloy na nagaganap ang mga pagbabago.
- Refactoring ansible code, configuration file
- Pagbabago ng mga panloob na pinakamahusay na kagawian
- Mga pagbabago batay sa mga resulta ng pagsusuri ng mga insidente/aksidente
- Pagbabago ng mga pamantayan sa seguridad, parehong panloob at panlabas. Halimbawa, ang PCI DSS ay ina-update na may mga bagong kinakailangan bawat taon
Paglago ng imprastraktura at ang simula ng paglalakbay
Lumaki ang bilang ng mga server/logical domain/data center, at kasama nila ang bilang ng mga error sa mga configuration. Sa ilang mga punto, dumating kami sa tatlong direksyon kung saan kailangang mabuo ang pamamahala ng configuration:
- Automation. Ang pagkakamali ng tao sa mga paulit-ulit na operasyon ay dapat na iwasan hangga't maaari.
- Pag-uulit. Mas madaling pamahalaan ang imprastraktura kapag ito ay predictable. Ang pagsasaayos ng mga server at tool para sa kanilang paghahanda ay dapat na pareho sa lahat ng dako. Mahalaga rin ito para sa mga pangkat ng produkto - pagkatapos ng pagsubok, ang application ay dapat na garantisadong mapupunta sa isang kapaligiran ng produksyon na na-configure nang katulad sa kapaligiran ng pagsubok.
- Ang pagiging simple at transparency ng paggawa ng mga pagbabago sa pamamahala ng configuration.
Ito ay nananatiling magdagdag ng ilang mga tool.
Pinili namin ang GitLab CE bilang aming imbakan ng code, hindi bababa sa mga built-in na CI/CD module nito.
Vault ng mga lihim - Hashicorp Vault, incl. para sa mahusay na API.
Pagsubok ng mga configuration at ansible na tungkulin β Molecule+Testinfra. Mas mabilis ang mga pagsubok kung kumonekta ka sa ansible mitogen. Kasabay nito, nagsimula kaming magsulat ng aming sariling CMDB at orkestra para sa awtomatikong pag-deploy (sa larawan sa itaas ng Cobbler), ngunit ito ay isang ganap na naiibang kuwento, na sasabihin ng aking kasamahan at ang pangunahing developer ng mga sistemang ito sa hinaharap.
Ang aming pagpipilian:
Molecule + Testinfra
Ansible + Tower + AWX
Mundo ng mga Server + DITNET (Sariling pag-unlad)
Cobbler
Gitlab + GitLab runner
Hashicorp Vault
Sa pamamagitan ng paraan, tungkol sa mga ansible na tungkulin. Sa una ay isa lamang, ngunit pagkatapos ng ilang mga refactorings ay mayroong 17 sa kanila. Lubos kong inirerekumenda na hatiin ang monolith sa mga idempotent na tungkulin, na pagkatapos ay maaaring ilunsad nang hiwalay, bukod pa rito, maaari kang magdagdag ng mga tag. Hinati namin ang mga tungkulin ayon sa functionality - network, logging, packages, hardware, molecule atbp. Sa pangkalahatan, sinunod namin ang diskarte sa ibaba. Hindi ko ipinipilit na ito lang ang katotohanan, ngunit ito ay nagtrabaho para sa amin.
- Ang pagkopya ng mga server mula sa "gintong imahe" ay masama!Ang pangunahing kawalan ay hindi mo alam nang eksakto kung ano ang estado ng mga imahe ngayon, at ang lahat ng mga pagbabago ay darating sa lahat ng mga imahe sa lahat ng mga virtualization farm.
- Gumamit ng mga default na configuration file sa pinakamababa at sumang-ayon sa ibang mga departamento na ikaw ang may pananagutan para sa mga pangunahing file ng system, halimbawa:
- Iwanang walang laman ang /etc/sysctl.conf, ang mga setting ay dapat lamang nasa /etc/sysctl.d/. Ang iyong default sa isang file, custom para sa application sa isa pa.
- Gumamit ng mga override na file para i-edit ang mga systemd unit.
- I-template ang lahat ng mga config at isama ang mga ito nang buo; kung maaari, walang sed o mga analogue nito sa mga playbook
- Refactoring ang configuration management system code:
- Hatiin ang mga gawain sa mga lohikal na entity at muling isulat ang monolith sa mga tungkulin
- Gumamit ng linters! Ansible-lint, yaml-lint, atbp
- Baguhin ang iyong diskarte! Walang bashible. Ito ay kinakailangan upang ilarawan ang estado ng sistema
- Para sa lahat ng Ansible na tungkulin kailangan mong magsulat ng mga pagsubok sa molekula at bumuo ng mga ulat isang beses sa isang araw.
- Sa aming kaso, pagkatapos ihanda ang mga pagsubok (kung saan mayroong higit sa 100), humigit-kumulang 70000 mga pagkakamali ang natagpuan. Tumagal ng ilang buwan para maayos ito.
Ang ating pagpapatupad
Kaya, handa na, na-template, at sinuri ng mga linter ang mga tungkulin. At kahit ang mga gits ay itinataas sa lahat ng dako. Ngunit ang tanong ng maaasahang paghahatid ng code sa iba't ibang mga segment ay nanatiling bukas. Nagpasya kaming mag-synchronize sa mga script. Mukhang ganito:
Pagkatapos dumating ang pagbabago, ang CI ay inilunsad, isang pagsubok na server ay nilikha, ang mga tungkulin ay inilunsad, at sinubok ng molekula. Kung ok ang lahat, mapupunta ang code sa prod branch. Ngunit hindi kami naglalapat ng bagong code sa mga kasalukuyang server sa makina. Ito ay isang uri ng stopper na kinakailangan para sa mataas na kakayahang magamit ng aming mga system. At kapag ang imprastraktura ay naging napakalaki, ang batas ng malaking bilang ay papasok - kahit na sigurado ka na ang pagbabago ay hindi nakakapinsala, maaari itong humantong sa mga kakila-kilabot na kahihinatnan.
Mayroon ding maraming mga pagpipilian para sa paglikha ng mga server. Natapos namin ang pagpili ng mga custom na script ng Python. At para sa 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}}"Ito ang narating natin, ang sistema ay patuloy na nabubuhay at umuunlad.
- 17 Madaling tungkulin para sa pag-set up ng server. Ang bawat isa sa mga tungkulin ay idinisenyo upang malutas ang isang hiwalay na lohikal na gawain (pag-log, pag-audit, awtorisasyon ng gumagamit, pagsubaybay, atbp.).
- Pagsusulit sa tungkulin. Molecule + TestInfra.
- Sariling pag-unlad: CMDB + Orchestrator.
- Ang oras ng paglikha ng server ay ~30 minuto, awtomatiko at halos independyente sa pila ng gawain.
- Ang parehong estado/pangalan ng imprastraktura sa lahat ng mga segment - mga playbook, mga repositoryo, mga elemento ng virtualization.
- Araw-araw na pagsusuri ng katayuan ng server na may pagbuo ng mga ulat sa mga pagkakaiba sa pamantayan.
Sana ay maging kapaki-pakinabang ang aking kwento sa mga nasa simula ng kanilang paglalakbay. Anong automation stack ang ginagamit mo?
Pinagmulan: www.habr.com