સ્પ્રિંગ બૂટ એપ્લિકેશન માટે ઑપ્ટિમાઇઝ ડોકર છબીઓ બનાવવી

કન્ટેનર એ એપ્લિકેશનને તેના તમામ સોફ્ટવેર અને ઓપરેટિંગ સિસ્ટમની અવલંબન સાથે પેકેજ કરવા અને પછી તેને વિવિધ વાતાવરણમાં પહોંચાડવાનું પસંદીદા માધ્યમ બની ગયું છે.

આ લેખ સ્પ્રિંગ બૂટ એપ્લિકેશનને કન્ટેનરાઇઝ કરવાની વિવિધ રીતોને આવરી લે છે:

• ડોકરફાઈલનો ઉપયોગ કરીને ડોકર ઈમેજ બનાવવી,
• ક્લાઉડ-નેટિવ બિલ્ડપેકનો ઉપયોગ કરીને સ્ત્રોતમાંથી OCI ઇમેજ બનાવવી,
• અને મલ્ટિ-ટાયર ટૂલ્સનો ઉપયોગ કરીને JAR ના ભાગોને વિવિધ સ્તરોમાં અલગ કરીને રન-ટાઇમ ઇમેજ ઑપ્ટિમાઇઝેશન.

 કોડ ઉદાહરણ

આ લેખ વર્કિંગ કોડ ઉદાહરણ સાથે છે GitHub પર .

કન્ટેનર પરિભાષા

અમે સમગ્ર લેખમાં ઉપયોગમાં લેવાતી કન્ટેનર પરિભાષા સાથે પ્રારંભ કરીશું:

• કન્ટેનર છબી: ચોક્કસ ફોર્મેટની ફાઇલ. અમે બિલ્ડ ટૂલ ચલાવીને અમારી એપ્લિકેશનને કન્ટેનર ઈમેજમાં કન્વર્ટ કરીએ છીએ.
• કન્ટેનર: કન્ટેનર ઇમેજનું એક્ઝિક્યુટેબલ ઉદાહરણ.
• કન્ટેનર એન્જિન: કન્ટેનર ચલાવવા માટે જવાબદાર ડિમન પ્રક્રિયા.
• કન્ટેનર હોસ્ટ: હોસ્ટ મશીન કે જેના પર કન્ટેનર એન્જિન ચાલી રહ્યું છે.
• કન્ટેનર રજિસ્ટ્રી: કન્ટેનર ઇમેજને પ્રકાશિત કરવા અને વિતરિત કરવા માટે વપરાતું સામાન્ય સ્થાન.
• OCI ધોરણ: ઓપન કન્ટેનર પહેલ (OCI) લિનક્સ ફાઉન્ડેશન દ્વારા રચાયેલ હલકો, ઓપન સોર્સ મેનેજમેન્ટ ફ્રેમવર્ક છે. OCI ઇમેજ સ્પેસિફિકેશન કન્ટેનર ઇમેજ ફોર્મેટ્સ અને રનટાઇમ માટે ઉદ્યોગના ધોરણોને વ્યાખ્યાયિત કરે છે તેની ખાતરી કરવા માટે કે તમામ કન્ટેનર એન્જિન કોઈપણ બિલ્ડ ટૂલ દ્વારા બનાવેલી કન્ટેનર ઇમેજ ચલાવી શકે છે.

એપ્લિકેશનને કન્ટેનરાઇઝ કરવા માટે, અમે અમારી એપ્લિકેશનને કન્ટેનર ઇમેજમાં લપેટીએ છીએ અને તે છબીને સાર્વજનિક રજિસ્ટ્રીમાં પ્રકાશિત કરીએ છીએ. કન્ટેનર રનટાઇમ આ છબીને રજિસ્ટ્રીમાંથી પુનઃપ્રાપ્ત કરે છે, તેને અનપેક કરે છે અને તેની અંદર એપ્લિકેશન ચલાવે છે.

