"ආරම්භක" සිට දත්ත මධ්‍යස්ථාන දුසිමක සේවාදායක දහස් ගණනක් දක්වා. අපි ලිනක්ස් යටිතල පහසුකම් වර්ධනය හඹා ගිය ආකාරය

ඔබේ තොරතුරු තාක්ෂණ යටිතල ව්‍යුහය ඉතා ඉක්මනින් වර්ධනය වුවහොත්, ඔබට ඉක්මනින් හෝ පසුව තේරීමකට මුහුණ දීමට සිදුවනු ඇත: එයට සහාය වීමට හෝ ස්වයංක්‍රීයකරණය ආරම්භ කිරීමට මානව සම්පත් රේඛීයව වැඩි කරන්න. යම් කාලයක් දක්වා, අපි පළමු සුසමාදර්ශය තුළ ජීවත් වූ අතර, පසුව යටිතල පහසුකම්-කේතය දක්වා දිගු මාවත ආරම්භ විය.

ඇත්ත වශයෙන්ම, NSPK යනු ආරම්භයක් නොවේ, නමුත් එවැනි වාතාවරණයක් එහි පැවැත්මේ පළමු වසර තුළ සමාගම තුළ රජ වූ අතර ඒවා ඉතා සිත්ගන්නා වසර විය. මගේ නම වන්නේ කෝර්නියාකොව් දිමිත්‍රි, මම වසර 10 කට වැඩි කාලයක් සඳහා ඉහළ ලබා ගැනීමේ අවශ්‍යතා සහිත Linux යටිතල පහසුකම් සඳහා සහාය දක්වමි. ඔහු 2016 ජනවාරි මාසයේදී NSPK කණ්ඩායමට සම්බන්ධ වූ අතර, අවාසනාවකට මෙන්, සමාගමේ පැවැත්මේ ආරම්භය දුටුවේ නැත, නමුත් විශාල වෙනස්කම්වල අවධියකට පැමිණියේය.

පොදුවේ ගත් කල, අපගේ කණ්ඩායම සමාගම සඳහා නිෂ්පාදන 2 ක් සපයන බව අපට පැවසිය හැකිය. පළමුවැන්න යටිතල පහසුකම් ය. තැපෑල ක්‍රියා කළ යුතුය, ඩීඑන්එස් ක්‍රියා කළ යුතුය, සහ වසම් පාලකයන් ඔබට බිඳවැටිය යුතු නැති සේවාදායකයන් වෙතට ඉඩ දිය යුතුය. සමාගමේ තොරතුරු තාක්ෂණ භූ දර්ශනය විශාලයි! මේවා ව්‍යාපාර සහ මෙහෙවර විවේචනාත්මක පද්ධති වේ, සමහරක් සඳහා පවතින අවශ්‍යතා 99,999 වේ. දෙවන නිපැයුම වන්නේ සර්වර් විසින්ම, භෞතික සහ අථත්ය වේ. පවතින ඒවා නිරීක්ෂණය කළ යුතු අතර නව ඒවා බොහෝ දෙපාර්තමේන්තු වලින් පාරිභෝගිකයින්ට නිතිපතා ලබා දිය යුතුය. මෙම ලිපියෙන් මට අවධානය යොමු කිරීමට අවශ්‍ය වන්නේ සේවාදායක ජීවන චක්‍රයට වගකිව යුතු යටිතල පහසුකම් අප දියුණු කළ ආකාරයයි.

ගමන ආරම්භ කිරීම

අපගේ ගමන ආරම්භයේදී, අපගේ තාක්‍ෂණ තොගය මෙලෙස දිස් විය:
OS CentOS 7
FreeIPA වසම් පාලක
ස්වයංක්‍රීයකරණය - Ansible(+කුළුණ), Cobbler

මේ සියල්ල දත්ත මධ්‍යස්ථාන කිහිපයක් පුරා පැතිරුණු වසම් 3ක පිහිටා තිබුණි. එක් දත්ත මධ්යස්ථානයක කාර්යාල පද්ධති සහ පරීක්ෂණ අඩවි ඇත, ඉතිරිය තුළ PROD ඇත.

එක් අවස්ථාවක සේවාදායකයන් සෑදීම මේ ආකාරයෙන් පෙනුනි:

VM අච්චුවෙහි, CentOS අවම වන අතර අවශ්‍ය අවමය නිවැරදි /etc/resolv.conf වැනි වේ, ඉතිරිය Ansible හරහා පැමිණේ.

CMDB - එක්සෙල්.

