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

এটি আমার একটি প্রতিলিপি ক্রিয়াকাণ্ড উপর DevopsConf 2019-05-28.

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

ইংরেজি সংস্করণ
রাশিয়ান সংস্করণ
ড্রাই রান 2019-04-24 SpbLUG
DevopsConf 2019-05-28 থেকে ভিডিও(RU)
DINS DevOps ইভেনিং 2019-06-20 থেকে ভিডিও(RU)
স্লাইডগুলি

বাশ ইতিহাস হিসাবে পরিকাঠামো

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

কিছু ইচ্ছা সঙ্গে, আমরা এটা বলতে পারেন বাশ ইতিহাস হিসাবে পরিকাঠামো এটি কোডের মত:

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

আমি কি করব?

কোড হিসাবে পরিকাঠামো

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

শুকনো

একটি স্টোরেজ সিস্টেম উন্নয়ন প্রকল্পে, একটি সাবটাস্ক ছিল পর্যায়ক্রমে SDS কনফিগার করুন: আমরা একটি নতুন রিলিজ প্রকাশ করছি - এটি আরও পরীক্ষার জন্য রোল আউট করা প্রয়োজন৷ কাজটি অত্যন্ত সহজ:

ssh এর মাধ্যমে এখানে লগ ইন করুন এবং কমান্ডটি চালান।
সেখানে ফাইলটি কপি করুন।
এখানে কনফিগারেশন সংশোধন করুন।
সেখানে পরিষেবা শুরু করুন
...
লাভ!

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

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

CFM এর জন্য সলিড

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

একক দায়িত্ব নীতি

প্রতিটি ক্লাস শুধুমাত্র একটি কাজ সম্পাদন করে।

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

খোলা বন্ধ নীতি

খোলা/বন্ধ নীতি।

এক্সটেনশনের জন্য খোলা: মানে নতুন সত্তার ধরন তৈরি করে একটি সত্তার আচরণ প্রসারিত করা যেতে পারে।
পরিবর্তনের জন্য বন্ধ: একটি সত্তার আচরণ প্রসারিত করার ফলে, সেই সত্তাগুলি ব্যবহার করে এমন কোডে কোনও পরিবর্তন করা উচিত নয়।

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

লিসকভ প্রতিস্থাপন নীতি

বারবারা লিসকভের প্রতিস্থাপন নীতি। একটি প্রোগ্রামের অবজেক্টগুলি অবশ্যই প্রোগ্রামের সঠিক সম্পাদন পরিবর্তন না করে তাদের সাব-টাইপের উদাহরণগুলির সাথে প্রতিস্থাপনযোগ্য হতে হবে

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

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

এখানে সমস্যাটি হল যে এটি Ansible এ বাস্তবায়ন করা অসম্ভব, যার ফলস্বরূপ কিছু চুক্তি দলের মধ্যে উপস্থিত হয়।

ইন্টারফেস সেগ্রিগেশন নীতি

ইন্টারফেস বিচ্ছেদ নীতি: “অনেক ক্লায়েন্ট-নির্দিষ্ট ইন্টারফেস একটি সাধারণ-উদ্দেশ্য ইন্টারফেসের চেয়ে ভাল।

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

নির্ভরতা বিপরীত নীতি

নির্ভরতা বিপরীত নীতি। উচ্চ স্তরের মডিউলগুলি নিম্ন স্তরের মডিউলগুলির উপর নির্ভর করা উচিত নয়। উভয় ধরনের মডিউল অবশ্যই বিমূর্ততার উপর নির্ভর করবে। বিমূর্ত বিবরণের উপর নির্ভর করা উচিত নয়। বিশদ বিমূর্ততার উপর নির্ভর করতে হবে।

এখানে উদাহরণ একটি antipattern উপর ভিত্তি করে করা হবে.

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

সেগুলো. হাই-লেভেল অ্যাপ্লিকেশান ডিপ্লোয়মেন্ট লজিক হাইপারভাইজারের নিম্ন স্তরে নির্ভরশীলতার সাথে প্রবাহিত হয় এবং এই লজিকটি পুনরায় ব্যবহার করার সময় এর অর্থ সমস্যা হয়। এভাবে করবেন না।

মিথষ্ক্রিয়া

কোড হিসাবে পরিকাঠামো শুধুমাত্র কোড সম্পর্কে নয়, কোড এবং মানুষের মধ্যে সম্পর্ক, অবকাঠামো বিকাশকারীদের মধ্যে মিথস্ক্রিয়া সম্পর্কেও।

বাস ফ্যাক্টর

