ឥឡូវនេះអ្នកអាចបង្កើតរូបភាព Docker នៅក្នុង werf ដោយប្រើ Dockerfile ធម្មតា។

យឺត​ប្រសើរ​ជាង​អវត្តមាន។ ឬរបៀបដែលយើងស្ទើរតែមានកំហុសធ្ងន់ធ្ងរដោយមិនមានការគាំទ្រសម្រាប់ Dockerfiles ធម្មតាដើម្បីបង្កើតរូបភាពកម្មវិធី។

យើងនឹងនិយាយអំពី werf - ឧបករណ៍ប្រើប្រាស់ GitOps ដែលរួមបញ្ចូលជាមួយប្រព័ន្ធ CI/CD ណាមួយ និងផ្តល់នូវការគ្រប់គ្រងវដ្តជីវិតកម្មវិធីទាំងមូល ដែលអនុញ្ញាតឱ្យ៖

• ប្រមូលនិងបោះពុម្ពរូបភាព,
• ដាក់ពង្រាយកម្មវិធីនៅក្នុង Kubernetes,
• លុបរូបភាពដែលមិនប្រើដោយប្រើគោលការណ៍ពិសេស។

ទស្សនវិជ្ជារបស់គម្រោងគឺប្រមូលឧបករណ៍កម្រិតទាបចូលទៅក្នុងប្រព័ន្ធបង្រួបបង្រួមតែមួយដែលផ្តល់ឱ្យវិស្វករ DevOps គ្រប់គ្រងលើកម្មវិធី។ ប្រសិនបើអាចធ្វើបាន ឧបករណ៍ប្រើប្រាស់ដែលមានស្រាប់ (ដូចជា Helm និង Docker) គួរតែត្រូវបានប្រើ។ ប្រសិនបើគ្មានដំណោះស្រាយចំពោះបញ្ហាទេ យើងអាចបង្កើត និងគាំទ្រអ្វីៗគ្រប់យ៉ាងដែលចាំបាច់សម្រាប់បញ្ហានេះ។

ផ្ទៃខាងក្រោយ៖ អ្នកប្រមូលរូបភាពផ្ទាល់ខ្លួនរបស់អ្នក។

នេះជាអ្វីដែលបានកើតឡើងជាមួយអ្នកប្រមូលរូបភាពក្នុង werf៖ Dockerfile ធម្មតាមិនគ្រប់គ្រាន់សម្រាប់យើងទេ។ ប្រសិនបើអ្នកក្រឡេកមើលប្រវត្តិនៃគម្រោងនេះ បញ្ហានេះបានលេចឡើងរួចហើយនៅក្នុងកំណែដំបូងនៃ werf (បន្ទាប់មកនៅតែ ត្រូវបានគេស្គាល់ថាជា dapp).

ខណៈពេលដែលបង្កើតឧបករណ៍សម្រាប់បង្កើតកម្មវិធីចូលទៅក្នុងរូបភាព Docker យើងបានដឹងភ្លាមៗថា Dockerfile មិនស័ក្តិសមសម្រាប់យើងសម្រាប់កិច្ចការជាក់លាក់មួយចំនួន៖

1. តំរូវការដើម្បីបង្កើតកម្មវិធីបណ្តាញតូចធម្មតាតាមគ្រោងការណ៍ស្តង់ដារខាងក្រោម៖
   • ដំឡើងភាពអាស្រ័យកម្មវិធីពេញប្រព័ន្ធ,
   • ដំឡើងបណ្តុំនៃបណ្ណាល័យភាពអាស្រ័យកម្មវិធី,
   • ប្រមូលទ្រព្យសម្បត្តិ,
   • ហើយសំខាន់បំផុត ធ្វើបច្ចុប្បន្នភាពកូដក្នុងរូបភាពយ៉ាងរហ័ស និងមានប្រសិទ្ធភាព។
