បានប្តូរពី Terraform ទៅ CloudFormation - ហើយសោកស្តាយវា។

ការតំណាងឱ្យហេដ្ឋារចនាសម្ព័ន្ធជាកូដនៅក្នុងទម្រង់អត្ថបទដែលអាចធ្វើម្តងទៀតបាន គឺជាការអនុវត្តដ៏សាមញ្ញបំផុតសម្រាប់ប្រព័ន្ធដែលមិនតម្រូវឱ្យមានការលេងសើចជាមួយសត្វកណ្តុរ។ ការអនុវត្តនេះមានឈ្មោះ - ហេដ្ឋារចនាសម្ព័ន្ធជាក្រមហើយរហូតមកដល់ពេលនេះមានឧបករណ៍ពេញនិយមពីរដើម្បីអនុវត្តវា ជាពិសេសនៅក្នុង AWS៖ Terraform и CloudFormation.

ការប្រៀបធៀបបទពិសោធន៍ជាមួយ Terraform និង CloudFormation

មុនពេលមក Twitch (គាត់​គឺ ក្រុមហ៊ុន Amazon Jr.) ខ្ញុំ​បាន​ធ្វើការ នៅក្នុងការចាប់ផ្ដើមមួយ។ ហើយបានប្រើ Terraform អស់រយៈពេលបីឆ្នាំ។ នៅកន្លែងថ្មី ខ្ញុំក៏បានប្រើ Terraform ដោយអស់ពីកម្លាំងរបស់ខ្ញុំ ហើយបន្ទាប់មកក្រុមហ៊ុនបានជំរុញការផ្លាស់ប្តូរទៅគ្រប់អ្វីៗទាំងអស់របស់ Amazon រួមទាំង CloudFormation ផងដែរ។ ខ្ញុំបានបង្កើតការអនុវត្តល្អបំផុតសម្រាប់ទាំងពីរយ៉ាងឧស្សាហ៍ព្យាយាម ហើយបានប្រើឧបករណ៍ទាំងពីរនៅក្នុងដំណើរការការងារដ៏ស្មុគស្មាញ និងពេញមួយស្ថាប័ន។ ក្រោយមក បន្ទាប់ពីការគិតថ្លឹងថ្លែងពីផលប៉ះពាល់នៃការធ្វើចំណាកស្រុកពី Terraform ទៅ CloudFormation ខ្ញុំជឿជាក់ថា Terraform ប្រហែលជាជម្រើសដ៏ល្អបំផុតសម្រាប់អង្គការ។

Terraform គួរឱ្យរន្ធត់

កម្មវិធីបេតា

Terraform មិនទាន់បានចេញកំណែ 1.0 នៅឡើយទេ ដែលជាហេតុផលដ៏ល្អក្នុងការមិនប្រើវា។ វា​បាន​ផ្លាស់​ប្តូរ​ច្រើន​តាំង​ពី​ខ្ញុំ​បាន​សាកល្បង​វា​ដោយ​ខ្លួន​ឯង​ដំបូង ប៉ុន្តែ​ត្រឡប់​មក​វិញ​ពេល​នោះ​ terraform apply ជារឿយៗខូចបន្ទាប់ពីការអាប់ដេតជាច្រើន ឬជាធម្មតាបន្ទាប់ពីប្រើប្រាស់បានពីរបីឆ្នាំ។ ខ្ញុំនឹងនិយាយថា "អ្វីគ្រប់យ៉ាងគឺខុសគ្នាឥឡូវនេះ" ប៉ុន្តែ ... នោះជាអ្វីដែលមនុស្សគ្រប់គ្នាហាក់ដូចជានិយាយមែនទេ? មានការផ្លាស់ប្តូរដែលមិនឆបគ្នាជាមួយកំណែមុន ទោះបីជាវាសមស្របក៏ដោយ ហើយវាថែមទាំងមានអារម្មណ៍ថាវាក្យសម្ព័ន្ធ និងអរូបីនៃឃ្លាំងផ្ទុកធនធានឥឡូវនេះគឺជាអ្វីដែលយើងត្រូវការ។ ឧបករណ៍​នេះ​ហាក់​ដូច​ជា​មាន​ភាព​ប្រសើរ​ជាង​មុន ប៉ុន្តែ... :-0

