🥇কিভাবে পরীক্ষা শুরু করবেন উত্তরযোগ্য, এক বছরে একটি প্রকল্প রিফ্যাক্টর করুন এবং পাগল হবেন না

এই প্রতিলিপি ক্রিয়াকাণ্ড উপর DevOps-40 2020-03-18:

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

উত্তরাধিকারের জন্ম

দিন # 1: রোগী জিরো

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

দিন #89: উত্তরাধিকারের জন্ম

এটি নিজেরাই লক্ষ্য না করে, তারা যতটা সম্ভব এটি করতে চেয়েছিল, কিন্তু এটি উত্তরাধিকার হিসাবে পরিণত হয়েছিল। এটা কিভাবে হয়?

আমাদের এখানে একটি জরুরী কাজ আছে, আসুন একটি নোংরা হ্যাক করি এবং তারপরে এটি ঠিক করি।
আপনাকে ডকুমেন্টেশন লিখতে হবে না এবং এখানে কী ঘটছে তা সবকিছু পরিষ্কার।
আমি Ansible/Python/Bash/Terraform জানি! দেখো আমি কিভাবে এড়িয়ে যেতে পারি!
আমি একটি সম্পূর্ণ স্ট্যাক ওভারফ্লো বিকাশকারী এবং এটি স্ট্যাকওভারফ্লো থেকে অনুলিপি করেছি, আমি জানি না এটি কীভাবে কাজ করে, তবে এটি দুর্দান্ত দেখাচ্ছে এবং সমস্যার সমাধান করে।

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

- hosts: localhost
  tasks:
    - shell: echo -n Z >> a.txt && cat a.txt
      register: output
      delay: 1
      retries: 5
      until: not output.stdout.find("ZZZ")

দিন #109: সমস্যা সম্পর্কে সচেতনতা

প্রাথমিকভাবে ধারণা করা এবং বাস্তবায়িত IaC মডেলটি আর ব্যবহারকারী/ব্যবসায়/অন্যান্য দলগুলির প্রয়োজনীয়তা পূরণ করে না এবং অবকাঠামোতে পরিবর্তন করার সময় গ্রহণযোগ্য হবে না। এই মুহুর্তে, বোঝা যায় যে এটি পদক্ষেপ নেওয়ার সময়।

IaC রিফ্যাক্টরিং

দিন #139: আপনার কি সত্যিই রিফ্যাক্টরিং দরকার?

আপনি রিফ্যাক্টরে ছুটে যাওয়ার আগে, আপনাকে অবশ্যই বেশ কয়েকটি গুরুত্বপূর্ণ প্রশ্নের উত্তর দিতে হবে:

কেন আপনি এই সব প্রয়োজন?
তোমার কি সময় আছে?
জ্ঞান কি যথেষ্ট?

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

দিন #149: রিফ্যাক্টরিংয়ের প্রস্তুতি

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

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

উত্তরযোগ্য পরীক্ষার প্রচেষ্টা

আমরা কীভাবে প্রকল্পে উত্তরযোগ্য পরীক্ষাগুলি কভার করেছি তা বর্ণনা করতে যাওয়ার আগে, আমি সিদ্ধান্তগুলির প্রেক্ষাপট বোঝার জন্য আগে ব্যবহার করার সুযোগ পেয়েছিলাম এমন প্রচেষ্টা এবং পদ্ধতিগুলি বর্ণনা করব।

দিন নং -997: SDS বিধান

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

দিন # -701: উত্তরযোগ্য এবং পরীক্ষামূলক রান্নাঘর

উত্তরীয় পরীক্ষার ধারণার বিকাশ ছিল রেডিমেড সরঞ্জামের ব্যবহার, যথা টেস্ট কিচেন/কিচেন-সি এবং ইনস্পেক। পছন্দটি রুবির জ্ঞান দ্বারা নির্ধারিত হয়েছিল (আরো বিশদ বিবরণের জন্য, হাব্রে নিবন্ধটি দেখুন: YML প্রোগ্রামাররা কি Ansible পরীক্ষার স্বপ্ন দেখে?) দ্রুত কাজ করেছে, 40টি ভূমিকার জন্য প্রায় 10 মিনিট। আমরা ভার্চুয়াল মেশিনের একটি প্যাক তৈরি করেছি এবং ভিতরে পরীক্ষা চালিয়েছি।