2. នៅពេលដែលការផ្លាស់ប្តូរត្រូវបានធ្វើឡើងចំពោះឯកសារគម្រោង អ្នកសាងសង់ត្រូវតែបង្កើតស្រទាប់ថ្មីយ៉ាងឆាប់រហ័សដោយអនុវត្តបំណះទៅនឹងឯកសារដែលបានផ្លាស់ប្តូរ។
3. ប្រសិនបើឯកសារមួយចំនួនបានផ្លាស់ប្តូរ នោះចាំបាច់ត្រូវបង្កើតដំណាក់កាលអាស្រ័យដែលត្រូវគ្នាឡើងវិញ។

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

ជាទូទៅដោយមិនគិតពីរដង យើងបានបំពាក់ខ្លួនយើងជាមួយនឹងភាសាសរសេរកម្មវិធីដែលយើងបានប្រើ (មើល​ខាង​ក្រោម) និងវាយផ្លូវដើម្បីអនុវត្ត DSL ផ្ទាល់ខ្លួន! អនុលោមតាមគោលបំណង វាមានគោលបំណងពិពណ៌នាអំពីដំណើរការជួបប្រជុំគ្នាជាដំណាក់កាល និងកំណត់ភាពអាស្រ័យនៃដំណាក់កាលទាំងនេះលើឯកសារ។ ហើយបានបំពេញបន្ថែម អ្នកប្រមូលផ្ទាល់ខ្លួនដែលបានប្រែក្លាយ DSL ទៅជាគោលដៅចុងក្រោយ - រូបភាពដែលបានជួបប្រជុំគ្នា។ ដំបូង DSL គឺនៅក្នុង Ruby ប៉ុន្តែដូច ការផ្លាស់ប្តូរទៅ Golang - ការកំណត់រចនាសម្ព័ន្ធរបស់អ្នកប្រមូលរបស់យើងបានចាប់ផ្តើមត្រូវបានពិពណ៌នានៅក្នុងឯកសារ YAML ។

ការកំណត់រចនាសម្ព័ន្ធចាស់សម្រាប់ dapp នៅក្នុង Ruby

ការកំណត់បច្ចុប្បន្នសម្រាប់ werf នៅលើ YAML

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

NB៖ នៅពេលនេះ អ្នកប្រមូលរបស់យើងដែលធ្វើការជាមួយការកំណត់រចនាសម្ព័ន្ធរបស់វាផ្ទាល់ (នៅក្នុង YAML) និងត្រូវបានគេហៅថាអ្នកប្រមូល Stapel បានបង្កើតរួចហើយទៅជាឧបករណ៍ដ៏មានឥទ្ធិពល។ ការពិពណ៌នាលម្អិតរបស់វាសមនឹងអត្ថបទដាច់ដោយឡែក ហើយព័ត៌មានលម្អិតជាមូលដ្ឋានអាចរកបាននៅក្នុង ឯកសារ.

ការយល់ដឹងអំពីបញ្ហា

ប៉ុន្តែ​យើង​បាន​ដឹង​ហើយ​មិនមែន​ភ្លាមៗ​ទេ​ថា​យើង​មាន​កំហុស​មួយ​គឺ​យើង​មិន​បាន​បន្ថែម​សមត្ថភាព បង្កើតរូបភាពតាមរយៈ Dockerfile ស្តង់ដារ ហើយបញ្ចូលពួកវាទៅក្នុងហេដ្ឋារចនាសម្ព័ន្ធគ្រប់គ្រងកម្មវិធីពីចុងដល់ចប់ដូចគ្នា (ឧ. ប្រមូលរូបភាព ដាក់ពង្រាយ និងសម្អាតពួកវា)។ តើវាអាចធ្វើដូចម្តេចដើម្បីធ្វើឱ្យឧបករណ៍សម្រាប់ដាក់ឱ្យប្រើប្រាស់នៅក្នុង Kubernetes និងមិនអនុវត្តការគាំទ្រ Dockerfile ពោលគឺឧ។ វិធីស្តង់ដារដើម្បីពិពណ៌នារូបភាពសម្រាប់គម្រោងភាគច្រើន?..