ម៉្យាងវិញទៀត AWS បានធ្វើការងារដ៏ល្អដោយរក្សាភាពឆបគ្នាថយក្រោយ។ នេះប្រហែលជាដោយសារតែសេវាកម្មរបស់ពួកគេជាញឹកញាប់ត្រូវបានសាកល្បងយ៉ាងហ្មត់ចត់នៅក្នុងស្ថាប័ន ហើយមានតែបន្ទាប់មកប្តូរឈ្មោះត្រូវបានបោះពុម្ពផ្សាយ។ ដូច្នេះ "ពួកគេបានព្យាយាមយ៉ាងខ្លាំង" គឺជាការនិយាយមិនច្បាស់។ ការរក្សាភាពឆបគ្នាថយក្រោយជាមួយ APIs សម្រាប់ប្រព័ន្ធដែលផ្លាស់ប្តូរ និងស្មុគស្មាញដូច AWS គឺពិបាកមិនគួរឱ្យជឿ។ នរណាម្នាក់ដែលត្រូវតែរក្សា APIs សាធារណៈដែលត្រូវបានប្រើយ៉ាងទូលំទូលាយដូចដែលពួកគេមានគួរតែយល់ថាវាលំបាកប៉ុណ្ណាក្នុងការធ្វើវាអស់រយៈពេលជាច្រើនឆ្នាំ។ ប៉ុន្តែឥរិយាបថរបស់ CloudFormation នៅក្នុងការចងចាំរបស់ខ្ញុំ មិនដែលផ្លាស់ប្តូរប៉ុន្មានឆ្នាំមកនេះ។

ជួបជើង... វាជាគ្រាប់កាំភ្លើង

តាមខ្ញុំដឹង លុបធនធាន អ្នកខាងក្រៅ ជង់ CloudFormation ពីជង់ CF របស់អ្នកមិនអាចធ្វើទៅបានទេ។ Terraform ក៏ដូចគ្នាដែរ។ វាអនុញ្ញាតឱ្យអ្នកនាំចូលធនធានដែលមានស្រាប់ទៅក្នុងជង់របស់អ្នក។ មុខងារអាចនិយាយបានថាអស្ចារ្យ ប៉ុន្តែជាមួយនឹងថាមពលដ៏អស្ចារ្យមកការទទួលខុសត្រូវដ៏អស្ចារ្យ។ អ្នកគ្រាន់តែត្រូវបន្ថែមធនធានទៅជង់ ហើយខណៈពេលដែលអ្នកកំពុងធ្វើការជាមួយជង់របស់អ្នក អ្នកមិនអាចលុប ឬផ្លាស់ប្តូរធនធាននេះបានទេ។ ថ្ងៃមួយ វាបានផ្ទុះឡើង។ នៅថ្ងៃមួយនៅលើ Twitch មាននរណាម្នាក់បាននាំចូលក្រុមសុវត្ថិភាព AWS របស់នរណាម្នាក់ដោយចៃដន្យចូលទៅក្នុងជង់ Terraform ផ្ទាល់ខ្លួនរបស់ពួកគេ ខណៈពេលដែលមិនមានកំហុសអ្វីទាំងអស់។ ខ្ញុំបានបញ្ចូលពាក្យបញ្ជាជាច្រើន ហើយ... ក្រុមសន្តិសុខ (រួមជាមួយនឹងចរាចរណ៍ចូល) បានបាត់។

Terraform អស្ចារ្យ

ការងើបឡើងវិញពីរដ្ឋមិនពេញលេញ

ពេលខ្លះ CloudFormation បរាជ័យក្នុងការផ្លាស់ប្តូរទាំងស្រុងពីរដ្ឋមួយទៅរដ្ឋមួយទៀត។ ក្នុងពេលជាមួយគ្នានេះគាត់នឹងព្យាយាមត្រលប់ទៅអតីតកាលវិញ។ វាជាការអាណិតដែលវាមិនតែងតែអាចទៅរួចនោះទេ។ វាអាចគួរឱ្យខ្លាចក្នុងការបំបាត់កំហុសនូវអ្វីដែលបានកើតឡើងនៅពេលក្រោយ - អ្នកមិនដឹងថាតើ CloudFormation នឹងសប្បាយចិត្តដែលវាត្រូវបានលួចទេ - សូម្បីតែដើម្បីជួសជុលវាក៏ដោយ។ ថាតើវាអាចទៅរួចឬអត់ដើម្បីត្រលប់ទៅស្ថានភាពមុននោះ គាត់ពិតជាមិនដឹងពីរបៀបកំណត់ ហើយតាមលំនាំដើម គាត់ព្យួរជាច្រើនម៉ោងរង់ចាំអព្ភូតហេតុ។

ម្យ៉ាងវិញទៀត Terraform មានទំនោរក្នុងការងើបឡើងវិញពីការផ្លាស់ប្តូរដែលបរាជ័យកាន់តែល្អ និងផ្តល់នូវឧបករណ៍បំបាត់កំហុសកម្រិតខ្ពស់។

ការផ្លាស់ប្តូរកាន់តែច្បាស់ចំពោះស្ថានភាពឯកសារ

“មិនអីទេ ការផ្ទុកតុល្យភាព អ្នកកំពុងផ្លាស់ប្តូរ។ ប៉ុន្តែ​ធ្វើ​យ៉ាងម៉េច?"

- វិស្វករ​ដែល​មាន​ការ​ព្រួយ​បារម្ភ, ត្រៀម​ខ្លួន​ជា​ស្រេច​ដើម្បី​ចុច​ប៊ូតុង "ទទួល​យក​" ។