සේවාදායකය භෞතික නම්, අථත්‍ය යන්ත්‍රය පිටපත් කිරීම වෙනුවට, OS එක Cobbler භාවිතයෙන් ස්ථාපනය කර ඇත - ඉලක්ක සේවාදායකයේ MAC ලිපින Cobbler වින්‍යාසයට එකතු කරනු ලැබේ, සේවාදායකයට DHCP හරහා IP ලිපිනයක් ලැබේ, පසුව OS එකතු කරනු ලැබේ.

මුලදී අපි Cobbler හි යම් ආකාරයක වින්‍යාස කළමනාකරණයක් කිරීමට පවා උත්සාහ කළෙමු. නමුත් කාලයාගේ ඇවෑමෙන්, මෙය අනෙකුත් දත්ත මධ්‍යස්ථාන වෙත සහ VMs සකස් කිරීම සඳහා වන Ansible කේතය යන දෙකටම වින්‍යාසවල අතේ ගෙන යා හැකි ගැටළු ගෙන ඒමට පටන් ගත්තේය.

එකල අපගෙන් බොහෝ දෙනෙක් ඇන්සිබල් යනු බාෂ් හි පහසු දිගුවක් ලෙස වටහා ගත් අතර ෂෙල් සහ සෙඩ් භාවිතයෙන් නිර්මාණ අතපසු නොකළෙමු. සමස්තයක් ලෙස Bashsible. මෙය අවසානයේ හේතු වූයේ කිසියම් හේතුවක් නිසා Playbook සේවාදායකයේ ක්‍රියා නොකළේ නම්, සේවාදායකය මකා දැමීම, Playbook නිවැරදි කර එය නැවත ධාවනය කිරීම පහසු වීමයි. අත්‍යවශ්‍යයෙන්ම ස්ක්‍රිප්ට් අනුවාදයක් හෝ වින්‍යාසයන් අතේ ගෙන යා හැකි බවක් නොතිබුණි.

උදාහරණයක් ලෙස, අපට සියලුම සර්වර් වල යම් වින්‍යාසය වෙනස් කිරීමට අවශ්‍ය විය:

1. තාර්කික කොටසේ/දත්ත මධ්‍යස්ථානයේ පවතින සර්වර් වල වින්‍යාසය අපි වෙනස් කරමු. සමහර විට එක් දිනක් තුළ නොවේ - ප්‍රවේශ්‍යතා අවශ්‍යතා සහ විශාල සංඛ්‍යා නීතිය මඟින් සියලු වෙනස්කම් එකවර යෙදීමට ඉඩ නොදේ. තවද සමහර වෙනස්කම් විනාශකාරී විය හැකි අතර යමක් නැවත ආරම්භ කිරීම අවශ්‍ය වේ - සේවා සිට OS වෙතම.
2. Ansible හි එය සවි කිරීම
3. අපි එය Cobbler හි සවි කරමු
4. එක් එක් තාර්කික අංශය/දත්ත මධ්‍යස්ථානය සඳහා N වාරයක් නැවත නැවත කරන්න

සියලුම වෙනස්කම් සුමටව සිදු කිරීම සඳහා, බොහෝ සාධක සැලකිල්ලට ගත යුතු අතර, වෙනස්කම් නිරන්තරයෙන් සිදු වේ.

• ඇසිබල් කේතය, වින්‍යාස ගොනු නැවත සකස් කිරීම
• අභ්යන්තර හොඳම භාවිතයන් වෙනස් කිරීම
• සිදුවීම්/අනතුරු විශ්ලේෂණයේ ප්‍රතිඵල මත පදනම් වූ වෙනස්කම්
• අභ්යන්තර සහ බාහිර යන දෙඅංශයෙන්ම ආරක්ෂක ප්රමිතීන් වෙනස් කිරීම. උදාහරණයක් ලෙස, PCI DSS සෑම වසරකම නව අවශ්‍යතා සමඟ යාවත්කාලීන වේ

යටිතල පහසුකම් වර්ධනය සහ ගමනේ ආරම්භය

සේවාදායක/තාර්කික වසම්/දත්ත මධ්‍යස්ථාන ගණන වැඩි වූ අතර ඒවා සමඟ වින්‍යාසයන්හි දෝෂ සංඛ්‍යාවද වැඩි විය. යම් අවස්ථාවක, අපි වින්‍යාස කළමනාකරණය දියුණු කළ යුතු දිශාවන් තුනකට පැමිණියෙමු:

1. ස්වයංක්රීයකරණය. පුනරාවර්තන මෙහෙයුම් වලදී මානව දෝෂ හැකිතාක් වළක්වා ගත යුතුය.
2. පුනරාවර්තන හැකියාව. එය පුරෝකථනය කළ හැකි විට යටිතල පහසුකම් කළමනාකරණය කිරීම වඩාත් පහසු වේ. ඒවා සකස් කිරීම සඳහා සේවාදායකයන් සහ මෙවලම් වින්‍යාසය සෑම තැනකම සමාන විය යුතුය. නිෂ්පාදන කණ්ඩායම් සඳහා ද මෙය වැදගත් වේ - පරීක්ෂා කිරීමෙන් පසු, යෙදුම පරීක්ෂණ පරිසරයට සමාන ලෙස වින්‍යාස කර ඇති නිෂ්පාදන පරිසරයක අවසන් වන බවට සහතික විය යුතුය.
3. වින්‍යාස කළමනාකරණයට වෙනස්කම් සිදු කිරීමේ සරල බව සහ විනිවිදභාවය.

