ការអភិវឌ្ឍន៍ និងដំណើរការសាកល្បងជាមួយ Docker និង Gitlab CI

ខ្ញុំស្នើឱ្យអានប្រតិចារិកនៃរបាយការណ៍ដោយ Alexander Sigachev ពី Inventos "ដំណើរការអភិវឌ្ឍន៍ និងការធ្វើតេស្តជាមួយ Docker + Gitlab CI"

អ្នកដែលទើបតែចាប់ផ្តើមអនុវត្តការអភិវឌ្ឍន៍ និងដំណើរការសាកល្បងដោយផ្អែកលើ Docker + Gitlab CI តែងតែសួរសំណួរជាមូលដ្ឋាន។ កន្លែងដែលត្រូវចាប់ផ្តើម? តើត្រូវរៀបចំយ៉ាងដូចម្តេច? តើត្រូវធ្វើតេស្តយ៉ាងដូចម្តេច?

របាយការណ៍នេះគឺល្អព្រោះវានិយាយតាមរបៀបរចនាសម្ព័ន្ធអំពីការអភិវឌ្ឍន៍ និងដំណើរការសាកល្បងដោយប្រើ Docker និង Gitlab CI ។ របាយការណ៍ខ្លួនឯងគឺពីឆ្នាំ 2017 ។ ខ្ញុំគិតថា ពីរបាយការណ៍នេះ អ្នកអាចរៀនពីមូលដ្ឋាន វិធីសាស្រ្ត គំនិត បទពិសោធន៍នៃការប្រើប្រាស់។

អ្នកណាខ្វល់សូមនៅក្រោមឆ្មា។

ឈ្មោះរបស់ខ្ញុំគឺ Alexander Sigachev ។ ខ្ញុំធ្វើការឱ្យ Inventos ។ ខ្ញុំនឹងប្រាប់អ្នកអំពីបទពិសោធន៍របស់ខ្ញុំក្នុងការប្រើប្រាស់ Docker និងរបៀបដែលយើងកំពុងអនុវត្តវាបន្តិចម្តងៗលើគម្រោងនៅក្នុងក្រុមហ៊ុន។

ប្រធានបទបទបង្ហាញ៖ ដំណើរការអភិវឌ្ឍន៍ដោយប្រើ Docker និង Gitlab CI ។

នេះជាការនិយាយលើកទីពីររបស់ខ្ញុំអំពី Docker ។ នៅពេលនៃរបាយការណ៍ដំបូង យើងប្រើតែ Docker in Development នៅលើម៉ាស៊ីនអ្នកអភិវឌ្ឍន៍ប៉ុណ្ណោះ។ ចំនួនបុគ្គលិកដែលប្រើ Docker មានប្រហែល 2-3 នាក់។ បន្តិចម្ដងៗ បទពិសោធន៍ត្រូវបានទទួល ហើយយើងឈានទៅមុខបន្តិចទៀត។ ភ្ជាប់ទៅរបស់យើង។ របាយការណ៍ដំបូង.

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

បាវចនារបស់យើងគឺ៖ ចតអ្វីគ្រប់យ៉ាងដែលយើងអាចចាប់ដៃរបស់យើង។

តើយើងកំពុងដោះស្រាយបញ្ហាអ្វីខ្លះ?

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

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

ជាធម្មតា ប្រសិនបើអ្នកចាប់ផ្តើមពីដំបូង នោះមានឯកសារតិចតួចនៅក្នុងគម្រោង។ ព័ត៌មានអំពីរបៀបតំឡើងគឺអាចរកបានសម្រាប់តែអ្នកចាស់ប៉ុណ្ណោះ។ និយោជិតរៀបចំកន្លែងធ្វើការដោយខ្លួនឯងក្នុងរយៈពេលមួយឬពីរថ្ងៃ។ ដើម្បីបង្កើនល្បឿននេះ យើងបានប្រើ Docker ។

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

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

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

បញ្ហាមួយទៀតគឺកំណែផ្សេងគ្នានៃបណ្ណាល័យ។ វាជារឿយៗកើតឡើងដែលអ្នកអភិវឌ្ឍន៍ធ្វើការជាមួយគម្រោងផ្សេងៗ។ មានគម្រោង Legacy ដែលបានចាប់ផ្តើមកាលពីប្រាំឆ្នាំមុន (ចាប់ពីឆ្នាំ 2017 - ed. note)។ នៅពេលចាប់ផ្តើម យើងបានចាប់ផ្តើមជាមួយ MySQL 5.5 ។ វាក៏មានគម្រោងទំនើបផងដែរ ដែលយើងព្យាយាមអនុវត្តកំណែទំនើបបន្ថែមទៀតនៃ MySQL ឧទាហរណ៍ 5.7 ឬចាស់ជាងនេះ (ក្នុងឆ្នាំ 2017 - ed. note)

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