સ્પ્રિંગ બૂટનું વર્ઝન 2.3 OCI ઇમેજ બનાવવા માટે પ્લગઇન્સ પ્રદાન કરે છે.

Docker સૌથી સામાન્ય રીતે ઉપયોગમાં લેવાતા કન્ટેનર અમલીકરણ છે, અને અમે અમારા ઉદાહરણોમાં ડોકરનો ઉપયોગ કરીએ છીએ, તેથી આ લેખમાંના તમામ અનુગામી કન્ટેનર સંદર્ભો ડોકરનો સંદર્ભ લેશે.

પરંપરાગત રીતે કન્ટેનરની છબી બનાવવી

સ્પ્રિંગ બૂટ એપ્લીકેશન માટે ડોકર ઈમેજીસ બનાવવી એ ડોકર ફાઈલમાં થોડી સૂચનાઓ ઉમેરીને ખૂબ જ સરળ છે.

અમે સૌપ્રથમ એક્ઝિક્યુટેબલ JAR બનાવીએ છીએ અને, Dockerfile સૂચનાઓના ભાગ રૂપે, જરૂરી કસ્ટમાઇઝેશન લાગુ કર્યા પછી બેઝ JRE ઇમેજની ટોચ પર એક્ઝિક્યુટેબલ JARની કૉપિ કરીએ છીએ.

ચાલો અમારી સ્પ્રિંગ એપ્લિકેશન બનાવીએ વસંત પ્રારંભિક નિર્ભરતા સાથે web, lombokи actuator. અમે એક API પ્રદાન કરવા માટે આરામ નિયંત્રક પણ ઉમેરીએ છીએ GETપદ્ધતિ

ડોકરફાઇલ બનાવી રહ્યા છીએ

પછી અમે આ એપ્લિકેશન ઉમેરીને કન્ટેનરમાં મૂકીએ છીએ Dockerfile:

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

અમારી ડોકરફાઈલમાં બેઝ ઈમેજ છે adoptopenjdk, જેની ઉપર આપણે આપણી JAR ફાઈલ કોપી કરીએ છીએ અને પછી પોર્ટ ખોલીએ છીએ, 8080જે વિનંતીઓ સાંભળશે.

એપ્લિકેશન એસેમ્બલી

પ્રથમ તમારે માવેન અથવા ગ્રેડલનો ઉપયોગ કરીને એપ્લિકેશન બનાવવાની જરૂર છે. અહીં આપણે માવેનનો ઉપયોગ કરી રહ્યા છીએ:

mvn clean package

આ એપ્લિકેશન માટે એક્ઝિક્યુટેબલ JAR ફાઇલ બનાવે છે. ડોકર એન્જિન પર ચાલવા માટે આપણે આ એક્ઝેક્યુટેબલ JAR ને ડોકર ઈમેજમાં કન્વર્ટ કરવાની જરૂર છે.

કન્ટેનર છબી બનાવી રહ્યા છીએ

અમે પછી આદેશ ચલાવીને આ JAR એક્ઝેક્યુટેબલને ડોકર ઈમેજમાં મૂકીએ છીએ docker buildઅગાઉ બનાવેલ ડોકરફાઇલ ધરાવતી પ્રોજેક્ટની રૂટ ડિરેક્ટરીમાંથી:

docker build  -t usersignup:v1 .

અમે આદેશ સાથે સૂચિમાં અમારી છબી જોઈ શકીએ છીએ:

docker images 

ઉપરોક્ત આદેશના આઉટપુટમાં અમારી છબી શામેલ છે usersignupઆધાર છબી સાથે, adoptopenjdkઅમારી ડોકરફાઇલમાં ઉલ્લેખિત છે.

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

કન્ટેનર ઇમેજની અંદરના સ્તરો જુઓ

ચાલો ઈમેજની અંદરના સ્તરોના સ્ટેકને જોઈએ. અમે ઉપયોગ કરીશું સાધન  ડાઇવ આ સ્તરો જોવા માટે:

dive usersignup:v1

