កម្មវិធីទំនើបនៅលើ OpenShift ផ្នែកទី 3៖ OpenShift ជាបរិយាកាសអភិវឌ្ឍន៍ និង OpenShift Pipelines

សួស្តីអ្នកទាំងអស់គ្នាក្នុងប្លក់នេះ! នេះគឺជាការប្រកាសទីបីនៅក្នុងស៊េរីមួយដែលយើងបង្ហាញពីរបៀបដាក់ពង្រាយកម្មវិធីបណ្ដាញទំនើបនៅលើ Red Hat OpenShift ។

នៅក្នុងការបង្ហោះពីរលើកមុន យើងបានបង្ហាញពីវិធីដាក់ពង្រាយកម្មវិធីបណ្ដាញទំនើបដោយគ្រាន់តែពីរបីជំហានប៉ុណ្ណោះ និងរបៀបប្រើរូបភាព S2I ថ្មី រួមជាមួយនឹងរូបភាពម៉ាស៊ីនមេ HTTP ក្រៅធ្នើ ដូចជា NGINX ដោយប្រើការបង្កើតជាច្រវាក់ ដើម្បីរៀបចំការដាក់ពង្រាយផលិតកម្ម។ .

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

OpenShift ជាបរិយាកាសអភិវឌ្ឍន៍

ដំណើរការអភិវឌ្ឍន៍

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

នៅក្នុងក្របខ័ណ្ឌទំនើបភាគច្រើន "ម៉ាស៊ីនមេអភិវឌ្ឍន៍" បែបនេះត្រូវបានបង្កើតឡើងនៅក្នុងឧបករណ៍បន្ទាត់ពាក្យបញ្ជាដែលត្រូវគ្នា។

ឧទាហរណ៍ក្នុងស្រុក

ដំបូង សូមមើលពីរបៀបដែលវាដំណើរការនៅពេលដំណើរការកម្មវិធីក្នុងមូលដ្ឋាន។ តោះយកពាក្យសុំធ្វើជាឧទាហរណ៍ ប្រតិកម្ម ពីអត្ថបទមុន ទោះបីជាគំនិតលំហូរការងារស្ទើរតែដូចគ្នាអនុវត្តនៅក្នុងក្របខ័ណ្ឌទំនើបផ្សេងទៀតទាំងអស់ក៏ដោយ។
ដូច្នេះ ដើម្បីចាប់ផ្តើម "dev server" នៅក្នុងឧទាហរណ៍ React របស់យើង យើងនឹងបញ្ចូលពាក្យបញ្ជាខាងក្រោម៖

$ npm run start

បន្ទាប់មកនៅក្នុងបង្អួចស្ថានីយយើងនឹងឃើញអ្វីមួយដូចនេះ:

ហើយកម្មវិធីរបស់យើងនឹងបើកនៅក្នុងកម្មវិធីរុករកលំនាំដើម៖

ឥឡូវនេះ ប្រសិនបើយើងធ្វើការផ្លាស់ប្តូរឯកសារនោះ កម្មវិធីគួរតែអាប់ដេតនៅក្នុងកម្មវិធីរុករក។

យល់ព្រម អ្វីគ្រប់យ៉ាងគឺច្បាស់ជាមួយនឹងការអភិវឌ្ឍន៍នៅក្នុងរបៀបមូលដ្ឋាន ប៉ុន្តែតើធ្វើដូចម្តេចដើម្បីសម្រេចបានដូចគ្នានៅលើ OpenShift?

ម៉ាស៊ីនមេអភិវឌ្ឍន៍នៅលើ OpenShift

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

ទោះយ៉ាងណាក៏ដោយប្រសិនបើអ្នកពិនិត្យមើលឱ្យកាន់តែច្បាស់ ដំណើរការស្គ្រីប ពីឧទាហរណ៍នោះ វាមានអថេរបរិស្ថាន $NPM_RUN ដែលអនុញ្ញាតឱ្យអ្នកប្រតិបត្តិពាក្យបញ្ជារបស់អ្នក។

ឧទាហរណ៍ យើងអាចប្រើម៉ូឌុល nodeshift ដើម្បីដាក់ឱ្យប្រើប្រាស់កម្មវិធីរបស់យើង៖

$ npx nodeshift --deploy.env NPM_RUN="yarn start" --dockerImage=nodeshift/ubi8-s2i-web-app