ពេលខ្លះខ្ញុំត្រូវធ្វើឧបាយកលមួយចំនួនជាមួយនឹងឧបករណ៍ផ្ទុកតុល្យភាពនៅក្នុងជង់ CloudFormation ដូចជាការបន្ថែមលេខច្រក ឬការផ្លាស់ប្តូរក្រុមសុវត្ថិភាព។ ClouFormation បង្ហាញការផ្លាស់ប្តូរមិនល្អ។ ខ្ញុំនៅលើម្ជុល និងម្ជុល ពិនិត្យមើលឯកសារ yaml ពីរដង ដើម្បីប្រាកដថា ខ្ញុំមិនបានលុបអ្វីដែលចាំបាច់ និងមិនបានបន្ថែមអ្វីដែលមិនចាំបាច់។

Terraform មានតម្លាភាពជាងក្នុងរឿងនេះ។ ពេល​ខ្លះ​គាត់​មាន​តម្លាភាព​ពេក (អាន៖ រំខាន)។ ជាសំណាងល្អ កំណែចុងក្រោយបំផុតរួមបញ្ចូលទាំងការបង្ហាញនៃការផ្លាស់ប្តូរដែលប្រសើរឡើង ដូច្នេះឥឡូវនេះអ្នកអាចឃើញច្បាស់នូវអ្វីដែលកំពុងផ្លាស់ប្តូរ។

ភាពបត់បែន

សរសេរកម្មវិធីថយក្រោយ។

ដើម្បីដាក់វាឱ្យត្រង់ លក្ខណៈសំខាន់បំផុតនៃកម្មវិធីដែលប្រើបានយូរគឺសមត្ថភាពក្នុងការសម្របខ្លួនទៅនឹងការផ្លាស់ប្តូរ។ សរសេរកម្មវិធីណាមួយថយក្រោយ។ ជាញឹកញាប់បំផុតខ្ញុំបានធ្វើកំហុសដោយទទួលយកសេវាកម្ម "សាមញ្ញ" ហើយបន្ទាប់មកចាប់ផ្តើមប្រមូលផ្តុំអ្វីគ្រប់យ៉ាងទៅជា CloudFormation ឬ Terraform stack តែមួយ។ ហើយ​ជា​ការ​ពិត​ណាស់ ប៉ុន្មាន​ខែ​ក្រោយ​មក វា​ត្រូវ​បាន​គេ​បង្ហាញ​ថា​ខ្ញុំ​បាន​យល់​អ្វី​គ្រប់​យ៉ាង​ខុស ហើយ​សេវា​ពិត​ជា​មិន​សាមញ្ញ​ទេ! ហើយ​ឥឡូវ​នេះ​ខ្ញុំ​ត្រូវ​ការ​ដូចម្ដេច​ដើម្បី​បំបែក​ជង់​ធំ​មួយ​ទៅ​ជា​សមាសភាគ​តូច​។ នៅពេលអ្នកធ្វើការជាមួយ CloudFormation នេះអាចត្រូវបានធ្វើដោយការបង្កើតឡើងវិញនូវជង់ដែលមានស្រាប់ជាមុនសិន ប៉ុន្តែខ្ញុំមិនធ្វើបែបនេះជាមួយមូលដ្ឋានទិន្នន័យរបស់ខ្ញុំទេ។ ម្យ៉ាងវិញទៀត Terraform បានធ្វើឱ្យវាអាចបំបែកជង់ និងបំបែកវាទៅជាផ្នែកតូចៗដែលអាចយល់បាន។

ម៉ូឌុលនៅក្នុង git

ការចែករំលែកកូដ Terraform នៅលើជង់ច្រើនគឺងាយស្រួលជាងការចែករំលែកកូដ CloudFormation ។ ជាមួយនឹង Terraform អ្នកអាចដាក់កូដរបស់អ្នកនៅក្នុងឃ្លាំង git ហើយចូលប្រើវាដោយប្រើការគ្រប់គ្រងកំណែ semantic ។ អ្នក​ណា​ម្នាក់​ដែល​មាន​សិទ្ធិ​ចូល​ទៅ​កាន់​ឃ្លាំង​នេះ​អាច​ប្រើ​កូដ​ដែល​បាន​ចែក​រំលែក​ឡើង​វិញ។ សមមូលរបស់ CloudFormation គឺ S3 ប៉ុន្តែវាមិនមានអត្ថប្រយោជន៍ដូចគ្នាទេ ហើយគ្មានហេតុផលដែលយើងគួរបោះបង់ចោល git ក្នុងការពេញចិត្ត S3 ទាល់តែសោះ។

