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

উৎসবের অংশ হিসেবে অনুষ্ঠিত DevOpsConf 27 সম্মেলনের মূল হলে 2019 মে RIT++ 2019, "কন্টিনিউয়াস ডেলিভারি" বিভাগের অংশ হিসাবে, একটি রিপোর্ট দেওয়া হয়েছে "werf - কুবারনেটে CI/CD এর জন্য আমাদের টুল"। এটা সেসব নিয়ে কথা বলে কুবারনেটসে মোতায়েন করার সময় যে সকল সমস্যা এবং চ্যালেঞ্জের সম্মুখীন হয়, সেইসাথে সূক্ষ্মতা সম্পর্কে যা অবিলম্বে লক্ষণীয় নাও হতে পারে। সম্ভাব্য সমাধান বিশ্লেষণ করে, আমরা দেখাই কিভাবে এটি একটি ওপেন সোর্স টুলে প্রয়োগ করা হয় werf.

উপস্থাপনার পর থেকে, আমাদের ইউটিলিটি (পূর্বে একটি ড্যাপ নামে পরিচিত) এর একটি ঐতিহাসিক মাইলফলক ছুঁয়েছে GitHub-এ 1000 তারা — আমরা আশা করি যে এর ব্যবহারকারীদের ক্রমবর্ধমান সম্প্রদায় অনেক DevOps ইঞ্জিনিয়ারদের জীবনকে সহজ করে তুলবে।

সুতরাং, আমরা উপস্থাপন প্রতিবেদনের ভিডিও (~47 মিনিট, নিবন্ধের চেয়ে অনেক বেশি তথ্যপূর্ণ) এবং পাঠ্য আকারে এটি থেকে মূল নির্যাস। যাওয়া!

কুবারনেটসকে কোড প্রদান করা হচ্ছে

আলোচনাটি আর ওয়ার্ফ সম্পর্কে নয়, কুবারনেটসে সিআই/সিডি সম্পর্কে হবে, যা বোঝায় যে আমাদের সফ্টওয়্যার ডকার পাত্রে প্যাকেজ করা হয়েছে (আমি এই বিষয়ে কথা বলেছি 2016 রিপোর্ট), এবং K8s এটি উৎপাদনে চালানোর জন্য ব্যবহার করা হবে (এ সম্পর্কে আরও 2017 বছর).

কুবারনেটসে ডেলিভারি কেমন দেখায়?

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

এখানে কয়েকটি গুরুত্বপূর্ণ নোট রয়েছে:

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

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

মঞ্চ তৈরি করুন

দেখে মনে হবে আপনি 2019 সালে ডকার ইমেজ তৈরির বিষয়ে কথা বলতে পারেন, যখন সবাই জানে কিভাবে ডকারফাইলস লিখতে হয় এবং চালাতে হয় docker build?.. এখানে আমি মনোযোগ দিতে চাই যে সূক্ষ্মতা আছে:

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

এটি ছিল আইসবার্গের টিপ যা প্রত্যেকের মুখোমুখি হয়। কিন্তু অন্যান্য সমস্যা আছে, বিশেষ করে:

1. প্রায়ই সমাবেশ পর্যায়ে আমরা কিছু প্রয়োজন মাউন্ট (উদাহরণস্বরূপ, তৃতীয় পক্ষের ডিরেক্টরিতে apt-এর মতো কমান্ডের ফলাফল ক্যাশে করুন)।
2. আমরা চাই Ansible শেলে লেখার পরিবর্তে।
3. আমরা চাই ডকার ছাড়া নির্মাণ (কেন আমাদের একটি অতিরিক্ত ভার্চুয়াল মেশিনের প্রয়োজন যেখানে আমাদের এর জন্য সবকিছু কনফিগার করতে হবে, যখন আমাদের ইতিমধ্যে একটি কুবারনেটস ক্লাস্টার রয়েছে যেখানে আমরা কন্টেইনার চালাতে পারি?)
4. সমান্তরাল সমাবেশ, যা বিভিন্ন উপায়ে বোঝা যায়: ডকারফাইল থেকে বিভিন্ন কমান্ড (যদি মাল্টি-স্টেজ ব্যবহার করা হয়), একই রিপোজিটরির একাধিক কমিট, বেশ কয়েকটি ডকারফাইল।
5. বিতরণ সমাবেশ: আমরা শুঁটি জিনিসপত্র সংগ্রহ করতে চাই যেগুলি "ক্ষণস্থায়ী" কারণ তাদের ক্যাশে অদৃশ্য হয়ে যায়, যার মানে এটি আলাদাভাবে কোথাও সংরক্ষণ করা প্রয়োজন।
6. অবশেষে, আমি ইচ্ছার শীর্ষের নাম দিলাম স্বয়ংক্রিয়: রিপোজিটরিতে যাওয়া, কিছু কমান্ড টাইপ করা এবং কীভাবে এবং কী সঠিকভাবে করতে হবে তা বোঝার সাথে একত্রিত একটি রেডিমেড চিত্র পাওয়া আদর্শ হবে। যাইহোক, আমি ব্যক্তিগতভাবে নিশ্চিত নই যে সমস্ত সূক্ষ্মতা এইভাবে পূর্বাভাস করা যেতে পারে।

