🥇ការវិវត្តន៍នៃឧបករណ៍ចែកចាយ ឬគំនិតលើ Docker, deb, jar និងរបស់ផ្សេងទៀត

ការវិវត្តនៃឧបករណ៍ចែកចាយ ឬគំនិតអំពី Docker, deb, jar និងច្រើនទៀត

នៅពេលមួយ ខ្ញុំបានសម្រេចចិត្តសរសេរអត្ថបទអំពីការចែកចាយក្នុងទម្រង់ជា Docker containers និង deb packages ប៉ុន្តែនៅពេលខ្ញុំចាប់ផ្តើម ដោយសារហេតុផលខ្លះ ខ្ញុំត្រូវបានគេដឹកត្រឡប់ទៅពេលឆ្ងាយនៃកុំព្យូទ័រផ្ទាល់ខ្លួនដំបូង និងសូម្បីតែម៉ាស៊ីនគិតលេខ។ ជាទូទៅ ជំនួសឱ្យការប្រៀបធៀបស្ងួតនៃ docker និង deb យើងទទួលបានគំនិតទាំងនេះលើប្រធានបទនៃការវិវត្តន៍ ដែលខ្ញុំបង្ហាញសម្រាប់ការពិចារណារបស់អ្នក។

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

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

ដូច្នេះ នៅសម័យបុរាណ... វិធីសាស្រ្តដំបូងបំផុតនៃការចែកចាយដែលខ្ញុំបានរកឃើញគឺ កាសែតកាសែតពីម៉ាស៊ីនថតសំឡេង។ ខ្ញុំមានកុំព្យូទ័រ BK-0010.01...

យុគសម័យនៃម៉ាស៊ីនគិតលេខ

អត់ទេ មានពេលមុន ក៏មានម៉ាស៊ីនគិតលេខដែរ។ MK-61 и MK-52.

ការវិវត្តនៃឧបករណ៍ចែកចាយ ឬគំនិតអំពី Docker, deb, jar និងច្រើនទៀត ដូច្នេះនៅពេលដែលខ្ញុំមាន MK-61បន្ទាប់មកវិធីផ្ទេរកម្មវិធីគឺជាក្រដាសធម្មតាមួយនៅក្នុងប្រអប់ដែលកម្មវិធីត្រូវបានសរសេរ ដែលប្រសិនបើចាំបាច់ ដើម្បីដំណើរការវាដោយដៃ វាត្រូវបានសរសេរទៅក្នុងម៉ាស៊ីនគិតលេខ។ ប្រសិនបើអ្នកចង់លេង (បាទសូម្បីតែម៉ាស៊ីនគិតលេខ antediluvian នេះមានហ្គេម) - អ្នកអង្គុយចុះហើយបញ្ចូលកម្មវិធីទៅក្នុងម៉ាស៊ីនគិតលេខ។ ជាធម្មតា នៅពេលដែលម៉ាស៊ីនគិតលេខត្រូវបានបិទ កម្មវិធីនោះក៏បាត់ទៅវិញ។ បន្ថែមពីលើលេខកូដម៉ាស៊ីនគិតលេខដែលសរសេរនៅលើក្រដាសនៅក្នុងដៃរបស់គាត់ កម្មវិធីត្រូវបានបោះពុម្ពនៅក្នុងទស្សនាវដ្តី "វិទ្យុ" និង "បច្ចេកវិទ្យាសម្រាប់យុវជន" ហើយក៏ត្រូវបានបោះពុម្ពនៅក្នុងសៀវភៅនៅសម័យនោះ។

ការកែប្រែបន្ទាប់គឺម៉ាស៊ីនគិតលេខ MK-52វាមានភាពស្រដៀងគ្នាខ្លះនៃការផ្ទុកទិន្នន័យដែលមិនងាយនឹងបង្កជាហេតុ។ ឥឡូវនេះហ្គេម ឬកម្មវិធីមិនចាំបាច់បញ្ចូលដោយដៃទេ ប៉ុន្តែបន្ទាប់ពីអនុវត្តការឆ្លងកាត់វេទមន្តមួយចំនួនដោយប្រើប៊ូតុង វាបានដំណើរការដោយខ្លួនឯង។

