Канвенцыя наймення
Агульныя пагадненні
Не павінна быць прычын не прытрымлівацца хаця б гэтых канвенцый :)
Звярніце ўвагу, што рэальныя воблачныя рэсурсы часта маюць абмежаванні на дазволеныя назвы. Некаторыя рэсурсы, напрыклад не могуць утрымліваць працяжнікі, а некаторыя павінны быць напісаны ў camel-case. Пагадненні ў гэтай кнізе адносяцца да саміх назваў Terraform.
Выкарыстоўвайце
_(падкрэсліванне) замест-(дэфіса) паўсюль (у назвах рэсурсаў, назвах крыніц даных, назвах пераменных, outputs і г.д.).Аддавайце перавагу малым літарам і лічбам (хоць UTF-8 і падтрымліваецца).
Аргументы рэсурсаў і крыніц дадзеных
Не паўтарайце тып рэсурсу ў назве рэсурсу (ні часткова, ні цалкам):
`resource "aws_route_table" "public" {}``resource "aws_route_table" "public_route_table" {}``resource "aws_route_table" "public_aws_route_table" {}`Назва рэсурсу павінна быць
thisкалі няма больш дакладнай і агульнай назвы, або калі модуль рэсурсаў стварае адзіны рэсурс гэтага тыпу (напрыклад, у AWS VPC модулі ёсць адзін рэсурс тыпуaws_nat_gatewayand і некалькі рэсурсаў тыпуaws_route_table, тамуaws_nat_gatewayпавінен называццаthisаaws_route_tableпавінны мець больш дакладныя назвы — напрыкладprivate,public,database).Заўсёды выкарыстоўвайце назоўнікі ў адзіночным ліку для назваў.
Выкарыстоўвайце
-у значэннях аргументаў і ў месцах, дзе значэнне будзе бачна чалавеку (напрыклад, у DNS імёнах альбо RDS экзэмпляры).Уключайце колькасць аргументаў
count/for_eachу блоку рэсурса або крыніцы даных у якасці першага аргумента ўверсе і аддзяляйце ад яго адзіным радком.Уключайце аргумент
tagsкалі яны падтрымліваюцца рэсурсам, у якасці апошняга рэальнага аргумента, пасляdepends_onіlifecycle, калі гэта неабходна. Усе яны павінны быць аддзеленыя адзіным пустым радком.Пры выкарыстанні ўмоў у аргуменце
count/for_eachаддавайце перавагу лагічным значэнням замест выкарыстанняlengthальбо іншых выразаў.
Прыклады кода resource
resourceВыкарыстанне count / for_each
count / for_eachРазмяшчэнне tags
tagsУмовы ў count
countПераменныя
Не вынаходзьце ровар у модулях рэсурсаў: выкарыстоўвайце
name,description, іdefaultдля зменных, як гэта вызначана ў раздзеле «Спасылка на аргументы» для рэсурса, з якім вы працуеце.адтрымка валідацыі для зменных даволі абмежаваная (напрыклад немагчыма атрымаць доступ да іншых пераменных або выконваць пошук, калі выкарыстоўваецца версія да Terraform
1.9). Плануйце адпаведна, бо ў многіх выпадках гэтая функцыя бескарысная.Выкарыстоўвайце форму множага ліку ў назве пераменнай калі тып —
list(...)абоmap(...).Размяшчайце ключы ў блоку зменных у такім парадку:
description,type,default,validation.Заўсёды дадавайце
descriptionда ўсіх пераменных, нават калі вам здаецца, што яно відавочнае (яно спатрэбіцца ў будучыні). Выкарыстоўвайце тую ж тэрміналогію, што і ў зыходнай дакументацыі, калі гэта магчыма.Аддавайце перавагу выкарыстанню простых тыпаў (
number,string,list(...),map(...),any) перад спецыфічнымі, такімі якobject()калі толькі вам не патрэбны строгія абмежаванні для кожнага ключа.Выкарыстоўвайце такія спецыфічныя тыпы, як
map(map(string))калі ўсе элементы мапы маюць аднолькавы тып (напрыкладstring) або могуць быць пераўтвораны ў яго (напрыкладnumberможна пераўтварыць уstring).Выкарыстоўвайце тып
anyкаб адключыць праверку тыпаў пачынаючы з пэўнай глыбіні або калі неабходна падтрымліваць некалькі тыпаў.Значэнне
{}часам з'яўляецца мапай, а часам — аб'ектам. Выкарыстоўвайцеtomap(...)каб стварыць мапу, бо няма спосабу стварыць аб'ект.Пазбягайце падвойных адмоў: выкарыстоўвайце станоўчыя назвы зменных, каб пазбегнуць блытаніны. Напрыклад, выкарыстоўвайце
encryption_enabledзаместencryption_disabled.Для пераменных, якія ніколі не павінны быць
null, усталюйцеnullable = false. Гэта гарантуе, што пры перадачыnullбудзе выкарыстоўвацца значэнне па змаўчанні заместnull. Каліnullз'яўляецца прымальным значэннем, вы можаце прапусціць nullable або ўсталяваць яго значэнне наtrue.
Outputs
Рабіце outputs паслядоўнымі і зразумелымі па-за межамі яго сферы прымянення (калі карыстальнік працуе з модулем, павінна быць відавочна, які тып і атрыбут мае вяртаемыя ім значэнне).
Назва output павінна апісваць уласцівасць, якую яна змяшчае, і быць менш свабоднай формы, чым звычайна хацелася б.
Добрая структура для назвы output выглядае так
{name}_{type}_{attribute}, дзе:{name}ёсць назвай рэсурсу або крыніцы дадзеных{name}дляdata "aws_subnet" "private"ёсцьprivate{name}дляresource "aws_vpc_endpoint_policy" "test"ёсцьtest
{type}з'яўляецца тыпам рэсурсу або крыніцы дадзеных без прэфікса пастаўшчыка{type}дляdata "aws_subnet" "private"ёсцьsubnet{type}дляresource "aws_vpc_endpoint_policy" "test"ёсцьvpc_endpoint_policy
{attribute}з'яўляецца атрыбутам, які вяртаецца output
Калі output вяртае значэнне з інтэрпаляцыйнымі функцыямі і некалькімі рэсурсамі,
{name}і{type}павінны быць максімальна агульнымі (прэфіксthisварта выключыць). Глядзі прыклад.Калі вернутае значэнне ёсць спісам, яго назва павінна быць у множным ліку. Глядзі прыклад.
Заўсёды дадавайце
descriptionдля ўсіх outputs нават калі вам здаецца, што яно відавочнае.Пазбягайце вызначаць
sensitiveаргумент, калі вы не кантралюеце цалкам выкарыстанне гэтага вываду ва ўсіх месцах ва ўсіх модулях.Аддавайце перавагу
try()(даступна з Terraform 0.13) перадelement(concat(...))(стары падыход для версій да 0.13)
Прыклады кода output
outputВяртайце максімум адзін ID групы бяспекі:
Калі ёсць некалькі рэсурсаў аднаго тыпу, this трэба выключыць з назвы output:
Выкарыстоўвайце імя ў множным ліку, калі вяртанае значэнне ёсць спісам
Last updated