ការអនុវត្តរបស់យើងនៃការដាក់ពង្រាយជាបន្តបន្ទាប់នៅលើវេទិការបស់អតិថិជន

យើងនៅ True Engineering បានបង្កើតដំណើរការមួយសម្រាប់ការចែកចាយព័ត៌មានថ្មីៗជាបន្តបន្ទាប់ទៅកាន់ម៉ាស៊ីនមេរបស់អតិថិជន ហើយចង់ចែករំលែកបទពិសោធន៍នេះ។

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

នៅក្នុងអត្ថបទនេះ យើងនឹងនិយាយអំពីដំណាក់កាលទាំងអស់នៃដំណើរការដាក់ពង្រាយបន្ត (ស៊ីឌី) ឬការចែកចាយបច្ចុប្បន្នភាពទៅកាន់វេទិការបស់អតិថិជន៖

1. តើដំណើរការនេះចាប់ផ្តើមដោយរបៀបណា?
2. ការធ្វើសមកាលកម្មជាមួយឃ្លាំង Git របស់អតិថិជន,
3. ការជួបប្រជុំគ្នានៃផ្នែកខាងក្រោយនិងផ្នែកខាងមុខ,
4. ការដាក់ពង្រាយកម្មវិធីដោយស្វ័យប្រវត្តិនៅក្នុងបរិយាកាសសាកល្បង,
5. ការដាក់ពង្រាយដោយស្វ័យប្រវត្តិទៅ Prod ។

យើងនឹងចែករំលែកព័ត៌មានលម្អិតអំពីការដំឡើងនៅតាមផ្លូវ។

1. ចាប់ផ្តើមស៊ីឌី

ការដាក់ឱ្យប្រើប្រាស់ជាបន្តបន្ទាប់ចាប់ផ្តើមដោយអ្នកអភិវឌ្ឍន៍ជំរុញការផ្លាស់ប្តូរទៅកាន់សាខាចេញផ្សាយនៃឃ្លាំង Git របស់យើង។

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

យើងរៀបចំការងារតាមរយៈឃ្លាំងមួយសម្រាប់ហេតុផលជាច្រើន៖

• ភាពងាយស្រួលនៃការអភិវឌ្ឍន៍ - កម្មវិធីកំពុងអភិវឌ្ឍយ៉ាងសកម្ម ដូច្នេះអ្នកអាចធ្វើការជាមួយកូដទាំងអស់ក្នុងពេលតែមួយ។
• បំពង់ CI/CD តែមួយដែលធានាថាកម្មវិធីជាប្រព័ន្ធតែមួយឆ្លងកាត់ការសាកល្បងទាំងអស់ ហើយត្រូវបានបញ្ជូនទៅបរិយាកាសផលិតកម្មរបស់អតិថិជន។
• យើងលុបបំបាត់ភាពច្របូកច្របល់នៅក្នុងកំណែនានា - យើងមិនចាំបាច់រក្សាទុកកំណែផែនទីនៃសេវាកម្មមីក្រូ និងពណ៌នាអំពីការកំណត់របស់វាសម្រាប់សេវាមីក្រូនីមួយៗនៅក្នុងស្គ្រីប Helm នោះទេ។

2. ការធ្វើសមកាលកម្មជាមួយឃ្លាំង Git នៃកូដប្រភពរបស់អតិថិជន

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

យើងមិនអាចធ្វើការជាមួយឃ្លាំងរបស់អតិថិជនដោយផ្ទាល់បានទេ ដោយសារយើងត្រូវការបរិយាកាសផ្ទាល់ខ្លួនរបស់យើងសម្រាប់ការអភិវឌ្ឍន៍ និងការធ្វើតេស្ត។ យើងប្រើឃ្លាំង Git របស់យើងសម្រាប់គោលបំណងទាំងនេះ - វាត្រូវបានធ្វើសមកាលកម្មជាមួយឃ្លាំង Git របស់ពួកគេ។ ដរាបណាអ្នកអភិវឌ្ឍន៍ប្រកាសការផ្លាស់ប្តូរទៅសាខាសមស្របនៃឃ្លាំងរបស់យើង GitLab ជំរុញការផ្លាស់ប្តូរទាំងនេះទៅអតិថិជនភ្លាមៗ។

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

3. ការប្រមូលផ្តុំផ្នែកខាងក្រោយ និងផ្នែកខាងមុខ

ការកសាង backend និង frontend គឺជាកិច្ចការស្របគ្នាពីរដែលត្រូវបានអនុវត្តនៅក្នុងប្រព័ន្ធ GitLab Runner ។ ការកំណត់រចនាសម្ព័ន្ធដើមរបស់វាមានទីតាំងនៅក្នុងឃ្លាំងតែមួយ។