ចំណាំ៖ ឧទាហរណ៍ខាងលើត្រូវបានសរសេរជាអក្សរកាត់ដើម្បីបង្ហាញពីគំនិតទូទៅ។

នៅទីនេះ យើងបានបន្ថែមអថេរបរិស្ថាន NPM_RUN ទៅនឹងការដាក់ឱ្យប្រើប្រាស់របស់យើង ដែលប្រាប់រយៈពេលដំណើរការដើម្បីដំណើរការពាក្យបញ្ជា yarn start ដែលចាប់ផ្តើម React developer server នៅខាងក្នុង OpenShift pod របស់យើង។

ប្រសិនបើអ្នកក្រឡេកមើលកំណត់ហេតុនៃការរត់ pod វានឹងមើលទៅដូចនេះ:

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

ធ្វើសមកាលកម្មពីចម្ងាយ និងលេខកូដមូលដ្ឋាន

ជាសំណាងល្អ nodeshift អាចជួយបានយ៉ាងងាយស្រួលជាមួយនឹងការធ្វើសមកាលកម្ម ហើយអ្នកអាចប្រើពាក្យបញ្ជានាឡិកាដើម្បីតាមដានការផ្លាស់ប្តូរ។

ដូច្នេះបន្ទាប់ពីយើងបានដំណើរការពាក្យបញ្ជាដើម្បីដាក់ពង្រាយម៉ាស៊ីនមេអភិវឌ្ឍន៍សម្រាប់កម្មវិធីរបស់យើង យើងអាចប្រើពាក្យបញ្ជាខាងក្រោមដោយសុវត្ថិភាព៖

$ npx nodeshift watch

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

ដូច្នេះ ប្រសិនបើឥឡូវនេះយើងអាប់ដេតឯកសារ src/App.js ប្រព័ន្ធនឹងប្រតិកម្មចំពោះការផ្លាស់ប្តូរទាំងនេះ ចម្លងពួកវាទៅចង្កោមពីចម្ងាយ ហើយចាប់ផ្តើមម៉ាស៊ីនមេអភិវឌ្ឍន៍ ដែលបន្ទាប់មកនឹងធ្វើបច្ចុប្បន្នភាពកម្មវិធីរបស់យើងនៅក្នុងកម្មវិធីរុករក។

ដើម្បី​បញ្ចប់​រូបភាព សូម​បង្ហាញ​ពី​អ្វី​ដែល​ពាក្យ​បញ្ជា​ទាំង​អស់​នេះ​មើល​ទៅ​ដូច​ជា៖

$ npx nodeshift --strictSSL=false --dockerImage=nodeshift/ubi8-s2i-web-app --build.env YARN_ENABLED=true --expose --deploy.env NPM_RUN="yarn start" --deploy.port 3000

$ npx nodeshift watch --strictSSL=false

ពាក្យបញ្ជានាឡិកាគឺជាអរូបីមួយនៅលើកំពូលនៃពាក្យបញ្ជា oc rsync អ្នកអាចស្វែងយល់បន្ថែមអំពីរបៀបដែលវាដំណើរការ នៅទីនេះ.

នេះជាឧទាហរណ៍សម្រាប់ React ប៉ុន្តែវិធីសាស្ត្រដូចគ្នាពិតប្រាកដអាចត្រូវបានប្រើជាមួយក្របខ័ណ្ឌផ្សេងទៀត ដោយគ្រាន់តែកំណត់អថេរបរិស្ថាន NPM_RUN ជាការចាំបាច់។
 

បំពង់ Openshift

បន្ទាប់មកយើងនឹងនិយាយអំពីឧបករណ៍ដូចជា OpenShift Pipelines និងរបៀបដែលវាអាចត្រូវបានប្រើជាជម្រើសមួយសម្រាប់ការបង្កើតខ្សែសង្វាក់។

តើអ្វីទៅជា OpenShift Pipelines