បញ្ហាបន្ទាប់គឺនៅពេលដែលអ្នកអភិវឌ្ឍន៍ធ្វើការលើម៉ាស៊ីនក្នុងស្រុក គាត់ប្រើធនធានក្នុងស្រុក ឯកសារមូលដ្ឋាន RAM មូលដ្ឋាន។ អន្តរកម្មទាំងអស់នៅពេលបង្កើតដំណោះស្រាយចំពោះបញ្ហាត្រូវបានអនុវត្តក្នុងក្របខ័ណ្ឌនៃការពិតដែលថាវាដំណើរការលើម៉ាស៊ីនតែមួយ។ ឧទាហរណ៍មួយគឺនៅពេលដែលយើងមានម៉ាស៊ីនមេ backend នៅក្នុងផលិតកម្ម 3 ហើយអ្នកអភិវឌ្ឍន៍រក្សាទុកឯកសារទៅថត root ហើយពីទីនោះ nginx យកឯកសារដើម្បីឆ្លើយតបទៅនឹងសំណើ។ នៅពេលដែលកូដបែបនេះចូលទៅក្នុងផលិតកម្ម វាបង្ហាញថាឯកសារមានវត្តមាននៅលើម៉ាស៊ីនមេមួយក្នុងចំណោម 3 server។

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

Frondend-developer ដែលអភិវឌ្ឍលើ JS ស្ទើរតែគ្មានឥទ្ធិពលលើ Backend ទេ។ អ្នកអភិវឌ្ឍន៍ backend អភិវឌ្ឍក្នុងករណីរបស់យើង Ruby on Rails និងមិនជ្រៀតជ្រែកជាមួយ Frondend ទេ។ អន្តរកម្មត្រូវបានអនុវត្តដោយប្រើ API ។

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

ឧបករណ៍។ តើយើងប្រើអ្វី?

• Docker ខ្លួនឯង។ Dockerfile ពិពណ៌នាអំពីភាពអាស្រ័យនៃកម្មវិធីតែមួយ។
• Docker-compose គឺជាបណ្តុំដែលប្រមូលផ្តុំនូវកម្មវិធី Docker មួយចំនួនរបស់យើង។
• យើងប្រើ GitLab ដើម្បីរក្សាទុកកូដប្រភព។
• យើងប្រើ GitLab-CI សម្រាប់ការរួមបញ្ចូលប្រព័ន្ធ។

របាយការណ៍មានពីរផ្នែក។

ផ្នែកទីមួយនឹងនិយាយអំពីរបៀបដែល Docker ត្រូវបានដំណើរការនៅលើម៉ាស៊ីនរបស់អ្នកអភិវឌ្ឍន៍។

ផ្នែកទីពីរនឹងនិយាយអំពីរបៀបធ្វើអន្តរកម្មជាមួយ GitLab របៀបដែលយើងដំណើរការការធ្វើតេស្ត និងរបៀបដែលយើងដាក់ចេញទៅកាន់ Staging ។

Docker គឺជាបច្ចេកវិទ្យាដែលអនុញ្ញាតឱ្យ (ប្រើវិធីសាស្រ្តប្រកាស) ដើម្បីពិពណ៌នាអំពីសមាសធាតុចាំបាច់។ នេះគឺជាឧទាហរណ៍ Dockerfile ។ នៅទីនេះយើងប្រកាសថាយើងកំពុងទទួលមរតកពីរូបភាព Ruby: 2.3.0 Docker ផ្លូវការ។ វាមានកំណែ Ruby 2.3 ដែលបានដំឡើង។ យើងដំឡើងបណ្ណាល័យសាងសង់ដែលត្រូវការ និង NodeJS ។ យើងពិពណ៌នាថាយើងបង្កើតថតឯកសារ /app. កំណត់ថតកម្មវិធីជាថតការងារ។ នៅក្នុងថតនេះ យើងដាក់ Gemfile និង Gemfile.lock អប្បបរមាដែលត្រូវការ។ បន្ទាប់មកយើងបង្កើតគម្រោងដែលដំឡើងរូបភាពអាស្រ័យនេះ។ យើងបង្ហាញថាកុងតឺន័រនឹងរួចរាល់ដើម្បីស្តាប់នៅលើច្រកខាងក្រៅ 3000។ ពាក្យបញ្ជាចុងក្រោយគឺជាពាក្យបញ្ជាដែលបើកដំណើរការកម្មវិធីរបស់យើងដោយផ្ទាល់។ ប្រសិនបើយើងប្រតិបត្តិពាក្យបញ្ជាចាប់ផ្តើមគម្រោង កម្មវិធីនឹងព្យាយាមដំណើរការ និងដំណើរការពាក្យបញ្ជាដែលបានបញ្ជាក់។

នេះគឺជាឧទាហរណ៍តិចតួចបំផុតនៃឯកសារ docker-compose ។ ក្នុងករណីនេះយើងបង្ហាញថាមានការតភ្ជាប់រវាងធុងពីរ។ នេះគឺដោយផ្ទាល់ទៅក្នុងសេវាមូលដ្ឋានទិន្នន័យ និងសេវាគេហទំព័រ។ កម្មវិធីគេហទំព័ររបស់យើងនៅក្នុងករណីភាគច្រើនទាមទារប្រភេទនៃមូលដ្ឋានទិន្នន័យមួយចំនួនជាផ្នែកខាងក្រោយសម្រាប់ការរក្សាទុកទិន្នន័យ។ ដោយសារយើងកំពុងប្រើ MySQL ឧទាហរណ៍គឺជាមួយ MySQL ប៉ុន្តែគ្មានអ្វីរារាំងយើងពីការប្រើប្រាស់មូលដ្ឋានទិន្នន័យផ្សេងទៀត (PostgreSQL, Redis) ។

