Post Mortem នៅលើ Quay.io ភាពមិនមាន

ចំណាំ។ បកប្រែ៖ នៅដើមខែសីហា Red Hat បាននិយាយជាសាធារណៈអំពីការដោះស្រាយបញ្ហាភាពងាយស្រួលដែលអ្នកប្រើប្រាស់សេវាកម្មរបស់ខ្លួនបានជួបប្រទះកាលពីខែមុន Quay.io (វាផ្អែកលើបញ្ជីឈ្មោះសម្រាប់រូបភាពកុងតឺន័រ ដែលក្រុមហ៊ុនបានទទួលរួមជាមួយការទិញ CoreOS)។ ដោយមិនគិតពីចំណាប់អារម្មណ៍របស់អ្នកចំពោះសេវាកម្មនេះទេ ផ្លូវដែលវិស្វករ SRE របស់ក្រុមហ៊ុនបានអនុវត្តដើម្បីធ្វើរោគវិនិច្ឆ័យ និងលុបបំបាត់មូលហេតុនៃគ្រោះថ្នាក់នេះ គឺជាការណែនាំ។

នៅថ្ងៃទី 19 ឧសភា ព្រឹកព្រលឹម (ម៉ោងពន្លឺថ្ងៃភាគខាងកើត EDT) សេវា quay.io បានគាំង។ គ្រោះថ្នាក់នេះបានប៉ះពាល់ដល់ទាំងអ្នកប្រើប្រាស់ quay.io និងគម្រោង Open Source ដោយប្រើ quay.io ជាវេទិកាសម្រាប់សាងសង់ និងចែកចាយកម្មវិធី។ Red Hat ឱ្យតម្លៃលើការជឿទុកចិត្តរបស់អ្នកទាំងពីរ។

ក្រុមវិស្វករ SRE បានចូលរួមភ្លាមៗ ហើយព្យាយាមធ្វើឱ្យសេវាកម្ម Quay មានស្ថេរភាពឱ្យបានឆាប់តាមដែលអាចធ្វើទៅបាន។ ទោះជាយ៉ាងណាក៏ដោយ ខណៈពេលដែលពួកគេកំពុងធ្វើនេះ អតិថិជនបានបាត់បង់សមត្ថភាពក្នុងការរុញរូបភាពថ្មី ហើយមានតែម្តងម្កាលប៉ុណ្ណោះដែលពួកគេអាចទាញរូបភាពដែលមានស្រាប់។ សម្រាប់ហេតុផលដែលមិនស្គាល់មួយចំនួន មូលដ្ឋានទិន្នន័យ quay.io ត្រូវបានរារាំងបន្ទាប់ពីធ្វើមាត្រដ្ឋានសេវាកម្មដល់សមត្ថភាពពេញលេញ។

«តើមានអ្វីផ្លាស់ប្តូរ?" - នេះគឺជាសំណួរដំបូងដែលជាធម្មតាត្រូវបានសួរនៅក្នុងករណីបែបនេះ។ យើងបានកត់សម្គាល់ឃើញថាមិនយូរប៉ុន្មានមុនពេលបញ្ហានេះ ចង្កោម OpenShift Dedicated (ដែលដំណើរការ quay.io) បានចាប់ផ្តើមធ្វើបច្ចុប្បន្នភាពទៅកំណែ 4.3.19 ។ ចាប់តាំងពី quay.io ដំណើរការលើ Red Hat OpenShift Dedicated (OSD) ការធ្វើបច្ចុប្បន្នភាពជាប្រចាំគឺជាទម្លាប់ ហើយមិនដែលបង្កបញ្ហាឡើយ។ ជាងនេះទៅទៀត ក្នុងរយៈពេលប្រាំមួយខែមុន យើងបានធ្វើឱ្យប្រសើរឡើងនូវចង្កោម Quay ជាច្រើនដងដោយមិនមានការរំខានណាមួយនៅក្នុងសេវាកម្ម។