সাধারণভাবে, সমাধানটি কাজ করেছিল, তবে ভিন্নতাজনিত কারণে কিছু পলল ছিল। যখন পরীক্ষিত লোকের সংখ্যা 13টি মৌলিক ভূমিকা এবং 2টি মেটা ভূমিকায় ছোট ভূমিকার সমন্বয়ে বৃদ্ধি করা হয়, তখন হঠাৎ করে পরীক্ষাগুলি 70 মিনিটের জন্য চলতে শুরু করে, যা প্রায় 2 গুণ বেশি। এক্সপি (চরম প্রোগ্রামিং) অনুশীলন সম্পর্কে কথা বলা কঠিন ছিল কারণ... কেউ 70 মিনিট অপেক্ষা করতে চায় না। এই পদ্ধতি পরিবর্তনের কারণ ছিল

দিন # -601: উত্তরযোগ্য এবং অণু

ধারণাগতভাবে, এটি টেস্টকিচেনের অনুরূপ, শুধুমাত্র আমরা ভূমিকা পরীক্ষাকে ডকারে নিয়েছি এবং স্ট্যাক পরিবর্তন করেছি। ফলস্বরূপ, 20টি ভূমিকার জন্য সময়টি 25-7 মিনিটে স্থিতিশীল হয়ে যায়।

পরীক্ষিত ভূমিকার সংখ্যা 17-এ বৃদ্ধি করে এবং 45টি ভূমিকা লিন্টিং করে, আমরা 28 মিনিটের মধ্যে 2 জেনকিন্স স্লেভের উপর এটি চালিয়েছি।

দিন #167: প্রকল্পে উত্তরযোগ্য পরীক্ষা যোগ করা

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

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

রিফ্যাক্টরিং সহজ:

খাওয়া.
ঘুম.
কোড।
আইএসি পরীক্ষা।
পুনরাবৃত্তি

এবং আমরা এটি পুনরাবৃত্তি করি যতক্ষণ না আমরা উদ্দিষ্ট লক্ষ্যে পৌঁছাই।

এখনই সবকিছু পরীক্ষা করা শুরু করা সম্ভব নাও হতে পারে, তাই আমাদের প্রথম কাজটি ছিল লিন্টিং এবং সিনট্যাক্স পরীক্ষা করে শুরু করা।

দিন #181: গ্রিন বিল্ড মাস্টার

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

লাল পরীক্ষা খারাপ।
আমি কিছু ঠিক করতে এসেছি এবং একই সাথে কোডটিকে আপনার আগের চেয়ে একটু ভাল করে তুলছি।

দিন #193: লিন্টিং থেকে ইউনিট পরীক্ষা পর্যন্ত

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

দিন #211: ইউনিট থেকে ইন্টিগ্রেশন পরীক্ষা

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

জেনকিনস ব্যবহার করে, আমরা অনেকগুলি পর্যায় তৈরি করেছি যা সমান্তরালভাবে ভূমিকা/প্লেবুকগুলিকে লিন্টেড করে, তারপর পাত্রে ইউনিট পরীক্ষা এবং অবশেষে ইন্টিগ্রেশন পরীক্ষা।

জেনকিন্স + ডকার + উত্তরযোগ্য = পরীক্ষা

রেপো চেকআউট করুন এবং বিল্ড স্টেজ তৈরি করুন।
সমান্তরালভাবে লিন্ট প্লেবুক পর্যায় চালান।
সমান্তরালভাবে লিন্ট রোল স্টেজ চালান।
সমান্তরালভাবে সিনট্যাক্স চেক ভূমিকা পর্যায় চালান।
সমান্তরালভাবে পরীক্ষার ভূমিকা পর্যায়গুলি চালান।
1. লিন্ট ভূমিকা.
2. অন্যান্য ভূমিকার উপর নির্ভরতা পরীক্ষা করুন।
3. সিনট্যাক্স পরীক্ষা করুন।
4. ডকার উদাহরণ তৈরি করুন
5. molecule/default/playbook.yml চালান।
6. আত্মশক্তি পরীক্ষা করুন।
ইন্টিগ্রেশন পরীক্ষা চালান
শেষ