យើងយកពីប្រភពផ្លូវការពី Docker hub រូបភាពនៃ MySQL 5.7.14 ដោយគ្មានការផ្លាស់ប្តូរ។ យើងប្រមូលរូបភាពដែលទទួលខុសត្រូវសម្រាប់កម្មវិធីគេហទំព័ររបស់យើងពីថតបច្ចុប្បន្ន។ វា​ប្រមូល​រូបភាព​សម្រាប់​យើង​អំឡុង​ពេល​បើក​ដំណើរការ​ដំបូង។ បន្ទាប់មកវាដំណើរការពាក្យបញ្ជាដែលយើងកំពុងប្រតិបត្តិនៅទីនេះ។ ប្រសិនបើយើងត្រលប់ទៅវិញយើងនឹងឃើញថាពាក្យបញ្ជាបើកដំណើរការតាមរយៈ Puma ត្រូវបានកំណត់។ Puma គឺជាសេវាកម្មដែលសរសេរនៅក្នុង Ruby ។ ក្នុងករណីទីពីរយើងបដិសេធ។ ពាក្យ​បញ្ជា​នេះ​អាច​ធ្វើ​តាម​អំពើ​ចិត្ត​អាស្រ័យ​លើ​តម្រូវ​ការ​ឬ​កិច្ចការ​របស់​យើង។

យើងក៏ពណ៌នាថា យើងត្រូវបញ្ជូនច្រកនៅលើម៉ាស៊ីនអ្នកអភិវឌ្ឍន៍របស់យើងពី 3000 ទៅ 3000 នៅលើច្រកកុងតឺន័រ។ នេះត្រូវបានធ្វើដោយស្វ័យប្រវត្តិដោយប្រើ iptables និងយន្តការរបស់វា ដែលត្រូវបានបង្កប់ដោយផ្ទាល់នៅក្នុង Docker ។

ដូចពីមុន អ្នកអភិវឌ្ឍន៍ក៏អាចចូលប្រើអាសយដ្ឋាន IP ណាក៏បានដែរ ឧទាហរណ៍ 127.0.0.1 គឺជាអាសយដ្ឋាន IP ក្នុងស្រុក ឬខាងក្រៅរបស់ម៉ាស៊ីន។

បន្ទាត់ចុងក្រោយនិយាយថា web container អាស្រ័យលើ db container។ នៅពេលដែលយើងហៅការចាប់ផ្តើមនៃ web container នោះ docker-compose ជាដំបូងនឹងចាប់ផ្តើម database សម្រាប់ពួកយើង។ រួច​ហើយ​នៅ​ពេល​ចាប់​ផ្ដើម​មូលដ្ឋាន​ទិន្នន័យ (តាម​ពិត​ក្រោយ​ការ​បើក​ដំណើរការ​កុងតឺន័រ! នេះ​មិន​ធានា​ការ​ត្រៀម​ខ្លួន​របស់​ឃ្លាំង​ទិន្នន័យ) នឹង​បើក​ដំណើរការ​កម្មវិធី​ដែល​ជា​ផ្នែក​ខាង​ក្រោយ​របស់​យើង។

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

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

យើងមានឱកាសប្រើការកំណត់ដ៏ល្អប្រសើរសម្រាប់បរិស្ថានអភិវឌ្ឍន៍ដែលនឹងខុសពីលំនាំដើម។ MySQL ត្រូវបានកំណត់រចនាសម្ព័ន្ធសម្រាប់ម៉ាស៊ីនខ្សោយតាមលំនាំដើម ហើយដំណើរការរបស់វាចេញពីប្រអប់គឺអន់ណាស់។

Docker អនុញ្ញាតឱ្យអ្នកប្រើកម្មវិធីបកប្រែ Python, Ruby, NodeJS, PHP នៃកំណែដែលចង់បាន។ យើងកម្ចាត់តម្រូវការប្រើប្រាស់កម្មវិធីគ្រប់គ្រងកំណែមួយចំនួន។ ពីមុន Ruby បានប្រើកញ្ចប់ rpm ដែលអនុញ្ញាតឱ្យអ្នកផ្លាស់ប្តូរកំណែអាស្រ័យលើគម្រោង។ វាក៏អនុញ្ញាតឱ្យផងដែរ សូមអរគុណដល់ Docker container ដើម្បីផ្ទេរកូដដោយរលូន និងកំណែវារួមគ្នាជាមួយនឹងភាពអាស្រ័យ។ យើងគ្មានបញ្ហាក្នុងការយល់ដឹងអំពីកំណែទាំងអ្នកបកប្រែ និងកូដនោះទេ។ ដើម្បីធ្វើបច្ចុប្បន្នភាពកំណែ សូមបន្ទាបធុងចាស់ ហើយលើកធុងថ្មី។ ប្រសិនបើមានអ្វីខុស យើងអាចទម្លាក់ធុងថ្មី លើកធុងចាស់។

បន្ទាប់​ពី​បង្កើត​រូបភាព​រួច ធុង​ទាំង​ក្នុង​ការ​អភិវឌ្ឍ និង​ផលិតកម្ម​នឹង​ដូច​គ្នា។ នេះជាការពិតជាពិសេសសម្រាប់ការដំឡើងធំ។

នៅលើ Frontend យើងប្រើ JavaScipt និង NodeJS ។