ជំនួសឱ្យការឆ្លើយសំណួរនេះ យើងផ្តល់ជូននូវដំណោះស្រាយមួយ។ ចុះបើអ្នកមាន Dockerfile (ឬសំណុំ Dockerfiles) ហើយចង់ប្រើ werf?

NB៖ និយាយអញ្ចឹង ហេតុអ្វីបានជាអ្នកចង់ប្រើ werf? លក្ខណៈសំខាន់ៗមានដូចខាងក្រោម៖

• វដ្តនៃការគ្រប់គ្រងកម្មវិធីពេញលេញ រួមទាំងការសម្អាតរូបភាព។
• សមត្ថភាពក្នុងការគ្រប់គ្រងការជួបប្រជុំគ្នានៃរូបភាពជាច្រើនក្នុងពេលតែមួយពីការកំណត់តែមួយ;
• ដំណើរការដាក់ពង្រាយប្រសើរឡើងសម្រាប់គំនូសតាងដែលឆបគ្នាជាមួយ Helm ។

បញ្ជីពេញលេញបន្ថែមទៀតនៃពួកវាអាចរកបាននៅ ទំព័រគម្រោង.

ដូច្នេះ ប្រសិនបើមុននេះ ពួកយើងនឹងស្នើឱ្យសរសេរ Dockerfile ឡើងវិញនៅក្នុង config របស់យើងឥឡូវនេះ យើងនឹងនិយាយដោយរីករាយថា "Let werf build your Dockerfiles!"

របៀបប្រើ?

ការអនុវត្តពេញលេញនៃលក្ខណៈពិសេសនេះបានបង្ហាញខ្លួននៅក្នុងការចេញផ្សាយ werf v1.0.3-beta.1. គោលការណ៍ទូទៅគឺសាមញ្ញ៖ អ្នកប្រើប្រាស់បញ្ជាក់ផ្លូវទៅកាន់ Dockerfile ដែលមានស្រាប់នៅក្នុង werf config ហើយបន្ទាប់មកដំណើរការពាក្យបញ្ជា werf build... ហើយនោះហើយជាវា - werf នឹងប្រមូលផ្តុំរូបភាព។ សូមក្រឡេកមើលឧទាហរណ៍អរូបី។

តោះប្រកាសបន្ទាប់ Dockerfile នៅក្នុងឫសគម្រោង៖

FROM ubuntu:18.04
RUN echo Building ...

ហើយយើងនឹងប្រកាស werf.yamlដែលប្រើនេះ។ Dockerfile:

configVersion: 1
project: dockerfile-example
---
image: ~
dockerfile: ./Dockerfile

ទាំងអស់! ឆ្វេង រត់ werf build:

លើសពីនេះទៀតអ្នកអាចប្រកាសដូចខាងក្រោម werf.yaml ដើម្បីបង្កើតរូបភាពជាច្រើនពី Dockerfiles ផ្សេងៗគ្នាក្នុងពេលតែមួយ៖

configVersion: 1
project: dockerfile-example
---
image: backend
dockerfile: ./dockerfiles/Dockerfile-backend
---
image: frontend
dockerfile: ./dockerfiles/Dockerfile-frontend

ជាចុងក្រោយ វាក៏គាំទ្រការឆ្លងកាត់ប៉ារ៉ាម៉ែត្រសាងសង់បន្ថែមផងដែរ ដូចជា --build-arg и --add-host - តាមរយៈការកំណត់រចនាសម្ព័ន្ធ werf ។ ការពិពណ៌នាពេញលេញនៃការកំណត់រចនាសម្ព័ន្ធរូបភាព Dockerfile មាននៅ ទំព័រឯកសារ.

តើវាដំណើរការយ៉ាងដូចម្តេច?