ខណៈពេលដែលយើងកំពុងព្យាយាមស្ដារសេវាកម្មនេះ វិស្វករផ្សេងទៀតបានចាប់ផ្តើមរៀបចំ OSD cluster ថ្មីជាមួយនឹងកំណែមុនរបស់កម្មវិធី ដូច្នេះប្រសិនបើមានអ្វីកើតឡើង ពួកគេអាចដាក់ពង្រាយអ្វីគ្រប់យ៉ាងនៅលើវា។

ការវិភាគមូលហេតុ

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

យើងក៏បានព្យាយាមកំណត់អត្តសញ្ញាណគំរូមួយនៅក្នុងចរាចរណ៍មូលដ្ឋានទិន្នន័យដែលអាចបណ្តាលឱ្យមានការរអិលបាក់ដីនេះ។ ទោះយ៉ាងណាក៏ដោយ យើងមិនអាចរកឃើញលំនាំណាមួយនៅក្នុងកំណត់ហេតុនោះទេ។ ខណៈពេលដែលកំពុងរង់ចាំសម្រាប់ចង្កោមថ្មីជាមួយ OSD 4.3.18 រួចរាល់ យើងបានបន្តព្យាយាមបើកដំណើរការ quay.io pods ។ រាល់ពេលដែលក្រុមឈានដល់សមត្ថភាពពេញលេញ មូលដ្ឋានទិន្នន័យនឹងបង្កក។ នេះមានន័យថាវាចាំបាច់ដើម្បីចាប់ផ្តើមឧទាហរណ៍ RDS ឡើងវិញបន្ថែមលើ quay.io pods ទាំងអស់។

នៅពេលល្ងាច យើងបានធ្វើឱ្យសេវាកម្មមានស្ថេរភាពនៅក្នុងរបៀបបានតែអាន ហើយបានបិទមុខងារមិនសំខាន់ជាច្រើនតាមដែលអាចធ្វើទៅបាន (ឧទាហរណ៍ ការប្រមូលសំរាម namespace) ដើម្បីកាត់បន្ថយការផ្ទុកនៅលើមូលដ្ឋានទិន្នន័យ។ ការបង្កកបានឈប់ ប៉ុន្តែហេតុផលមិនត្រូវបានរកឃើញទេ។. ចង្កោម OSD ថ្មីបានត្រៀមរួចរាល់ ហើយយើងបានផ្ទេរសេវាកម្ម ទំនាក់ទំនងចរាចរណ៍ និងបន្តការត្រួតពិនិត្យ។

Quay.io ដំណើរការយ៉ាងមានស្ថេរភាពនៅលើចង្កោម OSD ថ្មី ដូច្នេះយើងត្រលប់ទៅកំណត់ហេតុមូលដ្ឋានទិន្នន័យវិញ ប៉ុន្តែមិនអាចរកឃើញការជាប់ទាក់ទងគ្នាដែលនឹងពន្យល់ពីការស្ទះនោះទេ។ វិស្វករ OpenShift បានធ្វើការជាមួយយើងដើម្បីស្វែងយល់ថាតើការផ្លាស់ប្តូរនៅក្នុង Red Hat OpenShift 4.3.19 អាចបណ្តាលឱ្យមានបញ្ហាជាមួយ Quay ដែរឬទេ។ ទោះយ៉ាងណាក៏ដោយ គ្មានអ្វីត្រូវបានរកឃើញ និង វាមិនអាចទៅរួចទេក្នុងការបង្កើតបញ្ហាឡើងវិញនៅក្នុងលក្ខខណ្ឌមន្ទីរពិសោធន៍.

ការបរាជ័យទីពីរ

