Southbridge នៅ Chelyabinsk និង Bitrix នៅ Kubernetes

ការជួបប្រជុំរបស់អ្នកគ្រប់គ្រងប្រព័ន្ធ Sysadminka កំពុងប្រព្រឹត្តទៅនៅ Chelyabinsk ហើយចុងក្រោយខ្ញុំបានផ្ដល់របាយការណ៍អំពីដំណោះស្រាយរបស់យើងសម្រាប់ការដំណើរការកម្មវិធីនៅលើ 1C-Bitrix នៅក្នុង Kubernetes ។

Bitrix, Kubernetes, Ceph - ល្បាយដ៏អស្ចារ្យ?

ខ្ញុំនឹងប្រាប់អ្នកពីរបៀបដែលយើងដាក់បញ្ចូលគ្នានូវដំណោះស្រាយការងារពីបញ្ហាទាំងអស់នេះ។

តោះទៅ!

ការ​ជួប​គ្នា​នេះ​បាន​ធ្វើ​ឡើង​នៅ​ថ្ងៃ​ទី 18 ខែ​មេសា​នៅ Chelyabinsk ។ អ្នកអាចអានអំពីកិច្ចប្រជុំរបស់យើងនៅ ផ្ទាំងពេលវេលា ហើយមើល យូធូប.

ប្រសិនបើអ្នកចង់មករកយើងជាមួយនឹងរបាយការណ៍ឬជាអ្នកស្តាប់ - សូមស្វាគមន៍, សរសេរទៅ [អ៊ីមែលការពារ] និងនៅលើ Telegram t.me/vadimisakanov ។

របាយការណ៍របស់ខ្ញុំ

ស្លាយ

ដំណោះស្រាយ "Bitrix ក្នុង Kubernetes កំណែ Southbridge 1.0"

ខ្ញុំនឹងនិយាយអំពីដំណោះស្រាយរបស់យើងនៅក្នុងទម្រង់ "សម្រាប់អត់ចេះសោះក្នុង Kubernetes" ដូចដែលបានធ្វើនៅឯកិច្ចប្រជុំ។ ប៉ុន្តែខ្ញុំសន្មត់ថាអ្នកស្គាល់ពាក្យ Bitrix, Docker, Kubernetes, Ceph យ៉ាងហោចណាស់នៅកម្រិតនៃអត្ថបទនៅលើវិគីភីឌា។

តើ​អ្វី​ដែល​ត្រៀម​រួច​ជា​ស្រេច​អំពី Bitrix នៅ​ក្នុង Kubernetes?

មានព័ត៌មានតិចតួចណាស់នៅលើអ៊ីនធឺណិតទាំងមូលអំពីប្រតិបត្តិការនៃកម្មវិធី Bitrix នៅក្នុង Kubernetes ។
ខ្ញុំបានរកឃើញតែសម្ភារៈទាំងនេះ៖

រាយការណ៍ដោយ Alexander Serbul, 1C-Bitrix, និង Anton Tuzlukov ពី Qsoft:

ខ្ញុំសូមណែនាំឱ្យស្តាប់វា។

បង្កើតដំណោះស្រាយផ្ទាល់ខ្លួនរបស់អ្នកពីអ្នកប្រើប្រាស់ សឺគីរ៉ុន នៅលើ Habre.
បានរកឃើញច្រើនទៀត ការសម្រេចចិត្តបែបនេះ.

Aaand... តាមពិតទៅ នោះហើយជាទាំងអស់។

ខ្ញុំ​សូម​ព្រមាន​អ្នក យើង​មិន​បាន​ពិនិត្យ​គុណភាព​នៃ​ដំណោះស្រាយ​ក្នុង​តំណ​ខាង​លើ :)
និយាយអីញ្ចឹង ពេលរៀបចំដំណោះស្រាយរបស់យើង ខ្ញុំបានពិភាក្សាជាមួយ Alexander Serbul បន្ទាប់មករបាយការណ៍របស់គាត់មិនទាន់លេចចេញទេ ដូច្នេះនៅក្នុងស្លាយរបស់ខ្ញុំមានធាតុ "Bitrix មិនប្រើ Kubernetes"។

ប៉ុន្តែមានរូបភាព Docker ដែលត្រៀមរួចជាស្រេចជាច្រើនសម្រាប់ការដំណើរការ Bitrix នៅក្នុង Docker៖ https://hub.docker.com/search?q=bitrix&type=image