ការបង្រៀនសម្រាប់ការសរសេរអក្សរ YAML សម្រាប់ការសាងសង់នៅក្នុង GitLab.

GitLab Runner យកកូដពីឃ្លាំងដែលត្រូវការ ប្រមូលផ្តុំវាជាមួយពាក្យបញ្ជាបង្កើតកម្មវិធី Java ហើយផ្ញើវាទៅ Docker registry ។ នៅទីនេះយើងប្រមូលផ្តុំផ្នែកខាងក្រោយ និងផ្នែកខាងមុខ ទទួលបានរូបភាព Docker ដែលយើងដាក់ក្នុងឃ្លាំងនៅខាងអតិថិជន។ ដើម្បីគ្រប់គ្រងរូបភាព Docker យើងប្រើ កម្មវិធីជំនួយ Gradle.

យើងធ្វើសមកាលកម្មកំណែនៃរូបភាពរបស់យើងជាមួយនឹងកំណែចេញផ្សាយដែលនឹងត្រូវបានបោះពុម្ពនៅក្នុង Docker ។ ដើម្បីដំណើរការរលូន យើងបានធ្វើការកែសម្រួលជាច្រើន៖

1. កុងតឺន័រមិនត្រូវបានសាងសង់ឡើងវិញរវាងបរិយាកាសសាកល្បងនិងបរិយាកាសផលិតកម្មទេ។ យើងបានធ្វើការកំណត់ប៉ារ៉ាម៉ែត្រដើម្បីឱ្យធុងដូចគ្នាអាចដំណើរការជាមួយការកំណត់ទាំងអស់ អថេរបរិស្ថាន និងសេវាកម្មទាំងនៅក្នុងបរិយាកាសសាកល្បង និងក្នុងផលិតកម្មដោយមិនចាំបាច់សាងសង់ឡើងវិញ។

2. ដើម្បីធ្វើបច្ចុប្បន្នភាពកម្មវិធីតាមរយៈ Helm អ្នកត្រូវតែបញ្ជាក់កំណែរបស់វា។ យើងបង្កើតផ្នែកខាងក្រោយ ផ្នែកខាងមុខ និងធ្វើបច្ចុប្បន្នភាពកម្មវិធី - ទាំងនេះគឺជាកិច្ចការបីផ្សេងគ្នា ដូច្នេះវាជាការសំខាន់ណាស់ក្នុងការប្រើកំណែដូចគ្នានៃកម្មវិធីនៅគ្រប់ទីកន្លែង។ សម្រាប់កិច្ចការនេះ យើងប្រើប្រាស់ទិន្នន័យពីប្រវត្តិ Git ដោយហេតុថាការកំណត់រចនាសម្ព័ន្ធ និងកម្មវិធីចង្កោម K8S របស់យើងស្ថិតនៅក្នុងឃ្លាំង Git តែមួយ។

យើងទទួលបានកំណែកម្មវិធីពីលទ្ធផលប្រតិបត្តិពាក្យបញ្ជា
git describe --tags --abbrev=7.

4. ការដាក់ពង្រាយដោយស្វ័យប្រវត្តិនូវការផ្លាស់ប្តូរទាំងអស់ចំពោះបរិយាកាសសាកល្បង (UAT)

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

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

យើងផ្គត់ផ្គង់ការកំណត់រចនាសម្ព័ន្ធចង្កោម K8S រួមជាមួយនឹងការជួបប្រជុំគ្នា។ ដូច្នេះ ជំហានបន្ទាប់គឺធ្វើបច្ចុប្បន្នភាពវា៖ configMaps ការដាក់ពង្រាយ សេវាកម្ម អាថ៌កំបាំង និងការកំណត់រចនាសម្ព័ន្ធ K8S ផ្សេងទៀតដែលយើងបានផ្លាស់ប្តូរ។

បន្ទាប់មក Helm ដំណើរការការអាប់ដេត RollOut នៃកម្មវិធីខ្លួនវានៅក្នុងបរិយាកាសសាកល្បង។ មុនពេលកម្មវិធីត្រូវបានដាក់ពង្រាយទៅផលិតកម្ម។ នេះត្រូវបានធ្វើដូច្នេះ អ្នកប្រើប្រាស់អាចសាកល្បងដោយខ្លួនឯងនូវលក្ខណៈអាជីវកម្មដែលយើងដាក់ចូលទៅក្នុងបរិយាកាសសាកល្បង។

