DEVOXX ចក្រភពអង់គ្លេស។ Kubernetes នៅក្នុងផលិតកម្ម៖ ការដាក់ពង្រាយពណ៌ខៀវ/បៃតង ការធ្វើមាត្រដ្ឋានដោយស្វ័យប្រវត្តិ និងការដាក់ពង្រាយស្វ័យប្រវត្តិកម្ម។ ផ្នែកទី 2

Kubernetes គឺជាឧបករណ៍ដ៏ល្អសម្រាប់ដំណើរការ Docker containers នៅក្នុងបរិយាកាសផលិតកម្មដែលមានចង្កោម។ ទោះយ៉ាងណាក៏ដោយ មានបញ្ហាដែល Kubernetes មិនអាចដោះស្រាយបាន។ សម្រាប់ការដាក់ពង្រាយផលិតកម្មញឹកញាប់ យើងត្រូវការការដាក់ពង្រាយពណ៌ខៀវ/បៃតងដោយស្វ័យប្រវត្តិយ៉ាងពេញលេញ ដើម្បីជៀសវាងការខកខានក្នុងដំណើរការ ដែលក៏ត្រូវការដោះស្រាយសំណើ HTTP ខាងក្រៅ និងអនុវត្តការបិទ SSL ផងដែរ។ វាទាមទារការរួមបញ្ចូលជាមួយឧបករណ៍ផ្ទុកតុល្យភាពដូចជា ha-proxy ។ បញ្ហាប្រឈមមួយទៀតគឺការធ្វើមាត្រដ្ឋានពាក់កណ្តាលស្វ័យប្រវត្តិនៃចង្កោម Kubernetes ខ្លួនវានៅពេលដំណើរការក្នុងបរិយាកាសពពក ឧទាហរណ៍ ការធ្វើមាត្រដ្ឋានចុះក្រោមផ្នែកខ្លះនៃចង្កោមនៅពេលយប់។

ខណៈពេលដែល Kubernetes មិនមានលក្ខណៈពិសេសទាំងនេះចេញពីប្រអប់នោះ វាបានផ្តល់នូវ API ដែលអ្នកអាចប្រើដើម្បីដោះស្រាយបញ្ហាស្រដៀងគ្នានេះ។ ឧបករណ៍សម្រាប់ការដាក់ពង្រាយពណ៌ខៀវ/បៃតងដោយស្វ័យប្រវត្តិ និងការធ្វើមាត្រដ្ឋាននៃចង្កោម Kubernetes ត្រូវបានបង្កើតឡើងជាផ្នែកមួយនៃគម្រោង Cloud RTI ដែលត្រូវបានបង្កើតឡើងដោយផ្អែកលើប្រភពបើកចំហ។

អត្ថបទនេះ ជាប្រតិចារឹកវីដេអូ បង្ហាញអ្នកពីរបៀបដំឡើង Kubernetes រួមជាមួយនឹងសមាសធាតុប្រភពបើកចំហផ្សេងទៀត ដើម្បីបង្កើតបរិយាកាសដែលត្រៀមរួចជាស្រេចក្នុងការផលិត ដែលទទួលយកកូដពី git commit ដោយគ្មានពេលវេលារងចាំក្នុងផលិតកម្ម។

DEVOXX ចក្រភពអង់គ្លេស។ Kubernetes នៅក្នុងផលិតកម្ម៖ ការដាក់ពង្រាយពណ៌ខៀវ/បៃតង ការធ្វើមាត្រដ្ឋានដោយស្វ័យប្រវត្តិ និងការដាក់ពង្រាយស្វ័យប្រវត្តិកម្ម។ ផ្នែកទី 1

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

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

