វិធីសាស្រ្តមួយ អាយ។ ស៊ី។ ស៊ី (Infrastructure as Code) មិនត្រឹមតែមានកូដដែលត្រូវបានរក្សាទុកក្នុងឃ្លាំងប៉ុណ្ណោះទេ ប៉ុន្តែក៏មានមនុស្ស និងដំណើរការដែលនៅជុំវិញកូដនេះផងដែរ។ តើវាអាចទៅរួចទេក្នុងការប្រើប្រាស់ឡើងវិញនូវវិធីសាស្រ្តពីការអភិវឌ្ឍន៍កម្មវិធី រហូតដល់ការគ្រប់គ្រងហេដ្ឋារចនាសម្ព័ន្ធ និងការពិពណ៌នា? វាជាការល្អក្នុងការរក្សាគំនិតនេះក្នុងចិត្តនៅពេលអ្នកអានអត្ថបទ។

នេះគឺជាប្រតិចារិករបស់ខ្ញុំ ការសម្តែង នៅលើ DevopsConf 2019-05-28.

ស្លាយ និងវីដេអូ

ភាសាអង់គ្លេស
កំណែជាភាសារុស្សី
ដំណើរការស្ងួត 2019-04-24 SpbLUG
វីដេអូ (RU) ពី DevopsConf 2019-05-28
វីដេអូ(RU) ពី DINS DevOps EVENING 2019-06-20
ស្លាយ

ហេដ្ឋារចនាសម្ព័ន្ធជាប្រវត្តិសាស្ត្រ

ឧបមាថាអ្នកមកគម្រោងថ្មី ហើយពួកគេប្រាប់អ្នកថា “យើងមាន ហេដ្ឋារចនាសម្ព័ន្ធជាក្រម"។ នៅក្នុងការពិតវាប្រែចេញ ហេដ្ឋារចនាសម្ព័ន្ធជាប្រវត្តិសាស្ត្រ ឬឧទាហរណ៍ ការចងក្រងឯកសារជាប្រវត្តិសាស្ត្រ. នេះគឺជាស្ថានភាពជាក់ស្តែងមួយ ជាឧទាហរណ៍ ករណីស្រដៀងគ្នានេះត្រូវបានពិពណ៌នាដោយ Denis Lysenko នៅក្នុងសុន្ទរកថាមួយ។ តើធ្វើដូចម្តេចដើម្បីជំនួសហេដ្ឋារចនាសម្ព័ន្ធទាំងមូលហើយចាប់ផ្តើមដេកលក់ស្រួលគាត់បានប្រាប់ពីរបៀបដែលពួកគេទទួលបានហេដ្ឋារចនាសម្ព័ន្ធដែលស៊ីសង្វាក់គ្នាសម្រាប់គម្រោងពីប្រវត្តិសាស្រ្ត bash ។

ជាមួយនឹងបំណងប្រាថ្នាខ្លះយើងអាចនិយាយបាន។ ហេដ្ឋារចនាសម្ព័ន្ធជាប្រវត្តិសាស្ត្រ នេះគឺដូចជាកូដ៖

ការបន្តពូជ៖ អ្នកអាចយកប្រវត្តិ bash ដំណើរការពាក្យបញ្ជាពីទីនោះ ហើយអ្នកអាចទទួលបានការកំណត់រចនាសម្ព័ន្ធការងារជាលទ្ធផល។
កំណែទម្រង់៖ អ្នកដឹងថាអ្នកណាដែលចូលមក និងអ្វីដែលពួកគេបានធ្វើ ជាថ្មីម្តងទៀត វាមិនមែនជាការពិតដែលថាវានឹងនាំអ្នកទៅកាន់ការកំណត់រចនាសម្ព័ន្ធការងារនៅច្រកចេញនោះទេ។
ប្រវត្តិសាស្រ្ត៖ រឿងអ្នកណាធ្វើអី។ មានតែអ្នកនឹងមិនអាចប្រើវាបានប្រសិនបើអ្នកបាត់បង់ម៉ាស៊ីនមេ។

តើខ្ញុំគួរធ្វើអ្វី?

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

សូម្បីតែករណីចម្លែកបែបនេះ ហេដ្ឋារចនាសម្ព័ន្ធជាប្រវត្តិសាស្ត្រ អ្នកអាចទាញវាដោយត្រចៀក ហេដ្ឋារចនាសម្ព័ន្ធជាក្រមប៉ុន្តែនៅពេលដែលយើងចង់ធ្វើអ្វីមួយដែលស្មុគ្រស្មាញជាងម៉ាស៊ីនមេ LAMP ចាស់ល្អនោះ យើងនឹងសន្និដ្ឋានថា កូដនេះត្រូវតែត្រូវបានកែប្រែ ផ្លាស់ប្តូរ និងកែលម្អ។ បន្ទាប់យើងចង់ពិចារណាភាពស្រដៀងគ្នារវាង ហេដ្ឋារចនាសម្ព័ន្ធជាក្រម និងការអភិវឌ្ឍន៍កម្មវិធី។

D.R.Y.

