ការកសាងរូបភាព Docker ល្អបំផុតសម្រាប់កម្មវិធី Spring Boot

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

អត្ថបទនេះគ្របដណ្តប់វិធីផ្សេងគ្នាក្នុងការផ្ទុកកម្មវិធី Spring Boot៖

• បង្កើតរូបភាព Docker ដោយប្រើឯកសារ Docker,
• បង្កើតរូបភាព OCI ពីប្រភពដោយប្រើ Cloud-Native Buildpack,
• និងការបង្កើនប្រសិទ្ធភាពរូបភាពពេលដំណើរការដោយការបំបែកផ្នែកនៃ JAR ទៅជាស្រទាប់ផ្សេងៗគ្នាដោយប្រើឧបករណ៍ពហុស្រទាប់។

 ឧទាហរណ៍កូដ

អត្ថបទនេះត្រូវបានអមដោយឧទាហរណ៍កូដការងារ នៅលើ GitHub .

វាក្យសព្ទកុងតឺន័រ

យើងនឹងចាប់ផ្តើមជាមួយនឹងពាក្យ container ដែលប្រើក្នុងអត្ថបទ៖

• រូបភាពកុងតឺន័រ៖ ឯកសារនៃទម្រង់ជាក់លាក់។ យើងនឹងបំប្លែងកម្មវិធីរបស់យើងទៅជារូបភាពកុងតឺន័រដោយដំណើរការឧបករណ៍សាងសង់។
• កុងតឺន័រ៖ ជាឧទាហរណ៍ដែលអាចប្រតិបត្តិបាននៃរូបភាពកុងតឺន័រ។
• ម៉ាស៊ីនកុងតឺន័រ៖ ដំណើរការដេមិនទទួលខុសត្រូវសម្រាប់ដំណើរការកុងតឺន័រ។
• ម្ចាស់ផ្ទះកុងតឺន័រ៖ កុំព្យូទ័រម៉ាស៊ីនដែលម៉ាស៊ីនកុងតឺន័រដំណើរការ។
• ការចុះបញ្ជីកុងតឺន័រ៖ ទីតាំងទូទៅដែលប្រើសម្រាប់បោះពុម្ព និងចែកចាយរូបភាពកុងតឺន័រ។
• ស្តង់ដារ OCI: គំនិតផ្តួចផ្តើមបើកកុងតឺន័រ (OCI) គឺ​ជា​រចនាសម្ព័ន្ធ​អភិបាលកិច្ច​បើកចំហរ​ស្រាល​ដែល​បង្កើត​ឡើង​ក្នុង​មូលនិធិ​លីនុច។ ការបញ្ជាក់រូបភាព OCI កំណត់ស្តង់ដារឧស្សាហកម្មសម្រាប់រូបភាពកុងតឺន័រ និងទម្រង់ពេលដំណើរការ ដើម្បីធានាថាម៉ាស៊ីនកុងតឺន័រទាំងអស់អាចដំណើរការរូបភាពកុងតឺន័រដែលបង្កើតឡើងដោយឧបករណ៍សាងសង់ណាមួយ។

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

កំណែ 2.3 នៃ Spring Boot ផ្តល់នូវកម្មវិធីជំនួយសម្រាប់បង្កើតរូបភាព OCI ។

Dockers គឺជាការអនុវត្តកុងតឺន័រដែលប្រើជាទូទៅបំផុត ហើយយើងប្រើ Docker ក្នុងឧទាហរណ៍របស់យើង ដូច្នេះរាល់ឯកសារយោងកុងតឺន័រជាបន្តបន្ទាប់នៅក្នុងអត្ថបទនេះនឹងសំដៅលើ Docker ។

ការកសាងរូបភាពកុងតឺន័រតាមវិធីប្រពៃណី

ការបង្កើតរូបភាព Docker សម្រាប់កម្មវិធី Spring Boot គឺងាយស្រួលណាស់ដោយបន្ថែមការណែនាំមួយចំនួនទៅឯកសារ Docker ។

ដំបូងយើងបង្កើតឯកសារ JAR ដែលអាចប្រតិបត្តិបាន ហើយជាផ្នែកមួយនៃការណែនាំឯកសារ Docker ចម្លងឯកសារ JAR ដែលអាចប្រតិបត្តិបាននៅលើកំពូលនៃរូបភាព JRE មូលដ្ឋានបន្ទាប់ពីអនុវត្តការកំណត់ចាំបាច់។

