វេទិកាទំនើបសម្រាប់ការអភិវឌ្ឍន៍ និងការដាក់ឱ្យប្រើប្រាស់កម្មវិធី

នេះជាលើកដំបូងនៅក្នុងការប្រកាសជាបន្តបន្ទាប់អំពីការផ្លាស់ប្តូរ ការកែលម្អ និងការបន្ថែមនៅក្នុងការអាប់ដេត Red Hat OpenShift platform 4.0 ដែលនឹងជួយអ្នករៀបចំសម្រាប់ការផ្លាស់ប្តូរទៅកាន់កំណែថ្មី។

ចាប់តាំងពីពេលដែលសហគមន៍ Kubernetes ដែលកំពុងរត់គេចខ្លួនបានប្រមូលផ្តុំគ្នាជាលើកដំបូងនៅការិយាល័យរបស់ Google នៅទីក្រុង Seattle នៅរដូវស្លឹកឈើជ្រុះឆ្នាំ 2014 វាច្បាស់ណាស់ថាគម្រោង Kubernetes ត្រូវបានកំណត់គោលដៅដើម្បីធ្វើបដិវត្តវិធីដែលកម្មវិធីត្រូវបានបង្កើត និងដាក់ឱ្យប្រើប្រាស់នាពេលបច្ចុប្បន្ននេះ។ ទន្ទឹមនឹងនេះ អ្នកផ្តល់សេវាពពកសាធារណៈបានបន្តវិនិយោគយ៉ាងច្រើនក្នុងការអភិវឌ្ឍន៍ហេដ្ឋារចនាសម្ព័ន្ធ និងសេវាកម្ម ដែលធ្វើឲ្យការធ្វើការជាមួយ IT និងការបង្កើតកម្មវិធីកាន់តែងាយស្រួល និងអាចចូលប្រើប្រាស់បានកាន់តែច្រើន ហើយធ្វើឱ្យពួកគេអាចចូលប្រើបានមិនគួរឱ្យជឿ ដែលមនុស្សមួយចំនួនតូចអាចស្រមៃនៅដើមដំបូងនៃ ទសវត្សរ៍។

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

មិនបាច់និយាយទេ ជម្លោះទាំងអស់នេះពិតជាល្ងង់ណាស់។

ការពិតគឺថា គ្មានអ្វីនឹងរលាយបាត់ឡើយ ហើយសព្វថ្ងៃនេះ យើងអាចមើលឃើញកំណើនអិចស្ប៉ូណង់ស្យែលនៅក្នុងផលិតផលចុងក្រោយ និងវិធីដែលពួកគេត្រូវបានបង្កើតឡើង ដោយសារការលេចឡើងឥតឈប់ឈរនៃកម្មវិធីថ្មីៗនៅក្នុងជីវិតរបស់យើង។ ហើយបើទោះបីជាការពិតដែលថាអ្វីគ្រប់យ៉ាងនៅជុំវិញនឹងផ្លាស់ប្តូរ, ក្នុងពេលតែមួយ, នៅក្នុងខ្លឹមសារ, អ្វីគ្រប់យ៉ាងនឹងនៅតែមិនផ្លាស់ប្តូរ។ អ្នកអភិវឌ្ឍន៍កម្មវិធីនឹងនៅតែសរសេរកូដជាមួយនឹងកំហុស វិស្វករប្រតិបត្តិការ និងអ្នកឯកទេសភាពជឿជាក់នឹងនៅតែដើរជុំវិញជាមួយ pagers និងទទួលបានការជូនដំណឹងដោយស្វ័យប្រវត្តិនៅក្នុង Slack អ្នកគ្រប់គ្រងនឹងនៅតែដំណើរការតាមគោលគំនិតរបស់ OpEx និង CapEx ហើយរាល់ពេលដែលមានការបរាជ័យកើតឡើង អ្នកគ្រប់គ្រងជាន់ខ្ពស់ នឹង​ដក​ដង្ហើម​យ៉ាង​ក្រៀម​ក្រំ​ជា​មួយ​នឹង​ពាក្យ​ថា “ខ្ញុំ​បាន​ប្រាប់​អ្នក​ហើយ”...

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

