আপনি এখন নিয়মিত ডকারফাইল ব্যবহার করে ডকার ইমেজ তৈরি করতে পারেন

কখনও না চেয়ে দেরি করা ভাল। অথবা কীভাবে আমরা অ্যাপ্লিকেশন ইমেজ তৈরি করতে নিয়মিত ডকারফাইলের সমর্থন না পেয়ে প্রায় একটি গুরুতর ভুল করেছি।

এটা সম্পর্কে হবে werf — একটি GitOps ইউটিলিটি যা যেকোনো CI/CD সিস্টেমের সাথে সংহত করে এবং সমগ্র অ্যাপ্লিকেশনের জীবনচক্র পরিচালনা করে, আপনাকে অনুমতি দেয়:

• ছবি সংগ্রহ এবং প্রকাশ করা,
• কুবারনেটসে অ্যাপ্লিকেশন স্থাপন করুন,
• বিশেষ নীতি ব্যবহার করে অব্যবহৃত ছবি মুছে দিন।

প্রকল্পের দর্শন হল একটি একক ইউনিফাইড সিস্টেমে নিম্ন-স্তরের সরঞ্জামগুলি সংগ্রহ করা যা DevOps ইঞ্জিনিয়ারদের অ্যাপ্লিকেশনগুলির উপর নিয়ন্ত্রণ দেয়। যদি সম্ভব হয়, বিদ্যমান ইউটিলিটিগুলি (যেমন হেলম এবং ডকার) ব্যবহার করা উচিত। যদি কোনো সমস্যার কোনো সমাধান না হয়, তাহলে আমরা এর জন্য প্রয়োজনীয় সবকিছু তৈরি ও বজায় রাখতে পারি।

পটভূমি: আপনার নিজের ছবি সংগ্রাহক

ওয়ার্ফের ইমেজ নির্মাতার সাথে এটি ঘটেছিল: আমাদের সাধারণ ডকারফাইলের অভাব ছিল। আপনি যদি সংক্ষিপ্তভাবে প্রকল্পের ইতিহাসে ডুবে যান, তবে এই সমস্যাটি ইতিমধ্যেই ওয়ার্ফের প্রথম সংস্করণগুলিতে নিজেকে প্রকাশ করেছে (তারপর ড্যাপ নামে পরিচিত).

ডকার ইমেজে অ্যাপ্লিকেশন তৈরি করার জন্য একটি টুল তৈরি করার সময়, আমরা দ্রুত বুঝতে পেরেছি যে ডকারফাইল কিছু নির্দিষ্ট কাজের জন্য আমাদের জন্য উপযুক্ত নয়:

1. নিম্নলিখিত স্ট্যান্ডার্ড স্কিম অনুসারে সাধারণ ছোট ওয়েব অ্যাপ্লিকেশনগুলিকে একত্রিত করার প্রয়োজন:
   • অ্যাপ্লিকেশনটির সিস্টেম-ব্যাপী নির্ভরতা ইনস্টল করুন,
   • অ্যাপ্লিকেশন নির্ভরতা লাইব্রেরির একটি বান্ডিল ইনস্টল করুন,
   • সম্পদ সংগ্রহ করা,
   • এবং সবচেয়ে গুরুত্বপূর্ণভাবে, ইমেজে কোডটি দ্রুত এবং দক্ষতার সাথে আপডেট করুন।
2. প্রজেক্ট ফাইলগুলিতে পরিবর্তন করা হলে, বিল্ডারকে অবশ্যই পরিবর্তিত ফাইলগুলি প্যাচ করে একটি নতুন স্তর তৈরি করতে হবে।
3. যদি নির্দিষ্ট ফাইল পরিবর্তিত হয়, তাহলে সংশ্লিষ্ট নির্ভরশীল পর্যায়টি পুনর্নির্মাণ করতে হবে।

আজ, আমাদের কলে আরও অনেক সম্ভাবনা রয়েছে, তবে প্রাথমিক ইচ্ছা এবং তাগিদগুলি নিম্নরূপ ছিল।