ឥឡូវនេះយើងមានគម្រោងចុងក្រោយនៅលើ ReacJS ។ អ្នកអភិវឌ្ឍន៍បានដំណើរការអ្វីគ្រប់យ៉ាងនៅក្នុងកុងតឺន័រ ហើយបានបង្កើតដោយប្រើ hot-reload ។

បន្ទាប់មក កិច្ចការដំឡើង JavaScipt ត្រូវបានចាប់ផ្តើម ហើយកូដដែលបានចងក្រងជាឋិតិវន្តត្រូវបានផ្តល់តាមរយៈធនធានសន្សំ nginx ។

នៅទីនេះខ្ញុំបានផ្តល់ឱ្យគ្រោងការណ៍នៃគម្រោងចុងក្រោយរបស់យើង។

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

តើយើងបានធ្វើអ្វីសម្រាប់រឿងនេះ?

យើងបានបែងចែកទៅជាកម្មវិធីដូចជា៖ ផ្នែកគ្រប់គ្រងនៅលើ JS ដែលជាផ្នែកខាងក្រោយដែលដំណើរការតាមរយៈចំណុចប្រទាក់ REST នៅក្រោម Ruby on Rails ។ ផ្នែកខាងក្រោយមានអន្តរកម្មជាមួយមូលដ្ឋានទិន្នន័យ។ លទ្ធផល​ដែល​ត្រូវ​បាន​បង្កើត​ត្រូវ​បាន​ផ្តល់​ឱ្យ​អតិថិជន។ បន្ទះគ្រប់គ្រងធ្វើអន្តរកម្មជាមួយផ្នែកខាងក្រោយ និងមូលដ្ឋានទិន្នន័យតាមរយៈចំណុចប្រទាក់ REST ។

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

យើងបានបង្កើតគ្រោងការណ៍ដូចខាងក្រោម៖ ប្រតិបត្តិករពីកម្មវិធីរុករកអន្តរកម្មជាមួយបន្ទះគ្រប់គ្រង បន្ទះគ្រប់គ្រងធ្វើអន្តរកម្មជាមួយផ្នែកខាងក្រោយ ភារកិច្ចគឺផ្ញើការជូនដំណឹងរុញ។

ការជូនដំណឹងជំរុញអន្តរកម្មជាមួយសមាសភាគផ្សេងទៀតដែលត្រូវបានអនុវត្តនៅក្នុង NodeJS ។

ជួរត្រូវបានសាងសង់ ហើយបន្ទាប់មកការជូនដំណឹងត្រូវបានផ្ញើទៅតាមយន្តការរបស់វា។

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

ដូចគ្នាប៉ុន្តែនៅក្នុងលេខ។ នេះជាកន្លែងដែលការប្រើកូដឡើងវិញមានសារៈសំខាន់។

ប្រសិនបើមុននេះ យើងបាននិយាយអំពីការប្រើប្រាស់កូដឡើងវិញក្នុងទម្រង់បណ្ណាល័យ នោះក្នុងឧទាហរណ៍នេះ សេវាកម្មរបស់យើងដែលឆ្លើយតបទៅនឹងការជូនដំណឹង Push ត្រូវបានប្រើឡើងវិញជាម៉ាស៊ីនមេពេញលេញ។ វាផ្តល់ API ។ ហើយការអភិវឌ្ឍន៍ថ្មីរបស់យើងមានអន្តរកម្មជាមួយវារួចហើយ។

នៅពេលនោះយើងកំពុងប្រើកំណែ 4 នៃ NodeJS ។ ឥឡូវនេះ (ក្នុងឆ្នាំ 2017 - ed. note) នៅក្នុងការអភិវឌ្ឍន៍ថ្មីៗ យើងប្រើកំណែ 7 នៃ NodeJS ។ មិនមានបញ្ហានៅក្នុងសមាសធាតុថ្មីដើម្បីពាក់ព័ន្ធនឹងកំណែថ្មីនៃបណ្ណាល័យទេ។

បើចាំបាច់ អ្នកអាចកែប្រែ និងលើកកំណែ NodeJS ពីសេវាកម្មជូនដំណឹង Push ។

ហើយប្រសិនបើយើងអាចរក្សាភាពឆបគ្នារបស់ API នោះវានឹងអាចជំនួសវាជាមួយនឹងគម្រោងផ្សេងទៀតដែលត្រូវបានប្រើពីមុន។

តើអ្នកត្រូវការអ្វីខ្លះដើម្បីបន្ថែម Docker? យើងបន្ថែម Dockerfile ទៅក្នុងឃ្លាំងរបស់យើង ដែលពិពណ៌នាអំពីភាពអាស្រ័យចាំបាច់។ ក្នុងឧទាហរណ៍នេះ សមាសធាតុត្រូវបានបំបែកជាឡូជីខល។ នេះគឺជាសំណុំអប្បបរមារបស់អ្នកអភិវឌ្ឍន៍កម្មវិធីខាងក្រោយ។

នៅពេលបង្កើតគម្រោងថ្មី យើងបង្កើត Dockerfile ពិពណ៌នាអំពីប្រព័ន្ធអេកូដែលចង់បាន (Python, Ruby, NodeJS)។ នៅក្នុង docker-compose វាពិពណ៌នាអំពីភាពអាស្រ័យចាំបាច់ - មូលដ្ឋានទិន្នន័យ។ យើងពណ៌នាថាយើងត្រូវការមូលដ្ឋានទិន្នន័យនៃកំណែបែបនោះ ហើយផ្ទុកទិន្នន័យនៅទីនោះ និងទីនោះ។