នៅថ្ងៃទី 28 ខែឧសភា មិនយូរប៉ុន្មានមុនពេលថ្ងៃត្រង់ EDT quay.io បានគាំងម្តងទៀតជាមួយនឹងរោគសញ្ញាដូចគ្នា៖ មូលដ្ឋានទិន្នន័យត្រូវបានរារាំង។ ហើយម្តងទៀត យើងបានបោះចោលរាល់កិច្ចខិតខំប្រឹងប្រែងរបស់យើង ក្នុងការស៊ើបអង្កេត។ ដំបូងបង្អស់វាចាំបាច់ដើម្បីស្តារសេវាកម្មឡើងវិញ។ ទោះយ៉ាងណាក៏ដោយ លើកនេះ ចាប់ផ្ដើម RDS ឡើងវិញ ហើយចាប់ផ្ដើម quay.io pods ឡើងវិញ មិនបានធ្វើអ្វីសោះ: ការតភ្ជាប់ផ្សេងទៀតបានគ្របដណ្តប់លើមូលដ្ឋាន។ តែ​ហេតុអ្វី?

Quay ត្រូវបានសរសេរជា Python ហើយផតនីមួយៗដំណើរការជាធុង monolithic តែមួយ។ រយៈពេលដំណើរការកុងតឺន័រដំណើរការភារកិច្ចប៉ារ៉ាឡែលជាច្រើនក្នុងពេលដំណាលគ្នា។ យើងប្រើបណ្ណាល័យ gevent ក្រោម gunicorn ដើម្បីដំណើរការសំណើគេហទំព័រ។ នៅពេលដែលសំណើមួយចូលមកក្នុង Quay (តាមរយៈ API របស់យើងផ្ទាល់ ឬតាមរយៈ Docker's API) វាត្រូវបានចាត់តាំងឱ្យបុគ្គលិក gevent ។ ជាធម្មតា បុគ្គលិកនេះគួរតែទាក់ទងមូលដ្ឋានទិន្នន័យ។ បន្ទាប់ពីការបរាជ័យលើកដំបូង យើងបានរកឃើញថា បុគ្គលិក gevent កំពុងភ្ជាប់ទៅមូលដ្ឋានទិន្នន័យដោយប្រើការកំណត់លំនាំដើម។

ដោយទទួលបានចំនួនដ៏សំខាន់នៃ Quay pods និងសំណើចូលរាប់ពាន់ក្នុងមួយវិនាទី ការភ្ជាប់មូលដ្ឋានទិន្នន័យមួយចំនួនធំអាចគ្របដណ្តប់លើឧទាហរណ៍ MySQL ។ សូមអរគុណចំពោះការត្រួតពិនិត្យ វាត្រូវបានគេដឹងថា Quay ដំណើរការជាមធ្យម 5 ពាន់សំណើក្នុងមួយវិនាទី។ ចំនួននៃការភ្ជាប់ទៅមូលដ្ឋានទិន្នន័យគឺប្រហែលដូចគ្នា។ ការតភ្ជាប់ចំនួន 5 ពាន់គឺស្ថិតនៅក្នុងសមត្ថភាពនៃឧទាហរណ៍ RDS របស់យើង (ដែលមិនអាចនិយាយបានអំពីរាប់ពាន់នាក់) ។ សម្រាប់ហេតុផលមួយចំនួន មានការកើនឡើងដែលមិនរំពឹងទុកនៅក្នុងចំនួននៃការតភ្ជាប់ទោះយ៉ាងណាក៏ដោយ យើងមិនបានកត់សម្គាល់ការជាប់ទាក់ទងណាមួយជាមួយសំណើចូលទេ។

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

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

ដោយបានគ្រប់គ្រងដើម្បីឆ្លងកាត់បញ្ហាដែលនាំទៅដល់ការទប់ស្កាត់។ យើង​មិន​បាន​រក​ឃើញ​មូលហេតុ​ពិត​ប្រាកដ​របស់​វា​ទេ។. វាត្រូវបានបញ្ជាក់ថាវាមិនទាក់ទងទៅនឹងការផ្លាស់ប្តូរណាមួយនៅក្នុង OpenShift 4.3.19 ទេចាប់តាំងពីរឿងដដែលនេះបានកើតឡើងនៅលើកំណែ 4.3.18 ដែលពីមុនបានធ្វើការជាមួយ Quay ដោយគ្មានបញ្ហាអ្វីទាំងអស់។

ច្បាស់​ណាស់​មាន​អ្វី​ផ្សេង​ទៀត​កំពុង​លាក់​ខ្លួន​ក្នុង​ចង្កោម។

ការសិក្សាលម្អិត

Quay.io បានប្រើការកំណត់លំនាំដើមដើម្បីភ្ជាប់ទៅមូលដ្ឋានទិន្នន័យសម្រាប់រយៈពេលប្រាំមួយឆ្នាំដោយគ្មានបញ្ហាអ្វីទាំងអស់។ តើមានអ្វីផ្លាស់ប្តូរ? វាច្បាស់ណាស់ថាគ្រប់ពេលវេលាចរាចរណ៍នៅលើ quay.io ត្រូវបានកើនឡើងជាលំដាប់។ ក្នុងករណីរបស់យើង វាមើលទៅហាក់បីដូចជាតម្លៃកម្រិតមួយត្រូវបានឈានដល់ ដែលដើរតួជាគន្លឹះសម្រាប់ការភ្ជាប់ទំនាក់ទំនង។ យើងបានបន្តសិក្សាកំណត់ហេតុមូលដ្ឋានទិន្នន័យបន្ទាប់ពីការបរាជ័យលើកទីពីរ ប៉ុន្តែមិនបានរកឃើញគំរូ ឬទំនាក់ទំនងជាក់ស្តែងណាមួយឡើយ។

ក្នុងពេលជាមួយគ្នានេះ ក្រុមការងារ SRE បាននិងកំពុងធ្វើការលើការកែលម្អលើការសង្កេតលើសំណើរបស់ Quay និងសុខភាពសេវាកម្មទាំងមូល។ មាត្រដ្ឋាន និងផ្ទាំងគ្រប់គ្រងថ្មីត្រូវបានដាក់ពង្រាយដោយបង្ហាញពីផ្នែកណាមួយនៃ Quay ដែលត្រូវបានទាមទារច្រើនបំផុតពីអតិថិជន។

Quay.io ដំណើរការល្អរហូតដល់ថ្ងៃទី 9 ខែមិថុនា។ នៅព្រឹកនេះ (EDT) យើងបានឃើញការកើនឡើងគួរឱ្យកត់សម្គាល់នៃចំនួននៃការភ្ជាប់មូលដ្ឋានទិន្នន័យ។ លើកនេះមិនមានពេលសម្រាកទេ។ចាប់តាំងពីប៉ារ៉ាម៉ែត្រថ្មីកំណត់ចំនួនរបស់ពួកគេ និងមិនអនុញ្ញាតឱ្យពួកគេលើសពី MySQL ឆ្លងកាត់។ ទោះយ៉ាងណាក៏ដោយ ប្រហែលកន្លះម៉ោង អ្នកប្រើប្រាស់ជាច្រើនបានកត់សម្គាល់ឃើញថា ដំណើរការយឺតរបស់ quay.io។ យើងបានប្រមូលទិន្នន័យដែលអាចធ្វើបានទាំងអស់យ៉ាងឆាប់រហ័សដោយប្រើឧបករណ៍ត្រួតពិនិត្យបន្ថែម។ រំពេចនោះមានគំរូមួយបានលេចចេញមក។

មុនពេលមានការកើនឡើងនៃការតភ្ជាប់ សំណើមួយចំនួនធំត្រូវបានធ្វើឡើងចំពោះ App Registry API. App Registry គឺជាមុខងារដែលគេស្គាល់តិចតួចរបស់ quay.io ។ វាអនុញ្ញាតឱ្យអ្នករក្សាទុកអ្វីៗដូចជាតារាង Helm និងធុងដែលមានទិន្នន័យមេតាសម្បូរបែប។ អ្នកប្រើប្រាស់ quay.io ភាគច្រើនមិនដំណើរការជាមួយមុខងារនេះទេ ប៉ុន្តែ Red Hat OpenShift ប្រើវាយ៉ាងសកម្ម។ OperatorHub ជាផ្នែកនៃ OpenShift រក្សាទុកប្រតិបត្តិករទាំងអស់នៅក្នុង App Registry ។ ប្រតិបត្តិករទាំងនេះបង្កើតជាមូលដ្ឋានសម្រាប់ប្រព័ន្ធអេកូបន្ទុកការងារ OpenShift និងគំរូប្រតិបត្តិការដែលផ្តោតលើដៃគូ (ប្រតិបត្តិការថ្ងៃទី 2) ។

ចង្កោម OpenShift 4 នីមួយៗប្រើប្រតិបត្តិករពី OperatorHub ដែលភ្ជាប់មកជាមួយដើម្បីបោះពុម្ពផ្សាយកាតាឡុកនៃប្រតិបត្តិករដែលមានសម្រាប់ដំឡើង និងផ្តល់ការអាប់ដេតដល់អ្នកដែលបានដំឡើងរួចហើយ។ ជាមួយនឹងការកើនឡើងនូវប្រជាប្រិយភាពនៃ OpenShift 4 ចំនួននៃចង្កោមនៅលើវានៅជុំវិញពិភពលោកក៏បានកើនឡើងផងដែរ។ ចង្កោមនីមួយៗទាំងនេះទាញយកមាតិកាប្រតិបត្តិករដើម្បីដំណើរការ OperatorHub ដែលភ្ជាប់មកជាមួយ ដោយប្រើ App Registry នៅខាងក្នុង quay.io ជាផ្នែកខាងក្រោយ។ ក្នុងការស្វែងរកប្រភពនៃបញ្ហា យើងបានខកខាននូវការពិតដែលថានៅពេលដែល OpenShift កាន់តែមានប្រជាប្រិយភាពបន្តិចម្តងៗ ការផ្ទុកនៅលើមុខងារ quay.io ដ៏កម្រមួយក៏កើនឡើងផងដែរ។.

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

ការលុបបំបាត់បុព្វហេតុ

នៅសប្តាហ៍បន្ទាប់ យើងបានចំណាយលើការបង្កើនប្រសិទ្ធភាពកូដនៃការចុះបញ្ជីកម្មវិធីខ្លួនវា និងបរិស្ថានរបស់វា។ សំណួរ SQL ដែលមិនមានប្រសិទ្ធភាពច្បាស់លាស់ត្រូវបានដំណើរការឡើងវិញ ហើយការហៅពាក្យបញ្ជាដែលមិនចាំបាច់ត្រូវបានលុបចោល tar (វាត្រូវបានដំណើរការរាល់ពេលដែល blobs ត្រូវបានទាញយក) ឃ្លាំងសម្ងាត់ត្រូវបានបន្ថែមគ្រប់ទីកន្លែងដែលអាចធ្វើទៅបាន។ បន្ទាប់មកយើងបានធ្វើការសាកល្បងដំណើរការយ៉ាងទូលំទូលាយ និងប្រៀបធៀបល្បឿននៃការចុះបញ្ជីកម្មវិធីមុន និងក្រោយការផ្លាស់ប្តូរ។

សំណើ API ដែលពីមុនចំណាយពេលដល់ទៅកន្លះនាទីឥឡូវនេះត្រូវបានបញ្ចប់ជាមីលីវិនាទី. នៅសប្តាហ៍បន្ទាប់ យើងបានដាក់ពង្រាយការផ្លាស់ប្តូរទៅផលិតកម្ម ហើយចាប់តាំងពីពេលនោះមក quay.io បានដំណើរការយ៉ាងមានស្ថេរភាព។ ក្នុងអំឡុងពេលនេះ មានចរាចរណ៍កើនឡើងយ៉ាងខ្លាំងនៅលើចំណុចបញ្ចប់នៃការចុះឈ្មោះកម្មវិធី ប៉ុន្តែការកែលម្អបានរារាំងការដាច់ទិន្នន័យទិន្នន័យ។

តើយើងបានរៀនអ្វីខ្លះ?

វាច្បាស់ណាស់ថាសេវាណាមួយព្យាយាមជៀសវាងពេលទំនេរ។ ក្នុងករណីរបស់យើង យើងជឿថាការដាច់ចរន្តអគ្គិសនីថ្មីៗនេះបានជួយធ្វើឱ្យ quay.io កាន់តែប្រសើរឡើង។ យើងបានរៀនមេរៀនសំខាន់ៗមួយចំនួនដែលយើងចង់ចែករំលែក៖

1. ទិន្នន័យអំពីអ្នកណាដែលប្រើប្រាស់សេវាកម្មរបស់អ្នក និងរបៀបគឺមិនដែលនាំអោយ. ដោយសារតែ Quay "ទើបតែបានដំណើរការ" យើងមិនដែលត្រូវចំណាយពេលបង្កើនប្រសិទ្ធភាពចរាចរណ៍ និងគ្រប់គ្រងបន្ទុកនោះទេ។ ទាំងអស់នេះបានបង្កើតនូវអារម្មណ៍សុវត្ថិភាពមិនពិត ដែលសេវាកម្មនេះអាចធ្វើមាត្រដ្ឋានដោយគ្មានកំណត់។
2. នៅពេលដែលសេវាកម្មធ្លាក់ចុះ។ ការទទួលបានវាមកវិញ និងដំណើរការគឺជាអាទិភាពកំពូល។. ដោយសារតែ Quay បានបន្តរងទុក្ខពីឃ្លាំងទិន្នន័យជាប់សោកំឡុងពេលដាច់ភ្លើងដំបូង នីតិវិធីស្តង់ដាររបស់យើងមិនមានប្រសិទ្ធិភាពដូចបំណងទេ ហើយយើងមិនអាចស្ដារសេវាកម្មឡើងវិញដោយប្រើពួកវាបានទេ។ នេះបាននាំឱ្យមានស្ថានភាពមួយដែលចំណាយពេលវិភាគ និងប្រមូលទិន្នន័យក្នុងក្តីសង្ឃឹមក្នុងការស្វែងរកមូលហេតុដើម - ជំនួសឱ្យការផ្តោតលើកិច្ចខិតខំប្រឹងប្រែងទាំងអស់លើការស្ដារមុខងារឡើងវិញ។
3. វាយតម្លៃផលប៉ះពាល់នៃមុខងារសេវាកម្មនីមួយៗ. អតិថិជនកម្របានប្រើការចុះបញ្ជីកម្មវិធី ដូច្នេះវាមិនមែនជាអាទិភាពសម្រាប់ក្រុមរបស់យើងទេ។ នៅពេលដែលលក្ខណៈពិសេសផលិតផលមួយចំនួនត្រូវបានប្រើប្រាស់ទទេ កំហុសរបស់ពួកគេកម្រនឹងលេចឡើង ហើយអ្នកអភិវឌ្ឍន៍ឈប់ត្រួតពិនិត្យកូដ។ វាងាយនឹងធ្លាក់ចូលទៅក្នុងការយល់ខុសថានេះជារបៀបដែលវាគួរតែជា — រហូតដល់ភ្លាមៗនោះមុខងារនោះរកឃើញខ្លួនឯងនៅចំកណ្តាលនៃឧប្បត្តិហេតុធំមួយ។

តើមានអ្វីជាបន្ទាប់?

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

1. ដាក់ពង្រាយការចម្លងមូលដ្ឋានទិន្នន័យបានតែអាន ដើម្បីជួយឱ្យសេវាកម្មដោះស្រាយចរាចរណ៍សមស្របក្នុងករណីមានបញ្ហាជាមួយឧទាហរណ៍ RDS ចម្បង។
2. ការធ្វើបច្ចុប្បន្នភាពឧទាហរណ៍ RDS ។ កំណែបច្ចុប្បន្នខ្លួនឯងមិនមែនជាបញ្ហាទេ។ ផ្ទុយទៅវិញ យើងគ្រាន់តែចង់ដកផ្លូវមិនពិត (ដែលយើងធ្វើតាមអំឡុងពេលបរាជ័យ)។ ការរក្សាកម្មវិធីឱ្យទាន់សម័យនឹងលុបបំបាត់កត្តាមួយផ្សេងទៀតនៅក្នុងព្រឹត្តិការណ៍នៃការដាច់នាពេលអនាគត។
3. ឃ្លាំងសម្ងាត់បន្ថែមនៅទូទាំងចង្កោមទាំងមូល។ យើងបន្តស្វែងរកកន្លែងដែលឃ្លាំងសម្ងាត់អាចកាត់បន្ថយការផ្ទុកនៅលើមូលដ្ឋានទិន្នន័យ។
4. ការបន្ថែមជញ្ជាំងភ្លើងកម្មវិធីបណ្ដាញ (WAF) ដើម្បីមើលថាអ្នកណាកំពុងភ្ជាប់ទៅ quay.io និងមូលហេតុ។
5. ចាប់ផ្តើមជាមួយនឹងការចេញផ្សាយលើកក្រោយ ចង្កោម Red Hat OpenShift នឹងបោះបង់ចោលការចុះឈ្មោះកម្មវិធីក្នុងការពេញចិត្តនៃកាតាឡុកប្រតិបត្តិករដោយផ្អែកលើរូបភាពកុងតឺន័រដែលមាននៅលើ quay.io ។
6. ការជំនួសរយៈពេលវែងសម្រាប់ការចុះបញ្ជីកម្មវិធីអាចជាការគាំទ្រសម្រាប់ការបញ្ជាក់វត្ថុបុរាណ Open Container Initiative (OCI) ។ បច្ចុប្បន្នវាត្រូវបានអនុវត្តជាមុខងារ Quay ដើម ហើយនឹងមានសម្រាប់អ្នកប្រើប្រាស់នៅពេលដែលការបញ្ជាក់ខ្លួនឯងត្រូវបានបញ្ចប់។

ទាំងអស់ខាងលើគឺជាផ្នែកមួយនៃការវិនិយោគដែលកំពុងបន្តរបស់ Red Hat នៅក្នុង quay.io នៅពេលដែលយើងផ្លាស់ប្តូរពីក្រុម "ចាប់ផ្តើមអាជីវកម្ម" តូចមួយទៅកាន់វេទិកាដែលជំរុញដោយ SRE ចាស់ទុំ។ យើងដឹងថាអតិថិជនរបស់យើងជាច្រើនពឹងផ្អែកលើ quay.io ក្នុងការងារប្រចាំថ្ងៃរបស់ពួកគេ (រួមទាំង Red Hat!) ហើយយើងព្យាយាមធ្វើឱ្យមានតម្លាភាពតាមដែលអាចធ្វើទៅបានអំពីការដាច់ចរន្តអគ្គិសនី និងការខិតខំប្រឹងប្រែងជាបន្តបន្ទាប់ដើម្បីកែលម្អ។

PS ពីអ្នកបកប្រែ

សូមអានផងដែរនៅលើប្លក់របស់យើង៖

• «កូដចុះបញ្ជីប្រភពបើកចំហ Red Hat សម្រាប់រូបភាពកុងតឺន័រ CoreOS - Quay»
• «រឿងជាក់ស្តែងពីជីវិតប្រចាំថ្ងៃរបស់ SRE របស់យើង។ ផ្នែកទី 2»
• «របៀបដែលអាទិភាពរបស់ pod នៅក្នុង Kubernetes បណ្តាលឱ្យមានការខកខាននៅ Grafana Labs"។

ប្រភព: www.habr.com