ទំហំនៃកម្មវិធីធំបំផុតនៅក្នុងម៉ាស៊ីនគិតលេខគឺ 105 ជំហាន ហើយទំហំនៃអង្គចងចាំអចិន្រ្តៃយ៍នៅក្នុង MK-52 គឺ 512 ជំហាន។

ដោយវិធីនេះប្រសិនបើមានអ្នកគាំទ្រនៃម៉ាស៊ីនគិតលេខទាំងនេះដែលកំពុងអានអត្ថបទនេះនៅក្នុងដំណើរការនៃការសរសេរអត្ថបទខ្ញុំបានរកឃើញទាំងកម្មវិធីត្រាប់តាមម៉ាស៊ីនគិតលេខសម្រាប់ប្រព័ន្ធប្រតិបត្តិការ Android និងកម្មវិធីសម្រាប់វា។ ឆ្ពោះទៅអតីតកាល!

ការបកស្រាយខ្លីអំពី MK-52 (ពីវិគីភីឌា)
MK-52 បានហោះឡើងលើយានអវកាស Soyuz TM-7 ។ វាត្រូវបានគេសន្មត់ថាត្រូវបានប្រើដើម្បីគណនាគន្លងចុះចត ក្នុងករណីដែលកុំព្យូទ័រនៅលើយន្តហោះបរាជ័យ។
ចាប់តាំងពីឆ្នាំ 52 មក MK-1988 ជាមួយអង្គភាពពង្រីកអង្គចងចាំ Elektronika-Astro ត្រូវបានផ្គត់ផ្គង់ដល់កប៉ាល់កងទ័ពជើងទឹក ដែលជាផ្នែកមួយនៃឧបករណ៍គណនានាវាចរណ៍។

កុំព្យូទ័រផ្ទាល់ខ្លួនដំបូង

ការវិវត្តនៃឧបករណ៍ចែកចាយ ឬគំនិតអំពី Docker, deb, jar និងច្រើនទៀត ចូរយើងត្រលប់ទៅសម័យកាលវិញ។ BC-0010. វាច្បាស់ណាស់ថាមានអង្គចងចាំច្រើននៅទីនោះ ហើយការវាយបញ្ចូលកូដពីក្រដាសមួយសន្លឹកមិនមែនជាជម្រើសទៀតទេ (ទោះបីជាដំបូងខ្ញុំធ្វើដូច្នេះក៏ដោយ ព្រោះមិនមានឧបករណ៍ផ្ទុកផ្សេងទៀតទេ)។ កាសែតអូឌីយ៉ូសម្រាប់ឧបករណ៍ថតសំឡេងកំពុងក្លាយជាមធ្យោបាយសំខាន់ក្នុងការរក្សាទុក និងចែកចាយកម្មវិធី។

ការវិវត្តនៃឧបករណ៍ចែកចាយ ឬគំនិតអំពី Docker, deb, jar និងច្រើនទៀត ការផ្ទុកនៅលើកាសែតជាធម្មតាមានទម្រង់ជាឯកសារគោលពីរមួយ ឬពីរ ហើយអ្វីៗផ្សេងទៀតត្រូវបានផ្ទុកនៅខាងក្នុង។ ភាពជឿជាក់មានកម្រិតទាបណាស់ ខ្ញុំត្រូវរក្សាទុក 2-3 ច្បាប់ចម្លងនៃកម្មវិធី។ ពេលវេលាផ្ទុកក៏ខកចិត្តដែរ ហើយអ្នកចូលចិត្តសាកល្បងជាមួយការអ៊ិនកូដប្រេកង់ផ្សេងៗគ្នា ដើម្បីយកឈ្នះលើចំណុចខ្វះខាតទាំងនេះ។ នៅពេលនោះ ខ្លួនខ្ញុំផ្ទាល់មិនទាន់បានចូលរួមក្នុងការអភិវឌ្ឍន៍កម្មវិធីដែលមានជំនាញវិជ្ជាជីវៈនៅឡើយទេ (មិនរាប់បញ្ចូលកម្មវិធីសាមញ្ញក្នុង BASIC) ដូច្នេះជាអកុសលខ្ញុំនឹងមិនប្រាប់អ្នកលម្អិតអំពីរបៀបដែលអ្វីៗត្រូវបានរៀបចំនៅខាងក្នុងនោះទេ។ ការពិតដែលថាកុំព្យូទ័រមានតែ RAM សម្រាប់ផ្នែកភាគច្រើនកំណត់ភាពសាមញ្ញនៃគ្រោងការណ៍ផ្ទុកទិន្នន័យ។