អង្គការបានរីកចម្រើន ហើយសមត្ថភាពក្នុងការចែករំលែកជង់ទូទៅឈានដល់កម្រិតសំខាន់មួយ។ Terraform ធ្វើឱ្យអ្វីៗទាំងអស់នេះមានភាពងាយស្រួល និងមានលក្ខណៈធម្មជាតិ ចំណែក CloudFormation នឹងធ្វើឱ្យអ្នកលោតតាមរង្វង់មូល មុនពេលអ្នកអាចទទួលបានការងារបែបនេះ។

ប្រតិបត្តិការជាកូដ

"តោះ​សរសេរ​វា​ហើយ​មិន​អី​ទេ"។

-វិស្វករ 3 ឆ្នាំមុនពេលបង្កើតកង់ Terraform ។

នៅពេលនិយាយអំពីការអភិវឌ្ឍន៍កម្មវិធី Go ឬកម្មវិធី Java មិនមែនគ្រាន់តែជាកូដនោះទេ។

កូដជាកូដ

វាក៏មានហេដ្ឋារចនាសម្ព័ន្ធដែលវាដំណើរការផងដែរ។

ហេដ្ឋារចនាសម្ព័ន្ធជាក្រម

ប៉ុន្តែតើនាងមកពីណា? តើធ្វើដូចម្តេចដើម្បីតាមដានវា? តើលេខកូដរបស់អ្នករស់នៅទីណា? តើអ្នកអភិវឌ្ឍន៍ត្រូវការការអនុញ្ញាតចូលប្រើដែរឬទេ?

ប្រតិបត្តិការជាកូដ

ក្នុងនាមជាអ្នកបង្កើតកម្មវិធីមិនមែនមានន័យថាគ្រាន់តែសរសេរកូដនោះទេ។

AWS មិនមែនតែមួយទេ៖ អ្នកប្រហែលជាប្រើអ្នកផ្តល់សេវាផ្សេងទៀត។ SignalFx, PagerDuty ឬ Github ។ ប្រហែលជាអ្នកមានម៉ាស៊ីនមេ Jenkins ខាងក្នុងសម្រាប់ CI/CD ឬផ្ទាំងគ្រប់គ្រង Grafana ខាងក្នុងសម្រាប់ការត្រួតពិនិត្យ។ Infra as Code ត្រូវបានជ្រើសរើសសម្រាប់ហេតុផលផ្សេងៗគ្នា ហើយនីមួយៗមានសារៈសំខាន់ដូចគ្នាសម្រាប់អ្វីគ្រប់យ៉ាងដែលទាក់ទងនឹងកម្មវិធី។

នៅពេលដែលខ្ញុំធ្វើការនៅ Twitch យើងបានបង្កើនល្បឿនសេវាកម្មនៅក្នុងប្រព័ន្ធបង្កប់ និង AWS របស់ក្រុមហ៊ុន Amazon ។ យើងបានបង្រួបបង្រួម និងគាំទ្រសេវាកម្មមីក្រូជាច្រើន ដោយបង្កើនតម្លៃប្រតិបត្តិការ។ ការពិភាក្សាបានប្រព្រឹត្តទៅដូចនេះ៖

• Я៖ យ៉ាប់ នោះ​ជា​កាយវិការ​ជា​ច្រើន​ក្នុង​ការ​ត្រួត​ពិនិត្យ​សេវា​មីក្រូ​មួយ។ ខ្ញុំនឹងត្រូវប្រើសំរាមនេះដើម្បីបង្កើតគណនី AWS (យើងបានទៅគណនី 2 នៅលើ សេវាមីក្រូ) បន្ទាប់មក នេះ​សម្រាប់​ការ​កំណត់​ការ​ជូន​ដំណឹង មួយ​នេះ​សម្រាប់​ឃ្លាំង​កូដ និង​មួយ​នេះ​សម្រាប់​បញ្ជី​អ៊ីមែល ហើយ​បន្ទាប់​មក​នេះ...
• នាំមុខ៖ តោះ​សរសេរ​វា​ហើយ​មិន​អី​ទេ។
• Я៖ មិនអីទេ ប៉ុន្តែស្គ្រីបខ្លួនឯងនឹងផ្លាស់ប្តូរ។ យើងនឹងត្រូវការវិធីមួយដើម្បីពិនិត្យមើលថា Amazon gizmos ដែលភ្ជាប់មកជាមួយទាំងនេះគឺទាន់សម័យ។
• នាំមុខ: ពិតជា​ល្អ​ណាស់។ ហើយយើងនឹងសរសេរស្គ្រីបសម្រាប់រឿងនេះ។
• Я៖ អស្ចារ្យណាស់! ហើយស្គ្រីបប្រហែលជានៅតែត្រូវកំណត់ប៉ារ៉ាម៉ែត្រ។ តើគាត់នឹងទទួលយកពួកគេទេ?
• នាំមុខ៖ ឲ្យ​គាត់​យក​ទៅ!
• Я៖ ដំណើរការអាចផ្លាស់ប្តូរ ហើយភាពឆបគ្នាថយក្រោយនឹងបាត់បង់។ ប្រភេទនៃការគ្រប់គ្រងកំណែ semantic មួយចំនួននឹងត្រូវបានទាមទារ។
• នាំមុខ៖ គំនិតល្អណាស់!
• Я៖ ឧបករណ៍អាចត្រូវបានផ្លាស់ប្តូរដោយដៃ នៅខាងក្នុងចំណុចប្រទាក់អ្នកប្រើ។ យើងនឹងត្រូវការវិធីមួយដើម្បីពិនិត្យ និងជួសជុលវា។