OpenShift Pipelines គឺជាប្រព័ន្ធរួមបញ្ចូល និងបញ្ជូនបន្ត CI/CD ដែលមានដើមកំណើតពីពពក ដែលត្រូវបានរចនាឡើងសម្រាប់រៀបចំបំពង់បង្ហូរប្រេងដោយប្រើ Tekton ។ Tekton គឺជាប្រភពបើកចំហរដែលអាចបត់បែនបាន Kubernetes-native CI/CD framework ដែលអនុញ្ញាតឱ្យអ្នកធ្វើស្វ័យប្រវត្តិកម្មការដាក់ឱ្យប្រើប្រាស់នៅលើវេទិកាផ្សេងៗ (Kubernetes, serverless, virtual machines ។ល។) ដោយអរូបីពីស្រទាប់មូលដ្ឋាន។

ការយល់ដឹងអំពីអត្ថបទនេះទាមទារចំណេះដឹងខ្លះៗអំពីបំពង់បង្ហូរប្រេង ដូច្នេះយើងសូមណែនាំយ៉ាងមុតមាំថាអ្នកអានជាមុនសិន សៀវភៅសិក្សាផ្លូវការ.

រៀបចំបរិយាកាសការងាររបស់អ្នក។

ដើម្បីលេងជាមួយឧទាហរណ៍ក្នុងអត្ថបទនេះ ដំបូងអ្នកត្រូវរៀបចំបរិយាកាសការងាររបស់អ្នក៖

1. ដំឡើង និងកំណត់រចនាសម្ព័ន្ធក្រុម OpenShift 4 ។ ឧទាហរណ៍របស់យើងប្រើ CodeReady Containers (CRD) សម្រាប់វា ការណែនាំអំពីការដំឡើងដែលអាចត្រូវបានរកឃើញ នៅទីនេះ.
2. បន្ទាប់ពីចង្កោមរួចរាល់ អ្នកត្រូវដំឡើង Pipeline Operator នៅលើវា។ កុំភ័យខ្លាចវាងាយស្រួល ការណែនាំអំពីការដំឡើង នៅទីនេះ.
3. ទាញយក Tekton CLI (tkn) នៅទីនេះ.
4. ដំណើរការឧបករណ៍បន្ទាត់ពាក្យបញ្ជា create-react-app ដើម្បីបង្កើតកម្មវិធីដែលបន្ទាប់មកអ្នកនឹងដាក់ពង្រាយ (នេះគឺជាកម្មវិធីសាមញ្ញ ប្រតិកម្ម).
5. (ជាជម្រើស) ក្លូនឃ្លាំងដើម្បីដំណើរការកម្មវិធីឧទាហរណ៍ក្នុងមូលដ្ឋានដោយដំឡើង npm ហើយបន្ទាប់មក npm ចាប់ផ្តើម។

ឃ្លាំងកម្មវិធីក៏នឹងមានថត k8s ដែលនឹងមាន Kubernetes/OpenShift YAMLs ដែលប្រើដើម្បីដាក់ឱ្យប្រើប្រាស់កម្មវិធី។ វានឹងមាន Tasks, ClusterTasks, Resources and Pipelines ដែលយើងនឹងបង្កើតនៅក្នុងនេះ។ ឃ្លាំង.

តោះ​ចាប់ផ្តើម

ជំហានដំបូងសម្រាប់ឧទាហរណ៍របស់យើងគឺបង្កើតគម្រោងថ្មីនៅក្នុងចង្កោម OpenShift ។ ចូរហៅគម្រោងនេះថា webapp-pipeline ហើយបង្កើតវាដោយប្រើពាក្យបញ្ជាខាងក្រោម៖

$ oc new-project webapp-pipeline

ឈ្មោះគម្រោងនេះនឹងបង្ហាញនៅក្នុងកូដនៅពេលក្រោយ ដូច្នេះប្រសិនបើអ្នកសម្រេចចិត្តដាក់ឈ្មោះវាអ្វីផ្សេងទៀត កុំភ្លេចកែសម្រួលកូដឧទាហរណ៍តាម។ ចាប់ផ្តើមពីចំណុចនេះ យើងនឹងមិនចុះពីលើចុះក្រោមទេ ប៉ុន្តែចុះក្រោម៖ នោះគឺដំបូងយើងនឹងបង្កើតសមាសធាតុទាំងអស់នៃ conveyor ហើយបន្ទាប់មកមានតែ conveyor ខ្លួនឯងប៉ុណ្ណោះ។

ដូច្នេះ ជាដំបូង...

ភារកិច្ច