នៅលើគម្រោងអភិវឌ្ឍន៍ប្រព័ន្ធផ្ទុក មានកិច្ចការរងមួយ។ កំណត់រចនាសម្ព័ន្ធ SDS ជាទៀងទាត់៖ យើងកំពុងបញ្ចេញការចេញផ្សាយថ្មី - វាត្រូវតែត្រូវបានដាក់ឱ្យដំណើរការសម្រាប់ការសាកល្បងបន្ថែមទៀត។ ភារកិច្ចគឺសាមញ្ញណាស់៖

ចូលនៅទីនេះតាមរយៈ ssh ហើយប្រតិបត្តិពាក្យបញ្ជា។
ចម្លងឯកសារនៅទីនោះ។
កែការកំណត់នៅទីនេះ។
ចាប់ផ្តើមសេវាកម្មនៅទីនោះ
...
ពត៌មានផ្ទាល់ខ្លួន!

សម្រាប់តក្កវិជ្ជាដែលបានពិពណ៌នា bash គឺច្រើនជាងគ្រប់គ្រាន់ ជាពិសេសនៅដំណាក់កាលដំបូងនៃគម្រោង នៅពេលដែលវាទើបតែចាប់ផ្តើម។ នេះ។ វាមិនអាក្រក់ទេដែលអ្នកប្រើ bashប៉ុន្តែយូរ ៗ ទៅមានសំណើដើម្បីដាក់ពង្រាយអ្វីមួយដែលស្រដៀងគ្នាប៉ុន្តែខុសគ្នាបន្តិចបន្តួច។ រឿងដំបូងដែលចូលមកក្នុងគំនិតគឺចម្លង-បិទភ្ជាប់។ ហើយឥឡូវនេះ យើងមានស្គ្រីបស្រដៀងគ្នាខ្លាំងពីររួចហើយដែលធ្វើស្ទើរតែដូចគ្នា។ យូរ ៗ ទៅចំនួនស្គ្រីបកើនឡើង ហើយយើងប្រឈមមុខនឹងការពិតដែលថាមានតក្កវិជ្ជាអាជីវកម្មជាក់លាក់មួយសម្រាប់ការដាក់ពង្រាយការដំឡើងដែលចាំបាច់ត្រូវធ្វើសមកាលកម្មរវាងស្គ្រីបផ្សេងៗគ្នា វាមានភាពស្មុគស្មាញណាស់។

វាប្រែថាមានការអនុវត្តដូចជា D.R.Y. (កុំធ្វើខ្លួនឯងម្តងទៀត)។ គំនិតគឺប្រើកូដដែលមានស្រាប់ឡើងវិញ។ វាស្តាប់ទៅសាមញ្ញ ប៉ុន្តែយើងមិនបានមកភ្លាមៗនោះទេ។ ក្នុងករណីរបស់យើង វាជាគំនិតហាមប្រាម៖ ដើម្បីបំបែកការកំណត់ពីស្គ្រីប។ ទាំងនោះ។ តក្កវិជ្ជាអាជីវកម្មនៃរបៀបដែលការដំឡើងត្រូវបានដាក់ពង្រាយដោយឡែកពីគ្នា កំណត់រចនាសម្ព័ន្ធដោយឡែកពីគ្នា។

រឹង។ សម្រាប់ CFM

យូរ ៗ ទៅគម្រោងបានរីកចម្រើន ការបន្តធម្មជាតិ គឺជាការលេចឡើងនៃ Ansible ។ ហេតុផលចម្បងសម្រាប់រូបរាងរបស់វាគឺថាមានជំនាញក្នុងក្រុម ហើយថា bash មិនត្រូវបានរចនាឡើងសម្រាប់តក្កវិជ្ជាស្មុគស្មាញនោះទេ។ Ansible ក៏ចាប់ផ្តើមមានតក្កវិជ្ជាស្មុគស្មាញផងដែរ។ ដើម្បីទប់ស្កាត់តក្កវិជ្ជាស្មុគស្មាញពីការប្រែក្លាយទៅជាភាពវឹកវរ មានគោលការណ៍សម្រាប់រៀបចំកូដក្នុងការអភិវឌ្ឍន៍កម្មវិធី រឹង។ ឧទាហរណ៍ផងដែរ Grigory Petrov នៅក្នុងរបាយការណ៍ "ហេតុអ្វីបានជាអ្នកឯកទេសផ្នែកព័ត៌មានវិទ្យាត្រូវការម៉ាកផ្ទាល់ខ្លួន" បានលើកឡើងនូវសំណួរថាមនុស្សម្នាក់ត្រូវបានរចនាឡើងតាមរបៀបដែលវាងាយស្រួលសម្រាប់គាត់ក្នុងប្រតិបត្តិការជាមួយអង្គភាពសង្គមមួយចំនួននៅក្នុងការអភិវឌ្ឍន៍កម្មវិធីទាំងនេះ។ គឺជាវត្ថុ។ ប្រសិនបើយើងបញ្ចូលគ្នានូវគំនិតទាំងពីរនេះ ហើយបន្តអភិវឌ្ឍវា យើងនឹងសម្គាល់ឃើញថា យើងក៏អាចប្រើប្រាស់បានដែរ។ រឹង។ ដើម្បីធ្វើឱ្យវាកាន់តែងាយស្រួលក្នុងការរក្សា និងកែប្រែតក្កវិជ្ជានេះនាពេលអនាគត។