সাধারণভাবে, দুবার চিন্তা না করে, আমরা ব্যবহৃত প্রোগ্রামিং ভাষা দিয়ে নিজেদের সজ্জিত করি (নিচে দেখ) এবং রাস্তা আঘাত - বাস্তবায়ন নিজস্ব ডিএসএল! টাস্ক সেট অনুসারে, এটির উদ্দেশ্য ছিল বিল্ড প্রক্রিয়াটি পর্যায়ক্রমে বর্ণনা করা এবং ফাইলগুলিতে এই পর্যায়ের নির্ভরতা নির্ধারণ করা। এবং এটি পরিপূরক নিজস্ব কল, যা ডিএসএলকে চূড়ান্ত গোলে পরিণত করেছে - একত্রিত চিত্র। প্রথমে ডিএসএল রুবিতে ছিল, কিন্তু হিসাবে গোলং এ স্যুইচ করা হচ্ছে - আমাদের সংগ্রাহকের কনফিগারেশন YAML ফাইলে বর্ণনা করা শুরু হয়েছে।

রুবিতে ড্যাপের জন্য পুরানো কনফিগারেশন

YAML-এ werf-এর জন্য প্রকৃত কনফিগারেশন

কালেক্টরের মেকানিজমও সময়ের সাথে পরিবর্তিত হয়। প্রথমে, আমরা ফ্লাইতে আমাদের কনফিগারেশন থেকে কিছু অস্থায়ী ডকারফাইল তৈরি করেছিলাম এবং তারপরে আমরা অস্থায়ী পাত্রে বিল্ড নির্দেশাবলী চালাতে শুরু করি এবং একটি প্রতিশ্রুতি তৈরি করি।

NB: এই মুহুর্তে, আমাদের বিল্ডার, যেটি তার নিজস্ব কনফিগারেশনের সাথে কাজ করে (YAML-এ) এবং যাকে বলা হয় স্টেপেল বিল্ডার, ইতিমধ্যেই একটি মোটামুটি শক্তিশালী টুলে বিকশিত হয়েছে৷ এর বিশদ বিবরণ পৃথক নিবন্ধের যোগ্য, এবং মূল বিবরণ পাওয়া যাবে ডকুমেন্টেশন.

সমস্যার সচেতনতা

কিন্তু আমরা বুঝতে পেরেছি, এবং অবিলম্বে নয়, আমরা একটি ভুল করেছি: আমরা ক্ষমতা যোগ করিনি একটি স্ট্যান্ডার্ড ডকারফাইলের মাধ্যমে ছবি তৈরি করুন এবং সেগুলিকে একই এন্ড-টু-এন্ড অ্যাপ্লিকেশন ম্যানেজমেন্ট অবকাঠামোতে একীভূত করুন (যেমন ছবি সংগ্রহ করুন, স্থাপন করুন এবং পরিষ্কার করুন)। আপনি কীভাবে কুবারনেটসে একটি স্থাপনার সরঞ্জাম তৈরি করতে পারেন এবং ডকারফাইল সমর্থন বাস্তবায়ন করতে পারবেন না, যেমন বেশিরভাগ প্রকল্পের জন্য চিত্রগুলি বর্ণনা করার একটি আদর্শ উপায়? ..

এই ধরনের প্রশ্নের উত্তর না দিয়ে আমরা এর সমাধান দিই। আপনার যদি ইতিমধ্যেই একটি ডকারফাইল (বা ডকারফাইলের একটি সেট) থাকে এবং আপনি ওয়ার্ফ ব্যবহার করতে চান তবে কী করবেন?

NB: যাইহোক, কেন আপনি এমনকি werf ব্যবহার করতে চান? প্রধান বৈশিষ্ট্যগুলি নিম্নলিখিতগুলিতে ফোটে:

• ক্লিনিং ইমেজ সহ সম্পূর্ণ অ্যাপ্লিকেশন ব্যবস্থাপনা চক্র;
• একটি একক কনফিগারেশন থেকে একসাথে বেশ কয়েকটি চিত্রের সমাবেশ পরিচালনা করার ক্ষমতা;
• হেলম সামঞ্জস্যপূর্ণ চার্টের জন্য উন্নত স্থাপনার প্রক্রিয়া।