5. ការដាក់ពង្រាយដោយស្វ័យប្រវត្តិនៃការផ្លាស់ប្តូរទាំងអស់ទៅ Prod

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

កម្មវិធីដូចគ្នាអាចដំណើរការក្នុងបរិយាកាសផ្សេងៗគ្នា - ការធ្វើតេស្ត និងការផលិត - ដោយមិនចាំបាច់សាងសង់ឡើងវិញ។ យើងប្រើវត្ថុបុរាណដូចគ្នាដោយមិនផ្លាស់ប្តូរអ្វីទាំងអស់នៅក្នុងកម្មវិធី ហើយយើងកំណត់ប៉ារ៉ាម៉ែត្រខាងក្រៅ។

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

អ្វីដែលពិបាកបំផុតគឺកំណត់ប៉ារ៉ាម៉ែត្រសេវាកម្ម និងអថេរទាំងអស់ដែលប្រើរួចដែលអាស្រ័យលើបរិស្ថាន ហើយបកប្រែវាទៅជាអថេរបរិស្ថាន និងការកំណត់រចនាសម្ព័ន្ធការពិពណ៌នានៃប៉ារ៉ាម៉ែត្របរិស្ថានសម្រាប់ Helm ។

ការកំណត់កម្មវិធីប្រើអថេរបរិស្ថាន។ តម្លៃ​របស់​វា​ត្រូវ​បាន​កំណត់​ក្នុង​កុងតឺន័រ​ដោយ​ប្រើ K8S configmap ដែល​ត្រូវ​បាន​បង្កើត​ដោយ​ប្រើ​គំរូ Go ។ ជាឧទាហរណ៍ ការកំណត់អថេរបរិស្ថានទៅនឹងឈ្មោះដែនអាចត្រូវបានធ្វើដូចនេះ៖

APP_EXTERNAL_DOMAIN: {{ (pluck .Values.global.env .Values.app.properties.app_external_domain | first) }}

.Values.global.env - អថេរនេះរក្សាទុកឈ្មោះបរិស្ថាន (ផលិតផល, ដំណាក់កាល, UAT) ។
.Values.app.properties.app_external_domain – នៅក្នុងអថេរនេះ យើងកំណត់ដែនដែលចង់បាននៅក្នុងឯកសារ .Values.yaml

នៅពេលអាប់ដេតកម្មវិធី Helm បង្កើតឯកសារ configmap.yaml ពីគំរូ ហើយបំពេញតម្លៃ APP_EXTERNAL_DOMAIN ជាមួយនឹងតម្លៃដែលចង់បាន អាស្រ័យលើបរិយាកាសដែលកម្មវិធីចាប់ផ្តើមអាប់ដេត។ អថេរនេះត្រូវបានកំណត់រួចហើយនៅក្នុងកុងតឺន័រ។ វាអាចត្រូវបានចូលប្រើពីកម្មវិធី ដូច្នេះបរិស្ថានកម្មវិធីនីមួយៗនឹងមានតម្លៃខុសគ្នាសម្រាប់អថេរនេះ។

ថ្មីៗនេះ ការគាំទ្រ K8S បានបង្ហាញខ្លួននៅក្នុង Spring Cloud រួមទាំងធ្វើការជាមួយ configMaps៖ Spring Cloud Kubernetes. ខណៈពេលដែលគម្រោងកំពុងអភិវឌ្ឍ និងផ្លាស់ប្តូរយ៉ាងសកម្ម យើងមិនអាចប្រើវានៅក្នុងការផលិតបានទេ។ ប៉ុន្តែយើងតាមដានស្ថានភាពរបស់វាយ៉ាងសកម្ម ហើយប្រើវានៅក្នុងការកំណត់រចនាសម្ព័ន្ធ DEV ។ ដរាបណាវាមានស្ថេរភាព យើងនឹងប្តូរពីការប្រើប្រាស់អថេរបរិស្ថានទៅវា។

សរុប

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

ផែនការអនាគត៖ ការផ្ទេរទិន្នន័យដោយស្វ័យប្រវត្តិ

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

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

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

យើងមានគម្រោងធ្វើការផ្លាស់ប្តូរមូលដ្ឋានទិន្នន័យដោយស្វ័យប្រវត្តិតាមរយៈការងារ K8S ដោយបញ្ចូលវាទៅក្នុងដំណើរការស៊ីឌី។ ហើយយើងពិតជានឹងចែករំលែកបទពិសោធន៍នេះនៅលើ Habre ។

ប្រភព: www.habr.com