जावा अनुप्रयोगों के लिए छवि अनुकूलन की कहानी वसंत ब्लॉग लेख एक कंटेनर में स्प्रिंग बूट के साथ शुरू हुई। इसमें स्प्रिंग बूट एप्लिकेशन के लिए डॉकटर इमेज बनाने के विभिन्न पहलुओं पर चर्चा की गई, जिसमें छवियों के आकार को कम करने के लिए एक दिलचस्प मुद्दा भी शामिल है। हमारी टीमों के लिए, यह कई कारणों से प्रासंगिक था, इसलिए हमने इस समाधान को हमारे अनुप्रयोगों पर लागू करने का निर्णय लिया।

जैसा कि अक्सर होता है, सब कुछ पहली बार नहीं हुआ, मल्टी-मॉड्यूल प्रोजेक्ट्स के साथ बारीकियां थीं और सीआई सिस्टम पर यह सब ड्राइव करने का प्रयास किया गया था, इसलिए इस लेख में आप इन समस्याओं का समाधान पाएंगे।

अनुकूलन का लक्ष्य असेंबली से विधानसभा तक परिणामी छवियों के बीच अंतर को कम करना है, जो निरंतर वितरण की प्रक्रिया में एक अच्छा परिणाम देता है, इसलिए यदि आप छवि के आकार को कम से कम करने में रुचि रखते हैं, तो आप हब पर अन्य लेखों का संदर्भ ले सकते हैं

यदि आपको यह स्पष्ट नहीं करना है कि छवि में रखने से पहले आपको मल्टी-मीटर बूट एप्लिकेशन के साथ कुछ क्यों करना चाहिए, तो आप तुरंत अनुकूलन दृष्टिकोण के विवरण पर जा सकते हैं। यदि आप वसंत ब्लॉग से लेख से परिचित होने में कामयाब रहे, तो आप पाई गई समस्याओं के समाधान के लिए आगे बढ़ सकते हैं।

क्यों यह सब है, या वसा जार के फ्लिप पक्ष

डिफ़ॉल्ट रूप से, जार जो स्प्रिंग बूट का उत्पादन करता है, एक निष्पादन योग्य जार फ़ाइल है जिसमें एप्लिकेशन कोड और इसकी सभी निर्भरताएं होती हैं।

इस दृष्टिकोण का लाभ स्पष्ट है: एक फ़ाइल के साथ काम करना सुविधाजनक है, इसमें वह सब कुछ है जो आपको java -jar <myapp>.jar से चलाने की आवश्यकता है। Dockerfile तुच्छ है और ब्याज की नहीं।

नकारात्मक पहलू अक्षम भंडारण है। क्लासिक बूट एप्लिकेशन में, कोड और पुस्तकालयों का अनुपात स्पष्ट रूप से हमारे कोड के पक्ष में नहीं है। उदाहरण के लिए, डेटाबेस के साथ काम करने के लिए एक वेब पार्ट और पुस्तकालयों के साथ एक खाली अनुप्रयोग, जो start.spring.io के माध्यम से उत्पन्न किया जा सकता है, 20mb ले जाएगा, जिसमें से 98% लाइब्रेरी होंगे। और यह अनुपात विकास प्रक्रिया के दौरान बहुत अधिक नहीं बदलता है।

लेकिन हम एक से अधिक बार आवेदन एकत्र करते हैं, लेकिन नियमित रूप से सीआई सर्वर पर, और फिर वातावरण की एक श्रृंखला पर तैनात होते हैं। इस प्रकार, 10 असेंबली 200mb पर बढ़ती है, और 100 - 2 जीबी पर, जिनमें से संशोधन बहुत कम होंगे।

यह तर्क दिया जा सकता है कि भंडारण की वर्तमान लागत के लिए, ये हास्यास्पद आंकड़े हैं और आपको इस तरह के अनुकूलन पर समय नहीं देना है, लेकिन यह सभी संगठन के आकार और उन अनुप्रयोगों की संख्या पर निर्भर करता है जिनकी छवियों को संग्रहीत करने की आवश्यकता है। तैनाती की स्थिति भी दृढ़ता से प्रेरित कर सकती है: जब रजिस्ट्री और सर्वर पास होते हैं, यहां तक कि 100mb का अंतर भी बहुत ध्यान देने योग्य नहीं होता है, लेकिन वितरित प्रणालियों में यह बहुत अधिक महत्वपूर्ण हो सकता है, खासकर जब आपको ऐसे विशिष्ट देशों में तैनात करने की आवश्यकता होती है जैसे कि चीन अपने फ़ायरवॉल और अस्थिर चैनलों के साथ। बाहर की दुनिया के लिए।