Kubernetes គឺជាឧបករណ៍បែបនេះ។ ការងារកំពុងដំណើរការដើម្បីបញ្ចូលគ្នានូវ Red Hat OpenShift ជាមួយនឹងឧបករណ៍ និងសេវាកម្មផ្សេងទៀតចូលទៅក្នុងវេទិកាតែមួយដែលនឹងធ្វើឱ្យកម្មវិធីកាន់តែគួរឱ្យទុកចិត្ត ងាយស្រួលគ្រប់គ្រង និងមានសុវត្ថិភាពជាងមុនសម្រាប់អ្នកប្រើប្រាស់។

ជាមួយនឹងអ្វីដែលបាននិយាយថាក្រុម OpenShift សួរសំណួរសាមញ្ញមួយ:

តើអ្នកអាចធ្វើឱ្យការធ្វើការជាមួយ Kubernetes កាន់តែងាយស្រួល និងងាយស្រួលដោយរបៀបណា?

ចម្លើយគឺច្បាស់គួរឱ្យភ្ញាក់ផ្អើល៖

• ធ្វើស្វ័យប្រវត្តិកម្មទិដ្ឋភាពស្មុគស្មាញនៃការដាក់ពង្រាយនៅលើពពក ឬនៅខាងក្រៅពពក។
• ផ្តោតលើភាពជឿជាក់ខណៈពេលដែលលាក់ភាពស្មុគស្មាញ;
• បន្តធ្វើការជាបន្តបន្ទាប់ដើម្បីចេញផ្សាយបច្ចុប្បន្នភាពសាមញ្ញ និងសុវត្ថិភាព។
• សម្រេចបាននូវការគ្រប់គ្រង និងសវនកម្ម;
• ព្យាយាមដំបូងដើម្បីធានាសុវត្ថិភាពខ្ពស់ ប៉ុន្តែមិនចំណាយលើលទ្ធភាពប្រើប្រាស់នោះទេ។

ការចេញផ្សាយបន្ទាប់នៃ OpenShift គួរតែគិតទាំងបទពិសោធន៍របស់អ្នកបង្កើត និងបទពិសោធន៍របស់អ្នកអភិវឌ្ឍន៍ផ្សេងទៀតដែលកំពុងអនុវត្តកម្មវិធីក្នុងទ្រង់ទ្រាយធំនៅក្នុងក្រុមហ៊ុនធំជាងគេលើពិភពលោក។ លើសពីនេះ វាត្រូវតែគិតគូរពីបទពិសោធន៍បង្គរទាំងអស់នៃប្រព័ន្ធអេកូឡូស៊ីបើកចំហ ដែលស្ថិតនៅក្រោមពិភពលោកទំនើបនាពេលបច្ចុប្បន្ននេះ។ ក្នុងពេលជាមួយគ្នានេះ ចាំបាច់ត្រូវបោះបង់ចោលចិត្តគំនិតចាស់របស់អ្នកអភិវឌ្ឍន៍ស្ម័គ្រចិត្ត ហើយឈានទៅរកទស្សនវិជ្ជាថ្មីនៃអនាគតស្វ័យប្រវត្តិ។ វាត្រូវការភ្ជាប់គម្លាតរវាងវិធីចាស់ និងថ្មីនៃការដាក់ពង្រាយកម្មវិធី ហើយទាញយកអត្ថប្រយោជន៍ពេញលេញពីហេដ្ឋារចនាសម្ព័ន្ធដែលមានទាំងអស់ - មិនថាវាត្រូវបានបង្ហោះដោយអ្នកផ្តល់សេវាពពកដ៏ធំបំផុត ឬដំណើរការលើប្រព័ន្ធតូចៗនៅគែមនោះទេ។

តើធ្វើដូចម្តេចដើម្បីសម្រេចបានលទ្ធផលនេះ?

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