នេះគឺជា REST ដូច្នេះអ្នកអាចប្រើភាសា ឬឧបករណ៍ណាមួយដើម្បីធ្វើការជាមួយ API នេះ ប៉ុន្តែជីវិតរបស់អ្នកនឹងត្រូវបានធ្វើឱ្យកាន់តែងាយស្រួលដោយបណ្ណាល័យផ្ទាល់ខ្លួន។ ក្រុមរបស់ខ្ញុំបានសរសេរបណ្ណាល័យបែបនេះចំនួន 2៖ មួយសម្រាប់ Java/OSGi និងមួយទៀតសម្រាប់ Go ។ ទីពីរ​មិន​ត្រូវ​បាន​គេ​ប្រើ​ញឹកញាប់​ទេ ប៉ុន្តែ​ក្នុង​ករណី​ណា​មួយ​ដែល​អ្នក​មាន​របស់​មាន​ប្រយោជន៍​ទាំង​នេះ​នៅ​ក្នុង​ការ​ចោល​របស់​អ្នក។ ពួកគេគឺជាគម្រោងប្រភពបើកចំហដែលមានអាជ្ញាប័ណ្ណដោយផ្នែក។ មានបណ្ណាល័យបែបនេះជាច្រើនសម្រាប់ភាសាផ្សេងៗគ្នា ដូច្នេះអ្នកអាចជ្រើសរើសអ្វីដែលសាកសមនឹងអ្នកបំផុត។

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

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

យន្តការដាក់ពង្រាយពណ៌ខៀវ/បៃតងមើលទៅដូចនេះ។ យើងទទួលបានចរាចរណ៍សម្រាប់កម្មវិធីរបស់យើងតាមរយៈ ha-proxy ដែលបញ្ជូនវាទៅដំណើរការចម្លងនៃកម្មវិធីនៃកំណែដូចគ្នា។

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

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

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

បន្ទាប់ពីប្រព័ន្ធផ្ទៀងផ្ទាត់ថាការចម្លងដែលបានធ្វើបច្ចុប្បន្នភាពទាំងអស់កំពុងដំណើរការ អ្នកចែកចាយនឹងអាប់ដេតការកំណត់រចនាសម្ព័ន្ធ និងឆ្លងកាត់ confd ត្រឹមត្រូវ ដែលនឹងកំណត់រចនាសម្ព័ន្ធ ha-proxy ឡើងវិញ។

មានតែបន្ទាប់ពីនេះទេដែលនឹងចរាចរត្រូវបានដឹកនាំទៅកាន់ផតថលជាមួយនឹងការចម្លងនៃកំណែថ្មី ហើយផតចាស់នឹងរលាយបាត់។

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

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

ដូច្នេះ រឿងដំបូងដែល Deployer ធ្វើគឺបង្កើតឧបករណ៍បញ្ជាចម្លង RC ដោយប្រើ Kubernetes API។ API នេះបង្កើតផត និងសេវាកម្មសម្រាប់ការដាក់ពង្រាយបន្ថែមទៀត ពោលគឺវាបង្កើតចង្កោមថ្មីទាំងស្រុងសម្រាប់កម្មវិធីរបស់យើង។ ដរាបណា RC ត្រូវបានគេជឿជាក់ថាការចម្លងបានចាប់ផ្តើម វានឹងធ្វើការត្រួតពិនិត្យសុខភាពលើមុខងាររបស់វា។ ដើម្បីធ្វើដូច្នេះ Deployer ប្រើពាក្យបញ្ជា GET /health ។ វាដំណើរការសមាសធាតុស្កេនដែលសមស្រប និងពិនិត្យធាតុទាំងអស់ដែលគាំទ្រប្រតិបត្តិការនៃចង្កោម។

បន្ទាប់ពីផតទាំងអស់បានរាយការណ៍អំពីសុខភាពរបស់ពួកគេ អ្នកចែកចាយបង្កើតធាតុកំណត់រចនាសម្ព័ន្ធថ្មី - ឃ្លាំងផ្ទុកចែកចាយ etcd ដែលត្រូវបានប្រើខាងក្នុងដោយ Kubernetes រួមទាំងការរក្សាទុកការកំណត់រចនាសម្ព័ន្ធផ្ទុកតុល្យភាព។ យើងសរសេរទិន្នន័យទៅ etcd និងឧបករណ៍តូចមួយហៅថា confd monitors etcd សម្រាប់ទិន្នន័យថ្មី។

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

ដូចដែលអ្នកអាចឃើញទោះបីជាមានសមាសធាតុសម្បូរបែបក៏ដោយក៏មិនមានអ្វីស្មុគស្មាញនៅទីនេះដែរ។ អ្នកគ្រាន់តែត្រូវយកចិត្តទុកដាក់បន្ថែមទៀតចំពោះ API និងល។ ខ្ញុំចង់ប្រាប់អ្នកអំពីអ្នកដាក់ពង្រាយប្រភពបើកចំហដែលយើងខ្លួនយើងប្រើ - Amdatu Kubernetes Deployer ។