យើងប្រើធុងទីបីដាច់ដោយឡែកជាមួយ nginx ដើម្បីបម្រើឋិតិវន្ត។ វាអាចទៅរួចក្នុងការផ្ទុករូបភាព។ Backend ដាក់ពួកវានៅក្នុងកម្រិតសំឡេងដែលបានរៀបចំជាមុន ដែលត្រូវបានម៉ោនផងដែរនៅក្នុងកុងតឺន័រដែលមាន nginx ដែលផ្តល់ឱ្យឋិតិវន្ត។

ដើម្បីរក្សាទុក nginx ការកំណត់ mysql យើងបានបន្ថែមថត Docker ដែលយើងរក្សាទុកការកំណត់ចាំបាច់។ នៅពេលអ្នកអភិវឌ្ឍន៍ធ្វើការក្លូន git នៃឃ្លាំងនៅលើម៉ាស៊ីនរបស់គាត់ គាត់មានគម្រោងរួចរាល់ហើយសម្រាប់ការអភិវឌ្ឍន៍ក្នុងតំបន់។ មិនមានសំណួរថាតើច្រកអ្វីឬការកំណត់អ្វីដែលត្រូវអនុវត្ត។

បន្ទាប់ យើងមានសមាសភាគជាច្រើន៖ អ្នកគ្រប់គ្រង ជូនដំណឹង-API ការជូនដំណឹងរុញ។

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

នេះគឺជាឧទាហរណ៍នៃខ្លឹមសារនៃកម្មវិធី dockerized ។ យើងក៏នាំយកថតឯកសារ Docker នៅទីនេះផងដែរ ដែលយើងបំពេញក្នុងការកំណត់រចនាសម្ព័ន្ធដែលត្រូវការសម្រាប់អន្តរកម្មនៃសមាសធាតុទាំងអស់។ មាន README.md ដែលពិពណ៌នាសង្ខេបពីរបៀបដំណើរការគម្រោង។

នៅទីនេះយើងបានអនុវត្តឯកសារ docker-compose ពីរ។ នេះត្រូវបានធ្វើដើម្បីអាចដំណើរការជាជំហានៗ។ នៅពេលអ្នកអភិវឌ្ឍន៍ធ្វើការជាមួយស្នូល គាត់មិនត្រូវការការជូនដំណឹងជំរុញទេ គាត់គ្រាន់តែបើកដំណើរការឯកសារ docker-compose ហើយតាមនោះ ធនធានត្រូវបានរក្សាទុក។

ប្រសិនបើមានតម្រូវការក្នុងការរួមបញ្ចូលជាមួយការជូនដំណឹងជំរុញ នោះ docker-compose.yaml និង docker-compose-push.yaml ត្រូវបានបើកដំណើរការ។

ដោយសារ docker-compose.yaml និង docker-compose-push.yaml ស្ថិតនៅក្នុងថតមួយ បណ្តាញនិម្មិតតែមួយត្រូវបានបង្កើតដោយស្វ័យប្រវត្តិ។

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

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

សម្រាប់បរិស្ថានអភិវឌ្ឍន៍ យើងប្រើដែន .dev - api.informer.dev ។ កម្មវិធីដែលមានដែន .dev មាននៅលើម៉ាស៊ីនមូលដ្ឋានរបស់អ្នកអភិវឌ្ឍន៍។

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

តាមក្រាហ្វិក វាប្រែថាម៉ាស៊ីនភ្ញៀវគឺជាកម្មវិធីរុករករបស់យើង ឬឧបករណ៍មួយចំនួនដែលយើងធ្វើសំណើទៅកាន់ឧបករណ៍តុល្យភាព។

តុល្យភាពឈ្មោះដែនកំណត់កុងតឺន័រដែលត្រូវទាក់ទង។

វាអាចជា nginx ដែលផ្តល់ឱ្យអ្នកគ្រប់គ្រង JS ។ នេះអាចជា nginx ដែលផ្តល់ API ឬឯកសារឋិតិវន្ត ដែលត្រូវបានផ្តល់ឱ្យ nginx ក្នុងទម្រង់នៃការបង្ហោះរូបភាព។

ដ្យាក្រាមបង្ហាញថាកុងតឺន័រត្រូវបានភ្ជាប់ដោយបណ្តាញនិម្មិត ហើយលាក់នៅពីក្រោយប្រូកស៊ី។

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

តើឧទាហរណ៍មួយណាដែលត្រូវមើលដើម្បី dockerize កម្មវិធីរបស់អ្នក? តាមគំនិតរបស់ខ្ញុំ ឧទាហរណ៍ដ៏ល្អមួយគឺរូបភាព docker ផ្លូវការសម្រាប់ MySQL ។

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

Hub.docker.com ជាធម្មតាមានតំណភ្ជាប់ទៅកាន់ github.com ដែលមានទិន្នន័យឆៅដោយផ្ទាល់ដែលអ្នកអាចបង្កើតរូបភាពដោយខ្លួនឯង។

លើសពីនេះទៀតនៅក្នុងឃ្លាំងនេះមានស្គ្រីប docker-endpoint.sh ដែលទទួលខុសត្រូវចំពោះការចាប់ផ្តើមដំបូង និងសម្រាប់ដំណើរការបន្ថែមទៀតនៃការចាប់ផ្តើមកម្មវិធី។

