ওয়ার্ফে মনোরেপো এবং মাল্টিরেপোর জন্য সমর্থন এবং ডকার রেজিস্ট্রি এর সাথে কী করতে হবে

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

werf-এ সম্প্রতি যুক্ত হওয়া mono-repo সাপোর্ট এর একটি ভালো উদাহরণ। কিন্তু প্রথমে, চলুন জেনে নেওয়া যাক এই সাপোর্টটি werf ব্যবহারের সাথে কীভাবে সম্পর্কিত এবং এর সাথে Docker Registry-র কী সম্পর্ক…

সমস্যাযুক্ত

আসুন এই পরিস্থিতিটি কল্পনা করি। একটি কোম্পানিতে একাধিক ডেভেলপমেন্ট টিম রয়েছে যারা স্বাধীন প্রকল্পে কাজ করছে। বেশিরভাগ অ্যাপ্লিকেশন কুবারনেটিসে চলে এবং তাই কন্টেইনারাইজড। কন্টেইনার এবং ইমেজ সংরক্ষণের জন্য একটি রেজিস্ট্রি প্রয়োজন। কোম্পানিটি একটিমাত্র অ্যাকাউন্ট দিয়ে তার রেজিস্ট্রি হিসেবে ডকার হাব ব্যবহার করে। COMPANYবেশিরভাগ সোর্স কোড সংরক্ষণ ব্যবস্থার মতোই, ডকার হাব নেস্টেড রিপোজিটরি হায়ারার্কি অনুমোদন করে না।যেমন COMPANY/PROJECT/IMAGEসেক্ষেত্রে... প্রতিটি প্রজেক্টের জন্য আলাদা অ্যাকাউন্ট তৈরি না করে, এই সীমাবদ্ধতা মেনে আমরা কীভাবে রেজিস্ট্রি-তে নন-মনোলিথিক অ্যাপ্লিকেশনগুলো সংরক্ষণ করতে পারি?

এই পরিস্থিতিটি কারও কারও কাছে পরিচিত হতে পারে, কিন্তু আসুন উপরের উদাহরণ এবং ডকার হাবের উল্লেখ না করে সাধারণভাবে অ্যাপ্লিকেশন স্টোরেজ সংগঠিত করার বিষয়টি দেখি।

সমাধান

যদি আবেদনটি এককভাবেযদি একটি একক ইমেজ হিসেবে সরবরাহ করা হয়, তাহলে কোনো প্রশ্ন ওঠে না এবং আমরা সরাসরি ইমেজগুলো প্রজেক্টের কন্টেইনার রেজিস্ট্রি-তে সেভ করে দিই।

যখন একটি অ্যাপ্লিকেশন একাধিক উপাদান হিসাবে উপস্থাপন করা হয়, মাইক্রো সার্ভিসতাহলে একটি নির্দিষ্ট পদ্ধতি বেছে নিতে হবে। দুটি ছবি নিয়ে গঠিত একটি সাধারণ ওয়েব অ্যাপ্লিকেশনের উদাহরণ ব্যবহার করে বলা যায়: frontend и backend সম্ভাব্য বিকল্পগুলো হলো:

1. ছবিগুলো আলাদা নেস্টেড রিপোজিটরিতে সংরক্ষণ করুন:

   

2. সবকিছু একটি রিপোজিটরিতে সংরক্ষণ করুন, এবং ট্যাগের মধ্যে ছবির নামটি অন্তর্ভুক্ত করুন, উদাহরণস্বরূপ, এইভাবে:

   

NBআসলে, বিভিন্ন রিপোজিটরিতে সংরক্ষণ করার আরেকটি বিকল্পও রয়েছে, PROJECT-frontend и PROJECT-backendকিন্তু সহায়তা, সংগঠন এবং ব্যবহারকারীদের মধ্যে অধিকার বণ্টনের জটিলতার কারণে আমরা এটি বিবেচনা করব না।

ওয়ার্ফে সমর্থন

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

বাস্তবায়ন একটি বিকল্প হিসাবে উপলব্ধ। --images-repo-mode=multirepo|monorepo (ডিফল্টরূপে) multirepo(অর্থাৎ, নেস্টেড রিপোজিটরিতে সংরক্ষণ করা)। এটি সেই টেমপ্লেটগুলো নির্ধারণ করে, যার মাধ্যমে রেজিস্ট্রি-তে ইমেজগুলো সংরক্ষিত হয়। বেসিক কমান্ডগুলো ব্যবহার করার সময় কেবল কাঙ্ক্ষিত মোডটি নির্বাচন করুন, এবং বাকি সবকিছু অপরিবর্তিত থাকবে।

