werf - ឧបករណ៍របស់យើងសម្រាប់ CI / CD នៅក្នុង Kubernetes (ទិដ្ឋភាពទូទៅ និងរបាយការណ៍វីដេអូ)

ថ្ងៃទី 27 ខែឧសភា នៅសាលធំនៃសន្និសីទ DevOpsConf 2019 ដែលប្រារព្ធឡើងជាផ្នែកនៃពិធីបុណ្យ RIT++ 2019ជាផ្នែកនៃផ្នែក "ការចែកចាយបន្ត" របាយការណ៍មួយត្រូវបានផ្តល់ឱ្យ "werf - ឧបករណ៍របស់យើងសម្រាប់ CI/CD នៅក្នុង Kubernetes" ។ វានិយាយអំពីរឿងទាំងនោះ បញ្ហា​និង​បញ្ហា​ប្រឈម​ដែល​អ្នក​រាល់​គ្នា​ប្រឈម​មុខ​នៅ​ពេល​ដាក់​ពង្រាយ​ទៅ Kubernetesក៏ដូចជាអំពីការ nuances ដែលអាចមិនគួរឱ្យកត់សម្គាល់ភ្លាមៗ។ ការវិភាគដំណោះស្រាយដែលអាចកើតមាន យើងបង្ហាញពីរបៀបដែលវាត្រូវបានអនុវត្តនៅក្នុងឧបករណ៍ប្រភពបើកចំហ werf.

ចាប់តាំងពីការធ្វើបទបង្ហាញ ឧបករណ៍ប្រើប្រាស់របស់យើង (ពីមុនត្រូវបានគេស្គាល់ថាជា dapp) បានឈានដល់ចំណុចសំខាន់ជាប្រវត្តិសាស្ត្រនៃ ផ្កាយ 1000 នៅលើ GitHub — យើងសង្ឃឹមថាសហគមន៍អ្នកប្រើប្រាស់ដែលកំពុងកើនឡើងនឹងធ្វើឱ្យជីវិតកាន់តែងាយស្រួលសម្រាប់វិស្វករ DevOps ជាច្រើន។

ដូច្នេះសូមណែនាំ វីដេអូនៃរបាយការណ៍ (~៤៧ នាទី ផ្តល់ព័ត៌មានច្រើនជាងអត្ថបទ) និងការដកស្រង់សំខាន់ពីវាក្នុងទម្រង់ជាអត្ថបទ។ ទៅ!

បញ្ជូនលេខកូដទៅ Kubernetes

ការពិភាក្សានឹងលែងនិយាយអំពី werf ទៀតហើយ ប៉ុន្តែអំពី CI/CD នៅក្នុង Kubernetes ដោយបញ្ជាក់ថាកម្មវិធីរបស់យើងត្រូវបានខ្ចប់នៅក្នុង Docker containers (ខ្ញុំបាននិយាយអំពីរឿងនេះនៅក្នុង របាយការណ៍ឆ្នាំ 2016)ហើយ K8s នឹងត្រូវបានប្រើដើម្បីដំណើរការវានៅក្នុងផលិតកម្ម (បន្ថែមទៀតអំពីរឿងនេះនៅក្នុង ឆ្នាំ 2017).

តើការដឹកជញ្ជូនមើលទៅដូចអ្វីនៅក្នុង Kubernetes?

• មានឃ្លាំង Git ដែលមានលេខកូដ និងការណែនាំសម្រាប់សាងសង់វា។ កម្មវិធីនេះត្រូវបានបង្កើតឡើងជារូបភាព Docker ហើយត្រូវបានបោះពុម្ពនៅក្នុង Docker Registry ។
• ឃ្លាំងដូចគ្នាក៏មានការណែនាំអំពីរបៀបដាក់ពង្រាយ និងដំណើរការកម្មវិធីផងដែរ។ នៅដំណាក់កាលដាក់ពង្រាយ ការណែនាំទាំងនេះត្រូវបានផ្ញើទៅកាន់ Kubernetes ដែលទទួលរូបភាពដែលចង់បានពីបញ្ជីឈ្មោះ ហើយបើកដំណើរការវា។
• លើសពីនេះទៀតជាធម្មតាមានការធ្វើតេស្ត។ ទាំងនេះខ្លះអាចធ្វើបាននៅពេលបោះពុម្ពរូបភាព។ អ្នកក៏អាច (ធ្វើតាមការណែនាំដូចគ្នា) ដាក់ពង្រាយច្បាប់ចម្លងនៃកម្មវិធី (នៅក្នុង namespace K8s ឬចង្កោមដាច់ដោយឡែក) ហើយដំណើរការការធ្វើតេស្តនៅទីនោះ។
• ចុងក្រោយ អ្នកត្រូវការប្រព័ន្ធ CI ដែលទទួលព្រឹត្តិការណ៍ពី Git (ឬការចុចប៊ូតុង) ហើយហៅដំណាក់កាលដែលបានកំណត់ទាំងអស់៖ បង្កើត បោះពុម្ព ពង្រាយ សាកល្បង។

មានកំណត់ចំណាំសំខាន់ៗមួយចំនួននៅទីនេះ៖