តើវាគ្រប់គ្រាន់ក្នុងការបង្កើតដំណោះស្រាយពេញលេញសម្រាប់ Bitrix នៅក្នុង Kubernetes ដែរឬទេ?
ទេ មានបញ្ហាមួយចំនួនធំដែលត្រូវដោះស្រាយ។

តើមានបញ្ហាអ្វីខ្លះជាមួយ Bitrix នៅក្នុង Kubernetes?

ជាដំបូង រូបភាពដែលត្រៀមរួចជាស្រេចពី Dockerhub មិនស័ក្តិសមសម្រាប់ Kubernetes ទេ។

ប្រសិនបើយើងចង់បង្កើតស្ថាបត្យកម្មមីក្រូវ៉េវ (ហើយនៅក្នុង Kubernetes ជាធម្មតាយើងធ្វើ) យើងត្រូវបំបែកកម្មវិធី Kubernetes របស់យើងទៅជាកុងតឺន័រ ហើយឱ្យកុងតឺន័រនីមួយៗអនុវត្តមុខងារតូចមួយ (ហើយធ្វើវាឱ្យបានល្អ)។ ហេតុអ្វីមានតែមួយ? និយាយឱ្យខ្លី កាន់តែសាមញ្ញ កាន់តែអាចទុកចិត្តបាន។
ដើម្បីឱ្យកាន់តែច្បាស់ សូមទស្សនាអត្ថបទ និងវីដេអូនេះទាំងអស់គ្នា៖ https://habr.com/ru/company/southbridge/blog/426637/

រូបភាព Docker នៅក្នុង Dockerhub ត្រូវបានបង្កើតឡើងជាចម្បងលើគោលការណ៍ all-in-one ដូច្នេះហើយយើងនៅតែត្រូវធ្វើកង់ផ្ទាល់ខ្លួនរបស់យើង ហើយថែមទាំងបង្កើតរូបភាពពីទទេទៀតផង។

ទីពីរ - កូដគេហទំព័រត្រូវបានកែសម្រួលពីបន្ទះគ្រប់គ្រង

យើងបានបង្កើតផ្នែកថ្មីមួយនៅលើគេហទំព័រ - កូដត្រូវបានធ្វើបច្ចុប្បន្នភាព (ថតដែលមានឈ្មោះនៃផ្នែកថ្មីត្រូវបានបន្ថែម) ។

ប្រសិនបើអ្នកបានផ្លាស់ប្តូរលក្ខណសម្បត្តិនៃសមាសភាគពីបន្ទះគ្រប់គ្រង លេខកូដបានផ្លាស់ប្តូរ។

Kubernetes "តាមលំនាំដើម" មិនអាចដំណើរការជាមួយធុងនេះបានទេ។

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

ទីបី - អ្នកត្រូវដោះស្រាយបញ្ហាជាមួយនឹងការដាក់ពង្រាយ

ប្រសិនបើយើងមាន monolith និងម៉ាស៊ីនមេ "បុរាណ" មួយ អ្វីគ្រប់យ៉ាងគឺសាមញ្ញណាស់: យើងដាក់ពង្រាយមូលដ្ឋានកូដថ្មី ផ្ទេរទិន្នន័យ ប្តូរចរាចរទៅកាន់កំណែថ្មីនៃកូដ។ ការប្តូរកើតឡើងភ្លាមៗ។
ប្រសិនបើយើងមានគេហទំព័រនៅក្នុង Kubernetes កាត់ចូលទៅក្នុង microservices មានធុងជាច្រើនដែលមានលេខកូដ - អូ។ អ្នក​ត្រូវ​ប្រមូល​កុងតឺន័រ​ជាមួយ​កំណែ​ថ្មី​នៃ​កូដ រមៀល​វា​ចេញ​ជំនួស​ឱ្យ​លេខ​ចាស់ ផ្ទេរ​មូលដ្ឋាន​ទិន្នន័យ​ឱ្យ​បាន​ត្រឹមត្រូវ ហើយ​ធ្វើ​បែប​នេះ​ដោយ​អ្នក​ទស្សនា​ដោយ​មិន​មាន​ការ​កត់​សម្គាល់។ ជាសំណាងល្អ Kubernetes ជួយយើងក្នុងរឿងនេះ ដោយគាំទ្រក្រុមទាំងមូលនៃប្រភេទផ្សេងគ្នានៃការដាក់ពង្រាយ។