…៣ឆ្នាំក្រោយ៖

• នាំមុខ៖ ហើយយើងទទួលបាន terraform ។

សីល​នៃ​រឿង​គឺ៖ ទោះ​ជា​អ្នក ឈានជើងលើកែងជើងនៅក្នុងអ្វីគ្រប់យ៉ាង Amazonអ្នកនៅតែប្រើអ្វីមួយដែលមិនមែនមកពី AWS ហើយសេវាកម្មទាំងនេះមានស្ថានភាពដែលប្រើភាសាកំណត់រចនាសម្ព័ន្ធដើម្បីរក្សាស្ថានភាពនោះឱ្យស៊ីសង្វាក់គ្នា។

CloudFormation lambda ទល់នឹង git ម៉ូឌុល terraform

lambda គឺជាដំណោះស្រាយរបស់ CloudFormation ចំពោះបញ្ហាតក្កវិជ្ជាផ្ទាល់ខ្លួន។ ជាមួយ lambda អ្នកអាចធ្វើបាន បង្កើតម៉ាក្រូ ឬ ធនធានអ្នកប្រើប្រាស់. វិធីសាស្រ្តនេះណែនាំភាពស្មុគស្មាញបន្ថែមដែលមិនមានវត្តមាននៅក្នុងកំណែ semantic របស់ Terraform នៃម៉ូឌុល git ។ សម្រាប់ខ្ញុំ បញ្ហាដែលចាប់អារម្មណ៍បំផុតគឺការគ្រប់គ្រងការអនុញ្ញាតសម្រាប់ lambdas អ្នកប្រើប្រាស់ទាំងអស់នេះ (ហើយទាំងនេះគឺជាគណនី AWS រាប់សិប)។ បញ្ហាសំខាន់មួយទៀតគឺ "តើអ្វីបានមកដល់មុន សាច់មាន់ ឬស៊ុត?" វាទាក់ទងនឹងកូដ lambda ។ មុខងារនេះខ្លួនឯងគឺជាហេដ្ឋារចនាសម្ព័ន្ធ និងកូដ ហើយខ្លួនវាត្រូវការការត្រួតពិនិត្យ និងធ្វើបច្ចុប្បន្នភាព។ ក្រចកចុងក្រោយនៅក្នុងមឈូសគឺជាការលំបាកក្នុងការធ្វើបច្ចុប្បន្នភាព semantically ការផ្លាស់ប្តូរកូដ lambda; យើងក៏ត្រូវប្រាកដថាសកម្មភាពជង់ដោយគ្មានពាក្យបញ្ជាផ្ទាល់មិនផ្លាស់ប្តូររវាងការរត់។

ខ្ញុំចាំបានថា ខ្ញុំចង់បង្កើតការដាក់ពង្រាយ Canary សម្រាប់បរិស្ថាន Elastic Beanstalk ជាមួយនឹងឧបករណ៍ផ្ទុកតុល្យភាពបុរាណ។ អ្វី​ដែល​ស្រួល​បំផុត​នឹង​ធ្វើ​គឺ​ត្រូវ​ធ្វើ​ការ​ដាក់​ពង្រាយ​ទីពីរ​សម្រាប់ EB នៅ​ជាប់​នឹង​បរិយាកាស​ផលិតកម្ម ដោយ​យក​វា​មួយ​ជំហាន​ទៀត៖ ការ​រួម​បញ្ចូល​ក្រុម​ដាក់​ពង្រាយ Canary ដែល​ធ្វើ​មាត្រដ្ឋាន​ដោយ​ស្វ័យ​ប្រវត្តិ​ជាមួយ​នឹង​ការ​ដាក់​ពង្រាយ LB ទៅ​ក្នុង​បរិយាកាស​ផលិតកម្ម។ ហើយចាប់តាំងពី Terraform ប្រើ ASG beantalk ជាការសន្និដ្ឋានវានឹងទាមទារ 4 បន្ទាត់បន្ថែមនៃកូដនៅក្នុង Terraform ។ នៅពេលខ្ញុំសួរថាតើមានដំណោះស្រាយដែលអាចប្រៀបធៀបបាននៅក្នុង CloudFormation ដែរឬទេ ពួកគេបានចង្អុលខ្ញុំទៅកាន់ឃ្លាំង git ទាំងមូលជាមួយនឹងបំពង់ដាក់ពង្រាយ និងអ្វីៗគ្រប់យ៉ាង ដើម្បីជាប្រយោជន៍ដល់អ្វីមួយដែលកូដ Terraform ខ្សោយចំនួន 4 អាចធ្វើបាន។