គោលការណ៍ទំនួលខុសត្រូវតែមួយ

ថ្នាក់នីមួយៗអនុវត្តភារកិច្ចតែមួយ។

មិនចាំបាច់លាយកូដ និងបង្កើតសត្វចម្លែក spaghetti ដ៏ទេវភាព monolithic ។ ហេដ្ឋារចនាសម្ព័ន្ធគួរតែមានឥដ្ឋសាមញ្ញ។ វាប្រែថាប្រសិនបើអ្នកបំបែក Ansible playbook ទៅជាបំណែកតូចៗ អានតួនាទី Ansible នោះពួកគេកាន់តែងាយស្រួលក្នុងការរក្សា។

គោលការណ៍បិទបើក

គោលការណ៍បើក / បិទ។

បើកទៅផ្នែកបន្ថែម៖ មានន័យថាឥរិយាបថរបស់អង្គភាពអាចត្រូវបានពង្រីកដោយបង្កើតប្រភេទអង្គភាពថ្មី។
បិទសម្រាប់ការផ្លាស់ប្តូរ៖ ជាលទ្ធផលនៃការពង្រីកឥរិយាបទរបស់អង្គភាព មិនគួរមានការផ្លាស់ប្តូរណាមួយចំពោះកូដដែលប្រើប្រាស់អង្គភាពទាំងនោះឡើយ។

ដំបូងឡើយ យើងបានដាក់ពង្រាយហេដ្ឋារចនាសម្ព័ន្ធសាកល្បងនៅលើម៉ាស៊ីននិម្មិត ប៉ុន្តែដោយសារតែការពិតដែលថាតក្កវិជ្ជាអាជីវកម្មនៃការដាក់ពង្រាយគឺដាច់ដោយឡែកពីការអនុវត្ត យើងបានបន្ថែមការដំណើរការទៅកាន់ baremetall ដោយគ្មានបញ្ហាអ្វីឡើយ។

គោលការណ៍ជំនួស Liskov

គោលការណ៍ជំនួសរបស់ Barbara Liskov ។ វត្ថុនៅក្នុងកម្មវិធីត្រូវតែអាចជំនួសបានដោយឧទាហរណ៍នៃប្រភេទរងរបស់វាដោយមិនផ្លាស់ប្តូរការប្រតិបត្តិត្រឹមត្រូវនៃកម្មវិធី

ប្រសិនបើអ្នកក្រឡេកមើលវាកាន់តែទូលំទូលាយ វាមិនមែនជាលក្ខណៈនៃគម្រោងពិសេសណាមួយដែលអាចត្រូវបានអនុវត្តនៅទីនោះទេ។ រឹង។ជាទូទៅវាគឺអំពី CFM ជាឧទាហរណ៍ នៅលើគម្រោងមួយផ្សេងទៀត វាចាំបាច់ក្នុងការដាក់ពង្រាយកម្មវិធី Java ដែលមានប្រអប់នៅលើ Java ផ្សេងៗ ម៉ាស៊ីនមេកម្មវិធី មូលដ្ឋានទិន្នន័យ ប្រព័ន្ធប្រតិបត្តិការ។ល។ ដោយប្រើឧទាហរណ៍នេះ ខ្ញុំនឹងពិចារណាគោលការណ៍បន្ថែមទៀត រឹង។

ក្នុងករណីរបស់យើង មានកិច្ចព្រមព្រៀងមួយនៅក្នុងក្រុមហេដ្ឋារចនាសម្ព័ន្ធថា ប្រសិនបើយើងបានដំឡើងតួនាទី imbjava ឬ oraclejava នោះ យើងមាន java binary executable ។ នេះគឺចាំបាច់ដោយសារតែ តួនាទីខាងលើអាស្រ័យលើឥរិយាបថនេះ ពួកគេរំពឹងថា java ។ ក្នុងពេលជាមួយគ្នានេះ វាអនុញ្ញាតឱ្យយើងជំនួសការអនុវត្ត/កំណែ java មួយជាមួយមួយផ្សេងទៀត ដោយមិនចាំបាច់ផ្លាស់ប្តូរតក្កវិជ្ជានៃការអនុវត្តកម្មវិធី។

បញ្ហានៅទីនេះគឺស្ថិតនៅក្នុងការពិតដែលថាវាមិនអាចទៅរួចទេក្នុងការអនុវត្តវានៅក្នុង Ansible ដែលជាលទ្ធផលនៃកិច្ចព្រមព្រៀងមួយចំនួនលេចឡើងនៅក្នុងក្រុម។

គោលការណ៍បែងចែកចំណុចប្រទាក់