វាគឺជាឧបករណ៍សម្រាប់រៀបចំការដាក់ឱ្យប្រើប្រាស់ Kubernetes និងមានលក្ខណៈពិសេសដូចខាងក្រោម៖

• ការដាក់ពង្រាយពណ៌ខៀវ / បៃតង;
• រៀបចំតុល្យភាពបន្ទុកខាងក្រៅ;
• ការគ្រប់គ្រងការពិពណ៌នាអំពីការដាក់ពង្រាយ;
• គ្រប់គ្រងការអនុវត្តជាក់ស្តែង;
• ពិនិត្យមុខងារនៃការពិនិត្យសុខភាពកំឡុងពេលដាក់ពង្រាយ;
• ការអនុវត្តអថេរបរិស្ថានទៅជាផត។

Deployer នេះត្រូវបានបង្កើតឡើងនៅលើកំពូលនៃ Kubernetes API និងផ្តល់នូវ REST API សម្រាប់គ្រប់គ្រងចំណុចទាញ និងការដាក់ឱ្យប្រើប្រាស់ ព្រមទាំង Websocket API សម្រាប់ការផ្សាយកំណត់ហេតុក្នុងអំឡុងពេលដំណើរការដាក់ឱ្យប្រើប្រាស់។

វាដាក់ទិន្នន័យការកំណត់រចនាសម្ព័ន្ធផ្ទុកតុល្យភាពទៅក្នុង etcd ដូច្នេះអ្នកមិនចាំបាច់ប្រើ ha-proxy ជាមួយនឹងការគាំទ្រក្រៅប្រអប់នោះទេ ប៉ុន្តែងាយស្រួលប្រើឯកសារកំណត់រចនាសម្ព័ន្ធផ្ទុកតុល្យភាពរបស់អ្នក។ Amdatu Deployer ត្រូវបានសរសេរនៅក្នុង Go ដូចជា Kubernetes ខ្លួនឯង ហើយត្រូវបានផ្តល់អាជ្ញាប័ណ្ណដោយ Apache ។

មុនពេលដែលខ្ញុំចាប់ផ្តើមប្រើកំណែនៃអ្នកដាក់ពង្រាយនេះ ខ្ញុំបានប្រើឧបករណ៍ពិពណ៌នាអំពីការដាក់ពង្រាយខាងក្រោម ដែលបញ្ជាក់ពីប៉ារ៉ាម៉ែត្រដែលខ្ញុំត្រូវការ។

ប៉ារ៉ាម៉ែត្រសំខាន់មួយនៃកូដនេះគឺដើម្បីបើកទង់ "useHealthCheck" ។ យើងត្រូវបញ្ជាក់ថាការត្រួតពិនិត្យអនាម័យត្រូវតែធ្វើឡើងក្នុងអំឡុងពេលដំណើរការដាក់ពង្រាយ។ ការ​កំណត់​នេះ​អាច​ត្រូវ​បាន​បិទ​នៅ​ពេល​ការ​ដាក់​ពង្រាយ​ប្រើ​ធុង​ភាគី​ទី​បី​ដែល​មិន​ត្រូវ​ការ​ផ្ទៀងផ្ទាត់។ អ្នកពណ៌នានេះក៏បង្ហាញពីចំនួននៃការចម្លង និង URL ខាងមុខដែល ha-proxy ត្រូវការ។ នៅចុងបញ្ចប់គឺជាទង់បញ្ជាក់ pod "podspec" ដែលហៅ Kubernetes សម្រាប់ព័ត៌មានអំពីការកំណត់រចនាសម្ព័ន្ធច្រក រូបភាព។ល។ នេះគឺជាការពិពណ៌នា JSON ដ៏សាមញ្ញ។