វា​រក​ឃើញ​ការ​រសាត់​ល្អ​ជាង

ត្រូវប្រាកដថាការពិតត្រូវនឹងការរំពឹងទុក។

ការ​រក​ឃើញ​ការ​រសាត់ គឺ​ជា​ប្រតិបត្តិការ​ដ៏​មាន​ឥទ្ធិពល​ជា​លក្ខណៈ​កូដ​ដោយ​សារ​តែ​វា​ជួយ​ធានា​ថា​ការ​ពិត​ត្រូវ​នឹង​ការ​រំពឹង​ទុក។ វាអាចប្រើបានទាំង CloudFormation និង Terraform ។ ប៉ុន្តែនៅពេលដែលផលិតកម្មកើនឡើង ការស្វែងរករសាត់នៅក្នុង CloudFormation បានបង្កើតការរកឃើញមិនពិតកាន់តែច្រើនឡើង។

ជាមួយនឹង Terraform អ្នកមានទំពក់ជីវិតកម្រិតខ្ពស់បន្ថែមទៀតសម្រាប់ការរកឃើញរសាត់។ ឧទាហរណ៍អ្នកបញ្ចូលពាក្យបញ្ជា មិនអើពើ_ការផ្លាស់ប្តូរ ដោយផ្ទាល់នៅក្នុងនិយមន័យភារកិច្ច ECS ប្រសិនបើអ្នកចង់មិនអើពើការផ្លាស់ប្តូរចំពោះការកំណត់ភារកិច្ចជាក់លាក់ដោយមិនអើពើការផ្លាស់ប្តូរចំពោះការដាក់ពង្រាយ ECS ទាំងមូលរបស់អ្នក។

CDK និងអនាគតនៃ CloudFormation

CloudFormation មានការលំបាកក្នុងការគ្រប់គ្រងលើមាត្រដ្ឋានឆ្លងកាត់ហេដ្ឋារចនាសម្ព័ន្ធធំៗ។ ការលំបាកទាំងនេះជាច្រើនត្រូវបានទទួលស្គាល់ ហើយឧបករណ៍ត្រូវការអ្វីៗដូចជា aws-cdkដែលជាក្របខ័ណ្ឌសម្រាប់កំណត់ហេដ្ឋារចនាសម្ព័ន្ធពពកនៅក្នុងកូដ និងដំណើរការវាតាមរយៈ AWS CloudFormation។ វានឹងគួរឱ្យចាប់អារម្មណ៍ក្នុងការមើលថាតើអនាគតនឹងមានអ្វីសម្រាប់ aws-cdk ប៉ុន្តែវានឹងមានការលំបាកក្នុងការប្រកួតប្រជែងជាមួយនឹងភាពខ្លាំងផ្សេងទៀតរបស់ Terraform ។ ដើម្បីនាំយក CloudFormation ទាន់សម័យ ការផ្លាស់ប្តូរសកលនឹងត្រូវបានទាមទារ។

ដូច្នេះ Terraform មិនខកចិត្តទេ។

នេះគឺជា "ហេដ្ឋារចនាសម្ព័ន្ធជាកូដ" មិនមែន "ជាអត្ថបទ" ទេ។

ចំណាប់អារម្មណ៍ដំបូងរបស់ខ្ញុំចំពោះ Terraform គឺអាក្រក់ជាង។ ខ្ញុំ​គិត​ថា​ខ្ញុំ​គ្រាន់​តែ​មិន​យល់​ពី​វិធី​សា​ស្រ្ត​។ វិស្វករស្ទើរតែទាំងអស់យល់ឃើញដោយអចេតនាថាវាជាទម្រង់អត្ថបទដែលត្រូវការបំប្លែងទៅជាហេដ្ឋារចនាសម្ព័ន្ធដែលចង់បាន។ កុំធ្វើវាតាមរបៀបនេះ។

ការពិតនៃការអភិវឌ្ឍន៍កម្មវិធីល្អក៏អនុវត្តចំពោះ Terraform ផងដែរ។

ខ្ញុំបានឃើញការអនុវត្តជាច្រើនដែលត្រូវបានអនុម័តដើម្បីបង្កើតកូដល្អដែលមិនត្រូវបានអើពើនៅក្នុង Terraform ។ អ្នកបានសិក្សាអស់ជាច្រើនឆ្នាំ ដើម្បីក្លាយជាអ្នកសរសេរកម្មវិធីដ៏ល្អម្នាក់។ កុំបោះបង់បទពិសោធន៍នេះ ដោយសារអ្នកកំពុងធ្វើការជាមួយ Terraform។ ការពិតនៃការអភិវឌ្ឍន៍កម្មវិធីល្អអនុវត្តចំពោះ Terraform ។

ម៉េច​មិន​សរសេរ​កូដ?

