GitOps: আরেকটি বাজওয়ার্ড বা অটোমেশনে একটি অগ্রগতি?

আমাদের মধ্যে বেশিরভাগ, আইটি ব্লগস্ফিয়ার বা কনফারেন্সে আরেকটি নতুন শব্দ লক্ষ্য করে, শীঘ্র বা পরে একই প্রশ্ন জিজ্ঞাসা করুন: "এটি কী? শুধু আরেকটি বাজওয়ার্ড, একটি "buzzword" বা সত্যিই ঘনিষ্ঠ মনোযোগ, অধ্যয়ন এবং নতুন দিগন্তের প্রতিশ্রুতির যোগ্য কিছু? একই জিনিস টার্ম সঙ্গে আমার ঘটেছে GitOps কিছু সময় আগে. অনেক বিদ্যমান নিবন্ধ, সেইসাথে কোম্পানীর সহকর্মীদের জ্ঞান দিয়ে সজ্জিত GitLab, আমি এটা কি ধরনের জানোয়ার, এবং এর ব্যবহার অনুশীলনে কেমন হতে পারে তা বের করার চেষ্টা করেছি।

যাইহোক, শব্দটির অভিনবত্ব সম্পর্কে GitOps আমাদের সাম্প্রতিক সমীক্ষা আরও বলে: জরিপ করা অর্ধেকেরও বেশি এখনও এর নীতিগুলি নিয়ে কাজ শুরু করেনি।

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

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

তাই পার্থক্য ঠিক কি? GitOps থেকে আইএসি? এই প্রশ্ন নিয়েই আমি আমার তদন্ত শুরু করেছি। সহকর্মীদের সাথে কথা বলার পরে, আমি নিম্নলিখিত তুলনা নিয়ে আসতে সক্ষম হয়েছি:

GitOps

আইএসি

সমস্ত কোড একটি গিট সংগ্রহস্থলে সংরক্ষণ করা হয়

কোড সংস্করণ ঐচ্ছিক

ঘোষণামূলক কোডের বর্ণনা / ইডেমপোটেন্সি

ঘোষণামূলক এবং অপরিহার্য উভয় বর্ণনাই গ্রহণযোগ্য

পরিবর্তনগুলি মার্জ রিকোয়েস্ট/পুল রিকোয়েস্ট মেকানিজম ব্যবহার করে কার্যকর হয়

চুক্তি, অনুমোদন এবং সহযোগিতা ঐচ্ছিক

আপডেট রোলআউট প্রক্রিয়া স্বয়ংক্রিয় হয়

আপডেট রোলআউট প্রক্রিয়া মানসম্মত নয় (স্বয়ংক্রিয়, ম্যানুয়াল, ফাইল অনুলিপি করা, কমান্ড লাইন ব্যবহার করে, ইত্যাদি)

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

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

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

কোম্পানির মধ্যে GitLab আমরা এই নতুন শব্দটির দুটি সংজ্ঞা তৈরি করেছি: তাত্ত্বিক এবং ব্যবহারিক। আসুন তাত্ত্বিক দিয়ে শুরু করা যাক:

GitOps একটি পদ্ধতি যা অ্যাপ্লিকেশন বিকাশের জন্য ব্যবহৃত সেরা DevOps নীতিগুলি গ্রহণ করে, যেমন সংস্করণ নিয়ন্ত্রণ, সহযোগিতা, অর্কেস্ট্রেশন, CI/CD, এবং সেগুলি স্বয়ংক্রিয় পরিকাঠামো পরিচালনার চ্যালেঞ্জগুলিতে প্রয়োগ করে৷

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

ব্যবহারিক দৃষ্টিকোণ থেকে, আমরা বর্ণনা করি GitOps নিম্নরূপ:

আমরা ইতিমধ্যে এই সূত্রের অন্যতম প্রধান উপাদান হিসাবে কোড হিসাবে অবকাঠামো নিয়ে আলোচনা করেছি। বাকি অংশগ্রহণকারীদের পরিচয় করিয়ে দেওয়া যাক।

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

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

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

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

এবং আপনি যদি হঠাৎ করেই আগ্রহী হয়ে ওঠেন যে এটি কীভাবে অনুশীলনে দেখায়, তবে আমি আপনাকে আমাদের দেখার জন্য আমন্ত্রণ জানাই মাস্টার ক্লাস, যেখানে আমি আপনাকে ধাপে ধাপে বলি কিভাবে গিটল্যাব ব্যবহার করতে হয়:

• GitOps এর মৌলিক নীতিগুলি বাস্তবায়ন করুন

• ক্লাউড অবকাঠামো তৈরি করুন এবং পরিবর্তন করুন (ইয়ানডেক্স ক্লাউডের উদাহরণ ব্যবহার করে)

• সক্রিয় পর্যবেক্ষণ ব্যবহার করে একটি পছন্দসই অবস্থা থেকে সিস্টেম প্রবাহের স্বয়ংক্রিয় সনাক্তকরণ

https://bit.ly/34tRpwZ

উত্স: www.habr.com