මෙවලම් කිහිපයක් එකතු කිරීමට එය ඉතිරිව ඇත.

අපි GitLab CE අපගේ කේත ගබඩාව ලෙස තෝරා ගත්තෙමු, අඩුම තරමින් එහි ඇති CI/CD මොඩියුල සඳහා නොවේ.

රහස් සුරක්ෂිතාගාරය - Hashicorp Vault, ඇතුළුව. විශිෂ්ට API සඳහා.

පරීක්ෂණ වින්‍යාසයන් සහ ප්‍රධාන භූමිකාවන් - Molecule+Testinfra. ඔබ ansible mitogen වෙත සම්බන්ධ කළහොත් පරීක්ෂණ වඩා වේගවත් වේ. ඒ අතරම, අපි ස්වයංක්‍රීයව යෙදවීම සඳහා අපගේම CMDB සහ වාදකයෙකු ලිවීමට පටන් ගත්තෙමු (ඉහත පින්තූරයේ ඇති Cobbler), නමුත් මෙය සම්පූර්ණයෙන්ම වෙනස් කතාවකි, එය මගේ සගයා සහ මෙම පද්ධතිවල ප්‍රධාන සංවර්ධකයා අනාගතයේදී පවසනු ඇත.

අපගේ තේරීම:

අණු + Testinfra
Ansible + Tower + AWX
වර්ල්ඩ් ඔෆ් සර්වර් + DITNET (තමන්ගේම සංවර්ධනය)
කොබ්ලර්
Gitlab + GitLab ධාවකය
Hashicorp සුරක්ෂිතාගාරය

මාර්ගය වන විට, වගකිවයුතු භූමිකාවන් ගැන. මුලදී තිබුණේ එකක් පමණි, නමුත් ප්‍රතිනිර්මාණය කිරීම් කිහිපයකට පසු ඒවායින් 17 ක් තිබුණි. මම තරයේ නිර්දේශ කරන්නේ මොනොලිත් දුර්වල භූමිකාවන් බවට පත් කරන ලෙසයි, පසුව එය වෙන වෙනම දියත් කළ හැකිය; ඊට අමතරව, ඔබට ටැග් එකතු කළ හැකිය. අපි භූමිකාවන් ක්‍රියාකාරීත්වය අනුව බෙදුවෙමු - ජාලය, ලොග් කිරීම, පැකේජ, දෘඩාංග, අණු ආදිය. පොදුවේ, අපි පහත උපාය මාර්ගය අනුගමනය කළෙමු. මෙය එකම සත්‍යය බව මම අවධාරනය නොකරමි, නමුත් එය අපට වැඩ කළේය.

• "රන් රූපය" වෙතින් සේවාදායකයන් පිටපත් කිරීම නරකයි!ප්‍රධාන අවාසිය නම්, රූප දැන් ඇත්තේ කුමන තත්වයකදැයි ඔබ හරියටම නොදන්නා අතර, සියලු අථත්‍යකරණ ගොවිපලවල ඇති සියලුම පින්තූර වෙත සියලු වෙනස්කම් පැමිණෙනු ඇත.
• පෙරනිමි වින්‍යාස ගොනු අවම වශයෙන් භාවිතා කරන්න සහ ප්‍රධාන පද්ධති ගොනු සඳහා ඔබ වගකිව යුතු වෙනත් දෙපාර්තමේන්තු සමඟ එකඟ වන්නඋදාහරණයක් ලෙස:
  1. /etc/sysctl.conf හිස්ව තබන්න, සැකසීම් /etc/sysctl.d/ හි පමණක් තිබිය යුතුය. එක් ගොනුවක ඔබගේ පෙරනිමි, තවත් ගොනුවක යෙදුම සඳහා අභිරුචි.
  2. systemd ඒකක සංස්කරණය කිරීමට override ගොනු භාවිතා කරන්න.