ក្នុងឧទាហរណ៍នេះផងដែរ មានសមត្ថភាពក្នុងការកំណត់រចនាសម្ព័ន្ធដោយប្រើអថេរបរិស្ថាន។ តាមរយៈការកំណត់អថេរបរិស្ថាននៅពេលដំណើរការកុងតឺន័រតែមួយ ឬតាមរយៈ docker-compose យើងអាចនិយាយបានថាយើងត្រូវកំណត់ពាក្យសម្ងាត់ទទេសម្រាប់ docker ដើម្បី root នៅលើ MySQL ឬអ្វីក៏ដោយដែលយើងចង់បាន។

មានជម្រើសមួយដើម្បីបង្កើតពាក្យសម្ងាត់ចៃដន្យ។ យើងនិយាយថាយើងត្រូវការអ្នកប្រើប្រាស់ យើងត្រូវកំណត់ពាក្យសម្ងាត់សម្រាប់អ្នកប្រើប្រាស់ ហើយយើងត្រូវបង្កើតមូលដ្ឋានទិន្នន័យ។

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

នេះគឺជាឧទាហរណ៍នៃអ្វីដែលកំណែជាក់លាក់នៃ MySQL មើលទៅដូចនៅលើ github.com ។ អ្នកអាចបើក Dockerfile ហើយមើលពីរបៀបដែលការដំឡើងកំពុងដំណើរការនៅទីនោះ។

docker-endpoint.sh គឺជាស្គ្រីបដែលទទួលខុសត្រូវចំពោះចំណុចចូល។ ក្នុងអំឡុងពេលនៃការចាប់ផ្តើមដំបូង ជំហានរៀបចំមួយចំនួនត្រូវបានទាមទារ ហើយសកម្មភាពទាំងអស់នេះត្រូវបានដកចេញដោយគ្រាន់តែនៅក្នុងស្គ្រីបចាប់ផ្តើមប៉ុណ្ណោះ។

ចូរបន្តទៅផ្នែកទីពីរ។

ដើម្បីរក្សាទុកកូដប្រភព យើងបានប្តូរទៅ gitlab ។ នេះគឺជាប្រព័ន្ធដ៏មានឥទ្ធិពលដែលមានចំណុចប្រទាក់ដែលមើលឃើញ។

សមាសធាតុមួយនៃ Gitlab គឺ Gitlab CI ។ វាអនុញ្ញាតឱ្យអ្នកពិពណ៌នាអំពីលំដាប់នៃពាក្យបញ្ជាដែលក្រោយមកនឹងត្រូវបានប្រើដើម្បីរៀបចំប្រព័ន្ធចែកចាយកូដ ឬដំណើរការការធ្វើតេស្តដោយស្វ័យប្រវត្តិ។

Gitlab CI 2 និយាយ https://goo.gl/uohKjI - រាយការណ៍ពីក្លឹប Ruby Russia - លម្អិតហើយប្រហែលជាវានឹងចាប់អារម្មណ៍អ្នក។

ឥឡូវនេះយើងនឹងពិនិត្យមើលនូវអ្វីដែលតម្រូវឱ្យធ្វើដើម្បីធ្វើឱ្យ Gitlab CI សកម្ម។ ដើម្បីចាប់ផ្តើម Gitlab CI យើងគ្រាន់តែត្រូវដាក់ឯកសារ .gitlab-ci.yml ជា root នៃគម្រោង។

នៅទីនេះយើងពណ៌នាថាយើងចង់ប្រតិបត្តិតាមលំដាប់នៃរដ្ឋដូចជាការធ្វើតេស្ត ដាក់ពង្រាយ។

យើងប្រតិបត្តិស្គ្រីបដែលហៅដោយផ្ទាល់ទៅ docker-compose ដើម្បីបង្កើតកម្មវិធីរបស់យើង។ នេះគ្រាន់តែជាឧទាហរណ៍ខាងក្រោយប៉ុណ្ណោះ។

បន្ទាប់មក យើងនិយាយថា វាចាំបាច់ក្នុងការដំណើរការការធ្វើចំណាកស្រុក ដើម្បីផ្លាស់ប្តូរមូលដ្ឋានទិន្នន័យ និងដំណើរការការធ្វើតេស្ត។

ប្រសិនបើស្គ្រីបត្រូវបានប្រតិបត្តិត្រឹមត្រូវ ហើយមិនត្រឡប់កូដកំហុសទេនោះ ប្រព័ន្ធបន្តទៅដំណាក់កាលទីពីរនៃការដាក់ពង្រាយ។

ដំណាក់កាលដាក់ពង្រាយបច្ចុប្បន្នត្រូវបានអនុវត្តសម្រាប់ដំណាក់កាល។ យើង​មិន​បាន​រៀបចំ​ការ​ចាប់​ផ្តើ​ម​ពេល​វេលា​សូន្យ​។

យើងពន្លត់ធុងទាំងអស់ដោយបង្ខំ ហើយបន្ទាប់មកយើងលើកធុងទាំងអស់ម្តងទៀត ដែលប្រមូលបាននៅដំណាក់កាលដំបូងកំឡុងពេលធ្វើតេស្ត។