ទីបួន - អ្នកត្រូវដោះស្រាយបញ្ហានៃការរក្សាទុកឋិតិវន្ត

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

តើមានអ្វីបាត់ពីដំណោះស្រាយរបស់យើង?

លេខកូដ Bitrix ទាំងមូលមិនត្រូវបានបែងចែកទៅជា microfunctions/microservices (ដូច្នេះការចុះឈ្មោះគឺដាច់ដោយឡែក ម៉ូឌុលហាងអនឡាញគឺដាច់ដោយឡែក។ល។)។ យើងរក្សាទុកមូលដ្ឋានកូដទាំងមូលនៅក្នុងធុងនីមួយៗ។

យើងក៏មិនរក្សាទុកមូលដ្ឋានទិន្នន័យនៅក្នុង Kubernetes (ខ្ញុំនៅតែអនុវត្តដំណោះស្រាយជាមួយមូលដ្ឋានទិន្នន័យនៅក្នុង Kubernetes សម្រាប់បរិស្ថានអភិវឌ្ឍន៍ ប៉ុន្តែមិនមែនសម្រាប់ផលិតកម្មទេ)។

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

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

ស្ថាបត្យកម្ម

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

យើងដោះស្រាយសំណួរ៖

• កន្លែងដែលត្រូវរក្សាទុកវគ្គ?
• កន្លែងដែលត្រូវទុកឃ្លាំងសម្ងាត់?
• កន្លែងដែលត្រូវរក្សាទុកឋិតិវន្ត មិនមែនដើម្បីដាក់ជីហ្គាបៃនៃឋិតិវន្តនៅក្នុងចង្កោមនៃធុង?
• តើមូលដ្ឋានទិន្នន័យនឹងដំណើរការយ៉ាងដូចម្តេច?

រូបថតរបស់ Docker

យើងចាប់ផ្តើមដោយបង្កើតរូបភាព Docker ។

ជម្រើសដ៏ល្អគឺថាយើងមានរូបភាពសកលមួយ ដោយផ្អែកលើមូលដ្ឋានរបស់វា យើងទទួលបានផតថលកម្មករ ផតឃែរជាមួយ Crontasks និងដំឡើងកំណែផត។

យើងបង្កើតរូបភាពបែបនេះ.

វារួមបញ្ចូល nginx, apache/php-fpm (អាចត្រូវបានជ្រើសរើសកំឡុងពេលសាងសង់) msmtp សម្រាប់ផ្ញើសំបុត្រ និង cron ។

នៅពេលដំឡើងរូបភាព មូលដ្ឋានកូដទាំងមូលនៃគេហទំព័រត្រូវបានចម្លងទៅថត /app (លើកលែងតែផ្នែកទាំងនោះដែលយើងនឹងផ្លាស់ទីទៅកន្លែងផ្ទុកដែលបានចែករំលែកដាច់ដោយឡែក)។

សេវាមីក្រូ, សេវាកម្ម

កន្ត្រកកម្មករ៖

• កុងតឺន័រដែលមាន nginx + container apache/php-fpm + msmtp
• វាមិនដំណើរការទេក្នុងការផ្លាស់ទី msmtp ទៅក្នុងសេវាមីក្រូដាច់ដោយឡែកមួយ Bitrix ចាប់ផ្តើមខឹងដែលវាមិនអាចផ្ញើសំបុត្រដោយផ្ទាល់
• ធុងនីមួយៗមានមូលដ្ឋានកូដពេញលេញ។
• ការហាមឃាត់លើការផ្លាស់ប្តូរលេខកូដនៅក្នុងកុងតឺន័រ។

cron ក្រោម៖

• ធុងជាមួយ apache, php, cron
• មូលដ្ឋានកូដពេញលេញរួមបញ្ចូល
• ហាមឃាត់ការផ្លាស់ប្តូរកូដនៅក្នុងធុង

ធ្វើឱ្យប្រសើរឡើងនៅក្រោម៖

• ធុងផ្ទុក nginx + apache/php-fpm container + msmtp
• មិនមានការហាមឃាត់លើការផ្លាស់ប្តូរលេខកូដនៅក្នុងកុងតឺន័រទេ។

ការផ្ទុកវគ្គ

ឃ្លាំងសម្ងាត់ Bitrix

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