ধরুন আপনার প্রজেক্টে ভাস্য আছে। Vasya আপনার পরিকাঠামো সম্পর্কে সবকিছু জানে, Vasya হঠাৎ অদৃশ্য হয়ে গেলে কি হবে? এটি একটি খুব বাস্তব পরিস্থিতি, কারণ তাকে একটি বাস দ্বারা আঘাত করা হতে পারে। মাঝেমধ্যে ইহা ঘটে. যদি এটি ঘটে এবং কোড, এর গঠন, এটি কীভাবে কাজ করে, উপস্থিতি এবং পাসওয়ার্ড সম্পর্কে জ্ঞান টিমের মধ্যে বিতরণ না করা হয়, তাহলে আপনি অনেকগুলি অপ্রীতিকর পরিস্থিতির সম্মুখীন হতে পারেন। এই ঝুঁকিগুলি কমাতে এবং দলের মধ্যে জ্ঞান বিতরণ করতে, আপনি বিভিন্ন পদ্ধতি ব্যবহার করতে পারেন

পেয়ার ডেভপসিং

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

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

কোড পূনর্বিবেচনা

বিষয়গতভাবে, অবকাঠামো সম্পর্কে জ্ঞান ছড়িয়ে দেওয়া এবং এটি কোড পর্যালোচনা ব্যবহার করে কীভাবে কাজ করে তা আরও কার্যকর ছিল:

রিপোজিটরিতে কোড দ্বারা পরিকাঠামো বর্ণনা করা হয়।
পরিবর্তন একটি পৃথক শাখায় ঘটে।
একটি মার্জ অনুরোধের সময়, আপনি পরিকাঠামোতে পরিবর্তনের ডেল্টা দেখতে পারেন।

এখানে হাইলাইট ছিল যে পর্যালোচকদের একে একে নির্বাচন করা হয়েছিল, একটি সময়সূচী অনুযায়ী, অর্থাৎ কিছু সম্ভাবনার সাথে আপনি একটি নতুন পরিকাঠামোতে আরোহণ করবেন।

কোড স্টাইল

সময়ের সাথে সাথে, পর্যালোচনার সময় ঝগড়া দেখা দিতে শুরু করে, কারণ... পর্যালোচকদের নিজস্ব শৈলী ছিল এবং পর্যালোচকদের ঘূর্ণন তাদের বিভিন্ন শৈলী দিয়ে স্ট্যাক করেছে: 2টি স্পেস বা 4টি, ক্যামেলকেস বা স্নেক_কেস। এটা তাৎক্ষণিকভাবে বাস্তবায়ন করা সম্ভব হয়নি।

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

গ্রিন বিল্ড মাস্টার

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

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

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

IaC টেস্টিং

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

কেউ হয়তো প্রশ্ন করতে পারে, কেন জটিল অবকাঠামোকে আরও জটিল করা? অবকাঠামোর জন্য পরীক্ষাগুলি, কোডের মতোই, সরলীকরণ সম্পর্কে নয়, তবে আপনার অবকাঠামো কীভাবে কাজ করা উচিত তা জানার বিষয়ে।

IaC টেস্টিং পিরামিড

IaC পরীক্ষা: স্ট্যাটিক বিশ্লেষণ

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

বাশ কঠিন

একটা তুচ্ছ উদাহরণ দেখি। বর্তমান ডিরেক্টরির সমস্ত ফাইল নির্বাচন করুন এবং অন্য অবস্থানে অনুলিপি করুন। প্রথম জিনিস যা মনে আসে:

for i in * ; do 
    cp $i /some/path/$i.bak
done

ফাইলের নামে একটি স্পেস থাকলে কি হবে? আচ্ছা, ঠিক আছে, আমরা স্মার্ট, আমরা জানি কিভাবে উদ্ধৃতি ব্যবহার করতে হয়:

for i in * ; do cp "$i" "/some/path/$i.bak" ; done

সাবাশ? না! ডিরেক্টরিতে কিছু না থাকলে কি হবে, যেমন গ্লোবিং কাজ করবে না।

find . -type f -exec mv -v {} dst/{}.bak ;

এখন ভালো হয়েছে? না... ফাইলের নামে কী থাকতে পারে তা ভুলে গেছি n.

touch x
mv x  "$(printf "foonbar")"
find . -type f -print0 | xargs -0 mv -t /path/to/target-dir

স্ট্যাটিক বিশ্লেষণ সরঞ্জাম

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

ভাষা
টুল

সজোরে আঘাত
শেলচেক

চুনি
রুবোকপ

পাইথন
পাইলট

ansible
উত্তরযোগ্য লিন্ট

IaC পরীক্ষা: ইউনিট পরীক্ষা