• සියලුම වින්‍යාසයන් අච්චු කර ඒවා සම්පූර්ණයෙන්ම ඇතුළත් කරන්න; හැකි නම්, සෙල්ලම් පොත්වල sed හෝ එහි ප්‍රතිසම නැත
• වින්‍යාස කළමනාකරණ පද්ධති කේතය නැවත සකස් කිරීම:
  1. කාර්යයන් තාර්කික ආයතනවලට කඩා ඒකලිතය භූමිකාවන්ට නැවත ලියන්න
  2. ලින්ටර් භාවිතා කරන්න! Ansible-lint, yaml-lint, ආදිය
  3. ඔබේ ප්‍රවේශය වෙනස් කරන්න! බෂ්සිබල් නැත. පද්ධතියේ තත්වය විස්තර කිරීම අවශ්ය වේ
• සියලුම Ansible භූමිකාවන් සඳහා ඔබ අණු වල පරීක්ෂණ ලිවිය යුතු අතර දිනකට වරක් වාර්තා ජනනය කළ යුතුය.
• අපගේ නඩුවේදී, පරීක්ෂණ සකස් කිරීමෙන් පසු (එයින් 100 කට වඩා වැඩි ගණනක් ඇත), දෝෂ 70000 ක් පමණ සොයා ගන්නා ලදී. එය නිවැරදි කිරීමට මාස කිහිපයක් ගත විය.

අපගේ ක්රියාත්මක කිරීම

එබැවින්, අසංඛ්‍යාත භූමිකාවන් සූදානම්, සැකිලි සහ ලින්ටර් මගින් පරීක්ෂා කරන ලදී. ඒ වගේම gits පවා හැමතැනම උස්සනවා. නමුත් විවිධ කොටස් වලට විශ්වාසනීය කේත බෙදා හැරීමේ ප්රශ්නය විවෘතව පැවතුනි. අපි ස්ක්‍රිප්ට් සමඟ සමමුහුර්ත කිරීමට තීරණය කළෙමු. පෙනෙන ආකාරයට:

වෙනස පැමිණීමෙන් පසු, CI දියත් කරනු ලැබේ, පරීක්ෂණ සේවාදායකයක් සාදනු ලැබේ, භූමිකාවන් රෝල් කරනු ලැබේ, සහ අණුව මගින් පරීක්ෂා කරනු ලැබේ. හැම දෙයක්ම හරි නම්, කේතය prod ශාඛාව වෙත යයි. නමුත් අපි යන්ත්‍රයේ පවතින සර්වර් වලට අලුත් කේතයක් යොදන්නේ නැහැ. මෙය අපගේ පද්ධතිවල ඉහළ ප්‍රයෝජනයක් සඳහා අවශ්‍ය වන නැවතුම් වර්ගයකි. යටිතල පහසුකම් විශාල වන විට, විශාල සංඛ්‍යා නීතිය ක්‍රියාත්මක වේ - වෙනස හානිකර නොවන බව ඔබට විශ්වාස වුවද, එය දරුණු ප්‍රතිවිපාකවලට තුඩු දිය හැකිය.

සේවාදායකයන් නිර්මාණය කිරීම සඳහා බොහෝ විකල්ප තිබේ. අපි අභිරුචි පයිතන් ස්ක්‍රිප්ට් තෝරාගැනීම අවසන් කළෙමු. සහ 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}}"

අප පැමිණ ඇත්තේ මෙයයි, පද්ධතිය දිගටම ජීවත් වෙමින් සංවර්ධනය වෙමින් පවතී.

• 17 සේවාදායකය පිහිටුවීම සඳහා වගකිව යුතු භූමිකාවන්. සෑම භූමිකාවක්ම වෙනම තාර්කික කාර්යයක් විසඳීම සඳහා නිර්මාණය කර ඇත (ලොග් කිරීම, විගණනය, පරිශීලක අවසරය, අධීක්ෂණය, ආදිය).
• භූමිකාව පරීක්ෂා කිරීම. අණු + TestInfra.
• තමන්ගේම සංවර්ධනය: CMDB + Orchestrator.
• සේවාදායකය සෑදීමේ කාලය මිනිත්තු ~30, ස්වයංක්‍රීය සහ කාර්ය පෝලිමෙන් ප්‍රායෝගිකව ස්වාධීන වේ.
• සියලුම අංශවල යටිතල ව්‍යුහයේ එකම තත්ත්වය/නම් කිරීම - ක්‍රීඩා පොත්, ගබඩා, අථත්‍යකරණ මූලද්‍රව්‍ය.
• ප්‍රමිතිය සමඟ ඇති නොගැලපීම් පිළිබඳ වාර්තා උත්පාදනය කිරීම සමඟ සේවාදායක තත්ත්වය දිනපතා පරීක්ෂා කිරීම.

මගේ කතාව ගමනේ ආරම්භයේ සිටින අයට ප්‍රයෝජනවත් වේ යැයි මම බලාපොරොත්තු වෙමි. ඔබ භාවිතා කරන ස්වයංක්‍රීය ස්ටැක් මොනවාද?

මූලාශ්රය: www.habr.com