যেহেতু বেশিরভাগ ওয়ার্ফ বিকল্প সেট করা যেতে পারে পরিবেশগত ভেরিয়েবলCI/CD সিস্টেমে, সাধারণত পুরো প্রোজেক্টের জন্য স্টোরেজ মোড বিশ্বব্যাপী সহজেই সেট করা যায়। উদাহরণস্বরূপ, গিটল্যাবের ক্ষেত্রে প্রজেক্ট সেটিংসে একটি এনভায়রনমেন্ট ভেরিয়েবল যোগ করাই যথেষ্ট: সেটিংস -> সিআই / সিডি -> ভেরিয়েবল: WERF_IMAGES_REPO_MODE: multirepo|monorepo.

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

শয়তান বিস্তারিত আছে

নতুন স্টোরেজ পদ্ধতি যোগ করার ক্ষেত্রে পার্থক্য এবং প্রধান অসুবিধাটি হলো রেজিস্ট্রি পরিষ্কার করার প্রক্রিয়া। (werf দ্বারা সমর্থিত পরিষ্কার করার ক্ষমতা সম্পর্কে জানতে, দেখুন) পরিষ্কারের প্রক্রিয়া).

পরিষ্কার করার সময়, werf কুবারনেটিস ক্লাস্টারে ব্যবহৃত ইমেজ এবং ব্যবহারকারী-কনফিগার করা পলিসিগুলো বিবেচনা করে। পলিসিগুলো ট্যাগগুলোকে বিভিন্ন স্ট্র্যাটেজিতে ভাগ করার উপর ভিত্তি করে তৈরি হয়। বর্তমানে সমর্থিত স্ট্র্যাটেজিগুলো হলো:

1. গিট-এর ট্যাগ, ব্রাঞ্চ এবং কমিট-এর মতো মৌলিক উপাদান সম্পর্কিত ৩টি কৌশল;
2. কাস্টম ট্যাগের জন্য ১টি কৌশল।

একটি ছবি প্রকাশ করার সময় আমরা চূড়ান্ত ছবির লেবেলে ট্যাগ কৌশল সম্পর্কিত তথ্য সংরক্ষণ করি। মানটি নিজেই তথাকথিত মেটা ট্যাগ কিছু নীতি প্রয়োগের জন্য এটি প্রয়োজনীয়। উদাহরণস্বরূপ, একটি গিট রিপোজিটরি থেকে কোনো ব্রাঞ্চ বা ট্যাগ ডিলিট করার সময়, এর সাথে যুক্তগুলোও ডিলিট করে দেওয়া যুক্তিযুক্ত। অব্যবহৃত রেজিস্ট্রি থেকে প্রাপ্ত ছবি, যা আমাদের নীতিমালার একটি অংশ।

একটি রিপোজিটরিতে সংরক্ষণ করার সময় (monorepoমেটা ট্যাগের পাশাপাশি, ইমেজ ট্যাগে ছবির নামও সংরক্ষণ করা যায়: PROJECT:frontend-META-TAGসেগুলোকে আলাদা করার জন্য আমরা কোনো নির্দিষ্ট বিভাজক ব্যবহার করিনি, বরং প্রকাশের সময় চূড়ান্ত ছবির লেবেলে প্রয়োজনীয় মানটি যোগ করে দিয়েছি।

NBআপনি যদি werf সোর্স কোডে বর্ণিত সবকিছু দেখতে আগ্রহী হন, তাহলে একটি সূচনা বিন্দু হতে পারে জনসংযোগ 1684.

এই প্রবন্ধে আমরা আমাদের পদ্ধতির সমস্যা ও যৌক্তিকতার উপর আর বেশি মনোযোগ দেব না: ট্যাগিং কৌশল, লেবেলে ডেটা সংরক্ষণ এবং সাধারণভাবে প্রকাশনা প্রক্রিয়া - এই সমস্ত কিছু দিমিত্রি স্তোলিয়ারভের একটি সাম্প্রতিক প্রতিবেদনে বিশদভাবে বর্ণনা করা হয়েছে: “werf হল Kubernetes-এ CI/CD-এর জন্য আমাদের টুল».

সংক্ষিপ্তসার

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

আমাদের সাথেই থাকুন এবং আমরা অদূর ভবিষ্যতে অন্যান্য উদ্ভাবন সম্পর্কে আপনাদের জানাবো। werf!

দ্রষ্টব্য

আমাদের ব্লগেও পড়ুন:

• «আপনি এখন নিয়মিত ডকারফাইল ব্যবহার করে ডকার ইমেজ তৈরি করতে পারেন";
• «werf - Kubernetes-এ CI/CD-এর জন্য আমাদের টুল (ওভারভিউ এবং ভিডিও রিপোর্ট)».

উত্স: www.habr.com