ឧបករណ៍មួយទៀតដែលជាផ្នែកមួយនៃគម្រោង Amdatu ប្រភពបើកចំហគឺ Deploymentctl ។ វាមាន UI សម្រាប់កំណត់រចនាសម្ព័ន្ធការដាក់ឱ្យប្រើប្រាស់ រក្សាទុកប្រវត្តិនៃការដាក់ឱ្យប្រើប្រាស់ និងមាន webhooks សម្រាប់ callbacks ពីអ្នកប្រើប្រាស់ និងអ្នកអភិវឌ្ឍន៍ភាគីទីបី។ អ្នកប្រហែលជាមិនប្រើ UI ទេ ដោយសារ Amdatu Deployer ខ្លួនវាគឺជា REST API ប៉ុន្តែចំណុចប្រទាក់នេះអាចធ្វើអោយការដាក់ពង្រាយកាន់តែងាយស្រួលសម្រាប់អ្នកដោយមិនពាក់ព័ន្ធនឹង API ណាមួយឡើយ។ Deploymentctl ត្រូវបានសរសេរក្នុង OSGi/Vertx ដោយប្រើ Angular 2។

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

នៅទីនេះយើងកំពុងបង្កើតម៉ាស៊ីនមេ HTTP ដែលឆ្លើយតបតែចំពោះ / សុខភាព ដូច្នេះកម្មវិធីនេះគ្រាន់តែធ្វើតេស្តពិនិត្យសុខភាពប៉ុណ្ណោះ ហើយគ្មានអ្វីផ្សេងទៀតទេ។ ប្រសិនបើការត្រួតពិនិត្យឆ្លងកាត់ រចនាសម្ព័ន្ធ JSON ដែលបង្ហាញខាងក្រោមត្រូវបានប្រើ។ វាមានកំណែនៃកម្មវិធីដែលនឹងត្រូវបានដាក់ឱ្យប្រើប្រាស់ដោយអ្នកដាក់ពង្រាយ សារដែលអ្នកឃើញនៅផ្នែកខាងលើនៃឯកសារ និងប្រភេទទិន្នន័យប៊ូលីន - ថាតើកម្មវិធីរបស់យើងដំណើរការឬអត់។

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

ដូច្នេះសូមចាប់ផ្តើម។ ជាដំបូង យើងពិនិត្យរកមើលវត្តមានរបស់ផតឃែរដែលកំពុងដំណើរការដោយប្រើពាក្យបញ្ជា ~ kubectl get pods ហើយផ្អែកលើអវត្តមាននៃការឆ្លើយតបពី URL ផ្នែកខាងមុខ យើងធ្វើឱ្យប្រាកដថាមិនមានការដាក់ពង្រាយបច្ចុប្បន្នកំពុងត្រូវបានធ្វើឡើងទេ។

បន្ទាប់នៅលើអេក្រង់អ្នកឃើញចំណុចប្រទាក់ Deploymentctl ដែលខ្ញុំបានលើកឡើង ដែលក្នុងនោះប៉ារ៉ាម៉ែត្រដាក់ពង្រាយត្រូវបានកំណត់៖ namespace ឈ្មោះកម្មវិធី កំណែដាក់ពង្រាយ ចំនួននៃការចម្លង URL ផ្នែកខាងមុខ ឈ្មោះកុងតឺន័រ រូបភាព ដែនកំណត់ធនធាន លេខច្រកសម្រាប់ការពិនិត្យសុខភាព។ ល។ ដែនកំណត់ធនធានមានសារៈសំខាន់ខ្លាំងណាស់ ដោយសារវាអនុញ្ញាតឱ្យអ្នកប្រើចំនួនអតិបរមានៃផ្នែករឹង។ នៅទីនេះអ្នកក៏អាចមើលកំណត់ហេតុនៃការដាក់ពង្រាយផងដែរ។

ប្រសិនបើអ្នកឥឡូវនេះម្តងទៀតនូវពាក្យបញ្ជា ~ kubectl get pods អ្នកអាចឃើញថាប្រព័ន្ធ "បង្កក" រយៈពេល 20 វិនាទី ក្នុងអំឡុងពេលដែល ha-proxy ត្រូវបានកំណត់រចនាសម្ព័ន្ធឡើងវិញ។ បន្ទាប់ពីនេះ ផតចាប់ផ្តើម ហើយការចម្លងរបស់យើងអាចមើលឃើញនៅក្នុងកំណត់ហេតុនៃការដាក់ពង្រាយ។