একটি আরো সম্পূর্ণ তালিকা পাওয়া যাবে প্রকল্প পাতা.

সুতরাং, যদি আগে আমরা আমাদের কনফিগারে ডকারফাইলটি পুনরায় লেখার পরামর্শ দিই, এখন আমরা বলতে পেরে খুশি: "আসুন আপনার ডকারফাইলগুলি তৈরি করুন!"

কিভাবে ব্যবহার করবেন?

এই বৈশিষ্ট্যটির সম্পূর্ণ বাস্তবায়ন রিলিজে উপস্থিত হয়েছিল werf v1.0.3-beta.1. সাধারণ নীতিটি সহজ: ব্যবহারকারী ওয়ার্ফ কনফিগারেশনে বিদ্যমান ডকারফাইলের পথটি নির্দিষ্ট করে এবং তারপর কমান্ডটি চালায় werf build... এবং এটাই - ওয়ার্ফ ছবিটি তৈরি করবে। আসুন একটি বিমূর্ত উদাহরণ বিবেচনা করা যাক।

এর পরের ঘোষণা করা যাক Dockerfile প্রকল্পের মূলে:

FROM ubuntu:18.04
RUN echo Building ...

এবং আমরা ঘোষণা করব werf.yamlযা এই ব্যবহার করে Dockerfile:

configVersion: 1
project: dockerfile-example
---
image: ~
dockerfile: ./Dockerfile

সমস্ত ! বাম চালান werf build:

উপরন্তু, আপনি নিম্নলিখিত ঘোষণা করতে পারেন werf.yaml বিভিন্ন ডকারফাইল থেকে একসাথে বেশ কয়েকটি ছবি তৈরি করতে:

configVersion: 1
project: dockerfile-example
---
image: backend
dockerfile: ./dockerfiles/Dockerfile-backend
---
image: frontend
dockerfile: ./dockerfiles/Dockerfile-frontend

অবশেষে, অতিরিক্ত বিল্ড প্যারামিটার পাস করাও সমর্থিত - যেমন --build-arg и --add-host - werf কনফিগারেশনের মাধ্যমে। ডকারফাইল ইমেজ কনফিগারেশনের একটি সম্পূর্ণ বিবরণ পাওয়া যায় ডকুমেন্টেশন পৃষ্ঠা.

এটা কিভাবে কাজ করে?

বিল্ড প্রক্রিয়া চলাকালীন, ডকার ফাংশনে স্থানীয় স্তরগুলির স্ট্যান্ডার্ড ক্যাশে কাজ করে। যাইহোক, গুরুত্বপূর্ণভাবে, এছাড়াও werf ডকারফাইল কনফিগারেশনকে এর পরিকাঠামোতে সংহত করে. এটার মানে কি?

1. একটি ডকারফাইল থেকে নির্মিত প্রতিটি চিত্র একটি একক পর্যায় নিয়ে গঠিত dockerfile (Werf-এ কোন ধাপ রয়েছে সে সম্পর্কে আরও, আপনি পড়তে পারেন এখানে).
2. মঞ্চের জন্য dockerfile werf একটি স্বাক্ষর গণনা করে যা ডকারফাইল কনফিগারেশনের বিষয়বস্তুর উপর নির্ভর করে। ডকারফাইল কনফিগারেশন পরিবর্তন করা স্টেজ স্বাক্ষর পরিবর্তন করে dockerfile এবং werf নতুন ডকারফাইল কনফিগারেশনের সাথে সেই পর্যায়ের পুনর্নির্মাণ শুরু করবে। যদি স্বাক্ষর পরিবর্তন না হয়, তাহলে werf ক্যাশে থেকে ছবিটি নেয় (ওয়ার্ফে স্বাক্ষরের ব্যবহার সম্পর্কে আরও বর্ণনা করা হয়েছে এই প্রতিবেদন).
3. উপরন্তু, সংগৃহীত ছবি কমান্ড দিয়ে প্রকাশ করা যেতে পারে werf publish (বা werf build-and-publish) এবং এটি কুবারনেটে স্থাপন করতে ব্যবহার করুন। ডকার রেজিস্ট্রিতে প্রকাশিত ছবিগুলি স্ট্যান্ডার্ড ওয়ার্ফ ক্লিনআপ টুল দিয়ে পরিষ্কার করা হবে, যেমন পুরানো ছবিগুলির একটি স্বয়ংক্রিয় ক্লিনআপ থাকবে (N দিনের বেশি পুরানো), অ-অস্তিত্বশীল গিট শাখাগুলির সাথে যুক্ত ছবি এবং অন্যান্য নীতি৷