គោលការណ៍បំបែកចំណុចប្រទាក់៖ “ចំណុចប្រទាក់ជាក់លាក់របស់អតិថិជនជាច្រើនគឺប្រសើរជាងចំណុចប្រទាក់គោលបំណងទូទៅមួយ។

ដំបូងឡើយ យើងបានព្យាយាមដាក់ភាពប្រែប្រួលទាំងអស់នៃការដាក់ពង្រាយកម្មវិធីទៅក្នុង Ansible playbook ប៉ុន្តែវាពិបាកក្នុងការគាំទ្រ ហើយវិធីសាស្រ្តនៅពេលដែលយើងមានចំណុចប្រទាក់ខាងក្រៅដែលបានបញ្ជាក់ (អតិថិជនរំពឹងថានឹងមានច្រក 443) បន្ទាប់មកហេដ្ឋារចនាសម្ព័ន្ធអាចត្រូវបានប្រមូលផ្តុំពីបុគ្គលម្នាក់ៗ។ ឥដ្ឋសម្រាប់ការអនុវត្តជាក់លាក់។

គោលការណ៍បញ្ច្រាសភាពអាស្រ័យ

គោលការណ៍នៃការបញ្ច្រាសភាពអាស្រ័យ។ ម៉ូឌុលនៅកម្រិតខ្ពស់មិនគួរពឹងផ្អែកលើម៉ូឌុលនៅកម្រិតទាបទេ។ ប្រភេទទាំងពីរនៃម៉ូឌុលត្រូវតែពឹងផ្អែកលើ abstractions ។ អរូបីមិនគួរអាស្រ័យលើព័ត៌មានលម្អិតទេ។ ព័ត៌មានលម្អិតត្រូវតែពឹងផ្អែកលើអរូបី។

នៅទីនេះឧទាហរណ៍នឹងផ្អែកលើការប្រឆាំងលំនាំមួយ។

អតិថិជនម្នាក់មានពពកឯកជន។
យើងបានបញ្ជាទិញម៉ាស៊ីននិម្មិតនៅខាងក្នុងពពក។
ប៉ុន្តែដោយសារតែធម្មជាតិនៃពពក ការដាក់ឱ្យប្រើប្រាស់កម្មវិធីត្រូវបានភ្ជាប់ជាមួយ hypervisor ដែល VM បើក។

ទាំងនោះ។ តក្កវិជ្ជានៃការដាក់ពង្រាយកម្មវិធីកម្រិតខ្ពស់បានហូរដោយភាពអាស្រ័យទៅកម្រិតទាបនៃអ្នកត្រួតពិនិត្យខ្ពស់ ហើយនេះមានន័យថាមានបញ្ហានៅពេលប្រើតក្កវិជ្ជានេះឡើងវិញ។ កុំធ្វើវាតាមរបៀបនេះ។

អន្តរកម្ម

ហេដ្ឋារចនាសម្ព័ន្ធជាកូដមិនត្រឹមតែនិយាយអំពីកូដប៉ុណ្ណោះទេ ប៉ុន្តែក៏អំពីទំនាក់ទំនងរវាងកូដនិងមនុស្ស អំពីអន្តរកម្មរវាងអ្នកបង្កើតហេដ្ឋារចនាសម្ព័ន្ធ។

កត្តាឡានក្រុង

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

គូ Devopsing

វាមិនដូចនោះទេ។ ជារឿងកំប្លែងដែលអ្នកគ្រប់គ្រងបានផឹកស្រាបៀរ ផ្លាស់ប្តូរពាក្យសម្ងាត់ និង analogue នៃការសរសេរកម្មវិធីជាគូ។ ទាំងនោះ។ វិស្វករពីរនាក់អង្គុយនៅកុំព្យូទ័រមួយ ក្តារចុចមួយ ហើយចាប់ផ្តើមរៀបចំហេដ្ឋារចនាសម្ព័ន្ធរបស់អ្នកជាមួយគ្នា៖ ដំឡើងម៉ាស៊ីនមេ សរសេរតួនាទី Ansible ជាដើម។ វាស្តាប់ទៅល្អ ប៉ុន្តែវាមិនដំណើរការសម្រាប់យើងទេ។ ប៉ុន្តែករណីពិសេសនៃការអនុវត្តនេះបានដំណើរការ។ និយោជិតថ្មីមកដល់ អ្នកណែនាំរបស់គាត់ទទួលភារកិច្ចជាក់ស្តែងរួមគ្នាជាមួយគាត់ ធ្វើការ និងផ្ទេរចំណេះដឹង។

ករណីពិសេសមួយទៀតគឺការហៅឧប្បត្តិហេតុ។ ក្នុងអំឡុងពេលមានបញ្ហាមួយ ក្រុមនៃអ្នកបំពេញកាតព្វកិច្ច និងអ្នកពាក់ព័ន្ធបានប្រមូលផ្តុំគ្នា អ្នកដឹកនាំម្នាក់ត្រូវបានតែងតាំង ដែលចែករំលែកអេក្រង់របស់គាត់ និងបញ្ចេញសម្លេងនៃគំនិត។ អ្នកចូលរួមផ្សេងទៀតធ្វើតាមគំនិតរបស់អ្នកដឹកនាំ ឈ្លបយកការណ៍ពីល្បិចពីកុងសូល ពិនិត្យមើលថាពួកគេមិនបានខកខានបន្ទាត់នៅក្នុងកំណត់ហេតុ និងរៀនអ្វីថ្មីអំពីប្រព័ន្ធ។ វិធីសាស្រ្តនេះមានប្រសិទ្ធភាពច្រើនជាងធម្មតា។

