यो लेख पोष्टहरूको शृंखलाको एक भाग हो जहाँ म रेलहरू पूर्वनिर्धारित डकरफाइलको प्रत्येक लाइनमा हिंड्नेछु र उत्तम अभ्यासहरू र अप्टिमाइजेसनहरू व्याख्या गर्नेछु। डकर छविहरू विभिन्न तरिकामा अनुकूलित गर्न सकिन्छ जसमा छवि आकार घटाउने, प्रदर्शन अनुकूलन निर्माण, सुरक्षा, र रखरखाव योग्यता उत्तम अभ्यासहरू, र अनुप्रयोग-विशेष अनुकूलनहरू समावेश छन्, तर सीमित छैनन्। पहिलो लेखमा, म छवि आकार घटाउने अनुकूलन मात्र छुनेछु र तिनीहरू किन महत्त्वपूर्ण छन् भनेर व्याख्या गर्नेछु। किन छवि आकार अनुकूलन गर्न? सफ्टवेयर विकासको हरेक अन्य प्रक्रियामा जस्तै, प्रत्येक विकासकर्ताले आफ्नो कारणहरू सूचीबद्ध गर्नेछ किन उसले आफ्नो डकर छिटो निर्माण गर्न चाहन्छ। म मेरो लागि सबैभन्दा महत्त्वपूर्ण कारणहरू सूचीबद्ध गर्नेछु। छिटो निर्माण र तैनाती साना छविहरू निर्माण गर्न छिटो हुन्छ किनभने कम फाइलहरू र तहहरू प्रशोधन गर्न आवश्यक छ। यसले विकासकर्ताको उत्पादकतामा सुधार गर्छ, विशेष गरी पुनरावृत्ति विकास चक्रहरूमा। साना तस्बिरहरूले रजिस्ट्रीमा पुश गर्न र डिप्लोइमेन्टको क्रममा त्यसबाट तान्न कम समय लिन्छ। यो विशेष गरी CI/CD पाइपलाइनहरूमा महत्वपूर्ण छ जहाँ कन्टेनरहरू बनाइन्छ र बारम्बार तैनात गरिन्छ। कम भण्डारण लागत र नेटवर्क ब्यान्डविथ उपयोग साना छविहरूले कन्टेनर रजिस्ट्रीहरू, स्थानीय विकास मेसिनहरू, र उत्पादन सर्भरहरूमा कम भण्डारण खपत गर्दछ। यसले पूर्वाधार लागत घटाउँछ, विशेष गरी ठूला परिनियोजनका लागि। सर्भरहरू बीच स्थानान्तरण गर्दा साना छविहरूले कम ब्यान्डविथ प्रयोग गर्दछ, विशेष गरी महत्त्वपूर्ण जब तपाईं छविहरू स्थानीय रूपमा वा CI/CD पाइपलाइनहरूमा निर्माण गर्दै हुनुहुन्छ र तिनीहरूलाई रजिस्ट्रीमा धकेल्दै हुनुहुन्छ। "हामीले 2022 मा क्लाउडमा $ 3.2 मिलियन खर्च गर्यौं... हामी हाम्रो क्लाउड निकासबाट पाँच वर्षमा सर्भर खर्चमा $ 7m बचत गर्न खडा छौं।" डेभिड हेइनमेयर ह्यान्सन - हे विश्व सुधारिएको प्रदर्शन र सुरक्षा साना छविहरूलाई कम स्रोतहरू (जस्तै, CPU, RAM) लोड गर्न र चलाउन आवश्यक हुन्छ, कन्टेनरीकृत अनुप्रयोगहरूको समग्र प्रदर्शन सुधार गर्न। छिटो स्टार्टअप समय भनेको तपाईंका सेवाहरू अझ छिटो तयार छन्, जुन मापन र उच्च-उपलब्धता प्रणालीहरूको लागि महत्त्वपूर्ण छ। वा जस्ता न्यूनतम आधार छविहरूमा कम पूर्व-स्थापित प्याकेजहरू हुन्छन्, जसले अनप्याच नगरिएको वा अनावश्यक सफ्टवेयरको शोषणको जोखिम घटाउँछ। alpine debian-slim माथि उल्लेखित सबै कुरा बाहेक, अनावश्यक फाइलहरू र उपकरणहरू हटाउनाले समस्याहरूको निदान गर्दा विचलितहरूलाई कम गर्छ र राम्रो मर्मतयोग्यता र कम प्राविधिक ऋणमा जान्छ। डकर छविहरू निरीक्षण गर्दै आकार सहित छविको विभिन्न प्यारामिटरहरू प्राप्त गर्न, तपाईं या त डकर डेस्कटप हेर्न सक्नुहुन्छ वा टर्मिनलमा आदेश चलाउन सक्नुहुन्छ। docker images ➜ docker images REPOSITORY TAG IMAGE ID CREATED SIZE kamal-dashboard latest 673737b771cd 2 days ago 619MB kamal-proxy latest 5f6cd8983746 6 weeks ago 115MB docs-server latest a810244e3d88 6 weeks ago 1.18GB busybox latest 63cd0d5fb10d 3 months ago 4.04MB postgres latest 6c9aa6ecd71d 3 months ago 456MB postgres 16.4 ced3ad69d60c 3 months ago 453MB तस्विरको साइज थाहा पाउँदा पूर्ण तस्विर दिदैन। तपाईलाई थाहा छैन कि छवि भित्र के छ, यसको कति तहहरू छन्, वा प्रत्येक तह कति ठूलो छ। पढ्न-मात्र, हो जुन डकर छविको एक भाग हो। प्रत्येक तहले छविको फाइल प्रणालीमा गरिएका परिवर्तनहरूको सेट प्रतिनिधित्व गर्दछ, जस्तै फाइलहरू थप्ने, कन्फिगरेसनहरू परिमार्जन गर्ने, वा सफ्टवेयर स्थापना गर्ने। डकर छवि तह अपरिवर्तनीय फाइल प्रणाली तह डकर छविहरू क्रमशः बनाइन्छ, तहद्वारा तह, र प्रत्येक तह निर्देशनसँग मेल खान्छ। छविको तहहरू प्राप्त गर्न, तपाइँ आदेश चलाउन सक्नुहुन्छ। Dockerfile docker history ➜ docker history kamal-dashboard:latest IMAGE CREATED CREATED BY SIZE COMMENT 673737b771cd 4 days ago CMD ["./bin/thrust" "./bin/rails" "server"] 0B buildkit.dockerfile.v0 <missing> 4 days ago EXPOSE map[80/tcp:{}] 0B buildkit.dockerfile.v0 <missing> 4 days ago ENTRYPOINT ["/rails/bin/docker-entrypoint"] 0B buildkit.dockerfile.v0 <missing> 4 days ago USER 1000:1000 0B buildkit.dockerfile.v0 <missing> 4 days ago RUN /bin/sh -c groupadd --system --gid 1000 … 54MB buildkit.dockerfile.v0 <missing> 4 days ago COPY /rails /rails # buildkit 56.2MB buildkit.dockerfile.v0 <missing> 4 days ago COPY /usr/local/bundle /usr/local/bundle # b… 153MB buildkit.dockerfile.v0 <missing> 4 days ago ENV RAILS_ENV=production BUNDLE_DEPLOYMENT=1… 0B buildkit.dockerfile.v0 <missing> 4 days ago RUN /bin/sh -c apt-get update -qq && apt… 137MB buildkit.dockerfile.v0 <missing> 4 days ago WORKDIR /rails 0B buildkit.dockerfile.v0 <missing> 3 weeks ago CMD ["irb"] 0B buildkit.dockerfile.v0 <missing> 3 weeks ago RUN /bin/sh -c set -eux; mkdir "$GEM_HOME";… 0B buildkit.dockerfile.v0 <missing> 3 weeks ago ENV PATH=/usr/local/bundle/bin:/usr/local/sb… 0B buildkit.dockerfile.v0 <missing> 3 weeks ago ENV BUNDLE_SILENCE_ROOT_WARNING=1 BUNDLE_APP… 0B buildkit.dockerfile.v0 <missing> 3 weeks ago ENV GEM_HOME=/usr/local/bundle 0B buildkit.dockerfile.v0 <missing> 3 weeks ago RUN /bin/sh -c set -eux; savedAptMark="$(a… 78.1MB buildkit.dockerfile.v0 <missing> 3 weeks ago ENV RUBY_DOWNLOAD_SHA256=018d59ffb52be3c0a6d… 0B buildkit.dockerfile.v0 <missing> 3 weeks ago ENV RUBY_DOWNLOAD_URL=https://cache.ruby-lan… 0B buildkit.dockerfile.v0 <missing> 3 weeks ago ENV RUBY_VERSION=3.4.1 0B buildkit.dockerfile.v0 <missing> 3 weeks ago ENV LANG=C.UTF-8 0B buildkit.dockerfile.v0 <missing> 3 weeks ago RUN /bin/sh -c set -eux; mkdir -p /usr/loca… 19B buildkit.dockerfile.v0 <missing> 3 weeks ago RUN /bin/sh -c set -eux; apt-get update; a… 43.9MB buildkit.dockerfile.v0 <missing> 3 weeks ago # debian.sh --arch 'arm64' out/ 'bookworm' '… 97.2MB debuerreotype 0.15 मैले पहिले नै छविहरू र तहहरूको बारेमा सिद्धान्त प्रदान गरेको हुनाले, यो अन्वेषण गर्ने समय हो। रेल 7.1 बाट सुरु हुँदै, नयाँ रेल अनुप्रयोगको साथ उत्पन्न हुन्छ। तल यो कस्तो देखिन सक्छ को एक उदाहरण छ। Dockerfile Dockerfile # syntax=docker/dockerfile:1 # check=error=true # Make sure RUBY_VERSION matches the Ruby version in .ruby-version ARG RUBY_VERSION=3.4.1 FROM docker.io/library/ruby:$RUBY_VERSION-slim AS base # Rails app lives here WORKDIR /rails # Install base packages # Replace libpq-dev with sqlite3 if using SQLite, or libmysqlclient-dev if using MySQL RUN apt-get update -qq && \ apt-get install --no-install-recommends -y curl libjemalloc2 libvips libpq-dev && \ rm -rf /var/lib/apt/lists /var/cache/apt/archives # Set production environment ENV RAILS_ENV="production" \ BUNDLE_DEPLOYMENT="1" \ BUNDLE_PATH="/usr/local/bundle" \ BUNDLE_WITHOUT="development" # Throw-away build stage to reduce size of final image FROM base AS build # Install packages needed to build gems RUN apt-get update -qq && \ apt-get install --no-install-recommends -y build-essential curl git pkg-config libyaml-dev && \ rm -rf /var/lib/apt/lists /var/cache/apt/archives # Install application gems COPY Gemfile Gemfile.lock ./ RUN bundle install && \ rm -rf ~/.bundle/ "${BUNDLE_PATH}"/ruby/*/cache "${BUNDLE_PATH}"/ruby/*/bundler/gems/*/.git && \ bundle exec bootsnap precompile --gemfile # Copy application code COPY . . # Precompile bootsnap code for faster boot times RUN bundle exec bootsnap precompile app/ lib/ # Precompiling assets for production without requiring secret RAILS_MASTER_KEY RUN SECRET_KEY_BASE_DUMMY=1 ./bin/rails assets:precompile # Final stage for app image FROM base # Copy built artifacts: gems, application COPY --from=build "${BUNDLE_PATH}" "${BUNDLE_PATH}" COPY --from=build /rails /rails # Run and own only the runtime files as a non-root user for security RUN groupadd --system --gid 1000 rails && \ useradd rails --uid 1000 --gid 1000 --create-home --shell /bin/bash && \ chown -R rails:rails db log storage tmp USER 1000:1000 # Entrypoint prepares the database. ENTRYPOINT ["/rails/bin/docker-entrypoint"] # Start server via Thruster by default, this can be overwritten at runtime EXPOSE 80 CMD ["./bin/thrust", "./bin/rails", "server"] तल म अन्तिम छवि आकार कुशल बनाउनको लागि माथिको लागू हुने दृष्टिकोण र नियमहरूको सूची प्रदान गर्नेछु। Dockerfile प्याकेज स्थापनाहरू अनुकूलन गर्नुहोस् म पक्का छु कि तपाईंले आफ्नो स्थानीय विकास मेसिनमा आवश्यक सफ्टवेयर मात्र राख्नुहुन्छ। उही डकर छविहरूमा लागू गरिनु पर्छ। तलका उदाहरणहरूमा म माथिको रेल डकरफाइलबाट लगातार खराब बनाउनेछु। म यसलाई संस्करणको रूपमा सन्दर्भ गर्नेछु। निकालिएको डकरफाइललाई मूल Dockerfile नियम #1: न्यूनतम आधार छविहरू प्रयोग गर्नुहोस् FROM docker.io/library/ruby:$RUBY_VERSION-slim AS base आधार छवि लागि सुरूवात बिन्दु हो। यो छवि हो जुन कन्टेनर सिर्जना गर्न प्रयोग गरिन्छ। आधार छवि पहिलो तह हो, र यो एक मात्र तह हो जुन आफैले सिर्जना गरेको छैन। Dockerfile Dockerfile Dockerfile आधार छवि आदेश संग निर्दिष्ट गरिएको छ, छवि नाम र ट्याग पछि। ट्याग ऐच्छिक छ, र यदि निर्दिष्ट गरिएको छैन भने, ट्याग प्रयोग गरिन्छ। आधार छवि डकर हब वा कुनै अन्य रजिस्ट्रीमा उपलब्ध कुनै पनि छवि हुन सक्छ। FROM latest बारेमा, हामी ट्यागको साथ छवि प्रयोग गर्दैछौं। छवि डकर हबमा उपलब्ध हो। ट्याग रुबी छविको स्लिम संस्करण हो जुन छविमा आधारित छ। जबकि छवि डेबियन लिनक्स छविको न्यूनतम संस्करण हो जुन आकारको लागि अनुकूलित छ। छवि कति सानो छ भनेर एक विचार प्राप्त गर्न तलको तालिका हेर्नुहोस्। Dockerfile 3.4.1-slim ruby ruby आधिकारिक रूबी छवि 3.4.1-slim debian-slim debian-slim slim ➜ docker images --filter "reference=ruby" REPOSITORY TAG IMAGE ID CREATED SIZE ruby 3.4.1-slim 0bf957e453fd 5 days ago 219MB ruby 3.4.1-alpine cf9b1b8d4a0c 5 days ago 99.1MB ruby 3.4.1-bookworm 1e77081540c0 5 days ago 1.01GB जनवरी, 2024 सम्म, हालको डेबियन रिलीजलाई भनिन्छ र अघिल्लोलाई भनिन्छ। बुकवर्म बुल्सेइ 1GB को सट्टा 219 MB — ठूलो भिन्नता। तर छवि अझ सानो छ भने के हुन्छ? छवि अल्पाइन लिनक्स वितरणमा आधारित छ, जुन एक सुपर लाइटवेट लिनक्स वितरण हो जुन साइज र सुरक्षाको लागि अनुकूलित छ। अल्पाइनले GNU समकक्षहरूको सट्टा पुस्तकालय ( को सट्टा) र (Unix उपयोगिताहरूको कम्प्याक्ट सेट) प्रयोग गर्दछ। जबकि रेलहरू चलाउनको लागि छवि प्रयोग गर्न प्राविधिक रूपमा सम्भव छ, म यसलाई यस लेखमा कभर गर्ने छैन। alpine alpine musl glibc busybox alpine नियम #2: तहहरू न्यूनतम गर्नुहोस् RUN apt-get update -qq && \ apt-get install --no-install-recommends -y curl libjemalloc2 libvips libpq-dev && \ rm -rf /var/lib/apt/lists /var/cache/apt/archives प्रत्येक , र निर्देशनले नयाँ तह सिर्जना गर्दछ। तपाईंसँग जति धेरै तहहरू छन्, छविको आकार त्यति ठूलो हुन्छ। यसैले सबै भन्दा राम्रो अभ्यास एकल निर्देशनमा धेरै आदेशहरू संयोजन गर्न हो। यो बिन्दु चित्रण गर्न, तलको उदाहरण हेरौं। Dockerfile RUN COPY FROM RUN # syntax=docker/dockerfile:1 # check=error=true # Make sure RUBY_VERSION matches the Ruby version in .ruby-version ARG RUBY_VERSION=3.4.1 FROM docker.io/library/ruby:$RUBY_VERSION-slim AS base RUN apt-get update -qq RUN apt-get install --no-install-recommends -y curl RUN apt-get install --no-install-recommends -y libjemalloc2 RUN apt-get install --no-install-recommends -y libvips RUN apt-get install --no-install-recommends -y libpq-dev RUN rm -rf /var/lib/apt/lists /var/cache/apt/archives CMD ["echo", "Whalecome!"] मैले निर्देशनलाई धेरै लाइनहरूमा विभाजन गरेको छु, जसले स्पष्ट रूपमा तिनीहरूलाई अधिक बनाउँछ। तर यसले छविको आकारलाई कसरी असर गर्छ? छवि निर्माण गरौं र यसलाई जाँच गरौं। RUN मानव-पठनीय ➜ time docker build -t no-minimize-layers --no-cache -f no-minimize-layers.dockerfile . 0.31s user 0.28s system 2% cpu 28.577 total छवि बनाउन २८ सेकेन्ड लाग्यो, जबकि बनाउन मात्र १९ सेकेन्ड लाग्छ ( )। मिनिमाइज्ड लेयरहरूसँग मूल संस्करण लगभग ३३% छिटो ➜ time docker build -t original --no-cache -f original.dockerfile . 0.25s user 0.28s system 2% cpu 19.909 total छविहरूको साइज जाँच गरौं। ➜ docker images --filter "reference=*original*" --filter "reference=*no-minimize*" REPOSITORY TAG IMAGE ID CREATED SIZE original latest f1363df79c8a 8 seconds ago 356MB no-minimize-layers latest ad3945c8a8ee 43 seconds ago 379MB न्यूनतम तहहरू भएको छवि कुनै न्यूनतम तहहरू नभएको भन्दा २३ MB सानो छ। यो हो। यद्यपि यो उदाहरणमा सानो भिन्नता जस्तो देखिन्छ, यदि तपाईंले सबै निर्देशनहरूलाई बहु रेखाहरूमा विभाजन गर्नुभयो भने भिन्नता धेरै ठूलो हुनेछ। आकारमा 6% कमी RUN नियम # 3: आवश्यक के मात्र स्थापना गर्नुहोस् पूर्वनिर्धारित रूपमा, सिफारिस गरिएका प्याकेजहरू साथै तपाईंले यसलाई स्थापना गर्न भन्नुभएको प्याकेजहरू स्थापना गर्दछ। विकल्पले लाई स्पष्ट रूपमा निर्दिष्ट गरिएका प्याकेजहरू मात्र स्थापना गर्न बताउँछ र सिफारिस गरिएकाहरूलाई होइन। apt-get install --no-install-recommends apt-get ➜ time docker build -t without-no-install-recommends --no-cache -f without-no-install-recommends.dockerfile . 0.33s user 0.30s system 2% cpu 29.786 total ➜ docker images --filter "reference=*original*" --filter "reference=*recommends*" REPOSITORY TAG IMAGE ID CREATED SIZE without-no-install-recommends latest 41e6e37f1e2b 3 minutes ago 426MB minimize-layers latest dff22c85d84c 17 minutes ago 356MB तपाईले देख्न सक्नुहुन्छ, बिनाको छवि भन्दा 70 MB ठूलो छ। यो हो। --no-install-recommends मूल आकारमा 16% वृद्धि छविमा कुन फाइलहरू थपिएका थिए हेर्न उपयोगिता - लेखको अन्त्यमा यसको बारेमा थप पढ्नुहोस्। डाइभ प्रयोग गर्नुहोस् नियम #4: स्थापना पछि सफा गर्नुहोस् मूल आदेश आदेश पछि समावेश गर्दछ। यो आदेशले प्याकेज सूचीहरू र अभिलेखहरूलाई हटाउँछ जुन स्थापना पछि आवश्यक पर्दैन। यसले छवि आकारलाई कसरी असर गर्छ हेरौं, त्यो प्राप्त गर्न, म नयाँ सिर्जना गर्नेछु। Dockerfile rm -rf /var/lib/apt/lists/* /var/cache/apt/archives apt-get install सफा आदेश बिना Dockerfile RUN apt-get update -qq && \ apt-get install --no-install-recommends -y curl libjemalloc2 libvips libpq-dev तस्बिरहरू निर्माण गर्न मूल रूपमा लगभग उही समय लाग्छ, जसले अर्थ बनाउँछ। ➜ time docker build -t without-cleaning --no-cache -f without-cleaning.dockerfile . 0.28s user 0.30s system 2% cpu 21.658 total छविहरूको साइज जाँच गरौं। ➜ docker images --filter "reference=*original*" --filter "reference=*cleaning*" REPOSITORY TAG IMAGE ID CREATED SIZE without-cleaning latest 52884fe50773 2 minutes ago 375MB original latest f1363df79c8a 16 minutes ago 356MB सफाई बिनाको छवि सफाई भएको छवि भन्दा 19 MB ठूलो छ, यो हो। आकारमा 5% वृद्धि सबैभन्दा खराब परिदृश्य के हुन्छ यदि माथि उल्लेखित सबै चार अनुकूलनहरू लागू गरिएन? नयाँ सिर्जना गरौं र छवि निर्माण गरौं। कुनै पनि अप्टिमाइजेसन बिना Dockerfile # syntax=docker/dockerfile:1 # check=error=true ARG RUBY_VERSION=3.4.1 FROM docker.io/library/ruby:$RUBY_VERSION AS base RUN apt-get update -qq RUN apt-get install -y curl RUN apt-get install -y libjemalloc2 RUN apt-get install -y libvips RUN apt-get install -y libpq-dev CMD ["echo", "Whalecome!"] ➜ time docker build -t without-optimizations --no-cache -f without-optimizations.dockerfile . 0.46s user 0.45s system 1% cpu 1:02.21 total वाह, छवि निर्माण गर्न एक मिनेट भन्दा बढी लाग्यो। ➜ docker images --filter "reference=*original*" --filter "reference=*without-optimizations*" REPOSITORY TAG IMAGE ID CREATED SIZE without-optimizations latest 45671929c8e4 2 minutes ago 1.07GB original latest f1363df79c8a 27 hours ago 356MB अनुकूलन बिनाको छवि मूल भन्दा 714 MB ठूलो छ, यो हो। यसले स्पष्ट रूपमा देखाउँछ कि अप्टिमाइज गर्न कत्तिको महत्त्वपूर्ण छ, ठूला छविहरूले निर्माण गर्न र थप डिस्क ठाउँ खपत गर्न बढी समय लिन्छ। आकारमा 200% वृद्धि Dockerfile सधैं .dockerignore प्रयोग गर्नुहोस् फाइल Git द्वारा प्रयोग गरिएको फाइल जस्तै छ। यो निर्माणको सन्दर्भबाट फाइलहरू र डाइरेक्टरीहरू बहिष्कार गर्न प्रयोग गरिन्छ। सन्दर्भ फाइल र डाइरेक्टरीहरूको सेट हो जुन छवि निर्माण गर्दा डकर डेमनमा पठाइन्छ। सन्दर्भ डकर डेमनमा टारबलको रूपमा पठाइन्छ, त्यसैले यसलाई सकेसम्म सानो राख्न महत्त्वपूर्ण छ। .dockerignore .gitignore यदि, कुनै कारणले, तपाइँसँग तपाइँको परियोजनामा फाइल छैन भने, तपाइँ यसलाई म्यानुअल रूपमा सिर्जना गर्न सक्नुहुन्छ। म तपाईंलाई आधिकारिक रेलहरू सुरूवात बिन्दुको रूपमा प्रयोग गर्न सुझाव दिन्छु। तल यो कस्तो देखिन सक्छ को एक उदाहरण छ। .dockerignore .dockerignore फाइल टेम्प्लेट # See https://docs.docker.com/engine/reference/builder/#dockerignore-file for more about ignoring files. # Ignore git directory. /.git/ /.gitignore # Ignore bundler config. /.bundle # Ignore all environment files. /.env* # Ignore all default key files. /config/master.key /config/credentials/*.key # Ignore all logfiles and tempfiles. /log/* /tmp/* !/log/.keep !/tmp/.keep # Ignore pidfiles, but keep the directory. /tmp/pids/* !/tmp/pids/.keep # Ignore storage (uploaded files in development and any SQLite databases). /storage/* !/storage/.keep /tmp/storage/* !/tmp/storage/.keep # Ignore assets. /node_modules/ /app/assets/builds/* !/app/assets/builds/.keep /public/assets # Ignore CI service files. /.github # Ignore development files /.devcontainer # Ignore Docker-related files /.dockerignore /Dockerfile* परियोजनामा फाइल सन्दर्भबाट अनावश्यक फाइलहरू र डाइरेक्टरीहरू (जस्तै, फोल्डरबाट GitHub कार्यप्रवाहहरू वा बाट JavaScript निर्भरताहरू) छाड्न अनुमति दिन्छ। यसले गल्तिले छविमा संवेदनशील जानकारी थप्नबाट जोगिन मद्दत गर्दछ। उदाहरणका लागि, फाइल जसले वातावरण चर समावेश गर्दछ वा फाइल जुन प्रमाणहरू डिक्रिप्ट गर्न प्रयोग गरिन्छ। .dockerfile हुनुले .github node_modules .env master.key डाइभ प्रयोग गर्नुहोस् माथि उल्लेखित सबै अप्टिमाइजेसनहरू व्याख्या गर्दा स्पष्ट देखिन सक्छ। के गर्ने यदि तपाइँसँग पहिले नै ठूलो छवि छ, र तपाइँ कहाँ सुरु गर्ने थाहा छैन? मेरो मनपर्ने र सबैभन्दा उपयोगी उपकरण हो। डाइभ एउटा डकर छवि, तह सामग्रीहरू, र छवि आकार संकुचन गर्ने तरिकाहरू पत्ता लगाउनको लागि TUI उपकरण हो। डाइभ तपाइँको प्रणाली प्याकेज प्रबन्धक संग स्थापना गर्न सकिन्छ, वा तपाइँ यसलाई चलाउन यसको आधिकारिक डकर छवि प्रयोग गर्न सक्नुहुन्छ। हाम्रो सबैभन्दा खराब परिदृश्यबाट छवि प्रयोग गरौं। डाइभ docker run --rm -it -v /var/run/docker.sock:/var/run/docker.sock wagoodman/dive:latest without-optimizations माथिको स्क्रिनसटमा, तपाईंले हाम्रो सबैभन्दा गैर-इष्टतम छविको निरीक्षण देख्न सक्नुहुन्छ। डाइभले प्रत्येक तहको आकार, छविको कुल आकार, र प्रत्येक तहमा परिवर्तन गरिएका (थपिएका, परिमार्जन गरिएका वा मेटाइएका) फाइलहरू देखाउँछन्। मेरो लागि, यो डाइभको सबैभन्दा उपयोगी सुविधा हो। दायाँ प्यानलमा फाइलहरू सूचीबद्ध गरेर, तपाईं सजिलैसँग आवश्यक नभएका फाइलहरू पहिचान गर्न सक्नुहुन्छ र तिनीहरूलाई छविमा थप्ने आदेशहरू हटाउन सक्नुहुन्छ। एउटा कुरा जुन मलाई डाइभको बारेमा साँच्चै मनपर्छ त्यो हो कि, टर्मिनल UI हुनुको अलावा, यसले CI-मैत्री आउटपुट पनि प्रदान गर्न सक्छ, जुन स्थानीय विकासमा पनि प्रभावकारी हुन सक्छ। यसलाई प्रयोग गर्नको लागि, वातावरण चरको साथ डाइभ चलाउनुहोस् मा सेट गर्नुहोस्, आदेशको आउटपुट तलको स्क्रिनसटमा छ। CI true docker run -e CI=true --rm -it -v /var/run/docker.sock:/var/run/docker.sock wagoodman/dive:latest without-optimizations मेरो व्यक्तिगत प्राथमिकता अनुसूचित आधारमा डाइभ प्रयोग गर्नु हो, उदाहरणका लागि, हप्तामा एक पटक, तपाइँका छविहरू अझै राम्रो आकारमा छन् भनेर सुनिश्चित गर्न। आगामी लेखहरूमा, म डाइभ र सहित मेरो डकरफाइल जाँच गर्न प्रयोग गर्ने स्वचालित कार्यप्रवाहहरू कभर गर्नेछु। ह्याडोलिन्ट तहहरू स्क्वाश नगर्नुहोस् मैले देखेको छवि आकारलाई कम गर्ने एउटा दृष्टिकोण भनेको तहहरू स्क्वाश गर्ने प्रयास गर्नु हो। छविको आकार घटाउन धेरै तहहरूलाई एकल तहमा जोड्ने विचार थियो। डकरसँग एक प्रयोगात्मक विकल्प थियो , यस बाहेक, त्यहाँ जस्ता तेस्रो-पक्ष उपकरणहरू थिए। --squash डकर-स्क्वाश यस दृष्टिकोणले विगतमा काम गरे पनि, हाल यसलाई बहिष्कार गरिएको छ र प्रयोग गर्न सिफारिस गरिएको छैन। स्क्वाशिङ लेयरले डकरको लेयर क्यासिङको आधारभूत विशेषतालाई नष्ट गर्यो। यस बाहेक, प्रयोग गर्दा तपाईंले अन्जानमा अन्तिम छविमा अघिल्लो तहहरूबाट संवेदनशील वा अस्थायी फाइलहरू समावेश गर्न सक्नुहुन्छ। यो सबै वा केही नभएको दृष्टिकोण हो जसमा फाइन-ग्रेन्ड नियन्त्रणको कमी छ। --squash तहहरू स्क्वाश गर्नुको सट्टा, बहु-चरण निर्माणहरू प्रयोग गर्न सिफारिस गरिन्छ। रेल पहिले नै बहु-चरण निर्माणहरू प्रयोग गर्दछ, म यो अर्को लेखमा कसरी काम गर्दछ भनेर वर्णन गर्नेछु। Dockerfile निष्कर्ष डकर छविहरू अनुकूलन, कुनै अन्य अप्टिमाइजेसन जस्तै, । यो एक निरन्तर प्रक्रिया हो जसलाई नियमित जाँच र सुधार आवश्यक छ। मैले आधारभूत कुराहरू कभर गर्ने प्रयास गरें, तर तिनीहरू जान्न र बुझ्न महत्त्वपूर्ण छन्। अर्को लेखहरूमा, म थप उन्नत प्रविधिहरू र उपकरणहरू कभर गर्नेछु जसले तपाईंको डकरलाई छिटो र अधिक कुशल बनाउन मद्दत गर्न सक्छ। एक पटक र बिर्सन सकिँदैन
