কোনও কোড ভাণ্ডারে ডিওওপস সম্পর্কিত কোড এবং কনফিগারেশন কীভাবে গঠন করবেন?


10

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

এই সমস্ত কিছুর জন্য কিছু স্তরের কোডিং বা কনফিগারেশন প্রয়োজন - উত্তরযোগ্য স্ক্রিপ্টস এবং কনফিগারেশন, জেনকিনস গ্রোভি স্ক্রিপ্টস, ডকফেরফিলস এবং ওয়াইএএমএল কনফিগারেশন।

এখনকার জন্য, আমরা জন্য উচ্চ পর্যায়ের ডিরেক্টরি সাথে পৃথক "অপস" সংগ্রহস্থল তৈরি করেছি jenkins, ansible, dockerএবং other(যা একটি ভয়ানক নাম, কিন্তু এখন জন্য সব "অন্যান্য" DevOps অটোমেশন জিনিষ আছে)।

আমাদের পদ্ধতির সঠিক মনে হয় না এবং স্কেল নাও হতে পারে তবে ডিভোপস-সম্পর্কিত কোড কোনও কোড সংগ্রহস্থল বা সংগ্রহস্থলে রাখার জন্য সেরা অনুশীলন এবং সুপারিশগুলি কী কী?


6
আমি শেফের "প্রতিটি অংশে একটি অ্যাপ্লিকেশন, একটি অ্যাপো প্রতি একটি রেপো" পদ্ধতিটি নিয়ে যাচ্ছি, যার অর্থ রান্নাঘরের প্রতি 1 টি রেপো।
তেনসিবাই

@ তানসিবাই ঠিক বলেছেন, আমি আশঙ্কা করেছি যে একটিমাত্র "অপ্স" রেপো দ্রুত ব্যবহারহীন হয়ে উঠবে। ধন্যবাদ।
অ্যালেক্স

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

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

1
আমি এগুলিকে একাধিক রেপোতে কাজের 'সান্নিধ্য' দিয়ে বিভক্ত করতাম, এক্স এক্সে একসাথে কাজ করা স্ক্রিপ্টগুলি, আপনার দুটি অ্যাপ্লিকেশনে স্ক্রিপ্ট ব্যবহার করা যেতে পারে, তবে অ্যাপ্লিকেশন যদি কোনও পদ্ধতিতে পরিবর্তিত হয় তবে কোন অ্যাপ্লিকেশনটির সাথে কথা বলে এটি স্ক্রিপ্টটি পরিচালনা করতে পারে , দুটি পৃথক সংস্করণ থাকা ভাল, সুতরাং আমি এটোটটিডি সেগুলির সাথে সম্পর্কিত অ্যাপ্লিকেশনটি দিয়ে সংরক্ষণ করব বা যদি তারা প্রতিটি কার্য নির্দিষ্ট রেপোজিটরিতে একাধিক অ্যাপ্লিকেশন স্প্যান করে থাকে, তাই আপনার সর্বদা নিযুক্ত অ্যাপ্লিকেশনগুলির সাথে সঙ্গতিপূর্ণ একটি সংস্করণ থাকে এবং আপনি ডন না একই সাথে একটি সম্পর্কযুক্ত স্ক্রিপ্ট ট্যাগ করতে হবে না।
তেনসিবাই

উত্তর:


4

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

এর কারণ হ'ল আমরা নিদর্শনগুলির ( যেমন একটি ডকার চিত্র বা একটি সফ্টওয়্যার প্যাকেজ) নিম্নলিখিত ক্রিয়াগুলির অবজেক্ট হিসাবে বিবেচনা করতে চাই:

  • বিল্ড
  • পরীক্ষা
  • প্রয়োগের

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

উদাহরণস্বরূপ কোনও ওয়েবসাইটের জন্য কোড এবং একটি মাইক্রো-পরিষেবা "ক" সহ একটি রিপোজিটরি অপারেশনে নিবেদিত নিম্নলিখিত সাব-ডিরেক্টরি থাকতে পারে:

./ops/website
./ops/micro-service-a

প্রতিটি থাকার তিন স্ক্রিপ্ট নামক build, testএবং deploy। এখন যেহেতু অটোমেশন আইটেমগুলির সংগঠনটি কোনওভাবে পরিষ্কার করা হয়েছে, আসুন আমরা কনফিগারেশনের দিকে মনোযোগ দিন।