ការផ្ទុកសម្រាប់ឋិតិវន្ត

អ្នកអាចប្រើអ្វីក៏បាន៖ ceph, nfs (ប៉ុន្តែយើងមិនណែនាំ nfs សម្រាប់ការផលិត) ការផ្ទុកបណ្តាញពីអ្នកផ្តល់សេវាពពក។ល។

កន្លែងផ្ទុកនឹងត្រូវភ្ជាប់ក្នុងកុងតឺន័រទៅកាន់ /upload/ directory នៃគេហទំព័រ និងថតផ្សេងទៀតដែលមានមាតិកាឋិតិវន្ត។

មូលដ្ឋានទិន្នន័យ

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

ការផ្ទុកវគ្គ

យើងប្រើ memcached :)

វាគ្រប់គ្រងការផ្ទុកសម័យបានយ៉ាងល្អ ត្រូវបានដាក់ជាចង្កោម និងត្រូវបានគាំទ្រ "ដើមកំណើត" ជា session.save_path ក្នុង php ។ ប្រព័ន្ធបែបនេះត្រូវបានសាកល្បងជាច្រើនដងនៅក្នុងស្ថាបត្យកម្ម monolithic បុរាណ នៅពេលដែលយើងបង្កើតចង្កោមជាមួយនឹងម៉ាស៊ីនមេគេហទំព័រមួយចំនួនធំ។ សម្រាប់ការដាក់ពង្រាយ យើងប្រើមួកសុវត្ថិភាព។

$ helm install stable/memcached --name session

php.ini - នៅទីនេះរូបភាពមានការកំណត់សម្រាប់រក្សាទុកវគ្គក្នុង memcached

យើងបានប្រើ Environment Variables ដើម្បីបញ្ជូនទិន្នន័យអំពីម៉ាស៊ីនជាមួយ memcached https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/.
វាអនុញ្ញាតឱ្យអ្នកប្រើកូដដូចគ្នានៅក្នុង dev, stage, test, prod environments (ឈ្មោះម៉ាស៊ីន memcached នៅក្នុងពួកវានឹងខុសគ្នា ដូច្នេះយើងត្រូវឆ្លងកាត់ឈ្មោះម៉ាស៊ីនតែមួយគត់សម្រាប់ sessions ទៅបរិស្ថាននីមួយៗ)។
ឃ្លាំងសម្ងាត់ Bitrix

យើងត្រូវការកន្លែងផ្ទុកដែលអត់ឱនចំពោះកំហុស ដែលផតថលទាំងអស់អាចសរសេរ និងអានពី។

យើងក៏ប្រើ memcached ផងដែរ។
ដំណោះស្រាយនេះត្រូវបានណែនាំដោយ Bitrix ខ្លួនវាផ្ទាល់។

$ helm install stable/memcached --name cache

bitrix/.settings_extra.php - នៅទីនេះក្នុង Bitrix វាត្រូវបានបញ្ជាក់កន្លែងដែលឃ្លាំងសម្ងាត់ត្រូវបានរក្សាទុក

យើងក៏ប្រើ Environment Variables ផងដែរ។

ក្រូនតាស្គី

មានវិធីសាស្រ្តផ្សេងគ្នាក្នុងការដំណើរការ Crontasks នៅក្នុង Kubernetes ។