យើងកំពុងដំណើរការសម្រាប់ការផ្លាស់ប្តូរមូលដ្ឋានទិន្នន័យអថេរបរិស្ថានបច្ចុប្បន្នដែលត្រូវបានសរសេរដោយអ្នកអភិវឌ្ឍន៍។

មានចំណាំថានេះអនុវត្តចំពោះតែសាខាមេប៉ុណ្ណោះ។

នៅពេលផ្លាស់ប្តូរសាខាផ្សេងទៀតមិនត្រូវបានប្រតិបត្តិទេ។

វាអាចធ្វើទៅបានដើម្បីរៀបចំការចេញដំណើរតាមសាខា។

ដើម្បីរៀបចំវាបន្ថែមទៀត យើងត្រូវដំឡើង Gitlab Runner ។

ឧបករណ៍ប្រើប្រាស់នេះត្រូវបានសរសេរជា Golang ។ វា​គឺ​ជា​ឯកសារ​តែ​មួយ​ដូច​ជា​ទូទៅ​នៅ​ក្នុង​ពិភព Golang ដែល​មិន​តម្រូវ​ឱ្យ​មាន​ភាព​អាស្រ័យ​ណា​មួយ​។

នៅពេលចាប់ផ្តើម យើងចុះឈ្មោះ Gitlab Runner ។

យើងទទួលបានគន្លឹះនៅក្នុងចំណុចប្រទាក់បណ្តាញ Gitlab ។

បន្ទាប់មកយើងហៅពាក្យបញ្ជាចាប់ផ្តើមនៅលើបន្ទាត់ពាក្យបញ្ជា។

ដំឡើង Gitlab Runner អន្តរកម្ម (Shell, Docker, VirtualBox, SSH)

កូដនៅលើ Gitlab Runner នឹងប្រតិបត្តិលើរាល់ commit អាស្រ័យលើការកំណត់ .gitlab-ci.yml ។

របៀបដែលវាមើលទៅមើលឃើញនៅក្នុង Gitlab នៅក្នុងចំណុចប្រទាក់បណ្ដាញ។ បន្ទាប់ពីយើងបានភ្ជាប់ GITlab CI យើងមានទង់មួយដែលបង្ហាញពីស្ថានភាពនៃការសាងសង់នៅពេលនេះ។

យើងឃើញថាការប្តេជ្ញាចិត្តមួយត្រូវបានធ្វើឡើងកាលពី 4 នាទីមុន ដែលឆ្លងកាត់ការធ្វើតេស្តទាំងអស់ ហើយមិនបង្កបញ្ហាអ្វីឡើយ។

យើង​អាច​ពិនិត្យ​មើល​ឲ្យ​បាន​ដិត​ដល់​អំពី​ការ​សាងសង់។ នៅទីនេះយើងឃើញថារដ្ឋពីរបានឆ្លងកាត់រួចហើយ។ ស្ថានភាពសាកល្បង និងស្ថានភាពដាក់ពង្រាយនៅលើឆាក។

ប្រសិនបើយើងចុចលើ build ជាក់លាក់មួយ នោះវានឹងមានកុងសូល output នៃ commands ដែលត្រូវបានដំណើរការក្នុងដំណើរការនេះបើយោងតាម ​​.gitlab-ci.yml ។

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

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

ដើម្បី​ធ្វើ​ដូច្នេះ យើង​ត្រូវ​បំបែក​អ្វី​គ្រប់​យ៉ាង​ទៅ​ក្នុង​ថត​ដោយ​ឡែក​ពី​គ្នា។

បន្ទាប់ពីយើងធ្វើបែបនេះ យើងមានបញ្ហាជាមួយនឹងការពិតដែលថា Docker-compose បង្កើតទំហំបណ្តាញផ្ទាល់ខ្លួនរបស់វាសម្រាប់ប៉ានីមួយៗ ហើយមិនឃើញសមាសធាតុរបស់អ្នកជិតខាងនោះទេ។

ដើម្បីចូលទៅជុំវិញ យើងបានបង្កើតបណ្តាញនៅក្នុង Docker ដោយដៃ។ វាត្រូវបានសរសេរនៅក្នុង Docker-compose ដែលអ្នកប្រើបណ្តាញបែបនេះសម្រាប់គម្រោងនេះ។

ដូច្នេះសមាសធាតុនីមួយៗដែលចាប់ផ្តើមជាមួយសំណាញ់នេះមើលឃើញសមាសធាតុនៅក្នុងផ្នែកផ្សេងទៀតនៃប្រព័ន្ធ។

បញ្ហាបន្ទាប់គឺការបំបែកដំណាក់កាលលើគម្រោងជាច្រើន។

ចាប់តាំងពីដើម្បីឱ្យអ្វីៗមើលទៅស្រស់ស្អាត និងជិតស្និទ្ធបំផុតតាមដែលអាចធ្វើទៅបានចំពោះការផលិត វាជាការប្រសើរណាស់ក្នុងការប្រើច្រក 80 ឬ 443 ដែលត្រូវបានប្រើនៅគ្រប់ទីកន្លែងនៅក្នុងគេហទំព័រ។

តើយើងបានដោះស្រាយវាដោយរបៀបណា? យើងបានចាត់តាំង Gitlab Runner ម្នាក់ដល់គម្រោងធំៗទាំងអស់។