នៅដើមឆ្នាំ 2018 Red Hat បានទទួលគម្រោង CoreOS ដែលមានទស្សនៈស្រដៀងគ្នាអំពីអនាគត - កាន់តែមានសុវត្ថិភាព និងអាចទុកចិត្តបាន បង្កើតនៅលើគោលការណ៍ប្រភពបើកចំហ។ ក្រុមហ៊ុនបានធ្វើការដើម្បីអភិវឌ្ឍបន្ថែមទៀតនូវគំនិតទាំងនេះ និងអនុវត្តវា ដោយដាក់ទស្សនវិជ្ជារបស់យើងទៅជាការអនុវត្ត ដោយព្យាយាមធានាថាកម្មវិធីទាំងអស់ដំណើរការដោយសុវត្ថិភាព។ ការងារទាំងអស់នេះត្រូវបានបង្កើតឡើងនៅលើ Kubernetes លីនុច ពពកសាធារណៈ ពពកឯកជន និងគម្រោងរាប់ពាន់ផ្សេងទៀតដែលគាំទ្រប្រព័ន្ធអេកូឌីជីថលទំនើបរបស់យើង។

ការចេញផ្សាយថ្មីនៃ OpenShift 4 នឹងមានភាពច្បាស់លាស់ ស្វ័យប្រវត្តិ និងមានលក្ខណៈធម្មជាតិជាងមុន

វេទិកា OpenShift នឹងដំណើរការជាមួយប្រព័ន្ធប្រតិបត្តិការលីនុចដែលល្អបំផុត និងគួរឱ្យទុកចិត្តបំផុត ដោយមានការគាំទ្រផ្នែករឹងដែកទទេ ការនិម្មិតងាយស្រួល ការសរសេរកម្មវិធីហេដ្ឋារចនាសម្ព័ន្ធដោយស្វ័យប្រវត្តិ និងជាការពិតណាស់ ធុងផ្ទុក (ដែលសំខាន់គ្រាន់តែជារូបភាពលីនុច)។

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

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

វានឹងអនុញ្ញាតឱ្យអ្នកអភិវឌ្ឍន៍ផ្តោតលើការបង្កើតផលិតផលពិតប្រាកដសម្រាប់អ្នកប្រើប្រាស់ និងអតិថិជន។ អ្នកនឹងមិនចាំបាច់ឆ្លងកាត់ព្រៃនៃការកំណត់ផ្នែករឹង និងសូហ្វវែរទេ ហើយភាពស្មុគស្មាញដោយចៃដន្យទាំងអស់នឹងក្លាយជារឿងអតីតកាល។

OpenShift 4: វេទិកា NoOps ដែលមិនត្រូវការការថែទាំ

В ការបោះពុម្ពផ្សាយនេះ។ បានពិពណ៌នាអំពីកិច្ចការទាំងនោះដែលបានជួយរៀបចំចក្ខុវិស័យរបស់ក្រុមហ៊ុនសម្រាប់ OpenShift 4។ គោលដៅរបស់ក្រុមគឺធ្វើឱ្យការងារប្រចាំថ្ងៃនៃប្រតិបត្តិការ និងការថែរក្សាកម្មវិធីមានភាពងាយស្រួលតាមដែលអាចធ្វើទៅបាន ដើម្បីធ្វើឱ្យដំណើរការទាំងនេះមានភាពងាយស្រួល និងបន្ធូរបន្ថយ - ទាំងអ្នកឯកទេសដែលចូលរួមក្នុងការអនុវត្ត និងអ្នកអភិវឌ្ឍន៍។ ប៉ុន្តែ តើអ្នកអាចខិតទៅជិតគោលដៅនេះដោយរបៀបណា? តើធ្វើដូចម្តេចដើម្បីបង្កើតវេទិកាសម្រាប់ដំណើរការកម្មវិធីដែលត្រូវការអន្តរាគមន៍តិចតួច? តើ NoOps មានន័យយ៉ាងណានៅក្នុងបរិបទនេះ?

