Əgər İT infrastrukturunuz çox sürətlə inkişaf edirsə, gec-tez siz seçim qarşısında qalacaqsınız - onu dəstəkləmək üçün insan resurslarını xətti artırın və ya avtomatlaşdırmağa başlayın. Müəyyən bir nöqtəyə qədər biz ilk paradiqmada yaşadıq və sonra İnfrastruktur-Kod kimi uzun bir səyahət başladı.
Təbii ki, NSPK startap deyil, lakin yarandığı ilk illərdə şirkətdə belə bir atmosfer hökm sürürdü və bu illər çox maraqlı illər idi. Mənim adım , Mən 10 ildən artıqdır ki, yüksək əlçatanlıq tələbləri ilə Linux infrastrukturunu saxlayıram. O, 2016-cı ilin yanvarında NSPK komandasına qoşuldu və təəssüf ki, şirkətin mövcudluğunun ilk başlanğıcını görmədi, lakin böyük dəyişikliklər mərhələsinə gəldi.
Ümumilikdə deyə bilərik ki, komandamız şirkət üçün 2 məhsul tədarük edir. Birincisi, infrastrukturdur. Poçt getməlidir, DNS işləməlidir və domen nəzarətçiləri sizi düşməməli olan serverlərə buraxmalıdır. Şirkətin İT mənzərəsi böyükdür! Bunlar biznes və missiya üçün kritik sistemlərdir, bəziləri üçün əlçatanlıq tələbləri 99,999-dur. İkinci məhsul fiziki və virtual serverlərin özləridir. Mövcud olanlara nəzarət edilməli, yeniləri mütəmadi olaraq bir çox şöbələrdən müştərilərə çatdırılmalıdır. Bu yazıda mən serverlərin həyat dövrü üçün cavabdeh olan infrastrukturu necə inkişaf etdirdiyimizə diqqət yetirmək istəyirəm.
Bir səfər başlanğıcı
Səyahətimizin əvvəlində texnologiya yığınımız belə görünürdü:
ƏS CentOS 7
FreeIPA Domain Controllers
Avtomatlaşdırma - Ansible(+Tower), Cobbler
Bütün bunlar bir neçə məlumat mərkəzinə yayılmış 3 domendə yerləşirdi. Bir məlumat mərkəzində - ofis sistemləri və test saytları, qalanlarında - PROD.
Bir anda serverlərin yaradılması belə görünürdü:
CentOS VM şablonu minimaldır və çılpaq minimum düzgündür /etc/resolv.conf, qalanı Ansible vasitəsilə gəlir.
CMDB - Excel.
Əgər server fizikidirsə, virtual maşını kopyalamaq əvəzinə Cobbler-dən istifadə edərək OS ona quraşdırılmışdır - hədəf serverin MAC ünvanları Cobbler konfiqurasiyasına əlavə olunur, server DHCP vasitəsilə IP ünvanı alır, sonra isə ƏS. tökülür.
Əvvəlcə Cobbler-də bir növ konfiqurasiya idarəçiliyi etməyə çalışdıq. Lakin zaman keçdikcə bu, həm digər məlumat mərkəzlərinə, həm də VM hazırlamaq üçün Ansible koduna konfiqurasiyaların daşınması ilə bağlı problemlər gətirməyə başladı.
O dövrdə Ansible bir çoxumuz tərəfindən rahat Bash uzantısı kimi qəbul edildi və qabıqdan istifadə edən konstruksiyalara qənaət etmədi, sed. Ümumiyyətlə, Bashsible. Bu, nəticədə ona gətirib çıxardı ki, əgər oyun kitabı nədənsə serverdə işləməyibsə, serveri silmək, oyun kitabını düzəltmək və yenidən yuvarlamaq daha asan oldu. Əslində, skriptlərin versiyaları, konfiqurasiyaların daşınması da yox idi.
Məsələn, bütün serverlərdə bəzi konfiqurasiyaları dəyişmək istədik:
- Məntiqi seqmentdə / məlumat mərkəzində mövcud serverlərdə konfiqurasiyanı dəyişdiririk. Bəzən bir gündə deyil - mövcudluq tələbləri və çox sayda qanun bütün dəyişiklikləri bir anda tətbiq etməyə imkan vermir. Bəzi dəyişikliklər potensial olaraq dağıdıcıdır və hər hansı bir şeyin yenidən başlamasını tələb edir - xidmətlərdən tutmuş ƏS-in özünə qədər.
- Ansible-da düzəltmə
- Pinəçidə bərkitmə
- Hər məntiqi seqment/məlumat mərkəzi üçün N dəfə təkrarlayın
Bütün dəyişikliklərin rəvan getməsi üçün bir çox amillər nəzərə alınmalı idi və dəyişikliklər hər zaman baş verir.
- Ansible kodun, konfiqurasiya fayllarının refaktorinqi
- Daxili ən yaxşı təcrübələrin dəyişdirilməsi
- Hadisələrin/qəzaların təhlilindən sonra dəyişikliklər
- Həm daxili, həm də xarici təhlükəsizlik standartlarının dəyişdirilməsi. Məsələn, PCI DSS hər il yeni tələblərlə yenilənir.
İnfrastrukturun böyüməsi və səyahətin başlanğıcı
Serverlərin / məntiqi domenlərin / məlumat mərkəzlərinin sayı və onlarla birlikdə konfiqurasiyalarda səhvlərin sayı artdı. Bir anda konfiqurasiya idarəetməsini inkişaf etdirməli olduğumuz istiqamətdə üç istiqamətə gəldik:
- Avtomatlaşdırma. Mümkün qədər təkrarlanan əməliyyatlarda insan səhvindən qaçınmaq lazımdır.
- Təkrarlanma qabiliyyəti. İnfrastruktur proqnozlaşdırıla bilən olduqda onu idarə etmək daha asandır. Serverlərin konfiqurasiyası və onların hazırlanması üçün alətlər hər yerdə eyni olmalıdır. Bu, məhsul qrupları üçün də vacibdir - sınaqdan sonra tətbiqin test mühitinə bənzər şəkildə konfiqurasiya edilmiş məhsuldar mühitə daxil olmasına zəmanət verilməlidir.
- Konfiqurasiyanın idarə edilməsində dəyişikliklərin sadəliyi və şəffaflığı.
Bir neçə alət əlavə etmək qalır.
Biz GitLab CE-ni kod anbarımız kimi seçdik, ən azı onun daxili CI/CD modulları üçün.
Sirlər anbarı - Hashicorp Vault, daxil olmaqla. böyük API üçün.
Test konfiqurasiyaları və uyğun rollar - Molecule+Testinfra. Anlaşılabilir mitogenə qoşulsanız, testlər daha sürətli gedir. Paralel olaraq, biz öz CMDB və avtomatik yerləşdirmə üçün orkestr yazmağa başladıq (Cobbler-in yuxarıda təsviri), lakin bu, mənim həmkarımın və bu sistemlərin əsas tərtibatçısının gələcəkdə danışacağı tamamilə fərqli bir hekayədir.
Bizim seçimimiz:
Molekul + Testinfra
Ansible + Tower + AWX
Serverlər Dünyası + DITNET (Öz inkişafı)
Çəkic
Gitlab + GitLab qaçışı
Hashicorp Vault
Yeri gəlmişkən, məqbul rollar haqqında. Əvvəlcə tək idi, bir neçə refaktorinqdən sonra onlardan 17-si oldu.Mən monoliti idempotent rollara bölməyi şiddətlə tövsiyə edirəm, daha sonra ayrıca işlədilə bilər, əlavə olaraq teqlər əlavə edə bilərsiniz. Rolları funksionallığa görə böldük - şəbəkə, giriş, paketlər, aparat, molekul və s. Ümumiyyətlə, aşağıdakı strategiyaya əməl olunur. Mən təkid etmirəm ki, bu, bir halda ki, həqiqətdir, amma bu, bizim üçün işlədi.
- Qızıl görüntüdən serverləri kopyalamaq pisdir!Əsas çatışmazlıqlardan - şəkillərin indi hansı vəziyyətdə olduğunu və bütün dəyişikliklərin bütün virtuallaşdırma təsərrüfatlarında bütün şəkillərə gələcəyini dəqiq bilmirsiniz.
- Standart konfiqurasiya fayllarını minimuma endirin və əsas sistem fayllarına cavabdeh olduğunuz digər şöbələrlə razılaşın, məsələn:
- /etc/sysctl.conf boş buraxın, parametrlər yalnız /etc/sysctl.d/ daxilində olmalıdır. Bir faylda defoltunuz, digərində tətbiq üçün fərdi.
- Sistem vahidlərini redaktə etmək üçün ləğvetmə fayllarından istifadə edin.
- Bütün konfiqurasiyaları şablonlaşdırın və onları tam şəkildə yerləşdirin, mümkünsə, sed və onun analoqlarını oyun kitablarında yerləşdirin
- Konfiqurasiya idarəetmə sistemi kodunun yenidən qurulması:
- Tapşırıqları məntiqi varlıqlara bölün və monoliti rollara yenidən yazın
- Linterlərdən istifadə edin! Ansible-lint, yaml-lint və s
- Yanaşmanızı dəyişdirin! Etiraz yoxdur. Sistemin vəziyyətini təsvir edin
- Bütün Ansible rolları üçün siz molekulda testlər yazmalı və gündə bir dəfə hesabatlar yaratmalısınız.
- Bizim vəziyyətimizdə testlər hazırlandıqdan sonra (onların sayı 100-dən çoxdur) təxminən 70000 səhv aşkar edilmişdir. Bir neçə aya düzəldildi.
Bizim həyata keçirməmiz
Beləliklə, ansible rollar hazır idi, şablonlaşdırıldı və linters tərəfindən yoxlanıldı. Və hətta gits hər yerdə qaldırılır. Lakin kodun müxtəlif seqmentlərə etibarlı çatdırılması məsələsi açıq qaldı. Skriptlərlə sinxronizasiya etmək qərarına gəldik. Belə görünür:
Dəyişiklik gəldikdən sonra CI işə salınır, test serveri yaradılır, rollar yuvarlanır, molekul tərəfindən sınaqdan keçirilir. Hər şey qaydasındadırsa, kod pro filialına gedir. Lakin biz avtomatik olaraq mövcud serverlərə yeni kodu tətbiq etmirik. Bu, sistemlərimizin yüksək əlçatanlığı üçün zəruri olan bir növ dayandırıcıdır. İnfrastruktur nəhəng olduqda, böyük rəqəmlər qanunu işə düşür - hətta dəyişikliyin zərərsiz olduğuna əmin olsanız belə, bu, kədərli nəticələrə səbəb ola bilər.
Server yaratmaq üçün bir çox variant da var. Xüsusi python skriptlərini seçdik. Və CI ansible üçün:
- 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}}"Gəldiyimiz budur, sistem yaşamağa və inkişaf etməyə davam edir.
- Server qurmaq üçün 17 əsas rol. Rolların hər biri ayrıca məntiqi vəzifəni həll etmək üçün nəzərdə tutulmuşdur (giriş, audit, istifadəçi icazəsi, monitorinq və s.).
- Rol testi. Molekul + Test İnfra.
- Öz inkişafı: CMDB + Orchestrator.
- Serverin yaradılması vaxtı ~30 dəqiqədir, avtomatlaşdırılmışdır və praktiki olaraq tapşırıq növbəsindən asılı deyil.
- Bütün seqmentlərdə infrastrukturun eyni vəziyyəti / adlandırılması - oyun kitabları, depolar, virtuallaşdırma elementləri.
- Standartla uyğunsuzluqlar haqqında hesabatların yaradılması ilə serverlərin vəziyyətinin gündəlik yoxlanılması.
Ümid edirəm ki, hekayəm səyahətin əvvəlində olanlar üçün faydalı olacaq. Hansı avtomatlaşdırma yığınından istifadə edirsiniz?
Mənbə: www.habr.com