ProHoster > Blogs > Administrācija > No ā€œstartÄ“Å”anasā€ lÄ«dz tÅ«kstoÅ”iem serveru duci datu centru. Kā mēs tiecāmies pēc Linux infrastruktÅ«ras izaugsmes

No ā€œstartÄ“Å”anasā€ lÄ«dz tÅ«kstoÅ”iem serveru duci datu centru. Kā mēs tiecāmies pēc Linux infrastruktÅ«ras izaugsmes

Ja jÅ«su IT infrastruktÅ«ra augs pārāk ātri, jÅ«s agrāk vai vēlāk bÅ«siet izvēles priekŔā: lineāri palielināt cilvēkresursus, lai to atbalstÄ«tu vai sāktu automatizāciju. LÄ«dz kādam brÄ«dim mēs dzÄ«vojām pirmajā paradigmā, un tad sākās garÅ” ceļŔ uz Infrastructure-as-Code.

No ā€œstartÄ“Å”anasā€ lÄ«dz tÅ«kstoÅ”iem serveru duci datu centru. Kā mēs tiecāmies pēc Linux infrastruktÅ«ras izaugsmes

Protams, NSPK nav startup, taču tāda atmosfēra uzņēmumā valdÄ«ja pirmajos pastāvÄ“Å”anas gados, un tie bija ļoti interesanti gadi. Mani sauc Korņakovs Dmitrijs, Es atbalstu Linux infrastruktÅ«ru ar augstām pieejamÄ«bas prasÄ«bām vairāk nekā 10 gadus. NSPK komandai viņŔ pievienojās 2016. gada janvārÄ« un diemžēl neredzēja paÅ”u uzņēmuma pastāvÄ“Å”anas sākumu, bet nonāca lielu pārmaiņu stadijā.

Kopumā varam teikt, ka mÅ«su komanda uzņēmumam piegādā 2 produktus. Pirmais ir infrastruktÅ«ra. Pastam ir jādarbojas, DNS ir jādarbojas, un domēna kontrolleriem ir jāļauj jums piekļūt serveriem, kuriem nevajadzētu avarēt. Uzņēmuma IT ainava ir milzÄ«ga! Å Ä«s ir biznesa un misijas kritiskās sistēmas, dažu pieejamÄ«bas prasÄ«bas ir 99,999 XNUMX. Otrs produkts ir paÅ”i serveri, fiziskie un virtuālie. EsoÅ”ie ir jāuzrauga, un jauni regulāri jāpiegādā klientiem no daudzām nodaļām. Å ajā rakstā es vēlos pievērsties tam, kā mēs izstrādājām infrastruktÅ«ru, kas ir atbildÄ«ga par servera dzÄ«ves ciklu.

Sākot no ceļojuma

Mūsu ceļojuma sākumā mūsu tehnoloģiju kaudze izskatījās Ŕādi:
OS CentOS 7
FreeIPA domēna kontrolieri
Automatizācija - Ansible(+Tower), Kurpnieks

Tas viss atradās 3 domēnos, kas bija izvietoti vairākos datu centros. Vienā datu centrā ir biroja sistēmas un testÄ“Å”anas vietas, pārējās ir PROD.

Serveru izveide vienā brīdī izskatījās Ŕādi:

No ā€œstartÄ“Å”anasā€ lÄ«dz tÅ«kstoÅ”iem serveru duci datu centru. Kā mēs tiecāmies pēc Linux infrastruktÅ«ras izaugsmes

VM veidnē CentOS ir minimāls un nepiecieÅ”amais minimums ir kā pareizais /etc/resolv.conf, pārējais nāk caur Ansible.

CMDB ā€” Excel.

Ja serveris ir fizisks, tad tā vietā, lai kopētu virtuālo maŔīnu, OS tajā tika instalēta, izmantojot Cobbler - mērÄ·a servera MAC adreses tiek pievienotas Cobbler konfigurācijai, serveris saņem IP adresi, izmantojot DHCP, un pēc tam OS. ir pievienots.

Sākumā mēs pat mēģinājām veikt kaut kādu konfigurācijas pārvaldÄ«bu programmā Cobbler. Bet laika gaitā tas sāka radÄ«t problēmas ar konfigurāciju pārnesamÄ«bu gan uz citiem datu centriem, gan ar Ansible kodu virtuālo maŔīnu sagatavoÅ”anai.

Tajā laikā daudzi no mums uztvēra Ansible kā ērtu Bash paplaÅ”inājumu un neskopojās ar dizainparaugiem, izmantojot shell un sed. Kopumā Bashsible. Tas galu galā noveda pie tā, ka, ja rokasgrāmata kāda iemesla dēļ nedarbojās serverÄ«, bija vieglāk izdzēst serveri, salabot rokasgrāmatu un palaist to vēlreiz. BÅ«tÄ«bā nebija skriptu versijas, nebija konfigurāciju pārnesamÄ«bas.

