„დაწყებიდან“ ათასობით სერვერამდე ათეულ მონაცემთა ცენტრში. როგორ ვიდევნეთ Linux ინფრასტრუქტურის ზრდას

თუ თქვენი IT ინფრასტრუქტურა ძალიან სწრაფად იზრდება, ადრე თუ გვიან არჩევანის წინაშე დადგებით: ხაზოვანი გაზარდოთ ადამიანური რესურსები მის მხარდასაჭერად ან დაიწყოთ ავტომატიზაცია. რაღაც მომენტამდე ჩვენ ვცხოვრობდით პირველ პარადიგმაში და შემდეგ დაიწყო გრძელი გზა ინფრასტრუქტურა-როგორც კოდისკენ.

რა თქმა უნდა, NSPK არ არის სტარტაპი, მაგრამ ასეთი ატმოსფერო სუფევდა კომპანიაში არსებობის პირველ წლებში და ეს იყო ძალიან საინტერესო წლები. Მე მქვია დიმიტრი კორნიაკოვი, მე მხარს ვუჭერ Linux ინფრასტრუქტურას მაღალი ხელმისაწვდომობის მოთხოვნებით 10 წელზე მეტი ხნის განმავლობაში. ის შეუერთდა NSPK გუნდს 2016 წლის იანვარში და, სამწუხაროდ, არ უნახავს კომპანიის არსებობის დასაწყისი, მაგრამ მოვიდა დიდი ცვლილებების ეტაპზე.

ზოგადად, შეგვიძლია ვთქვათ, რომ ჩვენი გუნდი აწვდის 2 პროდუქტს კომპანიისთვის. პირველი არის ინფრასტრუქტურა. ფოსტამ უნდა იმუშაოს, DNS უნდა იმუშაოს და დომენის კონტროლერებმა უნდა შეგეშვათ სერვერებზე, რომლებიც არ უნდა დაირღვეს. კომპანიის IT ლანდშაფტი უზარმაზარია! ეს არის ბიზნესისა და მისიის კრიტიკული სისტემები, ზოგიერთისთვის ხელმისაწვდომობის მოთხოვნები არის 99,999. მეორე პროდუქტი არის თავად სერვერები, ფიზიკური და ვირტუალური. არსებულის მონიტორინგი უნდა მოხდეს და ახლები რეგულარულად უნდა მიეწოდოს მომხმარებელს მრავალი დეპარტამენტიდან. ამ სტატიაში მინდა გავამახვილო ყურადღება იმაზე, თუ როგორ განვავითარეთ ინფრასტრუქტურა, რომელიც პასუხისმგებელია სერვერის სასიცოცხლო ციკლზე.

დასაწყისი მოგზაურობა

ჩვენი მოგზაურობის დასაწყისში ჩვენი ტექნოლოგიური დასტა ასე გამოიყურებოდა:
OS CentOS 7
FreeIPA დომენის კონტროლერები
ავტომატიზაცია - Ansible(+Tower), Cobbler

ეს ყველაფერი განთავსებული იყო 3 დომენში, გავრცელდა რამდენიმე მონაცემთა ცენტრში. ერთ მონაცემთა ცენტრში არის საოფისე სისტემები და სატესტო ადგილები, დანარჩენში არის PROD.

სერვერების შექმნა ერთ მომენტში ასე გამოიყურებოდა:

VM შაბლონში, CentOS მინიმალურია და საჭირო მინიმუმი არის სწორი /etc/resolv.conf, დანარჩენი მოდის Ansible-ის საშუალებით.

CMDB - Excel.

თუ სერვერი ფიზიკურია, მაშინ ვირტუალური მანქანის კოპირების ნაცვლად, მასზე OS დაინსტალირებული იყო Cobbler-ის გამოყენებით - სამიზნე სერვერის MAC მისამართები ემატება Cobbler კონფიგურაციას, სერვერი იღებს IP მისამართს DHCP-ის საშუალებით, შემდეგ კი OS-ს. ემატება.

თავიდან ჩვენ ვცდილობდით გაგვეკეთებინა რაიმე სახის კონფიგურაციის მართვა Cobbler-ში. მაგრამ დროთა განმავლობაში, ამან დაიწყო პრობლემები კონფიგურაციის პორტაბელურობასთან დაკავშირებით, როგორც სხვა მონაცემთა ცენტრებში, ასევე VM-ების მომზადების Ansible კოდში.

იმ დროს ბევრი ჩვენგანი აღიქვამდა Ansible-ს, როგორც Bash-ის მოსახერხებელ გაფართოებას და არ იკლებდა დიზაინს shell-ისა და sed-ის გამოყენებით. საერთო Bashsible. ამან საბოლოოდ განაპირობა ის, რომ თუ სათამაშო წიგნი რაიმე მიზეზით არ მუშაობდა სერვერზე, უფრო ადვილი იყო სერვერის წაშლა, დაკვრის წიგნის დაფიქსირება და ხელახლა გაშვება. არსებითად არ არსებობდა სკრიპტების ვერსიირება, კონფიგურაციების პორტაბელურობა.