Gitlab អនុញ្ញាតឱ្យអ្នកដំណើរការ Gitlab Runners ដែលបានចែកចាយជាច្រើនដែលនឹងយកភារកិច្ចទាំងអស់ទៅជាវេនក្នុងលក្ខណៈវឹកវរហើយដំណើរការវា។

ដូច្នេះ​ហើយ​យើង​មិន​មាន​ផ្ទះ យើង​បាន​កំណត់​ក្រុម​នៃ​គម្រោង​របស់​យើង​ទៅ​ជា Gitlab Runner មួយ​ដែល​អាច​ដោះស្រាយ​ដោយ​មិន​មាន​បញ្ហា​ជាមួយ​បរិមាណ​របស់​យើង។

យើងបានផ្លាស់ប្តូរ nginx-proxy ទៅជាស្គ្រីបចាប់ផ្តើមដាច់ដោយឡែក និងបានបន្ថែមក្រឡាចត្រង្គសម្រាប់គម្រោងទាំងអស់នៅក្នុងវា។

គម្រោងរបស់យើងមានក្រឡាចត្រង្គតែមួយ ហើយឧបករណ៍តុល្យភាពមានក្រឡាចត្រង្គជាច្រើនតាមឈ្មោះគម្រោង។ វាអាចប្រូកស៊ីបន្ថែមទៀតដោយឈ្មោះដែន។

សំណើរបស់យើងមកតាមរយៈដែននៅលើច្រក 80 ហើយត្រូវបានដោះស្រាយទៅក្នុងក្រុមកុងតឺន័រដែលបម្រើដែននេះ។

តើមានបញ្ហាអ្វីផ្សេងទៀតនៅទីនោះ? នេះគឺជាអ្វីដែលធុងទាំងអស់ដំណើរការជា root តាមលំនាំដើម។ នេះគឺជា root មិនស្មើទៅនឹង root host នៃប្រព័ន្ធ។

ទោះយ៉ាងណាក៏ដោយ ប្រសិនបើអ្នកបញ្ចូលកុងតឺន័រ វានឹងជា root ហើយឯកសារដែលយើងបង្កើតនៅក្នុងកុងតឺន័រនេះទទួលបានសិទ្ធិជា root ។

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

តើ​វា​អាច​ដោះស្រាយ​ដោយ​របៀប​ណា? អ្នកអាចបន្ថែមអ្នកប្រើប្រាស់ដែលនឹងនៅក្នុងកុងតឺន័រ។

តើមានបញ្ហាអ្វីខ្លះកើតឡើងនៅពេលយើងបន្ថែមអ្នកប្រើប្រាស់?

នៅពេលបង្កើតអ្នកប្រើប្រាស់ យើងច្រើនតែមិនមានលេខសម្គាល់ក្រុមដូចគ្នា (UID) និងលេខសម្គាល់អ្នកប្រើប្រាស់ (GID) ទេ។

ដើម្បីដោះស្រាយបញ្ហានេះនៅក្នុងកុងតឺន័រ យើងប្រើអ្នកប្រើប្រាស់ដែលមានលេខសម្គាល់ 1000។

ក្នុងករណីរបស់យើង វាស្របគ្នានឹងការពិតដែលថាអ្នកអភិវឌ្ឍន៍ស្ទើរតែទាំងអស់ប្រើ Ubuntu OS ។ ហើយនៅលើអ៊ូប៊ុនទូ អ្នកប្រើប្រាស់ដំបូងមានលេខសម្គាល់ 1000។

តើយើងមានគម្រោងទេ?

អានឯកសារ Docker ។ គម្រោងកំពុងអភិវឌ្ឍយ៉ាងសកម្ម ឯកសារកំពុងផ្លាស់ប្តូរ។ ទិន្នន័យ​ដែល​បាន​ទទួល​កាលពី​ពីរ​ឬ​បី​ខែ​មុន​កំពុង​ក្លាយ​ជា​យឺតយ៉ាវ​ហើយ។

បញ្ហា​ខ្លះ​ដែល​យើង​បាន​ដោះស្រាយ​គឺ​អាច​ដោះស្រាយ​រួច​ហើយ​តាម​មធ្យោបាយ​ស្តង់ដារ។

ដូច្នេះ​ខ្ញុំ​ចង់​ទៅ​កាន់​តែ​ឆ្ងាយ​ទៅ​មុខ​វង់​ភ្លេង​ផ្ទាល់។

ឧទាហរណ៍មួយគឺយន្តការបង្កើតរបស់ Docker ដែលហៅថា Docker Swarm ដែលចេញមកក្រៅប្រអប់។ ខ្ញុំចង់ដំណើរការអ្វីមួយនៅក្នុងផលិតកម្មដោយផ្អែកលើបច្ចេកវិទ្យា Docker Swarm ។

ធុងពងធ្វើឱ្យមានការរអាក់រអួលក្នុងការធ្វើការជាមួយកំណត់ហេតុ។ ឥឡូវ​ឈើ​ត្រូវ​ដាច់​ដោយ​ឡែក។ ពួកវាត្រូវបានរាយប៉ាយនៅទូទាំងធុង។ ភារកិច្ចមួយគឺធ្វើឱ្យមានភាពងាយស្រួលក្នុងការចូលប្រើកំណត់ហេតុតាមរយៈចំណុចប្រទាក់បណ្ដាញ។

ប្រភព: www.habr.com