Bu məqalə “Şəbəkə İnfrastrukturunuza Necə Nəzarət Edin” seriyasının altıncı məqaləsidir. Serialdakı bütün məqalələrin məzmunu və keçidləri ilə tanış ola bilərsiniz .
Bir neçə mövzunu arxada qoyub, yeni fəsil açmağa qərar verdim.
Bir az sonra mühafizəyə qayıdacağam. Burada mən bir sadə, lakin effektiv yanaşmanı müzakirə etmək istəyirəm ki, əminəm ki, bu və ya digər formada çoxları üçün faydalı ola bilər. Bu, avtomatlaşdırmanın mühəndisin həyatını necə dəyişdirə biləcəyi haqqında daha çox qısa hekayədir. Şablonların istifadəsi haqqında danışacağıq. Sonda layihələrimin siyahısı var, burada təsvir olunan hər şeyin necə işlədiyini görə bilərsiniz.
Şəbəkə üçün DevOps
Skriptlə konfiqurasiya yaratmaq, İT infrastrukturunda dəyişikliklərə nəzarət etmək üçün GIT-dən istifadə etmək, uzaqdan “yükləmə” – DevOps yanaşmasının texniki tətbiqi haqqında düşünəndə bu fikirlər ilk növbədə gəlir. Üstünlüklər göz qabağındadır. Amma təəssüf ki, mənfi cəhətləri də var.
5 ildən çox əvvəl tərtibatçılarımız bizə, şəbəkəçilər bu təkliflərlə gələndə, biz sevinmədik.
Deməliyəm ki, bizə 10-a yaxın müxtəlif təchizatçının avadanlıqlarından ibarət kifayət qədər rəngarəng şəbəkə miras qalmışdı. Sevimli cli vasitəsilə bəzi şeyləri konfiqurasiya etmək rahat idi, lakin digərlərində biz GUI-dən istifadə etməyə üstünlük verdik. Bundan əlavə, "canlı" avadanlıq üzərində uzun müddət işləmək bizə real vaxt rejimində nəzarət etməyi öyrətdi. Məsələn, dəyişikliklər edərkən, birbaşa cli vasitəsilə işləməkdə özümü daha rahat hiss edirəm. Bu yolla nəyinsə səhv getdiyini tez görə bilərəm və dəyişiklikləri geri qaytara bilərəm. Bütün bunlar onların fikirləri ilə müəyyən ziddiyyət təşkil edirdi.
Digər suallar da yaranır, məsələn, interfeys proqramın versiyasından bir qədər dəyişə bilər. Bu, nəticədə skriptinizin yanlış "konfiqurasiya" yaratmasına səbəb olacaq. İstehsaldan “qaçış” üçün istifadə etmək istəməzdim.
Və ya konfiqurasiya əmrlərinin düzgün tətbiq olunduğunu necə başa düşmək olar və səhv olarsa nə etməli?
Mən demək istəmirəm ki, bütün bu problemlər həll olunmazdır. Sadəcə “A” deməklə, yəqin ki, “B” demək də məntiqlidir və əgər inkişafda olduğu kimi dəyişikliklərə nəzarət üçün eyni proseslərdən istifadə etmək istəyirsinizsə, istehsala əlavə olaraq inkişaf və səhnələşdirmə mühitlərinə sahib olmalısınız. Sonra bu yanaşma tam görünür. Amma nə qədər başa gələcək?
Ancaq bir vəziyyət var ki, çatışmazlıqlar praktiki olaraq düzəldilir və yalnız üstünlüklər qalır. Mən dizayn işindən danışıram.
Layihə
Son iki ildə mən böyük bir provayder üçün məlumat mərkəzinin qurulması layihəsində iştirak edirəm. Mən bu layihədə F5 və Palo Alto üçün cavabdehəm. Cisco nöqteyi-nəzərindən bu, “3-cü tərəf avadanlığıdır”.
Şəxsən mənim üçün bu layihənin iki fərqli mərhələsi var.
Birinci mərhələ
Birinci il sonsuz məşğul idim, gecələr və həftə sonları işlədim. Başımı qaldıra bilmədim. Rəhbərliyin və müştərinin təzyiqi güclü və davamlı idi. Davamlı bir iş rejimində prosesi optimallaşdırmağa belə cəhd edə bilmədim. Bu, dizayn sənədlərinin hazırlanması kimi təkcə avadanlıqların konfiqurasiyası deyildi.
İlk sınaqlar başladı və nə qədər kiçik səhvlərə və qeyri-dəqiqliklərə yol verildiyinə heyran olardım. Təbii ki, hər şey işləyirdi, amma adda əskik hərf var idi, əmrdə əskik bir sətir var idi... Testlər davam edirdi və mən onsuz da daimi, gündəlik xətalar, testlər və sənədlərlə mübarizə aparırdım. .
Bu bir il davam etdi. Layihə, başa düşdüyüm qədər, hər kəs üçün asan deyildi, lakin getdikcə müştəri getdikcə daha çox məmnun oldu və bu, gündəlik işlərin bir hissəsini özləri götürə bilən əlavə mühəndisləri işə götürməyə imkan verdi.
İndi bir az ətrafa baxa bildik.
Və bu, ikinci mərhələnin başlanğıcı idi.
İkinci mərhələ
Prosesi avtomatlaşdırmaq qərarına gəldim.
O vaxt tərtibatçılarla ünsiyyətimdən anladığım odur ki, mətn formatı ilk baxışdan DOS əməliyyat sistemi dünyasından bir şey kimi görünsə də, bir sıra var. qiymətli xassələrdən ibarətdir.
Beləliklə, məsələn, GIT və onun bütün törəmələrindən tam istifadə etmək istəyirsinizsə, mətn formatı faydalı olacaq. Və mən istədim.
Deyəsən, sadəcə bir konfiqurasiya və ya əmrlər siyahısını saxlaya bilərsiniz, lakin dəyişiklik etmək olduqca əlverişsizdir. Bundan əlavə, dizayn zamanı başqa bir vacib vəzifə var. Dizaynınızı bütövlükdə (Aşağı Səviyyəli Dizayn) və xüsusi tətbiqi (Şəbəkə İcra Planı) təsvir edən sənədləriniz olmalıdır. Və bu vəziyyətdə şablonların istifadəsi çox uyğun bir seçim kimi görünür.
Beləliklə, YAML və Jinja2 istifadə edərkən, IP ünvanları, BGP AS nömrələri, ... kimi konfiqurasiya parametrləri olan YAML faylı NIP rolunu mükəmməl şəkildə yerinə yetirir, Jinja2 şablonları isə dizayna uyğun sintaksisi ehtiva edir, yəni mahiyyətcə LLD-nin əks olunması.
YAML və Jinja2-ni öyrənmək iki gün çəkdi. Bunun necə işlədiyini başa düşmək üçün bir neçə yaxşı nümunə kifayətdir. Sonra dizaynımıza uyğun gələn bütün şablonları yaratmaq təxminən iki həftə çəkdi: Palo Alto üçün bir həftə və F5 üçün başqa bir həftə. Bütün bunlar korporativ githab-da yerləşdirilib.
İndi dəyişiklik prosesi belə görünürdü:
- YAML faylını dəyişdirdi
- şablondan istifadə edərək konfiqurasiya faylı yaratdı (Jinja2)
- uzaq depoda saxlanılır
- yaradılmış konfiqurasiyanı avadanlıqa yüklədi
- Səhv gördüm
- YAML faylını və ya Jinja2 şablonunu dəyişdi
- şablondan istifadə edərək konfiqurasiya faylı yaratdı (Jinja2)
- ...
Aydındır ki, əvvəlcə redaktələrə çox vaxt sərf olundu, lakin bir-iki həftədən sonra bu, olduqca nadir hala gəldi.
Müştərinin ad konvensiyasını dəyişdirmək istəyi yaxşı bir sınaq və hər şeyi sazlamaq imkanı idi. F5 ilə işləyənlər vəziyyətin acınacaqlı olduğunu başa düşürlər. Amma mənim üçün hər şey olduqca sadə idi. YAML faylındakı adları dəyişdirdim, bütün konfiqurasiyanı avadanlıqdan sildim, yenisini yaratdım və yüklədim. Hər şey, o cümlədən səhvlərin düzəldilməsi 4 gün çəkdi: hər texnologiya üçün iki gün. Bundan sonra mən növbəti mərhələyə, yəni DEV və Staging məlumat mərkəzlərinin yaradılmasına hazır idim.
İnkişaf və Səhnələşdirmə
Səhnələşdirmə əslində istehsalı tamamilə təkrarlayır. Dev, əsasən virtual aparat üzərində qurulmuş, çox soyulmuş bir nüsxədir. Yeni yanaşma üçün ideal vəziyyət. Mən sərf etdiyim vaxtı ümumi prosesdən təcrid etsəm, işin 2 həftədən çox çəkmədiyini düşünürəm. Əsas vaxt qarşı tərəfi gözləmək və problemləri birlikdə axtarmaqdır. 3-cü tərəfin tətbiqi digərləri tərəfindən demək olar ki, diqqətdən kənarda qaldı. Hətta bir şey öyrənmək və Habré haqqında bir neçə məqalə yazmaq üçün vaxt var idi :)
ümumiləşdirmək üçün
Beləliklə, mənim nəticədə nə var?
- Konfiqurasiyanı dəyişmək üçün etməliyəm yalnız konfiqurasiya parametrləri ilə sadə, aydın strukturlaşdırılmış YAML faylını dəyişdirməkdir. Mən heç vaxt python skriptini dəyişdirmirəm və çox nadir hallarda (yalnız xəta olarsa) Jinja2 istilik sistemini dəyişirəm
- Sənədləşmə baxımından bu, demək olar ki, ideal bir vəziyyətdir. Siz sənədləri dəyişdirirsiniz (YAML faylları NIP kimi xidmət edir) və bu konfiqurasiyanı avadanlıqa yükləyirsiniz. Beləliklə, sənədləriniz həmişə yenilənir
Bütün bunlar ona gətirib çıxardı ki
- səhv nisbəti demək olar ki, 0-a düşdü
- Rutinin 90 faizi getdi
- icra sürəti xeyli artmışdır
PAY, F5Y, ACY
Dedim ki, bunun necə işlədiyini başa düşmək üçün bir neçə nümunə kifayətdir.
İşim zamanı yaradılanların qısa (və əlbəttə ki, dəyişdirilmiş) versiyası budur.
= yerləşdirmə Palo Alto Yaml = Yamldan Palo Alto
= yerləşdirmə F5 etibarən Yaml = F5 etibarən Yaml (tezliklə)
= yerləşdirmə ACməndən Yaml = F5 etibarən Yaml
ACY haqqında bir neçə söz əlavə edəcəyəm (ACI ilə səhv salmamaq üçün).
ACI ilə işləyənlər bilirlər ki, bu möcüzə (və yaxşı mənada) mütləq şəbəkəçilər tərəfindən yaradılmayıb :). Şəbəkə haqqında bildiyiniz hər şeyi unudun - bu sizin üçün faydalı olmayacaq!
Bu, bir az şişirdilmişdir, lakin bu, mənim son 3 ildə ACI ilə işləyərkən daim yaşadığım hissi təqribən çatdırır.
Və bu halda, ACY yalnız dəyişikliklərə nəzarət prosesi qurmaq üçün bir fürsət deyil (bu, ACI vəziyyətində xüsusilə vacibdir, çünki o, məlumat mərkəzinizin mərkəzi və ən vacib hissəsi olmalıdır), həm də sizə konfiqurasiya yaratmaq üçün istifadəçi dostu interfeys.
Bu layihə üzrə mühəndislər eyni məqsədlər üçün YAML əvəzinə ACI-ni konfiqurasiya etmək üçün Excel-dən istifadə edirlər. Əlbəttə ki, Excel-dən istifadənin üstünlükləri var:
- bir faylda NIP
- müştərinin baxması üçün xoş olan gözəl əlamətlər
- bəzi excel alətlərindən istifadə edə bilərsiniz
Ancaq bir mənfi cəhət var və mənim fikrimcə, o, müsbətləri üstələyir. Dəyişikliklərə nəzarət etmək və komanda işini koordinasiya etmək daha da çətinləşir.
ACY əslində ACI-ni konfiqurasiya etmək üçün 3-cü tərəf üçün istifadə etdiyim eyni yanaşmaların tətbiqidir.
Mənbə: www.habr.com