ការពិនិត្យកូដ

តាមប្រធានបទ វាកាន់តែមានប្រសិទ្ធភាពក្នុងការផ្សព្វផ្សាយចំណេះដឹងអំពីហេដ្ឋារចនាសម្ព័ន្ធ និងរបៀបដែលវាដំណើរការដោយប្រើការពិនិត្យកូដ៖

ហេដ្ឋារចនាសម្ព័ន្ធត្រូវបានពិពណ៌នាដោយលេខកូដនៅក្នុងឃ្លាំង។
ការផ្លាស់ប្តូរកើតឡើងនៅក្នុងសាខាដាច់ដោយឡែកមួយ។
ក្នុងអំឡុងពេលសំណើបញ្ចូលគ្នា អ្នកអាចឃើញតំបន់ដីសណ្តនៃការផ្លាស់ប្តូរនៅក្នុងហេដ្ឋារចនាសម្ព័ន្ធ។

ការបន្លិចនៅទីនេះគឺថាអ្នកត្រួតពិនិត្យត្រូវបានជ្រើសរើសម្តងមួយៗតាមកាលវិភាគពោលគឺឧ។ ជាមួយនឹងកម្រិតខ្លះនៃប្រូបាប៊ីលីតេ អ្នកនឹងឡើងចូលទៅក្នុងផ្នែកថ្មីនៃហេដ្ឋារចនាសម្ព័ន្ធ។

រចនាប័ទ្មកូដ

យូរៗទៅ ការឈ្លោះប្រកែកគ្នា ចាប់ផ្តើមលេចចេញជារូបរាង អំឡុងពេលពិនិត្យ ពីព្រោះ... អ្នកត្រួតពិនិត្យមានរចនាប័ទ្មផ្ទាល់ខ្លួនរបស់ពួកគេ ហើយការបង្វិលអ្នកត្រួតពិនិត្យបានជង់ពួកវាជាមួយនឹងរចនាប័ទ្មខុសៗគ្នា៖ ចន្លោះ 2 ឬ 4, camelCase ឬ snake_case ។ វាមិនអាចទៅរួចទេក្នុងការអនុវត្តភ្លាមៗ។

គំនិតដំបូងគឺត្រូវណែនាំឱ្យប្រើ linter បន្ទាប់ពីទាំងអស់ មនុស្សគ្រប់គ្នាគឺជាវិស្វករ មនុស្សគ្រប់គ្នាគឺឆ្លាត។ ប៉ុន្តែកម្មវិធីនិពន្ធផ្សេងគ្នា OS មិនងាយស្រួលទេ។
វាបានវិវត្តទៅជា bot ដែលសរសេរដើម្បីយឺតសម្រាប់ការប្រព្រឹត្តិបញ្ហានីមួយៗ និងភ្ជាប់ទិន្នផល linter ។ ប៉ុន្តែក្នុងករណីភាគច្រើន មានរឿងសំខាន់ជាងដែលត្រូវធ្វើ ហើយកូដនៅតែមិនជួសជុល។

Green Build Master

ពេលវេលាបានកន្លងផុតទៅ ហើយយើងបានឈានដល់ការសន្និដ្ឋានថា ការប្តេជ្ញាចិត្តដែលមិនឆ្លងកាត់ការសាកល្បងមួយចំនួន មិនអាចអនុញ្ញាតិឱ្យចូលទៅក្នុងមេបានទេ។ អីយ៉ា! យើងបានបង្កើត Green Build Master ដែលត្រូវបានអនុវត្តក្នុងការអភិវឌ្ឍន៍កម្មវិធីអស់រយៈពេលជាយូរ៖

ការអភិវឌ្ឍន៍កំពុងដំណើរការនៅក្នុងសាខាដាច់ដោយឡែកមួយ។
ការធ្វើតេស្តកំពុងដំណើរការលើខ្សែនេះ។
ប្រសិនបើការធ្វើតេស្តបរាជ័យ លេខកូដនឹងមិនធ្វើឱ្យវាក្លាយជាមេទេ។

ការសម្រេចចិត្តនេះពិតជាឈឺចាប់ខ្លាំងណាស់ព្រោះ... បង្កជារឿងចម្រូងចម្រាសជាច្រើន ប៉ុន្តែវាមានតម្លៃព្រោះ... ការពិនិត្យឡើងវិញបានចាប់ផ្តើមទទួលបានសំណើសម្រាប់ការរួមបញ្ចូលគ្នាដោយគ្មានភាពខុសគ្នានៅក្នុងរចនាប័ទ្ម ហើយយូរ ៗ ទៅចំនួននៃតំបន់បញ្ហាបានចាប់ផ្តើមថយចុះ។

