Bu çıxışın stenoqramıdır и .
Bu, öz-özünə yazılmış konfiqurasiya idarəetmə sistemindən istifadə edən bir layihənin hekayəsidir və niyə Ansible-a keçid 18 ay çəkdi.
Gün № -ХХХ: Başlamadan əvvəl
Əvvəlcə infrastruktur Hyper-V ilə işləyən bir çox ayrı hostlardan ibarət idi. Virtual maşının yaradılması bir çox addımlar tələb edirdi: diskləri düzgün yerə qoymaq, DNS-ni qeydiyyata almaq, DHCP-ni rezerv etmək, VM konfiqurasiyasını git repozitoriyasına qoymaq. Bu proses qismən mexanikləşdirildi, lakin məsələn, VM-lər hostlar arasında əl ilə paylandı. Lakin, məsələn, tərtibatçılar git-də VM konfiqurasiyasını düzəldə və VM-ni yenidən işə salmaqla tətbiq edə bilərlər.
Xüsusi Konfiqurasiya İdarəetmə Həlli
Şübhə edirəm ki, orijinal ideya IaC kimi hazırlanmışdır: yenidən işə salındıqda vəziyyətini sıfıra sıfırlayan bir çox vətəndaşlığı olmayan VM-lər. VM konfiqurasiya idarəetməsi nə idi? Sxematik olaraq sadə görünür:
- VM üçün statik MAC bağlandı.
- CoreOS ilə ISO və yükləmə diski VM-ə qoşuldu.
- CoreOS fərdiləşdirmə skriptini IP əsasında WEB serverindən endirərək işə salır.
- Skript IP ünvanına əsasən SCP vasitəsilə VM konfiqurasiyasını yükləyir.
- Systemd vahid fayllarının ayaq örtüyü və bash skriptlərinin ayaq örtüyü işə salınır.
Bu həllin bir çox açıq problemləri var idi:
- CoreOS ISO köhnəlmişdir.
- VM-ləri köçürərkən/yaratarkən çoxlu mürəkkəb avtomatlaşdırılmış hərəkətlər və sehr.
- Proqram təminatının müəyyən versiyasına ehtiyac olduqda və yeniləmə ilə bağlı çətinliklər. Kernel modulları ilə daha da əyləncəlidir.
- VM-lər məlumat olmadan belə əldə edilməmişdir, yəni. VM-lər əlavə istifadəçi məlumatı quraşdırılmış disklə meydana çıxdı.
- Kimsə sistem vahidindən asılılıqları daim pozurdu və CoreOS yenidən başladıqda donurdu. CoreOS-da mövcud vasitələrdən istifadə edərək bunu tutmaq çətin idi.
- Sirlərin idarə edilməsi.
- CM yox idi. CoreOS üçün bash və YML konfiqurasiyaları var idi.
VM konfiqurasiyasını tətbiq etmək üçün onu yenidən başlatmalısınız, lakin o, yenidən başlamaya bilər. Bu, açıq bir problem kimi görünür, lakin davamlı disklər yoxdur - qeydləri saxlamaq üçün heç bir yer yoxdur. Yaxşı, yaxşı, logların göndərilməsi üçün kernel yükləmə seçimini əlavə etməyə çalışaq. Amma yox, hər şey nə qədər mürəkkəbdir.
Gün №0: Problemi tanıyın
Bu, adi inkişaf infrastrukturu idi: jenkins, test mühitləri, monitorinq, reyestr. CoreOS k8s klasterlərini yerləşdirmək üçün nəzərdə tutulmuşdur, yəni. problem CoreOS-un necə istifadə olunması idi. İlk addım bir yığın seçmək idi. Biz qərarlaşdıq:
- CentOS əsas paylama kimi, çünki Bu, istehsal mühitlərinə ən yaxın paylamadır.
- Yoxdur konfiqurasiya idarə edilməsi üçün, çünki Bununla bağlı geniş araşdırma aparılıb.
- Jenkins mövcud proseslərin avtomatlaşdırılması üçün çərçivə kimi, çünki inkişaf prosesləri üçün artıq fəal şəkildə istifadə edilmişdir
- Hyper-V virtuallaşdırma platforması kimi. Hekayənin əhatəsindən kənara çıxan bir sıra səbəblər var, amma qısacası - buludlardan istifadə edə bilmirik, öz aparatımızdan istifadə etməliyik.
Gün № 30: Mövcud müqavilələrin düzəldilməsi - Sazişlər Məcəllə kimi
Yığın aydın olduqdan sonra hərəkət üçün hazırlıqlar başladı. Mövcud müqavilələrin kod şəklində düzəldilməsi (Kodeks kimi müqavilələr!). Keçid əl işi -> mexanizasiya -> avtomatlaşdırma.
1. VM-ləri konfiqurasiya edin
Ansible bu işdə əla iş görür. Minimum bədən hərəkətləri ilə VM konfiqurasiyalarına nəzarət edə bilərsiniz:
- Git deposu yaradın.
- VM-lərin siyahısını inventarda, konfiqurasiyaları oyun kitablarında və rollarda yerləşdiririk.
- Biz Ansible-ı işlədə biləcəyiniz xüsusi jenkins slave qururuq.
- Biz bir iş yaradırıq və Jenkins-i konfiqurasiya edirik.
Birinci proses hazırdır. Müqavilələr sabitdir.
2. Yeni VM yaradın
Burada hər şey çox əlverişli deyildi. Linux-dan Hyper-V-də VM-lər yaratmaq çox rahat deyil. Bu prosesi mexanikləşdirmək cəhdlərindən biri:
- Ansbile WinRM vasitəsilə Windows hostuna qoşulur.
- Ansible powershell skriptini işlədir.
- Powershell skripti yeni VM yaradır.
- Hyper-V/ScVMM-dən istifadə edərək, qonaq OS-də VM yaratarkən host adı konfiqurasiya edilir.
- DHCP icarəsini yeniləyərkən VM öz host adını göndərir.
- Domain Controller tərəfində standart ddns & dhcp inteqrasiyası DNS qeydini konfiqurasiya edir.
- Siz inventarınıza VM əlavə edə və onu Ansible ilə konfiqurasiya edə bilərsiniz.
3.VM şablonu yaradın
Burada heç nə icad etmədilər - qablaşdırıcı götürdülər.
- Paketləyicini, kickstart konfiqurasiyasını git deposuna əlavə edin.
- Hyper-v və Packer ilə xüsusi jenkins qulunun qurulması.
- Biz bir iş yaradırıq və Jenkins-i konfiqurasiya edirik.
Bu keçid necə işləyir:
- Packer boş bir VM yaradır və ISO-nu götürür.
- VM işə düşür, Packer disketdən və ya http-dən kickstart faylımızdan istifadə etmək üçün yükləyiciyə əmr daxil edir.
- Anaconda konfiqurasiyamızla işə salındı və ilkin OS konfiqurasiyası tamamlandı.
- Packer VM-nin əlçatan olmasını gözləyir.
- VM daxilində Packer yerli rejimdə ansible işləyir.
- Ansible 1-ci addımda işlədiyi eyni rollardan istifadə edir.
- Packer VM şablonunu ixrac edir.
Gün №75: Müqaviləni pozmadan yenidən düzəldin = Test ansible + Testkitchen
Kodda konvensiyaları tutmaq kifayət olmaya bilər. Axı, prosesin incəliklərində nəyisə dəyişdirmək istəsən, nəyisə poza bilərsən. Buna görə də, infrastruktur məsələsində məhz bu infrastrukturun sınaqdan keçirilməsi görünür. Komanda daxilində bilikləri sinxronlaşdırmaq üçün biz Ansible rollarını sınaqdan keçirməyə başladıq. Mən dərinə getməyəcəm, çünki... o dövrdə baş verən hadisələri təsvir edən bir məqalə var (spoiler bu son versiya deyildi və sonradan hər şey daha mürəkkəbləşdi ).
Gün # 130: Bəlkə CentOS+ansible lazım deyil? bəlkə openshift?
Biz başa düşməliyik ki, infrastrukturun tətbiqi prosesi tək deyildi və əlavə sublayihələr də var idi. Məsələn, tətbiqimizi openshift-də işə salmaq üçün sorğu gəldi və bu, bir həftədən çox araşdırma ilə nəticələndi hərəkət prosesini ləngitdi. Nəticə məlum oldu ki, openshift bütün ehtiyacları ödəmir, sizə real aparat lazımdır, ya da heç olmasa nüvə ilə oynamaq bacarığı.
Gün # 170: Openshift uyğun deyil, gəlin Windows Azure Paketi ilə bir şans verək?
Hyper-V çox dost deyil, SCVMM onu daha da yaxşılaşdırmır. Ancaq SCVMM-ə əlavə olan və Azure-u təqlid edən Windows Azure Pack kimi bir şey var. Ancaq əslində məhsul tərk edilmiş görünür: sənədlərdə bağlantılar pozulmuşdur və çox seyrəkdir. Ancaq buludumuzun həyatını asanlaşdırmaq variantlarının öyrənilməsinin bir hissəsi olaraq, ona da baxdılar.
Gün # 250: Windows Azure Paketi çox yaxşı deyil. Biz SCVMM-də qalırıq
Windows Azure Pack perspektivli görünürdü, lakin lazımsız xüsusiyyətlər naminə mürəkkəbliyi ilə WAP-ı sistemə gətirməmək qərara alındı və SCVMM-də qaldı.
Gün # 360: Fili parça-parça yemək
Yalnız bir ildən sonra köçmək üçün platforma hazır oldu və köçürmə prosesi başladı. Bu məqsədlə SMART tapşırıq qoyulmuşdur. Biz bütün VM-ləri yoxladıq və konfiqurasiyanı bir-bir anlamağa, Ansible-da təsvir etməyə və testlərlə əhatə etməyə başladıq.
Gün # 450: Hansı sistem əldə etdiniz?
Prosesin özü maraqlı deyil. Bu, müntəzəmdir, qeyd etmək olar ki, konfiqurasiyaların əksəriyyəti nisbətən sadə və ya izomorf idi və Pareto prinsipinə görə, VM konfiqurasiyalarının 80% -i vaxtın 20% -ni tələb edir. Eyni prinsiplə, vaxtın 80% -i hərəkətin hazırlanmasına və yalnız 20% -i hərəkətin özünə sərf edilmişdir.
Gün # 540: Final
18 ayda nə baş verdi?
- Müqavilələr məcəlləyə çevrildi.
- Əl işi -> Mexanikləşdirmə -> Avtomatlaşdırma.
Links
Mənbə: www.habr.com