• ការដាក់ពង្រាយដាច់ដោយឡែកជាមួយផតសម្រាប់ដំណើរការ Crontasks
• cronjob សម្រាប់ប្រតិបត្តិ crontask (ប្រសិនបើនេះជាកម្មវិធីបណ្តាញ - ជាមួយ wget https://$host$cronjobnameឬ kubectl exec នៅខាងក្នុងផតថលកម្មករ។ល។)
• ល

អ្នកអាចជជែកវែកញែកអំពីអ្វីដែលត្រឹមត្រូវបំផុត ប៉ុន្តែក្នុងករណីនេះយើងបានជ្រើសរើសជម្រើស "ការដាក់ពង្រាយដោយឡែកពីគ្នាជាមួយ pods សម្រាប់ Crontasks"

តើវាត្រូវបានធ្វើយ៉ាងដូចម្តេច៖

• បន្ថែមកិច្ចការ cron តាមរយៈ ConfigMap ឬតាមរយៈឯកសារ config/addcron
• ក្នុងឧទាហរណ៍មួយ យើងបើកដំណើរការកុងតឺន័រដូចគ្នាបេះបិទទៅនឹងផតថលកម្មករ + អនុញ្ញាតឱ្យអនុវត្តកិច្ចការមកុដនៅក្នុងវា
• មូលដ្ឋានកូដដូចគ្នាត្រូវបានប្រើ អរគុណចំពោះការបង្រួបបង្រួម ការផ្គុំកុងតឺន័រគឺសាមញ្ញ

តើយើងទទួលបានអ្វីល្អ៖

• យើងមានការងារ Crontask ក្នុងបរិយាកាសដូចគ្នាបេះបិទទៅនឹងបរិស្ថានរបស់អ្នកអភិវឌ្ឍន៍ (docker)
• Crontasks មិនចាំបាច់ត្រូវបាន "សរសេរឡើងវិញ" សម្រាប់ Kubernetes ទេ ពួកវាដំណើរការក្នុងទម្រង់ដូចគ្នា និងក្នុងមូលដ្ឋានកូដដូចគ្នាដូចពីមុន
• ភារកិច្ច cron អាចត្រូវបានបន្ថែមដោយសមាជិកក្រុមទាំងអស់ដែលមានសិទ្ធិក្នុងផ្នែកផលិតកម្ម មិនមែនត្រឹមតែជាអ្នកគ្រប់គ្រងប៉ុណ្ណោះទេ

ម៉ូឌុល Southbridge K8SDeploy និងការកែសម្រួលកូដពីបន្ទះគ្រប់គ្រង

យើងកំពុងនិយាយអំពីការធ្វើឱ្យប្រសើរឡើងនៅក្រោម?
តើធ្វើដូចម្តេចដើម្បីដឹកនាំចរាចរណ៍នៅទីនោះ?
Hurray យើងបានសរសេរម៉ូឌុលសម្រាប់នេះនៅក្នុង PHP :) នេះគឺជាម៉ូឌុលបុរាណតូចមួយសម្រាប់ Bitrix ។ វាមិនទាន់មានជាសាធារណៈនៅឡើយទេ ប៉ុន្តែយើងគ្រោងនឹងបើកវា។
ម៉ូឌុលត្រូវបានដំឡើងដូចម៉ូឌុលធម្មតានៅក្នុង Bitrix៖

ហើយវាមើលទៅដូចនេះ៖

វាអនុញ្ញាតឱ្យអ្នកកំណត់ខូគីដែលកំណត់អត្តសញ្ញាណអ្នកគ្រប់គ្រងគេហទំព័រ និងអនុញ្ញាតឱ្យ Kubernetes បញ្ជូនចរាចរណ៍ទៅកាន់ផតអាប់ដេត។

នៅពេលដែលការផ្លាស់ប្តូរត្រូវបានបញ្ចប់ អ្នកត្រូវចុច git push ការផ្លាស់ប្តូរកូដនឹងត្រូវបានផ្ញើទៅកាន់ git បន្ទាប់មកប្រព័ន្ធនឹងបង្កើតរូបភាពជាមួយនឹងកំណែថ្មីនៃកូដ ហើយ "roll out" វាឆ្លងកាត់ចង្កោមដោយជំនួស pods ចាស់។ .

បាទ វាជាឈើច្រត់បន្តិច ប៉ុន្តែក្នុងពេលជាមួយគ្នានេះ យើងរក្សាស្ថាបត្យកម្មមីក្រូសេវាកម្ម ហើយមិនដកយកឱកាសដែលពួកគេចូលចិត្តដើម្បីកែកូដពីអ្នកប្រើប្រាស់ Bitrix ចេញពីផ្ទាំងគ្រប់គ្រងនោះទេ។ នៅទីបញ្ចប់នេះគឺជាជម្រើសមួយ; អ្នកអាចដោះស្រាយបញ្ហានៃការកែសម្រួលកូដនៅក្នុងវិធីផ្សេងគ្នា។

គំនូសតាងមួកសុវត្ថិភាព

ដើម្បីបង្កើតកម្មវិធីនៅលើ Kubernetes ជាធម្មតាយើងប្រើកម្មវិធីគ្រប់គ្រងកញ្ចប់ Helm ។
សម្រាប់ដំណោះស្រាយ Bitrix របស់យើងនៅក្នុង Kubernetes លោក Sergey Bondarev ដែលជាអ្នកគ្រប់គ្រងប្រព័ន្ធឈានមុខគេរបស់យើងបានសរសេរតារាង Helm ពិសេស។

