Yeni il yaxınlaşırdı. Ölkənin hər yerində uşaqlar artıq Şaxta babaya məktublar göndərmişdilər və ya özləri üçün hədiyyələr hazırlamışdılar və onların əsas icraçısı, əsas pərakəndə satıcılardan biri satışın apoteozuna hazırlaşırdı. Dekabr ayında onun data mərkəzinə yük bir neçə dəfə artır. Buna görə də şirkət data mərkəzini modernləşdirmək və istismar müddətini başa vurmaqda olan avadanlıqların əvəzinə onlarla yeni serveri istifadəyə vermək qərarına gəlib. Bu, fırlanan qar dənələrinin fonunda nağılı bitirir və triller başlayır.
Avadanlıq satışların pik nöqtəsindən bir neçə ay əvvəl əraziyə gəlib. Əməliyyatlar xidməti, əlbəttə ki, onları istehsal mühitinə gətirmək üçün serverlərdə necə və nəyi konfiqurasiya edəcəyini bilir. Amma biz bunu avtomatlaşdırıb insan amilini aradan qaldırmalıydıq. Bundan əlavə, serverlər şirkət üçün vacib olan bir sıra SAP sistemlərinin miqrasiyasından əvvəl dəyişdirilib.
Yeni serverlərin istismara verilməsi ciddi şəkildə son tarixlə bağlı idi. Və onu köçürmək həm bir milyard hədiyyənin daşınmasını, həm də sistemlərin miqrasiyasını təhlükə altına almaq demək idi. Hətta Şaxta baba və Şaxta babadan ibarət komanda tarixi dəyişdirə bilmədi - SAP sistemini ildə bir dəfə anbar idarəçiliyinə köçürə bilərsiniz. Dekabrın 31-dən yanvarın 1-dək pərakəndə satış şirkətinin ümumilikdə 20 futbol meydançası olan nəhəng anbarları 15 saat işini dayandırır. Və bu, sistemin hərəkəti üçün yeganə müddətdir. Serverləri təqdim edərkən xətaya yerimiz yox idi.
Açıq deyim: hekayəm komandamızın istifadə etdiyi alətləri və konfiqurasiya idarəetmə prosesini əks etdirir.
Konfiqurasiya idarəetmə kompleksi bir neçə səviyyədən ibarətdir. Əsas komponent CMS sistemidir. Sənaye əməliyyatında səviyyələrdən birinin olmaması qaçılmaz olaraq xoşagəlməz möcüzələrə səbəb olardı.
OS quraşdırma idarəetməsi
Birinci səviyyə fiziki və virtual serverlərdə əməliyyat sistemlərinin quraşdırılmasının idarə edilməsi sistemidir. O, insan amilini aradan qaldıraraq əsas ƏS konfiqurasiyalarını yaradır.
Bu sistemdən istifadə edərək, biz sonrakı avtomatlaşdırma üçün uyğun olan OS ilə standart server nümunələri aldıq. “Tökmə” zamanı onlar minimum yerli istifadəçilər dəsti və ictimai SSH açarları, həmçinin ardıcıl OS konfiqurasiyası aldılar. Bizə CMS vasitəsilə serverləri idarə etməyə zəmanət verildi və ƏS səviyyəsində “aşağıda” sürprizlərin olmadığına əmin olduq.
Quraşdırma idarəetmə sistemi üçün "maksimum" vəzifə serverləri BIOS/Firmware səviyyəsindən ƏS-ə avtomatik konfiqurasiya etməkdir. Burada çox şey avadanlıq və quraşdırma tapşırıqlarından asılıdır. Heterojen avadanlıqlar üçün nəzərdən keçirə bilərsiniz . Əgər bütün avadanlıq bir satıcıdandırsa, o zaman hazır idarəetmə vasitələrindən (məsələn, HP ILO Amplifier, DELL OpenManage və s.) istifadə etmək çox vaxt daha rahatdır.
ƏS-ni fiziki serverlərə quraşdırmaq üçün əməliyyat xidməti ilə razılaşdırılmış quraşdırma profilləri dəstini təyin edən məşhur Cobbler-dən istifadə etdik. İnfrastruktura yeni server əlavə edərkən mühəndis serverin MAC ünvanını Cobbler-də tələb olunan profilə bağladı. Şəbəkə üzərindən ilk dəfə yüklənərkən, server müvəqqəti ünvan və təzə OS aldı. Daha sonra hədəf VLAN/IP ünvanlanmasına köçürüldü və orada iş davam etdirildi. Bəli, VLAN-ın dəyişdirilməsi vaxt tələb edir və koordinasiya tələb edir, lakin o, serverin istehsal mühitində təsadüfən quraşdırılmasına qarşı əlavə qoruma təmin edir.
HashiСorp Packer istifadə edərək hazırlanmış şablonlar əsasında virtual serverlər yaratdıq. Səbəb eyni idi: OS quraşdırarkən mümkün insan səhvlərinin qarşısını almaq. Lakin, fiziki serverlərdən fərqli olaraq, Packer PXE, şəbəkə yüklənməsi və VLAN dəyişikliklərinə ehtiyacı aradan qaldırır. Bu, virtual serverlər yaratmağı asanlaşdırdı və sadələşdirdi.
düyü. 1. Əməliyyat sistemlərinin quraşdırılmasının idarə edilməsi.
Sirləri idarə etmək
İstənilən konfiqurasiya idarəetmə sistemi adi istifadəçilərdən gizlədilməli, lakin sistemlərin hazırlanması üçün lazım olan məlumatları ehtiva edir. Bunlar yerli istifadəçilər və xidmət hesabları üçün parollar, sertifikat açarları, müxtəlif API Tokenləri və s. Onlar adətən “sirrlər” adlanır.
Bu sirlərin harada və necə saxlanacağını əvvəldən müəyyənləşdirməsəniz, məlumat təhlükəsizliyi tələblərinin şiddətindən asılı olaraq, aşağıdakı saxlama üsulları ehtimal olunur:
- birbaşa konfiqurasiya nəzarət kodunda və ya depodakı fayllarda;
- xüsusi konfiqurasiya idarəetmə vasitələrində (məsələn, Ansible Vault);
- CI/CD sistemlərində (Jenkins/TeamCity/GitLab/və s.) və ya konfiqurasiya idarəetmə sistemlərində (Ansible Tower/Ansible AWX);
- sirlər də “əl ilə” ötürülə bilər. Məsələn, onlar müəyyən bir yerə yerləşdirilir və sonra konfiqurasiya idarəetmə sistemləri tərəfindən istifadə olunur;
- yuxarıda göstərilənlərin müxtəlif birləşmələri.
Hər bir metodun öz mənfi cəhətləri var. Əsas odur ki, sirrlərə daxil olmaq üçün siyasətin olmaması: müəyyən sirlərdən kimin istifadə edə biləcəyini müəyyən etmək mümkün deyil və ya çətindir. Digər çatışmazlıq giriş auditinin və tam həyat dövrünün olmamasıdır. Məsələn, kodda və bir sıra əlaqəli sistemlərdə yazılmış açıq açarı necə tez əvəz etmək olar?
Biz mərkəzləşdirilmiş gizli saxlama HashiCorp Vault-dan istifadə etdik. Bu bizə imkan verdi:
- sirləri qoruyun. Onlar şifrələnir və kimsə Vault verilənlər bazasına giriş əldə etsə belə (məsələn, onu ehtiyat nüsxədən bərpa etməklə), orada saxlanılan sirləri oxuya bilməyəcək;
- sirrlərə daxil olmaq üçün siyasət təşkil edir. İstifadəçilər və tətbiqlər üçün yalnız onlara "ayrılmış" sirlər mövcuddur;
- sirrlərə audit girişi. Gizli olan hər hansı hərəkətlər Vault audit jurnalında qeyd olunur;
- sirlərlə işləmək üçün tam hüquqlu bir "həyat dövrü" təşkil edin. Onlar yaradıla, ləğv edilə, istifadə müddəti təyin edilə və s.
- sirrlərə giriş tələb edən digər sistemlərlə asan inteqrasiya;
- və həmçinin uç-to-end şifrələmə, ƏS və verilənlər bazası üçün birdəfəlik parollar, səlahiyyətli mərkəzlərin sertifikatları və s.
İndi mərkəzi autentifikasiya və avtorizasiya sisteminə keçək. Onsuz etmək mümkün idi, lakin bir çox əlaqəli sistemlərdə istifadəçiləri idarə etmək çox əhəmiyyətsizdir. Biz LDAP xidməti vasitəsilə autentifikasiya və avtorizasiyanı konfiqurasiya etmişik. Əks halda, Vault davamlı olaraq istifadəçilər üçün autentifikasiya nişanlarını buraxmalı və izləməli olacaq. İstifadəçiləri silmək və əlavə etmək isə “mən bu istifadəçi hesabını hər yerdə yaratmışam/silmişəm?” sualına çevriləcək.
Sistemimizə başqa səviyyə əlavə edirik: sirlərin idarə edilməsi və mərkəzi autentifikasiya/avtorizasiya:
düyü. 2. Sirlərin idarə edilməsi.
Konfiqurasiyanın idarə edilməsi
Özümüzə - CMS sisteminə gəldik. Bizim vəziyyətimizdə bu, Ansible və Red Hat Ansible AWX-in birləşməsidir.
Ansible əvəzinə Chef, Puppet, SaltStack istifadə edilə bilər. Biz Ansible-ı bir neçə meyar əsasında seçdik.
- Birincisi, çox yönlüdür. Nəzarət üçün hazır modullar dəsti . Əgər kifayət qədər məlumatınız yoxdursa, GitHub və Galaxy-də axtarış edə bilərsiniz.
- İkincisi, idarə olunan avadanlıqda agentləri quraşdırmaq və dəstəkləmək, onların yükə müdaxilə etmədiyini sübut etmək və "əlfəcinlərin" olmamasını təsdiqləmək lazım deyil.
- Üçüncüsü, Ansible-in giriş üçün aşağı maneəsi var. Bacarıqlı mühəndis məhsulla işlədiyi ilk gündə sözün həqiqi mənasında işləyən bir oyun kitabı yazacaq.
Amma istehsal mühitində tək Ansible bizim üçün kifayət etmədi. Əks halda, girişin məhdudlaşdırılması və idarəçilərin hərəkətlərinin yoxlanılması ilə bağlı bir çox problemlər yaranacaq. Girişi necə məhdudlaşdırmaq olar? Axı, hər bir şöbə üçün "öz" server dəstini idarə etmək (oxu: Ansible oyun kitabını işə salmaq) lazım idi. Yalnız müəyyən işçilərin xüsusi Ansible oyun kitablarını işlətməsinə necə icazə vermək olar? Və ya Ansible ilə işləyən serverlər və avadanlıqlar haqqında çoxlu yerli biliklər yaratmadan oyun kitabını kimin işə saldığını necə izləmək olar?
Belə məsələlərin aslan payını Red Hat həll edir , və ya onun açıq mənbəli yuxarı layihəsi . Ona görə də müştəriyə üstünlük verdik.
Və CMS sistemimizin portretinə daha bir toxunuş. Ansible playbook kod anbarının idarəetmə sistemlərində saxlanmalıdır. Bizdə var .
Beləliklə, konfiqurasiyaların özləri Ansible/Ansible AWX/GitLab kombinasiyası ilə idarə olunur (bax. Şəkil 3). Əlbəttə ki, AWX/GitLab vahid autentifikasiya sistemi ilə, Ansible playbook isə HashiCorp Vault ilə inteqrasiya olunub. Konfiqurasiyalar istehsal mühitinə yalnız bütün “oyun qaydaları”nın göstərildiyi Ansible AWX vasitəsilə daxil olur: kim nəyi konfiqurasiya edə bilər, CMS üçün konfiqurasiya idarəetmə kodunu haradan əldə etmək olar və s.
düyü. 3. Konfiqurasiyanın idarə edilməsi.
Test idarəetməsi
Konfiqurasiyamız kod şəklində təqdim olunur. Buna görə də, proqram tərtibatçıları ilə eyni qaydalarla oynamaq məcburiyyətindəyik. Biz istehsal serverlərinə konfiqurasiya kodunun inkişafı, davamlı sınaqdan keçirilməsi, çatdırılması və tətbiqi proseslərini təşkil etməli idik.
Bu dərhal edilməsə, konfiqurasiya üçün yazılmış rollar ya dəstəklənməyi və dəyişdirilməyi dayandıracaq, ya da istehsala buraxılmayacaq. Bu ağrının müalicəsi məlumdur və bu layihədə özünü sübut etdi:
- hər bir rol vahid testlərlə əhatə olunur;
- konfiqurasiyaları idarə edən kodda hər hansı dəyişiklik olduqda testlər avtomatik olaraq həyata keçirilir;
- konfiqurasiya idarəetmə kodunda dəyişikliklər yalnız bütün testlərdən və kodun nəzərdən keçirilməsindən uğurla keçdikdən sonra istehsal mühitinə buraxılır.
Kodun inkişafı və konfiqurasiyanın idarə edilməsi daha sakit və proqnozlaşdırıla bilən hala gəldi. Davamlı testləri təşkil etmək üçün GitLab CI/CD alət dəstindən istifadə etdik və götürdük .
Konfiqurasiya idarəetmə kodunda dəyişiklik olduqda, GitLab CI/CD Molekulu çağırır:
- kod sintaksisini yoxlayır,
- Docker konteynerini qaldırır,
- dəyişdirilmiş kodu yaradılmış konteynerə tətbiq edir,
- rolu idempotentliyə görə yoxlayır və bu kod üçün testlər aparır (burada qranularlıq əsas rol səviyyəsindədir, Şəkil 4-ə baxın).
Biz Ansible AWX istifadə edərək konfiqurasiyaları istehsal mühitinə çatdırdıq. Əməliyyat mühəndisləri əvvəlcədən təyin edilmiş şablonlar vasitəsilə konfiqurasiya dəyişikliklərini tətbiq etdilər. AWX hər dəfə istifadə edildikdə GitLab master filialından kodun ən son versiyasını müstəqil olaraq “tələb etdi”. Beləliklə, istehsal mühitində sınaqdan keçirilməmiş və ya köhnəlmiş kodun istifadəsini istisna etdik. Təbii ki, kod master filialına yalnız sınaqdan keçirildikdən, nəzərdən keçirildikdən və təsdiqləndikdən sonra daxil oldu.
düyü. 4. GitLab CI/CD-də rolların avtomatik sınaqdan keçirilməsi.
İstehsal sistemlərinin işləməsi ilə bağlı problem də var. Real həyatda yalnız CMS kodu vasitəsilə konfiqurasiya dəyişiklikləri etmək çox çətindir. Mühəndis kodun redaktəsini, sınaqdan keçirilməsini, təsdiqini və s. gözləmədən konfiqurasiyanı "burada və indi" dəyişdirməli olduğu zaman fövqəladə vəziyyətlər yaranır.
Nəticədə, əl ilə edilən dəyişikliklərə görə, eyni tipli avadanlıqda konfiqurasiyada uyğunsuzluqlar görünür (məsələn, sysctl parametrləri HA klaster qovşaqlarında fərqli şəkildə konfiqurasiya edilir). Və ya avadanlıqdakı faktiki konfiqurasiya CMS kodunda göstəriləndən fərqlidir.
Buna görə də, davamlı sınaqdan əlavə, konfiqurasiya uyğunsuzluqları üçün istehsal mühitini yoxlayırıq. Ən sadə variantı seçdik: CMS konfiqurasiya kodunu "quru qaçış" rejimində, yəni dəyişikliklər tətbiq etmədən, lakin planlaşdırılmış və faktiki konfiqurasiya arasındakı bütün uyğunsuzluqlar barədə bildirişlə işlətmək. Biz bunu istehsal serverlərində “-yoxla” seçimi ilə bütün Ansible oyun kitablarını vaxtaşırı işlətməklə həyata keçirdik. Həmişə olduğu kimi, Ansible AWX oyun kitabının işə salınması və yenilənməsi üçün cavabdehdir (bax. Şəkil 5):
düyü. 5. Ansible AWX-də konfiqurasiya uyğunsuzluqlarını yoxlayır.
Yoxlamalardan sonra AWX administratorlara uyğunsuzluq hesabatı göndərir. Problemli konfiqurasiyanı öyrənirlər və sonra düzəliş edilmiş oyun kitabları vasitəsilə düzəldirlər. İstehsal mühitində konfiqurasiyanı belə qoruyuruq və CMS həmişə yenilənir və sinxronlaşdırılır. Bu, "istehsal" serverlərində CMS kodu istifadə edildikdə xoşagəlməz "möcüzələri" aradan qaldırır.
İndi bizim Ansible AWX/GitLab/Molecule-dən ibarət mühüm sınaq qatımız var (Şəkil 6).
düyü. 6. Testin idarə edilməsi.
Çətin? mübahisə etmirəm. Lakin konfiqurasiya idarəetməsinin belə bir kompleksi server konfiqurasiyasının avtomatlaşdırılması ilə bağlı bir çox suallara hərtərəfli cavab oldu. İndi pərakəndə satıcının standart serverləri həmişə ciddi şəkildə müəyyən edilmiş konfiqurasiyaya malikdir. CMS, mühəndisdən fərqli olaraq, lazımi parametrləri əlavə etməyi, istifadəçilər yaratmağı və onlarla və ya yüzlərlə tələb olunan parametrləri yerinə yetirməyi unutmayacaq.
Bu gün serverlərin və mühitlərin parametrlərində “gizli bilik” yoxdur. Bütün lazımi xüsusiyyətlər oyun kitabında öz əksini tapmışdır. Artıq yaradıcılıq və qeyri-müəyyən göstərişlər yoxdur: "Onu adi Oracle kimi quraşdırın, lakin siz bir neçə sysctl parametrini təyin etməli və tələb olunan UID-ə sahib olan istifadəçiləri əlavə etməlisiniz. Əməliyyatda olanlardan soruşun, bilirlər.
Konfiqurasiya uyğunsuzluqlarını aşkar etmək və onları proaktiv şəkildə düzəltmək qabiliyyəti dinclik təmin edir. Konfiqurasiya idarəetmə sistemi olmadan bu adətən fərqli görünür. Problemlər bir gün istehsala “atılana qədər” yığılır. Sonra debrifinq aparılır, konfiqurasiyalar yoxlanılır və düzəldilir. Və dövr yenidən təkrarlanır
Və əlbəttə ki, serverlərin işə salınmasını bir neçə gündən saatlara qədər sürətləndirdik.
Bəli, Yeni il ərəfəsində uşaqlar sevinclə hədiyyələri açarkən və böyüklər zəng çaldıqca arzularını bildirəndə mühəndislərimiz SAP sistemini yeni serverlərə köçürdülər. Hətta Şaxta baba deyəcək ki, ən yaxşı möcüzələr yaxşı hazırlanmış möcüzələrdir.
P.S. Komandamız tez-tez müştərilərin konfiqurasiya idarəetmə problemlərini mümkün qədər sadə şəkildə həll etmək istəməsi ilə qarşılaşır. İdeal olaraq, sanki sehrlə - bir alətlə. Ancaq həyatda hər şey daha mürəkkəbdir (bəli, gümüş güllələr yenidən çatdırılmadı): müştəri komandası üçün əlverişli vasitələrdən istifadə edərək bütöv bir proses yaratmalısınız.
Müəllif: Sergey Artemov, şöbə memarı "Jet Infosystems"
Mənbə: www.habr.com