এর সাথে একক সমাধান ছাড়াও বিভিন্ন কৌশল রয়েছে। আপনি সম্ভবত নিম্নলিখিত কয়েকটি করতে চান:
প্রথমে পুনরায় ব্যবহারের জন্য আপনার চিত্র স্তরগুলি অনুকূলিত করুন optim পূর্ববর্তী স্তরগুলি থেকে পূর্বের স্তরগুলি ক্যাশে হওয়ার সম্ভাবনা বাড়ানোর জন্য ডকফাইলে পরে প্রায়শই পরিবর্তনের পদক্ষেপগুলি রাখুন। একটি পুনঃব্যবহৃত স্তরটি আরও একটি ডিস্কের স্থান হিসাবে প্রদর্শিত হবে docker image ls, তবে আপনি যদি অন্তর্নিহিত ফাইল সিস্টেমটি পরীক্ষা করেন তবে প্রতিটি স্তরের কেবলমাত্র একটি অনুলিপি ডিস্কে সঞ্চিত থাকে। এর অর্থ প্রতিটির 2 জিবি 3 টি চিত্র, তবে যা শেষ কয়েকটি স্তরগুলির মধ্যে কেবল 50 এমবি পৃথক রয়েছে কেবলমাত্র 2.1 গিগাবাইটের ডিস্ক স্থান গ্রহণ করবে, যদিও তালিকাতে দেখা যাচ্ছে যে তারা যেহেতু 6 জিবি ব্যবহার করছে পুনরায় ব্যবহৃত স্তরগুলির প্রতিটি ডাবল গণনা।
স্তর পুনঃব্যবহারের কারণেই আপনি কোডগুলি অনুলিপি করার আগে বিল্ড নির্ভরতা পরিবর্তনের পরিবর্তে চিত্রগুলি দেখেন। এমন কোনও অজগর উদাহরণ দেখুন যার প্যাটার্ন রয়েছে:
FROM python
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
# note how the code is copied only after the pip install
# since code changes but requirements.txt doesn't
COPY . .
CMD ["gunicorn", "app:app"]
একটি ন্যূনতম বেস চিত্র চয়ন করুন। এই কেন আপনি দেখতে মানুষের কাছ থেকে যেতে ubuntuকরার debian:slim(পাতলা রূপগুলো, ছোট কম সরঞ্জামগুলির সাথে শিপিং), অথবা এমনকি alpine। এটি আপনার প্রারম্ভিক পয়েন্টটির আকার হ্রাস করে এবং আপনি যদি বেস ইমেজের ক্রমাগত নতুন সংস্করণ টানতে থাকেন তবে এটি খুব সহায়ক। তবে, যদি আপনার বেস চিত্রটি খুব কমই পরিবর্তিত হয়, তবে স্তর পুনঃব্যবহার একটি ন্যূনতম বেস চিত্রের অনেক সুবিধা সরিয়ে দেয়।
আপনি যে সবচেয়ে ছোট বেস ইমেজটি বেছে নিতে পারেন scratchতা হ'ল যা কিছুই নয়, কোনও শেল বা লাইব্রেরি নয় এবং এটি কেবল স্ট্যাটিক্যালি সংকলিত বাইনারিগুলির সাথেই কার্যকর। অন্যথায়, একটি বেস চিত্র চয়ন করুন যা আপনাকে প্রয়োজনীয় সরঞ্জামগুলি ছাড়াই আপনার প্রয়োজনীয় সরঞ্জামগুলি অন্তর্ভুক্ত করে।
এরপরে, কোনও ফাইল পরিবর্তন করে বা মুছতে পারে এমন কোনও পদক্ষেপ সেই ফাইলটি তৈরি করা পূর্ববর্তী পদক্ষেপের সাথে একত্রিত করা উচিত। অন্যথায় স্তরযুক্ত ফাইল সিস্টেম, যা ফাইল অনুমতি পরিবর্তনের মতো জিনিসগুলিতে এমনকি অনুলিপি ব্যবহার করে, তার আগের স্তরে আসল ফাইলটি থাকবে এবং আপনি ফাইলগুলি সরানোর সময় চিত্রের আকার সঙ্কুচিত হবে না। rmফলস্বরূপ ডিস্কের জায়গাতে আপনার কমান্ডগুলির কোনও প্রভাব নেই। পরিবর্তে, আপনি আদেশগুলি শৃঙ্খলাবদ্ধ করতে পারেন:
RUN apt-get update \
&& apt-get install -y \
a-package \
wget \
&& ... \
&& apt-get purge -y wget \
&& rm -r a-build-dir \
&& apt-get purge -y a-package
নোট করুন যে কমান্ড শৃঙ্খলার অতিরিক্ত ব্যবহার আপনার বিল্ডগুলি ধীর করতে পারে যেহেতু আপনাকে পূর্বনির্ধারিত পরিবর্তনগুলি (যেমন কোডটি উইজেটের সাথে টানা হচ্ছে) যে কোনও সময় একই সরঞ্জাম সেটটি পুনরায় ইনস্টল করতে হবে। আরও ভাল বিকল্পের জন্য নীচে মাল্টি-স্টেজটি দেখুন।
আপনার ফলাফল তৈরি করা যে চিত্রটির দরকার নেই সেগুলি তৈরি করুন এমন পদক্ষেপে মোছা উচিত। এর মধ্যে প্যাকেজ ক্যাশে, লগস, ম্যান পৃষ্ঠা, ইত্যাদি অন্তর্ভুক্ত রয়েছে প্রতিটি স্তরে কোন ফাইলগুলি তৈরি হচ্ছে তা আবিষ্কার করতে আপনি ওয়াগুডম্যান / ডাইভের মতো একটি সরঞ্জাম ব্যবহার করতে পারেন (যা আমি ব্যক্তিগতভাবে নিরীক্ষণ করি নি এবং সাবধানতা প্রকাশ করব যেহেতু এটি সম্পূর্ণ রুট অ্যাক্সেসের সাথে চালিত হয়) আপনার হোস্টে) বা আপনি মাঝারি পাত্রে ছাঁটাই ছাড়াই আপনার ডকারের চিত্রগুলি তৈরি করতে পারেন এবং তারপরে ভিন্নতাটি দেখতে পারেন:
# first create and leave containers from any RUN step using options on build
docker image build --rm=false --no-cache -t image_name .
# review which layers use an unexpectedly large amount of space
docker image history image_name
# list all containers, particularly the exited ones from above
docker container ps -a
# examine any of those containers
docker container diff ${container_id}
# ... repeat the diff for other build steps
# then cleanup exited containers
docker container prune
সেই অন্তর্বর্তী পাত্রে প্রতিটি সঙ্গে, পরিবর্তন দেখাবে কি ফাইল, যোগ পরিবর্তন, বা যে ধাপে মুছে ফেলা হয় (এই একটি সঙ্গে ব্যবহৃত হয় A, Cঅথবা Dপ্রতিটি ফাইলের নাম আগে)। পার্থক্যটি যা দেখায় তা হ'ল কনটেইনার নির্দিষ্ট পঠন / লেখার ফাইল সিস্টেম, যা অনুলিপি দ্বারা অনুলিপি ব্যবহার করে চিত্র রাষ্ট্র থেকে ধারক দ্বারা পরিবর্তিত কোনও ফাইল।
চিত্রের আকার হ্রাস করার সর্বোত্তম উপায় হ'ল আপনার পাঠানো চিত্র থেকে কোনও অপ্রয়োজনীয় উপাদান যেমন সংকলককে মুছে ফেলা। তার জন্য, মাল্টি-স্টেজ বিল্ডগুলি আপনাকে একটি পর্যায়ে সংকলন করতে দেয় এবং তারপরে কেবল বিল্ড স্টেজ থেকে একটি রানটাইম চিত্রে ফলাফল প্রাপ্ত শৈল্পিকাগুলি অনুলিপি করে যার অ্যাপ্লিকেশনটি চালানোর জন্য কেবল সর্বনিম্ন প্রয়োজনীয় needed এটি ফলাফলের চিত্রের সাথে প্রেরণ না করায় যে কোনও বিল্ড পদক্ষেপের অনুকূলকরণের প্রয়োজনীয়তা এড়িয়ে যায়।
FROM debian:9 as build
# still chain update with install to prevent stale cache issues
RUN apt-get update \
&& apt-get install -y \
a-package \
wget \
RUN ... # perform any download/compile steps
FROM debian:9-slim as release
COPY --from=build /usr/local/bin/app /usr/local/bin/app
CMD [ "/usr/local/bin/app" ]
স্ট্যাটিকালি সংকলিত বাইনারিগুলির সাথে মাল্টি-স্টেজ আদর্শ, যা আপনি আপনার বেস ইমেজ হিসাবে স্ক্র্যাচ দিয়ে চালাতে পারেন, বা জেডিকে-র মতো একটি সংকলন পরিবেশ থেকে জেআরই-এর মতো রানটাইমে স্থানান্তরিত করতে পারেন। এটি দ্রুত নির্মাণের সময় নাটকীয়ভাবে আপনার চিত্রের আকার হ্রাস করার সবচেয়ে সহজ উপায়। আপনি এখনও আপনার রিলিজ পর্যায়ে পদক্ষেপের শৃঙ্খলা সম্পাদন করতে পারেন যদি আপনার পূর্ববর্তী ধাপগুলিতে তৈরি ফাইলগুলি পরিবর্তন বা মুছে ফেলা পদক্ষেপ থাকে তবে বেশিরভাগ অংশের জন্য, COPYঅন্য স্তরের পূর্ববর্তী বিল্ড পর্যায়ে অভিজ্ঞ যে কোনও স্তর ফোলা থেকে মুক্তি পর্বটি বিচ্ছিন্ন করে।
দ্রষ্টব্য, আমি চিত্রগুলি স্কোয়াশ করার পরামর্শ দিচ্ছি না কারণ এটি স্তর পুনরায় ব্যবহারের ব্যয় করে এক চিত্রের আকার হ্রাস করে। এর অর্থ ভবিষ্যতে একই চিত্রের বিল্ডগুলিতে আপডেটগুলি প্রেরণের জন্য আরও বেশি ডিস্ক এবং নেটওয়ার্ক ট্র্যাফিকের প্রয়োজন হবে। প্রথম উদাহরণে ফিরে যেতে স্কোয়াশ করা আপনার চিত্রটি 2 জিবি থেকে 1 জিবি কমাতে পারে তবে 3 টি চিত্র নয় তবে 2.1 গিগাবাইটের পরিবর্তে 3 জিবি নিতে পারে।
2.37বনাম1.47 GB