দিন #271: বাস ফ্যাক্টর

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

এবং এটি এখানে আরামদায়ক হওয়া উচিত। এটি একটি পর্যালোচনা করা সুবিধাজনক, এটি কোন কাজটি করা হয়েছিল এবং আলোচনার ইতিহাসের কাঠামোর মধ্যে দেখুন৷ আমরা জেনকিন্স + বিটবাকেট + জিরা সংহত করেছি।

কিন্তু এই হিসাবে, একটি পর্যালোচনা একটি প্যানেসিয়া নয়; একরকম, আমরা মাস্টার কোডে প্রবেশ করেছি, যা আমাদের ফ্লপ পরীক্ষা করেছে:

- get_url:
    url: "{{ actk_certs }}/{{ item.1 }}"
    dest: "{{ actk_src_tmp }}/"
    username: "{{ actk_mvn_user }}"
    password: "{{ actk_mvn_pass }}"
  with_subelements:
    - "{{ actk_cert_list }}"
    - "{{ actk_certs }}"
  delegate_to: localhost

- copy:
    src: "{{ actk_src_tmp }}/{{ item.1 }}"
    dest: "{{ actk_dst_tmp }}"
  with_subelements:
    - "{{ actk_cert_list }}"
    - "{{ actk_certs }}"

তারপর তারা এটি ঠিক করেছে, কিন্তু পলি থেকে গেছে।

get_url:
    url: "{{ actk_certs }}/{{ actk_item }}"
    dest: "{{ actk_src_tmp }}/{{ actk_item }}"
    username: "{{ actk_mvn_user }}"
    password: "{{ actk_mvn_pass }}"
  loop_control:
    loop_var: actk_item
  with_items: "{{ actk_cert_list }}"
  delegate_to: localhost

- copy:
    src: "{{ actk_src_tmp }}/{{ actk_item }}"
    dest: "{{ actk_dst_tmp }}"
  loop_control:
    loop_var: actk_item
  with_items: "{{ actk_cert_list }}"

দিন #311: পরীক্ষা দ্রুত করা

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

কঠোরভাবে বলতে গেলে, ব্যবস্থার একটি সেট ছিল:

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

ফলস্বরূপ, জেনকিন্সের পাইপলাইনও একীভূত হয়েছিল

নির্মাণের পর্যায়গুলি তৈরি করুন।
সমান্তরাল সব লিন্ট.
সমান্তরালভাবে পরীক্ষার ভূমিকা পর্যায়গুলি চালান।
শেষ করুন।

পাঠ শিখেছি

গ্লোবাল ভেরিয়েবল এড়িয়ে চলুন

Ansible গ্লোবাল ভেরিয়েবল ব্যবহার করে, ফর্মের একটি আংশিক সমাধান আছে ব্যক্তিগত_ভূমিকা_ভার্স, কিন্তু এটি একটি নিরাময় নয়।

আমাকে যদি আপনি একটি উদাহরণ দিতে। আমাদের আছে role_a и role_b

# cat role_a/defaults/main.yml
---
msg: a

# cat role_a/tasks/main.yml
---
- debug:
    msg: role_a={{ msg }}

# cat role_b/defaults/main.yml
---
msg: b

# cat role_b/tasks/main.yml
---
- set_fact:
    msg: b
- debug:
    msg: role_b={{ msg }}

- hosts: localhost
  vars:
    msg: hello
  roles:
    - role: role_a
    - role: role_b
  tasks:
    - debug:
        msg: play={{msg}}