მაგალითად, ჩვენ გვინდოდა შეგვეცვალა გარკვეული კონფიგურაცია ყველა სერვერზე:

1. ჩვენ ვცვლით კონფიგურაციას არსებულ სერვერებზე ლოგიკურ სეგმენტში/მონაცემთა ცენტრში. ზოგჯერ არა ერთ დღეში - ხელმისაწვდომობის მოთხოვნები და დიდი რიცხვების კანონი არ იძლევა ყველა ცვლილების ერთდროულად გამოყენების საშუალებას. და ზოგიერთი ცვლილება პოტენციურად დესტრუქციულია და მოითხოვს რაღაცის გადატვირთვას - სერვისებიდან თავად OS-მდე.
2. მისი დაფიქსირება Ansible-ში
3. ჩვენ ვასწორებთ მას Cobbler-ში
4. გაიმეორეთ N ჯერ თითოეული ლოგიკური სეგმენტისთვის/მონაცემთა ცენტრისთვის

იმისათვის, რომ ყველა ცვლილება შეუფერხებლად წასულიყო, საჭირო იყო მრავალი ფაქტორის გათვალისწინება და ცვლილებები მუდმივად ხდება.

• ასახული კოდის, კონფიგურაციის ფაილების რეფაქტორირება
• შიდა საუკეთესო პრაქტიკის შეცვლა
• ცვლილებები ინციდენტების/ავარიების ანალიზის შედეგებზე დაყრდნობით
• უსაფრთხოების სტანდარტების შეცვლა, როგორც შიდა, ასევე გარე. მაგალითად, PCI DSS ყოველწლიურად განახლდება ახალი მოთხოვნებით

ინფრასტრუქტურის ზრდა და მოგზაურობის დასაწყისი

გაიზარდა სერვერების/ლოგიკური დომენების/მონაცემთა ცენტრების რაოდენობა და მათთან ერთად გაიზარდა შეცდომების რაოდენობა კონფიგურაციებში. რაღაც მომენტში მივედით სამ მიმართულებამდე, რომლებშიც კონფიგურაციის მენეჯმენტი უნდა განვითარდეს:

1. ავტომატიზაცია. ადამიანური შეცდომები განმეორებით ოპერაციებში მაქსიმალურად უნდა იქნას აცილებული.
2. განმეორებადობა. გაცილებით ადვილია ინფრასტრუქტურის მართვა, როცა ის პროგნოზირებადია. სერვერებისა და მათი მომზადების ხელსაწყოების კონფიგურაცია ყველგან ერთნაირი უნდა იყოს. ეს ასევე მნიშვნელოვანია პროდუქტის გუნდებისთვის - ტესტირების შემდეგ, აპლიკაცია გარანტირებული უნდა იყოს, რომ აღმოჩნდეს საწარმოო გარემოში, რომელიც კონფიგურირებულია ტესტის გარემოს ანალოგიურად.
3. კონფიგურაციის მენეჯმენტში ცვლილებების შეტანის სიმარტივე და გამჭვირვალობა.

რჩება რამდენიმე ხელსაწყოს დამატება.

ჩვენ ავირჩიეთ GitLab CE, როგორც ჩვენი კოდის საცავი, განსაკუთრებით მისი ჩაშენებული CI/CD მოდულებისთვის.

საიდუმლოების სარდაფი - Hashicorp Vault, ჩათვლით. დიდი API-სთვის.

ტესტირების კონფიგურაციები და პასუხისმგებელი როლები - Molecule+Testinfra. ტესტები ბევრად უფრო სწრაფად მიდის, თუ დაუკავშირდებით მდგრად მიტოგენს. ამავდროულად, ჩვენ დავიწყეთ საკუთარი CMDB და ორკესტრის დაწერა ავტომატური განლაგებისთვის (სურათზე ზემოთ Cobbler), მაგრამ ეს არის სრულიად განსხვავებული ამბავი, რომელსაც ჩემი კოლეგა და ამ სისტემების მთავარი დეველოპერი მომავალში მოგიყვებათ.

ჩვენი არჩევანი:

მოლეკულა + ტესტინფრა
Ansible + Tower + AWX
სერვერების სამყარო + DITNET (საკუთარი განვითარება)
კობლლერი
Gitlab + GitLab მორბენალი
Hashicorp Vault

სხვათა შორის, გონივრული როლების შესახებ. თავიდან იყო მხოლოდ ერთი, მაგრამ რამდენიმე რეფაქტორინგის შემდეგ იყო 17. კატეგორიულად გირჩევთ მონოლითის დაშლას იდემპოტენტურ როლებად, რომლებიც შემდეგ შეიძლება ცალკე გაუშვათ; დამატებით შეგიძლიათ დაამატოთ ტეგები. ჩვენ დავყავით როლები ფუნქციონალურობის მიხედვით - ქსელი, ლოგინგი, პაკეტები, აპარატურა, მოლეკულა და ა.შ. ზოგადად, ჩვენ მივყვეთ ქვემოთ მოცემულ სტრატეგიას. მე არ ვამტკიცებ, რომ ეს ერთადერთი ჭეშმარიტებაა, მაგრამ ეს ჩვენთვის მუშაობდა.

