Көптеген адамдар Terraform-ті күнделікті жұмысында біледі және пайдаланады, бірақ ол үшін ең жақсы тәжірибе әлі қалыптаспаған. Әр команда өзінің тәсілдер мен әдістерін ойлап табуы керек.
Сіздің инфрақұрылымыңыз оңай басталады: бірнеше ресурстар + бірнеше әзірлеушілер. Уақыт өте келе ол барлық бағытта өседі. Ресурстарды Terraform модульдеріне топтастыру, кодты қалталарға ұйымдастыру жолдарын табасыз ба және тағы не қате болуы мүмкін? (белгілі соңғы сөздер)
Уақыт өтеді және сіздің инфрақұрылымыңыз сіздің жаңа үй жануарыңыз сияқты сезінесіз, бірақ неге? Сіз инфрақұрылымдағы түсініксіз өзгерістерге алаңдайсыз, инфрақұрылым мен кодқа қол тигізуге қорқасыз - нәтижесінде сіз жаңа функцияларды кешіктіресіз немесе сапаны төмендетесіз...
Github жүйесінде AWS үшін Terraform қауымдастығы модульдерінің топтамасын үш жыл басқарғаннан кейін және өндірісте Terraform-ға ұзақ мерзімді техникалық қызмет көрсетуден кейін Антон Бабенко өз тәжірибесімен бөлісуге дайын: болашақта зиян тигізбеуі үшін TF модульдерін қалай жазу керек.
Әңгіменің соңында қатысушылар Terraform жүйесіндегі ресурстарды басқару принциптерімен, Terraform модульдерімен байланысты озық тәжірибелермен және инфрақұрылымды басқарумен байланысты кейбір үздіксіз интеграция принциптерімен көбірек таныс болады.
Жауапкершіліктен бас тарту: Бұл есептің 2018 жылдың қарашасында екенін ескертемін — 2 жыл өтті. Есепте талқыланған Terraform 0.11 нұсқасына енді қолдау көрсетілмейді. Соңғы 2 жылда көптеген жаңалықтарды, жақсартуларды және өзгерістерді қамтитын 2 жаңа шығарылым шығарылды. Осыған назар аударып, құжаттаманы тексеріңіз.
сілтемелер:
- +
- — автоматты пішімдеу коды және құжаттама
- — Terraform модульдерінің генераторы (WIP)
- — Көрнекі диаграммалардан терраформалық код генераторы (WIP)
- www.terraform-best-practices.com
- (Жаңа хабарламалар менің www.antonbabenko.com/ жеке сайтымда)
- @antonbabenko - Твиттер және әртүрлі слэктердің тобы
Менің атым Антон Бабенко. Кейбіреулеріңіз мен жазған кодты пайдаланған шығарсыз. Мен қазір бұл туралы бұрынғыдан да сенімдірек айтамын, өйткені менде статистикаға қол жетімді.
Мен Terraform-да жұмыс істеймін және 2015 жылдан бері Terraform және Amazon-қа қатысты ашық бастапқы жобалардың көп санына белсенді қатысушы және үлес қосушы болдым.
Содан бері мен оны қызықты етіп қою үшін жеткілікті код жаздым. Ал мен бұл туралы қазір айтып беруге тырысамын.
Мен Terraform-пен жұмыс істеудің қыр-сырлары мен ерекшеліктері туралы айтатын боламын. Бірақ бұл шын мәнінде HighLoad тақырыбы емес. Ал енді неге екенін түсінесіз.
Уақыт өте келе мен Terraform модульдерін жаза бастадым. Пайдаланушылар сұрақтар жазды, мен оларды қайта жаздым. Содан кейін мен кодты алдын ала орындау ілгегі арқылы пішімдеу үшін әртүрлі утилиталарды жаздым.
Көптеген қызықты жобалар болды. Маған код генерациясы ұнайды, себебі мен компьютердің маған және бағдарламашыға көбірек жұмыс істегенін ұнатамын, сондықтан мен қазір визуалды диаграммалардан Terraform код генераторында жұмыс істеп жатырмын. Мүмкін сіздердің кейбіреулеріңіз оларды көрген шығар. Бұл жебелері бар әдемі қораптар. Менің ойымша, егер сіз «Экспорттау» түймесін басып, бәрін код ретінде алсаңыз, бұл өте жақсы.
Мен украинаданмын. Мен көп жылдар бойы Норвегияда тұрдым.
Сондай-ақ, бұл репортаж үшін ақпарат менің атымды білетін және мені әлеуметтік желілерден табатын адамдардан жиналды. Менде әрқашан дерлік бірдей лақап есім бар.
Мен атап өткенімдей, мен Terraform AWS модульдерінің негізгі қолдаушысымын, ол GitHub-тағы ең үлкен репозиторийлердің бірі болып табылады, онда біз ең көп таралған тапсырмаларға арналған модульдерді орналастырамыз: VPC, Autoscaling, RDS.
Ал қазір естігендеріңіз ең қарапайым. Егер сіз Terraform не екенін түсінетініңізге күмәндансаңыз, уақытыңызды басқа жерде өткізгеніңіз жөн. Мұнда көптеген техникалық терминдер болады. Ал мен баяндаманың деңгейін ең жоғары деп жариялаудан тартынбадым. Бұл барлық мүмкін терминдерді көп түсіндірместен қолдана алатынымды білдіреді.
Terraform 2014 жылы инфрақұрылымды код ретінде жазуға, жоспарлауға және басқаруға мүмкіндік беретін қызметтік бағдарлама ретінде пайда болды. Мұндағы негізгі ұғым – «инфрақұрылым код ретінде».
Барлық құжаттама, мен айтқанымдай, жазылған . Көптеген адамдар бұл сайт туралы біледі және құжаттаманы оқыды деп үміттенемін. Егер солай болса, сіз дұрыс жердесіз.
Кәдімгі Terraform конфигурация файлы осылай көрінеді, мұнда біз алдымен кейбір айнымалыларды анықтаймыз.
Бұл жағдайда біз «aws_region» анықтаймыз.
Содан кейін біз қандай ресурстарды жасағымыз келетінін сипаттаймыз.
Тәуелділіктер мен провайдерлерді жүктеу үшін біз кейбір пәрмендерді, атап айтқанда «terraform init» іске қосамыз.
Көрсетілген конфигурацияның біз жасаған ресурстарға сәйкес келетінін тексеру үшін біз «terraform application» пәрменін іске қосамыз. Біз бұрын ештеңе жасамағандықтан, Terraform бізге осы ресурстарды жасауға шақырады.
Біз мұны растаймыз. Осылайша біз теңіз ұлулары деп аталатын шелек жасаймыз.
Сондай-ақ бірнеше ұқсас утилиталар бар. Amazon қолданбасын пайдаланатындардың көпшілігі AWS CloudFormation немесе Google Cloud Deployment Manager немесе Azure Resource Manager бағдарламасын біледі. Олардың әрқайсысында осы жалпы бұлттық провайдерлердің әрқайсысында ресурстарды басқаруға арналған қандай да бір өзіндік іске асыру бар. Terraform әсіресе пайдалы, себебі ол 100-ден астам провайдерді басқаруға мүмкіндік береді. (Толығырақ )
Терраформ басынан бастап алға қойған мақсаттары:
- Terraform ресурстардың бір көрінісін береді.
- Барлық заманауи платформаларды қолдауға мүмкіндік береді.
- Ал Terraform ең басынан бастап инфрақұрылымды қауіпсіз және болжамды түрде өзгертуге мүмкіндік беретін утилита ретінде жасалған.
2014 жылы «болжауға болатын» сөзі осы контексте өте ерекше болып шықты.
Terraform – әмбебап утилита. Егер сізде API болса, онда сіз бәрін басқара аласыз:
- Сіз қалағанның бәрін басқару үшін 120-дан астам провайдерді пайдалана аласыз.
- Мысалы, GitHub репозиторийлеріне кіруді сипаттау үшін Terraform қолданбасын пайдалануға болады.
- Сіз тіпті Jira-да қателерді жасап, жаба аласыз.
- Жаңа реликтік көрсеткіштерді басқаруға болады.
- Шынымен де қаласаңыз, dropbox ішінде файлдарды жасауға болады.
Мұның барлығына Go бағдарламасында сипаттауға болатын ашық API бар Terraform провайдерлерінің көмегімен қол жеткізіледі.
Алдыңғы слайдтарда көрсеткенімдей, біз Terraform-ды пайдалана бастадық делік, сайттағы кейбір құжаттамаларды оқыдық, біраз бейне көріп, main.tf жаза бастадық.
Және бәрі тамаша, сізде VPC жасайтын файл бар.
VPC жасағыңыз келсе, шамамен осы 12 жолды көрсетіңіз. Қай аймақта жасағыңыз келетінін, қандай cidr_block IP мекенжайларын пайдалану керектігін сипаттаңыз. Болды.
Әрине, жоба біртіндеп өседі.
Ол жерде сіз көптеген жаңа нәрселерді қосасыз: ресурстар, деректер көздері, сіз жаңа провайдерлермен біріктіресіз, кенеттен GitHub тіркелгісіндегі пайдаланушыларды басқару үшін Terraform қолданбасын пайдаланғыңыз келеді, т.б. Басқаларын пайдаланғыңыз келуі мүмкін. DNS провайдерлері, бәрін кесіп өтіңіз. Terraform мұны жеңілдетеді.
Келесі мысалды қарастырайық.
Сіз VPC ресурстарының интернетке қол жеткізуін қалайтындықтан, internet_gateway параметрін біртіндеп қосасыз. Бұл жақсы идея болып табылады.
Нәтиже мына негізгі.tf:
Бұл main.tf сайтының жоғарғы бөлігі.
Бұл main.tf файлының төменгі бөлігі.
Содан кейін ішкі желіні қосасыз. NAT шлюздерін, маршруттарды, маршруттау кестелерін және басқа ішкі желілерді қосқыңыз келген кезде сізде 38 жол емес, шамамен 200-300 жол болады.
Яғни, main.tf файлыңыз біртіндеп өсіп келеді. Көбінесе адамдар бәрін бір файлға қояды. main.tf файлында 10-20 Кб көрсетіледі. 10-20 Кб мәтіндік мазмұн деп елестетіңіз. Және бәрі бәріне байланысты. Бұл бірте-бірте жұмыс істеу қиынға соғады. 10-20 Кб жақсы пайдаланушы жағдайы, кейде одан да көп. Және адамдар мұны әрқашан жаман деп ойламайды.
Кәдімгі бағдарламалаудағы сияқты, яғни код ретінде инфрақұрылым емес, біз әртүрлі сыныптардың, пакеттердің, модульдердің, топтамалардың жиынтығын қолдануға үйрендік. Terraform сізге бірдей нәрсені жасауға мүмкіндік береді.
- Код өсіп келеді.
- Ресурстар арасындағы тәуелділік те өсуде.
Ал бізге үлкен қажеттілік бар. Біз енді бұлай өмір сүре алмайтынымызды түсінеміз. Біздің кодымыз орасан зор болып келеді. 10-20 Кб, әрине, өте үлкен емес, бірақ біз тек желілік стек туралы айтып отырмыз, яғни сіз тек желілік ресурстарды қостыңыз. Біз 100 Кб оңай тоқуға болатын Application Load Balancer, ES кластерін орналастыру, Kubernetes және т.б. туралы айтып отырған жоқпыз. Егер сіз мұның бәрін жазып алсаңыз, сіз Terraform Terraform модульдерін қамтамасыз ететінін жақын арада білесіз.
Terraform модульдері топ ретінде басқарылатын дербес Terraform конфигурациясы болып табылады. Бұл Terraform модульдері туралы білуіңіз керек нәрсе. Олар мүлде ақылды емес, бір нәрсеге байланысты күрделі байланыстарды жасауға мүмкіндік бермейді. Мұның бәрі әзірлеушілердің иығына түседі. Яғни, бұл сіз жазған Terraform конфигурациясының бір түрі ғана. Сіз оны жай ғана топ деп атай аласыз.
Сондықтан біз 10-20-30 Кб кодты қалай оңтайландыратынымызды түсінуге тырысамыз. Біз бірте-бірте кейбір модульдерді пайдалану керектігін түсінеміз.
Сіз кездесетін модульдердің бірінші түрі ресурс модульдері болып табылады. Олар сіздің инфрақұрылымыңыздың не туралы екенін, сіздің бизнесіңіздің немен айналысатынын, қай жерде және қандай шарттар бар екенін түсінбейді. Дәл осы модульдер мен ашық бастапқы қауымдастықпен бірге басқаратын және біз сіздің инфрақұрылымыңыз үшін ең бастапқы құрылыс блоктары ретінде ұсынған модульдер.
Ресурс модулінің мысалы.
Ресурс модулін шақырған кезде оның мазмұнын қай жолдан жүктеу керектігін анықтаймыз.
Біз жүктеп алғыңыз келетін нұсқаны көрсетеміз.
Біз сол жерде көптеген дәлелдер келтіреміз. Болды. Бұл модульді пайдаланған кезде білуіміз керек нәрсе.
Көптеген адамдар соңғы нұсқаны пайдаланса, бәрі тұрақты болады деп ойлайды. Бірақ жоқ. Инфрақұрылым нұсқа болуы керек, біз осы немесе басқа компонент қай нұсқаға орналастырылғанына нақты жауап беруіміз керек.
Міне, осы модульдің ішіндегі код. Қауіпсіздік тобының модулі. Мұнда айналдыру 640-шы жолға өтеді. Кез келген ықтимал конфигурацияда Amazon-да қауіпсіздік тобының ресурсын жасау өте маңызды емес тапсырма болып табылады. Қауіпсіздік тобын құру және оған қандай ережелерді беру керектігін айту жеткіліксіз. Бұл өте қарапайым болар еді. Amazon ішінде миллиондаған түрлі шектеулер бар. Мысалы, егер сіз қолдансаңыз VPC соңғы нүктесі, префикстер тізімі, әртүрлі API интерфейстері және мұның бәрін басқалармен біріктіруге тырысады, содан кейін Terraform мұны істеуге мүмкіндік бермейді. Amazon API да бұған рұқсат бермейді. Сондықтан біз осы қорқынышты логиканы модульде жасырып, пайдаланушы кодын дәл осылай көрінетін етіп беруіміз керек.
Пайдаланушы оның ішінде қалай жасалғанын білудің қажеті жоқ.
Ресурс модульдерінен тұратын модульдердің екінші түрі сіздің бизнесіңізге көбірек сәйкес келетін мәселелерді шешеді. Көбінесе бұл Terraform кеңейтімі болып табылатын және тегтер, компания стандарттары үшін кейбір қатаң мәндерді орнататын орын. Сондай-ақ, Terraform қазір пайдалануға рұқсат етпейтін функционалдылықты қоса аласыз. Бұл дәл қазір. Енді 0.11 нұсқасы, ол өткеннің еншісінде. Дегенмен, препроцессорлар, jsonnet, cookiecutter және басқа да көптеген заттар толыққанды жұмыс үшін қолданылуы керек көмекші механизм болып табылады.
Әрі қарай мен мұның бірнеше мысалдарын көрсетемін.
Инфрақұрылымдық модуль дәл осылай аталады.
Мазмұнды қай жерден жүктеп алу керектігі көрсетілген.
Бұл модульге бірнеше мәндер жіберіледі және беріледі.
Әрі қарай, осы модуль ішінде VPC немесе Бағдарлама жүктемесін теңестіруші жасау немесе қауіпсіздік тобын немесе серпімді контейнер қызметі кластерін жасау үшін ресурс модульдерінің жиынтығы шақырылады.
Модульдердің екі түрі бар. Мұны түсіну маңызды, себебі мен осы есепте топтастырылған ақпараттың көпшілігі құжаттамада жазылмаған.
Ал қазір Terraform құжаттамасы өте қиын, өйткені ол жай ғана бұл мүмкіндіктер бар екенін айтады, сіз оларды пайдалана аласыз. Бірақ ол бұл мүмкіндіктерді қалай пайдалану керектігін, неліктен оларды пайдалану жақсы екенін айтпайды. Сондықтан, өте көп адамдар өмір сүре алмайтын нәрсені жазады.
Енді осы модульдерді қалай жазу керектігін қарастырайық. Содан кейін біз оларды қалай шақыру керектігін және кодпен қалай жұмыс істеу керектігін көреміз.
Terraform тізілімі -
№0 кеңес - ресурс модульдерін жазбау. Бұл модульдердің көпшілігі сіз үшін жазылған. Мен айтқанымдай, олар ашық бастапқы код, оларда сіздің бизнес логикаңыздың ешқайсысы жоқ, оларда IP мекенжайлары, құпия сөздер және т.б. үшін қатты кодталған мәндер жоқ. Модуль өте икемді. Және ол қазірдің өзінде жазылған болуы мүмкін. Amazon ресурстарына арналған көптеген модульдер бар. 650-ге жуық. Ал олардың көпшілігінің сапасы жақсы.
Бұл мысалда сізге біреу келіп: «Мен дерекқорды басқара алғым келеді. Мен дерекқор жасай алатындай модуль жасаңыз." Адам Amazon немесе Terraform іске асыру туралы мәліметтерді білмейді. Ол жай ғана: «Мен MSSQL-ті басқарғым келеді» дейді. Яғни, ол біздің модульді шақырады, қозғалтқыш түрін сол жерде өткізеді және уақыт белдеуін көрсетеді.
Бұл модульдің ішінде екі түрлі ресурс жасайтынымызды адам білмеуі керек: біреуі MSSQL үшін, екіншісі қалғаны үшін, тек Terraform 0.11-де уақыт белдеуі мәндерін қосымша ретінде көрсете алмайсыз.
Ал бұл модульден шыққан кезде адам жай ғана мекен-жайды ала алады. Осының бәрін іштей қай дерекқордан, қай ресурстан жасап жатқанымызды ол білмейді. Бұл жасырудың өте маңызды элементі. Бұл ашық бастапқы кодта жалпыға қолжетімді модульдерге ғана емес, сонымен қатар жобаларыңыз бен командаларыңызда жазатын модульдерге де қатысты.
Бұл екінші дәлел, егер сіз Terraform қолданбасын біраз уақыт пайдалансаңыз өте маңызды. Сізде компания үшін барлық Terraform модульдерін орналастыратын репозиторий бар. Уақыт өте келе бұл жобаның көлемі бір немесе екі мегабайтқа дейін өсетіні қалыпты жағдай. Бұл жақсы.
Бірақ мәселе Terraform бұл модульдерді қалай атайды. Мысалы, әрбір жеке пайдаланушыны жасау үшін модульді шақырсаңыз, Terraform алдымен бүкіл репозиторийді жүктейді, содан кейін сол нақты модуль орналасқан қалтаға өтеді. Осылайша сіз әр уақытта бір мегабайт жүктейсіз. Егер сіз 100 немесе 200 пайдаланушыны басқарсаңыз, онда сіз 100 немесе 200 мегабайт жүктейсіз, содан кейін сол қалтаға өтіңіз. Сондықтан, әрине, сіз «Terraform init» түймесін басқан сайын көптеген материалдарды жүктеп алғыңыз келмейді.
Бұл мәселенің екі шешімі бар. Біріншісі - салыстырмалы жолдарды пайдалану. Осылайша сіз кодта қалтаның жергілікті (./) екенін көрсетесіз. Кез келген нәрсені іске қоспас бұрын, сіз жергілікті түрде осы репозиторийдің Git клонын жасайсыз. Осылайша сіз мұны бір рет жасайсыз.
Әрине, кемшіліктер көп. Мысалы, нұсқаны пайдалану мүмкін емес. Және бұл кейде өмір сүру қиын.
Екінші шешім. Егер сізде көптеген субмодульдер болса және сізде әлдеқашан орнатылған құбыр бар болса, онда монорепозиторийден көптеген әртүрлі пакеттерді жинауға және оларды S3-ге жүктеуге мүмкіндік беретін MBT жобасы бар. Бұл өте жақсы жол. Осылайша, iam-user-1.0.0.zip файлының салмағы небәрі 1 Кб болады, себебі бұл ресурсты құру коды өте аз. Және ол әлдеқайда жылдам жұмыс істейді.
Модульдерде нені қолдануға болмайтыны туралы сөйлесейік.
Неліктен модульдерде бұл зұлымдық бар? Ең нашар нәрсе - пайдаланушыны қабылдау. Пайдаланушыны әртүрлі адамдар пайдалана алатын провайдердің аутентификация опциясы деп есептейік. Мысалы, біз бәріміз рөлді ассимиляциялаймыз. Бұл Terraform бұл рөлді алады дегенді білдіреді. Содан кейін осы рөл арқылы ол басқа әрекеттерді орындайды.
Жамандығы сол, егер Вася Amazon-қа бір жолмен қосылуды ұнатса, мысалы, әдепкі орта айнымалысын пайдаланып, ал Петя құпия жерде бар ортақ кілтін пайдаланғанды ұнатса, онда екеуін де көрсете алмайсыз. Терраформа. Және олар қайғы-қасіретке ұшырамауы үшін модульде бұл блокты көрсетудің қажеті жоқ. Бұл жоғары деңгейде көрсетілуі керек. Яғни, бізде ресурстық модуль, инфрақұрылымдық модуль және жоғарғы жағында композиция бар. Және бұл жоғарырақ жерде көрсетілуі керек.
Екінші жамандық – ризық беруші. Бұл жерде зұлымдық соншалықты тривиальды емес, өйткені егер сіз кодты жазсаңыз және ол сіз үшін жұмыс істейтін болса, онда ол жұмыс істейтін болса, оны неге өзгерту керек деп ойлауыңыз мүмкін.
Ең жаманы, сіз бұл провайдердің қашан іске қосылатынын әрқашан бақылай алмайсыз. Екіншіден, сіз aws ec2 нені білдіретінін бақыламайсыз, яғни біз қазір Linux немесе Windows туралы айтып отырмыз. Сондықтан әртүрлі операциялық жүйелерде немесе әртүрлі пайдаланушы жағдайларында бірдей жұмыс істейтін нәрсені жаза алмайсыз.
Ресми құжаттамада да көрсетілген ең көп таралған мысал, егер сіз aws_instance деп жазып, аргументтер тобын көрсетсеңіз, онда «local-exec» провайдерін көрсетіп, ansible-ді іске қосатын болсаңыз, онда ешқандай қате жоқ. ойын кітапшасы.
Шындығында, иә, бұл жерде ештеңе жоқ. Бірақ көп ұзамай сіз бұл жергілікті-exec нәрсесінің жоқ екенін түсінесіз, мысалы, launch_configuration.
Ал іске қосу_конфигурациясын пайдаланғанда және бір данадан автомасштабтау тобын жасағыңыз келсе, launch_configuration ішінде «провайдер» ұғымы жоқ. «Пайдаланушы деректері» деген ұғым бар.
Сондықтан әмбебап шешім - пайдаланушы деректерін пайдалану. Және ол дананың өзінде, данасы қосылғанда немесе автоматты масштабтау тобы осы іске қосу_конфигурациясын пайдаланған кезде, сол пайдаланушы деректерінде іске қосылады.
Егер сіз әлі де провайдерді іске қосқыңыз келсе, себебі ол желімдеу компоненті, бір ресурс жасалған кезде, сол сәтте провайдеріңізді, пәрменіңізді іске қосуыңыз керек. Мұндай жағдайлар өте көп.
Және бұл үшін ең дұрыс ресурс null_resource деп аталады. Null_resource - ешқашан нақты жасалмаған жалған ресурс. Ол ештеңеге тимейді, API жоқ, автомасштабтау жоқ. Бірақ ол пәрменді қашан іске қосу керектігін басқаруға мүмкіндік береді. Бұл жағдайда пәрмен жасау кезінде орындалады.
байланыс
Бірнеше белгілер бар. Мен барлық белгілерді егжей-тегжейлі қарастырмаймын. Бұл туралы мақала бар. Бірақ егер сіз Terraform-пен жұмыс істеген болсаңыз немесе басқа адамдардың модульдерін пайдалансаңыз, онда сіз көптеген модульдерді, мысалы, ашық бастапқы кодтағы кодтардың көпшілігін адамдар өздерінің қажеттіліктері үшін жазғанын жиі байқадыңыз. Оны бір адам жазып, өз мәселесін шешті. Мен оны GitHub-ға қойдым, ол өмір сүрсін. Ол өмір сүреді, бірақ онда құжаттама мен мысалдар болмаса, оны ешкім пайдаланбайды. Ал егер оның нақты тапсырмасынан сәл артық шешуге мүмкіндік беретін функционалдылық болмаса, оны ешкім де пайдаланбайды. Пайдаланушыларды жоғалтудың көптеген жолдары бар.
Адамдар пайдаланатындай бірдеңе жазғыңыз келсе, мына белгілерді орындауға кеңес беремін.
Олар мыналар:
- Құжаттар мен мысалдар.
- Толық функционалдылық.
- Ақылға қонымды әдепкілер.
- Таза код.
- Тесттер.
Тесттер басқа жағдай, өйткені оларды жазу өте қиын. Мен құжаттар мен мысалдарға көбірек сенемін.
Сонымен, біз модульдерді қалай жазу керектігін қарастырдық. Екі аргумент бар. Біріншісі, ең бастысы, мүмкіндігіңіз болса жазбаңыз, өйткені бұл тапсырмаларды сізден бұрын бір топ адамдар орындап қойған. Екіншіден, егер сіз әлі де шешім қабылдасаңыз, модульдер мен провайдерлерде провайдерлерді қолданбауға тырысыңыз.
Бұл құжаттаманың сұр бөлігі. Сіз қазір ойлайтын шығарсыз: «Бір нәрсе түсініксіз. Сенімді емес». Бірақ алты айдан кейін көреміз.
Енді осы модульдерді қалай шақыруға болатынын айтайық.
Біздің кодымыз уақыт өте келе өсетінін түсінеміз. Бізде енді бір файл жоқ, бізде 20 файл бар. Олардың барлығы бір қалтада. Немесе бес қалта болуы мүмкін. Мүмкін біз оларды аймақтарға, кейбір құрамдас бөліктерге бөле бастайтын шығармыз. Содан кейін біз қазір синхрондау және оркестрлеудің кейбір негіздері бар екенін түсінеміз. Яғни, егер біз желі ресурстарын өзгертсек, не істеу керектігін, қалған ресурстармен не істеу керектігін, осы тәуелділіктерді қалай тудыратынын және т.б. түсінуіміз керек.
Екі шек бар. Бірінші экстремаль барлығы бір жерде. Бізде бір негізгі файл бар. Әзірге бұл Terraform веб-сайтындағы ресми ең жақсы тәжірибе болды.
Бірақ қазір ол ескірген және жойылған деп жазылған. Уақыт өте келе, Terraform қауымдастығы бұл ең жақсы тәжірибеден алыс екенін түсінді, өйткені адамдар жобаны әртүрлі тәсілдермен пайдалана бастады. Және проблемалар бар. Мысалы, біз барлық тәуелділіктерді бір жерде тізімдегенде. Біз «Terraform жоспарын» басқан кезде және Terraform барлық ресурстардың күйлерін жаңартпайынша, көп уақыт өтуі мүмкін жағдайлар бар.
Көп уақыт, мысалы, 5 минут. Кейбіреулер үшін бұл көп уақыт. Мен 15 минутқа созылған жағдайларды көрдім. AWS API әр ресурстың күйімен не болып жатқанын анықтауға 15 минут жұмсады. Бұл өте үлкен аумақ.
Және, әрине, бір жерде бір нәрсені өзгерткіңіз келгенде, байланысты мәселе пайда болады, содан кейін сіз 15 минут күтесіз және ол сізге кейбір өзгерістердің кенептерін береді. Сіз түкірдіңіз, «Иә» деп жаздыңыз, бірдеңе дұрыс болмады. Бұл өте нақты мысал. Terraform сізді проблемалардан қорғауға тырыспайды. Яғни, қалағаныңызды жазыңыз. Мәселелер болады - сіздің проблемаларыңыз. Terraform 0.11 сізге ешқандай жолмен көмектесуге тырыспайды. 0.12-де: «Вася, сен мұны шынымен қалайсың, өзіңе келе аласың ба?» Деуге мүмкіндік беретін қызықты жерлер бар.
Екінші әдіс - бұл аумақты азайту, яғни бір жерден қоңырау шалу басқа жерден азырақ қосылуы мүмкін.
Жалғыз мәселе - сізге көбірек код жазу керек, яғни файлдардың үлкен санындағы айнымалы мәндерді сипаттап, оны жаңарту керек. Кейбір адамдарға ұнамайды. Бұл мен үшін қалыпты жағдай. Кейбіреулер: «Неге мұны әртүрлі жерге жазамын, мен бәрін бір жерге қоямын» деп ойлайды. Бұл мүмкін, бірақ бұл екінші экстремалды.
Мұның бәрі бір жерде кім тұрады? Бір, екі, үш адам, яғни біреу пайдаланып жатыр.
Ал нақты бір компонентті, бір блокты немесе бір инфрақұрылым модулін кім атайды? Бес-жеті адам. Бұл керемет.
Ең көп таралған жауап - ортасында бір жерде. Егер жоба үлкен болса, онда сізде жиі ешқандай шешім қолайлы емес және бәрі де жұмыс істемейтін жағдайға тап боласыз, сондықтан сіз қоспамен аяқталасыз. Екеуінің де артықшылығы бар екенін түсінсеңіз, мұның еш жамандығы жоқ.
Егер VPC стекінде бірдеңе өзгерсе және сіз осы өзгерістерді EC2-ге қолданғыңыз келсе, яғни сізде жаңа ішкі желі болғандықтан автомасштабтау тобын жаңартқыңыз келсе, мен мұндай тәуелділік оркестрі деп атаймын. Кейбір шешімдер бар: кім не пайдаланады?
Мен қандай шешімдер бар екенін ұсына аламын. Сиқыр жасау үшін Терраформды пайдалануға болады немесе Terraform пайдалану үшін makefiles пайдалануға болады. Онда бірдеңе өзгергенін қараңыз, оны осы жерден іске қосуға болады.
Сізге бұл шешім қалай ұнады? Бұл керемет шешім екеніне біреу сене ме? Мен күлімсіреуді көрдім, шамасы, күмән пайда болды.
Әрине, мұны үйде сынамаңыз. Terraform ешқашан Terraform-дан жұмыс істеуге арналмаған.
Бір хабарда олар маған: «Жоқ, бұл жұмыс істемейді» деді. Мәселе мынада, ол жұмыс істемеуі керек. Terraform-тан Terraform-ды, содан кейін Terraform-ды іске қосқан кезде бұл өте әсерлі болып көрінсе де, мұны істемеу керек. Terraform әрқашан оңай басталуы керек.
Бір жерде бірдеңе өзгерген кезде қоңырау оркестрі қажет болса, онда Terragrunt бар.
Terragrunt - инфрақұрылымдық модульдерге қоңырауларды үйлестіруге және реттеуге мүмкіндік беретін Terraform қосымшасы, утилитасы.
Әдеттегі Terraform конфигурация файлы келесідей көрінеді.
Сіз қандай нақты модульге қоңырау шалғыңыз келетінін көрсетесіз.
Модульде қандай тәуелділіктер бар?
Және бұл модуль қандай аргументтерді қабылдайды. Террагрунт туралы білудің бәрі осы.
Құжаттама бар және GitHub-та 1 жұлдыз бар. Бірақ көп жағдайда бұл сізге білу керек нәрсе. Мұны Terraform-пен жұмыс істей бастаған компанияларда жүзеге асыру өте оңай.
Сонымен, оркестр - бұл Террагрунт. Басқа нұсқалар бар.
Енді кодпен қалай жұмыс істеу керектігі туралы сөйлесейік.
Кодыңызға жаңа мүмкіндіктерді қосу қажет болса, көп жағдайда бұл оңай. Сіз жаңа ресурс жазып жатырсыз, бәрі қарапайым.
Егер сізде алдын ала жасаған ресурс болса, мысалы, сіз AWS тіркелгісін ашқаннан кейін Terraform туралы білсеңіз және сізде бар ресурстарды пайдаланғыңыз келсе, модульді осылай кеңейту орынды болар еді. ол бар ресурстарды пайдалануды қолдайды.
Және блок ресурсын пайдалана отырып, жаңа ресурстарды құруды қолдады.
Шығаруда біз әрқашан пайдаланылған нәрсеге байланысты шығыс идентификаторын қайтарамыз.
Terraform 0.11-дегі екінші маңызды мәселе - тізімдермен жұмыс.
Қиындық мынада, егер бізде мұндай пайдаланушылар тізімі болса.
Біз бұл пайдаланушыларды блоктық ресурс арқылы жасағанда, бәрі жақсы болады. Біз барлық тізімді қарап шығамыз, әрқайсысына файл жасаймыз. Бәрі жақсы. Ал содан кейін, мысалы, ортада тұрған user3-ті осы жерден алып тастау керек, одан кейін жасалған барлық ресурстар қайта жасалады, себебі индекс өзгереді.
Күйлі ортада тізімдермен жұмыс істеу. Мемлекеттік орта дегеніміз не? Бұл ресурс жасалған кезде жаңа мән жасалатын жағдай. Мысалы, AWS кіру кілті немесе AWS құпия кілті, яғни пайдаланушы жасаған кезде біз жаңа Access немесе құпия кілт аламыз. Біз пайдаланушыны жойған сайын бұл пайдаланушыда жаңа кілт болады. Бірақ бұл фэн шуй емес, өйткені командадан шыққан сайын оған жаңа пайдаланушы жасасақ, пайдаланушы бізбен дос болғысы келмейді.
Бұл шешім. Бұл Jsonnet-те жазылған код. Jsonnet — Google ұсынған үлгілеу тілі.
Бұл пәрмен осы үлгіні қабылдауға мүмкіндік береді және нәтиже ретінде сіздің үлгіңізге сәйкес жасалған json файлын қайтарады.
Үлгі осылай көрінеді.
Terraform сізге HCL және Json екеуімен бірдей жұмыс істеуге мүмкіндік береді, сондықтан Json құру мүмкіндігіңіз болса, оны Terraform ішіне жылжытуға болады. .tf.json кеңейтімі бар файл сәтті жүктеледі.
Содан кейін біз онымен әдеттегідей жұмыс істейміз: terraform init, terramorm қолданылады. Ал біз екі пайдаланушы жасаймыз.
Қазір командадан біреу кетсе қорықпаймыз. Біз жай ғана json файлын өңдейміз. Вася Пупкин кетті, Петя Пяточкин қалды. Петя Пяточкин жаңа кілт алмайды.
Терраформды басқа құралдармен біріктіру шын мәнінде Terraform жұмысы емес. Terraform ресурстарды құруға арналған платформа ретінде құрылды және бұл. Кейінірек пайда болатын барлық нәрсе Терраформды алаңдатпайды. Ал ол жерде оны тоқудың қажеті жоқ. Сізге қажет нәрсенің бәрін жасайтын Ansible бар.
Терраформды кеңейтіп, бірдеңе аяқталғаннан кейін кейбір пәрмендерді шақырғымыз келген кезде жағдайлар туындайды.
Бірінші жол. Біз осы пәрменді жазатын жерде шығыс жасаймыз.
Содан кейін біз бұл пәрменді қабықша терраформасының шығысынан шақырамыз және біз қалаған мәнді көрсетеміз. Осылайша, команда барлық ауыстырылған мәндермен орындалады. Бұл өте ыңғайлы.
Екінші жол. Бұл біздің инфрақұрылымдағы өзгерістерге байланысты null_resource пайдалану. Кейбір ресурстың идентификаторы өзгерген кезде біз бірдей local-exe файлын шақыра аламыз.
Әрине, мұның бәрі қағазда тегіс, өйткені Amazon, барлық басқа мемлекеттік провайдерлер сияқты, өз бетінше көптеген жағдайларға ие.
Ең жиі кездесетін жағдай - AWS тіркелгісін ашқанда, қай аймақтарды пайдаланатыныңыз маңызды; онда бұл мүмкіндік қосылды ма; мүмкін сіз оны 2013 жылдың желтоқсанынан кейін ашқан шығарсыз; Мүмкін сіз VPC жүйесінде әдепкі параметрді пайдаланып жатқан шығарсыз. Көптеген шектеулер бар. Ал Amazon оларды құжаттамаға таратып жіберді.
Мен аулақ болуды ұсынатын бірнеше нәрсе бар.
Бастау үшін Terraform жоспары немесе Terraform CLI ішіндегі барлық құпия емес дәлелдерден аулақ болыңыз. Мұның барлығын tfvars файлына немесе орта айнымалысына қоюға болады.
Бірақ бұл сиқырлы пәрменді толығымен жаттап алудың қажеті жоқ. Terraform жоспары – бар және біз кетеміз. Бірінші айнымалы - var, екінші айнымалы - var, үшінші, төртінші. Мен жиі қолданатын код ретінде инфрақұрылымның ең маңызды принципі - кодты қарау арқылы мен онда не, қандай күйде және қандай құндылықтармен орналастырылғанын нақты түсінуім керек. Сондықтан мен құжаттаманы оқудың немесе Васядан кластерді жасау үшін қандай параметрлерді пайдаланғанын сұраудың қажеті жоқ. Мен жай ғана қоршаған ортаға жиі сәйкес келетін tfvars кеңейтімі бар файлды ашып, сонда бәрін қарауым керек.
Сондай-ақ, аумақты азайту үшін мақсатты аргументтерді пайдаланбаңыз. Бұл үшін шағын инфрақұрылымдық модульдерді пайдалану әлдеқайда оңай.
Сондай-ақ, параллелизмді шектеу және көбейтудің қажеті жоқ. Егер менде 150 ресурс болса және мен Amazon параллелизмін әдепкі 10-нан 100-ге дейін арттырғым келсе, бірдеңе дұрыс емес болуы мүмкін. Немесе қазір жақсы болуы мүмкін, бірақ Amazon сіз тым көп қоңырау шалып жатқаныңызды айтқан кезде, сіз қиындыққа тап боласыз.
Terraform осы мәселелердің көпшілігін қайта іске қосуға тырысады, бірақ сіз ештеңеге дерлік қол жеткізе алмайсыз. Параллелизм=1 - AWS API ішінде немесе Terraform провайдерінде қатеге тап болсаңыз, пайдалану үшін маңызды нәрсе. Содан кейін мынаны көрсету керек: параллелизм=1 және Terraform бір қоңырауды аяқтағанша күтіңіз, содан кейін екіншісі, содан кейін үшінші. Ол оларды бір-бірлеп іске қосады.
Адамдар маған: «Неліктен мен Terraform жұмыс кеңістігі жаман деп ойлаймын?» Деп сұрайды. Менің ойымша, инфрақұрылымның код ретінде принципі қандай инфрақұрылымның және қандай құндылықтармен жасалғанын көру болып табылады.
Жұмыс кеңістігін пайдаланушылар жасамаған. Бұл пайдаланушылар GitHub мәселелерінде Terraform жұмыс кеңістігінсіз өмір сүре алмайтынымызды жазды дегенді білдірмейді. Жоқ бұлай емес. Terraform Enterprise коммерциялық шешім болып табылады. HashiCorp ұсынған Terraform бізге жұмыс кеңістігі қажет деп шешті, сондықтан біз оны алып тастадық. Маған оны бөлек қалтаға салу оңайырақ. Содан кейін сәл көбірек файлдар болады, бірақ ол анық болады.
Кодпен қалай жұмыс істеу керек? Шындығында, тізімдермен жұмыс істеу жалғыз азап. Терраформды оңай алыңыз. Бұл сіз үшін барлық керемет нәрсені жасайтын нәрсе емес. Ол жерде құжаттамада жазылғанның бәрін ысырып тастаудың қажеті жоқ.
Баяндаманың тақырыбы «болашақ үшін» деп жазылған. Мен бұл туралы өте қысқаша айтамын. Болашақ үшін бұл 0.12 жақын арада шығарылатынын білдіреді.
0.12 - бұл бір тонна жаңа заттар. Егер сіз кәдімгі бағдарламалаудан келген болсаңыз, онда сіз динамикалық блоктардың, циклдардың, дұрыс және шартты салыстыру операцияларының барлық түрлерін жіберіп аласыз, мұнда сол және оң жақтар бір уақытта есептелмейді, бірақ жағдайға байланысты. Сіз оны қатты сағынасыз, сондықтан оны сіз үшін 0.12 шешеді.
Бірақ! Егер сіз дайын модульдер мен үшінші тарап шешімдерін пайдаланып, азырақ және қарапайымырақ жазсаңыз, күтудің қажеті жоқ және 0.12 келіп, сіз үшін бәрін түзетеді деп үміттенесіз.
Есеп үшін рахмет! Сіз инфрақұрылым туралы код ретінде айттыңыз және сынақтар туралы бір сөз айттыңыз. Модульдерде тесттер қажет пе? Бұл кімнің жауапкершілігі? Оны өзім жазуым керек пе, әлде модульдердің жауапкершілігі ме?
Келесі жыл біз бәрін сынақтан өткізуді шештік деген есептерге толы болады. Нені сынау керек - бұл ең үлкен сұрақ. Түрлі провайдерлерден көптеген тәуелділіктер, көптеген шектеулер бар. Сіз екеуміз сөйлесіп жатқанда: «Маған тест керек» десең, мен: «Нені сынайсың?» деп сұраймын. Өңіріңізде сынақтан өтемін дейсіз. Сосын менің облысымда бұл жұмыс істемейді деймін. Яғни, біз бұған келісе алмаймыз. Оны айтпағанда, техникалық ақаулар көп. Яғни, бұл тесттерді адекватты болу үшін қалай жазу керек.
Мен бұл тақырыпты белсенді түрде зерттеп жатырмын, яғни сіз жазған инфрақұрылым негізінде сынақтарды автоматты түрде жасау әдісі. Яғни, егер сіз осы кодты жазған болсаңыз, онда мен оны іске қосуым керек, соның негізінде тесттер жасай аламын.
Terraform үшін интеграциялық сынақтарды жазуға мүмкіндік беретін ең жиі айтылған кітапханалардың бірі болып табылады. Бұл утилиталардың бірі. Мен DSL түрін ұнатамын, мысалы, rspec.
Антон, есеп үшін рахмет! Менің атым Валерий. Кішкене философиялық сұрақ қояйын. Шартты түрде қамтамасыз ету бар, орналастыру бар. Қамтамасыз ету менің инфрақұрылымымды жасайды, орналастыру кезінде біз оны пайдалы нәрсемен толтырамыз, мысалы, серверлер, қолданбалар және т.б. Және менің ойымша, Terraform көбінесе қамтамасыз ету үшін, ал Ansible қолдану үшін көбірек, өйткені Ansible физикалық инфрақұрылымға да арналған. nginx, Postgres орнатуға мүмкіндік береді. Бірақ сонымен бірге Ansible, мысалы, Amazon немесе Google ресурстарын қамтамасыз етуге мүмкіндік беретін сияқты. Бірақ Terraform сонымен қатар оның модульдерін пайдаланып кейбір бағдарламалық жасақтаманы орналастыруға мүмкіндік береді. Сіздің көзқарасыңыз бойынша, Terraform және Ansible арасында өтетін қандай да бір шекара бар ма, қайда және нені қолданған дұрыс? Немесе, мысалы, Ansible қазірдің өзінде қоқыс деп ойлайсыз ба, Terraform-ды барлығына қолдануға тырысу керек пе?
Жақсы сұрақ, Валерий. Мен Terraform 2014 жылдан бері мақсаты жағынан өзгерген жоқ деп есептеймін. Ол инфрақұрылым үшін құрылды және инфрақұрылым үшін өлді. Бізде Ansible конфигурациясын басқаруға әлі де қажет болды және болады. Мәселе мынада, launch_configuration ішінде пайдаланушы деректері бар. Мұнда сіз Ansible, т.б. тартасыз. Бұл маған ең ұнайтын стандартты айырмашылық.
Егер біз әдемі инфрақұрылым туралы айтатын болсақ, онда бұл кескінді жинайтын Packer сияқты утилиталар бар. Содан кейін Terraform бұл кескінді табу және оның іске қосу_конфигурациясын жаңарту үшін деректер көзін пайдаланады. Яғни, осылайша біз алдымен Tracker тартамыз, содан кейін Terraform тартамыз. Ал егер құрастыру орын алса, жаңа өзгеріс орын алады.
Сәлеметсіз бе! Есеп үшін рахмет! Менің атым Миша, RBS компаниясы. Ресурсты жасау кезінде провайдер арқылы Ansible шақыруға болады. Ansible-де динамикалық түгендеу деп аталатын тақырып бар. Сіз алдымен Terraform-ға, содан кейін мемлекеттен ресурстарды алып, оны орындайтын Ansible-ге қоңырау шала аласыз. Не жақсы?
Адамдар екеуін бірдей табыспен пайдаланады. Менің ойымша, Ansible-дегі динамикалық түгендеу, егер біз автомасштабтау тобы туралы айтпасақ, ыңғайлы нәрсе. Өйткені автомасштабтау тобында бізде іске қосу_конфигурация деп аталатын жеке құралдар жинағы бар. launch_configuration ішінде біз жаңа ресурс жасаған кезде іске қосу қажет барлық нәрсені жазамыз. Сондықтан, Amazon-да динамикалық инвентаризацияны пайдалану және Terraform ts файлын оқу, менің ойымша, артық. Егер сіз «автомасштабтау тобы» түсінігі жоқ басқа құралдарды пайдалансаңыз, мысалы, DigitalOcean немесе автомасштабтау тобы жоқ басқа провайдерді қолдансаңыз, онда сіз API-ны қолмен тартып, IP мекенжайларын тауып, жасауыңыз керек. динамикалық түгендеу файлы және Ansible оны аралап шығады. Яғни, Amazon үшін launch_configuration бар, ал қалғандарының барлығы үшін динамикалық түгендеу бар.
Ақпарат көзі: www.habr.com