1. ដោយសារតែយើងមានហេដ្ឋារចនាសម្ព័ន្ធដែលមិនអាចផ្លាស់ប្តូរបាន។ (ហេដ្ឋារចនាសម្ព័ន្ធដែលមិនអាចផ្លាស់ប្តូរបាន)រូបភាពកម្មវិធីដែលប្រើនៅគ្រប់ដំណាក់កាល (ដំណាក់កាល ការផលិត។ ត្រូវតែមានមួយ។. ខ្ញុំបាននិយាយអំពីរឿងនេះឱ្យបានលំអិត និងជាមួយឧទាហរណ៍។ នៅទីនេះ.
2. ដោយសារតែយើងធ្វើតាមហេដ្ឋារចនាសម្ព័ន្ធជាវិធីសាស្រ្តកូដ (IaC), កូដកម្មវិធី សេចក្តីណែនាំសម្រាប់ការប្រមូលផ្តុំ និងការបើកដំណើរការវាគួរតែជា យ៉ាងពិតប្រាកដនៅក្នុងឃ្លាំងមួយ។. សម្រាប់ព័ត៌មានបន្ថែមអំពីរឿងនេះ សូមមើល របាយការណ៍ដដែល.
3. ខ្សែសង្វាក់ដឹកជញ្ជូន (ការដឹកជញ្ជូន) ជាធម្មតាយើងឃើញវាដូចនេះ៖ កម្មវិធីត្រូវបានប្រមូលផ្តុំ សាកល្បង ចេញផ្សាយ (ដំណាក់កាលចេញផ្សាយ) ហើយនោះហើយជាវា - ការដឹកជញ្ជូនបានកើតឡើង។ ប៉ុន្តែតាមពិត អ្នកប្រើប្រាស់ទទួលបានអ្វីដែលអ្នកបានបញ្ចេញ។ មិនមាន ពេល​ដែល​អ្នក​បញ្ជូន​វា​ទៅ​ផលិតកម្ម ហើយ​ពេល​ដែល​គាត់​អាច​ទៅ​ទីនោះ ហើយ​ផលិតកម្ម​នេះ​ដំណើរការ។ ដូច្នេះ​ខ្ញុំ​ជឿ​ថា​ខ្សែ​សង្វាក់​ដឹក​ជញ្ជូន​ត្រូវ​បញ្ចប់ មានតែនៅដំណាក់កាលប្រតិបត្តិការប៉ុណ្ណោះ។ (រត់)ឬច្បាស់ជាងនេះទៅទៀត សូម្បីតែនៅពេលនេះនៅពេលដែលលេខកូដត្រូវបានដកចេញពីការផលិត (ជំនួសវាដោយលេខកូដថ្មី)។

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

ដំណាក់កាលសាងសង់

វាហាក់ដូចជាអ្នកអាចនិយាយអំពីការបង្កើតរូបភាព Docker នៅឆ្នាំ 2019 នៅពេលដែលមនុស្សគ្រប់គ្នាដឹងពីរបៀបសរសេរ Dockerfiles និងដំណើរការ។ docker build?.. ខាងក្រោមនេះជាចំនុចដែលខ្ញុំចង់យកចិត្តទុកដាក់៖

1. ទម្ងន់រូបភាព សំខាន់ ដូច្នេះប្រើ ពហុដំណាក់កាលដើម្បីទុកក្នុងរូបភាពតែកម្មវិធីដែលពិតជាចាំបាច់សម្រាប់ប្រតិបត្តិការ។
2. ចំនួនស្រទាប់ ត្រូវតែត្រូវបានបង្រួមអប្បបរមាដោយការរួមបញ្ចូលខ្សែសង្វាក់នៃ RUN- បញ្ជាដោយអត្ថន័យ។
3. ទោះជាយ៉ាងណាក៏ដោយនេះបន្ថែមបញ្ហា ការកែកំហុស, ដោយសារតែនៅពេលដែលការជួបប្រជុំគ្នាគាំង, អ្នកត្រូវតែស្វែងរកពាក្យបញ្ជាត្រឹមត្រូវពីខ្សែសង្វាក់ដែលបណ្តាលឱ្យមានបញ្ហា។
4. ល្បឿនដំឡើង សំខាន់ព្រោះយើងចង់បញ្ចេញការផ្លាស់ប្តូរយ៉ាងឆាប់រហ័ស និងឃើញលទ្ធផល។ ឧទាហរណ៍ អ្នកមិនចង់បង្កើតភាពអាស្រ័យនៅក្នុងបណ្ណាល័យភាសាឡើងវិញទេ រាល់ពេលដែលអ្នកបង្កើតកម្មវិធី។
5. ជាញឹកញាប់ពីឃ្លាំង Git មួយដែលអ្នកត្រូវការ រូបភាពជាច្រើន។ដែលអាចត្រូវបានដោះស្រាយដោយសំណុំនៃ Dockerfiles (ឬដាក់ឈ្មោះដំណាក់កាលក្នុងឯកសារមួយ) និងស្គ្រីប Bash ជាមួយនឹងការជួបប្រជុំគ្នាជាបន្តបន្ទាប់របស់ពួកគេ។

នេះគ្រាន់តែជាចុងផ្ទាំងទឹកកក ដែលមនុស្សគ្រប់គ្នាប្រឈមមុខ។ ប៉ុន្តែមានបញ្ហាផ្សេងទៀតជាពិសេស៖

1. ជាញឹកញាប់នៅដំណាក់កាលជួបប្រជុំគ្នាយើងត្រូវការអ្វីមួយ ម៉ោន (ឧទាហរណ៍ រក្សាទុកលទ្ធផលនៃពាក្យបញ្ជាដូចជា apt នៅក្នុងថតភាគីទីបី)។
2. យើងចង់បាន Ansible ជំនួសឱ្យការសរសេរនៅក្នុងសែល។
3. យើងចង់បាន សាងសង់ដោយគ្មាន Docker (ហេតុអ្វីបានជាយើងត្រូវការម៉ាស៊ីននិម្មិតបន្ថែម ដែលយើងត្រូវកំណត់រចនាសម្ព័ន្ធអ្វីគ្រប់យ៉ាងសម្រាប់វា នៅពេលដែលយើងមានចង្កោម Kubernetes ដែលយើងអាចដំណើរការកុងតឺន័ររួចហើយ?)
4. ការផ្គុំប៉ារ៉ាឡែលដែលអាចយល់បានតាមវិធីផ្សេងៗគ្នា៖ ពាក្យបញ្ជាផ្សេងៗគ្នាពី Dockerfile (ប្រសិនបើមានច្រើនដំណាក់កាលត្រូវបានប្រើ) ការប្តេជ្ញាចិត្តជាច្រើននៃឃ្លាំងដូចគ្នា Dockerfiles ជាច្រើន។
5. ការជួបប្រជុំគ្នាចែកចាយ៖ យើង​ចង់​ប្រមូល​របស់​របរ​ក្នុង​ផត​ដែល​មាន​លក្ខណៈ​«​មិន​ចេះ​ចប់​»​ព្រោះ​ ឃ្លាំងសម្ងាត់របស់ពួកគេបាត់ ដែលមានន័យថាវាត្រូវរក្សាទុកនៅកន្លែងណាមួយដាច់ដោយឡែក។
6. ទីបំផុតខ្ញុំបានដាក់ឈ្មោះកំពូលនៃសេចក្តីប្រាថ្នា ស្វ័យប្រវត្តិកម្ម៖ វាជាការល្អក្នុងការចូលទៅកាន់ឃ្លាំង វាយពាក្យបញ្ជាមួយចំនួន និងទទួលបានរូបភាពដែលត្រៀមរួចជាស្រេច ប្រមូលផ្តុំដោយការយល់ដឹងអំពីរបៀប និងអ្វីដែលត្រូវធ្វើឱ្យបានត្រឹមត្រូវ។ ទោះជាយ៉ាងណាក៏ដោយ ខ្ញុំផ្ទាល់មិនប្រាកដថា nuances ទាំងអស់អាចត្រូវបានគេមើលឃើញទុកជាមុនតាមវិធីនេះទេ។

ហើយនេះគឺជាគម្រោង៖

• ឧបករណ៍ចល័ត / កញ្ចប់សាងសង់ - អ្នកសាងសង់មកពី Docker Inc (បានរួមបញ្ចូលទៅក្នុងកំណែបច្ចុប្បន្នរបស់ Docker) ដែលកំពុងតែព្យាយាមដោះស្រាយបញ្ហាទាំងអស់នេះ។
• កានីកូ - អ្នកសាងសង់ពី Google ដែលអនុញ្ញាតឱ្យអ្នកបង្កើតដោយគ្មាន Docker;
• Buildpacks.io - ការប៉ុនប៉ងរបស់ CNCF ដើម្បីបង្កើតវេទមន្តដោយស្វ័យប្រវត្តិ និងជាពិសេសដំណោះស្រាយគួរឱ្យចាប់អារម្មណ៍ជាមួយនឹងការដាក់ឡើងវិញសម្រាប់ស្រទាប់។
• និងឧបករណ៍ប្រើប្រាស់ផ្សេងៗទៀតដូចជា ស្ថាបនា, truetools/img...

... ហើយមើលថាតើពួកគេមានតារាប៉ុន្មាននាក់នៅលើ GitHub ។ នោះគឺនៅលើដៃម្ខាង។ docker build មានហើយអាចធ្វើអ្វីមួយបាន ប៉ុន្តែការពិត បញ្ហាមិនត្រូវបានដោះស្រាយទាំងស្រុងទេ។ - ភ័ស្តុតាងនៃនេះគឺជាការអភិវឌ្ឍន៍ស្របគ្នានៃអ្នកប្រមូលជំនួស ដែលផ្នែកនីមួយៗដោះស្រាយបញ្ហាមួយចំនួន។

ការជួបប្រជុំគ្នានៅក្នុង werf

ដូច្នេះយើងត្រូវតែ werf (ពីមុន ល្បី ដូចជា dapp) - ឧបករណ៍ប្រើប្រាស់ប្រភពបើកចំហពីក្រុមហ៊ុន Flant ដែលយើងបានបង្កើតអស់រយៈពេលជាច្រើនឆ្នាំ។ វាទាំងអស់បានចាប់ផ្តើមកាលពី 5 ឆ្នាំមុនជាមួយនឹងស្គ្រីប Bash ដែលធ្វើអោយប្រសើរឡើងនូវការជួបប្រជុំគ្នានៃ Dockerfiles ហើយសម្រាប់រយៈពេល 3 ឆ្នាំចុងក្រោយនេះ ការអភិវឌ្ឍន៍ពេញលេញត្រូវបានអនុវត្តនៅក្នុងក្របខ័ណ្ឌនៃគម្រោងមួយជាមួយនឹងឃ្លាំង Git ផ្ទាល់របស់វា។ (ដំបូងនៅ Ruby ហើយបន្ទាប់មក សរសេរឡើងវិញ ទៅ ហើយក្នុងពេលតែមួយប្តូរឈ្មោះ). តើបញ្ហាការជួបប្រជុំគ្នាអ្វីខ្លះត្រូវបានដោះស្រាយនៅក្នុង werf?

បញ្ហាដែលមានស្រមោលពណ៌ខៀវត្រូវបានអនុវត្តរួចហើយ ការសាងសង់ស្របគ្នាត្រូវបានធ្វើឡើងនៅក្នុងម៉ាស៊ីនតែមួយ ហើយបញ្ហាដែលបន្លិចជាពណ៌លឿងត្រូវបានគ្រោងនឹងបញ្ចប់នៅចុងរដូវក្តៅ។

ដំណាក់កាលនៃការបោះពុម្ពផ្សាយក្នុងបញ្ជីឈ្មោះ (បោះពុម្ព)

យើងបានចុច docker push... - តើ​អ្វី​អាច​ជា​ការ​លំបាក​ក្នុង​ការ​ផ្ទុក​ឡើង​រូបភាព​ទៅ​បញ្ជី​ឈ្មោះ? ហើយបន្ទាប់មកសំណួរកើតឡើង: "តើខ្ញុំគួរដាក់ស្លាកអ្វីនៅលើរូបភាព?" វាកើតឡើងដោយហេតុផលដែលយើងមាន លំហូរ (ឬយុទ្ធសាស្រ្ត Git ផ្សេងទៀត) និង Kubernetes ហើយឧស្សាហកម្មកំពុងព្យាយាមធានាថាអ្វីដែលកើតឡើងនៅក្នុង Kubernetes ធ្វើតាមអ្វីដែលកើតឡើងនៅក្នុង Git ។ យ៉ាងណាមិញ Git គឺជាប្រភពនៃការពិតតែមួយគត់របស់យើង។

តើ​មាន​អ្វី​ពិបាក​យ៉ាង​នេះ? ធានាការបន្តពូជ៖ ពីការប្តេជ្ញាចិត្តនៅក្នុង Git ដែលមិនអាចផ្លាស់ប្តូរបាននៅក្នុងធម្មជាតិ (មិនអាចផ្លាស់ប្តូរបាន)ទៅកាន់រូបភាព Docker ដែលគួររក្សាទុកដូចគ្នា។

វាក៏សំខាន់ផងដែរចំពោះយើង កំណត់ប្រភពដើមដោយ​សារ​តែ​យើង​ចង់​យល់​ថា​កម្មវិធី​ដែល​ដំណើរការ​នៅ​ក្នុង Kubernetes ត្រូវ​បាន​បង្កើត​ឡើង​ពី​ណា​មក​ហើយ (បន្ទាប់​មក​យើង​អាច​ធ្វើ​ការ​ខុស​គ្នា និង​អ្វី​ដែល​ស្រដៀង​គ្នា)។

យុទ្ធសាស្ត្រដាក់ស្លាក

ទីមួយគឺសាមញ្ញ ស្លាក git. យើង​មាន​បញ្ជី​ឈ្មោះ​ដែល​មាន​រូបភាព​ដែល​បាន​ដាក់​ស្លាក​ជា​ 1.0. Kubernetes មានដំណាក់កាល និងផលិតកម្ម ដែលរូបភាពនេះត្រូវបានបង្ហោះ។ នៅក្នុង Git យើងធ្វើការសន្យា ហើយនៅចំណុចខ្លះយើងដាក់ស្លាក 2.0. យើងប្រមូលវាតាមការណែនាំពីឃ្លាំងហើយដាក់វានៅក្នុងបញ្ជីឈ្មោះជាមួយស្លាក 2.0. យើង​រមៀល​វា​ចេញ​ទៅ​ឆាក ហើយ​ប្រសិន​បើ​ល្អ​នោះ​ទៅ​ផលិតកម្ម។

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

ជម្រើសទីពីរគឺ។ git commit + tag. សាខាមេមានស្លាក 1.0; សម្រាប់វានៅក្នុងបញ្ជីឈ្មោះ - រូបភាពដែលត្រូវបានដាក់ពង្រាយទៅផលិតកម្ម។ លើសពីនេះ ចង្កោម Kubernetes មានការមើលជាមុន និងទម្រង់ដំណាក់កាល។ បន្ទាប់យើងធ្វើតាម Gitflow: នៅក្នុងសាខាចម្បងសម្រាប់ការអភិវឌ្ឍន៍ (develop) យើងបង្កើតមុខងារថ្មីៗ ដែលបណ្តាលឱ្យមានការប្តេជ្ញាចិត្តជាមួយឧបករណ៍កំណត់អត្តសញ្ញាណ #c1. យើងប្រមូលវា ហើយបោះផ្សាយវានៅក្នុងបញ្ជីឈ្មោះដោយប្រើឧបករណ៍សម្គាល់នេះ (#c1) ជា​មួយ​នឹង​ការ​កំណត់​អត្តសញ្ញាណ​ដូច​គ្នា​នេះ​ដែរ យើង​ចេញ​ដើម្បី​មើល​ជា​មុន​។ យើងធ្វើដូចគ្នាជាមួយនឹងការសន្យា #c2 и #c3.

ពេល​យើង​ដឹង​ថា​មាន​លក្ខណៈ​គ្រប់គ្រាន់ យើង​ចាប់​ផ្ដើម​ធ្វើ​ឲ្យ​អ្វីៗ​មាន​ស្ថិរភាព។ បង្កើតសាខានៅក្នុង Git release_1.1 (នៅលើមូលដ្ឋាន #c3 ពី develop) មិនចាំបាច់ប្រមូលការចេញផ្សាយនេះទេព្រោះ ... នេះត្រូវបានធ្វើនៅជំហានមុន។ ដូច្នេះ យើង​អាច​ទាញ​វា​ចេញ​ទៅ​វគ្គ​បន្ត។ យើងជួសជុលកំហុសនៅក្នុង #c4 ហើយស្រដៀងគ្នានេះដែរ ចាប់ផ្តើមដំណើរការ។ ទន្ទឹមនឹងនោះ ការអភិវឌ្ឍន៍កំពុងដំណើរការ developដែលជាកន្លែងដែលការផ្លាស់ប្តូរត្រូវបានយកតាមកាលកំណត់ release_1.1. នៅចំណុចខ្លះ យើងទទួលបានពាក្យសន្យាមួយដែលបានចងក្រង និងបង្ហោះទៅកាន់ឆាក ដែលយើងសប្បាយចិត្តជាមួយ (#c25).

បន្ទាប់មកយើងបញ្ចូលគ្នា (ជាមួយការទៅមុខលឿន) សាខាចេញផ្សាយ (release_1.1) នៅក្នុងមេ។ យើងដាក់ស្លាកជាមួយកំណែថ្មីនៅលើការប្តេជ្ញាចិត្តនេះ (1.1) ប៉ុន្តែរូបភាពនេះត្រូវបានប្រមូលរួចហើយនៅក្នុងបញ្ជីឈ្មោះ ដូច្នេះដើម្បីកុំឱ្យប្រមូលវាម្តងទៀត យើងគ្រាន់តែបន្ថែមស្លាកទីពីរទៅរូបភាពដែលមានស្រាប់ (ឥឡូវនេះវាមានស្លាកនៅក្នុងបញ្ជីឈ្មោះ #c25 и 1.1) បន្ទាប់ពីនោះយើងរមៀលវាចេញទៅផលិតកម្ម។

មាន​គុណវិបត្តិ​ដែល​មាន​តែ​រូបភាព​មួយ​ប៉ុណ្ណោះ​ត្រូវ​បាន​ផ្ទុក​ឡើង​ទៅ​ឆាក (#c25) ហើយនៅក្នុងផលិតកម្មវាមានភាពខុសគ្នា (1.1) ប៉ុន្តែយើងដឹងថា "រាងកាយ" ទាំងនេះគឺជារូបភាពដូចគ្នាពីបញ្ជីឈ្មោះ។

គុណវិបត្តិពិតប្រាកដគឺថាមិនមានការគាំទ្រសម្រាប់ការបញ្ចូលគ្នាទេ អ្នកត្រូវតែធ្វើលឿនទៅមុខ។

យើង​អាច​បន្ត​ទៅ​មុខ​ទៀត​ហើយ​ធ្វើ​ល្បិច... តោះ​មើល​ឧទាហរណ៍​មួយ​នៃ Dockerfile សាមញ្ញ៖

FROM ruby:2.3 as assets
RUN mkdir -p /app
WORKDIR /app
COPY . ./
RUN gem install bundler && bundle install
RUN bundle exec rake assets:precompile
CMD bundle exec puma -C config/puma.rb

FROM nginx:alpine
COPY --from=assets /app/public /usr/share/nginx/www/public

ចូរយើងបង្កើតឯកសារមួយពីវាតាមគោលការណ៍ខាងក្រោម៖

• SHA256 ពីការកំណត់អត្តសញ្ញាណនៃរូបភាពដែលបានប្រើ (ruby:2.3 и nginx:alpine) ដែលជាមូលប្បទានប័ត្រនៃមាតិការបស់ពួកគេ;
• ក្រុមទាំងអស់ (RUN, CMD ល​ល។);
• SHA256 ពីឯកសារដែលត្រូវបានបន្ថែម។

... ហើយយក checksum (ម្តងទៀត SHA256) ពីឯកសារបែបនេះ។ នេះ។ ហត្ថលេខា អ្វីគ្រប់យ៉ាងដែលកំណត់មាតិកានៃរូបភាព Docker ។

ចូរយើងត្រលប់ទៅដ្យាក្រាមនិង ជំនួសឱ្យការសន្យា យើងនឹងប្រើហត្ថលេខាបែបនេះ, i.e. ស្លាករូបភាពដែលមានហត្ថលេខា។

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

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

ការដាក់ស្លាកនៅក្នុង werf

នៅក្នុង werf យើងបានទៅបន្ថែមទៀត ហើយកំពុងរៀបចំដើម្បីបង្កើតការចែកចាយជាមួយនឹងឃ្លាំងសម្ងាត់ដែលមិនត្រូវបានរក្សាទុកនៅលើម៉ាស៊ីនតែមួយ... ដូច្នេះយើងកំពុងបង្កើតរូបភាព Docker ពីរប្រភេទ យើងហៅវាថា ឆាក и រូបភាព.

ឃ្លាំង werf Git រក្សាទុកការណែនាំជាក់លាក់នៃការសាងសង់ ដែលពិពណ៌នាអំពីដំណាក់កាលផ្សេងៗគ្នានៃការសាងសង់ (មុនពេលដំឡើង, ដំឡើង, មុនពេលដំឡើង, ការដំឡើង) យើងប្រមូលរូបភាពដំណាក់កាលដំបូងដែលមានហត្ថលេខាកំណត់ថាជា checksum នៃជំហានដំបូង។ បន្ទាប់មក យើងបន្ថែមកូដប្រភព សម្រាប់រូបភាពដំណាក់កាលថ្មី យើងគណនា checksum របស់វា... ប្រតិបត្តិការទាំងនេះត្រូវបានធ្វើម្តងទៀតសម្រាប់ដំណាក់កាលទាំងអស់ ជាលទ្ធផលយើងទទួលបានសំណុំរូបភាពដំណាក់កាល។ បន្ទាប់មកយើងបង្កើតរូបភាពចុងក្រោយ ដែលមានទិន្នន័យមេតាអំពីប្រភពដើមរបស់វាផងដែរ។ ហើយយើងដាក់ស្លាករូបភាពនេះតាមវិធីផ្សេងៗគ្នា (ព័ត៌មានលម្អិតនៅពេលក្រោយ)។

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

ដូច្នេះ រូបភាពដំណាក់កាលគឺជាឃ្លាំងសម្ងាត់ដែលអាចត្រូវបានរក្សាទុកយ៉ាងចែកចាយ ហើយរូបភាពដែលបានបង្កើតរួចហើយពីវាត្រូវបានផ្ទុកឡើងទៅកាន់ Docker Registry ។

ការសម្អាតបញ្ជីឈ្មោះ

យើងមិននិយាយអំពីការលុបស្រទាប់ដែលនៅតែព្យួរបន្ទាប់ពីការលុបស្លាកទេ - នេះគឺជាលក្ខណៈស្តង់ដារនៃ Docker Registry ខ្លួនវាផ្ទាល់។ យើងកំពុងនិយាយអំពីស្ថានភាពមួយនៅពេលដែលស្លាក Docker ច្រើនកកកុញ ហើយយើងយល់ថាយើងលែងត្រូវការពួកវាមួយចំនួនទៀតហើយ ប៉ុន្តែពួកគេយកកន្លែងទំនេរ (និង/ឬយើងចំណាយសម្រាប់វា)។

តើយុទ្ធសាស្ត្រសម្អាតអ្វីខ្លះ?

1. អ្នកគ្រាន់តែមិនអាចធ្វើអ្វីបានទេ។ មិនសម្អាត. ពេលខ្លះ វាពិតជាងាយស្រួលក្នុងការចំណាយតិចតួចសម្រាប់ទំហំបន្ថែម ជាជាងការស្រាយស្លាកដែលមានភាពច្របូកច្របល់។ ប៉ុន្តែ​វា​ដំណើរការ​ត្រឹម​ចំណុច​ជាក់លាក់​មួយ​ប៉ុណ្ណោះ។
2. កំណត់ឡើងវិញពេញលេញ. ប្រសិនបើអ្នកលុបរូបភាពទាំងអស់ ហើយបង្កើតឡើងវិញតែរូបភាពបច្ចុប្បន្ននៅក្នុងប្រព័ន្ធ CI នោះបញ្ហាអាចនឹងកើតឡើង។ ប្រសិនបើកុងតឺន័រត្រូវបានចាប់ផ្តើមឡើងវិញនៅក្នុងផលិតកម្ម រូបភាពថ្មីនឹងត្រូវបានផ្ទុកសម្រាប់វា - មួយដែលមិនទាន់ត្រូវបានសាកល្បងដោយនរណាម្នាក់។ នេះសម្លាប់គំនិតនៃហេដ្ឋារចនាសម្ព័ន្ធដែលមិនអាចផ្លាស់ប្តូរបាន។
3. ខៀវបៃតង. បញ្ជីឈ្មោះមួយចាប់ផ្តើមហៀរ - យើងផ្ទុករូបភាពទៅមួយទៀត។ បញ្ហាដូចគ្នានឹងវិធីសាស្ត្រមុន៖ តើអ្នកអាចជម្រះបញ្ជីឈ្មោះដែលចាប់ផ្តើមហៀរចេញនៅពេលណា?
4. តាមពេលវេលា. លុបរូបភាពទាំងអស់ដែលចាស់ជាង 1 ខែ? ប៉ុន្តែ​ច្បាស់​ជា​នឹង​មាន​សេវា​មួយ​ដែល​មិន​ទាន់​បាន​អាប់ដេត​រយៈពេល​មួយ​ខែ…
5. ដោយដៃ កំណត់អ្វីដែលអាចត្រូវបានលុបរួចហើយ។

មាន​ជម្រើស​ពីរ​ដែល​អាច​ប្រើ​បាន​យ៉ាង​ពិត​ប្រាកដ៖ មិន​ត្រូវ​សម្អាត ឬ​ការ​ផ្សំ​ពណ៌​ខៀវ​បៃតង + ដោយដៃ។ ក្នុងករណីចុងក្រោយនេះ យើងកំពុងនិយាយអំពីចំណុចខាងក្រោម៖ នៅពេលដែលអ្នកយល់ថាវាដល់ពេលដែលត្រូវសម្អាតបញ្ជីឈ្មោះ អ្នកបង្កើតថ្មីមួយ ហើយបន្ថែមរូបភាពថ្មីទាំងអស់ទៅវាក្នុងអំឡុងមួយខែ ឧទាហរណ៍ដូចជាមួយខែ។ ហើយបន្ទាប់ពីមួយខែ សូមមើល pods ណាមួយនៅក្នុង Kubernetes នៅតែប្រើបញ្ជីឈ្មោះចាស់ ហើយផ្ទេរពួកវាទៅបញ្ជីឈ្មោះថ្មីផងដែរ។

តើយើងបានមករកអ្វី werf? យើងប្រមូល៖

1. ក្បាល Git៖ ស្លាកទាំងអស់ គ្រប់សាខា - សន្មត់ថាយើងត្រូវការអ្វីៗទាំងអស់ដែលត្រូវបានដាក់ស្លាកនៅក្នុង Git នៅក្នុងរូបភាព (ហើយបើមិនអញ្ចឹងទេ យើងត្រូវលុបវានៅក្នុង Git ដោយខ្លួនឯង);
2. ផតទាំងអស់ដែលបច្ចុប្បន្នត្រូវបានបូមចេញទៅកាន់ Kubernetes;
3. ReplicaSets ចាស់ (អ្វីដែលទើបនឹងចេញផ្សាយ) ហើយយើងក៏មានគម្រោងស្កេនការចេញផ្សាយ Helm ហើយជ្រើសរើសរូបភាពចុងក្រោយបំផុតនៅទីនោះ។

... ហើយធ្វើបញ្ជីសពីសំណុំនេះ - បញ្ជីរូបភាពដែលយើងនឹងមិនលុប។ យើង​សម្អាត​អ្វីៗ​ផ្សេង​ទៀត បន្ទាប់​មក​យើង​រក​ឃើញ​រូបភាព​ឆាក​កុមារ​កំព្រា ហើយ​លុប​វា​ចេញ​ផង​ដែរ។

ដាក់ពង្រាយដំណាក់កាល

សេចក្តីប្រកាសដែលអាចទុកចិត្តបាន។

ចំណុចដំបូងដែលខ្ញុំចង់ទាក់ទាញការយកចិត្តទុកដាក់ក្នុងការដាក់ពង្រាយគឺការដាក់ឱ្យដំណើរការនៃការកំណត់រចនាសម្ព័ន្ធធនធានដែលបានធ្វើបច្ចុប្បន្នភាពដែលបានប្រកាសដោយប្រកាស។ ឯកសារ YAML ដើមដែលពិពណ៌នាអំពីធនធាន Kubernetes តែងតែខុសគ្នាខ្លាំងពីលទ្ធផលដែលដំណើរការនៅក្នុងចង្កោម។ ដោយសារតែ Kubernetes បន្ថែមទៅលើការកំណត់៖

1. អត្តសញ្ញាណ;
2. ព័ត៌មានសេវាកម្ម;
3. តម្លៃលំនាំដើមជាច្រើន;
4. ផ្នែកដែលមានស្ថានភាពបច្ចុប្បន្ន;
5. ការផ្លាស់ប្តូរដែលបានធ្វើឡើងជាផ្នែកនៃ webhook ចូលរៀន;
6. លទ្ធផលនៃការងាររបស់ឧបករណ៍បញ្ជាផ្សេងៗ (និងកម្មវិធីកំណត់ពេល) ។

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

វិធីសាស្រ្តនេះត្រូវបានគេហៅថា ការរួមបញ្ចូលគ្នា 2 ផ្លូវ. វាត្រូវបានគេប្រើឧទាហរណ៍នៅក្នុង Helm ។

ក៏មានដែរ។ ការរួមបញ្ចូលគ្នា 3 ផ្លូវដែលខុសគ្នាត្រង់ថាៈ

• ការប្រៀបធៀប បានអនុវត្តចុងក្រោយ и ថ្មីយើងមើលអ្វីដែលត្រូវបានលុប;
• ការប្រៀបធៀប ថ្មី и រស់នៅយើងមើលអ្វីដែលត្រូវបានបន្ថែម ឬផ្លាស់ប្តូរ។
• បំណះសរុបត្រូវបានអនុវត្តទៅ រស់នៅ.

យើងដាក់ពង្រាយកម្មវិធី 1000+ ជាមួយ Helm ដូច្នេះយើងពិតជារស់នៅជាមួយការបញ្ចូលគ្នា 2 ផ្លូវ។ ទោះបីជាយ៉ាងណាក៏ដោយ វាមានបញ្ហាមួយចំនួនដែលយើងបានដោះស្រាយជាមួយនឹងបំណះរបស់យើង ដែលជួយឱ្យ Helm ដំណើរការជាធម្មតា។

ស្ថានភាព​ការ​ចេញ​ផ្សាយ​ពិត

បន្ទាប់ពីប្រព័ន្ធ CI របស់យើងបង្កើតការកំណត់រចនាសម្ព័ន្ធថ្មីសម្រាប់ Kubernetes ដោយផ្អែកលើព្រឹត្តិការណ៍បន្ទាប់ វាបញ្ជូនវាសម្រាប់ការប្រើប្រាស់ (អនុវត្ត) ទៅចង្កោម - ដោយប្រើ Helm ឬ kubectl apply. បន្ទាប់មក ការរួមបញ្ចូល N-way ដែលបានពិពណ៌នារួចហើយកើតឡើង ដែល Kubernetes API ឆ្លើយតបដោយយល់ព្រមចំពោះប្រព័ន្ធ CI ហើយចំពោះអ្នកប្រើប្រាស់របស់វា។

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

ដើម្បីធ្វើអ្វីៗគ្រប់យ៉ាងបានត្រឹមត្រូវ គ្រោងការណ៍នេះតម្រូវឱ្យមានតំណភ្ជាប់បន្ថែម - កម្មវិធីតាមដានពិសេសដែលនឹងទទួលបានព័ត៌មានស្ថានភាពពី Kubernetes API ហើយបញ្ជូនវាសម្រាប់ការវិភាគបន្ថែមអំពីស្ថានភាពពិតនៃវត្ថុ។ យើងបានបង្កើតបណ្ណាល័យប្រភពបើកចំហនៅក្នុង Go - កូនឆ្កែ (សូមមើលការប្រកាសរបស់វា។ នៅទីនេះ)ដែលដោះស្រាយបញ្ហានេះ និងត្រូវបានបង្កើតឡើងនៅក្នុង werf ។

ឥរិយាបថរបស់កម្មវិធីតាមដាននេះនៅកម្រិត werf ត្រូវបានកំណត់រចនាសម្ព័ន្ធដោយប្រើចំណារពន្យល់ដែលត្រូវបានដាក់នៅលើ Deployments ឬ StatefulSets។ ចំណារពន្យល់សំខាន់ - fail-mode - យល់អត្ថន័យដូចខាងក្រោមៈ

• IgnoreAndContinueDeployProcess - យើងមិនអើពើនឹងបញ្ហានៃការដាក់ចេញសមាសភាគនេះ ហើយបន្តការដាក់ឱ្យប្រើប្រាស់។
• FailWholeDeployProcessImmediately - កំហុសនៅក្នុងសមាសធាតុនេះបញ្ឈប់ដំណើរការដាក់ពង្រាយ។
• HopeUntilEndOfDeployProcess - យើងសង្ឃឹមថាសមាសភាគនេះនឹងដំណើរការនៅចុងបញ្ចប់នៃការដាក់ពង្រាយ។

ឧទាហរណ៍ ការរួមបញ្ចូលគ្នានៃធនធាន និងតម្លៃចំណារពន្យល់នេះ។ fail-mode:

នៅពេលដែលយើងដាក់ពង្រាយជាលើកដំបូង មូលដ្ឋានទិន្នន័យ (MongoDB) ប្រហែលជាមិនទាន់រួចរាល់នៅឡើយទេ - ការដាក់ពង្រាយនឹងបរាជ័យ។ ប៉ុន្តែអ្នកអាចរង់ចាំសម្រាប់ពេលវាចាប់ផ្តើម ហើយការដាក់ពង្រាយនឹងនៅតែប្រព្រឹត្តទៅ។

មានចំណារពន្យល់ពីរបន្ថែមទៀតសម្រាប់ kubedog នៅក្នុង werf៖

• failures-allowed-per-replica - ចំនួននៃការធ្លាក់ដែលត្រូវបានអនុញ្ញាតសម្រាប់ការចម្លងនីមួយៗ;
• show-logs-until - គ្រប់គ្រងពេលវេលារហូតដល់ពេលដែល werf បង្ហាញកំណត់ហេតុ (នៅក្នុង stdout) ពីផតដែលបានដាក់ចេញទាំងអស់។ លំនាំដើមគឺ PodIsReady (ដើម្បី​មិន​អើពើ​សារ​ដែល​យើង​ប្រហែល​ជា​មិន​ចង់​បាន​នៅ​ពេល​ដែល​ចរាចរណ៍​ចាប់​ផ្តើម​ចូល​មក​កាន់​ផត) ប៉ុន្តែ​តម្លៃ​ក៏​មាន​សុពលភាព​ដែរ៖ ControllerIsReady и EndOfDeploy.

តើយើងចង់បានអ្វីទៀតពីការដាក់ពង្រាយ?

បន្ថែមពីលើចំណុចពីរដែលបានពិពណ៌នារួចហើយ យើងចង់បាន៖

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

លទ្ធផល

សម្រាប់ពួកយើងជាក្រុមហ៊ុនមួយ ដើម្បីអនុវត្តរាល់ការពិពណ៌នាដែលបានពិពណ៌នានៅដំណាក់កាលផ្សេងៗគ្នានៃការចែកចាយ (សាងសង់ បោះពុម្ព ពង្រាយ) ប្រព័ន្ធ CI និងឧបករណ៍ប្រើប្រាស់គឺគ្រប់គ្រាន់ហើយ។ werf.

ជំនួសឱ្យការសន្និដ្ឋាន៖

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

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

វីដេអូពីការសម្តែង (~៤៧ នាទី)៖

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

PS

របាយការណ៍ផ្សេងទៀតអំពី Kubernetes នៅលើប្លក់របស់យើង៖

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

ប្រភព: www.habr.com