ក្នុងអំឡុងពេលដំណើរការបង្កើត ឃ្លាំងសម្ងាត់ស្តង់ដារនៃស្រទាប់មូលដ្ឋាននៅក្នុងមុខងារ Docker ។ ទោះជាយ៉ាងណាក៏ដោយអ្វីដែលសំខាន់នោះគឺថា werf ផងដែរ។ រួមបញ្ចូលការកំណត់រចនាសម្ព័ន្ធ Dockerfile ទៅក្នុងហេដ្ឋារចនាសម្ព័ន្ធរបស់វា។. តើ​នេះ​មានន័យថា​ម៉េច​?

1. រូបភាពនីមួយៗដែលបង្កើតឡើងពី Dockerfile មានដំណាក់កាលមួយហៅថា dockerfile (អ្នកអាចអានបន្ថែមអំពីដំណាក់កាលអ្វីខ្លះនៅក្នុង werf នៅទីនេះ).
2. សម្រាប់ឆាក dockerfile werf គណនាហត្ថលេខាដែលអាស្រ័យលើមាតិកានៃការកំណត់រចនាសម្ព័ន្ធ Dockerfile ។ នៅពេលដែលការកំណត់រចនាសម្ព័ន្ធ Dockerfile ផ្លាស់ប្តូរ ហត្ថលេខាដំណាក់កាលផ្លាស់ប្តូរ dockerfile ហើយ werf ផ្តួចផ្តើមការកសាងឡើងវិញនូវដំណាក់កាលនេះជាមួយនឹងការកំណត់រចនាសម្ព័ន្ធ Dockerfile ថ្មី។ ប្រសិនបើហត្ថលេខាមិនផ្លាស់ប្តូរទេនោះ werf យករូបភាពពីឃ្លាំងសម្ងាត់ (ព័ត៌មានលម្អិតបន្ថែមអំពីការប្រើប្រាស់ហត្ថលេខានៅក្នុង werf ត្រូវបានពិពណ៌នានៅក្នុង របាយការណ៍នេះ។).
3. បន្ទាប់មក រូបភាពដែលប្រមូលបានអាចត្រូវបានបោះពុម្ពដោយប្រើពាក្យបញ្ជា werf publish (ឬ werf build-and-publish) ហើយប្រើវាសម្រាប់ដាក់ពង្រាយទៅ Kubernetes ។ រូបភាពដែលបានបោះផ្សាយទៅកាន់ Docker Registry នឹងត្រូវបានសម្អាតដោយប្រើឧបករណ៍សម្អាត werf ស្តង់ដារ ពោលគឺឧ។ រូបភាពចាស់ (ចាស់ជាង N ថ្ងៃ) រូបភាពដែលភ្ជាប់ជាមួយសាខា Git ដែលមិនមាន ហើយគោលការណ៍ផ្សេងទៀតនឹងត្រូវបានសម្អាតដោយស្វ័យប្រវត្តិ។

ព័ត៌មានលម្អិតបន្ថែមអំពីចំណុចដែលបានពិពណ៌នានៅទីនេះអាចរកបាននៅក្នុងឯកសារ៖

• ដំណើរការបោះពុម្ព;
• ការរួមបញ្ចូលជាមួយដំណើរការដាក់ឱ្យប្រើប្រាស់ Kubernetes;
• ដំណើរការសំអាត.

កំណត់ចំណាំ និងការប្រុងប្រយ័ត្ន

1. URL ខាងក្រៅមិនត្រូវបានគាំទ្រក្នុង ADD ទេ។

បច្ចុប្បន្ននេះ វាមិនត្រូវបានគាំទ្រក្នុងការប្រើ URL ខាងក្រៅនៅក្នុងការណែនាំនោះទេ។ ADD. Werf នឹងមិនចាប់ផ្តើមការកសាងឡើងវិញនៅពេលដែលធនធាននៅ URL ដែលបានបញ្ជាក់ផ្លាស់ប្តូរ។ យើងគ្រោងនឹងបន្ថែមមុខងារនេះក្នុងពេលឆាប់ៗនេះ។