तो, कारणों के साथ, यह अनुकूलन का समय है।

हम असेंबली को ऑप्टिमाइज़ करते हैं, या स्प्रिंग ब्लॉग से क्या सीखा जा सकता है

लेख एक उचित समाधान प्रदान करता है: COPY my-jar.jar app.jar द्वारा उत्पन्न एक एकल परत के बजाय, हमें कई परतें बनाने की आवश्यकता है।
एक परत में पुस्तकालय होंगे, दूसरा हमारा अपना कोड है। ऐसा करने के लिए, आपको जार फ़ाइल को अनज़िप करने और सामग्री को छवि की विभिन्न परतों में कॉपी करने की आवश्यकता है।

जार फ़ाइल तैयार करने की स्क्रिप्ट इस प्रकार है:

 #!/bin/sh set -e path_to_jar=$1 dir=$(dirname "${path_to_jar}") jar_name=$(basename "${path_to_jar}") mkdir -p "${dir}/docker-dist" && cd "${dir}/docker-dist" jar -xf ../"${jar_name}"

मल्टी-स्टेज बिल्ड का उपयोग करने वाला डॉकटराइल ऐसा दिख सकता है

 FROM openjdk:8-jdk-alpine as build WORKDIR /wd COPY prepare_for_docker.sh /usr/local/bin/prepare_for_docker COPY target/demo.jar /wd/app.jar RUN prepare_for_docker /wd/app.jar FROM openjdk:8-jdk-alpine COPY --from=build /wd/docker-dist/BOOT-INF/lib /app/lib COPY --from=build /wd/docker-dist/META-INF /app/META-INF COPY --from=build /wd/docker-dist/BOOT-INF/classes /app ENTRYPOINT ["java","-cp","app:app/lib/*","com.example.demo.DemoApplication"]

पहले चरण में, हम अपनी ज़रूरत की हर चीज़ को कॉपी करते हैं, जार फ़ाइल को अनपैक करने के लिए अपनी स्क्रिप्ट चलाते हैं, और दूसरे चरण में हम अलग-अलग पुस्तकालयों और हमारे कोड को अलग-अलग परतों में रखते हैं।

यह सुनिश्चित करना आसान है:

पहली बार इकट्ठा हो रहा है
हमारे कोड में कोई भी बदलाव करें।

हम docker build फिर से लॉन्च करते हैं और संपूर्ण कार्यशील निर्देशिका को कॉपी करते समय Using cache पोषित लाइनों को देखते हैं

 ... Step 5/10 : RUN prepare_for_docker app.jar ---> Running in c8e422491eb2 Removing intermediate container c8e422491eb2 ---> c7dcec4ae18a Step 6/10 : FROM openjdk:8-jdk-alpine ---> a3562aa0b991 Step 7/10 : COPY --from=build /wd/docker-dist/BOOT-INF/lib /app/lib ---> Using cache ---> 01b600d7e350 Step 8/10 : COPY --from=build /wd/docker-dist/META-INF /app/META-INF ---> Using cache ---> 5c0c03a3c8f1 Step 9/10 : COPY --from=build /wd/docker-dist/BOOT-INF/classes /app ---> 5ffed6ee5696 Step 10/10 : ENTRYPOINT ["java","-cp","app:app/lib/*","com.example.demo.DemoApplication"] ---> Running in 99957250fe5d Removing intermediate container 99957250fe5d ---> 6735799d9f32 Successfully built 6735799d9f32 Successfully tagged boot2-sample:latest

इस दृष्टिकोण को बेहतर बनाने का एक स्पष्ट तरीका एक स्क्रिप्ट के साथ एक छोटी आधार छवि बनाना है, ताकि इसे परियोजना से परियोजना तक न खींचा जा सके। इस प्रकार, पहली परत अधिक संक्षिप्त हो जाती है।

 FROM zeldigas/java-layered-builder as build COPY target/demo.jar app.jar RUN prepare_for_docker app.jar

हम समाधान को अंतिम रूप दे रहे हैं

जैसा कि पहले से ही लेख की शुरुआत में उल्लेख किया गया है, समाधान काम कर रहा है, लेकिन ऑपरेशन के दौरान कुछ समस्याएं पाई गईं, जिनके बारे में बाद में चर्चा की जाएगी।