ខ្ញុំបានកាត់បន្ថយការរង់ចាំ 20 វិនាទីចេញពីវីដេអូ ហើយឥឡូវនេះអ្នកអាចមើលឃើញនៅលើអេក្រង់ថាកំណែដំបូងនៃកម្មវិធីត្រូវបានដាក់ពង្រាយ។ ទាំងអស់នេះត្រូវបានធ្វើដោយប្រើតែ UI ប៉ុណ្ណោះ។

ឥឡូវនេះសូមសាកល្បងកំណែទីពីរ។ ដើម្បីធ្វើដូចនេះខ្ញុំប្តូរសាររបស់កម្មវិធីពី "ជំរាបសួរ Kubernetes!" នៅលើ “Hello, Deployer!” ប្រព័ន្ធបង្កើតរូបភាពនេះ ហើយដាក់វានៅក្នុងបញ្ជីឈ្មោះ Docker បន្ទាប់ពីនោះយើងគ្រាន់តែចុចលើប៊ូតុង “Deploy” ម្តងទៀតនៅក្នុងបង្អួច Deploymentctl។ ក្នុងករណីនេះ កំណត់ហេតុនៃការដាក់ពង្រាយត្រូវបានបើកដំណើរការដោយស្វ័យប្រវត្តិតាមរបៀបដូចដែលវាបានកើតឡើងនៅពេលដាក់ពង្រាយកំណែដំបូងនៃកម្មវិធី។

ពាក្យបញ្ជា ~ kubectl get pods បង្ហាញថាបច្ចុប្បន្នមាន 2 កំណែនៃកម្មវិធីដែលកំពុងដំណើរការ ប៉ុន្តែផ្នែកខាងមុខបង្ហាញថាយើងនៅតែដំណើរការកំណែ 1 ។

តុល្យការផ្ទុករង់ចាំការត្រួតពិនិត្យសុខភាពដើម្បីបញ្ចប់ មុនពេលបញ្ជូនចរាចរទៅកាន់កំណែថ្មី។ បន្ទាប់ពី 20 វិនាទីយើងប្តូរទៅ curl ហើយឃើញថាឥឡូវនេះយើងមានកំណែ 2 នៃកម្មវិធីដែលបានដាក់ឱ្យប្រើប្រាស់ ហើយកម្មវិធីទីមួយត្រូវបានលុបចេញ។

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

ដូចដែលអ្នកអាចមើលឃើញ ការដាក់ពង្រាយឆ្លងកាត់គ្រប់ជំហានខាងលើ ហើយ~kubectl get pods បង្ហាញថា pods ទាំងពីរកំពុងដំណើរការ។ ប៉ុន្តែមិនដូចការដាក់ពង្រាយពីមុនទេ កំណត់ហេតុបង្ហាញស្ថានភាពអស់ពេល។ នោះគឺដោយសារតែការពិនិត្យសុខភាពបានបរាជ័យ កំណែថ្មីនៃកម្មវិធីមិនអាចត្រូវបានដាក់ឱ្យប្រើប្រាស់បានទេ។ ជាលទ្ធផល អ្នកឃើញថាប្រព័ន្ធបានត្រឡប់ទៅប្រើកំណែចាស់របស់កម្មវិធី ហើយកំណែថ្មីត្រូវបានលុបចោលយ៉ាងសាមញ្ញ។

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

មានរឿងតែមួយគត់ដែលអាចបរាជ័យ - ប្រសិនបើការពិនិត្យសុខភាពបានជោគជ័យ ប៉ុន្តែកម្មវិធីបរាជ័យភ្លាមៗនៅពេលដែលបន្ទុកការងារត្រូវបានអនុវត្តទៅលើវា នោះគឺជាការដួលរលំនឹងកើតឡើងតែបន្ទាប់ពីការដាក់ពង្រាយត្រូវបានបញ្ចប់។ ក្នុងករណីនេះ អ្នកនឹងត្រូវវិលត្រលប់ទៅកំណែចាស់ដោយដៃវិញ។ ដូច្នេះ យើងបានមើលពីរបៀបប្រើប្រាស់ Kubernetes ជាមួយនឹងឧបករណ៍ប្រភពបើកចំហដែលបានរចនាឡើងសម្រាប់វា។ ដំណើរការដាក់ពង្រាយនឹងកាន់តែងាយស្រួលប្រសិនបើអ្នកបង្កើតឧបករណ៍ទាំងនេះទៅក្នុង Build/Deploy pipelines របស់អ្នក។ ក្នុងពេលជាមួយគ្នានេះ ដើម្បីចាប់ផ្តើមដាក់ឱ្យប្រើប្រាស់ អ្នកអាចប្រើចំណុចប្រទាក់អ្នកប្រើ ឬធ្វើឱ្យដំណើរការនេះដោយស្វ័យប្រវត្តិទាំងស្រុងដោយប្រើឧទាហរណ៍ ប្តេជ្ញាធ្វើជាម្ចាស់។

