ការអនុវត្តការចែកចាយបន្តជាមួយ Docker (ពិនិត្យ និងវីដេអូ)

យើងនឹងចាប់ផ្តើមប្លុករបស់យើងជាមួយនឹងការបោះពុម្ពផ្សាយដោយផ្អែកលើសុន្ទរកថាចុងក្រោយបំផុតរបស់នាយកបច្ចេកទេសរបស់យើង។ ឌីស្តុល (Dmitry Stolyarov) ។ ពួកគេទាំងអស់បានធ្វើឡើងក្នុងឆ្នាំ 2016 នៅក្នុងព្រឹត្តិការណ៍អាជីពផ្សេងៗ ហើយត្រូវបានឧទ្ទិសដល់ប្រធានបទ DevOps និង Docker ។ វីដេអូមួយពីការប្រជុំ Docker Moscow នៅការិយាល័យ Badoo យើងមានរួចហើយ បោះពុម្ពផ្សាយ អនឡាញ។ អត្ថបទថ្មីនឹងត្រូវបានអមដោយអត្ថបទដែលបង្ហាញពីខ្លឹមសារនៃរបាយការណ៍។ ដូច្នេះ…

ថ្ងៃទី 31 ខែឧសភានៅក្នុងសន្និសីទ RootConf 2016ដែលបានប្រារព្ធឡើងជាផ្នែកមួយនៃមហោស្រព "បច្ចេកវិទ្យាអ៊ីនធឺណិតរុស្ស៊ី" (RIT ++ 2016) ផ្នែក "ការដាក់ពង្រាយបន្តនិងការដាក់ឱ្យប្រើប្រាស់" បានបើកជាមួយនឹងរបាយការណ៍ "ការអនុវត្តល្អបំផុតនៃការចែកចាយបន្តជាមួយ Docker" ។ វាបានសង្ខេប និងរៀបចំជាប្រព័ន្ធនូវការអនុវត្តល្អបំផុតសម្រាប់ការកសាងដំណើរការចែកចាយបន្ត (ស៊ីឌី) ដោយប្រើ Docker និងផលិតផលប្រភពបើកចំហផ្សេងទៀត។ យើងធ្វើការជាមួយដំណោះស្រាយទាំងនេះក្នុងផលិតកម្ម ដែលអនុញ្ញាតឱ្យយើងពឹងផ្អែកលើបទពិសោធន៍ជាក់ស្តែង។

ប្រសិនបើអ្នកមានឱកាសចំណាយពេលមួយម៉ោង វីដេអូនៃរបាយការណ៍យើងសូមណែនាំឱ្យមើលវាពេញ។ បើមិនដូច្នេះទេ ខាងក្រោមគឺជាសេចក្តីសង្ខេបសំខាន់ក្នុងទម្រង់អត្ថបទ។

ការដឹកជញ្ជូនជាបន្តបន្ទាប់ជាមួយ Docker

ក្រោម។ ការដឹកជញ្ជូនបន្ត យើងយល់ពីខ្សែសង្វាក់នៃព្រឹត្តិការណ៍ដែលជាលទ្ធផលនៃកូដកម្មវិធីពីឃ្លាំង Git ដំបូងមកដល់ការផលិត ហើយបន្ទាប់មកបញ្ចប់នៅក្នុងប័ណ្ណសារ។ នាងមើលទៅដូចនេះ៖ Git → Build → Test → Release → Operate.

របាយការណ៍ភាគច្រើនត្រូវបានឧទ្ទិសដល់ដំណាក់កាលសាងសង់ (ការជួបប្រជុំគ្នានៃកម្មវិធី) ហើយប្រធានបទដែលបានចេញផ្សាយ និងដំណើរការត្រូវបានប៉ះដោយសង្ខេប។ យើងនឹងនិយាយអំពីបញ្ហា និងលំនាំដែលអនុញ្ញាតឱ្យអ្នកដោះស្រាយពួកវា ហើយការអនុវត្តជាក់លាក់នៃគំរូទាំងនេះអាចខុសគ្នា។