ចូរយើងបង្កើតកិច្ចការពីរបី ដែលបន្ទាប់មកនឹងជួយដាក់ឱ្យប្រើប្រាស់កម្មវិធីនៅក្នុងបំពង់បង្ហូរប្រេងរបស់យើង។ កិច្ចការទីមួយ - apply_manifests_task - ទទួលខុសត្រូវក្នុងការអនុវត្ត YAML នៃធនធាន Kubernetes ទាំងនោះ (សេវាកម្ម ការដាក់ពង្រាយ និងផ្លូវ) ដែលមានទីតាំងនៅក្នុងថតឯកសារ k8s នៃកម្មវិធីរបស់យើង។ កិច្ចការទីពីរ – update_deployment_task – ទទួលខុសត្រូវចំពោះការអាប់ដេតរូបភាពដែលបានដាក់ពង្រាយរួចហើយទៅកាន់រូបភាពដែលបានបង្កើតដោយបំពង់បង្ហូរប្រេងរបស់យើង។

កុំបារម្ភប្រសិនបើវាមិនទាន់ច្បាស់នៅឡើយ។ តាមការពិត ការងារទាំងនេះគឺដូចជាឧបករណ៍ប្រើប្រាស់ ហើយយើងនឹងពិនិត្យមើលវាឱ្យកាន់តែលម្អិតនៅពេលក្រោយ។ សម្រាប់ពេលនេះ ចូរយើងបង្កើតពួកវា៖

$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/tasks/update_deployment_task.yaml
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/tasks/apply_manifests_task.yaml

បន្ទាប់មកដោយប្រើពាក្យបញ្ជា tkn CLI យើងនឹងពិនិត្យមើលថាភារកិច្ចត្រូវបានបង្កើត៖

$ tkn task ls

NAME                AGE
apply-manifests     1 minute ago
update-deployment   1 minute ago

ចំណាំ៖ ទាំងនេះគឺជាកិច្ចការក្នុងស្រុកសម្រាប់គម្រោងបច្ចុប្បន្នរបស់អ្នក។

កិច្ចការជាក្រុម

កិច្ចការ​ចង្កោម​គឺ​ជា​មូលដ្ឋាន​ដូចគ្នា​នឹង​កិច្ចការ​សាមញ្ញ។ នោះគឺ វាគឺជាបណ្តុំនៃជំហានដែលអាចប្រើឡើងវិញបាន ដែលត្រូវបានបញ្ចូលគ្នាក្នុងមធ្យោបាយមួយ ឬមួយផ្សេងទៀត នៅពេលដំណើរការកិច្ចការជាក់លាក់មួយ។ ភាព​ខុស​គ្នា​គឺ​ថា​កិច្ចការ​ចង្កោម​មាន​នៅ​គ្រប់​ទីកន្លែង​ក្នុង​ចង្កោម។ ដើម្បីមើលបញ្ជីនៃកិច្ចការចង្កោមដែលត្រូវបានបង្កើតដោយស្វ័យប្រវត្តិនៅពេលបន្ថែម Pipeline Operator យើងនឹងប្រើពាក្យបញ្ជា tkn CLI ម្តងទៀត៖

$ tkn clustertask ls

NAME                       AGE
buildah                    1 day ago
buildah-v0-10-0            1 day ago
jib-maven                  1 day ago
kn                         1 day ago
maven                      1 day ago
openshift-client           1 day ago
openshift-client-v0-10-0   1 day ago
s2i                        1 day ago
s2i-go                     1 day ago
s2i-go-v0-10-0             1 day ago
s2i-java-11                1 day ago
s2i-java-11-v0-10-0        1 day ago
s2i-java-8                 1 day ago
s2i-java-8-v0-10-0         1 day ago
s2i-nodejs                 1 day ago
s2i-nodejs-v0-10-0         1 day ago
s2i-perl                   1 day ago
s2i-perl-v0-10-0           1 day ago
s2i-php                    1 day ago
s2i-php-v0-10-0            1 day ago
s2i-python-3               1 day ago
s2i-python-3-v0-10-0       1 day ago
s2i-ruby                   1 day ago
s2i-ruby-v0-10-0           1 day ago
s2i-v0-10-0                1 day ago