ខ្ញុំបានឃើញជង់ Terraform ដ៏ធំដោយគ្មានឯកសារពិតប្រាកដ។ តើអ្នកអាចសរសេរកូដក្នុងទំព័រដោយរបៀបណា ដោយគ្មានឯកសារ? បន្ថែមឯកសារដែលពន្យល់របស់អ្នក។ កូដ Terraform (សង្កត់ធ្ងន់លើពាក្យ "កូដ") ហេតុអ្វីបានជាផ្នែកនេះមានសារៈសំខាន់ណាស់ ហើយអ្វីដែលអ្នកធ្វើ។

តើ​យើង​អាច​ដាក់​ពង្រាយ​សេវាកម្ម​ដែល​ធ្លាប់​ជា​មុខងារ​សំខាន់​មួយ​យ៉ាង​ដូចម្ដេច?

ខ្ញុំបានឃើញជង់ Terraform ស្មុគ្រស្មាញណាស់ដែលបង្ហាញជាម៉ូឌុលតែមួយ។ ហេតុអ្វីយើងមិនដាក់កម្មវិធីតាមវិធីនេះ? ហេតុអ្វីបានជាយើងបែងចែកមុខងារធំៗទៅជាមុខងារតូចៗ? ចម្លើយដូចគ្នានេះអនុវត្តចំពោះ Terraform ។ ប្រសិនបើម៉ូឌុលរបស់អ្នកធំពេក អ្នកត្រូវបំបែកវាទៅជាម៉ូឌុលតូចៗ។

តើក្រុមហ៊ុនរបស់អ្នកមិនប្រើបណ្ណាល័យទេ?

ខ្ញុំបានឃើញពីរបៀបដែលវិស្វករ បង្វិលគម្រោងថ្មីដោយប្រើ Terraform លួចចម្លង-បិទភ្ជាប់កំណាត់ធំៗពីគម្រោងផ្សេងទៀតទៅក្នុងរបស់ពួកគេ ហើយបន្ទាប់មកបានគិតគូរជាមួយពួកគេរហូតដល់វាចាប់ផ្តើមដំណើរការ។ តើអ្នកនឹងធ្វើការដូចនេះជាមួយកូដ "ប្រយុទ្ធ" នៅក្នុងក្រុមហ៊ុនរបស់អ្នកទេ? យើងមិនគ្រាន់តែប្រើបណ្ណាល័យទេ។ បាទ មិនមែនអ្វីៗទាំងអស់ត្រូវតែជាបណ្ណាល័យទេ ប៉ុន្តែតើយើងគ្មានបណ្ណាល័យចែករំលែកជាគោលការណ៍នៅឯណា?!

តើអ្នកមិនប្រើ PEP8 ឬ gofmt ទេ?

ភាសាភាគច្រើនមានគ្រោងការណ៍ស្តង់ដារដែលទទួលយកបាន។ នៅក្នុង Python នេះគឺជា PEP8 ។ នៅក្នុង Go - gofmt ។ Terraform មានផ្ទាល់ខ្លួនរបស់វា៖ terraform fmt. សូមរីករាយជាមួយវាដើម្បីសុខភាពរបស់អ្នក!

តើអ្នកនឹងប្រើ React ដោយមិនដឹង JavaScript ទេ?

ម៉ូឌុល Terraform អាចសម្រួលផ្នែកខ្លះនៃហេដ្ឋារចនាសម្ព័ន្ធស្មុគស្មាញដែលអ្នកបង្កើត ប៉ុន្តែនេះមិនមានន័យថាអ្នកមិនអាចប្រើប្រាស់វាទាល់តែសោះ។ ចង់ប្រើ Terraform ឱ្យបានត្រឹមត្រូវដោយមិនយល់ពីធនធាន? អ្នកនឹងត្រូវវិនាស៖ ពេលវេលានឹងកន្លងផុតទៅ ហើយអ្នកនឹងមិនអាចធ្វើជាម្ចាស់ Terraform បានទេ។

តើអ្នកសរសេរកូដជាមួយ singletons ឬ dependency injection?

ការចាក់ដោយភាពអាស្រ័យគឺជាការអនុវត្តល្អបំផុតដែលត្រូវបានទទួលស្គាល់សម្រាប់ការអភិវឌ្ឍន៍កម្មវិធី ហើយត្រូវបានគេពេញចិត្តជាង singletons ។ តើវាមានប្រយោជន៍យ៉ាងណានៅក្នុង Terraform? ខ្ញុំបានឃើញម៉ូឌុល Terraform ដែលអាស្រ័យលើស្ថានភាពពីចម្ងាយ។ ជំនួសឱ្យការសរសេរម៉ូឌុលដែលទាញយកស្ថានភាពពីចម្ងាយ សូមសរសេរម៉ូឌុលដែលយកប៉ារ៉ាម៉ែត្រ។ ហើយបន្ទាប់មកបញ្ជូនប៉ារ៉ាម៉ែត្រទាំងនេះទៅម៉ូឌុល។