মজার বিষয় হল যে প্লেবুকগুলির ফলাফল এমন জিনিসগুলির উপর নির্ভর করবে যা সবসময় সুস্পষ্ট নয়, যেমন ভূমিকা তালিকাভুক্ত করা হয় এমন ক্রম। দুর্ভাগ্যবশত, এটি হল Ansible-এর প্রকৃতি এবং সবচেয়ে ভাল জিনিসটি হল কিছু ধরনের চুক্তি ব্যবহার করা, উদাহরণস্বরূপ, একটি ভূমিকার মধ্যে, শুধুমাত্র এই ভূমিকায় বর্ণিত পরিবর্তনশীল ব্যবহার করা।

খারাপ: গ্লোবাল ভেরিয়েবল ব্যবহার করুন।

# cat roles/some_role/tasks/main.yml
---
debug:
  var: java_home

ভাল: ভি defaults প্রয়োজনীয় ভেরিয়েবল সংজ্ঞায়িত করুন এবং পরে শুধুমাত্র তাদের ব্যবহার করুন।

# cat roles/some_role/defaults/main.yml
---
r__java_home:
 "{{ java_home | default('/path') }}"

# cat roles/some_role/tasks/main.yml
---
debug:
  var: r__java_home

উপসর্গ ভূমিকা ভেরিয়েবল

খারাপ: গ্লোবাল ভেরিয়েবল ব্যবহার করুন।

# cat roles/some_role/defaults/main.yml
---
db_port: 5432

ভাল: ভেরিয়েবলের ভূমিকাতে, ভূমিকার নামের সাথে উপসর্গযুক্ত ভেরিয়েবল ব্যবহার করুন; এটি, ইনভেন্টরি দেখে, কী ঘটছে তা বোঝা সহজ করে তুলবে।

# cat roles/some_role/defaults/main.yml
---
some_role__db_port: 5432

লুপ কন্ট্রোল ভেরিয়েবল ব্যবহার করুন

খারাপ: লুপগুলিতে স্ট্যান্ডার্ড ভেরিয়েবল ব্যবহার করুন item, যদি এই টাস্ক/প্লেবুক কোথাও অন্তর্ভুক্ত করা হয়, তাহলে এটি অপ্রত্যাশিত আচরণের দিকে নিয়ে যেতে পারে

---
- hosts: localhost
  tasks:
    - debug:
        msg: "{{ item }}"
      loop:
        - item1
        - item2

ভাল: একটি লুপের মাধ্যমে একটি ভেরিয়েবলকে পুনরায় সংজ্ঞায়িত করুন loop_var.

---
- hosts: localhost
  tasks:
    - debug:
        msg: "{{ item_name }}"
      loop:
        - item1
        - item2
      loop_control:
        loop_var: item_name

ইনপুট ভেরিয়েবল চেক করুন

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

ভাল: ভেরিয়েবল চেক করুন.

- name: "Verify that required string variables are defined"
  assert:
    that: ahs_var is defined and ahs_var | length > 0 and ahs_var != None
    fail_msg: "{{ ahs_var }} needs to be set for the role to work "
    success_msg: "Required variables {{ ahs_var }} is defined"
  loop_control:
    loop_var: ahs_var
  with_items:
    - ahs_item1
    - ahs_item2
    - ahs_item3

হ্যাশ অভিধান এড়িয়ে চলুন, সমতল কাঠামো ব্যবহার করুন

যদি একটি ভূমিকা তার প্যারামিটারগুলির একটিতে একটি হ্যাশ/অভিধান আশা করে, তাহলে আমরা যদি চাইল্ড প্যারামিটারগুলির একটি পরিবর্তন করতে চাই, তাহলে আমাদের পুরো হ্যাশ/অভিধানটি ওভাররাইড করতে হবে, যা কনফিগারেশন জটিলতা বাড়াবে।

খারাপ: হ্যাশ/অভিধান ব্যবহার করুন।

---
user:
  name: admin
  group: admin

ভাল: একটি সমতল পরিবর্তনশীল কাঠামো ব্যবহার করুন.

---
user_name: admin
user_group: "{{ user_name }}"

অদম্য প্লেবুক এবং ভূমিকা তৈরি করুন

ভূমিকা এবং প্লেবুক অবশ্যই বুদ্ধিমান হতে হবে, কারণ কনফিগারেশন ড্রিফট এবং কিছু ভাঙ্গার ভয় কমায়। কিন্তু যদি আপনি অণু ব্যবহার করেন, তাহলে এটি ডিফল্ট আচরণ।