কনফিগারেশন সংগঠন সম্পর্কে প্রধান শর্তাদি এবং প্রয়োজনীয়তা deployক্রিয়াকলাপ দ্বারা যখন পরিষেবা-জাতীয় আর্টফ্যাক্ট প্রয়োগ করা হয় তখন সেট করা হয়। deployক্রিয়া নিম্নলিখিত পরামিতিগুলি থাকতে হবে:

  • স্থাপনের জন্য প্রত্নতত্ত্বের সংস্করণ,
  • আর্টফ্যাক্টের মোতায়েনের লক্ষ্য, যেখানে কংক্রিটের পরিবেশকে বর্ণনা করা হয় যেখানে মোতায়েন করা আর্টফ্যাক্ট চলবে ( উদাহরণস্বরূপ একটি ক্লাস্টার এবং শেষ পয়েন্টগুলি যার সাথে কথা বলা উচিত)
  • এটি অন্যান্য শেষ পয়েন্টগুলির সাথে সংযোগ স্থাপনের জন্য শংসাপত্রগুলি ব্যবহার করা উচিত ( যেমন ডাটাবেসগুলি)
  • রানটাইম কনফিগারেশন (যেমন ক্যাশে এন্ট্রিগুলি কত দিন বাঁচা উচিত ইত্যাদি)

অপারেশনাল দৃষ্টিকোণ থেকে, প্যারামিট্রাইজেশনটির এই ভাঙ্গন স্থাপনার সমস্যার স্বাধীনতার প্রাকৃতিক ডিগ্রির সাথে মেলে - রানটাইম কনফিগারেশনের শংসাপত্রগুলি বাদ দিয়ে, তবে এগুলিকে অযত্নে ছড়িয়ে দেওয়া এড়াতে তাদের আলাদা করা ভাল।


5

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


4

প্রতিটি সরঞ্জামের কোড তার নিজস্ব রেপোতে যায়। যেমন

  1. জেনকিনস গ্রোভির টেম্পলেটটি জেনকিন্সের রেপোতে
  2. তার নিজস্ব রেপোতে (ভূমিকা, কার্যাদি, ইনভেন্টরি সাব ডিরেক্টরিগুলি সহ) উত্তরযুক্ত YAML প্লেবুকগুলি
  3. নিজস্ব রেপোতে ক্লাউডফর্মেশন / টেরফর্ম টেম্পলেটগুলি
  4. ডকার ফাইলগুলি তার নিজস্ব 5 .. এবং তেমন

এটি আপনাকে প্রক্রিয়া অর্কেস্টেশন এবং প্রতিটি পরিবেশের জন্য বিভিন্ন শাখা বজায় রাখার ক্ষেত্রে আরও ভাল স্কেল করতে সহায়তা করবে

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

উদাহরণস্বরূপ আপনার প্রোডাকশনে (মাস্টার ব্রাঞ্চ) উত্তরীয় চলমান ভি ২.১ থাকতে পারে তবে প্রোডে চালিত ডকার পাত্রে ভিপি ২ (মাস্টার শাখা) থাকতে পারে

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


2
এই পদ্ধতির সমস্যাটি হ'ল, ভি ২.১ কিএএতে রয়েছে এবং বৈধ নয় এবং আপনাকে জরুরীভাবে উত্পাদন প্যাচ করতে হবে, আপনি ভি 2.0 সংশোধন করতে পারবেন না এবং যদি আপনি এই প্যাচটির জন্য একটি ভি 2.2 তৈরি করেন তবে এটির উচ্চ ঝুঁকি রয়েছে v2.1 উত্পাদনে গেলে হারিয়ে বা ওভাররাইট করা, কোনও রেপোতে পৃথক কোডের পরিমাণ দিয়ে গুণ করুন এবং শীঘ্রই আপনার ব্যাকপোর্টগুলির একটি দুঃস্বপ্ন হবে (এটি কাজ করে, তবে আমাকে এই
দাবিটি

3
পরিবেশ / স্থাপনার-সুনির্দিষ্ট তথ্যগুলি ট্র্যাক রাখতে শাখা ব্যবহার করা আমার কাছে একটি পিঁপড়ের মতো দেখায়: আমাদের যদি 20 পরিবেশ থাকে তবে এর অর্থ আমাদের সিঙ্কে রাখার জন্য 20 টি শাখা রয়েছে ... সম্ভাব্য ত্রুটি এবং বিভ্রান্তির উত্স source পরিবেশ / স্থাপনা-নির্দিষ্ট তথ্যের উপর নজর রাখতে আপনি কেন কনফিগারেশন ফাইল ব্যবহার করেন না এবং এই শাখাগুলির সাথে আপনার ওয়ার্কফ্লো কী কাজ করছে তা আপনি ব্যাখ্যা করতে পারেন? এগুলো তুচ্ছ সমস্যা নয়!
মাইকেল লে বার্বিয়ার গ্রেনওয়াল্ড

3

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

এই কথাটি বলে, প্রশ্নের উত্তর:

কোনও কোড ভাণ্ডারে ডিওওপস সম্পর্কিত কোড এবং কনফিগারেশন কীভাবে গঠন করবেন?

কনফিগারেশনটি যদি প্রকল্পটি চালাতে হয় তবে এটি একই ডিরেক্টরিতে রাখা উচিত।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.