ឥឡូវ​យើង​បង្កើត​កិច្ចការ​ចង្កោម​ពីរ។ ទីមួយនឹងបង្កើតរូបភាព S2I ហើយផ្ញើវាទៅបញ្ជីឈ្មោះ OpenShift ខាងក្នុង។ ទីពីរគឺបង្កើតរូបភាពរបស់យើងដោយផ្អែកលើ NGINX ដោយប្រើកម្មវិធីដែលយើងបានបង្កើតជាមាតិកា។

បង្កើតនិងផ្ញើរូបភាព

នៅពេលបង្កើតកិច្ចការដំបូង យើងនឹងនិយាយឡើងវិញនូវអ្វីដែលយើងបានធ្វើរួចហើយនៅក្នុងអត្ថបទមុនអំពីការជួបប្រជុំគ្នាដែលបានភ្ជាប់។ សូមចាំថាយើងបានប្រើរូបភាព S2I (ubi8-s2i-web-app) ដើម្បី "បង្កើត" កម្មវិធីរបស់យើង ហើយបានបញ្ចប់ដោយរូបភាពដែលបានរក្សាទុកនៅក្នុងបញ្ជីឈ្មោះខាងក្នុង OpenShift ។ ឥឡូវនេះយើងនឹងប្រើរូបភាពកម្មវិធីបណ្ដាញ S2I នេះដើម្បីបង្កើត DockerFile សម្រាប់កម្មវិធីរបស់យើង ហើយបន្ទាប់មកប្រើ Buildah ដើម្បីធ្វើការសាងសង់ពិតប្រាកដ ហើយរុញរូបភាពលទ្ធផលទៅបញ្ជីឈ្មោះខាងក្នុង OpenShift ព្រោះនោះជាអ្វីដែល OpenShift ធ្វើនៅពេលអ្នកដាក់ពង្រាយកម្មវិធីរបស់អ្នកដោយប្រើ NodeShift .

តើយើងដឹងរឿងទាំងអស់នេះដោយរបៀបណា? ពី កំណែផ្លូវការរបស់ Node.js ផ្លូវការយើងគ្រាន់តែចម្លងវា ហើយកែប្រែវាសម្រាប់ខ្លួនយើង។

ដូច្នេះ ឥឡូវ​យើង​បង្កើត​កិច្ចការ​ចង្កោម s2i-web-app៖

$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/clustertasks/s2i-web-app-task.yaml

យើងនឹងមិនវិភាគលម្អិតទេ ប៉ុន្តែនឹងផ្តោតតែលើប៉ារ៉ាម៉ែត្រ OUTPUT_DIR៖

params:
      - name: OUTPUT_DIR
        description: The location of the build output directory
        default: build

តាមលំនាំដើម ប៉ារ៉ាម៉ែត្រនេះគឺស្មើនឹង build ដែលជាកន្លែង React ដាក់មាតិកាដែលបានជួបប្រជុំគ្នា។ ក្របខណ្ឌផ្សេងទៀតប្រើផ្លូវផ្សេងគ្នា ឧទាហរណ៍នៅក្នុង Ember វានៅឆ្ងាយ។ លទ្ធផលនៃកិច្ចការចង្កោមដំបូងរបស់យើងនឹងជារូបភាពដែលមាន HTML, JavaScript និង CSS ដែលយើងប្រមូលបាន។

បង្កើតរូបភាពដោយផ្អែកលើ NGINX

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

ដើម្បីធ្វើដូចនេះយើង - ដូចគ្នាទៅនឹងអ្វីដែលបានរៀបរាប់ខាងលើ - នឹងបង្កើតការងារជាក្រុម webapp-build-runtime:

$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/clustertasks/webapp-build-runtime-task.yaml

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

ហើយនៅទីនេះយើងបន្តទៅចំណុចបន្ទាប់ដោយសុភាពរាបសា ...

ធនធាន

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

# This resource is the location of the git repo with the web application source
apiVersion: tekton.dev/v1alpha1
kind: PipelineResource
metadata:
  name: web-application-repo
spec:
  type: git
  params:
    - name: url
      value: https://github.com/nodeshift-starters/react-pipeline-example
    - name: revision
      value: master

នៅទីនេះ PipelineResource គឺជាប្រភេទ git ។ គន្លឹះ url ក្នុង​ផ្នែក params ចង្អុល​ទៅ​កន្លែង​ផ្ទុក​ជាក់លាក់ ហើយ​បញ្ជាក់​សាខា​មេ (នេះ​ជា​ជម្រើស ប៉ុន្តែ​យើង​សរសេរ​វា​សម្រាប់​ភាព​ពេញលេញ)។