আমরা আগের উদাহরণ থেকে দেখেছি, লিন্টারগুলি সর্বশক্তিমান নয় এবং সমস্ত সমস্যার ক্ষেত্রগুলি নির্দেশ করতে পারে না। আরও, সফ্টওয়্যার বিকাশে পরীক্ষার সাথে সাদৃশ্য দ্বারা, আমরা ইউনিট পরীক্ষাগুলি স্মরণ করতে পারি। অবিলম্বে কি মনে আসে shunit, জুনিট, rspec, পাইস্ট. কিন্তু উত্তরদাতা, শেফ, সল্টস্ট্যাক এবং তাদের মতো অন্যদের নিয়ে কী করবেন?

একেবারে শুরুতে আমরা কথা বলেছি সলিড এবং আমাদের অবকাঠামো ছোট ইট দিয়ে গঠিত হওয়া উচিত। তাদের সময় এসেছে।

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

IaC টেস্টিং: ইউনিট টেস্টিং টুল

প্রশ্ন, CFM পরীক্ষা কি কি? আপনি কেবল স্ক্রিপ্টটি চালাতে পারেন, অথবা আপনি এর জন্য প্রস্তুত-তৈরি সমাধান ব্যবহার করতে পারেন:

CFM
টুল

Ansible
টেস্টিনফ্রা

মাথা
পরিদর্শক

মাথা
সার্ভারস্পেক

সল্টস্ট্যাক
গস

testinfra জন্য উদাহরণ, যে ব্যবহারকারীদের চেক test1, test2 বিদ্যমান এবং একটি গ্রুপে আছে sshusers:

def test_default_users(host):
    users = ['test1', 'test2' ]
    for login in users:
        assert host.user(login).exists
        assert 'sshusers' in host.user(login).groups

কি নির্বাচন করতে? প্রশ্নটি জটিল এবং অস্পষ্ট, এখানে 2018-2019 এর জন্য গিথুবে প্রকল্পগুলির পরিবর্তনের একটি উদাহরণ রয়েছে:

IaC টেস্টিং ফ্রেমওয়ার্ক

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

CFM
টুল

Ansible
অণু

মাথা
টেস্ট রান্নাঘর

Terraform
টেরেটেস্ট

2018-2019 এর জন্য গিথুবে প্রকল্পগুলির পরিবর্তনের উদাহরণ:

অণু বনাম টেস্টকিচেন

প্রাথমিকভাবে আমরা টেস্টকিচেন ব্যবহার করার চেষ্টা করেছি:

সমান্তরালভাবে একটি VM তৈরি করুন।
উত্তরযোগ্য ভূমিকা প্রয়োগ করুন।
পরিদর্শন চালান।

25-35টি ভূমিকার জন্য এটি 40-70 মিনিট কাজ করেছে, যা দীর্ঘ ছিল।

পরবর্তী ধাপটি ছিল জেনকিন্স/ডকার/অ্যানসিবল/অণুতে রূপান্তর। আদর্শগতভাবে সবকিছু একই

লিন্ট প্লেবুক।
ভূমিকা লাইন আপ.
কন্টেইনার চালু করুন
উত্তরযোগ্য ভূমিকা প্রয়োগ করুন।
টেস্টিনফ্রা চালান।
আত্মশক্তি পরীক্ষা করুন।

40টি ভূমিকার জন্য লিন্টিং এবং এক ডজনের জন্য পরীক্ষা প্রায় 15 মিনিট সময় নিতে শুরু করে।

কী বেছে নেবেন তা অনেক বিষয়ের উপর নির্ভর করে, যেমন ব্যবহৃত স্ট্যাক, দলে দক্ষতা ইত্যাদি। এখানে সবাই নিজেরাই সিদ্ধান্ত নেয় কিভাবে ইউনিট পরীক্ষার প্রশ্ন বন্ধ করতে হয়

IaC টেস্টিং: ইন্টিগ্রেশন টেস্ট

পরিকাঠামো পরীক্ষার পিরামিডের পরবর্তী ধাপ হবে ইন্টিগ্রেশন পরীক্ষা। তারা ইউনিট পরীক্ষার অনুরূপ:

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

মোটামুটিভাবে বলতে গেলে, আমরা ইউনিট পরীক্ষার মতো সিস্টেমের একটি পৃথক উপাদানের কার্যকারিতা পরীক্ষা করি না, আমরা সার্ভারটি সামগ্রিকভাবে কীভাবে কনফিগার করা হয়েছে তা পরীক্ষা করি।

IaC পরীক্ষা: শেষ থেকে শেষ পরীক্ষা

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

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

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

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

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

উপসংহার

কোড হিসাবে অবকাঠামো

সংগ্রহস্থলে কোড।
মানুষের মিথস্ক্রিয়া.
অবকাঠামো পরীক্ষা।

লিঙ্ক

উত্স: www.habr.com

পরিকাঠামো কোডের 200 লাইন পরীক্ষা করে আমি যা শিখেছি