ការធ្វើតេស្ត IaC

បន្ថែមពីលើការត្រួតពិនិត្យរចនាប័ទ្ម អ្នកអាចប្រើរបស់ផ្សេងទៀតឧទាហរណ៍ ដើម្បីពិនិត្យមើលថាហេដ្ឋារចនាសម្ព័ន្ធរបស់អ្នកពិតជាអាចដាក់ពង្រាយបាន។ ឬពិនិត្យមើលថាការផ្លាស់ប្តូរហេដ្ឋារចនាសម្ព័ន្ធនឹងមិននាំឱ្យបាត់បង់លុយទេ។ ហេតុអ្វីបានជានេះអាចត្រូវការ? សំណួរគឺស្មុគ្រស្មាញ និងជាទស្សនវិជ្ជា វាជាការប្រសើរជាងក្នុងការឆ្លើយជាមួយនឹងរឿងមួយដែលថាមានឧបករណ៍ធ្វើមាត្រដ្ឋានដោយស្វ័យប្រវត្តិនៅលើ Powershell ដែលមិនបានពិនិត្យលក្ខខណ្ឌព្រំដែន => VMs កាន់តែច្រើនត្រូវបានបង្កើតឡើងលើសពីការចាំបាច់ => អតិថិជនបានចំណាយប្រាក់ច្រើនជាងការគ្រោងទុក។ នេះមិនសូវសប្បាយចិត្តទេ ប៉ុន្តែវាអាចនឹងអាចចាប់កំហុសនេះនៅដំណាក់កាលមុនបាន។

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

ពីរ៉ាមីតសាកល្បង IaC

ការធ្វើតេស្ត IaC៖ ការវិភាគឋិតិវន្ត

ប្រសិនបើអ្នកដាក់ពង្រាយហេដ្ឋារចនាសម្ព័ន្ធទាំងមូលក្នុងពេលតែមួយ ហើយពិនិត្យមើលថាវាដំណើរការ អ្នកអាចឃើញថាវាត្រូវការពេលវេលាច្រើន ហើយត្រូវការពេលវេលាច្រើន។ ដូច្នេះហើយ មូលដ្ឋានត្រូវតែជាអ្វីមួយដែលដំណើរការបានលឿន មានច្រើន ហើយវាគ្របដណ្ដប់កន្លែងបុព្វកាលច្រើន។

Bash មានល្បិច

សូមក្រឡេកមើលឧទាហរណ៍ដ៏កម្រមួយ។ ជ្រើសរើសឯកសារទាំងអស់នៅក្នុងថតបច្ចុប្បន្ន ហើយចម្លងទៅទីតាំងផ្សេងទៀត។ រឿងដំបូងដែលគិតដល់៖

for i in * ; do 
    cp $i /some/path/$i.bak
done

ចុះប្រសិនបើមានចន្លោះនៅក្នុងឈ្មោះឯកសារ? មិនអីទេ យើងឆ្លាត យើងដឹងពីរបៀបប្រើសម្រង់៖

for i in * ; do cp "$i" "/some/path/$i.bak" ; done

ល្អណាស់? ទេ! ចុះបើមិនមានអ្វីនៅក្នុងថត, i.e. ការគៀបនឹងមិនដំណើរការទេ។

find . -type f -exec mv -v {} dst/{}.bak ;

ធ្វើបានល្អឥឡូវនេះ? ទេ... ភ្លេចអ្វីដែលអាចមាននៅក្នុងឈ្មោះឯកសារ n.

touch x
mv x  "$(printf "foonbar")"
find . -type f -print0 | xargs -0 mv -t /path/to/target-dir

ឧបករណ៍វិភាគឋិតិវន្ត

បញ្ហាពីជំហានមុនអាចចាប់បាននៅពេលដែលយើងភ្លេចសម្រង់ ព្រោះវាមានវិធីព្យាបាលជាច្រើនក្នុងធម្មជាតិ ពិនិត្យសែលជាទូទៅមានពួកវាជាច្រើន ហើយភាគច្រើនអ្នកទំនងជាអាចស្វែងរកស្រទាប់សម្រាប់ជង់របស់អ្នកនៅក្រោម IDE របស់អ្នក។

ភាសា
ឧបករណ៍

bash
ពិនិត្យសែល

Ruby ព្រម
RuboCop

ពស់ថ្លាន់
ផៃលីន។

ansible
Ansible Lint

ការធ្វើតេស្ត IaC: ការធ្វើតេស្តឯកតា

ដូចដែលយើងបានឃើញពីឧទាហរណ៍មុន ធុងសំរាមមិនមានថាមពលពេញលេញទេ ហើយមិនអាចចង្អុលបង្ហាញគ្រប់បញ្ហាទាំងអស់នោះទេ។ លើសពីនេះ ដោយការប្រៀបធៀបជាមួយនឹងការធ្វើតេស្តនៅក្នុងការអភិវឌ្ឍន៍កម្មវិធី យើងអាចរំលឹកឡើងវិញនូវការធ្វើតេស្តឯកតា។ អ្វីដែលនឹកឃើញភ្លាមៗនោះគឺ ស៊ូនីត, យូនីត, rspec, pytest. ប៉ុន្តែអ្វីដែលត្រូវធ្វើជាមួយ ansible, ចុងភៅ, saltstack និងអ្នកដទៃចូលចិត្តពួកគេ?