এবং এখানে প্রকল্পগুলি রয়েছে:

• মবি/বিল্ডকিট — ডকার ইনকর্পোরেটেডের একজন নির্মাতা (ইতিমধ্যে ডকারের বর্তমান সংস্করণগুলিতে একীভূত), যা এই সমস্ত সমস্যার সমাধান করার চেষ্টা করছে;
• কানিকো — গুগলের একজন নির্মাতা যা আপনাকে ডকার ছাড়াই নির্মাণ করতে দেয়;
• Buildpacks.io — সিএনসিএফ-এর স্বয়ংক্রিয় জাদু তৈরির প্রচেষ্টা এবং বিশেষত, স্তরগুলির জন্য রিবেস সহ একটি আকর্ষণীয় সমাধান;
• এবং অন্যান্য ইউটিলিটিগুলির একটি গুচ্ছ, যেমন বিল্ডাহ, genuinetools/img...

...এবং GitHub-এ তাদের কতগুলি তারা আছে তা দেখুন। অর্থাৎ একদিকে, docker build বিদ্যমান এবং কিছু করতে পারে, কিন্তু বাস্তবে সমস্যা সম্পূর্ণরূপে সমাধান করা হয় না - এর প্রমাণ হল বিকল্প সংগ্রাহকদের সমান্তরাল বিকাশ, যার প্রত্যেকটি সমস্যার কিছু অংশ সমাধান করে।

werf মধ্যে সমাবেশ

তাই আমরা পেয়েছিলাম werf (পূর্বে বিখ্যাত ড্যাপের মত) — Flant কোম্পানির একটি ওপেন সোর্স ইউটিলিটি, যা আমরা বহু বছর ধরে তৈরি করে আসছি। এটি সবই 5 বছর আগে ব্যাশ স্ক্রিপ্টগুলির সাথে শুরু হয়েছিল যা ডকারফাইলসের সমাবেশকে অপ্টিমাইজ করেছিল এবং গত 3 বছর ধরে একটি প্রকল্পের কাঠামোর মধ্যে নিজস্ব গিট রিপোজিটরি সহ সম্পূর্ণ বিকাশ করা হয়েছে (প্রথমে রুবিতে, এবং তারপরে অনুলিপি করা যেতে, এবং একই সাথে নাম পরিবর্তন করা হয়েছে). werf এ কি সমাবেশ সমস্যা সমাধান করা হয়?

নীল রঙে ছায়াযুক্ত সমস্যাগুলি ইতিমধ্যেই বাস্তবায়িত হয়েছে, একই হোস্টের মধ্যে সমান্তরাল নির্মাণ করা হয়েছিল এবং হলুদে হাইলাইট করা সমস্যাগুলি গ্রীষ্মের শেষের দিকে সম্পন্ন করার পরিকল্পনা করা হয়েছে।

রেজিস্ট্রিতে প্রকাশের পর্যায় (প্রকাশ)

আমরা ডায়াল করেছি docker push... - রেজিস্ট্রি একটি ছবি আপলোড সম্পর্কে কি কঠিন হতে পারে? এবং তারপরে প্রশ্ন ওঠে: "আমি ছবিটিতে কী ট্যাগ লাগাব?" এটা আমাদের আছে যে কারণে উদ্ভূত হয় গ্রিটফ্লো (বা অন্যান্য গিট কৌশল) এবং কুবারনেটস, এবং শিল্প নিশ্চিত করার চেষ্টা করছে যে কুবারনেটসে যা ঘটে তা গিটে যা ঘটে তা অনুসরণ করে। সর্বোপরি, গিট আমাদের সত্যের একমাত্র উত্স।

