ການສ້າງຮູບພາບ Docker ທີ່ດີທີ່ສຸດສໍາລັບຄໍາຮ້ອງສະຫມັກ Spring Boot

ຕູ້ຄອນເທນເນີໄດ້ກາຍເປັນວິທີການທີ່ມັກຂອງການຫຸ້ມຫໍ່ຄໍາຮ້ອງສະຫມັກທີ່ມີຊອບແວແລະລະບົບປະຕິບັດການທັງຫມົດຂອງຕົນ, ແລະຫຼັງຈາກນັ້ນສົ່ງໃຫ້ເຂົາເຈົ້າກັບສະພາບແວດລ້ອມທີ່ແຕກຕ່າງກັນ.

ບົດຄວາມນີ້ກວມເອົາວິທີການຕ່າງໆໃນການບັນຈຸຄໍາຮ້ອງສະຫມັກ Spring Boot:

• ການສ້າງຮູບພາບ Docker ໂດຍໃຊ້ໄຟລ໌ Docker,
• ການສ້າງຮູບພາບ OCI ຈາກແຫຼ່ງໂດຍໃຊ້ Cloud-Native Buildpack,
• ແລະການເພີ່ມປະສິດທິພາບຮູບພາບໃນເວລາແລ່ນໂດຍການແຍກສ່ວນຕ່າງໆຂອງ JAR ອອກເປັນຊັ້ນຕ່າງໆໂດຍໃຊ້ເຄື່ອງມືຫຼາຍຊັ້ນ.

 ຕົວຢ່າງລະຫັດ

ບົດຄວາມນີ້ແມ່ນມາພ້ອມກັບຕົວຢ່າງລະຫັດການເຮັດວຽກ ໃນ GitHub .

ຄຳສັບກ່ຽວກັບຕູ້ຄອນເທນເນີ

ພວກເຮົາຈະເລີ່ມຕົ້ນດ້ວຍຄໍາສັບບັນຈຸທີ່ໃຊ້ໃນບົດຄວາມ:

• ຮູບພາບຕູ້ຄອນເທນເນີ: ໄຟລ໌ຂອງຮູບແບບສະເພາະ. ພວກເຮົາຈະປ່ຽນແອັບພລິເຄຊັນຂອງພວກເຮົາເປັນຮູບບັນຈຸໂດຍການແລ່ນເຄື່ອງມືສ້າງ.
• Container: ຕົວຢ່າງທີ່ປະຕິບັດໄດ້ຂອງຮູບບັນຈຸ.
• ເຄື່ອງຈັກບັນຈຸ: ຂະບວນການ daemon ທີ່ຮັບຜິດຊອບສໍາລັບການແລ່ນບັນຈຸ.
• ເຈົ້າພາບຕູ້ຄອນເທນເນີ: ຄອມພິວເຕີໂຮສທີ່ເຄື່ອງຈັກບັນຈຸບັນຈຸແລ່ນ.
• ທະບຽນຕູ້ຄອນເທນເນີ: ສະຖານທີ່ທົ່ວໄປທີ່ໃຊ້ເພື່ອເຜີຍແຜ່ ແລະແຈກຢາຍຮູບພາບບັນຈຸ.
• ມາດຕະຖານ OCI: Open Container Initiative (OCI) ແມ່ນໂຄງສ້າງການປົກຄອງແບບເປີດທີ່ມີນ້ຳໜັກເບົາທີ່ສ້າງຂຶ້ນພາຍໃນມູນນິທິ Linux. OCI Image Specification ກໍານົດມາດຕະຖານອຸດສາຫະກໍາສໍາລັບຮູບພາບ container ແລະຮູບແບບ runtime ເພື່ອຮັບປະກັນວ່າເຄື່ອງຈັກ container ທັງຫມົດສາມາດດໍາເນີນການຮູບພາບ container ທີ່ສ້າງໂດຍເຄື່ອງມືການກໍ່ສ້າງໃດໆ.

ເພື່ອບັນຈຸແອັບພລິເຄຊັນ, ພວກເຮົາຫໍ່ແອັບພລິເຄຊັນຂອງພວກເຮົາໃນຮູບບັນຈຸແລະເຜີຍແຜ່ຮູບພາບນັ້ນໄປຫາທະບຽນທີ່ແບ່ງປັນ. ຊ່ວງເວລາບັນຈຸບັນຈຸເອົາຮູບພາບນີ້ມາຈາກລີຈິດຊີ, ຖອດມັນອອກ, ແລະແລ່ນແອັບພລິເຄຊັນພາຍໃນມັນ.

ເວີຊັນ 2.3 ຂອງ Spring Boot ສະໜອງປລັກອິນເພື່ອສ້າງຮູບພາບ OCI.