នៅដើមដំបូងយើងបាននិយាយអំពី រឹង។ ហើយថាហេដ្ឋារចនាសម្ព័ន្ធរបស់យើងគួរតែមានឥដ្ឋតូចៗ។ ពេលវេលារបស់ពួកគេបានមកដល់ហើយ។

ហេដ្ឋារចនាសម្ព័ន្ធត្រូវបានបែងចែកទៅជាឥដ្ឋតូចៗ ឧទាហរណ៍ តួនាទី Ansible ។
ប្រភេទបរិយាកាសមួយចំនួនត្រូវបានដាក់ពង្រាយ មិនថាវា docker ឬ VM ទេ។
យើងអនុវត្តតួនាទី Ansible របស់យើងចំពោះបរិយាកាសសាកល្បងនេះ។
យើងពិនិត្យមើលថាអ្វីៗដំណើរការដូចដែលយើងរំពឹងទុក (យើងដំណើរការតេស្ត)។
យើងសម្រេចថាយល់ព្រម ឬមិនយល់ព្រម។

ការធ្វើតេស្ត IaC៖ ឧបករណ៍ធ្វើតេស្តឯកតា

សំណួរ តើតេស្តអ្វីខ្លះសម្រាប់ CFM? អ្នកគ្រាន់តែអាចដំណើរការស្គ្រីប ឬអ្នកអាចប្រើដំណោះស្រាយដែលត្រៀមរួចជាស្រេចសម្រាប់ការនេះ៖

CFM
ឧបករណ៍

Ansible
តេស្តិនហ្វ្រា

ប្រធាន
អធិការកិច្ច

ប្រធាន
Serverspec

អំបិល
ហ្កាស

ឧទាហរណ៍សម្រាប់ testinfra ពិនិត្យមើលអ្នកប្រើប្រាស់នោះ។ test1, test2 មានហើយស្ថិតក្នុងក្រុម sshusers:

def test_default_users(host):
    users = ['test1', 'test2' ]
    for login in users:
        assert host.user(login).exists
        assert 'sshusers' in host.user(login).groups

តើត្រូវជ្រើសរើសអ្វី? សំណួរគឺស្មុគ្រស្មាញ និងមិនច្បាស់លាស់ នេះគឺជាឧទាហរណ៍នៃការផ្លាស់ប្តូរគម្រោងនៅលើ github សម្រាប់ឆ្នាំ 2018-2019៖

ក្របខ័ណ្ឌនៃការធ្វើតេស្ត IaC

សំណួរកើតឡើង: របៀបដាក់វាទាំងអស់រួមគ្នាហើយចាប់ផ្តើមវា? អាច យកវាហើយធ្វើវាដោយខ្លួនឯង។ ប្រសិនបើមានវិស្វករគ្រប់គ្រាន់។ ឬអ្នកអាចយកដំណោះស្រាយដែលត្រៀមរួចជាស្រេច ទោះបីជាមានមិនច្រើនក៏ដោយ៖

CFM
ឧបករណ៍

Ansible
ម៉ូលេគុល

ប្រធាន
ផ្ទះបាយសាកល្បង

Terraform
គួរឱ្យខ្លាចបំផុត។

ឧទាហរណ៍នៃការផ្លាស់ប្តូរគម្រោងនៅលើ github សម្រាប់ឆ្នាំ 2018-2019៖

ម៉ូលេគុលទល់នឹង ផ្ទះបាយសាកល្បង

ដំបូងយើង សាកល្បងប្រើផ្ទះបាយ:

បង្កើត VM ស្របគ្នា។
អនុវត្តតួនាទី Ansible ។
ដំណើរការអធិការកិច្ច។

សម្រាប់ 25-35 តួនាទីវាដំណើរការ 40-70 នាទីដែលមានរយៈពេលយូរ។

ជំហានបន្ទាប់គឺការផ្លាស់ប្តូរទៅ jenkins/docker/ansible/molecule។ Idiologically អ្វីគ្រប់យ៉ាងគឺដូចគ្នា។

លីងសៀវភៅលេង។
តម្រង់ជួរតួនាទី។
បើកដំណើរការកុងតឺន័រ
អនុវត្តតួនាទី Ansible ។
ដំណើរការ testinfra ។
ពិនិត្យភាពគ្មានសមត្ថភាព។

Linting សម្រាប់ 40 តួនាទី និងការធ្វើតេស្តសម្រាប់រាប់សិបចាប់ផ្តើមចំណាយពេលប្រហែល 15 នាទី។