ឥឡូវនេះយើងត្រូវបង្កើតធនធានសម្រាប់រូបភាពដែលលទ្ធផលនៃកិច្ចការ s2i-web-app នឹងត្រូវបានរក្សាទុក វាត្រូវបានធ្វើដូចនេះ៖

# This resource is the result of running "npm run build",  the resulting built files will be located in /opt/app-root/output
apiVersion: tekton.dev/v1alpha1
kind: PipelineResource
metadata:
  name: built-web-application-image
spec:
  type: image
  params:
    - name: url
      value: image-registry.openshift-image-registry.svc:5000/webapp-pipeline/built-web-application:latest

នៅទីនេះ PipelineResource គឺជារូបភាពប្រភេទ ហើយតម្លៃនៃប៉ារ៉ាម៉ែត្រ url ចង្អុលទៅ OpenShift Image Registry ខាងក្នុង ជាពិសេសរូបភាពដែលមានទីតាំងនៅ webapp-pipeline namespace។ កុំភ្លេចផ្លាស់ប្តូរការកំណត់នេះ ប្រសិនបើអ្នកកំពុងប្រើលំហឈ្មោះផ្សេង។

ហើយជាចុងក្រោយ ធនធានចុងក្រោយដែលយើងត្រូវការក៏ជារូបភាពប្រភេទ ហើយនេះនឹងក្លាយជារូបភាព NGINX ចុងក្រោយដែលបន្ទាប់មកនឹងត្រូវបានប្រើកំឡុងពេលដាក់ពង្រាយ៖

# This resource is the image that will be just the static html, css, js files being run with nginx
apiVersion: tekton.dev/v1alpha1
kind: PipelineResource
metadata:
  name: runtime-web-application-image
spec:
  type: image
  params:
    - name: url
      value: image-registry.openshift-image-registry.svc:5000/webapp-pipeline/runtime-web-application:latest

ជាថ្មីម្តងទៀត សូមចំណាំថាធនធាននេះរក្សាទុករូបភាពនៅក្នុងបញ្ជីឈ្មោះ OpenShift ខាងក្នុងនៅក្នុង webapp-pipeline namespace។

ដើម្បីបង្កើតធនធានទាំងអស់នេះក្នុងពេលតែមួយ យើងប្រើពាក្យបញ្ជាបង្កើត៖

$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/resources/resource.yaml

អ្នកអាចប្រាកដថាធនធានត្រូវបានបង្កើតដូចនេះ៖

$ tkn resource ls

បំពង់បញ្ជូន

ឥឡូវ​នេះ​យើង​មាន​សមាសធាតុ​ចាំបាច់​ទាំង​អស់​ហើយ ចូរ​ប្រមូល​បំពង់​ពី​ពួក​វា​ដោយ​បង្កើត​វា​ដោយ​ប្រើ​ពាក្យ​បញ្ជា​ដូច​ខាង​ក្រោម៖

$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/pipelines/build-and-deploy-react.yaml

ប៉ុន្តែមុនពេលដែលយើងដំណើរការពាក្យបញ្ជានេះ សូមក្រឡេកមើលសមាសធាតុទាំងនេះ។ ទីមួយគឺឈ្មោះ៖

apiVersion: tekton.dev/v1alpha1
kind: Pipeline
metadata:
  name: build-and-deploy-react

បន្ទាប់មកនៅក្នុងផ្នែក spec យើងឃើញការចង្អុលបង្ហាញអំពីធនធានដែលយើងបានបង្កើតមុននេះ៖

spec:
  resources:
    - name: web-application-repo
      type: git
    - name: built-web-application-image
      type: image
    - name: runtime-web-application-image
      type: image

បន្ទាប់មកយើងបង្កើតកិច្ចការដែលបំពង់បង្ហូរប្រេងរបស់យើងត្រូវការដើម្បីបញ្ចប់។ ជាដំបូងវាត្រូវតែប្រតិបត្តិភារកិច្ច s2i-web-app ដែលយើងបានបង្កើតរួចហើយ៖

tasks:
    - name: build-web-application
      taskRef:
        name: s2i-web-app
        kind: ClusterTask