2. អ្នកមិនអាចបន្ថែម .git ទៅក្នុងរូបភាពបានទេ។

និយាយជាទូទៅការបន្ថែមថត .git នៅក្នុងរូបភាព - ការអនុវត្តអាក្រក់ដ៏កាចសាហាវ ហើយនេះជាមូលហេតុ៖

1. ប្រសិនបើមាន .git នៅតែស្ថិតក្នុងរូបភាពចុងក្រោយ វាបំពានគោលការណ៍ កម្មវិធី 12 កត្តា៖ ដោយសាររូបភាពចុងក្រោយត្រូវតែភ្ជាប់ទៅការប្តេជ្ញាចិត្តតែមួយ វាមិនគួរធ្វើបានទេ។ git checkout ការ​ប្រព្រឹត្ត​តាម​អំពើ​ចិត្ត។
2. .git បង្កើនទំហំនៃរូបភាព (ឃ្លាំងអាចមានទំហំធំដោយសារតែឯកសារធំម្តងត្រូវបានបន្ថែមទៅវាហើយបន្ទាប់មកលុប) ។ ទំហំនៃមែកធាងការងារដែលទាក់ទងតែជាមួយការប្តេជ្ញាចិត្តជាក់លាក់មួយនឹងមិនអាស្រ័យលើប្រវត្តិនៃប្រតិបត្តិការនៅក្នុង Git នោះទេ។ ក្នុងករណីនេះការបន្ថែមនិងការដកចេញជាបន្តបន្ទាប់ .git ពីរូបភាពចុងក្រោយនឹងមិនដំណើរការទេ៖ រូបភាពនឹងនៅតែទទួលបានស្រទាប់បន្ថែម - នេះជារបៀបដែល Docker ដំណើរការ។
3. Docker អាចផ្តួចផ្តើមការកសាងឡើងវិញដែលមិនចាំបាច់ បើទោះបីជាការប្តេជ្ញាដូចគ្នាកំពុងត្រូវបានសាងសង់ ប៉ុន្តែមកពីដើមឈើការងារផ្សេងៗគ្នា។ ឧទាហរណ៍ GitLab បង្កើតថតក្លូនដាច់ដោយឡែកពីគ្នា។ /home/gitlab-runner/builds/HASH/[0-N]/yourproject នៅពេលដែលការដំឡើងប៉ារ៉ាឡែលត្រូវបានបើក។ ការផ្គុំឡើងវិញបន្ថែមនឹងកើតឡើងដោយសារតែការពិតដែលថត .git គឺខុសគ្នានៅក្នុងកំណែក្លូនផ្សេងគ្នានៃឃ្លាំងដូចគ្នា បើទោះបីជាការប្តេជ្ញាចិត្តដូចគ្នាត្រូវបានបង្កើតឡើងក៏ដោយ។

ចំណុចចុងក្រោយក៏មានផលវិបាកនៅពេលប្រើ werf ។ Werf តម្រូវឱ្យឃ្លាំងសម្ងាត់ដែលបានសាងសង់មានវត្តមាននៅពេលដំណើរការពាក្យបញ្ជាមួយចំនួន (ឧ. werf deploy) នៅពេលដែលពាក្យបញ្ជាទាំងនេះដំណើរការ werf គណនាហត្ថលេខាដំណាក់កាលសម្រាប់រូបភាពដែលបានបញ្ជាក់នៅក្នុង werf.yamlហើយពួកគេត្រូវតែនៅក្នុងឃ្លាំងសម្ងាត់ការជួបប្រជុំគ្នា - បើមិនដូច្នេះទេពាក្យបញ្ជានឹងមិនអាចបន្តដំណើរការបានទេ។ ប្រសិនបើហត្ថលេខាដំណាក់កាលអាស្រ័យលើខ្លឹមសារ .gitបន្ទាប់មកយើងទទួលបានឃ្លាំងសម្ងាត់ដែលមិនស្ថិតស្ថេរចំពោះការផ្លាស់ប្តូរឯកសារដែលមិនពាក់ព័ន្ធ ហើយ werf នឹងមិនអាចអត់ទោសឱ្យការត្រួតពិនិត្យបែបនេះបានទេ (សម្រាប់ព័ត៌មានលម្អិត សូមមើល ឯកសារ).