ហេតុអ្វីបានជា Docker ត្រូវការនៅទីនេះ? វាមិនមែនសម្រាប់គ្មានអ្វីដែលយើងសម្រេចចិត្តនិយាយអំពីការអនុវត្តការចែកចាយបន្តនៅក្នុងបរិបទនៃឧបករណ៍ប្រភពបើកចំហនេះ។ ទោះបីជារបាយការណ៍ទាំងមូលត្រូវបានឧទ្ទិសដល់ការប្រើប្រាស់របស់វាក៏ដោយ ហេតុផលជាច្រើនត្រូវបានបង្ហាញនៅពេលពិចារណាលើគំរូចម្បងនៃការចេញផ្សាយកូដកម្មវិធី។

លំនាំ​ការ​ចេញ​ផ្សាយ​ចម្បង​

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

ដូច្នេះសម្រាប់ពេលខ្លះកំណែទាំងពីរនៃកម្មវិធី (ចាស់ និងថ្មី) នឹងដំណើរការក្នុងពេលដំណាលគ្នា។ ដែលនាំឱ្យដោយស្វ័យប្រវត្តិ ជម្លោះធនធានរួម៖ បណ្តាញ ប្រព័ន្ធឯកសារ IPC ។ល។ ជាមួយនឹង Docker បញ្ហានេះត្រូវបានដោះស្រាយយ៉ាងងាយស្រួលដោយការដំណើរការកំណែផ្សេងគ្នានៃកម្មវិធីនៅក្នុងធុងដាច់ដោយឡែក ដែលការញែកធនធានត្រូវបានធានានៅក្នុងម៉ាស៊ីនដូចគ្នា (ម៉ាស៊ីនមេ/ម៉ាស៊ីននិម្មិត)។ ជាការពិតណាស់អ្នកអាចទទួលបានដោយល្បិចមួយចំនួនដោយគ្មានអ៊ីសូឡង់ទាល់តែសោះប៉ុន្តែប្រសិនបើមានឧបករណ៍ដែលត្រៀមរួចជាស្រេចនិងងាយស្រួលនោះមានហេតុផលផ្ទុយ - មិនត្រូវធ្វេសប្រហែស។

ការ​ដាក់​កុងតឺន័រ​ផ្តល់​អត្ថប្រយោជន៍​ជា​ច្រើន​ទៀត​នៅ​ពេល​ដាក់​ពង្រាយ។ កម្មវិធីណាមួយអាស្រ័យលើ កំណែជាក់លាក់ (ឬជួរកំណែ) អ្នកបកប្រែភាពអាចរកបាននៃម៉ូឌុល/ផ្នែកបន្ថែម។ល។ ក៏ដូចជាកំណែរបស់វា។ ហើយនេះអនុវត្តមិនត្រឹមតែចំពោះបរិស្ថានដែលអាចប្រតិបត្តិបានភ្លាមៗប៉ុណ្ណោះទេ ប៉ុន្តែថែមទាំងចំពោះបរិស្ថានទាំងមូល រួមទាំងផងដែរ។ កម្មវិធីប្រព័ន្ធ និងកំណែរបស់វា (រហូតដល់ការចែកចាយលីនុចដែលបានប្រើ)។ ដោយសារតែការពិតដែលថាកុងតឺន័រមិនត្រឹមតែមានលេខកូដកម្មវិធីប៉ុណ្ណោះទេប៉ុន្តែថែមទាំងប្រព័ន្ធនិងកម្មវិធីដែលបានដំឡើងជាមុននៃកំណែដែលត្រូវការអ្នកអាចភ្លេចអំពីបញ្ហាជាមួយភាពអាស្រ័យ។

ចូរយើងសង្ខេប លំនាំ​ការ​ចេញ​ផ្សាយ​ចម្បង​ កំណែថ្មីដោយគិតគូរពីកត្តាខាងក្រោម៖