ប្រសិនបើអ្នកព្យាយាមអរូបី នោះសម្រាប់អ្នកអភិវឌ្ឍន៍ គោលគំនិតនៃ "serverless" ឬ "NoOps" មានន័យថាឧបករណ៍ និងសេវាកម្មដែលអនុញ្ញាតឱ្យអ្នកលាក់សមាសធាតុ "ប្រតិបត្តិការ" ឬកាត់បន្ថយបន្ទុកនេះឱ្យតិចបំផុតសម្រាប់អ្នកអភិវឌ្ឍន៍។

• មិនដំណើរការជាមួយប្រព័ន្ធ ប៉ុន្តែជាមួយចំណុចប្រទាក់កម្មវិធី (APIs) ។
• កុំរំខានការអនុវត្តកម្មវិធី - ទុកឱ្យអ្នកផ្តល់សេវាធ្វើវាសម្រាប់អ្នក។
• កុំលោតចូលទៅក្នុងការបង្កើតក្របខ័ណ្ឌធំភ្លាមៗ - ចាប់ផ្តើមដោយការសរសេរបំណែកតូចៗដែលនឹងដើរតួជា "ប្លុកអាគារ" ព្យាយាមធ្វើឱ្យកូដនេះដំណើរការជាមួយទិន្នន័យ និងព្រឹត្តិការណ៍ មិនមែនជាមួយថាស និងមូលដ្ឋានទិន្នន័យទេ។

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

សម្រាប់អ្នកជំនាញផ្នែកថែទាំ និងប្រតិបត្តិការ ពាក្យ "NoOps" អាចស្តាប់ទៅគួរឱ្យខ្លាចបន្តិច។ ប៉ុន្តែនៅពេលទំនាក់ទំនងជាមួយវិស្វករវាល វាច្បាស់ណាស់ថាគំរូ និងបច្ចេកទេសដែលពួកគេប្រើក្នុងគោលបំណងធានានូវភាពជឿជាក់និងភាពជឿជាក់ (Site Reliability Engineering, SRE) មានភាពស្រដៀងគ្នាជាច្រើនជាមួយនឹងលំនាំដែលបានពិពណ៌នាខាងលើ៖

• កុំគ្រប់គ្រងប្រព័ន្ធ - ធ្វើឱ្យដំណើរការគ្រប់គ្រងរបស់ពួកគេដោយស្វ័យប្រវត្តិ។
• កុំអនុវត្តកម្មវិធី - បង្កើតបំពង់ដើម្បីដាក់ពង្រាយវា។
• ជៀសវាងការរួមបញ្ចូលសេវាកម្មរបស់អ្នកទាំងអស់រួមគ្នា ហើយអនុញ្ញាតឱ្យការបរាជ័យមួយបណ្តាលឱ្យប្រព័ន្ធទាំងមូលបរាជ័យ—បំបែកពួកវានៅទូទាំងហេដ្ឋារចនាសម្ព័ន្ធរបស់អ្នកដោយប្រើឧបករណ៍ស្វ័យប្រវត្តិកម្ម ហើយភ្ជាប់ពួកវាតាមវិធីដែលអាចត្រួតពិនិត្យ និងត្រួតពិនិត្យបាន។

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