ជាទូទៅ បន្ថែមតែឯកសារចាំបាច់មួយចំនួន តាមរយៈការណែនាំ ADD ក្នុងករណីណាក៏ដោយបង្កើនប្រសិទ្ធភាពនិងភាពជឿជាក់នៃការសរសេរ Dockerfileហើយវាក៏ធ្វើអោយប្រសើរឡើងនូវស្ថេរភាពនៃឃ្លាំងសម្ងាត់ដែលប្រមូលបានសម្រាប់ការនេះ។ Dockerfileទៅនឹងការផ្លាស់ប្តូរដែលមិនពាក់ព័ន្ធនៅក្នុង Git ។

លទ្ធផល

ផ្លូវដំបូងរបស់យើងក្នុងការសរសេរកម្មវិធីសាងសង់ផ្ទាល់ខ្លួនរបស់យើងសម្រាប់តម្រូវការជាក់លាក់គឺពិបាក ស្មោះត្រង់ និងត្រង់៖ ជំនួសឱ្យការប្រើឈើច្រត់នៅលើ Dockerfile ស្តង់ដារ យើងបានសរសេរដំណោះស្រាយរបស់យើងជាមួយនឹងវាក្យសម្ព័ន្ធផ្ទាល់ខ្លួន។ ហើយនេះមានគុណសម្បត្តិរបស់វា: អ្នកប្រមូល Stapel ដោះស្រាយភារកិច្ចរបស់វាយ៉ាងល្អឥតខ្ចោះ។

ទោះយ៉ាងណាក៏ដោយ នៅក្នុងដំណើរការនៃការសរសេរកម្មវិធីសាងសង់ផ្ទាល់ខ្លួនរបស់យើង យើងបានបាត់បង់ការមើលឃើញនៃការគាំទ្រសម្រាប់ Dockerfiles ដែលមានស្រាប់។ ឥឡូវនេះ កំហុសនេះត្រូវបានជួសជុល ហើយនៅពេលអនាគត យើងមានគម្រោងបង្កើតការគាំទ្រ Dockerfile រួមជាមួយនឹងអ្នកបង្កើត Stapel ផ្ទាល់ខ្លួនរបស់យើងសម្រាប់ការស្ថាបនាដែលបានចែកចាយ និងសម្រាប់ការបង្កើតដោយប្រើ Kubernetes (ឧទាហរណ៍ បង្កើតនៅលើអ្នករត់ខាងក្នុង Kubernetes ដូចដែលបានធ្វើនៅក្នុង kaniko)។

ដូច្នេះប្រសិនបើអ្នកស្រាប់តែមាន Dockerfiles ពីរបីកំពុងស្ថិតនៅជុំវិញ... សាកល្បង werf!

PS បញ្ជីឯកសារលើប្រធានបទ

• ការណែនាំសម្រាប់ការចាប់ផ្តើមរហ័ស;
• ការកំណត់រចនាសម្ព័ន្ធ dockerfile builder;
• ឧបករណ៍ដំណាក់កាលនៅក្នុង werf;
• ដំណើរការបោះពុម្ពរូបភាព;
• ការរួមបញ្ចូលជាមួយដំណើរការដាក់ឱ្យប្រើប្រាស់ Kubernetes;
• ដំណើរការសំអាត;
• Stapel builder ជាជម្រើសជំនួស Dockerfile.

សូមអានផងដែរនៅក្នុងប្លុករបស់យើង៖ "werf - ឧបករណ៍របស់យើងសម្រាប់ CI / CD នៅក្នុង Kubernetes (ទិដ្ឋភាពទូទៅ និងរបាយការណ៍វីដេអូ)"។

ប្រភព: www.habr.com