តោះបង្កើតកម្មវិធី Spring របស់យើងនៅលើ និទាឃរដូវ Initializr ជាមួយនឹងភាពអាស្រ័យ web, lombokи actuator. យើងក៏កំពុងបន្ថែមឧបករណ៍បញ្ជាសម្រាកដើម្បីផ្តល់ API ផងដែរ។ GETវិធីសាស្រ្ត។

ការបង្កើត Dockerfile

បន្ទាប់មកយើងផ្ទុកកម្មវិធីនេះដោយបន្ថែម Dockerfile:

FROM adoptopenjdk:11-jre-hotspot
ARG JAR_FILE=target/*.jar
COPY ${JAR_FILE} application.jar
EXPOSE 8080
ENTRYPOINT ["java","-jar","/application.jar"]

ឯកសារ Docker របស់យើងមានរូបភាពមូលដ្ឋានពី adoptopenjdkខាងលើដែលយើងចម្លងឯកសារ JAR របស់យើង ហើយបន្ទាប់មកបើកច្រក។ 8080ដែលនឹងស្តាប់ការស្នើសុំ។

ការកសាងកម្មវិធី

ដំបូងអ្នកត្រូវបង្កើតកម្មវិធីដោយប្រើ Maven ឬ Gradle ។ នៅទីនេះយើងប្រើ Maven:

mvn clean package

វាបង្កើតឯកសារ JAR ដែលអាចប្រតិបត្តិបានសម្រាប់កម្មវិធី។ យើងត្រូវបំប្លែង JAR ដែលអាចប្រតិបត្តិបាននេះទៅជារូបភាព Docker ដើម្បីដំណើរការលើម៉ាស៊ីន Docker ។

ការបង្កើតរូបភាពកុងតឺន័រ

បន្ទាប់មកយើងដាក់ឯកសារ JAR ដែលអាចប្រតិបត្តិបាននេះទៅក្នុងរូបភាព Docker ដោយដំណើរការពាក្យបញ្ជា docker buildពីថត root របស់គម្រោងដែលមាន Dockerfile ដែលបានបង្កើតមុននេះ៖

docker build  -t usersignup:v1 .

យើងអាចមើលឃើញរូបភាពរបស់យើងនៅក្នុងបញ្ជីដោយប្រើពាក្យបញ្ជា៖

docker images 

លទ្ធផលនៃពាក្យបញ្ជាខាងលើរួមបញ្ចូលរូបភាពរបស់យើង។ usersignupរួមជាមួយនឹងរូបភាពមូលដ្ឋាន, adoptopenjdkបានបញ្ជាក់នៅក្នុងឯកសារ Docker របស់យើង។

REPOSITORY          TAG                 SIZE
usersignup          v1                  249MB
adoptopenjdk        11-jre-hotspot      229MB

មើលស្រទាប់ខាងក្នុងរូបភាពធុង

តោះមើលជង់នៃស្រទាប់ខាងក្នុងរូបភាព។ យើងនឹងប្រើ ឧបករណ៍  មុជទឹក ដើម្បីមើលស្រទាប់ទាំងនេះ៖

dive usersignup:v1

នេះគឺជាផ្នែកនៃលទ្ធផលពីពាក្យបញ្ជា Dive៖ 

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

ការបង្កើតរូបភាពកុងតឺន័រដោយប្រើ Buildpack

កញ្ចប់ដំឡើង (កញ្ចប់សាងសង់) គឺជាពាក្យទូទៅដែលប្រើដោយ Platform as a Service (PAAS) ជាច្រើនដែលផ្តល់អោយដើម្បីបង្កើតរូបភាពកុងតឺន័រពីកូដប្រភព។ វាត្រូវបានចាប់ផ្តើមដោយ Heroku ក្នុងឆ្នាំ 2011 ហើយចាប់តាំងពីពេលនោះមកត្រូវបានអនុម័តដោយ Cloud Foundry, Google App Engine, Gitlab, Knative និងមួយចំនួនទៀត។

អត្ថប្រយោជន៍នៃកញ្ចប់បង្កើតពពក

អត្ថប្រយោជន៍សំខាន់មួយនៃការប្រើប្រាស់ Buildpack ដើម្បីបង្កើតរូបភាពគឺនោះ។ ការផ្លាស់ប្តូរការកំណត់រចនាសម្ព័ន្ធរូបភាពអាចត្រូវបានគ្រប់គ្រងកណ្តាល (អ្នកសាងសង់) និងផ្សព្វផ្សាយទៅគ្រប់កម្មវិធីដោយប្រើកម្មវិធីសាងសង់។

កញ្ចប់សាងសង់ត្រូវបានភ្ជាប់យ៉ាងតឹងរឹងទៅនឹងវេទិកា។ Cloud-Native Buildpacks ផ្តល់នូវស្តង់ដារលើវេទិកានានាដោយគាំទ្រទ្រង់ទ្រាយរូបភាព OCI ដែលធានាថារូបភាពអាចដំណើរការដោយម៉ាស៊ីន Docker ។

ដោយប្រើកម្មវិធីជំនួយ Spring Boot

កម្មវិធីជំនួយ Spring Boot បង្កើតរូបភាព OCI ពីប្រភពដោយប្រើ Buildpack ។ រូបភាពត្រូវបានបង្កើតដោយប្រើ bootBuildImageកិច្ចការ (Gradle) ឬ spring-boot:build-imageគោលដៅ (Maven) និងការដំឡើង Docker មូលដ្ឋាន។

យើង​អាច​ប្ដូរ​ឈ្មោះ​រូបភាព​តាម​បំណង​ដើម្បី​រុញ​ទៅ​បញ្ជីឈ្មោះ Docker ដោយ​បញ្ជាក់​ឈ្មោះ​ចូល image tag:

<plugin>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-maven-plugin</artifactId>
  <configuration>
    <image>
      <name>docker.io/pratikdas/${project.artifactId}:v1</name>
    </image>
  </configuration>
</plugin>

តោះប្រើ Maven ដើម្បីធ្វើវា។ build-imageគោលដៅសម្រាប់បង្កើតកម្មវិធី និងបង្កើតរូបភាពកុងតឺន័រ។ យើងមិនប្រើ Dockerfiles ណាមួយទេនៅពេលនេះ។

mvn spring-boot:build-image

លទ្ធផលនឹងមានដូចនេះ៖

[INFO] --- spring-boot-maven-plugin:2.3.3.RELEASE:build-image (default-cli) @ usersignup ---
[INFO] Building image 'docker.io/pratikdas/usersignup:v1'
[INFO] 
[INFO]  > Pulling builder image 'gcr.io/paketo-buildpacks/builder:base-platform-api-0.3' 0%
.
.
.. [creator]     Adding label 'org.springframework.boot.version'
.. [creator]     *** Images (c311fe74ec73):
.. [creator]           docker.io/pratikdas/usersignup:v1
[INFO] 
[INFO] Successfully built image 'docker.io/pratikdas/usersignup:v1'

ពីទិន្នផលយើងឃើញ paketo Cloud-Native buildpackប្រើដើម្បីបង្កើតរូបភាព OCI ដែលកំពុងដំណើរការ។ ដូចពីមុន យើងអាចឃើញរូបភាពដែលបានរាយជារូបភាព Docker ដោយដំណើរការពាក្យបញ្ជា៖

docker images 

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

REPOSITORY                             SIZE
paketobuildpacks/run                  84.3MB
gcr.io/paketo-buildpacks/builder      652MB
pratikdas/usersignup                  257MB

ការបង្កើតរូបភាពកុងតឺន័រដោយប្រើ Jib

Jib គឺជាកម្មវិធីជំនួយបង្កើតរូបភាពពី Google ដែលផ្តល់នូវវិធីសាស្ត្រជំនួសសម្រាប់ការបង្កើតរូបភាពកុងតឺន័រពីកូដប្រភព។

កំណត់រចនាសម្ព័ន្ធ jib-maven-pluginនៅក្នុង pom.xml:

      <plugin>
        <groupId>com.google.cloud.tools</groupId>
        <artifactId>jib-maven-plugin</artifactId>
        <version>2.5.2</version>
      </plugin>

បន្ទាប់មក យើងដំណើរការកម្មវិធីជំនួយ Jib ដោយប្រើពាក្យបញ្ជា Maven ដើម្បីបង្កើតកម្មវិធី និងបង្កើតរូបភាពកុងតឺន័រ។ ដូចពីមុន យើងមិនប្រើឯកសារ Docker ណាមួយនៅទីនេះទេ៖

mvn compile jib:build -Dimage=<docker registry name>/usersignup:v1

បន្ទាប់ពីប្រតិបត្តិពាក្យបញ្ជា Maven ខាងលើយើងទទួលបានលទ្ធផលដូចខាងក្រោម:

[INFO] Containerizing application to pratikdas/usersignup:v1...
.
.
[INFO] Container entrypoint set to [java, -cp, /app/resources:/app/classes:/app/libs/*, io.pratik.users.UsersignupApplication]
[INFO] 
[INFO] Built and pushed image as pratikdas/usersignup:v1
[INFO] Executing tasks:
[INFO] [==============================] 100.0% complete

លទ្ធផលបង្ហាញថារូបភាពកុងតឺន័រត្រូវបានបង្កើត និងដាក់ក្នុងបញ្ជីឈ្មោះ។

ការលើកទឹកចិត្ត និងបច្ចេកទេសសម្រាប់បង្កើតរូបភាពដែលបានកែលម្អ

យើងមានហេតុផលសំខាន់ពីរសម្រាប់ការបង្កើនប្រសិទ្ធភាព៖

• ផលិតភាព៖ នៅក្នុងប្រព័ន្ធកុងតឺន័រ Orchestration រូបភាពកុងតឺន័រត្រូវបានទាញយកពីបញ្ជីឈ្មោះរូបភាពទៅកាន់ម៉ាស៊ីនដែលកំពុងដំណើរការម៉ាស៊ីនកុងតឺន័រ។ ដំណើរការនេះត្រូវបានគេហៅថាការធ្វើផែនការ។ ការទាញរូបភាពធំ ៗ ពីបញ្ជីឈ្មោះនាំឱ្យពេលវេលាកំណត់ពេលវេលាយូរនៅក្នុងប្រព័ន្ធរៀបចំកុងតឺន័រ និងរយៈពេលសាងសង់យូរនៅក្នុងបំពង់ CI ។
• សន្តិសុខ៖ រូបភាពធំក៏មានផ្ទៃធំសម្រាប់ភាពងាយរងគ្រោះផងដែរ។

រូបភាព Docker មានជង់នៃស្រទាប់ ដែលនីមួយៗតំណាងឱ្យការណែនាំនៅក្នុង Dockerfile របស់យើង។ ស្រទាប់នីមួយៗតំណាងឱ្យ delta នៃការផ្លាស់ប្តូរនៅក្នុងស្រទាប់ខាងក្រោម។ នៅពេលដែលយើងទាញរូបភាព Docker ចេញពីបញ្ជីឈ្មោះ វាត្រូវបានទាញជាស្រទាប់ៗ ហើយដាក់ក្នុងឃ្លាំងសម្ងាត់នៅលើម៉ាស៊ីន។

Spring Boot ប្រើ "JAR ខ្លាញ់" នៅក្នុង ជាទម្រង់វេចខ្ចប់លំនាំដើម។ នៅពេលយើងក្រឡេកមើល JAR ក្រាស់ យើងឃើញថាកម្មវិធីបង្កើតបានជាផ្នែកតូចមួយនៃ JAR ទាំងមូល។ នេះគឺជាផ្នែកដែលផ្លាស់ប្តូរញឹកញាប់បំផុត។ អ្វីដែលនៅសេសសល់រួមមាន Spring Framework dependencies។

រូបមន្តបង្កើនប្រសិទ្ធភាពផ្តោតលើការញែកកម្មវិធីនៅកម្រិតដាច់ដោយឡែកពីភាពអាស្រ័យនៃ Spring Framework ។

ស្រទាប់ភាពអាស្រ័យ ដែលបង្កើតជាឯកសារ JAR ដ៏ក្រាស់ត្រូវបានទាញយកតែម្តងគត់ ហើយបានរក្សាទុកក្នុងឃ្លាំងសម្ងាត់នៅលើប្រព័ន្ធម៉ាស៊ីន។

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

នៅក្នុងផ្នែកខាងក្រោម យើងនឹងមើលពីរបៀបបង្កើតរូបភាពដែលបានកែលម្អទាំងនេះសម្រាប់កម្មវិធី Spring Boot។

ការបង្កើតរូបភាពកុងតឺន័រដែលប្រសើរឡើងសម្រាប់កម្មវិធី Spring Boot ដោយប្រើ Buildpack

Spring Boot 2.3 គាំទ្រការបញ្ឈប់ដោយការទាញយកផ្នែកនៃឯកសារ JAR ក្រាស់ទៅជាស្រទាប់ដាច់ដោយឡែក។ មុខងារស្រទាប់ត្រូវបានបិទតាមលំនាំដើម ហើយត្រូវតែបើកយ៉ាងច្បាស់លាស់ដោយប្រើកម្មវិធីជំនួយ Spring Boot Maven៖

<plugin>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-maven-plugin</artifactId>
  <configuration>
    <layers>
      <enabled>true</enabled>
    </layers>
  </configuration> 
</plugin>

យើងនឹងប្រើការកំណត់នេះដើម្បីបង្កើតរូបភាពកុងតឺន័ររបស់យើងជាមុនសិនជាមួយ Buildpack ហើយបន្ទាប់មកជាមួយ Docker នៅក្នុងផ្នែកខាងក្រោម។

តោះចាប់ផ្តើម build-imageគោលដៅ Maven សម្រាប់បង្កើតរូបភាពកុងតឺន័រ៖

mvn spring-boot:build-image

ប្រសិនបើយើងដំណើរការ Dive ដើម្បីមើលស្រទាប់ក្នុងរូបភាពលទ្ធផល យើងអាចឃើញថាស្រទាប់កម្មវិធី (គូសជាពណ៌ក្រហម) គឺតូចជាងនៅក្នុងជួរគីឡូបៃបើប្រៀបធៀបទៅនឹងអ្វីដែលយើងទទួលបានដោយប្រើទម្រង់ JAR ខ្លាញ់៖

ការបង្កើតរូបភាពកុងតឺន័រដែលប្រសើរឡើងសម្រាប់កម្មវិធី Spring Boot ដោយប្រើ Docker

ជំនួសឱ្យការប្រើកម្មវិធីជំនួយ Maven ឬ Gradle យើងក៏អាចបង្កើតរូបភាព Docker JAR ដែលមានស្រទាប់ជាមួយឯកសារ Docker ផងដែរ។

នៅពេលយើងប្រើ Docker យើងត្រូវអនុវត្តជំហានពីរបន្ថែមទៀតដើម្បីស្រង់ស្រទាប់ ហើយចម្លងពួកវាទៅក្នុងរូបភាពចុងក្រោយ។

ខ្លឹមសារនៃ JAR លទ្ធផលបន្ទាប់ពីសាងសង់ដោយប្រើ Maven ជាមួយនឹងការបើកស្រទាប់នឹងមើលទៅដូចនេះ៖

META-INF/
.
BOOT-INF/lib/
.
BOOT-INF/lib/spring-boot-jarmode-layertools-2.3.3.RELEASE.jar
BOOT-INF/classpath.idx
BOOT-INF/layers.idx

លទ្ធផលបង្ហាញ JAR បន្ថែមដែលមានឈ្មោះ spring-boot-jarmode-layertoolsи layersfle.idxឯកសារ។ ឯកសារ JAR បន្ថែមនេះផ្តល់នូវសមត្ថភាពដំណើរការជាស្រទាប់ ដូចដែលបានពិពណ៌នានៅក្នុងផ្នែកបន្ទាប់។

ការស្រង់ចេញអាស្រ័យទៅលើស្រទាប់នីមួយៗ

ដើម្បីមើល និងស្រង់ស្រទាប់ចេញពី JAR ដែលមានស្រទាប់របស់យើង យើងប្រើលក្ខណសម្បត្តិប្រព័ន្ធ -Djarmode=layertoolsសម្រាប់ការចាប់ផ្តើម spring-boot-jarmode-layertoolsJAR ជំនួសឱ្យកម្មវិធី៖

java -Djarmode=layertools -jar target/usersignup-0.0.1-SNAPSHOT.jar

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

Usage:
  java -Djarmode=layertools -jar usersignup-0.0.1-SNAPSHOT.jar

Available commands:
  list     List layers from the jar that can be extracted
  extract  Extracts layers from the jar for image creation
  help     Help about any command

លទ្ធផលបង្ហាញពាក្យបញ្ជា list, extractи helpс helpជាលំនាំដើម។ តោះដំណើរការពាក្យបញ្ជាជាមួយ listជម្រើស៖

java -Djarmode=layertools -jar target/usersignup-0.0.1-SNAPSHOT.jar list

dependencies
spring-boot-loader
snapshot-dependencies
application

យើងឃើញបញ្ជីនៃភាពអាស្រ័យដែលអាចត្រូវបានបន្ថែមជាស្រទាប់។

ស្រទាប់លំនាំដើម៖

ឈ្មោះស្រទាប់

មាតិកា

dependencies

ភាពអាស្រ័យណាមួយដែលកំណែមិនមាន SNAPSHOT

spring-boot-loader

ថ្នាក់ផ្ទុក JAR

snapshot-dependencies

ភាពអាស្រ័យណាមួយដែលកំណែរបស់វាមាន SNAPSHOT

application

ថ្នាក់កម្មវិធី និងធនធាន

ស្រទាប់ត្រូវបានកំណត់នៅក្នុង layers.idxឯកសារតាមលំដាប់ដែលពួកគេគួរតែត្រូវបានបន្ថែមទៅរូបភាព Docker ។ ស្រទាប់ទាំងនេះត្រូវបានទុកក្នុងឃ្លាំងសម្ងាត់បន្ទាប់ពីការទាញយកលើកដំបូងព្រោះវាមិនផ្លាស់ប្តូរ មានតែស្រទាប់កម្មវិធីដែលបានអាប់ដេតប៉ុណ្ណោះដែលត្រូវបានទាញយកទៅកាន់ម៉ាស៊ីន ដែលលឿនជាងមុនដោយសារទំហំកាត់បន្ថយ .

ការ​បង្កើត​រូបភាព​ដោយ​មាន​ភាព​អាស្រ័យ​បាន​ស្រង់​ចេញ​ជា​ស្រទាប់​ដាច់​ដោយ​ឡែក

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

តោះកែប្រែ Dockerfile របស់យើងសម្រាប់ការស្ថាបនាពហុដំណាក់កាល៖

# the first stage of our build will extract the layers
FROM adoptopenjdk:14-jre-hotspot as builder
WORKDIR application
ARG JAR_FILE=target/*.jar
COPY ${JAR_FILE} application.jar
RUN java -Djarmode=layertools -jar application.jar extract

# the second stage of our build will copy the extracted layers
FROM adoptopenjdk:14-jre-hotspot
WORKDIR application
COPY --from=builder application/dependencies/ ./
COPY --from=builder application/spring-boot-loader/ ./
COPY --from=builder application/snapshot-dependencies/ ./
COPY --from=builder application/application/ ./
ENTRYPOINT ["java", "org.springframework.boot.loader.JarLauncher"]

យើងរក្សាទុកការកំណត់រចនាសម្ព័ន្ធនេះនៅក្នុងឯកសារដាច់ដោយឡែកមួយ - Dockerfile2.

យើងបង្កើតរូបភាព Docker ដោយប្រើពាក្យបញ្ជា៖

docker build -f Dockerfile2 -t usersignup:v1 .

បន្ទាប់ពីដំណើរការពាក្យបញ្ជានេះយើងទទួលបានលទ្ធផលដូចខាងក្រោម:

Sending build context to Docker daemon  20.41MB
Step 1/12 : FROM adoptopenjdk:14-jre-hotspot as builder
14-jre-hotspot: Pulling from library/adoptopenjdk
.
.
Successfully built a9ebf6970841
Successfully tagged userssignup:v1

យើងអាចមើលឃើញថារូបភាព Docker ត្រូវបានបង្កើតដោយ ID រូបភាព ហើយបន្ទាប់មកដាក់ស្លាក។

ជាចុងក្រោយ យើងដំណើរការពាក្យបញ្ជា Dive ដូចពីមុន ដើម្បីពិនិត្យមើលស្រទាប់ខាងក្នុងរូបភាព Docker ដែលបានបង្កើត។ យើងអាចផ្តល់លេខសម្គាល់រូបភាព ឬស្លាកជាការបញ្ចូលទៅក្នុងពាក្យបញ្ជា Dive៖

dive userssignup:v1

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

ទាញយកភាពអាស្រ័យខាងក្នុងលើស្រទាប់នីមួយៗ

យើងអាចកាត់បន្ថយទំហំនៃកម្រិតកម្មវិធីបន្ថែមទៀត ដោយទាញយកភាពអាស្រ័យផ្ទាល់ខ្លួនណាមួយរបស់យើងទៅជាថ្នាក់ដាច់ដោយឡែកជំនួសឱ្យការវេចខ្ចប់ពួកវាជាមួយកម្មវិធីដោយប្រកាសពួកវានៅក្នុង ymlឯកសារស្រដៀងគ្នាដែលមានឈ្មោះ layers.idx:

- "dependencies":
  - "BOOT-INF/lib/"
- "spring-boot-loader":
  - "org/"
- "snapshot-dependencies":
- "custom-dependencies":
  - "io/myorg/"
- "application":
  - "BOOT-INF/classes/"
  - "BOOT-INF/classpath.idx"
  - "BOOT-INF/layers.idx"
  - "META-INF/"

នៅក្នុងឯកសារនេះ។ layers.idxយើងបានបន្ថែមភាពអាស្រ័យផ្ទាល់ខ្លួនដែលមានឈ្មោះ io.myorgផ្ទុកនូវភាពអាស្រ័យរបស់អង្គការដែលបានទាញយកពីឃ្លាំងរួម។

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

នៅក្នុងអត្ថបទនេះ យើងបានពិនិត្យមើលការប្រើប្រាស់ Cloud-Native Buildpacks ដើម្បីបង្កើតរូបភាពកុងតឺន័រដោយផ្ទាល់ពីកូដប្រភព។ នេះគឺជាជម្រើសមួយសម្រាប់ការប្រើប្រាស់ Docker ដើម្បីបង្កើតរូបភាពកុងតឺន័រតាមរបៀបធម្មតា៖ ដំបូងបង្កើតឯកសារ JAR ដែលអាចប្រតិបត្តិបានក្រាស់ ហើយបន្ទាប់មកវេចខ្ចប់វាទៅក្នុងរូបភាពកុងតឺន័រដោយបញ្ជាក់ការណែនាំនៅក្នុងឯកសារ Docker ។

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

អ្នកអាចស្វែងរកកូដប្រភពទាំងអស់ដែលបានប្រើនៅក្នុងអត្ថបទនៅ Github .

សេចក្តីយោងពាក្យបញ្ជា

នេះជាការសង្ខេបខ្លីៗនៃពាក្យបញ្ជាដែលយើងបានប្រើក្នុងអត្ថបទនេះ។

ការសម្អាតបរិបទ៖

docker system prune -a

ការបង្កើតរូបភាពកុងតឺន័រដោយប្រើឯកសារ Docker៖

docker build -f <Docker file name> -t <tag> .

យើងបង្កើតរូបភាពកុងតឺន័រពីកូដប្រភព (ដោយគ្មាន Dockerfile)៖

mvn spring-boot:build-image

មើលស្រទាប់អាស្រ័យ។ មុនពេលបង្កើតឯកសារ JAR កម្មវិធី សូមប្រាកដថាមុខងារស្រទាប់ត្រូវបានបើកនៅក្នុង spring-boot-maven-plugin៖

java -Djarmode=layertools -jar application.jar list

ការស្រង់ចេញស្រទាប់អាស្រ័យ។ មុនពេលបង្កើតឯកសារ JAR កម្មវិធី សូមប្រាកដថាមុខងារស្រទាប់ត្រូវបានបើកនៅក្នុង spring-boot-maven-plugin៖

 java -Djarmode=layertools -jar application.jar extract

មើលបញ្ជីរូបភាពធុង

docker images

មើលនៅខាងឆ្វេងក្នុងរូបភាពកុងតឺន័រ (ត្រូវប្រាកដថាឧបករណ៍មុជទឹកត្រូវបានដំឡើង)៖

dive <image ID or image tag>

ប្រភព: www.habr.com