Build Server របស់យើងនឹងបង្កើតរូបភាព Docker រុញវាចូលទៅក្នុង Docker Hub ឬអ្វីក៏ដោយដែលអ្នកប្រើ។ Docker Hub គាំទ្រ webhook ដូច្នេះយើងអាចចាប់ផ្តើមការដាក់ពង្រាយពីចម្ងាយតាមរយៈ Deployer តាមវិធីដែលបានបង្ហាញខាងលើ។ វិធីនេះអ្នកអាចធ្វើស្វ័យប្រវត្តិកម្មពេញលេញនៃការដាក់ឱ្យប្រើប្រាស់កម្មវិធីរបស់អ្នកទៅផលិតកម្មដែលមានសក្តានុពល។

ចូរបន្តទៅប្រធានបទបន្ទាប់ - ការធ្វើមាត្រដ្ឋានក្រុម Kubernetes ។ ចំណាំថាពាក្យបញ្ជា kubectl គឺជាពាក្យបញ្ជាធ្វើមាត្រដ្ឋាន។ ដោយមានជំនួយកាន់តែច្រើន យើងអាចបង្កើនចំនួននៃការចម្លងនៅក្នុងចង្កោមដែលមានស្រាប់របស់យើងយ៉ាងងាយស្រួល។ ទោះជាយ៉ាងណាក៏ដោយ នៅក្នុងការអនុវត្តជាធម្មតា យើងចង់បង្កើនចំនួនថ្នាំងជាជាងផត។

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

នេះអាចជាបញ្ហាប្រឈម ព្រោះមិនថាយើងប្រើ Amazon ឬសេវាកម្មពពកផ្សេងទៀត Kubernetes មិនដឹងអ្វីទាំងអស់អំពីចំនួនម៉ាស៊ីនដែលកំពុងប្រើ។ វាខ្វះឧបករណ៍ដែលអនុញ្ញាតឱ្យអ្នកធ្វើមាត្រដ្ឋានប្រព័ន្ធនៅកម្រិតថ្នាំង។

ដូច្នេះយើងនឹងត្រូវថែរក្សាទាំងថ្នាំងនិងផត។ យើងអាចធ្វើមាត្រដ្ឋាននៃការចាប់ផ្តើមថ្នាំងថ្មីបានយ៉ាងងាយស្រួលដោយប្រើ AWS API និងម៉ាស៊ីនក្រុម Scaling ដើម្បីកំណត់រចនាសម្ព័ន្ធចំនួនថ្នាំងកម្មករ Kubernetes ។ អ្នកក៏អាចប្រើ cloud-init ឬស្គ្រីបស្រដៀងគ្នា ដើម្បីចុះឈ្មោះថ្នាំងនៅក្នុងចង្កោម Kubernetes ផងដែរ។