ភារកិច្ចនេះត្រូវការបញ្ចូល (ធនធាន gir) និងទិន្នផល (ធនធានគេហទំព័រដែលបានសាងសង់ឡើង - កម្មវិធី - រូបភាព) ។ យើងក៏ឆ្លងកាត់វានូវប៉ារ៉ាម៉ែត្រពិសេសមួយផងដែរ ដូច្នេះវាមិនអាចផ្ទៀងផ្ទាត់ TLS បានទេ ដោយសារយើងកំពុងប្រើវិញ្ញាបនបត្រដែលចុះហត្ថលេខាដោយខ្លួនឯង៖

resources:
        inputs:
          - name: source
            resource: web-application-repo
        outputs:
          - name: image
            resource: built-web-application-image
      params:
        - name: TLSVERIFY
          value: "false"

កិច្ចការបន្ទាប់គឺស្ទើរតែដូចគ្នា មានតែនៅទីនេះ webapp-build-runtime cluster task ដែលយើងបានបង្កើតរួចហើយត្រូវបានគេហៅថា៖

name: build-runtime-image
    taskRef:
      name: webapp-build-runtime
      kind: ClusterTask

ដូចនឹងកិច្ចការមុនដែរ យើងឆ្លងកាត់ធនធានមួយ ប៉ុន្តែឥឡូវនេះ វាត្រូវបានសាងសង់ឡើង-web-application-image (លទ្ធផលនៃកិច្ចការពីមុនរបស់យើង)។ ហើយជាលទ្ធផល យើងកំណត់រូបភាពម្តងទៀត។ ដោយសារ​កិច្ចការ​នេះ​ត្រូវ​តែ​ត្រូវ​បាន​ប្រតិបត្តិ​បន្ទាប់​ពី​កិច្ចការ​មុន យើង​បន្ថែម​វាល runAfter៖

resources:
        inputs:
          - name: image
            resource: built-web-application-image
        outputs:
          - name: image
            resource: runtime-web-application-image
        params:
        - name: TLSVERIFY
          value: "false"
      runAfter:
        - build-web-application

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

ការចាប់ផ្តើមឧបករណ៍បញ្ជូន

ដូច្នេះគ្រប់ផ្នែកទាំងអស់នៃបំពង់បង្ហូរប្រេងរបស់យើងត្រូវបានបង្កើតឡើង ហើយយើងនឹងដំណើរការវាដោយប្រើពាក្យបញ្ជាដូចខាងក្រោម៖

$ tkn pipeline start build-and-deploy-react

នៅដំណាក់កាលនេះ បន្ទាត់ពាក្យបញ្ជាត្រូវបានប្រើប្រាស់អន្តរកម្ម ហើយអ្នកត្រូវជ្រើសរើសធនធានសមស្រប ដើម្បីឆ្លើយតបទៅនឹងសំណើនីមួយៗរបស់វា៖ សម្រាប់ធនធាន git សូមជ្រើសរើស web-application-repo បន្ទាប់មកសម្រាប់ធនធានរូបភាពដំបូង កម្មវិធីបង្កើតគេហទំព័រ -image ហើយចុងក្រោយសម្រាប់ធនធានរូបភាពទីពីរ -runtime-web-application-image៖