Kubernetes នៅក្នុង OpenShift គឺជាវេទិកាមួយដែលត្រូវបានរចនាឡើងដើម្បីដោះស្រាយបញ្ហាចម្បងពីរ៖ ជំនួសឱ្យការបង្ខំអ្នកឱ្យយល់អំពីម៉ាស៊ីននិម្មិត ឬផ្ទុក APIs តុល្យភាព វាដំណើរការជាមួយ abstractions លំដាប់ខ្ពស់ជាង - ដំណើរការដាក់ពង្រាយ និងសេវាកម្ម។ ជំនួសឱ្យការដំឡើងភ្នាក់ងារកម្មវិធី អ្នកអាចដំណើរការកុងតឺន័រ ហើយជំនួសឱ្យការសរសេរជង់ត្រួតពិនិត្យផ្ទាល់ខ្លួនរបស់អ្នក ប្រើឧបករណ៍ដែលមានរួចហើយនៅក្នុងវេទិកា។ ដូច្នេះ ទឹកជ្រលក់សម្ងាត់របស់ OpenShift 4 គឺពិតជាគ្មានអាថ៌កំបាំងទេ វាគ្រាន់តែជាបញ្ហានៃការទទួលយកគោលការណ៍ SRE និងគោលគំនិតគ្មានម៉ាស៊ីនមេ ហើយនាំពួកគេទៅរកការសន្និដ្ឋានឡូជីខលរបស់ពួកគេដើម្បីជួយអ្នកអភិវឌ្ឍន៍ និងវិស្វករប្រតិបត្តិការ៖

• ធ្វើស្វ័យប្រវត្តិកម្ម និងធ្វើស្តង់ដារហេដ្ឋារចនាសម្ព័ន្ធដែលកម្មវិធីប្រើប្រាស់
• ភ្ជាប់ដំណើរការនៃការដាក់ពង្រាយ និងដំណើរការអភិវឌ្ឍន៍ជាមួយគ្នាដោយមិនដាក់កម្រិតអ្នកអភិវឌ្ឍន៍ខ្លួនឯង
• ធានាថាការបើកដំណើរការ សវនកម្ម និងធានាសេវាកម្ម មុខងារ កម្មវិធី ឬជង់ទាំងមូលគឺមិនពិបាកជាងលើកទី 100 នោះទេ។

ប៉ុន្តែតើអ្វីជាភាពខុសគ្នារវាងវេទិកា OpenShift 4 និងអ្នកកាន់តំណែងមុនរបស់វា និងពីវិធីសាស្រ្ត "ស្តង់ដារ" ដើម្បីដោះស្រាយបញ្ហាបែបនេះ? តើអ្វីជំរុញទំហំសម្រាប់ក្រុមអនុវត្ត និងប្រតិបត្តិការ? ដោយសារ​តែ​ស្តេច​ក្នុង​ស្ថានភាព​នេះ​ជា​ចង្កោម។ ដូច្នេះ

• យើង​ប្រាកដ​ថា​គោល​បំណង​នៃ​ចង្កោម​គឺ​ច្បាស់​លាស់ (ជាទី​គោរព​ពពក ខ្ញុំ​បាន​រើស​ចង្កោម​នេះ​ព្រោះ​ខ្ញុំ​អាច)
• មានម៉ាស៊ីន និងប្រព័ន្ធប្រតិបត្តិការ ដើម្បីបម្រើចង្កោម (ព្រះករុណា)
• គ្រប់គ្រងស្ថានភាពនៃម៉ាស៊ីនពីចង្កោម កាត់បន្ថយការកសាងឡើងវិញរបស់ពួកគេ (រសាត់)។
• សម្រាប់ធាតុសំខាន់ៗនីមួយៗនៃប្រព័ន្ធ មេដោះ (យន្តការ) គឺត្រូវការជាចាំបាច់ ដែលនឹងត្រួតពិនិត្យ និងលុបបំបាត់បញ្ហា
• ការបរាជ័យនៃ *គ្រប់ទិដ្ឋភាព* ឬធាតុនៃប្រព័ន្ធ និងយន្តការស្តារឡើងវិញដែលពាក់ព័ន្ធគឺជាផ្នែកធម្មតានៃជីវិត
• ហេដ្ឋារចនាសម្ព័ន្ធទាំងមូលត្រូវតែកំណត់រចនាសម្ព័ន្ធតាមរយៈ API ។
• ប្រើ Kubernetes ដើម្បីដំណើរការ Kubernetes ។ (បាទ/ចាស៎ នោះមិនមែនជាកំហុសទេ)
• ការអាប់ដេតគួរតែមានភាពងាយស្រួល និងមិនមានភាពស្មុគស្មាញក្នុងការដំឡើង។ ប្រសិនបើវាត្រូវការការចុចច្រើនជាងមួយដងដើម្បីដំឡើងបច្ចុប្បន្នភាព នោះច្បាស់ណាស់ថាយើងកំពុងធ្វើអ្វីខុស។
• ការត្រួតពិនិត្យ និងបំបាត់កំហុសផ្នែកណាមួយមិនគួរជាបញ្ហាទេ ដូច្នេះហើយការតាមដាន និងរាយការណ៍ជុំវិញហេដ្ឋារចនាសម្ព័ន្ធទាំងមូលក៏គួរតែមានភាពងាយស្រួល និងងាយស្រួលផងដែរ។