Piemēram, mēs vēlējāmies mainīt kādu konfigurāciju visos serveros:

  1. Mēs mainām konfigurāciju esoÅ”ajos serveros loÄ£iskajā segmentā/datu centrā. Dažkārt ne vienā dienā ā€“ pieejamÄ«bas prasÄ«bas un lielo skaitļu likums neļauj visas izmaiņas piemērot uzreiz. Un dažas izmaiņas ir potenciāli destruktÄ«vas un prasa kaut ko restartēt ā€” no pakalpojumiem uz paÅ”u OS.
  2. Labojiet to Ansible
  3. Mēs to labojam Cobbler
  4. Atkārtojiet N reizes katram loÄ£iskajam segmentam/datu centram

Lai visas izmaiņas noritētu raiti, bija jāņem vērā daudzi faktori, un izmaiņas notiek nepārtraukti.

  • Iespējamā koda pārstrukturÄ“Å”ana, konfigurācijas faili
  • IekŔējās paraugprakses maiņa
  • Izmaiņas, pamatojoties uz incidentu/avāriju analÄ«zes rezultātiem
  • Mainās gan iekŔējie, gan ārējie droŔības standarti. Piemēram, PCI DSS katru gadu tiek atjaunināts ar jaunām prasÄ«bām

Infrastruktūras izaugsme un ceļojuma sākums

Pieauga serveru/loģisko domēnu/datu centru skaits un līdz ar tiem arī kļūdu skaits konfigurācijās. Kādā brīdī mēs nonācām pie trim virzieniem, kuros ir jāattīsta konfigurācijas pārvaldība:

  1. Automatizācija. Cik vien iespējams, ir jāizvairās no cilvēka kļūdām atkārtotās darbībās.
  2. AtkārtojamÄ«ba. Ir daudz vieglāk pārvaldÄ«t infrastruktÅ«ru, ja tā ir paredzama. Serveru konfigurācijai un to sagatavoÅ”anas rÄ«kiem visur jābÅ«t vienādai. Tas ir svarÄ«gi arÄ« produktu komandām ā€“ pēc testÄ“Å”anas ir jāgarantē, ka lietojumprogramma nonāks ražoÅ”anas vidē, kas konfigurēta lÄ«dzÄ«gi kā testa videi.
  3. Konfigurācijas pārvaldÄ«bas izmaiņu veikÅ”anas vienkārŔība un caurspÄ«dÄ«gums.

Atliek pievienot pāris rīkus.

Mēs izvēlējāmies GitLab CE kā mÅ«su kodu krātuvi, jo Ä«paÅ”i tā iebÅ«vētajiem CI/CD moduļiem.

Noslēpumu glabātuve - Hashicorp Vault, t.sk. par lielisko API.

TestÄ“Å”anas konfigurācijas un iespējamās lomas ā€“ Molecule+Testinfra. Pārbaudes norit daudz ātrāk, ja izveidojat savienojumu ar iespējamo mitogēnu. Tajā paŔā laikā mēs sākām rakstÄ«t paÅ”i savu CMDB un orÄ·estrētāju automātiskai izvietoÅ”anai (attēlā virs Cobbler), taču tas ir pavisam cits stāsts, ko mans kolēģis un galvenais Å”o sistēmu izstrādātājs stāstÄ«s nākotnē.

Mūsu izvēle:

Molekula + Testinfra
Ansible + Tower + AWX
Serveru pasaule + DITNET (paŔu izstrāde)
Kobleris
Gitlab + GitLab skrējējs
Hashicorp Vault

No ā€œstartÄ“Å”anasā€ lÄ«dz tÅ«kstoÅ”iem serveru duci datu centru. Kā mēs tiecāmies pēc Linux infrastruktÅ«ras izaugsmes