ម៉ាស៊ីនថ្មីចាប់ផ្តើមនៅក្នុងក្រុមធ្វើមាត្រដ្ឋាន ផ្តួចផ្តើមខ្លួនឯងជាថ្នាំង ចុះឈ្មោះក្នុងបញ្ជីឈ្មោះមេ ហើយចាប់ផ្តើមដំណើរការ។ បន្ទាប់ពីនេះ អ្នកអាចបង្កើនចំនួនចម្លងសម្រាប់ប្រើលើថ្នាំងលទ្ធផល។ ការធ្វើមាត្រដ្ឋានចុះក្រោមតម្រូវឱ្យមានការខិតខំប្រឹងប្រែងបន្ថែមទៀត ព្រោះអ្នកត្រូវប្រាកដថាជំហានបែបនេះមិននាំទៅដល់ការបំផ្លាញកម្មវិធីដែលកំពុងដំណើរការរួចហើយបន្ទាប់ពីបិទម៉ាស៊ីន "មិនចាំបាច់"។ ដើម្បីទប់ស្កាត់សេណារីយ៉ូបែបនេះ អ្នកត្រូវកំណត់ថ្នាំងទៅជាស្ថានភាព "មិនអាចកំណត់ពេលបាន"។ នេះមានន័យថា កម្មវិធីកំណត់ពេលលំនាំដើមនឹងមិនអើពើថ្នាំងទាំងនេះ នៅពេលកំណត់ពេលកំណត់កម្មវិធី DaemonSet pods ។ កម្មវិធីកំណត់ពេលនឹងមិនលុបអ្វីចេញពីម៉ាស៊ីនមេទាំងនេះទេ ប៉ុន្តែក៏នឹងមិនដំណើរការធុងថ្មីនៅទីនោះដែរ។ ជំហានបន្ទាប់គឺការបណ្តេញថ្នាំងបង្ហូរ ពោលគឺផ្ទេរផតដែលកំពុងដំណើរការពីវាទៅម៉ាស៊ីនផ្សេងទៀត ឬថ្នាំងផ្សេងទៀតដែលមានសមត្ថភាពគ្រប់គ្រាន់សម្រាប់ការនេះ។ នៅពេលដែលអ្នកបានធានាថាលែងមានកុងតឺន័រនៅលើថ្នាំងទាំងនេះទៀតហើយ អ្នកអាចយកវាចេញពី Kubernetes បាន។ បន្ទាប់ពីនេះ ពួកវានឹងលែងមានសម្រាប់ Kubernetes។ បន្ទាប់មកអ្នកត្រូវប្រើ AWS API ដើម្បីបិទថ្នាំង ឬម៉ាស៊ីនដែលមិនចាំបាច់។
អ្នកអាចប្រើ Amdatu Scalerd ដែលជាឧបករណ៍ធ្វើមាត្រដ្ឋានប្រភពបើកចំហមួយផ្សេងទៀតស្រដៀងនឹង AWS API ។ វាផ្តល់ CLI ដើម្បីបន្ថែម ឬលុបថ្នាំងនៅក្នុងចង្កោម។ លក្ខណៈពិសេសគួរឱ្យចាប់អារម្មណ៍របស់វាគឺសមត្ថភាពក្នុងការកំណត់រចនាសម្ព័ន្ធកម្មវិធីកំណត់ពេលដោយប្រើឯកសារ json ខាងក្រោម។

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

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

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

ដើម្បីបញ្ចប់ប្រធានបទ ខ្ញុំចង់ណែនាំអ្នកអំពីវេទិកា Cloud RTI ដោយផ្អែកលើ Kubernetes ដែលក្រុមការងាររបស់ខ្ញុំកំពុងធ្វើការ។ វាផ្តល់នូវការកត់ត្រាជាកណ្តាល កម្មវិធី និងការត្រួតពិនិត្យចង្កោម និងមុខងារមានប្រយោជន៍ជាច្រើនទៀតដែលនឹងមានប្រយោជន៍។ វាប្រើឧបករណ៍ប្រភពបើកចំហជាច្រើនដូចជា Grafana ដើម្បីបង្ហាញការត្រួតពិនិត្យ។

មានសំណួរអំពីមូលហេតុដែលប្រើឧបករណ៍តុល្យភាពផ្ទុកប្រូកស៊ីជាមួយ Kubernetes ។ សំណួរល្អព្រោះបច្ចុប្បន្នមានតុល្យភាពបន្ទុក 2 កម្រិត។ សេវាកម្ម Kubernetes នៅតែស្ថិតនៅលើអាសយដ្ឋាន IP និម្មិត។ អ្នក​មិន​អាច​ប្រើ​វា​សម្រាប់​ច្រក​នៅ​លើ​ម៉ាស៊ីន​ម៉ាស៊ីន​ខាងក្រៅ​បាន​ទេ ព្រោះ​ប្រសិនបើ Amazon ផ្ទុក​ម៉ាស៊ីន​ពពក​របស់​ខ្លួន​លើស​ចំណុះ នោះ​អាសយដ្ឋាន​នឹង​ផ្លាស់ប្ដូរ។ នេះជាមូលហេតុដែលយើងដាក់ ha-proxy នៅពីមុខសេវាកម្ម - ដើម្បីបង្កើតរចនាសម្ព័ន្ធឋិតិវន្តបន្ថែមទៀតសម្រាប់ចរាចរណ៍ដើម្បីទំនាក់ទំនងយ៉ាងរលូនជាមួយ Kubernetes ។