सभी फाइलें समान रूप से लाइब्रेरी में नहीं हैं

यदि आपकी परियोजना बहु-मॉड्यूल है (कम से कम मॉड्यूल ए है, जिस पर मॉड्यूल बी निर्भर करता है, स्प्रिंग वसा जार के रूप में इकट्ठा होता है), तो इसका एक मूल समाधान लागू करने पर, आप पाएंगे कि कोई परत कैशिंग नहीं होती है। क्या गलत हुआ?

मामला अतिरिक्त मॉड्यूल में है: वे परत के लिए निरंतर परिवर्तनों के स्रोत हैं, भले ही आप मॉड्यूल कोड में कोई बदलाव न करें। यह मावेन जार फाइलें बनाने की ख़ासियत के कारण है (ढाल के साथ, स्थिति थोड़ी बेहतर है, लेकिन निश्चित नहीं है)। प्रतिलिपि प्रस्तुत करने योग्य कलाकृतियों को प्राप्त करने का कार्य इस लेख का विषय नहीं है (हालांकि, निश्चित रूप से, यह दिलचस्प और प्राप्त करने योग्य है), इसलिए हम एक काफी सरल समाधान की ओर मुड़ते हैं।

हम 2 निर्देशिकाओं में lib की सामग्री को वितरित करते हैं, अनपैक करने के बाद, प्रोजेक्ट मॉड्यूल को अन्य पुस्तकालयों से अलग करते हैं। चलो वसा जार अनपैकिंग स्क्रिप्ट को अंतिम रूप दें:

 #!/bin/sh set -e path_to_jar=$1 shift #(1) app_modules=$* #(2) dir=$(dirname "${path_to_jar}") jar_name=$(basename "${path_to_jar}") mkdir -p "${dir}/docker-dist" && cd "${dir}/docker-dist" jar -xf ../"${jar_name}" if [ -n "${app_modules}" ]; then #(3) mkdir app-lib for i in $app_modules; do mv "BOOT-INF/lib/$i"* app-lib #(4) done fi

नतीजतन, स्क्रिप्ट अतिरिक्त मापदंडों के स्थानांतरण का समर्थन करने लगी (1 और 2 देखें)। यदि अतिरिक्त तर्क (3) पारित हो जाते हैं, तो उनमें से प्रत्येक को फ़ाइल के नाम के लिए एक उपसर्ग माना जाता है जिसे हम (4) एक अलग निर्देशिका में स्थानांतरित करते हैं।

एक अतिरिक्त के साथ परिदृश्य के लिए डॉकफाइल उदाहरण। shared-module और संस्करण 1.0-SNAPSHOT

 FROM openjdk:8-jdk-alpine as build COPY target/demo.jar /wd/app.jar RUN prepare_for_docker /wd/app.jar shared-module-1.0 FROM openjdk:8-jdk-alpine COPY --from=build /wd/docker-dist/BOOT-INF/lib /app/lib COPY --from=build /wd/docker-dist/app-lib /app/lib COPY --from=build /wd/docker-dist/META-INF /app/META-INF COPY --from=build /wd/docker-dist/BOOT-INF/classes /app ENTRYPOINT ["java","-cp","app:app/lib/*","com.example.demo.DemoApplication"]

CI सर्वर पर चलाएँ

स्थानीय रूप से सब कुछ डिबग करने के बाद, परिणाम से संतुष्ट होकर, हमने CI सर्वर पर चलना शुरू कर दिया और बिल्ड लॉग से पाया कि कोई चमत्कार नहीं हुआ, या इसके बजाय परिणाम निरंतर नहीं थे: कुछ मामलों में, कैशिंग प्रदर्शन किया गया था, और अगली बार सभी परतें नई थीं।

नतीजतन, अपराधी की खोज की गई - डॉकटर कैश, या विभिन्न एजेंटों के मामले में इसकी अनुपस्थिति (हमारी विधानसभा सीआई सिस्टम के एक विशिष्ट एजेंट के लिए किसी को भी नहीं पकड़ा गया है)। जैसा कि यह पता चला है, अगर डॉकटर कैश में कोई उपयुक्त परतें नहीं हैं, तो फ़ाइलों के एक ही सेट से एक अलग चेकसम के साथ परतें प्राप्त की जाती हैं। आप इसे स्थानीय रूप से सत्यापित कर सकते हैं - निर्माण को --no-cache विकल्प के साथ चलाकर, या पहली बार छवि को हटाकर और सभी मध्यवर्ती परतों को बनाकर। नतीजतन, आपको पूरी तरह से अलग चेकसम लेयर मिलता है, जो पिछले सभी प्रयासों को नकार देता है।