এই সম্পর্কে এত কঠিন কি? প্রজননযোগ্যতা নিশ্চিত করুন: গিটে একটি কমিট থেকে, যা প্রকৃতিতে অপরিবর্তনীয় (অপরিবর্তনীয়), একটি ডকার ইমেজ, যা একই রাখা উচিত.

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

ট্যাগিং কৌশল

প্রথমটি সহজ git ট্যাগ. আমরা একটি ছবি ট্যাগ সঙ্গে একটি রেজিস্ট্রি আছে 1.0. Kubernetes মঞ্চ এবং উত্পাদন আছে, যেখানে এই ছবিটি আপলোড করা হয়. গিট-এ আমরা কমিট করি এবং কিছু সময়ে আমরা ট্যাগ করি 2.0. আমরা সংগ্রহস্থল থেকে নির্দেশাবলী অনুযায়ী এটি সংগ্রহ করি এবং ট্যাগ সহ রেজিস্ট্রিতে রাখি 2.0. আমরা এটিকে মঞ্চে নিয়ে আসি এবং, যদি সবকিছু ঠিক থাকে, তাহলে উৎপাদনে।

এই পদ্ধতির সমস্যা হল যে আমরা প্রথমে ট্যাগটি রাখি, এবং শুধুমাত্র তারপর এটি পরীক্ষা করে রোল আউট করি। কেন? প্রথমত, এটি কেবল অযৌক্তিক: আমরা সফ্টওয়্যারের একটি সংস্করণ জারি করছি যা আমরা এখনও পরীক্ষা করিনি (আমরা অন্যথায় করতে পারি না, কারণ পরীক্ষা করার জন্য, আমাদের একটি ট্যাগ লাগাতে হবে)। দ্বিতীয়ত, এই পথটি Gitflow এর সাথে সামঞ্জস্যপূর্ণ নয়।

দ্বিতীয় বিকল্পটি হ'ল git কমিট + ট্যাগ. মাস্টার শাখার একটি ট্যাগ আছে 1.0; রেজিস্ট্রিতে এটির জন্য - একটি চিত্র উত্পাদনে স্থাপন করা হয়েছে। এছাড়াও, কুবারনেটস ক্লাস্টারে প্রিভিউ এবং স্টেজিং কনট্যুর রয়েছে। পরবর্তীতে আমরা গিটফ্লো অনুসরণ করি: উন্নয়নের জন্য প্রধান শাখায় (develop) আমরা নতুন বৈশিষ্ট্য তৈরি করি, যার ফলে শনাক্তকারীর সাথে একটি প্রতিশ্রুতি হয় #c1. আমরা এটি সংগ্রহ করি এবং এই শনাক্তকারী ব্যবহার করে রেজিস্ট্রিতে প্রকাশ করি (#c1) একই শনাক্তকারীর সাহায্যে আমরা প্রিভিউতে রোল আউট করি। আমরা কমিটের সাথে একই কাজ করি #c2 и #c3.

