Здавалася б, распрацоўшчыкі Terraform прапануюць дастаткова зручныя best practices для працы з AWS-інфраструктурай. Толькі ёсць нюанс. З часам колькасць акружэнняў павялічваецца, у кожным з'яўляюцца асаблівасці. З'яўляецца амаль копія стэка прыкладанняў у суседнім рэгіёне. І Terraform-код трэба акуратна скапіяваць і адрэдагаваць паводле новых патрабаванняў ці зрабіць сняжынку.
Мой даклад пра патэрны ў Terraform для барацьбы з хаосам і ручной руцінай на буйных і доўгіх праектах.
Відэа:
Мне 40, я 20 гадоў у IT. 12 гадоў працую ў кампаніі Ixtens. Мы займаемся ecommerce-driven-development. І 5 гадоў практыкую DevOps-практыкі.
Маё апавяданне будзе пра вопыт у праекце ў кампаніі, назву якой я не буду гаварыць, прыкрываючыся пагадненнем аб неразгалошванні.
Лічбы на слайдзе пазначаны для таго, каб разумець маштаб праекта. І ўсё, што я буду далей казаць, злучана з Amazon.
Я далучыўся да гэтага праекту 4 гады таму. І ў самым разгары праходзіў рэфакторынг інфраструктуры, бо праект вырас. І тыя патэрны, якія выкарыстоўваліся, яны ўжо не падыходзілі. І улічваючы ўвесь планаваны рост праекта, трэба было нешта прыдумаць новае.
Дзякуй Мацвею, які ўчора расказаў, што ў іх адбывалася ў Дадо Піца. Гэта тое, што адбывалася ў нас 4 гады таму.
Дашлі распрацоўшчыкі і сталі рабіць інфраструктурны код.
Самыя відавочныя моманты, чаму гэта патрабавалася, трэба было time to market. Трэба было зрабіць так, каб DevOps-каманда не была вузкім месцам пры выкатцы. І акрамя ўсяго іншага на самым першым узроўні выкарыстоўваліся Terraform і Puppet.
Terraform - гэта open source праект кампаніі HashiCorp. І для тых, хто ўвогуле не ў курсе, што гэта, наступныя некалькі слайдаў.
Інфраструктура як код - гэта значыць, што мы можам апісаць нашу інфраструктуру і папрасіць нейкіх робатаў зрабіць так, каб мы атрымалі тыя рэсурсы, якія мы апісалі.
Напрыклад, нам патрэбная віртуальная машына. Мы апішам, дадамо некалькі абавязковых параметраў.
Пасля гэтага ў кансолі наладзім доступ да Amazon. І папросім Terraform plan. Terraform plan скажа: "Ок, для вашага рэсурсу мы можам зрабіць вось такія штукі". І, як мінімум, адзін рэсурс будзе дададзены. І ніякіх змен не прадбачыцца.
Пасля таго, як вас усё задаволіла, вы можаце папрасіць Terraform apply і Terraform створыць вам instance, і вы атрымаеце віртуальную машыну ў вашым воблаку.
Далей наш праект разьвіваецца. Мы дадаем туды нейкія змены. Мы просім больш instances, мы дадаем 53 запіс.
І паўтараем. Просім plan. Бачым, якія змены плануюцца. Ужывальны. І такім чынам нашая інфраструктура расце.
Terraform выкарыстоўвае такую штуку як state-файлы. Т. е. усе змены, якія сыходзяць на Amazon, ён захоўвае ў файліцы, дзе для кожнага рэсурсу, які вы апісалі, ёсць адпаведныя рэсурсы, якія былі створаны ў Amazon. Такім чынам пры змене апісання нейкага рэсурсу, Terraform сапраўды ведае, што менавіта трэба памяняць у Amazon.
Гэтыя state-файлы першапачаткова былі проста файламі. І мы іх захоўвалі ў Git, што было вельмі няёмка. Увесь час хтосьці забываў пракамміціць змены, і ўзнікала шмат канфліктаў.
Цяпер ёсць магчымасць выкарыстоўваць бэкэнд, т. е. Terraform паказваецца ў які bucket, па якім ключы трэба захаваць state-файл. І Terraform сам паклапоціцца аб тым, каб дастаць гэты state-файл, зрабіць усю магію і пакласці зваротна фінальны вынік.
Наша інфраструктура расце. Вось наш код. І мы зараз не жадаем проста ствараць віртуальную машыну, мы жадаем мець тэставае асяроддзе.
Terraform дазваляе зрабіць такую штуку як модуль, т. е. таксама самае апісаць у нейкай тэчцы.
І, напрыклад, у тэстынгу выклікаць гэты модуль і атрымаць тое самае як быццам мы выконвалі Terraform apply у самім модулі. Для тэсцінгу будзе вось такі код.
Для production мы можам паслаць туды нейкія змены, таму што ў тэсцінгу нам не патрэбны вялікія instances, у production вялікія instances як раз спатрэбяцца.
І далей я вярнуся назад у праект. Была складаная задача, інфраструктура планавалася вельмі вялікай. І трэба было неяк размясціць увесь код, каб гэта было зручна для ўсіх: і для тых, хто робіць maintenance над гэтым кодам, і для тых, хто ўносіць змены. А планавалася, што любы распрацоўшчык можа пайсці і паправіць інфраструктуру так, як трэба для яго часткі платформы.
Гэта дрэва каталогаў, якое рэкамендуецца самім HashiCorp, калі ў вас вялікі праект і ёсць сэнс падзяліць усю інфраструктуру на нейкія маленькія кавалачку, і кожныя кавалачкі апісваць у асобнай тэчцы.
Маючы шырокую бібліятэку рэсурсаў можна ў тэсцінгу і ў production выклікаць прыкладна адно і тое ж.
У нашым выпадку гэта не зусім падыходзіла, таму што тэставы стэк для распрацоўшчыкаў або для тэставання трэба было атрымліваць неяк прасцей. А хадзіць па татачках і ўжываць у патрэбнай паслядоўнасці, і турбавацца аб тым, што база паднімецца, а потым паднімецца instance, які выкарыстоўвае гэтую базу, не жадалася. Таму ўвесь тэстынг запускаўся з адной тэчкі. Тамака выклікаліся тыя ж самыя модулі, але праходзіла ўсё за адзін прагон.
Terraform турбуецца аб усіх залежнасцях. І заўсёды стварае рэсурсы ў той паслядоўнасці, каб можна было атрымаць IP-адрас, напрыклад, ад свежастворанага instance, і атрымаць гэты IP-адрас у route53 запіс.
Акрамя гэтага, платформа вельмі вялікая. І запуск тэставага стэка, нават калі на гадзіну, нават калі на 8 гадзін - гэта дастаткова дарагая справа.
І мы аўтаматызавалі гэтую справу. І Jenkins job дазваляў запускаць стэк. У ім трэба было запускаць pull request са зменамі, якія жадае распрацоўнік пратэставаць, паказаць усе патрэбныя опцыі, кампаненты, а таксама памеры. Калі ён хоча performance тэсціраванне, то ён можа пабольш instances ўзяць. Калі яму трэба проста праверыць, што нейкая формачка адчыняецца, то мог стартануць на мінімалках. А таксама паказаць патрэбен кластар ці не патрэбен і т. д.
І потым Jenkins штурхаў shell-скрыпт, які крышку мадыфікаваў код у тэчцы Terraform. Прыбіраў непатрэбныя файлы, дадаваў патрэбныя файлы. І потым адным прагонам Terraform apply стэк паднімаўся.
А далей ужо ішлі іншыя крокі, у якія я не хачу паглыбляцца.
З-за таго, што для тэстынгу нам патрабавалася крыху больш опцый, чым у production, нам даводзілася рабіць копіі модуляў, каб у гэтых копіях можна было дадаць тыя фічы, якія патрэбныя толькі ў тэстынгу.
І так атрымалася, што ў тэсцінгу быццам хочацца пратэставаць тыя змены, якія ў выніку пойдуць на production. Але насамрэч тэставалася адно, а ў production ужывалася крышку іншае. І быў невялікі парыў шаблону, што ў production усе змены ўжываліся operation камандай. І часам атрымлівалася так, што тыя змены, якія мусілі з тэстынгу перайсці ў production, яны заставаліся ў іншай версіі.
Акрамя гэтага была такая праблема, што дадаваўся новы сэрвіс, які крыху адрозніваўся ад нейкага ўжо існуючага. І замест таго, каб мадыфікаваць існуючы модуль, даводзілася рабіць яго копію і дадаваць неабходныя змены.
Па сутнасці, Terraform - гэта не сапраўдная мова. Гэта дэкларацыя. Калі нам трэба нешта задэклараваць, то мы гэта дэкларуем. І ўсё гэта працуе.
У нейкі момант, калі абмяркоўваўся адзін з маіх pull request, адзін з калегаў сказаў, што не трэба пладзіць сняжынкі. Я зацікавіўся, што ён мае на ўвазе. Ёсць такі навуковы факт, што ў свеце не існуе дзвюх аднолькавых сняжынак, усе яны крыху, ды адрозніваюцца. І як толькі я гэта пачуў, я адразу адчуў увесь цяжар Terraform-кода. Таму што калі патрабавалася перайсці з версіі на версію, то Terraform патрабаваў breaking chain змены, т. е. код больш не быў сумяшчальны з наступнай версіяй. І прыходзілася рабіць pull request, які пакрываў амаль палову файлаў у інфраструктуры, каб прывесці інфраструктуру да наступнай версіі Terraform.
І пасля таго, як з'явілася такая сняжынка, увесь Terraform-код, які ў нас меўся, ператвараўся ў вялікую-вялікую кучу снега.
Для вонкавага распрацоўніка, які па-за operation, для яго гэта не мае вялікага значэння, таму што ён зрабіў pull request, яго рэсурс запусціўся. І ўсё, далей не яго клопат. А камандзе DevOps, якія сочаць за тым, каб усё было Ок, патрабуецца робіцца рабіць усе гэтыя змены. І кошт гэтых змен вельмі-вельмі моцна ўзрастала з кожнай дадатковай сняжынкай.
Ёсць такая гісторыя пра тое, як студэнт на семінары малюе мелам на дошцы два ідэальныя кругі. І выкладчык дзівіцца, як яму ўдалося так роўна без цыркуля намаляваць. Студэнт адказвае: «Вельмі проста, я два гады ў войску круціў мясарубку».
І з тых чатырох гадоў, у якіх я ўдзельнічаю ў гэтым праекце, недзе каля двух гадоў я займаюся Terraform. І, вядома, у мяне ёсць нейкія фішкі, нейкія парады, як можна спрасціць Terraform-код, працаваць з ім, як з мовай праграмавання і паменшыць нагрузку на распрацоўшчыкаў, якія павінны падтрымліваць гэты код у актуальным стане.
Першае, з чаго я хацеў бы пачаць, гэта Symlinks. Terraform мае шмат паўтаральнага кода. Напрыклад, выклік правайдэра практычна ў кожным пункце, дзе мы ствараем кавалачак інфраструктуры, адзін і той жа. І лагічна вынесці яго ў асобную татачку. І ўсюды, дзе патрабуецца правайдэр рабіць Symlinks на гэты файлік.
Напрыклад, у вас у production выкарыстоўваецца assume role, які дазваляе вам атрымаць правы доступу на нейкі вонкавы Amazon-акаунт. І памяняўшы адзін файлік, усе пакінутыя, якія ў дрэве рэсурсаў, будуць мець патрабаваныя правы, каб Terraform ведаў да якога Amazon-сегменту звяртацца.
Дзе Symlinks не працуюць? Як і казаў, у Terraform ёсць state-файлы. І яны вельмі-вельмі класныя. Але справа ў тым, што Terraform ініцыялізуе бэкэнд у самым першым. І ён не можа выкарыстоўваць у гэтых параметрах якія-небудзь зменныя, іх заўсёды трэба пісаць тэкстам.
І як вынік, калі нехта робіць новы рэсурс, ён капіюе частку кода з іншых папачак. І ён можа памыліцца з ключом ці з bucket. Напрыклад, ён з sandbox робіць sandbox-штуку, а потым робіць у production. І так можа аказацца, што bucket у production будзе выкарыстоўвацца з sandbox. Канешне, гэта хутка знойдуць. Можна будзе гэта неяк выправіць, але тым не менш гэта страта часу і ў нейкай ступені рэсурсаў.
Што мы можам зрабіць далей? Перад тым, як працаваць з Terraform трэба яго праініцыялізаваць. У момант ініцыялізацыі Terraform выпампоўвае ўсе плагіны. Яны ў нейкі момант з маналіта разбіліся на больш мікрасэрвісную архітэктуру. І заўсёды трэба рабіць Terraform init, каб ён падцягнуў усе модулі, усе плагіны.
І можна выкарыстоўваць shell-скрыпт, які, па-першае, зможа дастаць усе зменныя. Shell-скрыпт нічым не абмежаваны. А, па-другое, шляхі. Калі мы заўсёды выкарыстоўваем той шлях, які ў рэпазітары як ключ да state-файла, то, адпаведна, памылка тут будзе выключана.
Адкуль дастаць дадзеныя? JSON-файл. Terraform дазваляе запісваць інфраструктуру не толькі ў hcl (HashiCorp Configuration Language), але і ў JSON.
JSON лёгка чытаецца з shell-скрыпту. Адпаведна, можна ў нейкае месца пакласці канфігурацыйны файл з bucket. І выкарыстоўваць гэты bucket і ў Terraform-кодзе, і ў shell-скрыпце для ініцыялізацыі.
Чаму важна мець bucket для Terraform? Бо ёсць такая штука як remote state-файлы. Т. е. калі я паднімаю нейкі рэсурс, мне для таго, каб сказаць Amazon: "Паднімі, калі ласка, instance", трэба паказаць вельмі шмат абавязковых параметраў.
І гэтыя ідэнтыфікатары захоўваюцца ў нейкай іншай татачцы. І я магу ўзяць і сказаць: "Terraform, збягай, калі ласка, у state-файл таго самага рэсурсу і дастань мне гэтыя ідэнтыфікатары". І такім чынам з'яўляецца нейкая ўніфікацыя паміж рознымі рэгіёнамі ці environments.
Не заўсёды можна выкарыстоўваць выдалены state-файл. Напрыклад, вы рукамі стварылі VPC. І той Terraform-код, які стварае VPC, стварае настолькі непадобны VPC, што вельмі доўга і трэба вам давядзецца падладжваць адно пад другое, таму можна выкарыстоўваць наступную фішку.
Т. е. зрабіць модуль, які як бы робіць VPC і як бы выдае вам ідэнтыфікатары, а насамрэч проста ёсць файлік з захардкоженными значэннямі, які можна выкарыстоўваць для стварэння таго ж instance.
Не заўсёды патрабуецца захоўваць state-файл у воблаку. Напрыклад, калі тэстуюцца модулі, можна выкарыстоўваць ініцыялізацыю бэкэнда, калі файл будзе захоўвацца проста на дыску на момант тэсціравання.
Цяпер трошкі пра тэставанне. Што ў Terraform можна тэставаць? Напэўна, шмат што можна, але я буду казаць пра вось гэтыя 4 штучкі.
У HashiCorp ёсць разуменне, як трэба фарматаваць Terraform-код. І Terraform fmt дазваляе вам адфарматаваць код, які вы рэдагуеце ў адпаведнасць з гэтай верай. Адпаведна, тэсты павінны абавязкова праверыць, а ці адпавядае фарматаванне таму, што завяшчаў HashiCorp, каб не даводзілася змяняць размяшчэнне клямарчыкаў і т. д.
Наступны - гэта Terraform validate. Ён робіць трошкі больш, чым праверку сінтаксісу - аля, ці ўсё дужкі парныя. Што тут важна? У нас інфраструктура вельмі раскідзістая. У ёй вельмі шмат розных тэчак. І ў кожнай трэба запусціць Terraform validate.
Адпаведна, каб паскорыць тэсціраванне, мы запускаем некалькі працэсаў паралельна, выкарыстоўваючы паралель.
Паралель - гэта вельмі класная штука, карыстайцеся.
Але кожны раз, калі адбываецца ініцыялізацыя Terraform, ён ідзе на HashiCorp і пытаецца: «Якія апошнія версіі плагінаў? А тая ўбудова, якая ў мяне кэшы – яна тая ці не тая?». І гэта на кожным кроку давала сваё запаволенне.
Калі Terraform падказаць, дзе ляжаць убудовы, то Terraform скажа: Ок, мусіць, гэта самае свежае, што ёсць. Я не буду нікуды хадзіць, я адразу пачну валідаваць ваш Terraform-код».
Для таго каб напоўніць татачку патрэбнымі убудовамі, у нас ёсць вельмі просты Terraform-код, які трэба проста праініцыялізаваць. Тут, вядома, трэба паказаць усіх правайдэраў, якія як-небудзь удзельнічаюць у вашым кодзе, інакш Terraform скажа: "Я не ведаю нейкага правайдэра, таму што яго няма ў кэшы".
Наступнае гэта Terraform plan. Як і казаў, распрацоўка - цыклічная. Мы робім код са зменамі. І потым трэба даведацца, якія змены плануюцца на інфраструктуру.
І калі інфраструктура вельмі-вельмі вялікая, можна памяняць адзін модуль, паправіць нейкае тэставае асяроддзе ці які-небудзь пэўны рэгіён і зламаць які-небудзь суседні. Таму Terraform plan павінен рабіцца на ўсю інфраструктуру і паказваць, якія змены плануюцца.
Рабіць гэта можна па разумным. Мы, напрыклад, напісалі скрыпт на Python, які разразоўвае залежнасці. І ў залежнасці ад таго, што было зменена: Terraform-модуль ці проста нейкі пэўны кампанент, ён робіць планы на ўсе залежныя тэчкі.
Terraform plan павінны рабіць па запыце. Прынамсі, гэта тое, што робім мы.
Тэсты, вядома, добра рабіць на кожную змену, на кожны коміт, але планы - гэта досыць дарагая штука. І мы ў pull request кажам: "Калі ласка, дай мне планы". Запускаецца робат. І дасылае ў каментары ці ў attach усе планы, якія мяркуюцца ад вашых змен.
План - рэч дастаткова дарагая. Яна займае час, таму што Terraform ідзе ў Amazon і пытаецца: А гэты instance яшчэ існуе? А ў гэтага autoscale сапраўды такія параметры?». І для таго, каб гэта паскорыць, можна выкарыстоўваць такі параметр, як refresh=false. Гэта значыць, што Terraform выпампуе з S3 state. І будзе верыць, што state будзе сапраўды адпавядаць таму, што знаходзіцца ў Amazon.
Такі Terraform plan праходзіць значна хутчэй, але state павінен адпавядаць вашай інфраструктуры, т. е. дзесьці, калісьці павінен запусціцца Terraform refresh. Terraform refresh робіць менавіта тое, каб state адпавядаў таму, што знаходзіцца ў рэальнай інфраструктуры.
І трэба сказаць аб бяспецы. З гэтага і трэба было пачынаць. Там, дзе вы запускаеце Terraform, і Terraform працуе з вашай інфраструктурай, ёсць уразлівасць. Т. е. вы, па сутнасці, выконваеце код. І калі pull request змяшчае нейкі шкоднасны код, то ён можа выканацца на інфраструктуры, якая мае занадта шмат доступу. Таму будзьце ўважлівыя, дзе вы запускаеце Terraform plan.
Наступнае, пра што я хацеў бы расказаць, гэта тэсціраванне user-data.
Што такое user-data? У Amazon, калі мы ствараем instance, мы можам з instance адправіць нейкі ліст - мета-дадзеныя. Калі instance запускаецца, звычайна cloud init заўседы прысутнічае на гэтых instances. Cloud init счытвае гэты ліст і кажа: "Ок, сёння я - load balancer". І ў адпаведнасць з гэтымі запаветамі робіць нейкія дзеянні.
Але, нажаль, калі мы робім Terraform plan і Terraform apply, user-data выглядае, як вось такая кашыца з лічбаў. Т. е. ён проста дасылае вам хэш. І ўсё, што вы можаце паглядзець у плане, гэта будуць нейкія змены ці хэш застанецца тым жа самым.
І калі на гэта не зважаць, то на Amazon, на рэальную інфраструктуру можа сысці нейкі пабіты тэкставы файлік.
Як варыянт, можна пры выкананні ўказаць не ўсю інфраструктуру, а толькі template. І ў кодзе сказаць: "Калі ласка, вывядзі мне на экран гэты template". І ў выніку можна атрымаць раздрукоўку, як будзе выглядаць вашыя дадзеныя на Amazon.
Іншы варыянт - гэта выкарыстоўваць модуль для генерацыі user-data. Вы прымяніце гэты модуль. Атрымліваеце файл на дыску. Параўноўваеце яго з рэферэнсным. І такім чынам, калі нейкі джун вырашыць паправіць крышку user-data, то вашыя тэсты скажуць: "Ок, вось тут і тут нейкія змены - гэта нармальна".
Наступнае, пра што я хацеў бы расказаць, гэта Automate Terraform apply.
Вядома, дастаткова страшна рабіць Terraform apply у аўтаматычным рэжыме, таму што, хто ведае, якія тамака прыйшлі змены і наколькі яны могуць быць згубныя для жывой інфраструктуры.
Для тэставага асяроддзя - гэта ўсё нармальна. Т. е. job, які стварае тэставае асяроддзе, гэта тое, што трэба ўсім распрацоўнікам. І такі выраз, як "у мяне ўсё працавала" - гэта не смешны мем, а доказ таго, што чалавек затлуміўся, падняў стэк, запусціў на гэты стэк нейкія тэсты. І пераканаўся, што там усё нармальна і сказаў: "Ок, той код, які я выпускаю, быў пратэставаны".
У production, sandbox і іншых акружэннях, якія больш важныя для бізнесу, можна прымяняць часткова некаторыя рэсурсы дастаткова бяспечна, таму што гэта не прыводзіць да таго, што нехта памірае. Гэта: autoscale-групы, security-групы, roles, route53 і там спіс можа быць дастаткова вялікі. Але сачыце за тым, што адбываецца, чытайце справаздачы аб аўтаматычных ужываннях.
Там, дзе прымяняць небяспечна ці боязна, напрыклад, калі гэта нейкія рэсурсы з persistent, з базы дадзеных, то атрымлівайце справаздачы аб тым, што ў нейкім кавалачку інфраструктуры ёсць не прымененыя змены. І інжынер ужо пад наглядам запускае jobs, каб прымяніць ці робіць гэта са сваёй кансолі.
У Amazon ёсць такая штука як Terminate protection. І яна можа абараніць у некаторых выпадках ад непатрабавальных для вас змен. Т. е. Terraform пайшоў на Amazon і кажа: "Мне трэба забіць гэты instance, каб зрабіць іншы". А Amazon кажа: Sorry, не сёння. У нас стаіць Terminate protection».
І вішанька на торце - гэта аптымізацыя кода. Калі мы працуем з Terraform-кодам, мы павінны перадаць у модуль вельмі вялікая колькасць параметраў. Гэта тыя параметры, якія неабходны для таго, каб стварыць нейкі рэсурс. І код ператвараецца ў вялікія спісы параметраў, якія трэба перадаць з модуля ў модуль, з модуля ў модуль, асабліва, калі модулі укладзеныя.
І гэта вельмі складана чытаема. На гэта складана рабіць review. І вельмі часта атрымоўваецца так, што нейкія параметры праходзяць review і яны не зусім тыя, якія патрэбныя. А гэта каштуе часу і грошай, каб потым выправіць.
Таму я вам прапаную выкарыстоўваць такую штуку як складаны параметр, які складаецца з нейкае дрэва значэнняў. Т. е. патрэбна нейкая тэчка, дзе ў вас указаны ўсе значэння, якія вы хацелі б мець на нейкім environment.
І выклікаючы гэты модуль, можна атрымаць дрэва, якое генеруецца ў адным агульным модулі, т. е. у агульным модулі, які аднолькава працуе для ўсёй інфраструктуры.
У гэтым модулі можна зрабіць некаторыя вылічэнні, выкарыстоўваючы такую свежую фічу ў Terraform, як locals. І потым адным output'ам выдаць нейкі складаны параметр, які можа складацца з хэшы масівы і т. д.
На гэтым усе найлепшыя знаходкі, якія ў мяне ёсць скончыліся. І хацеў бы расказаць байку пра Калумба. Калі ён шукаў грошы на сваю экспедыцыю, каб адкрыць Індыю (як тады ён думаў), яму ніхто не верыў і лічылі, што гэта немагчыма. Тады ён сказаў: "Зрабіце так, каб яйка не ўпала". Усе банкіры, вельмі багатыя і, мусіць, разумныя людзі, спрабавалі нейкім чынам паставіць яйка, і яно ўвесь час падала. Тады Калумб узяў яйка, трошкі на яго націснуў. Шкарлупіна змялася, і яйка засталося нерухомым. Яны сказалі: "О, гэта занадта проста!". І Калумб адказаў: «Так, гэта занадта проста. І калі я адкрыю Індыю, усе будуць выкарыстоўваць гэты гандлёвы шлях».
І тое, што зараз я вам распавёў, гэта, напэўна, дастаткова простыя і трывіяльныя рэчы. І калі ты пра іх даведаешся і пачынаеш выкарыстоўваць, гэта ў парадку рэчаў. Так што карыстайцеся. І калі для вас гэта цалкам сабе нармальныя рэчы, то, прынамсі, вы ведаеце, як паставіць яйка, каб яно не ўпала.
Падвядзем вынікі:
- Паспрабуйце пазбягаць сняжынак. І чым менш сняжынак, тым менш рэсурсаў вам спатрэбіцца, каб рабіць нейкія змены на ўсёй вашай вялікай інфраструктуры.
- Пастаянныя змены. Т. е. калі ў кодзе адбыліся нейкія змены, трэба як мага хутчэй прывесці вашу інфраструктуру ў адпаведнасць з гэтымі зменамі. Не павінна быць сітуацыі, калі нехта праз два-тры месяцы прыходзіць, каб паглядзець Elasticsearch, робіць Terraform plan, а там куча змен, якіх ён не чакаў. І марнуецца вельмі шмат часу для таго, каб прывесці назад усё ў парадак.
- Тэсты і аўтаматызацыя. Чым больш у вас код пакрыты тэстамі і фішкамі, тым тым больш у вас упэўненасць у тым, што вы ўсё робіце правільна. А аўтаматычная дастаўка павялічыць вашу ўпэўненасць шматкроць.
- Код для тэставага і production-акружэнні павінен быць практычна аднолькавым. Практычна, таму што ўсё ж такі production крышку іншы і там усё роўна будуць нейкія нюансы, якія будуць выходзіць за рамкі тэставага асяроддзя. Але, тым не менш, плюс-мінус можна гэта забяспечыць.
- І калі ў вас вельмі шмат Terraform-кода і на падтрымку гэтага кода ў актуальным стане патрабуецца вельмі шмат часу, то ніколі не позна зрабіць refactoring і прывесці яго ў добрую форму.
- Immutable infrastructure. Дастаўка AMI па раскладзе.
- Структура для route53, калі ў вас запісаў вельмі шмат і вам хочацца, каб яны былі ва ўзгодненым парадку.
- Барацьба з API rate limits. Гэта калі Amazon кажа: "Усё-ўсё, больш я не магу прымаць запытаў, калі ласка, пачакайце". І палова канторы чакае, пакуль яна зможа запусціць сваю інфраструктуру.
- Spot instances. Amazon – нятаннае мерапрыемствы і spots дазваляюць дастаткова шмат эканоміць. І там можна расказаць цэлы даклад пра гэта.
- Бяспека і IAM roles.
- Пошук страчаных рэсурсаў, калі ў вас у Amazone ёсць instances незразумелага паходжання, яны ядуць грошы. Нават калі instances каштуе 100-150 даляраў у месяц - за год гэта 1 000 з лішнім. Пошук такіх рэсурсаў - гэта прыбытковая справа.
- І зарэзерваваныя instances.
На гэтым у мяне ўсё. Terraform - гэта вельмі крута, карыстаецеся. Дзякуй!
пытанні
Дзякуй за даклад! У вас state-файл ляжыць у S3, а як вы вырашаеце праблему, што некалькі чалавек могуць узяць гэты state-файл і паспрабаваць разгарнуцца?
Па-першае, мы не спяшаемся. Па-другое, ёсць flags, у якім мы паведамляем аб тым, што мы працуем над нейкім участкам кода. Т. е. нягледзячы на тое, што інфраструктура вельмі вялікая, гэта не значыць, што ўвесь час хтосьці нешта прымяняе. І калі была актыўная фаза - гэта было праблемай, у нас state-файлы ў Git захоўваліся. Гэта было важна, інакш нехта зробіць state-файл, і нам даводзілася ўручную іх збіраць у кучу, каб усё далей працягвалася. Цяпер такой праблемы няма. А ўвогуле, Terraform вырашыў гэтую задачу. І калі ўвесь час нешта змяняецца, то можна выкарыстоўваць locks, якія прадухіляюць тое, што вы сказалі.
Вы карыстаецеся адкрытую версію або enterprise?
Ніякага enterprise, г. зн. усё, што можна пайсці і спампаваць бясплатна.
Мяне клічуць Станіслаў. Я хацеў зрабіць маленькі дадатак. Вы распавялі пра фічу Amazon, якая дазваляе зрабіць instance незбіваным. Гэта ёсць і ў самім Terraform, у блоку Life Second можна прапісаць забарону на змену, альбо забарону на знішчэнне.
У часе быў абмежаваны. Добрая заўвага.
Яшчэ хацеў спытаць дзве рэчы. Па-першае, вы расказалі пра тэсціраванне. Ці карысталіся вы нейкімі інструментамі для тэсціравання? Я чуў пра плягін Test Kitchen. Магчыма, ёсць нешта яшчэ. І хацеў бы яшчэ спытаць пра Local Values. Чым яны ў прынцыпе адрозніваюцца ад Input Variables? І чаму я не магу параметрызаваць нешта толькі праз Local Values? Я спрабаваў разабрацца з гэтай тэмай, але неяк не разабраўся сам.
Мы можам падрабязней пагаварыць за гэтай залай. Інструменты для тэставання - гэта ў нас поўны самапал. Там нічога такога няма, каб пратэставаць. А наогул, ёсць варыянты, калі аўтаматычныя тэсты паднімаюць інфраструктуру дзесьці, правяраюць, што яна Ок, а потым усё знішчаюць са справаздачай, што ваша інфраструктура ўсё яшчэ ў добрай форме. У нас гэтага няма, таму што тэставыя стэкі запускаюцца кожны дзень. І гэтага дастаткова. І калі нешта пачало ламацца, то яно пачне ламацца без таго, што мы яшчэ недзе гэта праверым.
З нагоды Local Values давайце працягнем размову за залай.
Прывітанне! Дзякуй за даклад! Вельмі пазнавальна. Ты казаў, што ў вас вельмі шмат аднатыпнага кода для апісання інфраструктуры. Ці не разглядалі вы варыянт генерацыі гэтага кода?
Выдатнае пытанне, дзякуй! Справа ў тым, што, калі мы выкарыстоўваем інфраструктуру як код, мы мяркуем, што мы глядзім на код і разумеем, якая інфраструктура за гэтым кодам ляжыць. Калі код генеруецца, то нам трэба ўявіць, які код згенеруецца, каб зразумець, якая інфраструктура там будзе. Або мы генеруемы код, каміцім яго і, у сутнасці, атрымліваецца тое ж самае. Таму мы пайшлі па тым шляху, як мы напісалі, мы гэта атрымалі. Плюс генератары з'яўляліся крыху пазней, калі мы пачалі рабіць. І ўжо позна было мяняць.
Пра jsonnet чуў што-небудзь?
Няма.
Паглядзі, гэта вельмi класная штука. Я бачу канкрэтны кейс, дзе можна прымяніць яго і генераваць структуру дадзеных.
Генератары - гэта добра, калі ў вас, як у анекдоце пра машыну для галення. Г. зн. першы раз твар розны, але потым ва ўсіх твар аднолькавы. Генератары вельмі класна заходзяць. Але ў нас, на жаль, асобы крыху розныя. Гэта праблема.
Проста паглядзі. Дзякуй!
Мяне клічуць Максім, я з Ашчадбанка. Вы крыху распавялі, што спрабавалі прывесці Terraform да аналогу мовы праграмавання. Ці не прасцей карыстацца Ansible?
Гэта вельмі розныя рэчы. Можна і Ansible ствараць рэсурсы, і Puppet можна ствараць рэсурсы ў Amazon. Але Terraform прама заменчаны.
У вас толькі Amazon?
Справа не ў тым, што ў нас толькі Amazon. У нас амаль толькі Amazon. Але ключавая фіча ў тым, што Terraform памятае. У Ansible, калі сказаць: "Паднімі мне 5 instances", то ён падніме, а потым ты кажаш: "А зараз мне трэба 3". І Terraform скажа: "Ок, 2 заб'ю", а Ansible скажа: "Ок, вось табе 3". Разам 8.
Добры дзень! Дзякуй за ваш даклад! Вельмі цікава было паслухаць пра Terraform. Адразу жадаю даць маленькі каментар з нагоды таго, што Terraform усёткі не мае стабільнага рэлізу, таму з вялікай асцярогай стаўцеся да Terraform.
Добрая лыжка да абеду. Т. е. калі вам трэба рашэнне, тыя вы часам адкладаеце тое, што нестабільна і т. д., але яно працуе і нам дапамагло.
Пытанне такое. Вы карыстаецеся Remote backend, вы карыстаецеся S 3. Чаму афіцыйны бэкенд не карыстаецеся?
Афіцыйны?
Terraform Cloud.
Калі ён з'явіўся?
Месяца 4 таму.
Калі б ён з'явіўся 4 гады таму, то, напэўна, я б адказаў на ваша пытанне.
Тамака ёсць ужо ўбудаваная функцыя і locks, і можна захоўваць state -файл. Паспрабуйце. Але я таксама не тэсціраваў.
Мы едзем у вялікім цягніку, які рухаецца з вялікай хуткасцю. І нельга проста ўзяць і выкінуць некалькі вагонаў.
Вы казалі пра сняжынкі, а чаму вы не выкарыстоўвалі branch? Чаму не ўдалося так зрабіць?
У нас такі падыход, што ўся інфраструктура ў адным рэпазітары. Terraform, Puppet, усе скрыпты, якія хоць неяк да гэтага ставяцца, яны ўсё ў адным рэпазітары. Такім чынам, можам гарантаваць, што інкрыментальныя змены пратэставаны адна за адной. Калі б гэта было куча branches, то такі праект практычна немагчыма абслугоўваць. Праходзяць паўгода, і яны настолькі разыходзяцца, што гэта проста пакаранне нейкае. Гэта тое, ад чаго захацелася ўцячы да рэфактарынгу.
Т. е. гэта не працуе?
Гэта ўвогуле не працуе.
У палачы я выразаў слайд тэчкі. Т. е. калі зрабіць на кожны тэставы стэк, напрыклад, у каманды А– у яе свая татачка, у каманды Бы свая татачка, то гэта таксама не працуе. Мы зрабілі уніфікаваны код тэставага асяроддзя, які быў дастаткова гнуткі, каб падыходзіць усім. Т. е. мы адзін код абслугоўвалі.
Прывітанне! Мяне клічуць Юрась! Дзякуй за даклад! Пытанне аб модулях. Вы кажаце, што вы карыстаецеся модулі. Як вырашаеце пытанне, калі ў адным модулі занеслі змены, якія не сумяшчальныя са зменай іншага чалавека? Неяк версіянуеце модулі ці спрабуеце прывесці вундэрвафлю, каб адпавядаць двум патрабаванням?
Гэта праблема вялікай снежнай кучы. Гэта тое, чаму мы пакутуем, калі нейкая бяскрыўдная змена можа зламаць нейкую частку інфраструктуры. І гэта будзе заўважна толькі праз нейкі працяглы час.
Т. е. пакуль ніяк не вырашаецца?
Робіце ўніверсальныя модулі. Пазбягайце сняжынак. І ўсё атрымаецца. Другая палова даклада пра тое, як гэта пазьбегнуць.
Добры дзень! Дзякуй за даклад! Жадаў бы ўдакладніць. За кадрам засталася вялікая куча, дзеля якой я прыйшоў. Якім чынам інтэграваныя Puppet і раздача роляў?
User-data.
Т. е. проста выплёўваеце файлік і па ім як-то выконваеце?
User-data - гэта цыдулка, т. е. калі мы робім клон выявы, то тамака паднімаецца Daemon і спрабуючы разабрацца, хто ён, чытае цыдулку, што ён load balancer.
Г. зн. гэта нейкі асобны працэс, які аддаецца?
Не мы яго вынайшлі. Мы ім карыстаемся.
Добры дзень! У мяне якраз пытанне пра User – data. Вы сказалі, што там ёсць праблемы, што нехта можа нешта не туды перадаць. Ёсць нейкі спосаб захоўвання user - data у тым жа самым Git, каб заўсёды было зразумела, на што спасылаецца User-data?
Мы User-data генеруем з template. Т. е. туды звяртаецца нейкая колькасць зменных. І Terraform генеруе фінальны вынік. Таму нельга проста так паглядзець на template і сказаць, што атрымаецца, таму што ўсе праблемы злучаны з тым, што распрацоўнік думае, што ён у гэтай зменнай перадае радок, а тамака звяртаецца масіў. І ў яго - бац і я - той, той, наступны радок, і ўсё зламалася. Калі гэта новы рэсурс і чалавек уздымае яго, бачыць, што нешта не працуе, то гэта хутка вырашаецца. А калі гэта autoscale-група абнавілася, то ў нейкі момант instances у autoscale-групе пачынаюць падмяняцца. І хлоп, нешта не працуе. Гэта крыўдна.
Атрымліваецца, што адзінае рашэнне - гэта тэставаць?
Так, вы бачыце праблему, вы туды дадаеце тэставыя крокі. Т. е. output'ам таксама можна тэставаць. Можа быць, не так зручна, але таксама можна нейкія пазнакі паставіць - правярайце, што User-data тут цвікамі прыбіта.
Мяне клічуць Цімур. Вельмі класна, што ёсць даклады пра тое, як правільна арганізоўваць Terraform.
Я нават не пачынаў.
Я думаю, што ў наступнай канфэрэнцыі, магчыма, будзе. У мяне ёсць простае пытанне. Чаму вы хардкодзіце значэнне ў асобным модулі, а не карыстаецеся tfvars, г. зн. чым лепш модуль са значэннямі, чым tfvars ?
Г. зн. мне тут (слайд: Production/environment/settings.tf) напісаць: domain = пераменная, domain vpcnetwork, пераменная vpcnetwork і stvars – дастаць тое ж самае?
Мы ж сапраўды так робім. Спасылаемся на модуль setting source, напрыклад.
Па сутнасці, гэта такі tfvars. Tfvars вельмі зручны ў testing-акружэнні. У мяне есць tfvars для вялікіх instances, для маленькіх. І я адзін файлік кінуў у тэчку. І атрымаў тое, што я хацеў. Калі мы інфраструктуру пілуем, мы жадаем, каб можна было паглядзець і адразу ўсё зразумець. А так атрымліваецца, што трэба зірнуць сюды, потым зірнуць у tfvars.
Атрымліваецца, каб усё было ў адным месцы?
Так, tfvars - гэта калі ў вас адзін код. І ён выкарыстоўваецца ў некалькіх розных месцах з рознымі нюансамі. Тады вы б tfvars кінулі і атрымалі вашыя нюансы. А мы - гэта інфраструктура як код у чыстым выглядзе. Паглядзеў і зразумеў.
Добры дзень! Сутыкаліся з такімі сітуацыямі, калі хмарны правайдэр умешваецца ў тое, што вы зрабілі Terraform 'ом? Дапусцім, мы мета-данную правім. Там ssh -ключы. А Google увесь час туды падсоўвае свае мета-дадзеныя, свае ключы. І Terraform заўжды піша, што ў яго ёсць змены. Пасля кожнага прагону, нават калі нічога не мяняецца, ён заўсёды кажа, што ён зараз гэтае поле будзе абнаўляць.
З ключамі, але - так, частка інфраструктуры здзіўлена такой штукай, т. е. Terraform памяняць нічога не можа. Мы рукамі таксама памяняць нічога не можам. Пакуль жывем з гэтым.
Т. е. вы з такім сутыкаліся, але нічога не прыдумалі, ён як робіць і робіць сам?
Нажаль так.
Добры дзень! Мяне клічуць Старкоў Станіслаў. Mail. tatoeba be Group. Як вырашаеце праблему з генерацыяй тэга на …, як вы яго перадаеце ўнутр? Я так разумею, праз User - data, каб паказаць host name, Puppet нацкаваць? І другая частка пытання. Як вы вырашаеце гэтае пытанне ў SG, т. е. калі вы генеруеце SG, сотня аднатыпных instances, як іх правільна назваць?
Тыя instances, якія нам вельмі важныя, мы іх найменны прыгожа. Тыя, якія не патрэбны, там прыпіска, што гэта autoscale-група. І па ідэі гэта можна прыбіць, і атрымаць новы.
Наконт праблемы з тэгам, то няма такой праблемы, а ёсць такая задача. І тэгі ў нас вельмі-вельмі моцна выкарыстоўваюцца, бо інфраструктура вялікая і дарагая. І нам трэба глядзець, на што сыходзяць грошы, таму тэгі дазваляюць раз'юшыцца, што і куды сышло. І адпаведна пошук таго, што нешта тут шмат грошай траціцца.
Пра што яшчэ пытанне было?
Калі SG стварае сотню instances, іх трэба неяк адрозніваць?
Не, не трэба. На кожным instance есць агент, які паведамляе, што ў мяне праблема. Калі агент паведамляе, то пра яго агент ведае і, прынамсі, яго IP-адрас існуе. Ужо можна збегаць. Па-другое, у нас выкарыстоўваецца Consul для Discovery, там, дзе не Kubernetes. І Consul таксама паказвае IP-адрас instance.
Т. е. вы арыентуецеся менавіта на IP, а не на host name ?
Немагчыма арыентавацца па host name, т. е. іх вельмі шмат. Ёсць ідэнтыфікатары instance - AE і г. д. Яго можна дзе-небудзь знайсці, можна яго ў пошук кінуць.
Прывітанне! Я зразумеў, што Terraform гэта добрая штука, заменчаная пад аблокі.
Не толькі.
Менавіта гэтае пытанне мне і цікавае. Калі вы вырашыце пераязджаць, дапусцім, на Bare Metal масава з усімі сваімі instances? Не будзе ніякіх праблем? Альбо ўсё ж такі давядзецца выкарыстоўваць іншыя прадукты, напрыклад, той жа Ansible, які быў тут згаданы?
Ansible крыху пра іншае. Т. е. Ansible працуе ўжо тады, калі instance запусціўся. А Terraform працуе да таго, як instance запусціўся. Пераход на Bare Metal - не.
Цяпер няма, а прыйдзе бізнэс і скажа: "Давай".
Пераход на іншае воблака - так, але тут трошкі іншая фішка. Трэба пісаць так Terraform-код, каб з меншай крывёй можна было перайсці на нейкае іншае воблака.
Першапачаткова ставілася такая задача, што ў нас уся інфраструктура - агностык, т. е. любое воблака павінна падысці, але ў нейкі момант бізнэс здаўся і сказаў: «Ок, у бліжэйшыя N гадоў мы нікуды не сыдзем, можна выкарыстоўваць сэрвісы ад Amazon ».
Terraform дазваляе ствараць у Front-End jobs, канфігураваць PagerDuty, data doc і т. д. У яго вельмі шмат хвастоў. Ён практычна можа кантраляваць увесь сьвет.
Дзякуй за даклад! Я ўжо таксама 4 гады кручу Terraform. На этапе плыўнага пераходу да Terraform, да інфраструктуры, да дэкларатыўнага апісання, мы сутыкаліся з сітуацыяй, калі нехта нешта рабіў рукамі, а ты спрабаваў зрабіць plan. І атрымліваў там нейкую памылку. Як вы такія праблемы разбіраеце? Як знаходзіце страчаныя рэсурсы, якія былі пазначаны?
У асноўным рукамі і вачыма, калі мы бачым у справаздачы нешта дзіўнае, то мы аналізуем, што там адбываецца, альбо проста забіваем. А наогул, pull requests - гэта звычайная справа.
Калі ёсць памылка, ці робіце вы rollback? Спрабавалі такое рабіць?
Не, гэтае рашэнне чалавека ў моманце, калі ён бачыць праблему.
Крыніца: habr.com