ចង់ឃើញសមត្ថភាពរបស់វេទិកាក្នុងសកម្មភាពទេ?

កំណែមើលជាមុននៃ OpenShift 4 បានក្លាយជាមានសម្រាប់អ្នកអភិវឌ្ឍន៍។ ជាមួយនឹងកម្មវិធីដំឡើងដែលងាយស្រួលប្រើ អ្នកអាចដំណើរការចង្កោមនៅលើ AWS នៅលើ Red Had CoreOS ។ ដើម្បីប្រើការមើលជាមុន អ្នកគ្រាន់តែត្រូវការគណនី AWS ដើម្បីផ្តល់ហេដ្ឋារចនាសម្ព័ន្ធ និងសំណុំនៃគណនីដើម្បីចូលប្រើរូបភាពមើលជាមុន។

1. ដើម្បីចាប់ផ្តើម សូមចូលទៅកាន់ try.openshift.com ហើយចុច "ចាប់ផ្តើម" ។
2. ចូលទៅគណនី Red Hat របស់អ្នក (ឬបង្កើតថ្មីមួយ) ហើយធ្វើតាមការណែនាំដើម្បីដំឡើងចង្កោមដំបូងរបស់អ្នក។

បន្ទាប់ពីការដំឡើងជោគជ័យ សូមពិនិត្យមើលការបង្រៀនរបស់យើង។ ការបណ្តុះបណ្តាល OpenShiftដើម្បីទទួលបានការយល់ដឹងកាន់តែស៊ីជម្រៅអំពីប្រព័ន្ធ និងគោលគំនិតដែលធ្វើឱ្យវេទិកា OpenShift 4 ជាមធ្យោបាយងាយស្រួល និងងាយស្រួលក្នុងការដំណើរការ Kubernetes ។

សាកល្បងការចេញផ្សាយ OpenShift ថ្មី ហើយចែករំលែកយោបល់របស់អ្នក។ យើងប្តេជ្ញាថានឹងធ្វើការជាមួយនឹង Kumbernetes តាមដែលអាចធ្វើទៅបាន និងមិនពិបាកតាមដែលអាចធ្វើទៅបាន អនាគតនៃ NoOps ចាប់ផ្តើមនៅថ្ងៃនេះ។

ឥឡូវនេះយកចិត្តទុកដាក់!
នៅឯសន្និសីទ DevOpsForum 2019 នៅថ្ងៃទី 20 ខែមេសា អ្នកអភិវឌ្ឍន៍ OpenShift ម្នាក់គឺ Vadim Rutkovsky នឹងរៀបចំថ្នាក់មេ - គាត់នឹងបំបែកចង្កោមដប់ ហើយបង្ខំពួកគេឱ្យជួសជុលពួកគេ។ សន្និសីទត្រូវបានបង់ ប៉ុន្តែជាមួយនឹងលេខកូដផ្សព្វផ្សាយ #RedHat អ្នកទទួលបានការបញ្ចុះតម្លៃ 37%

ថ្នាក់មេនៅម៉ោង 17:15 - 18:15 ហើយកន្លែងឈរបើកពេញមួយថ្ងៃ។ អាវយឺត មួក ស្ទីគ័រ - ធម្មតា!

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

ប្រភព: www.habr.com