ការលេចឡើងនៃមេឌៀផ្ទុកដែលអាចទុកចិត្តបាននិងធំ

ក្រោយមក ថាសទន់បានលេចឡើង ដំណើរការចម្លងត្រូវបានធ្វើឱ្យសាមញ្ញ និងភាពជឿជាក់បានកើនឡើង។
ប៉ុន្តែស្ថានភាពផ្លាស់ប្តូរយ៉ាងខ្លាំងតែនៅពេលដែលការផ្ទុកក្នុងស្រុកធំគ្រប់គ្រាន់លេចឡើងក្នុងទម្រង់ជា HDDs ។

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

ទន្ទឹមនឹងនេះភាពស្មុគស្មាញនៃកម្មវិធីដែលបានផ្គត់ផ្គង់កំពុងកើនឡើង។
ចំនួនឯកសារនៅក្នុងការចែកចាយកើនឡើងពីពីរបីទៅរាប់រយទៅរាប់ពាន់នាក់ ការប៉ះទង្គិចរវាងកំណែបណ្ណាល័យ និងភាពរីករាយផ្សេងទៀតចាប់ផ្តើមនៅពេលដែលកម្មវិធីផ្សេងៗប្រើទិន្នន័យដូចគ្នា។

ការវិវត្តនៃឧបករណ៍ចែកចាយ ឬគំនិតអំពី Docker, deb, jar និងច្រើនទៀត នៅពេលនោះ អត្ថិភាពមិនទាន់ត្រូវបានបង្ហាញដល់ខ្ញុំនៅឡើយទេ Linuxខ្ញុំរស់នៅក្នុងពិភពនៃ MS DOS ហើយក្រោយមក Windowsហើយបានសរសេរជាភាសា Borland Pascal និង Delphi ដោយពេលខ្លះសាកល្បងប្រើ C++។ នៅពេលនោះ មនុស្សជាច្រើនបានប្រើ InstallShield ដើម្បីចែកចាយផលិតផល។ ru.wikipedia.org/wiki/InstallShieldដែលបានដោះស្រាយយ៉ាងជោគជ័យនូវរាល់កិច្ចការដែលបានកំណត់ក្នុងការដាក់ពង្រាយ និងកំណត់រចនាសម្ព័ន្ធកម្មវិធី។

សម័យអ៊ីនធឺណិត

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

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

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

ខ្ញុំចាំពីពេលដែលនៅក្នុងក្រុមហ៊ុនរបស់យើងដែលខ្ញុំធ្វើការនៅពេលនោះ (ខ្ញុំនឹងមិនដាក់ឈ្មោះវាទេ) ជំនួសឱ្យការកសាងតាមរយៈស្រមោច (maven មិនទាន់ពេញនិយម ឬមិនមានទាល់តែសោះ) មនុស្សគ្រាន់តែប្រមូលពាងនៅក្នុង IDE ហើយប្តេជ្ញាចិត្តយ៉ាងស្ងប់ស្ងាត់។ វានៅក្នុង SVN ។ ដូច្នោះហើយ ការដាក់ពង្រាយរួមមានការទាញយកឯកសារពី SVN ហើយចម្លងវាតាមរយៈ SSH ទៅកាន់ម៉ាស៊ីនដែលចង់បាន។ វាសាមញ្ញណាស់និងមិនល្អ។

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