અહીં ડાઇવ આદેશમાંથી આઉટપુટનો ભાગ છે: 

જેમ આપણે જોઈ શકીએ છીએ, એપ્લિકેશન સ્તર છબીના કદનો નોંધપાત્ર ભાગ બનાવે છે. અમે અમારા ઓપ્ટિમાઇઝેશનના ભાગ રૂપે નીચેના વિભાગોમાં આ સ્તરનું કદ ઘટાડવા માંગીએ છીએ.

બિલ્ડપેકનો ઉપયોગ કરીને કન્ટેનરની છબી બનાવવી

એસેમ્બલી પેકેજો (બિલ્ડપેક્સ) એ એક સામાન્ય શબ્દ છે જેનો ઉપયોગ વિવિધ પ્લેટફોર્મ દ્વારા સેવા (PAAS) ઓફરિંગ તરીકે સોર્સ કોડમાંથી કન્ટેનર ઇમેજ બનાવવા માટે થાય છે. તે 2011 માં Heroku દ્વારા લોન્ચ કરવામાં આવ્યું હતું અને ત્યારથી તેને ક્લાઉડ ફાઉન્ડ્રી, Google App Engine, Gitlab, Knative અને અન્ય ઘણા લોકો દ્વારા અપનાવવામાં આવ્યું છે.

ક્લાઉડ બિલ્ડ પેકેજીસનો ફાયદો

છબીઓ બનાવવા માટે બિલ્ડપેકનો ઉપયોગ કરવાનો મુખ્ય ફાયદો એ છે કે ઇમેજ રૂપરેખાંકન ફેરફારો કેન્દ્રિય રીતે મેનેજ કરી શકાય છે (બિલ્ડર) અને બિલ્ડરનો ઉપયોગ કરીને તમામ એપ્લિકેશનો પર પ્રચાર કરી શકાય છે.

બિલ્ડ પેકેજો પ્લેટફોર્મ સાથે નજીકથી જોડાયેલા હતા. ક્લાઉડ-નેટિવ બિલ્ડપેક્સ OCI ઇમેજ ફોર્મેટને સપોર્ટ કરીને સમગ્ર પ્લેટફોર્મ પર માનકીકરણ પ્રદાન કરે છે, જે ખાતરી કરે છે કે છબી ડોકર એન્જિન દ્વારા ચલાવી શકાય છે.

સ્પ્રિંગ બૂટ પ્લગઇનનો ઉપયોગ કરવો

સ્પ્રિંગ બૂટ પ્લગઇન બિલ્ડપેકનો ઉપયોગ કરીને સ્ત્રોતમાંથી OCI છબીઓ બનાવે છે. ની મદદથી છબીઓ બનાવવામાં આવે છે bootBuildImageકાર્યો (ગ્રેડલ) અથવા spring-boot:build-imageલક્ષ્ય (માવેન) અને સ્થાનિક ડોકર ઇન્સ્ટોલેશન.

અમે નામનો ઉલ્લેખ કરીને ડોકર રજિસ્ટ્રીમાં દબાણ કરવા માટે જરૂરી ઇમેજનું નામ કસ્ટમાઇઝ કરી શકીએ છીએ. 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>

ચાલો એક્ઝેક્યુટ કરવા માવેનનો ઉપયોગ કરીએ build-imageએપ્લિકેશન બનાવવા અને કન્ટેનર ઇમેજ બનાવવાના લક્ષ્યો. અમે હાલમાં કોઈપણ ડોકરફાઈલ્સનો ઉપયોગ કરી રહ્યાં નથી.

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 images 

ઉપસંહાર:

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

Jib સાથે કન્ટેનર છબી બનાવવી

Jib એ Google તરફથી ઇમેજ ઓથરિંગ પ્લગઇન છે જે સ્ત્રોતમાંથી કન્ટેનર ઇમેજ બનાવવાની વૈકલ્પિક પદ્ધતિ પ્રદાન કરે છે.

કસ્ટમાઇઝ કરો jib-maven-pluginpom.xml માં:

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