តើ​បណ្ណាល័យ​របស់​អ្នក​ធ្វើ​រឿង​ដប់​យ៉ាង​ល្អ​ឬ​រឿង​មួយ​អស្ចារ្យ?

បណ្ណាល័យដែលដំណើរការបានល្អបំផុតគឺអ្នកដែលផ្តោតលើកិច្ចការមួយដែលពួកគេធ្វើបានល្អណាស់។ ជំនួសឱ្យការសរសេរម៉ូឌុល Terraform ធំដែលព្យាយាមធ្វើអ្វីគ្រប់យ៉ាងក្នុងពេលតែមួយ បង្កើតផ្នែកខ្លះនៃពួកវាដែលធ្វើរឿងមួយបានល្អ។ ហើយបន្ទាប់មកផ្សំពួកវាតាមតម្រូវការ។

តើ​អ្នក​ធ្វើ​ការ​ផ្លាស់​ប្តូរ​បណ្ណាល័យ​ដោយ​មិន​មាន​ភាព​ត្រូវ​គ្នា​ថយ​ក្រោយ​ដោយ​របៀប​ណា?

ម៉ូឌុល Terraform ទូទៅ ដូចជាបណ្ណាល័យធម្មតា ត្រូវការទំនាក់ទំនងការផ្លាស់ប្តូរទៅកាន់អ្នកប្រើប្រាស់ ដោយមិនចាំបាច់ត្រូវគ្នាថយក្រោយ។ វាជាការរំខាននៅពេលដែលការផ្លាស់ប្តូរទាំងនេះកើតឡើងនៅក្នុងបណ្ណាល័យ ហើយវាគ្រាន់តែជាការរំខាននៅពេលដែលការផ្លាស់ប្តូរដែលមិនត្រូវគ្នានឹងថយក្រោយត្រូវបានធ្វើឡើងនៅក្នុងម៉ូឌុល Terraform ។ វាត្រូវបានណែនាំឱ្យប្រើស្លាក git និង semver នៅពេលប្រើម៉ូឌុល Terraform ។

តើសេវាកម្មផលិតរបស់អ្នកដំណើរការលើកុំព្យូទ័រយួរដៃរបស់អ្នក ឬនៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យមែនទេ?

Hashicorp មានឧបករណ៍ដូចជា ពពក terraform ដើម្បីដំណើរការ terraform របស់អ្នក។ សេវាកម្មកណ្តាលទាំងនេះធ្វើឱ្យមានភាពងាយស្រួលក្នុងការគ្រប់គ្រង សវនកម្ម និងអនុម័តការផ្លាស់ប្តូរផ្ទៃរាបស្មើ។

តើអ្នកមិនសរសេរតេស្តទេ?

វិស្វករទទួលស្គាល់ថាលេខកូដត្រូវតែត្រូវបានសាកល្បង ប៉ុន្តែពួកគេខ្លួនឯងជារឿយៗភ្លេចអំពីការធ្វើតេស្តនៅពេលធ្វើការជាមួយ Terraform ។ សម្រាប់ហេដ្ឋារចនាសម្ព័ន្ធ នេះគឺពោរពេញដោយគ្រាក្បត់។ ដំបូន្មានរបស់ខ្ញុំគឺ "សាកល្បង" ឬ "បង្កើតឧទាហរណ៍" ជង់ដោយប្រើម៉ូឌុលដែលអាចដាក់ឱ្យប្រើប្រាស់បានត្រឹមត្រូវសម្រាប់ការធ្វើតេស្តក្នុងអំឡុងពេល CI/CD ។

Terraform និង microservices

ជីវិត និងការស្លាប់របស់ក្រុមហ៊ុនសេវាមីក្រូ អាស្រ័យទៅលើល្បឿន ការច្នៃប្រឌិត និងការរំខាននៃការងារមីក្រូសេវាកម្មថ្មី។

ទិដ្ឋភាពអវិជ្ជមានទូទៅបំផុតដែលទាក់ទងនឹងស្ថាបត្យកម្មមីក្រូសេវាកម្ម ហើយដែលមិនអាចលុបចោលបាន គឺទាក់ទងនឹងការងារ មិនមែនកូដនោះទេ។ ប្រសិនបើអ្នកគិតថា Terraform គ្រាន់តែជាមធ្យោបាយមួយដើម្បីធ្វើស្វ័យប្រវត្តិកម្មផ្នែកហេដ្ឋារចនាសម្ព័ន្ធនៃស្ថាបត្យកម្ម microservices នោះអ្នកកំពុងបាត់បង់អត្ថប្រយោជន៍ពិតនៃប្រព័ន្ធនេះ។ ឥឡូវនេះវារួចទៅហើយ អ្វីគ្រប់យ៉ាងគឺដូចជាកូដ.

ប្រភព: www.habr.com