Код құрылымы

Terraform кодының құрылымына қатысты сұрақтар - қауымдастықта ең жиі қойылатын сұрақтардың бірі. Әркім де бір кездері жоба үшін ең жақсы код құрылымы қандай болатыны туралы ойланған.

Terraform конфигурацияларын қалай құрылымдауым керек?

Бұл - көптеген шешімдері бар және әмбебап кеңес беру өте қиын сұрақтардың бірі, сондықтан біз немен жұмыс істеп жатқанымызды түсінуден бастайық.

• Жобаңыздың күрделілігі қандай?

  • Байланысты ресурстар саны

  • Terraform провайдерлерінің саны (төмендегі «логикалық провайдерлер» туралы ескертуді қараңыз)

• Инфрақұрылымыңыз қаншалықты жиі өзгереді?

  • Айына/аптасына/күніне бір реттен бастап

  • Үздіксізге дейін (жаңа коммит болған сайын)

• Код өзгерістерінің бастамашылары кімдер? Жаңа артефакт жиналған кезде CI серверіне репозиторийді жаңартуға рұқсат бересіз бе?

  • Инфрақұрылым репозиторийіне тек әзірлеушілер ғана push жасай алады (өзгеріс жібере алады)

  • Әркім PR ашу арқылы кез келген нәрсеге өзгеріс ұсына алады (соның ішінде CI серверінде жұмыс істейтін автоматтандырылған тапсырмалар да)

• Қандай орналастыру (deployment) платформасын немесе қызметін пайдаланасыз?

  • AWS CodeDeploy, Kubernetes немесе OpenShift сәл басқаша тәсілді қажет етеді

• Орталар қалай топтастырылған?

  • Орта, аймақ, жоба бойынша

Логикалық провайдерлер_ толығымен Terraform логикасының ішінде жұмыс істейді және көбінесе басқа қызметтермен мүлдем әрекеттеспейді, сондықтан біз олардың күрделілігін O(1) деп қарастыра аламыз. Ең жиі кездесетін логикалық провайдерлерге random, local, terraform, null, time жатады.

Terraform конфигурацияларын құрылымдауға кіріспе

Жұмысты бастағанда немесе мысал жазғанда, барлық кодты main.tf файлына орналастыру - жақсы идея. Басқа жағдайлардың барлығында файлдарды келесідей логикалық түрде бөлген дұрыс:

• main.tf - барлық ресурстарды құру үшін модульдерді, locals және дереккөздерді шақыру

• variables.tf - main.tf ішінде қолданылатын айнымалылардың сипаттамасын қамтиды

• outputs.tf - main.tf ішінде құрылған ресурстардың шығыстарын (outputs) қамтиды

• versions.tf - Terraform және провайдерлерге арналған нұсқа талаптарын қамтиды

terraform.tfvars файлын композициядан басқа еш жерде қолданбау керек.

Terraform конфигурациясының құрылымы туралы қалай ойлау керек?

Келесі мысалдарда қолданылатындықтан, негізгі ұғымдарды -ресурс модулі, инфрақұрылым модулі және композицияны түсінгеніңізге көз жеткізіңіз.

Кодты құрылымдау бойынша жалпы ұсыныстар

• Аз санды ресурстармен жұмыс істеу оңайырақ әрі жылдамырақ

  • terraform plan және terraform apply пәрмендері ресурстардың күйін тексеру үшін бұлттық API шақыруларын жасайды

  • Егер бүкіл инфрақұрылымыңыз бір композицияда болса, бұл біраз уақыт алуы мүмкін

• Ресурстар аз болғанда зақымдану аймағы (қауіпсіздік бұзылған жағдайда) кішірек болады

  • Тәуелсіз ресурстарды бөлек композицияларға орналастыру арқылы бір-бірінен оқшаулау, бірдеңе дұрыс болмай қалған жағдайда тәуекелді азайтады

• Жобаңызды қашықтағы күйді пайдалана отырып бастаңыз, себебі:

  • Сіздің ноутбугіңіз инфрақұрылымның ақиқат көзі болатын орын емес

  • tfstate файлын git-те басқару — нағыз қорқынышты түс

  • Кейінірек инфрақұрылым қабаттары бірнеше бағытта (тәуелділіктер немесе ресурстар саны) өсе бастағанда, бәрін бақылауда ұстау оңайырақ болады

• Бірізді құрылым мен атау келісімін ұстаныңыз:

  • Процедуралық код сияқты, Terraform коды да бірінші кезекте адамдар оқуы үшін жазылуы керек, ал бірізділік алты айдан кейін өзгерістер енгізілгенде көмектеседі

  • Terraform күй файлында (state file) ресурстарды жылжытуға болады, бірақ құрылым мен атаулар жүйесіз болса, мұны істеу қиынырақ болуы мүмкін

• Ресурс модульдерін мүмкіндігінше қарапайым етіп сақтаңыз

• Айнымалы ретінде беруге немесе дереккөздер арқылы табуға болатын мәндерді кодқа қатқыл жазбаңыз

• Дереккөздер мен terraform_remote_state -ті композиция ішіндегі инфрақұрылым модульдерінің арасындағы «желім» ретінде арнайы қолданыңыз

Бұл кітапта үлгі жобалар күрделілігіне қарай топтастырылған — кішіден бастап өте үлкен инфрақұрылымдарға дейін. Бұл бөлу қатаң емес, сондықтан басқа құрылымдарды да тексеріп көріңіз.

Инфрақұрылым модульдері мен композицияларды оркестрациялау

Шағын инфрақұрылымның болуы тәуелділіктердің және ресурстардың аз екенін білдіреді. Жоба өскен сайын Terraform конфигурацияларының орындалуын тізбектеу, әртүрлі инфрақұрылым модульдерін байланыстыру және композиция ішінде мәндерді тасымалдау қажеттілігі айқын болады.

Әзірлеушілер қолданатын оркестрация шешімдерінің кем дегенде 5 бөлек тобы бар:

1. Тек Terraform. Өте қарапайым, жұмысты орындау үшін әзірлеушілерге тек Terraform-ды білу жеткілікті.

2. Terragrunt. Бүкіл инфрақұрылымды оркестрациялауға, сондай-ақ тәуелділіктерді басқаруға болатын таза оркестрация құралы. Terragrunt инфрақұрылым модульдерімен және композициялармен тума түрде жұмыс істейді, сондықтан ол кодтың қайталануын азайтады.

3. Ішкі скрипттер. Бұл көбінесе оркестрацияға бастапқы қадам ретінде және Terragrunt-ты ашқанға дейін орын алады.

4. Ansible немесе соған ұқсас жалпы мақсаттағы автоматтандыру құралы. Әдетте Terraform Ansible-ден кейін қабылданғанда немесе Ansible UI белсенді қолданылғанда пайдаланылады.

5. Crossplane және басқа Kubernetes-пен шабыттандырылған шешімдер. Кейде Kubernetes экожүйесін пайдалану және Terraform конфигурацияларының қалаған күйіне жету үшін үйлестіру циклі мүмкіндігін қолдану мағыналы болады. Қосымша ақпарат алу үшін Crossplane vs Terraform бейнесін қараңыз.

Осыны ескере отырып, бұл кітап осы жоба құрылымдарының алғашқы екеуін — «Тек Terraform» және «Terragrunt»-ты қарастырады.

Келесі тарауда Terraform немесе Terragrunt үшін код құрылымдарының мысалдарын қараңыз.