যখন আমরা বুঝতে পারি যে যথেষ্ট বৈশিষ্ট্য রয়েছে, তখন আমরা সবকিছু স্থিতিশীল করতে শুরু করি। Git এ একটি শাখা তৈরি করুন release_1.1 (বেসে #c3 থেকে develop) এই রিলিজ সংগ্রহ করার কোন প্রয়োজন নেই, কারণ... এটি পূর্ববর্তী ধাপে করা হয়েছিল। অতএব, আমরা এটিকে মঞ্চায়নে রোল আউট করতে পারি। আমরা বাগ ঠিক করি #c4 এবং একইভাবে মঞ্চে রোল আউট. একই সাথে উন্নয়নের কাজ চলছে develop, যেখানে পর্যায়ক্রমে পরিবর্তনগুলি নেওয়া হয় release_1.1. কিছু সময়ে, আমরা একটি প্রতিশ্রুতি সংকলন করি এবং স্টেজিংয়ে আপলোড করি, যা নিয়ে আমরা খুশি (#c25).

তারপরে আমরা রিলিজ শাখাকে (দ্রুত-ফরোয়ার্ড সহ) একত্রিত করি (release_1.1) মাস্টারে। আমরা এই প্রতিশ্রুতিতে নতুন সংস্করণের সাথে একটি ট্যাগ রেখেছি (1.1) কিন্তু এই ছবিটি ইতিমধ্যেই রেজিস্ট্রিতে সংগ্রহ করা হয়েছে, তাই এটি আবার সংগ্রহ না করার জন্য, আমরা কেবল বিদ্যমান ছবিতে একটি দ্বিতীয় ট্যাগ যুক্ত করি (এখন এটির রেজিস্ট্রিতে ট্যাগ রয়েছে #c25 и 1.1) এর পরে, আমরা এটি উত্পাদনে রোল আউট করি।

একটি অপূর্ণতা আছে যে শুধুমাত্র একটি ছবি স্টেজিং এ আপলোড করা হয় (#c25), এবং উৎপাদনে এটা ভিন্ন ধরনের (1.1), কিন্তু আমরা জানি যে "শারীরিকভাবে" এগুলি রেজিস্ট্রি থেকে একই চিত্র।

আসল অসুবিধা হ'ল মার্জ কমিটের জন্য কোনও সমর্থন নেই, আপনাকে দ্রুত-ফরোয়ার্ড করতে হবে।

আমরা আরও এগিয়ে গিয়ে একটি কৌশল করতে পারি... আসুন একটি সাধারণ ডকারফাইলের উদাহরণ দেখি:

FROM ruby:2.3 as assets
RUN mkdir -p /app
WORKDIR /app
COPY . ./
RUN gem install bundler && bundle install
RUN bundle exec rake assets:precompile
CMD bundle exec puma -C config/puma.rb

FROM nginx:alpine
COPY --from=assets /app/public /usr/share/nginx/www/public

আসুন নিম্নলিখিত নীতি অনুসারে এটি থেকে একটি ফাইল তৈরি করি:

• SHA256 ব্যবহৃত চিত্রগুলির সনাক্তকারী থেকে (ruby:2.3 и nginx:alpine), যা তাদের বিষয়বস্তুর চেকসাম;
• সব দল (RUN, CMD এবং তাই।);
• যুক্ত করা ফাইল থেকে SHA256।

... এবং এই ধরনের একটি ফাইল থেকে চেকসাম (আবার SHA256) নিন। এই স্বাক্ষর ডকার ইমেজের বিষয়বস্তু সংজ্ঞায়িত করে এমন সবকিছু।

এর ডায়াগ্রামে ফিরে যাওয়া যাক এবং প্রতিশ্রুতির পরিবর্তে আমরা এই ধরনের স্বাক্ষর ব্যবহার করব, অর্থাৎ স্বাক্ষর সহ ছবি ট্যাগ করুন।

এখন, যখন প্রয়োজন হয়, উদাহরণস্বরূপ, রিলিজ থেকে মাস্টারে পরিবর্তনগুলিকে একত্রিত করার জন্য, আমরা একটি বাস্তব মার্জ কমিট করতে পারি: এটির একটি ভিন্ন শনাক্তকারী থাকবে, কিন্তু একই স্বাক্ষর থাকবে৷ একই শনাক্তকারীর সাহায্যে আমরা ছবিটিকে প্রোডাকশনে রোল আউট করব।

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

werf ট্যাগিং

ওয়ার্ফ-এ আমরা আরও এগিয়ে গিয়েছিলাম এবং একটি ক্যাশে দিয়ে একটি বিতরণ করা বিল্ড করার প্রস্তুতি নিচ্ছি যা একটি মেশিনে সংরক্ষণ করা হয় না... সুতরাং, আমরা দুই ধরনের ডকার ইমেজ তৈরি করছি, আমরা তাদের বলি পর্যায় и ভাবমূর্তি.

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

ধরুন এর পরে একটি নতুন প্রতিশ্রুতি প্রদর্শিত হবে যেখানে শুধুমাত্র অ্যাপ্লিকেশন কোড পরিবর্তন করা হয়েছে। কি হবে? কোড পরিবর্তনের জন্য, একটি প্যাচ তৈরি করা হবে এবং একটি নতুন স্টেজ ইমেজ প্রস্তুত করা হবে। এর স্বাক্ষরটি পুরানো স্টেজ ইমেজ এবং নতুন প্যাচের চেকসাম হিসাবে নির্ধারিত হবে। এই ছবিটি থেকে একটি নতুন চূড়ান্ত চিত্র তৈরি করা হবে। অন্যান্য পর্যায়ে পরিবর্তনের সাথে অনুরূপ আচরণ ঘটবে।

এইভাবে, স্টেজ ইমেজগুলি হল একটি ক্যাশে যা বিতরণ করা যায় এবং এটি থেকে ইতিমধ্যে তৈরি করা ছবিগুলি ডকার রেজিস্ট্রিতে আপলোড করা হয়।

রেজিস্ট্রি পরিষ্কার করা

আমরা মুছে ফেলা ট্যাগগুলির পরে ঝুলে থাকা স্তরগুলি মুছে ফেলার বিষয়ে কথা বলছি না - এটি ডকার রেজিস্ট্রির একটি আদর্শ বৈশিষ্ট্য। আমরা এমন একটি পরিস্থিতির কথা বলছি যখন প্রচুর ডকার ট্যাগ জমা হয় এবং আমরা বুঝতে পারি যে আমাদের আর সেগুলির কিছুর প্রয়োজন নেই, তবে তারা জায়গা নেয় (এবং/অথবা আমরা এটির জন্য অর্থ প্রদান করি)।

পরিষ্কার করার কৌশল কি?

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

দুটি সত্যই কার্যকর বিকল্প রয়েছে: পরিষ্কার করবেন না বা নীল-সবুজ + ম্যানুয়ালি সংমিশ্রণ করবেন না। পরবর্তী ক্ষেত্রে, আমরা নিম্নলিখিতগুলি সম্পর্কে কথা বলছি: আপনি যখন বুঝতে পারেন যে এটি রেজিস্ট্রি পরিষ্কার করার সময়, আপনি একটি নতুন তৈরি করেন এবং এটিতে সমস্ত নতুন ছবি যুক্ত করেন, উদাহরণস্বরূপ, এক মাস। এবং এক মাস পরে, কুবারনেটসের কোন পডগুলি এখনও পুরানো রেজিস্ট্রি ব্যবহার করছে তা দেখুন এবং সেগুলিকেও নতুন রেজিস্ট্রিতে স্থানান্তর করুন৷

আমরা কি এসেছি werf? আমরা সংগ্রহ করি:

1. গিট হেড: সমস্ত ট্যাগ, সমস্ত শাখা - ধরে নিচ্ছি যে চিত্রগুলিতে গিটে ট্যাগ করা সমস্ত কিছু আমাদের দরকার (এবং যদি না হয় তবে আমাদের গিটেই মুছে ফেলতে হবে);
2. সমস্ত শুঁটি যা বর্তমানে কুবারনেটে পাম্প করা হয়;
3. পুরানো রেপ্লিকাসেট (যা সম্প্রতি প্রকাশিত হয়েছে), এবং আমরা হেলম রিলিজগুলি স্ক্যান করার এবং সেখানে সাম্প্রতিক চিত্রগুলি নির্বাচন করার পরিকল্পনা করছি৷

... এবং এই সেট থেকে একটি সাদা তালিকা তৈরি করুন - ছবির একটি তালিকা যা আমরা মুছব না। আমরা অন্য সবকিছু পরিষ্কার করি, তারপরে আমরা অনাথ মঞ্চের ছবিগুলি খুঁজে পাই এবং সেগুলিও মুছে ফেলি।

মঞ্চ স্থাপন

নির্ভরযোগ্য ঘোষণামূলকতা

স্থাপনার ক্ষেত্রে প্রথম যে বিষয়টির প্রতি আমি দৃষ্টি আকর্ষণ করতে চাই তা হল আপডেট করা রিসোর্স কনফিগারেশনের রোলআউট, ঘোষণামূলকভাবে ঘোষণা করা হয়েছে। কুবারনেটস সংস্থানগুলির বর্ণনাকারী আসল YAML নথিটি ক্লাস্টারে চলমান ফলাফল থেকে সর্বদা খুব আলাদা। কারণ Kubernetes কনফিগারেশন যোগ করে:

1. শনাক্তকারী;
2. পরিষেবা তথ্য;
3. অনেক ডিফল্ট মান;
4. বর্তমান অবস্থা সহ বিভাগ;
5. ভর্তি ওয়েবহুকের অংশ হিসাবে করা পরিবর্তন;
6. বিভিন্ন কন্ট্রোলার (এবং সময়সূচী) এর কাজের ফলাফল।

অতএব, যখন একটি নতুন সংস্থান কনফিগারেশন প্রদর্শিত হয় (নতুন), আমরা এটির সাথে বর্তমান, "লাইভ" কনফিগারেশনটি নিতে এবং ওভাররাইট করতে পারি না (জীবিত) এটি করার জন্য আমাদের তুলনা করতে হবে নতুন সর্বশেষ প্রয়োগকৃত কনফিগারেশন সহ (সর্বশেষ প্রয়োগ করা হয়েছে) এবং রোল সম্মুখের জীবিত প্রাপ্ত প্যাচ.

এই পদ্ধতি বলা হয় 2-ওয়ে মার্জ. এটি ব্যবহার করা হয়, উদাহরণস্বরূপ, হেলমে।

এছাড়াও আছে 3-ওয়ে মার্জ, যা এর মধ্যে ভিন্ন:

• তুলনা সর্বশেষ প্রয়োগ করা হয়েছে и নতুন, আমরা কি মুছে ফেলা হয়েছে তাকান;
• তুলনা নতুন и জীবিত, আমরা কী যোগ বা পরিবর্তন করা হয়েছে তা দেখি;
• সমষ্টি প্যাচ প্রয়োগ করা হয় জীবিত.

আমরা হেলমের সাথে 1000+ অ্যাপ্লিকেশন স্থাপন করি, তাই আমরা আসলে 2-ওয়ে মার্জ দিয়ে থাকি। যাইহোক, এতে বেশ কিছু সমস্যা রয়েছে যা আমরা আমাদের প্যাচ দিয়ে সমাধান করেছি, যা হেলমকে স্বাভাবিকভাবে কাজ করতে সাহায্য করে।

বাস্তব রোলআউট অবস্থা

আমাদের CI সিস্টেম পরবর্তী ইভেন্টের উপর ভিত্তি করে কুবারনেটসের জন্য একটি নতুন কনফিগারেশন তৈরি করার পরে, এটি ব্যবহারের জন্য এটি প্রেরণ করে (প্রয়োগ করুন) একটি ক্লাস্টারে - হেলম ব্যবহার করে বা kubectl apply. এর পরে, ইতিমধ্যে বর্ণিত N-ওয়ে মার্জ ঘটে, যার জন্য Kubernetes API CI সিস্টেমে এবং এটি তার ব্যবহারকারীর কাছে অনুমোদনের সাথে সাড়া দেয়।

যাইহোক, একটি বিশাল সমস্যা আছে: সব পরে সফল অ্যাপ্লিকেশন মানে সফল রোলআউট নয়. Kubernetes যদি বুঝতে পারে কোন পরিবর্তনগুলি প্রয়োগ করতে হবে এবং এটি প্রয়োগ করতে হবে, আমরা এখনও জানি না ফলাফল কী হবে। উদাহরণস্বরূপ, ফ্রন্টএন্ডে পড আপডেট করা এবং পুনরায় চালু করা সফল হতে পারে, তবে ব্যাকএন্ডে নয় এবং আমরা চলমান অ্যাপ্লিকেশন চিত্রগুলির বিভিন্ন সংস্করণ পাব।

সবকিছু সঠিকভাবে করতে, এই স্কিমটির একটি অতিরিক্ত লিঙ্ক প্রয়োজন - একটি বিশেষ ট্র্যাকার যা কুবারনেটস API থেকে স্থিতির তথ্য পাবে এবং জিনিসগুলির বাস্তব অবস্থার আরও বিশ্লেষণের জন্য এটি প্রেরণ করবে। আমরা গো-তে একটি ওপেন সোর্স লাইব্রেরি তৈরি করেছি - cubedog (এর ঘোষণা দেখুন এখানে), যা এই সমস্যার সমাধান করে এবং werf-এ নির্মিত।

werf স্তরে এই ট্র্যাকারের আচরণ ডিপ্লোয়মেন্ট বা স্টেটফুলসেটে রাখা টীকা ব্যবহার করে কনফিগার করা হয়। মূল টীকা- fail-mode - নিম্নলিখিত অর্থ বোঝে:

• IgnoreAndContinueDeployProcess — আমরা এই উপাদানটি রোল আউট করার সমস্যাগুলি উপেক্ষা করি এবং স্থাপনা চালিয়ে যাই;
• FailWholeDeployProcessImmediately — এই উপাদানটিতে একটি ত্রুটি স্থাপনা প্রক্রিয়া বন্ধ করে দেয়;
• HopeUntilEndOfDeployProcess — আমরা আশা করি যে এই উপাদানটি স্থাপনের শেষে কাজ করবে।

উদাহরণস্বরূপ, সম্পদ এবং টীকা মান এই সমন্বয় fail-mode:

যখন আমরা প্রথমবার স্থাপন করি, তখন ডাটাবেস (MongoDB) এখনও প্রস্তুত নাও হতে পারে - স্থাপনা ব্যর্থ হবে। কিন্তু আপনি এটি শুরু হওয়ার জন্য মুহুর্তের জন্য অপেক্ষা করতে পারেন, এবং স্থাপনা এখনও সঞ্চালিত হবে।

werf-এ kubedog-এর জন্য আরও দুটি টীকা আছে:

• failures-allowed-per-replica - প্রতিটি প্রতিরূপের জন্য অনুমোদিত ফলস সংখ্যা;
• show-logs-until — যতক্ষণ না werf সমস্ত রোল আউট পড থেকে লগ দেখায় (stdout-এ) সেই মুহূর্তটিকে নিয়ন্ত্রণ করে৷ ডিফল্ট হয় PodIsReady (পডে ট্র্যাফিক আসতে শুরু করলে আমরা সম্ভবত চাই না এমন বার্তাগুলিকে উপেক্ষা করার জন্য), তবে মানগুলিও বৈধ: ControllerIsReady и EndOfDeploy.

আমরা স্থাপনার থেকে আর কি চাই?

ইতিমধ্যে বর্ণিত দুটি পয়েন্ট ছাড়াও, আমরা চাই:

• দেখতে লগ - এবং শুধুমাত্র প্রয়োজনীয়গুলি, এবং একটি সারিতে সবকিছু নয়;
• ট্র্যাক উন্নতি, কারণ যদি কাজটি কয়েক মিনিটের জন্য "নিঃশব্দে" ঝুলে থাকে, তবে সেখানে কী ঘটছে তা বোঝা গুরুত্বপূর্ণ;
• иметь স্বয়ংক্রিয় রোলব্যাক যদি কিছু ভুল হয়ে যায় (এবং তাই স্থাপনার প্রকৃত অবস্থা জানা গুরুত্বপূর্ণ)। রোলআউটটি অবশ্যই পারমাণবিক হতে হবে: হয় এটি শেষ পর্যন্ত যায় বা সবকিছু তার আগের অবস্থায় ফিরে আসে।

ফলাফল

একটি কোম্পানি হিসাবে আমাদের জন্য, ডেলিভারির বিভিন্ন পর্যায়ে (নির্মাণ, প্রকাশ, স্থাপন) সমস্ত বর্ণিত সূক্ষ্মতা বাস্তবায়নের জন্য, একটি CI সিস্টেম এবং ইউটিলিটি যথেষ্ট werf.

একটি উপসংহারের পরিবর্তে:

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

ভিডিও এবং স্লাইড

পারফরম্যান্স থেকে ভিডিও (~47 মিনিট):

প্রতিবেদনের উপস্থাপনা:

দ্রষ্টব্য

আমাদের ব্লগে কুবারনেটস সম্পর্কে অন্যান্য প্রতিবেদন:

• «কুবারনেটসে অটোস্কেলিং এবং রিসোর্স ম্যানেজমেন্ট» (দিমিত্রি স্টোলিয়ারভ; 27 এপ্রিল, 2019 "স্ট্রাইক"-এ);
• «Kubernetes প্রসারিত এবং পরিপূরক» (Andrey Polovov; সেন্ট হাইলোড++ এ 8 এপ্রিল, 2019);
• «ডাটাবেস এবং কুবারনেটস» (দিমিত্রি স্টোলিয়ারভ; 8 নভেম্বর, 2018 হাইলোড++ এ);
• «মনিটরিং এবং কুবারনেটস» (দিমিত্রি স্টোলিয়ারভ; রুটকনফে 28 মে, 2018);
• «কুবারনেটস এবং গিটল্যাবের সাথে সিআই/সিডি সেরা অনুশীলন» (দিমিত্রি স্টোলিয়ারভ; 7 নভেম্বর, 2017 হাইলোড++ এ);
• «ছোট প্রকল্পে Kubernetes সঙ্গে আমাদের অভিজ্ঞতা» (দিমিত্রি স্টোলিয়ারভ; জুন 6, 2017 রুটকনফে).

উত্স: www.habr.com