កញ្ចប់ RPM និង DEB

ការវិវត្តនៃឧបករណ៍ចែកចាយ ឬគំនិតអំពី Docker, deb, jar និងច្រើនទៀត ម៉្យាងវិញទៀត ជាមួយនឹងការអភិវឌ្ឍអ៊ីនធឺណិត ប្រព័ន្ធដែលស្រដៀងនឹង UNIX បានចាប់ផ្តើមទទួលបានប្រជាប្រិយភាពកាន់តែខ្លាំងឡើង។ ជាពិសេស គឺនៅពេលនោះហើយដែលខ្ញុំបានរកឃើញ RedHat។ Linux ៦ ប្រហែលឆ្នាំ ២០០០។ ជាធម្មតា មានមធ្យោបាយជាក់លាក់សម្រាប់ចែកចាយកម្មវិធីនៅទីនោះផងដែរ។ យោងតាមវិគីភីឌា RPM ក្នុងនាមជាអ្នកគ្រប់គ្រងកញ្ចប់សំខាន់បានបង្ហាញខ្លួននៅឆ្នាំ ១៩៩៥ ក្នុងកំណែ RedHat។ Linux 2.0។ ចាប់តាំងពីពេលនោះមក ប្រព័ន្ធនេះត្រូវបានចែកចាយជាកញ្ចប់ RPM ហើយបន្តរីកចម្រើន។

ការចែកចាយរបស់គ្រួសារ Debian ពួកគេបានដើរតាមមាគ៌ាស្រដៀងគ្នា ហើយបានអនុវត្តការដឹកជញ្ជូនក្នុងទម្រង់ជាកញ្ចប់ deb ដែលនៅតែមិនផ្លាស់ប្តូររហូតមកដល់សព្វថ្ងៃនេះ។

អ្នកគ្រប់គ្រងកញ្ចប់អនុញ្ញាតឱ្យអ្នកចែកចាយផលិតផលកម្មវិធីដោយខ្លួនឯង កំណត់រចនាសម្ព័ន្ធពួកវាកំឡុងពេលដំណើរការដំឡើង គ្រប់គ្រងភាពអាស្រ័យរវាងកញ្ចប់ផ្សេងៗគ្នា ដកផលិតផលចេញ និងសម្អាតធាតុដែលមិនចាំបាច់កំឡុងពេលដំណើរការលុប។ ទាំងនោះ។ សម្រាប់ផ្នែកភាគច្រើន នោះហើយជាអ្វីទាំងអស់ដែលត្រូវការ ដែលជាមូលហេតុដែលពួកគេមានរយៈពេលជាច្រើនទសវត្សរ៍ស្ទើរតែមិនផ្លាស់ប្តូរ។

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

គួរកត់សម្គាល់ថាបច្ចុប្បន្ននេះមានការផ្លាស់ប្តូរមួយចំនួនឆ្ពោះទៅរកការផ្លាស់ប្តូរឆ្ងាយពី deb និងប្តូរទៅកញ្ចប់ខ្ទាស់ ប៉ុន្តែមានច្រើនទៀតនៅពេលក្រោយ។

