डकर छविहरू अप्टिमाइज गर्नु केवल एक र सम्पन्न चीज भन्दा बढी हो

यो लेख पोष्टहरूको शृंखलाको एक भाग हो जहाँ म रेलहरू पूर्वनिर्धारित डकरफाइलको प्रत्येक लाइनमा हिंड्नेछु र उत्तम अभ्यासहरू र अप्टिमाइजेसनहरू व्याख्या गर्नेछु।

डकर छविहरू विभिन्न तरिकामा अनुकूलित गर्न सकिन्छ जसमा छवि आकार घटाउने, प्रदर्शन अनुकूलन निर्माण, सुरक्षा, र रखरखाव योग्यता उत्तम अभ्यासहरू, र अनुप्रयोग-विशेष अनुकूलनहरू समावेश छन्, तर सीमित छैनन्। पहिलो लेखमा, म छवि आकार घटाउने अनुकूलन मात्र छुनेछु र तिनीहरू किन महत्त्वपूर्ण छन् भनेर व्याख्या गर्नेछु।

किन छवि आकार अनुकूलन गर्न?

सफ्टवेयर विकासको हरेक अन्य प्रक्रियामा जस्तै, प्रत्येक विकासकर्ताले आफ्नो कारणहरू सूचीबद्ध गर्नेछ किन उसले आफ्नो डकर छिटो निर्माण गर्न चाहन्छ। म मेरो लागि सबैभन्दा महत्त्वपूर्ण कारणहरू सूचीबद्ध गर्नेछु।

छिटो निर्माण र तैनाती

साना छविहरू निर्माण गर्न छिटो हुन्छ किनभने कम फाइलहरू र तहहरू प्रशोधन गर्न आवश्यक छ। यसले विकासकर्ताको उत्पादकतामा सुधार गर्छ, विशेष गरी पुनरावृत्ति विकास चक्रहरूमा। साना तस्बिरहरूले रजिस्ट्रीमा पुश गर्न र डिप्लोइमेन्टको क्रममा त्यसबाट तान्न कम समय लिन्छ। यो विशेष गरी 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

मैले पहिले नै छविहरू र तहहरूको बारेमा सिद्धान्त प्रदान गरेको हुनाले, यो Dockerfile अन्वेषण गर्ने समय हो। रेल 7.1 बाट सुरु हुँदै, 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 — ठूलो भिन्नता। तर alpine छवि अझ सानो छ भने के हुन्छ? alpine छवि अल्पाइन लिनक्स वितरणमा आधारित छ, जुन एक सुपर लाइटवेट लिनक्स वितरण हो जुन साइज र सुरक्षाको लागि अनुकूलित छ। अल्पाइनले GNU समकक्षहरूको सट्टा musl पुस्तकालय ( glibc को सट्टा) र busybox (Unix उपयोगिताहरूको कम्प्याक्ट सेट) प्रयोग गर्दछ। जबकि रेलहरू चलाउनको लागि 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

तपाईले देख्न सक्नुहुन्छ, --no-install-recommends बिनाको छवि मूल भन्दा 70 MB ठूलो छ। यो आकारमा 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 प्रयोग गर्नुहोस्

.dockerignore फाइल Git द्वारा प्रयोग गरिएको .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*

परियोजनामा .dockerfile फाइल हुनुले सन्दर्भबाट अनावश्यक फाइलहरू र डाइरेक्टरीहरू (जस्तै, .github फोल्डरबाट GitHub कार्यप्रवाहहरू वा node_modules बाट JavaScript निर्भरताहरू) छाड्न अनुमति दिन्छ। यसले गल्तिले छविमा संवेदनशील जानकारी थप्नबाट जोगिन मद्दत गर्दछ। उदाहरणका लागि, .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 पहिले नै बहु-चरण निर्माणहरू प्रयोग गर्दछ, म यो अर्को लेखमा कसरी काम गर्दछ भनेर वर्णन गर्नेछु।

निष्कर्ष

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