វាបង្កើតកម្មករ, កម្រិត, cron pods, កំណត់រចនាសម្ព័ន្ធ ingresses, សេវាកម្ម, និងផ្ទេរអថេរពី Kubernetes secrets ទៅ pods ។

យើងរក្សាទុកកូដនៅក្នុង Gitlab ហើយយើងក៏ដំណើរការ Helm build ពី Gitlab ផងដែរ។

និយាយឱ្យខ្លីវាមើលទៅដូចនេះ

$ helm upgrade --install project .helm --set image=registrygitlab.local/k8s/bitrix -f .helm/values.yaml --wait --timeout 300 --debug --tiller-namespace=production

Helm ក៏អនុញ្ញាតឱ្យអ្នកធ្វើ rollback "គ្មានថ្នេរ" ប្រសិនបើភ្លាមៗមានអ្វីមួយខុសប្រក្រតីកំឡុងពេលដាក់ពង្រាយ។ វាល្អណាស់នៅពេលដែលអ្នកមិនស្ថិតក្នុងភាពភ័យស្លន់ស្លោ "ជួសជុលកូដតាមរយៈ ftp ដោយសារតែផលិតផលធ្លាក់ចុះ" ប៉ុន្តែ Kubernetes ធ្វើវាដោយស្វ័យប្រវត្តិ និងដោយគ្មានពេលវេលារងចាំ។

ដាក់ពង្រាយ

បាទ យើងជាអ្នកគាំទ្រ Gitlab & Gitlab CI យើងប្រើវា :)
នៅពេលធ្វើការនៅក្នុង Gitlab ទៅកាន់ឃ្លាំងគម្រោង Gitlab បើកដំណើរការបំពង់បង្ហូរប្រេងដែលដាក់ពង្រាយកំណែថ្មីនៃបរិស្ថាន។

ដំណាក់កាល:

• build (បង្កើតរូបភាព Docker ថ្មី)
• តេស្ត (សាកល្បង)
• សម្អាត (លុបបរិយាកាសសាកល្បង)
• រុញ (យើងផ្ញើវាទៅបញ្ជីឈ្មោះ Docker)
• ដាក់ពង្រាយ (យើងដាក់ពង្រាយកម្មវិធីទៅ Kubernetes តាមរយៈ Helm) ។

ហ៊ឺ រួចរាល់ហើយ តោះអនុវត្តវា!
ឬសួរសំណួរប្រសិនបើមាន។

ដូច្នេះតើយើងបានធ្វើអ្វី

តាមទស្សនៈបច្ចេកទេស៖

• dockerized Bitrix;
• "កាត់" Bitrix ចូលទៅក្នុងធុងនីមួយៗដែលអនុវត្តមុខងារអប្បបរមា។
• សម្រេចបាននូវស្ថានភាពគ្មានរដ្ឋនៃធុង;
• បានដោះស្រាយបញ្ហាជាមួយនឹងការធ្វើបច្ចុប្បន្នភាព Bitrix នៅក្នុង Kubernetes;
• មុខងារ Bitrix ទាំងអស់បានបន្តដំណើរការ (ស្ទើរតែទាំងអស់);
• យើងបានធ្វើការលើការដាក់ឱ្យប្រើប្រាស់ទៅកាន់ Kubernetes និង rollback រវាងកំណែ។

តាមទស្សនៈអាជីវកម្ម៖

• ការអត់ធ្មត់កំហុស;
• ឧបករណ៍ Kubernetes (ការរួមបញ្ចូលយ៉ាងងាយស្រួលជាមួយ Gitlab CI ការដាក់ពង្រាយគ្មានថ្នេរ។ល។)
• ពាក្យសម្ងាត់សម្ងាត់ (អាចមើលឃើញតែចំពោះអ្នកដែលត្រូវបានអនុញ្ញាតឱ្យចូលប្រើពាក្យសម្ងាត់ដោយផ្ទាល់);
• វាងាយស្រួលក្នុងការបង្កើតបរិយាកាសបន្ថែម (សម្រាប់ការអភិវឌ្ឍន៍ ការធ្វើតេស្ត។ល។) នៅក្នុងហេដ្ឋារចនាសម្ព័ន្ធតែមួយ។

ប្រភព: www.habr.com