1. ដំបូង កំណែចាស់របស់កម្មវិធីដំណើរការក្នុងកុងតឺន័រដំបូង។
2. បន្ទាប់មកកំណែថ្មីត្រូវបានដាក់ចេញហើយ "កំដៅឡើង" នៅក្នុងធុងទីពីរ។ គួរកត់សម្គាល់ថាកំណែថ្មីនេះអាចអនុវត្តមិនត្រឹមតែកូដកម្មវិធីដែលបានអាប់ដេតប៉ុណ្ណោះទេ ថែមទាំងភាពអាស្រ័យណាមួយរបស់វា ក៏ដូចជាសមាសធាតុនៃប្រព័ន្ធ (ឧទាហរណ៍ កំណែថ្មីនៃ OpenSSL ឬការចែកចាយទាំងមូល)។
3. នៅពេលដែលកំណែថ្មីរួចរាល់ពេញលេញដើម្បីបម្រើសំណើ ចរាចរណ៍ប្តូរពីកុងតឺន័រទីមួយទៅធុងទីពីរ។
4. កំណែចាស់ឥឡូវនេះអាចត្រូវបានបញ្ឈប់។

វិធីសាស្រ្តនៃការដាក់ពង្រាយកំណែផ្សេងគ្នានៃកម្មវិធីនៅក្នុងធុងដាច់ដោយឡែកផ្តល់នូវភាពងាយស្រួលមួយផ្សេងទៀត - ការវិលត្រឡប់មកវិញរហ័ស ទៅកំណែចាស់ (បន្ទាប់ពីទាំងអស់ វាគ្រប់គ្រាន់ដើម្បីប្តូរចរាចរទៅកាន់កុងតឺន័រដែលចង់បាន)។

អនុសាសន៍ដំបូងចុងក្រោយស្តាប់ទៅដូចជាអ្វីមួយដែលសូម្បីតែប្រធានក្រុមមិនអាចរកឃើញកំហុសជាមួយ៖ "[ពេលរៀបចំការចែកចាយបន្តជាមួយ Docker] ប្រើ Docker [និងយល់ពីអ្វីដែលវាផ្តល់ឱ្យ]" សូមចាំថានេះមិនមែនជាគ្រាប់កាំភ្លើងប្រាក់ដែលនឹងដោះស្រាយបញ្ហាទាំងអស់នោះទេ ប៉ុន្តែជាឧបករណ៍ដែលផ្តល់នូវមូលដ្ឋានគ្រឹះដ៏អស្ចារ្យ។

ការបន្តពូជ

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

• ស្គ្រីបដែលត្រូវបានត្រួតពិនិត្យដោយនាយកដ្ឋានគុណភាពសម្រាប់ដំណាក់កាលត្រូវតែត្រូវបានផលិតឡើងវិញយ៉ាងត្រឹមត្រូវនៅក្នុងផលិតកម្ម។
• កម្មវិធីត្រូវបានបោះពុម្ពនៅលើម៉ាស៊ីនមេ ដែលអាចទទួលកញ្ចប់ពីកញ្ចក់ឃ្លាំងផ្សេងៗគ្នា (យូរៗទៅពួកគេត្រូវបានអាប់ដេត និងជាមួយពួកគេនូវកំណែកម្មវិធីដែលបានដំឡើង)។
• “អ្វីៗដំណើរការសម្រាប់ខ្ញុំក្នុងស្រុក!” (... និងអ្នកអភិវឌ្ឍន៍មិនត្រូវបានអនុញ្ញាតិឱ្យផលិត។ )
• អ្នកត្រូវពិនិត្យមើលអ្វីមួយនៅក្នុងកំណែចាស់ (ទុកក្នុងប័ណ្ណសារ)។
• ...