Docker ແມ່ນການປະຕິບັດພາຊະນະທີ່ໃຊ້ທົ່ວໄປທີ່ສຸດ, ແລະພວກເຮົາໃຊ້ Docker ໃນຕົວຢ່າງຂອງພວກເຮົາ, ດັ່ງນັ້ນການອ້າງອິງ container ຕໍ່ໄປທັງຫມົດໃນບົດຄວາມນີ້ຈະຫມາຍເຖິງ Docker.

ການສ້າງຮູບພາບຕູ້ຄອນເທນເນີຕາມແບບດັ້ງເດີມ

ການສ້າງຮູບພາບ Docker ສໍາລັບຄໍາຮ້ອງສະຫມັກ Spring Boot ແມ່ນງ່າຍຫຼາຍໂດຍການເພີ່ມຄໍາແນະນໍາຈໍານວນຫນ້ອຍໃສ່ໄຟລ໌ Docker.

ພວກເຮົາທໍາອິດສ້າງໄຟລ໌ JAR ທີ່ສາມາດປະຕິບັດໄດ້ແລະ, ເປັນສ່ວນຫນຶ່ງຂອງຄໍາແນະນໍາຂອງໄຟລ໌ Docker, ຄັດລອກໄຟລ໌ JAR ທີ່ສາມາດປະຕິບັດໄດ້ຢູ່ເທິງສຸດຂອງຮູບພາບ JRE ພື້ນຖານຫຼັງຈາກນໍາໃຊ້ການຕັ້ງຄ່າທີ່ຈໍາເປັນ.

ໃຫ້ສ້າງຄໍາຮ້ອງສະຫມັກພາກຮຽນ spring ຂອງພວກເຮົາກ່ຽວກັບ 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ຈາກໄດເລກະທໍລີຮາກໂຄງການທີ່ມີ Dockerfile ທີ່ສ້າງຂຶ້ນກ່ອນຫນ້ານີ້:

docker build  -t usersignup:v1 .

ພວກເຮົາສາມາດເບິ່ງຮູບພາບຂອງພວກເຮົາໃນບັນຊີລາຍຊື່ໂດຍໃຊ້ຄໍາສັ່ງ:

docker images 

ຜົນຜະລິດຂອງຄໍາສັ່ງຂ້າງເທິງນີ້ປະກອບມີຮູບພາບຂອງພວກເຮົາ usersignupພ້ອມ​ກັບ​ຮູບ​ພາບ​ພື້ນ​ຖານ​, adoptopenjdkລະບຸໄວ້ໃນໄຟລ໌ Docker ຂອງພວກເຮົາ.

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

ເບິ່ງຊັ້ນຂໍ້ມູນພາຍໃນຮູບບັນຈຸ

ໃຫ້ເບິ່ງຢູ່ໃນ stack ຂອງຊັ້ນໃນຮູບ. ພວກເຮົາຈະນໍາໃຊ້ ເຄື່ອງມື  ດຳນ້ຳ ເພື່ອເບິ່ງຊັ້ນຂໍ້ມູນເຫຼົ່ານີ້:

dive usersignup:v1

ນີ້ແມ່ນສ່ວນຫນຶ່ງຂອງຜົນຜະລິດຈາກຄໍາສັ່ງ Dive: 

ດັ່ງທີ່ພວກເຮົາສາມາດເຫັນໄດ້, ຊັ້ນຄໍາຮ້ອງສະຫມັກເຮັດໃຫ້ເຖິງສ່ວນທີ່ສໍາຄັນຂອງຂະຫນາດຮູບພາບ. ພວກເຮົາຕ້ອງການຫຼຸດຜ່ອນຂະຫນາດຂອງຊັ້ນນີ້ໃນສ່ວນຕໍ່ໄປນີ້ເປັນສ່ວນຫນຶ່ງຂອງການເພີ່ມປະສິດທິພາບຂອງພວກເຮົາ.

ການສ້າງຮູບພາບບັນຈຸໂດຍໃຊ້ Buildpack

ຊຸດປະກອບ (Buildpacks) ເປັນຄໍາສັບທົ່ວໄປທີ່ໃຊ້ໂດຍ Platform as a Service (PAAS) ຕ່າງໆທີ່ສະເຫນີເພື່ອສ້າງຮູບພາບ container ຈາກລະຫັດແຫຼ່ງ. ມັນໄດ້ຖືກເປີດຕົວໂດຍ Heroku ໃນປີ 2011 ແລະໄດ້ຮັບການຮັບຮອງເອົາໂດຍ Cloud Foundry, Google App Engine, Gitlab, Knative ແລະອື່ນໆຈໍານວນຫຼາຍ.

ປະໂຫຍດຂອງການຫຸ້ມຫໍ່ cloud build