អ្វីដែលត្រូវជ្រើសរើសអាស្រ័យលើកត្តាជាច្រើនដូចជាជង់ដែលបានប្រើ ជំនាញក្នុងក្រុម។ល។ នៅទីនេះអ្នកគ្រប់គ្នាសម្រេចចិត្តដោយខ្លួនឯងអំពីរបៀបបិទសំណួរតេស្តឯកតា

ការធ្វើតេស្ត IaC៖ ការធ្វើតេស្តរួមបញ្ចូល

ជំហានបន្ទាប់ក្នុងការធ្វើតេស្តហេដ្ឋារចនាសម្ព័ន្ធពីរ៉ាមីតនឹងជាការធ្វើតេស្តសមាហរណកម្ម។ ពួកវាស្រដៀងនឹងការធ្វើតេស្តឯកតា៖

ហេដ្ឋារចនាសម្ព័ន្ធត្រូវបានបែងចែកទៅជាឥដ្ឋតូចៗ ឧទាហរណ៍ តួនាទី Ansible ។
ប្រភេទបរិយាកាសមួយចំនួនត្រូវបានដាក់ពង្រាយ មិនថាវា docker ឬ VM ទេ។
សម្រាប់បរិយាកាសសាកល្បងនេះត្រូវបានអនុវត្ត មួយបាច់ តួនាទីដែលមិនអាចយល់បាន។
យើងពិនិត្យមើលថាអ្វីៗដំណើរការដូចដែលយើងរំពឹងទុក (យើងដំណើរការតេស្ត)។
យើងសម្រេចថាយល់ព្រម ឬមិនយល់ព្រម។

និយាយជារួម យើងមិនពិនិត្យមើលដំណើរការនៃធាតុនីមួយៗនៃប្រព័ន្ធដូចនៅក្នុងការធ្វើតេស្តឯកតានោះទេ យើងពិនិត្យមើលពីរបៀបដែលម៉ាស៊ីនមេត្រូវបានកំណត់រចនាសម្ព័ន្ធទាំងមូល។

ការធ្វើតេស្ត IaC៖ ការធ្វើតេស្តបញ្ចប់

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

គម្រោងដែលមានប្រវត្តិសម្បូរបែប។ វាត្រូវបានប្រើនៅក្នុងអង្គការធំៗ ហើយប្រហែលជាអ្នកម្នាក់ៗបានឆ្លងកាត់ផ្លូវដោយប្រយោលជាមួយវា។ កម្មវិធីនេះគាំទ្រមូលដ្ឋានទិន្នន័យជាច្រើន ការរួមបញ្ចូល។ល។ ការដឹងពីអ្វីដែលហេដ្ឋារចនាសម្ព័ន្ធអាចមានរូបរាងជាឯកសារ docker-compose ជាច្រើន និងការដឹងថាការធ្វើតេស្តណាមួយដែលត្រូវដំណើរការក្នុងបរិយាកាសមួយណាគឺ Jenkins ។

គ្រោងការណ៍នេះដំណើរការជាយូរណាស់មកហើយ រហូតដល់ក្នុងក្របខ័ណ្ឌ ការស្រាវជ្រាវ យើងមិនបានព្យាយាមផ្ទេរវាទៅ Openshift ទេ។ ធុងនៅតែដដែល ប៉ុន្តែបរិយាកាសនៃការបាញ់បង្ហោះបានផ្លាស់ប្តូរ (ជំរាបសួរ D.R.Y. ម្តងទៀត)។

គំនិតស្រាវជ្រាវបានបន្តទៅមុខទៀត ហើយនៅក្នុង openshift ពួកគេបានរកឃើញរឿងដូចជា APB (Ansible Playbook Bundle) ដែលអនុញ្ញាតឱ្យអ្នកខ្ចប់ចំណេះដឹងអំពីរបៀបដាក់ពង្រាយហេដ្ឋារចនាសម្ព័ន្ធទៅក្នុងកុងតឺន័រ។ ទាំងនោះ។ មានចំណុចដែលអាចសាកល្បងបាន និងអាចសាកល្បងបាននៃចំណេះដឹងអំពីរបៀបដាក់ពង្រាយហេដ្ឋារចនាសម្ព័ន្ធ។

ទាំងអស់នេះស្តាប់ទៅល្អរហូតដល់យើងរត់ចូលទៅក្នុងហេដ្ឋារចនាសម្ព័ន្ធចម្រុះ៖ យើងត្រូវការ Windows សម្រាប់ការធ្វើតេស្ត។ ជាលទ្ធផល ចំណេះដឹងនៃអ្វី កន្លែងណា របៀបដាក់ពង្រាយ និងការធ្វើតេស្តគឺស្ថិតនៅក្នុង jenkins ។

សន្និដ្ឋាន

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

លេខកូដនៅក្នុងឃ្លាំង។
អន្តរកម្មរបស់មនុស្ស។
ការធ្វើតេស្តហេដ្ឋារចនាសម្ព័ន្ធ។

តំណភ្ជាប់

ប្រភព: www.habr.com

អ្វីដែលខ្ញុំបានរៀនពីការសាកល្បង 200 បន្ទាត់នៃកូដរចនាសម្ព័ន្ធ