សំណួរល្អមួយទៀតគឺ តើអ្នកអាចថែរក្សាការផ្លាស់ប្តូរគ្រោងការណ៍មូលដ្ឋានទិន្នន័យដោយរបៀបណា នៅពេលធ្វើការដាក់ពង្រាយពណ៌ខៀវ/បៃតង? ការពិតគឺថាដោយមិនគិតពីការប្រើប្រាស់ Kubernetes ការផ្លាស់ប្តូរគ្រោងការណ៍មូលដ្ឋានទិន្នន័យគឺជាកិច្ចការដ៏លំបាកមួយ។ អ្នកត្រូវធានាថាគ្រោងការណ៍ចាស់ និងថ្មីគឺត្រូវគ្នា បន្ទាប់ពីនោះអ្នកអាចធ្វើបច្ចុប្បន្នភាពមូលដ្ឋានទិន្នន័យ ហើយបន្ទាប់មកធ្វើបច្ចុប្បន្នភាពកម្មវិធីដោយខ្លួនឯង។ អ្នក​អាច​ប្តូរ​មូលដ្ឋាន​ទិន្នន័យ​យ៉ាង​ក្តៅគគុក ហើយ​បន្ទាប់​មក​ធ្វើ​បច្ចុប្បន្នភាព​កម្មវិធី។ ខ្ញុំដឹងពីអ្នកដែលបានចាប់ផ្ដើមប្រព័ន្ធទិន្នន័យថ្មីទាំងស្រុងជាមួយនឹងគ្រោងការណ៍ថ្មី នេះគឺជាជម្រើសមួយ ប្រសិនបើអ្នកមានមូលដ្ឋានទិន្នន័យគ្មានគ្រោងដូច Mongo ប៉ុន្តែវាមិនមែនជាកិច្ចការងាយស្រួលនោះទេ។ ប្រសិនបើអ្នកមិនមានសំណួរបន្ថែមទេ សូមអរគុណចំពោះការយកចិត្តទុកដាក់របស់អ្នក!

ការផ្សាយពាណិជ្ជកម្មមួយចំនួន🙂

សូមអរគុណចំពោះការស្នាក់នៅជាមួយពួកយើង។ តើអ្នកចូលចិត្តអត្ថបទរបស់យើងទេ? ចង់មើលខ្លឹមសារគួរឱ្យចាប់អារម្មណ៍បន្ថែមទៀតទេ? គាំទ្រយើងដោយការបញ្ជាទិញឬណែនាំដល់មិត្តភក្តិ, cloud VPS សម្រាប់អ្នកអភិវឌ្ឍន៍ចាប់ពី $4.99, analogue តែមួយគត់នៃម៉ាស៊ីនមេកម្រិតធាតុ ដែលត្រូវបានបង្កើតឡើងដោយពួកយើងសម្រាប់អ្នក៖ ការពិតទាំងមូលអំពី VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps ចាប់ពី $19 ឬរបៀបចែករំលែកម៉ាស៊ីនមេ? (អាចប្រើបានជាមួយ RAID1 និង RAID10 រហូតដល់ 24 cores និងរហូតដល់ 40GB DDR4)។

Dell R730xd 2x ថោកជាងនៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យ Equinix Tier IV នៅទីក្រុង Amsterdam? នៅទីនេះ 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV ចាប់ពី $199 នៅប្រទេសហូឡង់! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ចាប់ពី $99! អាន​អំពី របៀបបង្កើតក្រុមហ៊ុនហេដ្ឋារចនាសម្ព័ន្ធ ថ្នាក់ជាមួយនឹងការប្រើប្រាស់ម៉ាស៊ីនមេ Dell R730xd E5-2650 v4 ដែលមានតម្លៃ 9000 អឺរ៉ូសម្រាប់មួយកាក់?

ប្រភព: www.habr.com