কমান্ড শেল মডিউল ব্যবহার করা এড়িয়ে চলুন

একটি শেল মডিউল ব্যবহার করার ফলে ঘোষণামূলক একটির পরিবর্তে একটি অপরিহার্য বর্ণনার দৃষ্টান্ত দেখা যায়, যা Ansible-এর মূল।

অণুর মাধ্যমে আপনার ভূমিকা পরীক্ষা করুন

অণু একটি খুব নমনীয় জিনিস, আসুন কয়েকটি দৃশ্যকল্প দেখি।

অণু একাধিক দৃষ্টান্ত

В molecule.yml বিভাগে platforms আপনি অনেক হোস্ট বর্ণনা করতে পারেন যা আপনি স্থাপন করতে পারেন।

---
    driver:
      name: docker
    platforms:
      - name: postgresql-instance
        hostname: postgresql-instance
        image: registry.example.com/postgres10:latest
        pre_build_image: true
        override_command: false
        network_mode: host
      - name: app-instance
        hostname: app-instance
        pre_build_image: true
        image: registry.example.com/docker_centos_ansible_tests
        network_mode: host

সেই অনুযায়ী, এই হোস্ট তারপর হতে পারে converge.yml ব্যবহার করুন:

---
- name: Converge all
  hosts: all
  vars:
    ansible_user: root
  roles:
    - role: some_role

- name: Converge db
  hosts: db-instance
  roles:
    - role: some_db_role

- name: Converge app
  hosts: app-instance
  roles:
    - role: some_app_role

উত্তরযোগ্য যাচাইকারী

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

---
- name: Verify
  hosts: all
  tasks:
    - name: copy config
      copy:
        src: expected_standalone.conf
        dest: /root/wildfly/bin/standalone.conf
        mode: "0644"
        owner: root
        group: root
      register: config_copy_result

    - name: Certify that standalone.conf changed
      assert:
        that: not config_copy_result.changed

অথবা পরিষেবাটি স্থাপন করুন, এটি উপলব্ধ হওয়ার জন্য অপেক্ষা করুন এবং একটি ধূমপান পরীক্ষা করুন:

---
  - name: Verify
    hosts: solr
    tasks:
      - command: /blah/solr/bin/solr start -s /solr_home -p 8983 -force
      - uri:
          url: http://127.0.0.1:8983/solr
          method: GET
          status_code: 200
        register: uri_result
        until: uri_result is not failed
        retries: 12
        delay: 10
      - name: Post documents to solr
        command: /blah/solr/bin/post -c master /exampledocs/books.csv

মডিউল এবং প্লাগইনগুলিতে জটিল যুক্তি রাখুন

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

টিপস এবং ট্রিকস সংক্ষিপ্ত করুন

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

উপসংহার

আপনি শুধু যেতে পারবেন না এবং একটি প্রকল্পের পরিকাঠামো রিফ্যাক্টর করতে পারবেন না, এমনকি আপনার IaC থাকলেও। এটি একটি দীর্ঘ প্রক্রিয়া যার জন্য ধৈর্য, সময় এবং জ্ঞান প্রয়োজন।

লিংক

UPD1 2020.05.01 20:30 - প্লেবুকগুলির প্রাথমিক প্রোফাইলিংয়ের জন্য আপনি ব্যবহার করতে পারেন callback_whitelist = profile_tasks দীর্ঘ সময়ের জন্য ঠিক কি কাজ করে তা বুঝতে। তারপর আমরা মাধ্যমে যেতে উত্তরযোগ্য ত্বরণ ক্লাসিক. আপনিও চেষ্টা করে দেখতে পারেন মাইটোজেন
UPD2 2020.05.03 16:34 - ইংরেজি সংস্করণ

উত্স: www.habr.com

কিভাবে Ansible পরীক্ষা শুরু করবেন, এক বছরের মধ্যে প্রজেক্টটি রিফ্যাক্টর করবেন এবং পাগল হবেন না