ដូច្នេះ អ្នកអភិវឌ្ឍន៍ពពកជំនាន់ថ្មីនេះ ដែលមិនស្គាល់ទាំង DEB ឬ RPM ក៏រីកចម្រើនបន្តិចម្តងៗ ទទួលបានបទពិសោធន៍ ផលិតផលកាន់តែស្មុគស្មាញ ហើយវិធីសាស្រ្តចែកចាយដែលសមហេតុផលមួយចំនួនទៀតគឺត្រូវការជាង FTP ស្គ្រីប bash និងសិប្បកម្មសិស្សស្រដៀងគ្នា។
ហើយនេះគឺជាកន្លែងដែល Docker ចូលមកក្នុងរូបភាព ដែលជាប្រភេទនៃល្បាយនៃនិម្មិត ការកំណត់ធនធាន និងវិធីសាស្ត្រចែកចាយ។ វាជាម៉ូដទាន់សម័យ និងក្មេងជាងវ័យ ប៉ុន្តែតើវាត្រូវការសម្រាប់អ្វីគ្រប់យ៉ាងមែនទេ? តើនេះជា panacea មែនទេ?

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

ខ្ញុំនឹងព្យាយាមចែករំលែកបទពិសោធន៍របស់ខ្ញុំអំពីរបៀបដែលយើងអនុវត្ត Docker និងអ្វីដែលបានកើតឡើងជាលទ្ធផល។

ស្គ្រីបដែលសរសេរដោយខ្លួនឯង។

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

ប៉ុន្តែស្គ្រីបមានគុណវិបត្តិមួយចំនួន៖

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

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

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

Dockers

ការវិវត្តនៃឧបករណ៍ចែកចាយ ឬគំនិតអំពី Docker, deb, jar និងច្រើនទៀត នៅចំណុចខ្លះ មជ្ឈិមសម័យថ្មីបានចាប់ផ្តើមមករកយើង ដោយឃើញគំនិត និងឈ្លើយអំពីអ្នកចត។ អញ្ចឹងទង់នៅក្នុងដៃ - តោះធ្វើវា! មានការប៉ុនប៉ងចំនួនពីរ។ ទាំងពីរមិនបានជោគជ័យទេ - ឧបមាថាដោយសារតែមហិច្ឆតាដ៏អស្ចារ្យ ប៉ុន្តែខ្វះបទពិសោធន៍ពិតប្រាកដ។ តើចាំបាច់ត្រូវបង្ខំវា ហើយបញ្ចប់វាដោយមធ្យោបាយណាដែលអាចធ្វើទៅបាន? វាមិនទំនងទេ - ក្រុមត្រូវតែវិវឌ្ឍន៍ទៅកម្រិតដែលត្រូវការ មុនពេលដែលវាអាចប្រើឧបករណ៍សមស្រប។ លើសពីនេះទៀត នៅពេលប្រើរូបភាព Docker ដែលត្រៀមរួចជាស្រេច យើងតែងតែជួបប្រទះនូវការពិតដែលថាបណ្តាញមិនដំណើរការត្រឹមត្រូវ (ដែលអាចបណ្តាលមកពីភាពសើមនៃ Docker ខ្លួនវា) ឬវាពិបាកក្នុងការពង្រីកកុងតឺន័ររបស់អ្នកដទៃ។

តើយើងជួបការរអាក់រអួលអ្វីខ្លះ?

បញ្ហាបណ្តាញនៅក្នុងរបៀបស្ពាន
វាជាការរអាក់រអួលក្នុងការមើលកំណត់ហេតុនៅក្នុងកុងតឺន័រ (ប្រសិនបើពួកវាមិនត្រូវបានរក្សាទុកដោយឡែកពីគ្នានៅក្នុងប្រព័ន្ធឯកសាររបស់ម៉ាស៊ីនមេ)
ElasticSearch ម្តងម្កាលបង្កកយ៉ាងចម្លែកនៅខាងក្នុងកុងតឺន័រ ហេតុផលមិនត្រូវបានកំណត់ទេ កុងតឺន័រគឺផ្លូវការ
វាចាំបាច់ក្នុងការប្រើសែលនៅខាងក្នុងធុង - អ្វីគ្រប់យ៉ាងត្រូវបានដកចេញយ៉ាងខ្លាំង មិនមានឧបករណ៍ធម្មតាទេ។
ទំហំធំនៃធុងប្រមូល - មានតម្លៃថ្លៃក្នុងការរក្សាទុក
ដោយសារតែទំហំធំនៃធុងវាពិបាកក្នុងការគាំទ្រកំណែច្រើន។
ពេលវេលាសាងសង់យូរជាង មិនដូចវិធីសាស្ត្រផ្សេងទៀត (ស្គ្រីប ឬកញ្ចប់ deb)