এখানে বর্ণিত পয়েন্ট সম্পর্কে আরও বিশদ ডকুমেন্টেশনে পাওয়া যাবে:

• প্রকাশনার প্রক্রিয়া;
• Kubernetes এ স্থাপনার প্রক্রিয়ার সাথে একীকরণ;
• পরিষ্কারের প্রক্রিয়া.

নোট এবং সতর্কতা

1. ADD-এ বাহ্যিক URL সমর্থিত নয়৷

একটি নির্দেশে একটি বহিরাগত URL এর ব্যবহার বর্তমানে সমর্থিত নয়৷ ADD. নির্দিষ্ট URL-এ কোনো সংস্থান পরিবর্তিত হলে Werf একটি পুনর্নির্মাণ ট্রিগার করবে না। এই বৈশিষ্ট্যটি শীঘ্রই যুক্ত করার পরিকল্পনা করা হয়েছে।

2. আপনি একটি ছবিতে .git যোগ করতে পারবেন না

সাধারণভাবে বলতে গেলে, একটি ডিরেক্টরি যোগ করা .git একটি চিত্রের মধ্যে একটি খারাপ অভ্যাস, এবং এখানে কেন:

1. যদি .git চূড়ান্ত চিত্রে থাকে, এটি নীতি লঙ্ঘন করে 12 ফ্যাক্টর অ্যাপ: যেহেতু ফলস্বরূপ চিত্রটি একটি একক প্রতিশ্রুতির সাথে যুক্ত হতে হবে, এটি করা সম্ভব নয় git checkout নির্বিচারে প্রতিশ্রুতি
2. .git চিত্রের আকার বৃদ্ধি করে (ভান্ডারটি বড় হতে পারে কারণ এটিতে একবার বড় ফাইল যুক্ত করা হয়েছিল এবং তারপর মুছে ফেলা হয়েছিল)। শুধুমাত্র একটি নির্দিষ্ট প্রতিশ্রুতির সাথে যুক্ত ওয়ার্ক-ট্রির আকার গিট-এ অপারেশনের ইতিহাসের উপর নির্ভর করবে না। এই ক্ষেত্রে, সংযোজন এবং পরবর্তী অপসারণ .git চূড়ান্ত চিত্র থেকে কাজ করবে না: চিত্রটি এখনও একটি অতিরিক্ত স্তর অর্জন করবে - এইভাবে ডকার কাজ করে।
3. ডকার একটি অপ্রয়োজনীয় পুনর্নির্মাণকে ট্রিগার করতে পারে এমনকি যদি একই প্রতিশ্রুতি বিভিন্ন কাজের গাছ থেকে তৈরি করা হয়। উদাহরণস্বরূপ, গিটল্যাব আলাদা ক্লোন ডিরেক্টরি তৈরি করে /home/gitlab-runner/builds/HASH/[0-N]/yourproject সমান্তরাল সমাবেশ সক্রিয় সঙ্গে. একটি অতিরিক্ত পুনঃনির্মাণ সত্য যে ডিরেক্টরির কারণে হবে .git একই সংগ্রহস্থলের বিভিন্ন ক্লোন সংস্করণে ভিন্ন, এমনকি একই প্রতিশ্রুতি নির্মিত হলেও।

