GitOps: পুল এবং পুশ পদ্ধতির তুলনা

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

গত বছর (আসলে, আনুষ্ঠানিকভাবে এটি 2017 সালের আগস্টে হয়েছিল - প্রায় অনুবাদ।) Kubernetes এ অ্যাপ্লিকেশন স্থাপন করার জন্য একটি নতুন পদ্ধতি আছে। এটিকে গিটঅপস বলা হয় এবং এটি মূল ধারণার উপর ভিত্তি করে যে স্থাপনার সংস্করণগুলি একটি গিট সংগ্রহস্থলের নিরাপদ পরিবেশে ট্র্যাক করা হয়।

এই পদ্ধতির প্রধান সুবিধাগুলি নিম্নরূপ::

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

আপনি দেখতে পাচ্ছেন, GitOps পদ্ধতিতে অনেক সুবিধা রয়েছে। গত এক বছরে, দুটি পদ্ধতি বিশেষ জনপ্রিয়তা অর্জন করেছে। একটি পুশ ভিত্তিক, অন্যটি টান ভিত্তিক। আমরা সেগুলি দেখার আগে, প্রথমে সাধারণ কুবারনেটস স্থাপনাগুলি কেমন তা দেখে নেওয়া যাক।

স্থাপনার পদ্ধতি

সাম্প্রতিক বছরগুলিতে, কুবারনেটসে স্থাপনার জন্য বিভিন্ন পদ্ধতি এবং সরঞ্জাম প্রতিষ্ঠিত হয়েছে:

1. নেটিভ Kubernetes/Kustomize টেমপ্লেটের উপর ভিত্তি করে. এটি Kubernetes এ অ্যাপ্লিকেশন স্থাপন করার সবচেয়ে সহজ উপায়। বিকাশকারী মৌলিক YAML ফাইল তৈরি করে এবং তাদের প্রয়োগ করে। ক্রমাগত একই টেমপ্লেটগুলি পুনরায় লেখা থেকে পরিত্রাণ পেতে, Kustomize তৈরি করা হয়েছিল (এটি Kubernetes টেমপ্লেটগুলিকে মডিউলে পরিণত করে)। বিঃদ্রঃ. অনুবাদ: Kustomize সঙ্গে kubectl এ একীভূত করা হয়েছে Kubernetes 1.14 এর রিলিজ.
2. হেলম চার্ট. হেলম চার্ট আপনাকে টেমপ্লেট, ইনিট কন্টেনার, সাইডকার ইত্যাদির সেট তৈরি করতে দেয়, যেগুলি টেমপ্লেট-ভিত্তিক পদ্ধতির চেয়ে আরও নমনীয় কাস্টমাইজেশন বিকল্পগুলির সাথে অ্যাপ্লিকেশন স্থাপন করতে ব্যবহৃত হয়। এই পদ্ধতিটি টেমপ্লেটেড YAML ফাইলের উপর ভিত্তি করে। হেলম সেগুলিকে বিভিন্ন পরামিতি দিয়ে পূরণ করে এবং তারপর সেগুলি টিলারে পাঠায়, একটি ক্লাস্টার উপাদান যা তাদের ক্লাস্টারে স্থাপন করে এবং আপডেট এবং রোলব্যাকের অনুমতি দেয়। গুরুত্বপূর্ণ বিষয় হল হেলম মূলত টেমপ্লেটগুলিতে কাঙ্খিত মানগুলি সন্নিবেশিত করে এবং তারপরে সেগুলিকে একইভাবে প্রয়োগ করে যেমনটি ঐতিহ্যগত পদ্ধতিতে করা হয় (এটি কীভাবে কাজ করে এবং আপনি কীভাবে এটি ব্যবহার করতে পারেন সে সম্পর্কে আরও পড়ুন আমাদের হেলমের নিবন্ধ - প্রায়. অনুবাদ।). বিভিন্ন ধরণের রেডিমেড হেলম চার্ট রয়েছে যা বিস্তৃত পরিসরে কাজ করে।
3. বিকল্প সরঞ্জাম. অনেক বিকল্প সরঞ্জাম আছে। তাদের সবার মধ্যে যা মিল রয়েছে তা হল তারা কিছু টেমপ্লেট ফাইলকে কুবারনেটস-পঠনযোগ্য YAML ফাইলে পরিণত করে এবং তারপরে সেগুলি ব্যবহার করে।

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

পুল ধাক্কা

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

বিশেষ দ্রষ্টব্য! GitOps ব্যবহার করার সমস্ত সুবিধা উভয় পদ্ধতির জন্য একই থাকে।

টান ভিত্তিক পদ্ধতি

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

পেশাদাররা:

1. কোনো বহিরাগত ক্লায়েন্টের ক্লাস্টারে পরিবর্তন করার অধিকার নেই; সমস্ত আপডেট ভিতরে থেকে আনা হয়।
2. কিছু সরঞ্জাম আপনাকে হেলম চার্ট আপডেটগুলি সিঙ্ক্রোনাইজ করতে এবং ক্লাস্টারের সাথে লিঙ্ক করার অনুমতি দেয়।
3. ডকার রেজিস্ট্রি নতুন সংস্করণের জন্য স্ক্যান করা যেতে পারে। যদি একটি নতুন ছবি পাওয়া যায়, Git সংগ্রহস্থল এবং স্থাপনা নতুন সংস্করণে আপডেট করা হয়।
4. বিভিন্ন গিট রিপোজিটরি এবং অনুমতি সহ বিভিন্ন নেমস্পেস জুড়ে পুল সরঞ্জামগুলি বিতরণ করা যেতে পারে। এই জন্য ধন্যবাদ, একটি multitenant মডেল ব্যবহার করা যেতে পারে। উদাহরণস্বরূপ, দল A নামস্থান A ব্যবহার করতে পারে, দল B নামস্থান B ব্যবহার করতে পারে এবং অবকাঠামো দল বিশ্বব্যাপী স্থান ব্যবহার করতে পারে।
5. একটি নিয়ম হিসাবে, সরঞ্জাম খুব হালকা।
6. অপারেটরের মতো সরঞ্জামগুলির সাথে মিলিত বিতনামি সিলড সিক্রেটস, গোপনীয়তাগুলি একটি গিট সংগ্রহস্থলে এনক্রিপ্ট করে সংরক্ষণ করা যেতে পারে এবং ক্লাস্টারের মধ্যে পুনরুদ্ধার করা যেতে পারে।
7. CD পাইপলাইনের সাথে কোন সংযোগ নেই যেহেতু ডিপ্লোয়মেন্ট ক্লাস্টারের মধ্যে ঘটে।

Минусы:

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

পুশ ভিত্তিক পদ্ধতি

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

Плюсы:

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

Минусы:

1. ক্লাস্টার অ্যাক্সেস ডেটা বিল্ড সিস্টেমের ভিতরে থাকে।
2. একটি টান প্রক্রিয়ার মাধ্যমে স্থাপনার পাত্রে আপডেট করা এখনও সহজ।
3. CD সিস্টেমের উপর প্রচুর নির্ভরতা, যেহেতু আমাদের প্রয়োজনীয় পাইপলাইনগুলি মূলত গিটল্যাব রানার্সের জন্য লেখা হতে পারে, এবং তারপরে দলটি Azure DevOps বা Jenkins-এ যাওয়ার সিদ্ধান্ত নেয়... এবং প্রচুর সংখ্যক বিল্ড পাইপলাইন স্থানান্তর করতে হবে।

ফলাফল: ধাক্কা বা টান?

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

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

সুতরাং, যদি পুল পদ্ধতিটি আরও শ্রম নিবিড় হয় এবং নিরাপত্তা সুবিধা প্রদান না করে, তবে শুধুমাত্র পুশ পদ্ধতি ব্যবহার করা কি যৌক্তিক নয়? তবে কেউ যুক্তি দিতে পারে যে পুশ পদ্ধতিতে আপনি সিডি সিস্টেমের সাথে খুব বেশি আবদ্ধ এবং সম্ভবত, এটি না করাই ভাল যাতে ভবিষ্যতে মাইগ্রেশন করা সহজ হয়।

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

আমি আশা করি এই বিষয়ে আমার অভিজ্ঞতা আপনাকে সিদ্ধান্ত নিতে সাহায্য করবে যে কোন পদ্ধতিটি আপনার ধরনের স্থাপনার জন্য আরও উপযুক্ত, এবং আমি আপনার মতামত শুনে খুশি হব।

অনুবাদক থেকে পিএস নোট

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

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

আমরা উভয় মডেল চেষ্টা করেছি এবং নিবন্ধের লেখক হিসাবে একই সিদ্ধান্তে পৌঁছেছি:

1. প্রচুর সংখ্যক ক্লাস্টারে সিস্টেমের উপাদানগুলির আপডেটগুলি সংগঠিত করার জন্য পুল মডেলটি আমাদের জন্য উপযুক্ত (দেখুন। অ্যাডঅন-অপারেটর সম্পর্কে নিবন্ধ).
2. GitLab CI ভিত্তিক পুশ মডেলটি হেলম চার্ট ব্যবহার করে অ্যাপ্লিকেশনগুলি রোল আউট করার জন্য উপযুক্ত। একই সময়ে, টুল ব্যবহার করে পাইপলাইনের মধ্যে স্থাপনার রোলআউট পর্যবেক্ষণ করা হয় werf. যাইহোক, আমাদের এই প্রকল্পের প্রেক্ষাপটে, আমরা KubeCon Europe'19-এ আমাদের স্ট্যান্ডে DevOps ইঞ্জিনিয়ারদের চাপের সমস্যা নিয়ে আলোচনা করার সময় ধ্রুবক "GitOps" শুনেছিলাম।

অনুবাদক থেকে PPS

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

• «Kubernetes টিপস এবং কৌশল: Helm 2 ব্যবস্থাপনায় একটি ক্লাস্টারে চলমান সম্পদ স্থানান্তর";
• «Kubernetes সম্পদ নিরীক্ষণের জন্য kubedog লাইব্রেরি চালু করা হচ্ছে";
• «Kubernetes সম্প্রসারণ এবং পরিপূরক (ওভারভিউ এবং ভিডিও রিপোর্ট)";
• «GitLab CI-এ কাস্টম ওয়ার্কফ্লো তৈরি করার জন্য টিপস».

শুধুমাত্র নিবন্ধিত ব্যবহারকারীরা জরিপে অংশগ্রহণ করতে পারবেন। সাইন ইন করুনকরুন।

আপনি কি GitOps ব্যবহার করছেন?

• হ্যাঁ, টান পন্থা

• হ্যাঁ, ধাক্কা

• হ্যাঁ, টান + ধাক্কা

• হ্যাঁ, অন্য কিছু

• না

30 জন ব্যবহারকারী ভোট দিয়েছেন। 10 জন ব্যবহারকারী বিরত ছিলেন।

উত্স: www.habr.com