Bir çox insanlar Terraformu bilir və gündəlik işlərində istifadə edirlər, lakin bunun üçün hələ də ən yaxşı təcrübələr yoxdur. Hər komanda öz yanaşmalarını və üsullarını icad etməlidir.
İnfrastrukturunuz demək olar ki, sadədir: bir neçə resurs + bir neçə tərtibatçı. Zamanla bütün istiqamətlərdə böyüyür. Resursları Terraform modullarında qruplaşdırmaq, kodu qovluqlarda təşkil etmək yollarını tapırsınız və başqa nə səhv ola bilər? (məşhur son sözlər)
Vaxt keçir və infrastrukturunuzun yeni ev heyvanınız olduğunu hiss edirsiniz, bəs niyə? İnfrastrukturdakı anlaşılmaz dəyişikliklərdən narahatsınız, infrastruktura və koda toxunmaqdan qorxursunuz - nəticədə yeni funksionallığı gecikdirirsiniz və ya keyfiyyəti aşağı salırsınız ...
Github-da AWS üçün Terraform icma modullarının kolleksiyasını üç il idarə etdikdən və istehsalda Terraforma uzunmüddətli texniki xidmət göstərdikdən sonra Anton Babenko öz təcrübəsini bölüşməyə hazırdır: TF modullarını gələcəkdə zərər verməmək üçün necə yazmaq olar.
Söhbətin sonunda iştirakçılar Terraform resurslarının idarə edilməsi prinsipləri, Terraform modulu ilə bağlı ən yaxşı təcrübələr və bəzi infrastrukturun idarə edilməsi ilə bağlı davamlı inteqrasiya prinsipləri ilə daha çox tanış olacaqlar.
Disclaimer: Qeyd edim ki, bu hesabat 2018-ci ilin noyabr ayına aiddir - 2 il keçib. Hesabatda nəzərdən keçirilən Terraform 0.11 versiyası artıq dəstəklənmir. Son 2 il ərzində çoxlu yeniliklər, təkmilləşdirmələr və dəyişikliklərin meydana çıxdığı 2 yeni buraxılış buraxıldı. Buna diqqət yetirin və sənədləri yoxlayın.
Referanslar:
- +
- — kodun və sənədlərin avtomatik formatlaşdırılması
- - Terraform modullarının generatoru (WIP)
- - Vizual diaqramlardan Terraform kod generatoru (WIP)
- www.terraform-best-practices.com
- (Yeni yazılar www.antonbabenko.com/ şəxsi saytındadır)
- @antonbabenko - Twitter və bir çox fərqli Slacks
Mənim adım Anton Babenkodur. Yəqin ki, bəziləriniz mənim yazdığım kodu istifadə etmisiniz. İndi bu barədə həmişəkindən daha əminliklə danışacağam, çünki mənim statistikaya çıxışım var.
Mən Terraform ilə məşğulam və 2015-ci ildən bəri Terraform və Amazon ilə əlaqəli çoxlu sayda açıq mənbə layihələrinin fəal iştirakçısı və töhfəçisi olmuşam.
O vaxtdan bəri bunu maraqlı etmək üçün kifayət qədər kod yazdım. Və indi bu barədə danışmağa çalışacağam.
Terraform ilə işləməyin incəlikləri və xüsusiyyətləri haqqında danışacağam. Amma əslində bu HighLoad üçün mövzu deyil. İndi bunun səbəbini başa düşəcəksiniz.
Zamanla Terraform modullarını yazmağa başladım. İstifadəçilər suallar yazdılar, mən onları yenidən yazdım. Sonra mən əvvəlcədən commit qarmaqları olan müxtəlif kod formatlama proqramlarını yazdım və s.
Çox maraqlı layihələr var idi. Mən kod yaratmağı xoşlayıram, çünki kompüterin mənim və proqramçı üçün getdikcə daha çox iş görməsini xoşlayıram, ona görə də hazırda vizual diaqramlardan Terraform kod generatoru üzərində işləyirəm. Yəqin ki, bəziləriniz onları görmüsünüz. Bunlar oxları olan gözəl qutulardır. Və məncə, "İxrac et" düyməsini sıxıb bütün bunları kod kimi əldə edə bilsəniz, əla olar.
Mən Ukraynadanam. Mən uzun illər Norveçdə yaşayıram.
Həmçinin bu reportaj üçün məlumatlar adımı bilən və sosial şəbəkələrdə məni tapan insanlardan toplanıb. Demək olar ki, həmişə eyni ləqəbim var.
Qeyd etdiyim kimi, mən ən çox yayılmış tapşırıqlar üçün modulları yerləşdirdiyimiz ən böyük GitHub depolarından biri olan Terraform AWS modullarının əsas təminatçısıyam: VPC, Autoscaling, RDS.
İndi eşitdikləriniz ən əsasdır. Terraformun nə olduğunu başa düşdüyünüzə şübhə edirsinizsə, vaxtınızı başqa yerdə keçirmək daha yaxşıdır. Burada çoxlu texniki terminlər olacaq. Və hesabatın səviyyəsini ən yüksək elan etməkdən çəkinmədim. Bu o deməkdir ki, mən çox izahat vermədən bütün mümkün terminlərdən istifadə edərək danışa bilərəm.
Terraform 2014-cü ildə infrastrukturu kod kimi yazmağa, planlaşdırmağa və idarə etməyə imkan verən bir yardım proqramı olaraq ortaya çıxdı. Burada əsas anlayış “kod kimi infrastruktur”dur.
Bütün sənədlər, dediyim kimi, yazılıb . Ümid edirəm ki, insanların çoxu bu sayt haqqında bilir və sənədləri oxuyub. Əgər belədirsə, deməli doğru yerdəsiniz.
Müntəzəm Terraform konfiqurasiya faylı belə görünür, burada biz əvvəlcə bəzi dəyişənləri təyin edirik.
Bu halda biz "aws_region"u təyin edirik.
Sonra hansı resursları yaratmaq istədiyimizi təsvir edirik.
Asılılıqları, provayderləri yükləmək üçün bəzi əmrləri, xüsusən də "terraform init"i işlədirik.
Göstərilən konfiqurasiyanın yaratdığımız resurslara uyğun olub olmadığını yoxlamaq üçün “terraform tətbiq et” əmrini işlədirik. Əvvəllər heç nə yaratmadığımız üçün Terraform bu resursları yaratmağımızı təklif edir.
Bunu təsdiq edirik. Dəniz ilbizi adlı vedrəni belə yaradırıq.
Bir neçə oxşar kommunal da var. Amazondan istifadə edən bir çoxunuz AWS CloudFormation və ya Google Cloud Deployment Manager və ya Azure Resource Manager-i bilirsiniz. Onların hər birinin bu ictimai bulud provayderlərinin hər birində resursları idarə etmək üçün bir növ tətbiqetmə var. Terraform xüsusilə faydalıdır, çünki o, 100-dən çox provayderi idarə etməyə imkan verir. (Daha çox )
Terraformun əvvəldən qarşısına qoyduğu məqsədlər:
- Terraform sizə resursların vahid görünüşünü təqdim edir.
- Bütün müasir platformaları dəstəkləməyə imkan verir.
- Və Terraform əvvəldən infrastrukturu təhlükəsiz və proqnozlaşdırıla bilən şəkildə dəyişdirməyə imkan verən bir yardım proqramı kimi düşünülmüşdür.
2014-cü ildə bu kontekstdə “proqnozlaşdırıla bilən” sözü çox qeyri-adi səsləndi.
Terraform universal köməkçi proqramdır. Bir API-niz varsa, tamamilə hər şeyi idarə edə bilərsiniz:
- Ürəyinizin istədiyi hər şeyi idarə etmək üçün 120-dən çox provayderdən istifadə edə bilərsiniz.
- Məsələn, GitHub repozitoriyalarına girişi təsvir etmək üçün Terraform-dan istifadə edə bilərsiniz.
- Siz hətta Jira-da səhvlər yarada və bağlaya bilərsiniz.
- Yeni Relic ölçülərini idarə edə bilərsiniz.
- Həqiqətən istəyirsinizsə, hətta dropbox-da fayllar yarada bilərsiniz.
Bütün bunlara Go-da təsvir edilə bilən açıq API olan Terraform provayderlərinin köməyi ilə nail olunur.
Tutaq ki, biz Terraformdan istifadə etməyə başladıq, saytda bəzi sənədləri oxuduq, bir neçə videoya baxdıq, əvvəlki slaydlarda göstərdiyim kimi main.tf yazmağa başladıq.
Və sizinlə hər şey yaxşıdır, VPC yaradan bir faylınız var.
Bir VPC yaratmaq istəyirsinizsə, onda siz təxminən bu 12 sətri qeyd edirsiniz. Hansı bölgədə yaratmaq istədiyinizi, IP ünvanlarının hansı cidr_blokunu istifadə edəcəyinizi təsvir edin. Və bu qədər.
Təbii ki, layihə tədricən böyüyəcək.
Və siz oraya bir sıra yeni şeylər əlavə edəcəksiniz: resurslar, məlumat mənbələri, yeni provayderlərlə inteqrasiya edəcəksiniz, birdən siz GitHub hesabınızdakı istifadəçiləri idarə etmək üçün Terraform-dan istifadə etmək istəyəcəksiniz və s. müxtəlif DNS provayderlərindən istifadə etmək, hər şeyi keçmək istəyirəm. Terraform bunu asanlaşdırır.
Aşağıdakı misalı nəzərdən keçirək.
Siz tədricən internet_gateway əlavə edirsiniz, çünki VPC-nizdəki resursların internetə çıxışı olmasını istəyirsiniz. Bu yaxşı fikirdir.
Nəticə budur main.tf:
Bu main.tf-nin yuxarı hissəsidir.
Bu main.tf-nin alt hissəsidir.
Sonra alt şəbəkə əlavə edirsiniz. NAT şlüzlərini, marşrutları, marşrutlaşdırma cədvəllərini və bir dəstə digər alt şəbəkələri əlavə etmək istədiyiniz zaman 38 xətt yox, təxminən 200-300 xətt olacaq.
Yəni main.tf faylınız tədricən böyüyür. Və çox vaxt insanlar hər şeyi bir fayla qoyurlar. main.tf-də 10-20 Kb görünür. Təsəvvür edin ki, 10-20 Kb mətn məzmunudur. Və hər şey hər şeyə bağlıdır. Bununla işləmək getdikcə çətinləşir. 10-20 Kb yaxşı istifadəçi vəziyyətidir, bəzən daha çox. Və insanlar həmişə bunun pis olduğunu düşünmürlər.
Adi proqramlaşdırmada olduğu kimi, yəni kod kimi infrastruktur deyil, biz müxtəlif siniflərdən, paketlərdən, modullardan, qruplardan istifadə etməyə öyrəşmişik. Terraform sizə eyni şeyi etməyə imkan verir.
- Kod böyüyür.
- Resurs asılılığı da artır.
Və bizim böyük, böyük ehtiyacımız var. Başa düşürük ki, daha belə yaşaya bilmərik. Bizdə kod nəhəng olur. 10-20 Kb, əlbəttə ki, çox böyük deyil, lakin biz yalnız şəbəkə yığınından danışırıq, yəni yalnız şəbəkə resurslarını əlavə etmisiniz. 100 Kb-in hələ də asanlıqla toxuna biləcəyi Tətbiq Yükü Balanslayıcısı, yerləşdirmə ES klasteri, Kubernetes və s.-dən danışmırıq. Bütün bunları yazsanız, çox tezliklə Terraformun Terraform modullarını təmin etdiyini öyrənəcəksiniz.
Terraform modulları qrup şəklində idarə olunan müstəqil Terraform konfiqurasiyalarıdır. Terraform modulları haqqında bilmək lazım olan hər şey budur. Onlar heç də ağıllı deyillər, nədənsə asılı olaraq hər hansı mürəkkəb əlaqə yaratmağa imkan vermirlər. Bütün bunlar tərtibatçıların çiyinlərinə düşür. Yəni, bu, artıq yazdığınız bir növ Terraform konfiqurasiyasıdır. Və siz sadəcə qrup şəklində zəng edə bilərsiniz.
Beləliklə, biz 10-20-30 Kb kodumuzu necə optimallaşdıracağımızı anlamağa çalışırıq. Tədricən başa düşürük ki, bəzi modullardan istifadə etmək lazımdır.
Qarşılaşılan modulların ilk növü resurs modullarıdır. Onlar başa düşmürlər ki, sizin infrastrukturunuz nə ilə bağlıdır, biznesiniz nə ilə bağlıdır, harada və hansı şəraitdədir. Bunlar məhz mənim açıq mənbə icması ilə birlikdə idarə etdiyim və infrastrukturunuz üçün ilkin tikinti blokları kimi irəli sürdüyümüz modullardır.
Resurs modulunun nümunəsi.
Resurs modulunu çağırdığımız zaman onun məzmununu hansı yoldan yükləməli olduğumuzu müəyyənləşdiririk.
Hansı versiyanı yükləmək istədiyimizi müəyyənləşdiririk.
Biz orada bir dəstə arqument keçirik. Və bu qədər. Bu moduldan istifadə edərkən bilməmiz lazım olan hər şey budur.
Bir çox insanlar düşünür ki, ən son versiyanı istifadə etsəniz, hər şey sabit olacaq. Amma yox. İnfrastruktur versiyalaşdırılmalıdır, bu və ya digər komponentin hansı versiyada yerləşdirildiyinə aydın cavab verməliyik.
Bu modulun içərisində olan kod budur. təhlükəsizlik qrupu modulu. Burada sürüşmə 640-cı sətirə qədər gedir. Amazon-da hər cür konfiqurasiyada resurs təhlükəsizliyi krupunun yaradılması çox qeyri-ciddi bir işdir. Yalnız təhlükəsizlik qrupu yaratmaq və ona hansı qaydaların keçəcəyini söyləmək kifayət deyil. Çox asan olardı. Amazon daxilində milyonlarla fərqli məhdudiyyət var. Məsələn, istifadə etsəniz VPC son nöqtəsi, prefiks siyahısı, müxtəlif API-lər və hər şeyi hər şeylə keçməyə çalışır, onda Terraform bunu etməyə icazə vermir. Və Amazon API də buna icazə vermir. Buna görə də, bütün bu dəhşətli məntiqi modulda gizlətməli və istifadəçiyə məhz belə görünən kodu verməliyik.
İstifadəçinin bunun içəridə necə edildiyini bilməsi lazım deyil.
Resurs modullarından ibarət olan ikinci tip modullar artıq biznesinizə daha uyğun olan vəzifələri həll edir. Tez-tez bu, Terraform üçün bir uzantı olan və etiketlər, şirkət standartları üçün bəzi sərt dəyərlər təyin edən bir yerdir. Siz həmçinin orada Terraformun hazırda istifadə etməyə icazə vermədiyi funksionallıq əlavə edə bilərsiniz. Elə indidir. İndi keçmişin bir şeyinə çevrilmək üzrə olan 0.11 versiyası. Ancaq yenə də tam hüquqlu iş üçün istifadə edilməli olan köməkçi mexanizmlər, preprocessors, jsonnet, cookiecutter və bir çox başqa şeylərdir.
Bundan sonra bunun bir neçə nümunəsini göstərəcəyəm.
İnfrastruktur modulu tam olaraq eyni şəkildə çağırılır.
Məzmunu haradan yükləmək üçün mənbəni müəyyənləşdirir.
Bu modula ötürülən bir dəstə dəyər ötürülür.
Bundan əlavə, bu modulun daxilində bir dəstə resurs modulu VPC və ya Tətbiq Yükü Balansçısı yaratmaq və ya təhlükəsizlik qrupu və ya Elastik Konteyner Xidməti klasteri yaratmaq üçün çağırılır.
İki növ modul var. Bunu başa düşmək vacibdir, çünki bu hesabatda qruplaşdırdığım məlumatların əksəriyyəti sənədlərdə yazılmayıb.
Və hazırda Terraform-da sənədlər olduqca problemlidir, çünki sadəcə belə xüsusiyyətlərin olduğunu söyləyir, onlardan istifadə edə bilərsiniz. Amma o, bu xüsusiyyətlərin necə istifadə olunacağını, niyə istifadə etməyin daha yaxşı olduğunu demir. Buna görə də, çox sayda insan sonradan yaşaya bilməyəcəyiniz bir şey yazır.
Gəlin bu modulları necə yazacağımıza baxaq. Sonra onları necə çağıracağımızı və kodla necə işləyəcəyimizi görəcəyik.
Terraform Registry -
İpucu # 0 resurs modullarını yazmamaqdır. Bu modulların əksəriyyəti artıq sizin üçün yazılmışdır. Dediyim kimi, onlar açıq mənbədir, onlar sizin biznes məntiqinizi ehtiva etmir, IP ünvanları, parollar və s. üçün kodlaşdırılmış dəyərlərə malik deyillər. Modul çox çevikdir. Və yəqin ki, artıq yazılıb. Amazondan qaynaqlar üçün çoxlu modullar var. Təxminən 650. Onların çoxu keyfiyyətlidir.
Bu nümunədə kimsə sizə gəlir və deyir: “Mən verilənlər bazasını idarə edə bilmək istəyirəm. Bir modul yaradın ki, verilənlər bazası yarada bilim." Şəxs nə Amazon, nə də Terraformun tətbiq detallarını bilmir. Sadəcə "Mən MSSQL-i idarə etmək istəyirəm" deyir. Yəni bizim modulumuzu çağıracağını, mühərrik tipini oraya keçirəcəyini və saat qurşağını göstərəcəyini nəzərdə tuturuq.
İnsan bilməməlidir ki, biz bu modul daxilində iki fərqli resurs yaradacayıq: biri MSSQL üçün, ikincisi hər şey üçün, çünki Terraform 0.11-də saat qurşağı dəyərlərini isteğe bağlı olaraq təyin edə bilməzsiniz.
Və bu modulun çıxışında bir şəxs sadəcə ünvanı ala biləcək. Bütün bunları daxilimizdə hansı bazadan, hansı resursdan yaratdığımızı bilməyəcək. Bu gizlənməyin çox vacib elementidir. Bu, yalnız açıq mənbədə açıq olan modullara deyil, həm də layihələrinizdə, komandalarınızda yazacağınız modullara aiddir.
Bu ikinci arqumentdir, əgər siz bir müddət Terraformdan istifadə edirsinizsə, bu olduqca vacibdir. Sizin şirkətiniz üçün bütün Terraform modullarınızı saxladığınız anbarınız var. Və zaman keçdikcə bu layihənin bir və ya iki meqabayt ölçüsünə qədər böyüməsi olduqca normaldır. Bu yaxşıdır.
Ancaq problem Terraformun bu modulları necə çağırmasıdır. Məsələn, hər bir fərdi istifadəçi yaratmaq üçün modul çağırsanız, Terraform əvvəlcə bütün deponu endirəcək, sonra isə bu xüsusi modulun yerləşdiyi qovluğa keçəcək. Bu yolla siz hər dəfə bir meqabayt endirəcəksiniz. Əgər siz 100 və ya 200 istifadəçini idarə edirsinizsə, onda siz 100 və ya 200 meqabayt yükləyəcəksiniz və sonra həmin qovluğa keçəcəksiniz. Beləliklə, təbii olaraq, hər dəfə "Terraform init" düyməsini vurduğunuzda bir dəstə material yükləmək istəmirsiniz.
Bu problemin iki həlli var. Birincisi, nisbi yollardan istifadə etməkdir. Qovluğun yerli (./) olduğunu kodda belə təyin edirsiniz. Və hər hansı bir işə başlamazdan əvvəl, yerli olaraq həmin anbarın Git klonunu edirsiniz. Beləliklə, bir dəfə edin.
Əlbəttə ki, bir sıra mənfi cəhətlər var. Məsələn, versiyadan istifadə edə bilməyəcəksiniz. Və bəzən onunla yaşamaq çətindir.
İkinci qərar. Çoxlu alt modullarınız varsa və artıq bir növ quraşdırılmış boru kəməriniz varsa, o zaman monorepozitoriyadan çoxlu müxtəlif paketləri toplamağa və onları S3-ə yükləməyə imkan verən MBT layihəsi var. Bu, çox yaxşı bir yoldur. Beləliklə, iam-user-1.0.0.zip faylının ölçüsü cəmi 1 Kb olacaq, çünki bu resursun yaradılması üçün kod çox kiçikdir. Və daha sürətli işləyəcək.
Modullarda istifadə edilə bilməyənlərdən danışaq.
Modullarda niyə pisdir? Ən qorxulusu istifadəçini qəbul etməkdir. İstifadəçinin müxtəlif insanlar tərəfindən istifadə oluna bilən bir provayder üçün autentifikasiya seçimi olduğunu düşünək. Məsələn, hamımız bir rol alacağıq. Bu o deməkdir ki, Terraform bu rolu öz üzərinə götürəcək. Və sonra bu rol ilə digər hərəkətləri yerinə yetirəcək.
Və pis odur ki, əgər Vasya Amazon-a bir şəkildə qoşulmağı sevirsə, məsələn, standart olaraq dəyişən mühitdən istifadə edərək və Petya gizli yerdə olan ortaq açarından istifadə etməyi sevirsə, hər ikisini Terraform-da qeyd etmək olmaz. . Və onların əziyyət çəkməməsi üçün modulda bu blok göstərilməməlidir. Bu, yuxarı səviyyədə göstərilməlidir. Yəni bizim resurs modulumuz, infrastruktur modulumuz və üstündə kompozisiyamız var. Və daha yüksək bir yerdə göstərilməlidir.
İkinci şər isə ruzi verəndir. Buradakı pislik o qədər də əhəmiyyətsiz deyil, çünki kod yazırsansa və o, sənin üçün işləyirsə, o zaman düşünə bilərsən ki, işləyirsə, onu niyə dəyişdirmək lazımdır.
Pislik ondadır ki, siz həmişə bu provayderi xüsusi olaraq işə salındıqda idarə etmirsiniz, birincisi. İkincisi, siz aws ec2-nin nə demək olduğunu idarə etmirsiniz, yəni biz indi Linux və ya Windows haqqında danışırıq. Beləliklə, fərqli əməliyyat sistemlərində və ya fərqli istifadəçi halları üçün eyni işləyəcək bir şey yaza bilməzsiniz.
Rəsmi sənədlərdə də göstərilən ən ümumi nümunə budur ki, aws_instance yazsanız, bir sıra arqumentlər göstərsəniz, orada "local-exec" provayderini də göstərsəniz və ansible-i işlətsəniz, heç bir səhv yoxdur. - oyun kitabı.
Əslində, bəli, heç bir qəbahət yoxdur. Ancaq sözün həqiqi mənasında, tezliklə başa düşəcəksiniz ki, bu yerli icraedici şey, məsələn, launch_configuration-da mövcud deyil.
Siz launch_configuration-dan istifadə etdikdə və bir instansiyadan avtomatik miqyaslı qrup yaratmaq istədiyiniz zaman launch_configuration-da "təminatçı" anlayışı yoxdur. “İstifadəçi məlumatları” anlayışı var.
Buna görə də, daha universal bir həll istifadəçi məlumatlarından istifadə etməkdir. Və o, ya nümunənin özündə, instansiya işə salındıqda və ya eyni istifadəçi məlumatında, avtomatik miqyaslama qrupu bu launch_configuration-dan istifadə etdikdə işə salınacaq.
Buna baxmayaraq, bir provayderi işə salmaq istəyi varsa, çünki bu, yapışqan komponentdir, bir resurs yaradıldıqda və bu anda provayderinizi, komandanızı işə salmalısınız. Belə hallar çoxdur.
Bunun üçün ən düzgün mənbə null_resource adlanır. Null_resource heç vaxt yaradılmayan dummy resursdur. Heç bir şeyə toxunmur, API yoxdur, avtomatik miqyaslama yoxdur. Lakin bu, əmrin nə vaxt icra olunacağını idarə etməyə imkan verir. Bu halda, komanda yaradılış zamanı işlədilir.
Əlaqə
Bir neçə əlamət var. Bütün xüsusiyyətlərə ətraflı şəkildə girməyəcəyəm. Bununla bağlı məqalə var. Ancaq Terraform ilə işləmisinizsə və ya başqalarının modullarından istifadə etmisinizsə, o zaman tez-tez bir çox modulların, açıq mənbədəki kodların əksəriyyəti kimi, insanlar tərəfindən öz ehtiyacları üçün yazıldığını görürsünüz. Adam yazdı, problemini həll etdi. Mən bunu GitHub-da etdim, yaşasın. Yaşayacaq, amma sənədləşmə və nümunələr olmasa, heç kim ondan istifadə etməyəcək. Xüsusi vəzifəsindən bir az daha çox həll etməyə imkan verən heç bir funksionallıq yoxdursa, heç kim ondan istifadə etməyəcək. İstifadəçiləri itirməyin bir çox yolu var.
Əgər insanların istifadə etməsi üçün bir şey yazmaq istəyirsinizsə, bu işarələrə əməl etməyi məsləhət görürəm.
Bunlar:
- Sənədlər və nümunələr.
- Tam funksionallıq.
- Ağlabatan defoltlar.
- Təmiz kod.
- Testlər.
Testlər ayrı bir vəziyyətdir, çünki onları yazmaq kifayət qədər çətindir. Mən sənədlərə və nümunələrə daha çox inanıram.
Beləliklə, modulları necə yazmağı gördük. İki arqument var. Birincisi və ən əsası, bacarırsınızsa yazmayın, çünki bir dəstə insan artıq bu işləri sizdən əvvəl görüb. İkincisi, hələ də qərar verərsinizsə, modullarda və provayderlərdə provayderlərdən istifadə etməməyə çalışın.
Bu, sənədlərin boz hissəsidir. İndi düşünə bilərsiniz: “Nəsə aydın deyil. inandırıcı deyil”. Amma altı aydan sonra görəcəyik.
İndi bu modulları necə çağırmaq barədə danışaq.
Biz başa düşürük ki, kodumuz zamanla böyüyür. Artıq bir faylımız yoxdur, artıq 20 faylımız var. Hamısı bir qovluqdadır. Və ya bəlkə beş qovluq. Ola bilsin ki, biz onları hansısa şəkildə bölgələrə, bəzi komponentlərə görə bölməyə başlayırıq. Sonra başa düşürük ki, indi bizdə sinxronizasiyanın bəzi əsasları var, orkestr yaranmalıdır. Yəni, şəbəkə resurslarını dəyişdirsək nə edəcəyimizi, qalan resurslarımızla nə edəcəyimizi, bu asılılıqları necə adlandıracağımızı və s.
İki ifrata var. Birinci ekstremal hamısı bir yerdədir. Bir master faylımız var. Hələlik bu, Terraform saytında rəsmi ən yaxşı təcrübə idi.
Amma indi köhnəlmiş və silinmiş kimi yazılır. Zamanla Terraform icması bunun ən yaxşı təcrübədən uzaq olduğunu başa düşdü, çünki insanlar layihədən müxtəlif yollarla istifadə etməyə başlayırlar. Və problemlər var. Məsələn, biz bir yerdə bütün asılılıqları təyin etdikdə. "Terraform planı"na kliklədiyimiz hallar olur və Terraformun bütün resursların vəziyyətlərini yeniləməsi çox vaxt apara bilər.
Çox vaxt, məsələn, 5 dəqiqədir. Bəziləri üçün bu, çox vaxtdır. 15 dəqiqə çəkdiyi hallar görmüşəm. 15 dəqiqə AWS API hər resursun vəziyyəti ilə nə baş verdiyini anlamaq üçün seğirildi. Bu çox böyük ərazidir.
Və əlbəttə ki, bir yerdə bir şeyi dəyişdirmək istədiyiniz zaman əlaqəli problem yaranacaq, sonra 15 dəqiqə gözləyin və bu sizə bəzi dəyişikliklərin kətanını verir. Tüpürdün, “Bəli” yazdın və nəsə səhv oldu. Bu çox real nümunədir. Terraform sizi problemlərdən təcrid etməyə çalışmır. Yəni istədiyinizi yazın. Problemlər olacaq - problemləriniz. Terraform 0.11 heç bir şəkildə sizə kömək etməyə çalışmır. 0.12-də sizə deməyə imkan verən müəyyən maraqlı yerlər var: "Vasya, bunu həqiqətən istəyirsən, fikrini dəyişə bilərsənmi?".
İkinci yol bu sahəni azaltmaqdır, yəni bir yerdən başqa bir yerdən edilən zənglər daha az bağlı ola bilər.
Yeganə problem odur ki, daha çox kod yazmalısınız, yəni çox sayda faylda dəyişənləri təsvir etməlisiniz, bunu yeniləyin. Kiminsə xoşuna gəlmir. Mənim üçün bu normaldır. Bəziləri isə belə düşünür: “Bunu niyə fərqli yerlərdə yazın, hamısını bir yerdə yazacam”. Mümkündür və belədir, amma bu, ikinci ifratdır.
Kimin hamısı bir yerdə var? Bir, iki, üç nəfər, yəni kimsə istifadə edir.
Bir xüsusi komponenti, bir bloku və ya bir infrastruktur modulunu kim çağırır? Beş-yeddi nəfər. Bu əladır.
Ən ümumi cavab ortada bir yerdədir. Layihə böyükdürsə, onda siz tez-tez heç bir həllin uyğun olmadığı və orada hər şeyin nəticə vermədiyi bir vəziyyətlə qarşılaşacaqsınız, buna görə də bir qarışıqla nəticələnirsiniz. Hər ikisinin bir üstünlüyü olduğunu başa düşsəniz, bunda heç bir səhv yoxdur.
VPC yığınında nəsə dəyişibsə və siz bu EC2 dəyişikliklərini tətbiq etmək istəyirsinizsə, yəni yeni alt şəbəkəniz olduğu üçün avtomatik miqyaslama qrupunu yeniləmək istəyirsinizsə, mən bu cür asılılıq orkestrasiyası adlandırıram. Bəzi həll yolları var: kim nədən istifadə edir?
Mən həll yollarının nə olduğunu təklif edə bilərəm. Sehr etmək üçün Terraform-dan istifadə edə bilərsiniz və ya Terraform-dan istifadə etmək üçün makefiles istifadə edə bilərsiniz. Baxın, orada bir şey dəyişibsə, onu burada işlədə bilərsiniz.
Bu qərarı necə bəyənirsiniz? Bunun sərin bir həll olduğuna inanan varmı? Bir təbəssüm görürəm, şübhələrin içəri girdiyini görürəm.
Təbii ki, evdə bunu təkrarlamayın. Terraform heç vaxt Terraformun içindən işləmək üçün nəzərdə tutulmayıb.
Bir hesabatda mənə dedilər: "Xeyr, bu işləməyəcək." İş ondadır ki, işləməməlidir. Terraform-u Terraform-dan işə sala bildiyiniz zaman çox təsir edici görünsə də, Terraform da var, amma bunu etmək lazım deyil. Terraform həmişə çox sadə başlamalıdır.
Bir yerdə bir şey dəyişdikdə zəngləri idarə etmək lazımdırsa, Terragrunt var.
Terragrunt bir yardım proqramıdır, o, Terraform-a əlavədir və infrastruktur modullarına zəngləri əlaqələndirməyə və orkestrləşdirməyə imkan verir.
Tipik bir Terraform konfiqurasiya faylı bu kimi görünür.
Hansı xüsusi modula zəng etmək istədiyinizi müəyyənləşdirirsiniz.
Hansı modulda asılılıqlar var.
Və bu modul hansı arqumentləri qəbul edir. Terragrunt haqqında bilmək lazım olan hər şey budur.
Sənədlər var, GitHub-da 1 ulduz da var. Ancaq əksər hallarda bu, bilməli olduğunuz şeydir. Bunu Terraform ilə yenicə işə başlayan şirkətlərdə həyata keçirmək çox asandır.
Beləliklə, orkestr Terragruntdur. Başqa variantlar da var.
İndi kodla necə işləmək barədə danışaq.
Koda yeni funksiyalar əlavə etmək ehtiyacınız varsa, əksər hallarda bu, asandır. Yeni resurs yazırsınız, burada hər şey sadədir.
Əgər əvvəlcədən yaratdığınız bəzi resursunuz varsa, məsələn, AWS hesabı açdıqdan sonra Terraform haqqında məlumat əldə etmisinizsə və artıq malik olduğunuz resurslardan istifadə etmək istəyirsinizsə, modulunuzu bu şəkildə genişləndirmək məqsədəuyğun olardı. mövcud resurslardan istifadəni dəstəklədiyini bildirir.
Və blok resursundan istifadə edərək yeni resursların yaradılmasını dəstəklədi.
Çıxışda biz həmişə istifadə olunandan asılı olaraq çıxış identifikatorunu qaytarırıq.
Terraform 0.11-də ikinci çox əhəmiyyətli problem siyahılarla işləməkdir.
Çətinlik ondadır ki, əgər belə bir istifadəçi siyahısı varsa.
Blok resursundan istifadə edərək bu istifadəçiləri yaratdıqda hər şey qaydasındadır. Bütün siyahıdan keçirik, hər biri üçün bir fayl yaradırıq. Hər şey yaxşıdır. Və sonra, məsələn, ortada olan user3 buradan silinməlidir, ondan sonra yaradılan bütün resurslar yenidən yaradılacaq, çünki indeks dəyişəcək.
Vəziyyət mühitində siyahılarla işləmək. Dövlət mühiti nədir? Bu, resursun yaradılması zamanı yeni bir dəyərin meydana gəldiyi vəziyyətdir. Məsələn, AWS Giriş Açarı və ya AWS Gizli Açarı, yəni istifadəçi yaratdıqda biz yeni Giriş və ya Gizli Açar alırıq. Və hər dəfə istifadəçini siləndə həmin istifadəçinin yeni açarı olacaq. Amma bu feng shui deyil, çünki hər dəfə kimsə komandadan çıxanda onun üçün yeni istifadəçi yaratsaq, istifadəçi bizimlə dost olmaq istəməz.
Həll yolu budur. Bu Jsonnet-də yazılmış koddur. Jsonnet Google tərəfindən hazırlanmış şablon dilidir.
Bu əmr bu şablonu qəbul etməyə imkan verir və nəticədə şablonunuza uyğun olaraq hazırlanmış json faylını qaytarır.
Şablon belə görünür.
Terraform sizə həm HCL, həm də Json ilə eyni şəkildə işləməyə imkan verir, buna görə də Json yaratmaq qabiliyyətiniz varsa, onu Terraforma keçirə bilərsiniz. .tf.json faylı uğurla yüklənəcək.
Və sonra biz həmişəki kimi onunla işləyirik: terraform init, terramorm tətbiq olunur. Və biz iki istifadəçi yaradırıq.
İndi kimsə komandadan ayrılsa, qorxmuruq. Biz sadəcə json faylını redaktə edəcəyik. Vasya Pupkin getdi, Petya Pyatochkin qaldı. Petya Pyatochkin yeni açar almayacaq.
Terraformu digər alətlərlə inteqrasiya etmək əslində Terraformun işi deyil. Terraform resurs yaratmaq platforması kimi yaradılıb və bu qədər. Bundan sonra gələn hər şey Terraformun narahatlığı deyil. Və onu ora qoymaq lazım deyil. Lazım olan hər şeyi edən Ansible var.
Ancaq elə vəziyyətlər var ki, biz Terraformu tamamlamaq və bir şey tamamlandıqdan sonra bəzi əmrləri çağırmaq istəyirik.
Birinci yol. Bu əmri yazdığımız yerdə çıxış yaradırıq.
Sonra shell terraform çıxışından bu əmri çağırırıq və istədiyimiz bu dəyəri təyin edirik. Beləliklə, əmr bütün əvəz edilmiş qiymətlərlə yerinə yetirilir. Çox rahatdır.
İkinci yol. Bu, infrastrukturumuzdakı dəyişikliklərdən asılı olaraq null_resource istifadəsidir. Bəzi resursun identifikatoru dəyişən kimi biz eyni local-exec-ə zəng edə bilərik.
Təbii ki, bunların hamısı kağız üzərində hamardır, çünki Amazon, bütün digər ictimai provayderlər kimi, öz kənar işlərinə malikdir.
Ən çox rast gəlinən kənar hallar odur ki, AWS hesabı açdığınız zaman hansı bölgələrdən istifadə etdiyinizin əhəmiyyəti; bu xüsusiyyətin oraya daxil olub-olmaması; bəlkə 2013-cü ilin dekabrından sonra açdınız; bəlkə siz VPC-də defolt istifadə edirsiniz və s. Çoxlu məhdudiyyətlər var. Və Amazon onları bütün sənədlərə səpələdi.
Qaçmağı tövsiyə etdiyim bir neçə şey var.
Başlamaq üçün, Terraform planı və ya Terraform CLI daxilində bütün gizli olmayan arqumentlərdən çəkinin. Bütün bunlar ya tfvars faylına, ya da mühit dəyişəninə əlavə edilə bilər.
Ancaq bütün bu sehrli əmri əzbərləmək lazım deyil. Terraform planı - var və uzaqlaşırıq. Birinci dəyişən var, ikinci dəyişən var, üçüncü, dördüncü. Ən çox istifadə etdiyim ən vacib infrastruktur-kod prinsipi odur ki, sadəcə koda baxmaqla mən orada nəyin, hansı vəziyyətdə və hansı dəyərlərlə yerləşdirildiyini mükəmməl başa düşə bilməliyəm. Və buna görə də sənədləri oxumağa və ya Vasyadan klasterimizi yaratmaq üçün hansı parametrlərdən istifadə etdiyini soruşmağa ehtiyac duymuram. Mənə tez-tez mühitə uyğun gələn tfvars uzantılı faylı açıb orada hər şeyi görmək kifayətdir.
Həmçinin əhatə dairəsini azaltmaq üçün hədəf arqumentlərindən istifadə etməyin. Bunun üçün kiçik infrastruktur modullarından istifadə etmək çox asandır.
Həm də paralelliyi məhdudlaşdırmayın və artırmayın. Əgər mənim 150 resursum varsa və Amazonun paralelliyini standart olan 10-dan 100-ə qədər artırmaq istəsəm, onda nəsə səhv gedəcək. Və ya indi yaxşı ola bilər, amma Amazon çox zəng etdiyinizi söyləyəndə problem yaşayırsınız.
Terraform bu problemlərin əksəriyyətini yenidən başlatmağa çalışacaq, lakin siz demək olar ki, heç nəyə nail olmayacaqsınız. Paralellik=1 AWS API daxilində və ya Terraform provayderində bəzi səhvlərlə üzləşsəniz istifadə etmək üçün vacib bir şeydir. Və sonra təyin etməlisiniz: paralellik=1 və Terraform bir zəngi, sonra ikincini, sonra üçüncünü bitirənə qədər gözləyin. Onları bir-bir işə salacaq.
İnsanlar tez-tez məndən soruşurlar: "Mən niyə Terraform iş yerlərinin pis olduğunu düşünürəm?". İnanıram ki, infrastrukturun kod kimi prinsipi hansı infrastrukturun və hansı dəyərlərlə yaradıldığını görməkdir.
İş yerləri istifadəçilər tərəfindən yaradılmayıb. Bu o demək deyil ki, istifadəçilər GitHub məsələlərində Terraform iş yerləri olmadan yaşaya bilməyəcəklərini yazıblar. Yox bu kimi deyil. Terraform Enterprise kommersiya həllidir. HashiCorp-dan olan Terraform qərara gəldi ki, bizə iş yerləri lazımdır, ona görə də onu sənədləşdirəcəyik. Mən onu ayrı bir qovluğa yerləşdirməyi daha asan hesab edirəm. Sonra bir az daha çox fayl olacaq, amma daha aydın olacaq.
Kodla necə işləmək olar? Əslində siyahılarla işləmək yeganə ağrıdır. Və Terraformu daha asan qəbul edin. Bu, sizi əla hiss etdirəcək bir şey deyil. Sənədlərdə yazılanların hamısını orada itələməyə ehtiyac yoxdur.
Hesabatın mövzusu “gələcək üçün” yazılmışdır. Bunu çox qısa deyim. Gələcək üçün bu, 0.12-nin tezliklə buraxılacağı deməkdir.
0.12 bir çox yeni şeydir. Əgər siz adi proqramlaşdırmadan gəlirsinizsə, onda siz sol və sağ hissələrin eyni vaxtda deyil, vəziyyətdən asılı olaraq hesablandığı hər cür dinamik blokları, döngələri, müntəzəm və şərti müqayisə əməliyyatlarını əldən verirsiniz. Çox darıxırsınız, ona görə də 0.12 sizin üçün həll edəcək.
Amma! Hazır modullardan, üçüncü tərəf həllərindən istifadə edərək daha az və daha asan yazsanız, o zaman gözləməli olmayacaqsınız və 0.12 gəlib sizin üçün hər şeyi düzəldəcək.
Hesabat üçün təşəkkür edirik! Siz infrastrukturdan kod kimi danışdınız və hərfi mənada testlər haqqında bir kəlmə dediniz. Vahid testləri lazımdırmı? Bu kimin məsuliyyətidir? Mən özüm yazmalıyam yoxsa modulların məsuliyyətidir?
Gələn il hər şeyi sınaqdan keçirməyə qərar verdiyimiz barədə xəbərlərlə bombalanacaq. Nəyi sınamaq ən böyük sualdır. Müxtəlif provayderlərdən çoxlu asılılıqlar, çoxlu məhdudiyyətlər var. Sənlə mən danışanda “Mənə testlər lazımdır” deyəndə mən soruşuram: “Nə sınayacaqsınız?”. Öz bölgənizdə sınaqdan keçirəcəyinizi deyirsiniz. Sonra deyirəm ki, mənim rayonda bu işləmir. Yəni biz sizinlə bu barədə heç razılaşa bilmərik. Texniki problemlərin çox olduğunu demirəm. Yəni bu testləri necə yazmaq lazımdır ki, adekvat olsun.
Mən bu mövzunu aktiv şəkildə araşdırıram, yəni sizin yazdığınız infrastruktur əsasında testləri avtomatik olaraq necə yaratmaq olar. Yəni bu kodu siz yazmısınızsa, onda mən onu işə salmalıyam, bunun əsasında testlər yarada bilərəm.
- bu Terraform üçün inteqrasiya testləri yazmağa imkan verən ən çox qeyd olunan kitabxanalardan biridir. Bu kommunal xidmətlərdən biridir. Mən rspec kimi bir DSL növünə üstünlük verirəm.
Anton, hesabata görə təşəkkürlər! Mənim adım Valeridir. İcazə verin sizə bir az fəlsəfi sual verim. Şərti olaraq, təminat var, yerləşdirmə var. Təminat mənim infrastrukturumu yaradır, yerləşdirmə zamanı biz onu faydalı bir şeylə doldururuq, məsələn, serverlər, proqramlar və s. Və mənim ağlıma gəlir ki, Terraform daha çox təchizat üçün, Ansible isə daha çox yerləşdirmə üçündür, çünki Ansible həm də fizikidir. infrastruktur nginx, Postgres quraşdırmaq imkanı verir. Ancaq eyni zamanda, Ansible, məsələn, Amazon və ya Google resurslarını təmin etməyə imkan verir. Lakin Terraform modullarının köməyi ilə bəzi proqram təminatı yerləşdirməyə də imkan verir. Sizin fikrinizcə, Terraform və Ansible arasında sərhəd varmı, harada və nədən istifadə etmək daha yaxşıdır? Yoxsa, məsələn, Ansible-ın artıq zibil olduğunu düşünürsən, hər şey üçün Terraformdan istifadə etməyə çalışmalısan?
Yaxşı sual, Valeri. Hesab edirəm ki, Terraform 2014-cü ildən bəri məqsəd baxımından dəyişməyib. İnfrastruktur üçün tikilib və infrastruktur üçün ölüb. Ansible-ın konfiqurasiya idarəçiliyinə hələ də ehtiyacımız var idi və lazımdır. Çətinlik ondadır ki, launch_configuration daxilində istifadəçi məlumatı var. Və orada siz Ansible-ı çəkirsiniz və s. Bu, mənim ən çox bəyəndiyim standart delimitasiyadır.
Əgər gözəl infrastrukturdan danışırıqsa, o zaman bu görüntünü yaradan Packer kimi kommunal proqramlar var. Sonra Terraform bu şəkli tapmaq və onun launch_konfiqurasiyasını yeniləmək üçün məlumat mənbəyindən istifadə edir. Yəni, bu şəkildə boru kəməri ondan ibarətdir ki, biz əvvəlcə Tracker-i, sonra Terraform-u çəkirik. Bir quruluş varsa, yeni bir dəyişiklik baş verir.
Salam! Hesabat üçün təşəkkür edirik! Mənim adım Misha, RBS şirkətidir. Resurs yaratarkən provayder vasitəsilə Ansible-a zəng edə bilərsiniz. Həm də Ansible-da dinamik inventar kimi bir mövzu var. Və əvvəlcə Terraform-a zəng edə bilərsiniz, sonra isə dövlətdən resursları götürəcək və onu icra edəcək Ansible-a zəng edə bilərsiniz. Hansı daha yaxşıdır?
Və bu və insanlar eyni müvəffəqiyyətlə istifadə edirlər. Mənə elə gəlir ki, Ansible-da dinamik inventar, əgər biz avtomatik miqyaslı qrupdan danışmırıqsa, əlverişli bir şeydir. Çünki autoscaling qrupunda bizim artıq launch_configuration adlı öz alət dəstimiz var. Biz launch_configuration-da yeni resurs yaratdıqda işə salınması lazım olan hər şeyi yazırıq. Buna görə Amazon ilə dinamik inventardan istifadə etmək və Terraform ts faylını oxumaq mənim fikrimcə həddən artıq ağırdır. "Avtomatik miqyaslama qrupu" anlayışının olmadığı digər vasitələrdən istifadə edirsinizsə, məsələn, DigitalOcean və ya avtomatik miqyaslama qrupu olmayan başqa bir provayderdən istifadə edirsinizsə, onda API tutacaqlarını çəkməli, IP ünvanlarını tapmalı, yaratmalısınız. dinamik inventar faylı və Ansible artıq onu gəzəcək. Yəni Amazon üçün launch_configuration, qalan hər şey üçün isə dinamik inventar var.
Mənbə: www.habr.com