ຫນຶ່ງໃນຜົນປະໂຫຍດຕົ້ນຕໍຂອງການນໍາໃຊ້ Buildpack ເພື່ອສ້າງຮູບພາບແມ່ນວ່າ ການ​ປ່ຽນ​ແປງ​ການ​ຕັ້ງ​ຄ່າ​ຮູບ​ພາບ​ສາ​ມາດ​ໄດ້​ຮັບ​ການ​ຄຸ້ມ​ຄອງ​ສູນ​ກາງ (ຜູ້​ສ້າງ​) ແລະ​ແຜ່​ຂະ​ຫຍາຍ​ໄປ​ທຸກ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ໂດຍ​ການ​ນໍາ​ໃຊ້ builder​.

ການຫຸ້ມຫໍ່ການກໍ່ສ້າງໄດ້ຖືກສົມທົບຢ່າງແຫນ້ນຫນາກັບເວທີ. Cloud-Native Buildpacks ສະຫນອງມາດຕະຖານໃນທົ່ວແພລະຕະຟອມໂດຍສະຫນັບສະຫນູນຮູບແບບຮູບພາບ OCI, ເຊິ່ງຮັບປະກັນວ່າຮູບພາບສາມາດດໍາເນີນການໂດຍເຄື່ອງຈັກ Docker.

ການນໍາໃຊ້ plugin Spring Boot

plugin 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 ເປັນ plugin ສ້າງຮູບພາບຈາກ 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 plugin ໂດຍໃຊ້ຄໍາສັ່ງ 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.

ສູດການເພີ່ມປະສິດທິພາບແມ່ນຈຸດສູນກາງກ່ຽວກັບການໂດດດ່ຽວແອັບພລິເຄຊັນໃນລະດັບທີ່ແຍກຕ່າງຫາກຈາກ Spring Framework dependencies.

ຊັ້ນການເພິ່ງພາອາໄສ, ເຊິ່ງປະກອບເປັນສ່ວນໃຫຍ່ຂອງໄຟລ໌ JAR ທີ່ຫນາ, ຖືກດາວໂຫຼດພຽງແຕ່ຄັ້ງດຽວແລະຖືກເກັບໄວ້ໃນລະບົບໂຮດ.

ພຽງແຕ່ບາງຊັ້ນຂອງແອັບພລິເຄຊັນຖືກດຶງໃນລະຫວ່າງການອັບເດດແອັບພລິເຄຊັນ ແລະການຈັດຕາຕະລາງບັນຈຸ. ດັ່ງທີ່ສະແດງຢູ່ໃນແຜນວາດນີ້:

ໃນພາກຕໍ່ໄປນີ້, ພວກເຮົາຈະເບິ່ງວິທີການສ້າງຮູບພາບທີ່ດີທີ່ສຸດເຫຼົ່ານີ້ສໍາລັບຄໍາຮ້ອງສະຫມັກ Spring Boot.

ການສ້າງຮູບພາບຕູ້ຄອນເທນເນີທີ່ດີທີ່ສຸດສໍາລັບຄໍາຮ້ອງສະຫມັກ Spring Boot ໂດຍໃຊ້ Buildpack

Spring Boot 2.3 ສະຫນັບສະຫນູນການຈັດຊັ້ນໂດຍການສະກັດເອົາພາກສ່ວນຂອງໄຟລ໌ JAR ຫນາເຂົ້າໄປໃນຊັ້ນແຍກຕ່າງຫາກ. ຄຸນສົມບັດການຈັດຊັ້ນແມ່ນຖືກປິດໃຊ້ງານໂດຍຄ່າເລີ່ມຕົ້ນ ແລະຕ້ອງຖືກເປີດໃຊ້ຢ່າງຈະແຈ້ງໂດຍໃຊ້ plugin 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 plugin, ພວກເຮົາຍັງສາມາດສ້າງຮູບພາບ 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 ທີ່ສາມາດເພີ່ມເປັນຊັ້ນ.

ຊັ້ນຂໍ້ມູນເລີ່ມຕົ້ນ:

ຊື່ຊັ້ນ

ເນື້ອໃນ

dependencies

ການເພິ່ງພາອາໄສໃດໆກໍຕາມທີ່ສະບັບບໍ່ມີ SNAPSHOT

spring-boot-loader

ຫ້ອງຮຽນ JAR Loader

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 ຮູບພາບແລະຫຼັງຈາກນັ້ນຖືກ tagged.

ສຸດທ້າຍ, ພວກເຮົາດໍາເນີນການຄໍາສັ່ງ Dive ຄືເກົ່າເພື່ອກວດກາຊັ້ນຕ່າງໆພາຍໃນຮູບພາບ Docker ທີ່ສ້າງຂຶ້ນ. ພວກ​ເຮົາ​ສາ​ມາດ​ສະ​ຫນອງ ID ຮູບ​ພາບ​ຫຼື​ໂຄດ​ຄໍາ​ສັ່ງ​ເປັນ​ການ​ປ້ອນ​ຂໍ້​ມູນ​ກັບ​ຄໍາ​ສັ່ງ 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