Starp citu, par prasmÄ«gām lomām. Sākumā bija tikai viens, bet pēc vairākiem pārveidojumiem bija 17. Ä»oti iesaku sadalÄ«t monolÄ«tu idempotentās lomās, kuras pēc tam var palaist atseviŔķi, papildus var pievienot tagus. Mēs sadalÄ«jām lomas pēc funkcionalitātes - tÄ«kls, reÄ£istrÄ“Å”ana, pakotnes, aparatÅ«ra, molekula utt. Kopumā mēs ievērojām tālāk norādÄ«to stratēģiju. Es neuzstāju, ka tā ir vienÄ«gā patiesÄ«ba, bet tā mums noderēja.

  • Serveru kopÄ“Å”ana no ā€œzelta attēlaā€ ir ļauna!Galvenais trÅ«kums ir tas, ka jÅ«s nezināt, kādā stāvoklÄ« ir attēli paÅ”laik, un visas izmaiņas attieksies uz visiem attēliem visās virtualizācijas fermās.
  • Izmantojiet noklusējuma konfigurācijas failus lÄ«dz minimumam un vienojieties ar citiem departamentiem, ka esat atbildÄ«gs par galvenajiem sistēmas failiem, piemēram:
    1. Atstājiet /etc/sysctl.conf tukÅ”u, iestatÄ«jumiem jābÅ«t tikai /etc/sysctl.d/. Noklusējums vienā failā, pielāgots lietojumprogrammai citā.
    2. Izmantojiet ignorÄ“Å”anas failus, lai rediģētu sistēmas vienÄ«bas.
  • Veidojiet visas konfigurācijas un iekļaujiet tās pilnÄ«bā; ja iespējams, rokasgrāmatās nelietojiet sed vai tā analogus
  • Konfigurācijas pārvaldÄ«bas sistēmas koda pārveidoÅ”ana:
    1. Sadaliet uzdevumus loģiskās vienībās un pārrakstiet monolītu lomās
    2. Izmantojiet linterus! Ansible-lint, yaml-lint utt
    3. Mainiet savu pieeju! Nav apkaunojuma. Ir nepiecieÅ”ams aprakstÄ«t sistēmas stāvokli
  • Visām Ansible lomām jums ir jāraksta testi molekulās un jāģenerē atskaites reizi dienā.
  • MÅ«su gadÄ«jumā pēc testu sagatavoÅ”anas (kuru ir vairāk nekā 100) tika atrastas aptuveni 70000 XNUMX kļūdu. Pagāja vairāki mēneÅ”i, lai to salabotu.No ā€œstartÄ“Å”anasā€ lÄ«dz tÅ«kstoÅ”iem serveru duci datu centru. Kā mēs tiecāmies pēc Linux infrastruktÅ«ras izaugsmes

Mūsu īstenoŔana

Tātad iespējamās lomas bija gatavas, veidotas un pārbaudÄ«tas. Un pat gitus visur audzē. Taču jautājums par uzticamu koda piegādi dažādiem segmentiem palika atklāts. Mēs nolēmām sinhronizēt ar skriptiem. Izskatās Ŕādi:

No ā€œstartÄ“Å”anasā€ lÄ«dz tÅ«kstoÅ”iem serveru duci datu centru. Kā mēs tiecāmies pēc Linux infrastruktÅ«ras izaugsmes

Pēc izmaiņu ievieÅ”anas tiek palaists CI, tiek izveidots testa serveris, tiek izlaistas lomas un molekula tiek pārbaudÄ«ta. Ja viss ir kārtÄ«bā, kods tiek nosÅ«tÄ«ts uz prod filiāli. Taču mēs nepielietojam jaunu kodu esoÅ”ajiem serveriem maŔīnā. Tas ir sava veida aizbāznis, kas nepiecieÅ”ams mÅ«su sistēmu augstajai pieejamÄ«bai. Un, kad infrastruktÅ«ra kļūst milzÄ«ga, stājas spēkā lielo skaitļu likums ā€“ pat ja esat pārliecināts, ka izmaiņas ir nekaitÄ«gas, tās var novest pie bēdÄ«gām sekām.

Ir arī daudz iespēju izveidot serverus. Mēs beidzot izvēlējāmies pielāgotus Python skriptus. Un 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}}"

Pie tā esam nonākuÅ”i, sistēma turpina dzÄ«vot un attÄ«stÄ«ties.

  • 17 Iespējamās lomas servera iestatÄ«Å”anai. Katra no lomām ir paredzēta atseviŔķa loÄ£iska uzdevuma risināŔanai (reÄ£istrācija, audits, lietotāja autorizācija, uzraudzÄ«ba utt.).
  • Lomu pārbaude. Molekula + TestInfra.
  • PaÅ”u izstrāde: CMDB + Orchestrator.
  • Servera izveides laiks ir ~30 minÅ«tes, automatizēts un praktiski neatkarÄ«gs no uzdevumu rindas.
  • Vienāds infrastruktÅ«ras stāvoklis/nosaukÅ”ana visos segmentos - playbooks, repozitorijs, virtualizācijas elementi.
  • Ikdienas servera statusa pārbaude, Ä£enerējot ziņojumus par neatbilstÄ«bām standartam.

Es ceru, ka mans stāsts būs noderīgs tiem, kas ir sava ceļojuma sākumā. Kādu automatizācijas steku jūs izmantojat?

Avots: www.habr.com