werf ব্যবহার করার সময় শেষ বিন্দুরও ফলাফল রয়েছে। কিছু কমান্ড চালানোর সময় Werf-এর জন্য নির্মিত ক্যাশে উপস্থিত থাকা প্রয়োজন (উদাহরণস্বরূপ, werf deploy) এই ধরনের কমান্ড কার্যকর করার সময়, werf নির্দিষ্ট চিত্রগুলির জন্য স্টেজ স্বাক্ষর গণনা করে werf.yaml, এবং সেগুলি অবশ্যই বিল্ড ক্যাশে থাকতে হবে, অন্যথায় কমান্ডটি চালিয়ে যেতে সক্ষম হবে না। যদি পর্যায়গুলির স্বাক্ষর বিষয়বস্তুর উপর নির্ভর করে .git, তারপরে আমরা একটি ক্যাশে পাই যা অপ্রাসঙ্গিক ফাইলগুলিতে পরিবর্তনের জন্য অস্থির, এবং werf এই ধরনের নজরদারি ক্ষমা করতে সক্ষম হবে না (আরো বিশদ বিবরণের জন্য, দেখুন ডকুমেন্টেশন).

সামগ্রিক শুধুমাত্র কিছু প্রয়োজনীয় ফাইল যোগ করা নির্দেশের মাধ্যমে ADD যে কোন ক্ষেত্রে লিখিত দক্ষতা এবং নির্ভরযোগ্যতা বৃদ্ধি Dockerfile, এবং এটি দ্বারা সংগৃহীত ক্যাশের স্থায়িত্ব উন্নত করে Dockerfile, Git-এ অপ্রাসঙ্গিক পরিবর্তনের জন্য।

ফলাফল

নির্দিষ্ট প্রয়োজনের জন্য আমাদের নিজস্ব নির্মাতা লেখার সাথে আমাদের প্রাথমিক পথটি কঠিন, সৎ এবং সোজা ছিল: স্ট্যান্ডার্ড ডকারফাইলের উপরে ক্রাচ ব্যবহার করার পরিবর্তে, আমরা কাস্টম সিনট্যাক্সের সাথে আমাদের নিজস্ব সমাধান লিখেছিলাম। এবং এটি এর সুবিধা দিয়েছে: স্ট্যাপেল-সংগ্রাহক তার কাজটি পুরোপুরি করে।

যাইহোক, আমাদের নিজস্ব নির্মাতা লেখার প্রক্রিয়ায়, আমরা ইতিমধ্যে বিদ্যমান ডকারফাইলগুলির জন্য সমর্থনের দৃষ্টিশক্তি হারিয়ে ফেলেছি। এখন এই ঘাটতি ঠিক করা হয়েছে, এবং ভবিষ্যতে আমরা বিতরণ করা বিল্ডের জন্য এবং Kubernetes ব্যবহার করে নির্মাণের জন্য আমাদের কাস্টম স্ট্যাপেল বিল্ডারের সাথে ডকারফাইল সমর্থন বিকাশ করার পরিকল্পনা করছি (অর্থাৎ কুবারনেটসের ভিতরে দৌড়বিদদের উপর তৈরি করা, যেমনটি কানিকোতে করা হয়)।

সুতরাং, যদি হঠাৎ আপনার চারপাশে কয়েকটি ডকারফাইল পড়ে থাকে ... চেষ্টা werf!

PS বিষয়ে ডকুমেন্টেশন তালিকা

• দ্রুত শুরু নির্দেশিকা;
• ডকারফাইল বিল্ডার কনফিগারেশন;
• পর্যায় ডিভাইস werf;
• ছবি প্রকাশের প্রক্রিয়া;
• Kubernetes এ স্থাপনার প্রক্রিয়ার সাথে একীকরণ;
• পরিষ্কারের প্রক্রিয়া;
• ডকারফাইলের বিকল্প হিসাবে স্ট্যাপেল নির্মাতা.

আমাদের ব্লগেও পড়ুন:werf - Kubernetes-এ CI/CD-এর জন্য আমাদের টুল (ওভারভিউ এবং ভিডিও রিপোর্ট)».

উত্স: www.habr.com