આગળ, અમે એપ્લિકેશન બનાવવા અને કન્ટેનર ઇમેજ બનાવવા માટે Maven આદેશનો ઉપયોગ કરીને Jib પ્લગઇન ચલાવીએ છીએ. પહેલાની જેમ, અમે અહીં કોઈપણ ડોકરફાઈલ્સનો ઉપયોગ કરી રહ્યા નથી:

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

ઉપરોક્ત મેવન આદેશ ચલાવ્યા પછી, અમને નીચેનું આઉટપુટ મળે છે:

[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

આઉટપુટ દર્શાવે છે કે કન્ટેનર ઇમેજ બનાવવામાં આવી છે અને રજિસ્ટ્રીમાં મૂકવામાં આવી છે.

ઑપ્ટિમાઇઝ છબીઓ બનાવવા માટેની પ્રેરણા અને પદ્ધતિઓ

ઑપ્ટિમાઇઝ કરવા માટે અમારી પાસે બે મુખ્ય કારણો છે:

• ઉત્પાદકતા: કન્ટેનર ઓર્કેસ્ટ્રેશન સિસ્ટમમાં, કન્ટેનર ઇમેજને ઇમેજ રજિસ્ટ્રીમાંથી કન્ટેનર એન્જિન ચલાવતા હોસ્ટ તરફ ખેંચવામાં આવે છે. આ પ્રક્રિયાને આયોજન કહેવામાં આવે છે. રજિસ્ટ્રીમાંથી મોટી છબીઓ ખેંચવાથી કન્ટેનર ઓર્કેસ્ટ્રેશન સિસ્ટમમાં લાંબા સમય સુધી સુનિશ્ચિત કરવામાં આવે છે અને CI પાઇપલાઇન્સમાં લાંબા સમય સુધી નિર્માણ થાય છે.
• સુરક્ષા: મોટી છબીઓમાં નબળાઈઓ માટે પણ મોટો વિસ્તાર હોય છે.

એક ડોકર ઇમેજ સ્તરોના સ્ટેકથી બનેલી છે, દરેક અમારી ડોકરફાઇલમાં નિવેદન રજૂ કરે છે. દરેક સ્તર અંતર્ગત સ્તરમાં થતા ફેરફારોના ડેલ્ટાને રજૂ કરે છે. જ્યારે આપણે રજિસ્ટ્રીમાંથી ડોકર ઇમેજ ખેંચીએ છીએ, ત્યારે તે સ્તરોમાં ખેંચાય છે અને હોસ્ટ પર કેશ થાય છે.

વસંત બુટ વાપરે છે "ચરબી JAR" માં ડિફૉલ્ટ પેકેજિંગ ફોર્મેટ તરીકે. જ્યારે આપણે ચરબીવાળા JAR ને જોઈએ છીએ, ત્યારે આપણે જોઈએ છીએ કે એપ્લિકેશન સમગ્ર JAR નો ખૂબ જ નાનો ભાગ છે. આ તે ભાગ છે જે સૌથી વધુ બદલાય છે. બાકીનામાં વસંત ફ્રેમવર્ક અવલંબનનો સમાવેશ થાય છે.

ઑપ્ટિમાઇઝેશન ફોર્મ્યુલા સ્પ્રિંગ ફ્રેમવર્ક અવલંબનથી અલગ સ્તરે એપ્લિકેશનને અલગ કરવાની આસપાસ કેન્દ્રિત છે.

નિર્ભરતા સ્તર કે જે જાડા JAR ફાઇલનો મોટો ભાગ બનાવે છે તે માત્ર એક જ વાર ડાઉનલોડ થાય છે અને હોસ્ટ સિસ્ટમ પર કેશ થાય છે.

એપ્લિકેશન અપડેટ્સ અને કન્ટેનર શેડ્યુલિંગ દરમિયાન એપ્લિકેશનનો માત્ર એક પાતળો સ્તર ખેંચાય છે. આ રેખાકૃતિમાં બતાવ્યા પ્રમાણે:

નીચેના વિભાગોમાં, અમે સ્પ્રિંગ બૂટ એપ્લિકેશન માટે આ ઑપ્ટિમાઇઝ કરેલી છબીઓ કેવી રીતે બનાવવી તે જોઈશું.

બિલ્ડપેક સાથે સ્પ્રિંગ બૂટ એપ્લિકેશન માટે ઑપ્ટિમાઇઝ કન્ટેનર છબી બનાવવી

સ્પ્રિંગ બૂટ 2.3 જાડા JAR ફાઇલના ભાગોને અલગ સ્તરોમાં કાઢીને લેયરિંગને સપોર્ટ કરે છે. લેયરિંગ સુવિધા ડિફૉલ્ટ રૂપે અક્ષમ છે અને સ્પ્રિંગ બૂટ મેવેન પ્લગઇનનો ઉપયોગ કરીને સ્પષ્ટપણે સક્ષમ હોવું આવશ્યક છે:

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

અમે આ રૂપરેખાંકનનો ઉપયોગ પહેલા બિલ્ડપેક સાથે અને પછી નીચેના વિભાગોમાં ડોકર સાથે અમારી કન્ટેનર ઇમેજ બનાવવા માટે કરીશું.

ચાલો દોડીએ build-imageકન્ટેનર ઇમેજ બનાવવા માટે મેવેન લક્ષ્ય:

mvn spring-boot:build-image

જો આપણે પરિણામી ઈમેજમાં લેયર્સ જોવા માટે ડાઈવ ચલાવીએ, તો આપણે જોઈ શકીએ છીએ કે જાડા JAR ફોર્મેટનો ઉપયોગ કરીને અમને જે મળ્યું તેની સરખામણીમાં એપ્લીકેશન લેયર (લાલ રંગમાં વર્તુળાકાર) કિલોબાઈટ રેન્જમાં ઘણું નાનું છે:

ડોકરનો ઉપયોગ કરીને સ્પ્રિંગ બૂટ એપ્લિકેશન માટે ઑપ્ટિમાઇઝ કન્ટેનર છબી બનાવવી

Maven અથવા Gradle પ્લગઇનનો ઉપયોગ કરવાને બદલે, અમે Docker ફાઇલ સાથે સ્તરવાળી Docker JAR ઇમેજ પણ બનાવી શકીએ છીએ.

જ્યારે આપણે ડોકરનો ઉપયોગ કરીએ છીએ, ત્યારે અમારે સ્તરોને બહાર કાઢવા અને તેને અંતિમ ઈમેજમાં કૉપિ કરવા માટે બે વધારાના પગલાં લેવાની જરૂર છે.

લેયરિંગ સક્ષમ સાથે Maven સાથે બનાવ્યા પછી પરિણામી JAR ની સામગ્રી આના જેવી દેખાશે:

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-layertoolsએપ્લિકેશનને બદલે JAR:

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ફાઇલ જે ક્રમમાં ડોકર ઇમેજમાં ઉમેરવી જોઈએ. આ સ્તરો પ્રથમ મેળવ્યા પછી હોસ્ટ પર કેશ કરવામાં આવે છે કારણ કે તે બદલાતા નથી. ફક્ત અપડેટ કરેલ એપ્લિકેશન લેયર જ હોસ્ટ પર ડાઉનલોડ થાય છે, જે ઘટાડેલા કદને કારણે ઝડપી છે .

અલગ સ્તરોમાં કાઢવામાં આવેલી અવલંબન સાથે છબી બનાવવી

અમે નામની પદ્ધતિનો ઉપયોગ કરીને બે તબક્કામાં અંતિમ છબી બનાવીશું મલ્ટી-સ્ટેજ એસેમ્બલી . પ્રથમ ચરણમાં આપણે નિર્ભરતાઓને એક્સ્ટ્રેક્ટ કરીશું અને બીજા સ્ટેપમાં આપણે એક્સટ્રેક્ટેડ ડિપેન્ડન્સીને ફાઈનલમાં કોપી કરીશું.

ચાલો મલ્ટિ-સ્ટેજ બિલ્ડ માટે અમારી ડોકરફાઈલમાં ફેરફાર કરીએ:

# 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 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

આપણે જોઈ શકીએ છીએ કે ડોકર ઈમેજ ઈમેજ આઈડી સાથે બનાવવામાં આવી છે અને પછી ટેગ કરવામાં આવી છે.

છેલ્લે, અમે જનરેટ કરેલ ડોકર ઈમેજની અંદરના સ્તરોને તપાસવા માટે પહેલાની જેમ ડાઈવ આદેશ ચલાવીએ છીએ. અમે ડાઇવ આદેશમાં ઇનપુટ તરીકે ઇમેજ ID અથવા ટૅગ પ્રદાન કરી શકીએ છીએ:

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શેર કરેલ રીપોઝીટરીમાંથી મેળવેલ સંસ્થા અવલંબન ધરાવે છે.

નિષ્કર્ષ

આ લેખમાં, અમે સીધા સ્ત્રોતમાંથી કન્ટેનર ઇમેજ બનાવવા માટે ક્લાઉડ-નેટિવ બિલ્ડપેક્સનો ઉપયોગ કરવાનું જોયું. સામાન્ય રીતે કન્ટેનર ઈમેજ બનાવવા માટે ડોકરનો ઉપયોગ કરવાનો આ એક વિકલ્પ છે: પ્રથમ, એક જાડી એક્ઝિક્યુટેબલ JAR ફાઈલ બનાવવામાં આવે છે અને પછી ડોકરફાઈલમાં સૂચનાઓનો ઉલ્લેખ કરીને કન્ટેનર ઈમેજમાં પેક કરવામાં આવે છે.

અમે એક લેયરિંગ સુવિધાને સક્ષમ કરીને અમારા કન્ટેનરને ઑપ્ટિમાઇઝ કરવા તરફ પણ જોયું જે યજમાન પર કેશ કરાયેલા અલગ સ્તરોમાં નિર્ભરતાને ખેંચે છે અને કન્ટેનરના એક્ઝેક્યુશન એન્જિનમાં શેડ્યૂલિંગ સમયે એપ્લિકેશનનો પાતળો સ્તર લોડ થાય છે.

તમે લેખમાં વપરાયેલ તમામ સ્રોત કોડ અહીં મેળવી શકો છો Github .

આદેશ સંદર્ભ

ઝડપી સંદર્ભ માટે અમે આ લેખમાં ઉપયોગમાં લીધેલા આદેશોનો સારાંશ અહીં છે.

સંદર્ભ ક્લિયરિંગ:

docker system prune -a

ડોકરફાઇલ સાથે કન્ટેનરની છબી બનાવવી:

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

સ્ત્રોતમાંથી કન્ટેનર ઇમેજ બનાવો (ડોકરફાઇલ વિના):

mvn spring-boot:build-image

નિર્ભરતા સ્તરો જુઓ. એપ્લિકેશન જાર ફાઇલ બનાવતા પહેલા, ખાતરી કરો કે લેયરિંગ સુવિધા spring-boot-maven-plugin માં સક્ષમ છે:

java -Djarmode=layertools -jar application.jar list

નિર્ભરતા સ્તરો બહાર કાઢો. એપ્લિકેશન જાર ફાઇલ બનાવતા પહેલા, ખાતરી કરો કે લેયરિંગ સુવિધા spring-boot-maven-plugin માં સક્ષમ છે:

 java -Djarmode=layertools -jar application.jar extract

કન્ટેનર છબીઓની સૂચિ જોવી

docker images

કન્ટેનર ઇમેજની અંદર ડાબી બાજુ જુઓ (ખાતરી કરો કે ડાઇવ ટૂલ ઇન્સ્ટોલ કરેલું છે):

dive <image ID or image tag>

સોર્સ: www.habr.com