? Choose the git resource to use for web-application-repo: web-application-repo (https://github.com/nodeshift-starters/react-pipeline-example)
? Choose the image resource to use for built-web-application-image: built-web-application-image (image-registry.openshift-image-registry.svc:5000/webapp-pipeline/built-web-
application:latest)
? Choose the image resource to use for runtime-web-application-image: runtime-web-application-image (image-registry.openshift-image-registry.svc:5000/webapp-pipeline/runtim
e-web-application:latest)
Pipelinerun started: build-and-deploy-react-run-4xwsr

ឥឡូវនេះសូមពិនិត្យមើលស្ថានភាពនៃបំពង់ដោយប្រើពាក្យបញ្ជាខាងក្រោម:

$ tkn pipeline logs -f

នៅពេលដែលបំពង់បង្ហូរប្រេងបានចាប់ផ្តើម ហើយកម្មវិធីត្រូវបានដាក់ឱ្យប្រើប្រាស់ យើងអាចស្នើសុំផ្លូវដែលបានបោះផ្សាយដោយប្រើពាក្យបញ្ជាដូចខាងក្រោម៖

$ oc get route react-pipeline-example --template='http://{{.spec.host}}'

សម្រាប់ការមើលឃើញកាន់តែច្បាស់ អ្នកអាចមើលបំពង់របស់យើងនៅក្នុងរបៀបអ្នកអភិវឌ្ឍន៍នៃកុងសូលគេហទំព័រនៅក្នុងផ្នែក បំពង់ដូចដែលបានបង្ហាញនៅក្នុងរូបភព។ ១.

រូប ១. ការពិនិត្យឡើងវិញនៃបំពង់ដែលកំពុងដំណើរការ។

ការចុចលើបំពង់ដែលកំពុងដំណើរការបង្ហាញព័ត៌មានលម្អិតបន្ថែម ដូចបង្ហាញក្នុងរូបភាពទី 2 ។

អង្ករ។ 2. ព័ត៌មានបន្ថែមអំពីបំពង់បង្ហូរប្រេង។

បន្ទាប់ពីព័ត៌មានបន្ថែម អ្នកអាចឃើញកម្មវិធីដែលកំពុងដំណើរការនៅក្នុងទិដ្ឋភាព Topologyដូចដែលបានបង្ហាញក្នុងរូបភាពទី 3 ។

រូបទី 3. ចាប់ផ្តើមផត។

ចុចលើរង្វង់នៅជ្រុងខាងស្តាំខាងលើនៃរូបតំណាងបើកកម្មវិធីរបស់យើង ដូចដែលបានបង្ហាញក្នុងរូបទី 4 ។

អង្ករ។ 4. កំពុងដំណើរការកម្មវិធី React ។

សេចក្តីសន្និដ្ឋាន

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

ធនធានបន្ថែម (EN)

• សៀវភៅអេឡិចត្រូនិចឥតគិតថ្លៃ "ការអភិវឌ្ឍន៍លើ OpenShift: ការណែនាំសម្រាប់អ្នកមិនចេះអត់ធ្មត់"
• ការបង្កើតកម្មវិធី Node.js ដែលផ្តោតលើកុងតឺន័រដោយប្រើ Red Hat OpenShift Application Runtimes និង Istio
• ការបំបាត់កំហុសកម្មវិធី Node.js នៅលើ OpenShift ដោយប្រើ Chrome DevTools
• ពាក្យបញ្ជាបីដើម្បីធ្វើជាម្ចាស់ Express នៅលើ OpenShift ពីទទេ
• សេចក្តីប្រកាសនៃកំណែដែលអាចប្រើបានជាទូទៅនៃ Node.js ដែលជាផ្នែកមួយនៃ Red Hat OpenShift Application Runtimes
• ការត្រួតពិនិត្យកម្មវិធី Node.js នៅលើ OpenShift ជាមួយ Prometheus
• អត្ថបទផ្សេងទៀតនៅលើ OpenShift និង Kubernetes នៅលើគេហទំព័រ Red Hat

សេចក្តីប្រកាសអំពី webinars នាពេលខាងមុខ

យើង​កំពុង​ចាប់ផ្តើម​វគ្គ​សិក្ខាសាលា​នៅ​ថ្ងៃ​សុក្រ​អំពី​បទពិសោធន៍​ដើម​ដោយ​ប្រើ Red Hat OpenShift Container Platform និង Kubernetes៖

• ថ្ងៃទី 28 ខែសីហា ការសិក្ខាសាលាលើបណ្តាញអធិរាជ "ប្រតិបត្តិករ"៖ ប្រតិបត្តិករនៅក្នុង OpenShift និង Kubernetes
• ថ្ងៃទី 11 ខែកញ្ញា DeploymentConfig vs Deployment – ​​OpenShift-specific magic សម្រាប់ការកសាង និងដាក់ពង្រាយកម្មវិធី
• ថ្ងៃទី 25 ខែកញ្ញា Red Hat OpenShift និង Machine API
• ថ្ងៃទី 9 ខែតុលា របៀបទប់ទល់នឹងការកើនឡើងភ្លាមៗនៃបន្ទុកការងារ
• ថ្ងៃទី 23 ខែតុលា Embedded Jenkins, Pipeline-builds, Tekton in Red Hat OpenShift Container Platform

ប្រភព: www.habr.com