ម៉្យាងវិញទៀត ហេតុអ្វីបានជាវាកាន់តែអាក្រក់ក្នុងការដាក់ឱ្យប្រើប្រាស់សេវាកម្ម Spring ក្នុងទម្រង់ជា jar archive តាមរយៈ deb ដូចគ្នា? តើភាពឯកោធនធានពិតជាចាំបាច់មែនទេ? តើវាមានតម្លៃបាត់បង់ឧបករណ៍ប្រព័ន្ធប្រតិបត្តិការដ៏ងាយស្រួលដោយការបញ្ចូលសេវាកម្មទៅក្នុងកុងតឺន័រដែលកាត់បន្ថយយ៉ាងខ្លាំងដែរឬទេ?

ដូចដែលការអនុវត្តបានបង្ហាញ តាមពិតនេះមិនចាំបាច់ទេ កញ្ចប់ deb គឺគ្រប់គ្រាន់ក្នុង 90% នៃករណី។

តើ deb ចាស់ល្អនៅពេលណា ហើយតើយើងត្រូវការ docker នៅពេលណា?

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

ចំណុចទីពីរដែលវាត្រូវបានគេគ្រោងនឹងប្រើប្រាស់ Docker គឺត្រូវដាក់ពង្រាយសេវាកម្មតាមគ្រោងការណ៍ដាក់ពង្រាយពណ៌ខៀវបៃតង។ ប៉ុន្តែនៅទីនេះខ្ញុំចង់ទទួលបាននូវភាពស្មុគស្មាញបន្តិចម្តងៗ៖ ដំបូង កញ្ចប់ deb ត្រូវបានសាងសង់ ហើយបន្ទាប់មកធុង docker ត្រូវបានបង្កើតឡើងពីពួកគេ។

កញ្ចប់ខ្ទាស់

ការវិវត្តនៃឧបករណ៍ចែកចាយ ឬគំនិតអំពី Docker, deb, jar និងច្រើនទៀត ចូរយើងត្រលប់ទៅកញ្ចប់ Snap វិញ។ ពួកវាបានបង្ហាញខ្លួនជាផ្លូវការជាលើកដំបូងនៅក្នុង Ubuntu ថ្ងៃទី 16.04 ខែមេសា។ មិនដូចកញ្ចប់ DEB និង RPM បែបប្រពៃណីទេ snaps រួមបញ្ចូល dependencies ទាំងអស់។ ខណៈពេលដែលវាជៀសវាងជម្លោះបណ្ណាល័យ វាក៏មានន័យថាកញ្ចប់លទ្ធផលមានទំហំធំជាង។ លើសពីនេះ នេះអាចប៉ះពាល់ដល់សុវត្ថិភាពប្រព័ន្ធ៖ នៅពេលដាក់ពង្រាយ snaps អ្នកអភិវឌ្ឍន៍ដែលបង្កើតកញ្ចប់ត្រូវតែគ្រប់គ្រងការផ្លាស់ប្តូរទាំងអស់ចំពោះបណ្ណាល័យដែលរួមបញ្ចូល។ ជារួម វាមិនមែនជារឿងងាយស្រួលនោះទេ ហើយការប្រើប្រាស់ពួកវាមិនមែនតែងតែជាស្ថានភាពឈ្នះ-ឈ្នះនោះទេ។ ទោះជាយ៉ាងណាក៏ដោយ វាជាជម្រើសសមហេតុផលទាំងស្រុង ប្រសិនបើឧទាហរណ៍ Docker ត្រូវបានប្រើជាឧបករណ៍វេចខ្ចប់តែប៉ុណ្ណោះ មិនមែនសម្រាប់ virtualization ទេ។