• სერვერების კოპირება "ოქროს სურათიდან" ბოროტებაა!მთავარი მინუსი არის ის, რომ თქვენ არ იცით ზუსტად რა მდგომარეობაშია სურათები ახლა და რომ ყველა ცვლილება მოვა ყველა სურათზე ყველა ვირტუალიზაციის ფერმაში.
• გამოიყენეთ ნაგულისხმევი კონფიგურაციის ფაილები მინიმუმამდე და დაეთანხმეთ სხვა განყოფილებებს, რომ პასუხისმგებელი ხართ სისტემის მთავარ ფაილებზე, მაგალითად:
  1. დატოვეთ /etc/sysctl.conf ცარიელი, პარამეტრები უნდა იყოს მხოლოდ /etc/sysctl.d/-ში. თქვენი ნაგულისხმევი ერთ ფაილში, მორგებულია აპლიკაციისთვის მეორეში.
  2. გამოიყენეთ უგულებელყოფილი ფაილები სისტემური ერთეულების რედაქტირებისთვის.
• შექმენით ყველა კონფიგურაციის შაბლონი და მთლიანად ჩართეთ ისინი; თუ შესაძლებელია, არ sed ან მისი ანალოგები სათამაშო წიგნებში
• კონფიგურაციის მართვის სისტემის კოდის რეფაქტორირება:
  1. დაყავით ამოცანები ლოგიკურ ერთეულებად და გადაწერეთ მონოლითი როლებად
  2. გამოიყენეთ ლინტერები! Ansible-lint, yaml-lint და ა.შ
  3. შეცვალეთ თქვენი მიდგომა! არა საზიზღარი. აუცილებელია სისტემის მდგომარეობის აღწერა
• Ansible-ის ყველა როლისთვის თქვენ უნდა დაწეროთ ტესტები მოლეკულაში და შექმნათ მოხსენებები დღეში ერთხელ.
• ჩვენს შემთხვევაში, ტესტების მომზადების შემდეგ (რომლებიც 100-ზე მეტია), დაახლოებით 70000 XNUMX შეცდომა იქნა ნაპოვნი. მის გამოსწორებას რამდენიმე თვე დასჭირდა.

ჩვენი განხორციელება

ასე რომ, გონივრული როლები მზად იყო, შაბლონი და შემოწმებული ლინტერებით. და გიტებიც კი ყველგან ამაღლებულია. მაგრამ სხვადასხვა სეგმენტზე კოდის საიმედო მიწოდების საკითხი ღია დარჩა. გადავწყვიტეთ სკრიპტებთან სინქრონიზაცია. ასე გამოიყურება:

ცვლილების მოსვლის შემდეგ, CI ამოქმედდება, იქმნება სატესტო სერვერი, როლები იშლება და მოლეკულა შემოწმდება. თუ ყველაფერი წესრიგშია, კოდი გადადის პროდ ფილიალში. მაგრამ ჩვენ არ ვიყენებთ ახალ კოდს აპარატში არსებულ სერვერებზე. ეს არის ერთგვარი საცობი, რომელიც აუცილებელია ჩვენი სისტემების მაღალი ხელმისაწვდომობისთვის. და როდესაც ინფრასტრუქტურა უზარმაზარი ხდება, დიდი რიცხვების კანონი მოქმედებს - მაშინაც კი, თუ დარწმუნებული ხართ, რომ ცვლილება უვნებელია, ამან შეიძლება გამოიწვიოს საშინელი შედეგები.

ასევე ბევრი ვარიანტია სერვერების შესაქმნელად. ჩვენ დავასრულეთ პითონის პერსონალური სკრიპტების არჩევა. და CI ანსიბილისთვის:

- 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 + ორკესტრი.
• სერვერის შექმნის დრო არის ~ 30 წუთი, ავტომატიზირებული და პრაქტიკულად დამოუკიდებელი დავალების რიგისგან.
• ინფრასტრუქტურის ერთი და იგივე მდგომარეობა/დასახელება ყველა სეგმენტში - სათამაშო წიგნები, საცავი, ვირტუალიზაციის ელემენტები.
• სერვერის სტატუსის ყოველდღიური შემოწმება სტანდარტთან შეუსაბამობის შესახებ მოხსენებების გენერირებით.

იმედი მაქვს, რომ ჩემი ისტორია გამოადგება მათთვის, ვინც მოგზაურობის დასაწყისშია. რა ავტომატიზაციის დასტას იყენებთ?

წყარო: www.habr.com