ខ្លឹមសារទូទៅរបស់ពួកគេបានពុះកញ្ជ្រោលទៅនឹងការពិតដែលថាការអនុលោមតាមច្បាប់ពេញលេញនៃបរិស្ថានដែលបានប្រើ (ក៏ដូចជាអវត្តមាននៃកត្តាមនុស្ស) គឺចាំបាច់។ តើយើងអាចធានាការបន្តពូជដោយរបៀបណា? បង្កើតរូបភាព Docker ផ្អែកលើកូដពី Git ហើយបន្ទាប់មកប្រើពួកវាសម្រាប់កិច្ចការណាមួយ៖ នៅលើគេហទំព័រសាកល្បង ការផលិត លើម៉ាស៊ីនក្នុងស្រុករបស់អ្នកសរសេរកម្មវិធី... ក្នុងពេលជាមួយគ្នានេះ វាជាការសំខាន់ក្នុងការកាត់បន្ថយសកម្មភាពដែលត្រូវបានអនុវត្ត។ после ការផ្គុំរូបភាព៖ កាន់តែសាមញ្ញ វាទំនងជាមានកំហុសតិច។

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

ប្រសិនបើតម្រូវការហេដ្ឋារចនាសម្ព័ន្ធ (ភាពអាចរកបាននៃកម្មវិធីម៉ាស៊ីនមេ កំណែរបស់វា ។ ឧទាហរណ៍ នៅក្នុងដំណាក់កាល អ្នកបានប្តូរទៅ PHP 7.0 ហើយសរសេរកូដឡើងវិញតាមនោះ - បន្ទាប់មករូបរាងរបស់វានៅក្នុងការផលិតជាមួយនឹង PHP ចាស់មួយចំនួន (5.5) ពិតជានឹងធ្វើឱ្យនរណាម្នាក់ភ្ញាក់ផ្អើល។ អ្នកប្រហែលជាមិនភ្លេចអំពីការផ្លាស់ប្តូរដ៏សំខាន់នៅក្នុងកំណែអ្នកបកប្រែនោះទេ ប៉ុន្តែ "អារក្សគឺនៅក្នុងព័ត៌មានលម្អិត"៖ ការភ្ញាក់ផ្អើលអាចស្ថិតនៅក្នុងការអាប់ដេតតិចតួចនៃភាពអាស្រ័យណាមួយ។

វិធីសាស្រ្តក្នុងការដោះស្រាយបញ្ហានេះត្រូវបានគេស្គាល់ថាជា IaC (Infrastructure as Code, “infrastructure as code”) និងពាក់ព័ន្ធនឹងការរក្សាទុកតម្រូវការហេដ្ឋារចនាសម្ព័ន្ធ រួមជាមួយនឹងកូដកម្មវិធី។ ដោយប្រើវា អ្នកអភិវឌ្ឍន៍ និងអ្នកឯកទេស DevOps អាចធ្វើការជាមួយឃ្លាំងកម្មវិធី Git ដូចគ្នា ប៉ុន្តែនៅលើផ្នែកផ្សេងៗរបស់វា។ ពីកូដនេះ រូបភាព Docker ត្រូវបានបង្កើតនៅក្នុង Git ដែលកម្មវិធីត្រូវបានដាក់ពង្រាយដោយគិតគូរពីភាពជាក់លាក់ទាំងអស់នៃហេដ្ឋារចនាសម្ព័ន្ធ។ និយាយឱ្យសាមញ្ញ ស្គ្រីប (ច្បាប់) សម្រាប់ការផ្គុំរូបភាពគួរតែស្ថិតនៅក្នុងឃ្លាំងតែមួយជាមួយកូដប្រភព ហើយបញ្ចូលគ្នាជាមួយគ្នា។

ក្នុងករណីស្ថាបត្យកម្មកម្មវិធីពហុស្រទាប់ - ឧទាហរណ៍មាន nginx ដែលឈរនៅពីមុខកម្មវិធីដែលកំពុងដំណើរការរួចហើយនៅក្នុងធុង Docker - រូបភាព Docker ត្រូវតែបង្កើតចេញពីកូដនៅក្នុង Git សម្រាប់ស្រទាប់នីមួយៗ។ បន្ទាប់មករូបភាពទីមួយនឹងមានកម្មវិធីដែលមានអ្នកបកប្រែ និងភាពអាស្រ័យ "បិទ" ផ្សេងទៀត ហើយរូបភាពទីពីរនឹងមាន nginx ខាងលើ។

រូបភាព Docker ការទំនាក់ទំនងជាមួយ Git

យើងបែងចែករូបភាព Docker ទាំងអស់ដែលប្រមូលបានពី Git ជាពីរប្រភេទ៖ បណ្តោះអាសន្ន និងចេញផ្សាយ។ រូបភាពបណ្តោះអាសន្ន ដាក់ស្លាកដោយឈ្មោះសាខានៅក្នុង Git អាចត្រូវបានសរសេរជាន់លើដោយការប្តេជ្ញាចិត្តបន្ទាប់ ហើយត្រូវបានចេញផ្សាយសម្រាប់តែការមើលជាមុនប៉ុណ្ណោះ (មិនមែនសម្រាប់ផលិតទេ)។ នេះគឺជាភាពខុសគ្នាដ៏សំខាន់របស់ពួកគេពីការចេញផ្សាយ៖ អ្នកមិនដឹងថាការប្តេជ្ញាចិត្តជាក់លាក់ណាមួយនៅក្នុងពួកគេ។

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

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

ដាប

អ្វីគ្រប់យ៉ាងដែលបានពិពណ៌នា (ការចេញផ្សាយ ការផ្គុំរូបភាព ការថែទាំជាបន្តបន្ទាប់) អាចត្រូវបានអនុវត្តដោយឯករាជ្យដោយប្រើស្គ្រីប Bash និងឧបករណ៍ "improvised" ផ្សេងទៀត។ ប៉ុន្តែប្រសិនបើអ្នកធ្វើបែបនេះ នោះនៅពេលណាមួយ ការអនុវត្តនឹងនាំឱ្យមានភាពស្មុគស្មាញខ្លាំង និងការគ្រប់គ្រងមិនល្អ។ ដោយយល់អំពីបញ្ហានេះ យើងបានមកបង្កើតឧបករណ៍ប្រើប្រាស់លំហូរការងារពិសេសផ្ទាល់ខ្លួនរបស់យើងសម្រាប់បង្កើត CI/CD - ដាប.

កូដប្រភពរបស់វាត្រូវបានសរសេរជា Ruby ដែលជាប្រភពបើកចំហ និងបោះពុម្ពនៅលើ GitHub. ជាអកុសល បច្ចុប្បន្នឯកសារគឺជាចំណុចខ្សោយបំផុតនៃឧបករណ៍ ប៉ុន្តែយើងកំពុងធ្វើការលើវា។ ហើយយើងនឹងសរសេរនិងនិយាយអំពី dapp ច្រើនជាងម្តងព្រោះ ... យើងមិនអាចរង់ចាំដោយស្មោះដើម្បីចែករំលែកសមត្ថភាពរបស់វាជាមួយសហគមន៍ដែលចាប់អារម្មណ៍ទាំងមូលនោះទេ ប៉ុន្តែក្នុងពេលនេះ សូមផ្ញើបញ្ហារបស់អ្នក និងទាញសំណើ និង/ឬតាមដានការអភិវឌ្ឍន៍គម្រោងនៅលើ GitHub ។

បានធ្វើបច្ចុប្បន្នភាពថ្ងៃទី 13 ខែសីហា ឆ្នាំ 2019៖ បច្ចុប្បន្នជាគម្រោង ដាប បានប្តូរឈ្មោះទៅជា werfលេខកូដរបស់វាត្រូវបានសរសេរឡើងវិញទាំងស្រុងនៅក្នុង Go ហើយឯកសាររបស់វាត្រូវបានធ្វើឱ្យប្រសើរឡើងយ៉ាងខ្លាំង។

Kubernetes

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

សម្រាប់ការដាក់ឱ្យដំណើរការ Kubernetes ផ្តល់ជូន៖

• ការស៊ើបអង្កេតការត្រៀមខ្លួន - ពិនិត្យមើលការត្រៀមខ្លួននៃកំណែថ្មីនៃកម្មវិធី (ដើម្បីប្តូរចរាចរណ៍ទៅវា);
• ការធ្វើបច្ចុប្បន្នភាពរំកិល - ការធ្វើបច្ចុប្បន្នភាពរូបភាពជាបន្តបន្ទាប់នៅក្នុងចង្កោមនៃធុង (ការបិទ, ធ្វើឱ្យទាន់សម័យ, ការរៀបចំសម្រាប់ការចាប់ផ្តើម, ការប្តូរចរាចរណ៍);
• ការធ្វើបច្ចុប្បន្នភាពសមកាលកម្ម - ការធ្វើបច្ចុប្បន្នភាពរូបភាពនៅក្នុងចង្កោមជាមួយនឹងវិធីសាស្រ្តផ្សេងគ្នា: ដំបូងនៅលើពាក់កណ្តាលនៃធុងបន្ទាប់មកនៅលើនៅសល់;
• ការចេញផ្សាយ Canary - ចាប់ផ្តើមរូបភាពថ្មីនៅលើធុងដែលមានកំណត់ (តូច) ដើម្បីតាមដានភាពមិនប្រក្រតី។

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

អនុសាសន៍ចុងក្រោយ

1. ប្រើ Docker ។
2. បង្កើតរូបភាព Docker នៃកម្មវិធីសម្រាប់គ្រប់តម្រូវការរបស់អ្នក។
3. អនុវត្តតាមគោលការណ៍ "ហេដ្ឋារចនាសម្ព័ន្ធគឺជាកូដ" ។
4. ភ្ជាប់ Git ទៅ Docker ។
5. គ្រប់គ្រងលំដាប់នៃការចេញផ្សាយ។
6. ប្រើវេទិកាដែលត្រៀមរួចជាស្រេច (Kubernetes ឬមួយផ្សេងទៀត)។

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

វីដេអូពីការសម្តែង (ប្រហែលមួយម៉ោង) ផ្សព្វផ្សាយនៅលើ YouTube (របាយការណ៍ខ្លួនវាចាប់ផ្តើមពីនាទីទី 5 - ធ្វើតាមតំណដើម្បីលេងចាប់ពីពេលនេះ).

បទបង្ហាញនៃរបាយការណ៍៖

PS

របាយការណ៍ផ្សេងទៀតលើប្រធានបទនៅលើប្លក់របស់យើង៖

• «werf - ឧបករណ៍របស់យើងសម្រាប់ CI / CD នៅក្នុង Kubernetes (ទិដ្ឋភាពទូទៅ និងរបាយការណ៍វីដេអូ)» (Dmitry Stolyarov; ថ្ងៃទី 27 ខែឧសភា ឆ្នាំ 2019 នៅ DevOpsConf);
• «មូលដ្ឋានទិន្នន័យ និង Kubernetes» (Dmitry Stolyarov; ថ្ងៃទី 8 ខែវិច្ឆិកាឆ្នាំ 2018 នៅលើ HighLoad ++);
• «CI/CD ការអនុវត្តល្អបំផុតជាមួយ Kubernetes និង GitLab» (Dmitry Stolyarov; ថ្ងៃទី 7 ខែវិច្ឆិកាឆ្នាំ 2017 នៅលើ HighLoad ++);
• «បទពិសោធន៍របស់យើងជាមួយ Kubernetes ក្នុងគម្រោងតូចៗ» (Dmitry Stolyarov; ថ្ងៃទី 6 ខែមិថុនា ឆ្នាំ 2017 នៅ RootConf).

ប្រភព: www.habr.com