सही कैश के बिना, हमें अलग-अलग परतें मिलती हैं

समस्या को हल करने के कई तरीके हैं:

यदि आपका CI- सिस्टम बॉक्स से बाहर का समर्थन करता है (उदाहरण के लिए, योजनाओं में सर्कल CI ने असेंबली के लिए साझा कैश के लिए अंतर्निहित समर्थन किया है)
एजेंटों के बीच डॉक कैश के साथ एक अनुभाग को फेरबदल करना
अंतर्निहित कैश प्रबंधन --cache-from लाभ उठाएं ( --cache-from कैश --cache-from )

हम तीसरे तरीके से गए, क्योंकि हमारे मामले में यह सबसे सरल था। विकल्प आपको डॉक डेमॉन को यह बताने की अनुमति देता है कि इसे किन छवियों को ध्यान में रखना चाहिए और विधानसभा के दौरान कैशिंग के लिए उपयोग करने का प्रयास करना चाहिए। आप आवश्यक के रूप में कई छवियों को निर्दिष्ट कर सकते हैं, मुख्य बात यह है कि वे फ़ाइल सिस्टम पर हैं। यदि निर्दिष्ट छवि मौजूद नहीं है, तो इसे आसानी से अनदेखा किया जाएगा, इसलिए आपको निर्माण से पहले खींचने की आवश्यकता है।

इस दृष्टिकोण से कंटेनर असेंबली कैसी दिखती है:

 set -e version=... #      docker pull registy.example.com/my-image:latest || true #         docker build -t registry.example.com/my-image:$version --cache-from registry.example.com/my-image:latest . #   registry    latest docker tag registry.example.com/my-image:$version registry.example.com/my-image:latest docker push registry.example.com/my-image:$version docker push registry.example.com/my-image:latest

हम केवल सबसे हालिया छवि से परतों का पुन: उपयोग करने का प्रयास करते हैं, जो अक्सर पर्याप्त होता है, लेकिन कोई भी अधिक जटिल तर्क को हवा देने और कुछ संस्करणों को पीछे करने या vcs कमिट की आईडी पर भरोसा करने के लिए परेशान नहीं करता है।

हम इस दृष्टिकोण को आपके CI की क्षमताओं के अनुकूल बनाते हैं और पुस्तकालयों के साथ परतों का विश्वसनीय पुन: उपयोग करते हैं।

कुल मिलाकर

समाधान अच्छे परिणाम दिखाता है, खासकर जब विकास के एक सक्रिय चरण और एक ट्यून्ड सीडी पाइपलाइन के साथ परियोजनाओं में उपयोग किया जाता है। नीचे दिया गया ग्राफ़ अनुप्रयोगों में से किसी एक में अनुकूलन लागू करने का परिणाम दिखाता है। यह स्पष्ट रूप से देखा गया है कि रैखिक विकास 70 वीं विधानसभा से शुरू होने वाली स्पस्मोडिक में बदल गया है (60 के दशक में विफलता बिल्ड एजेंटों पर डिबगिंग कार्य के साथ ठीक से जुड़ी हुई है)। बेस इमेज (हाई) और लाइब्रेरी (लोअर) को अपडेट करने के बाद के इमिशन

हमारे मामले में भंडारण अनुकूलन एक सुखद, बल्कि एक माध्यमिक बोनस है। कई क्षेत्रों में पुराने के ऊपर नए संस्करण की तैनाती का त्वरण अधिक सुखदायक है।

यह ध्यान दिया जाना चाहिए कि यह तकनीक एकल छवि (अल्पाइन और अन्य हल्के मूल चित्र, आवेदन के लिए कस्टम रनटाइम) के आकार को कम करने के उद्देश्य से अन्य दृष्टिकोणों के साथ काफी संगत है। मुख्य बात यह है कि कैशिंग के संदर्भ में छवि को इकट्ठा करने के लिए सामान्य नियमों का पालन करें और सुनिश्चित करें कि परिणाम प्रतिलिपि प्रस्तुत करने योग्य है।

जावा अनुप्रयोगों के लिए docker की छवियों को अनुकूलित करने का दूसरा तरीका