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

এই সর্বজনীন অন্যায় সংশোধন করার জন্য, যারা ইতিমধ্যে এটি জানেন তাদের জন্য আমি Ansible-এর একটি ভূমিকা লেখার সিদ্ধান্ত নিয়েছি। আমি আপনাকে সতর্ক করে দিচ্ছি, এটি মানুষের রিটেলিং নয়, এটি অনেকগুলি অক্ষর এবং কোনও ছবি নেই।

পাঠকের প্রত্যাশিত স্তর হল যে ইয়ামলার কয়েক হাজার লাইন ইতিমধ্যেই লেখা হয়েছে, কিছু ইতিমধ্যেই তৈরি হচ্ছে, কিন্তু "একরকমভাবে সবকিছু আঁকাবাঁকা।"

নাম

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

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

উত্তরযোগ্য-প্লেবুক প্লেবুকটি চালায়। একটি প্লেবুক হল yml/yaml এক্সটেনশন সহ একটি ফাইল, যার ভিতরে এরকম কিছু আছে:

---
- hosts: group1
  roles:
    - role1

- hosts: group2,group3
  tasks:
    - debug:

আমরা ইতিমধ্যে বুঝতে পেরেছি যে এই সম্পূর্ণ ফাইলটি একটি প্লেবুক। আমরা দেখাতে পারি ভূমিকা কোথায় এবং কাজগুলি কোথায়। কিন্তু খেলা কই? এবং নাটক এবং ভূমিকা বা playbook মধ্যে পার্থক্য কি?

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

সুতরাং, মনে রাখবেন: প্লেবুক হল একটি তালিকা যা খেলা এবং import_playbook.
এটি একটি নাটক:

- hosts: group1
  roles:
    - role1

এবং এটি আরেকটি নাটক:

- hosts: group2,group3
  tasks:
    - debug:

খেলা কি? সে কেন?

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

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

সহজ, তাই না? কিভাবে এটি অন্যথায় হতে পারে?

চরিত্রগত মুহূর্তগুলির মধ্যে একটি যখন লোকেদের এটি খেলার মাধ্যমে না করার ইচ্ছা থাকে তা হল "ভূমিকা যা সবকিছু সেট করে।" আমি একটি ভূমিকা রাখতে চাই যা প্রথম প্রকারের সার্ভার এবং দ্বিতীয় প্রকারের সার্ভার উভয়কেই কনফিগার করে।

একটি প্রত্নতাত্ত্বিক উদাহরণ হল পর্যবেক্ষণ। আমি একটি মনিটরিং ভূমিকা রাখতে চাই যা মনিটরিং কনফিগার করবে। পর্যবেক্ষণ ভূমিকা নিরীক্ষণ হোস্ট (খেলা অনুযায়ী) নিয়োগ করা হয়. কিন্তু দেখা যাচ্ছে যে নিরীক্ষণের জন্য আমরা যে হোস্টগুলি পর্যবেক্ষণ করছি তাদের কাছে প্যাকেজগুলি সরবরাহ করতে হবে। কেন প্রতিনিধি ব্যবহার করবেন না? আপনাকে iptables কনফিগার করতে হবে। প্রতিনিধি? মনিটরিং সক্ষম করার জন্য আপনাকে DBMS-এর জন্য একটি কনফিগারেশন লিখতে/শুদ্ধ করতে হবে। প্রতিনিধি এবং যদি সৃজনশীলতার অভাব হয়, তাহলে আপনি একটি প্রতিনিধি দল করতে পারেন include_role একটি নেস্টেড লুপে গ্রুপের তালিকায় এবং ভিতরে একটি কৌশলী ফিল্টার ব্যবহার করে include_role আপনি আরো করতে পারেন delegate_to আবার এবং আমরা চলে যাই...

একটি শুভ কামনা - একটি একক নিরীক্ষণের ভূমিকা থাকা, যা "সব কিছু করে" - আমাদেরকে সম্পূর্ণ নরকের দিকে নিয়ে যায় যেখান থেকে প্রায়শই কেবল একটি উপায় থাকে: স্ক্র্যাচ থেকে সবকিছু পুনর্লিখন করা।

এখানে ভুলটা কোথায় হলো? যে মুহুর্তে আপনি আবিষ্কার করেছেন যে হোস্ট X-এ টাস্ক "x" করতে আপনাকে Y হোস্টে যেতে হবে এবং সেখানে "y" করতে হবে, আপনাকে একটি সাধারণ অনুশীলন করতে হবে: যান এবং নাটক লিখুন, যা হোস্ট Y-এ y করে। "x" এ কিছু যোগ করবেন না, তবে এটি স্ক্র্যাচ থেকে লিখুন। এমনকি হার্ডকোড ভেরিয়েবল সহ।

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

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

ত্রুটি হল: ভূমিকা একটি লাইব্রেরি ফাংশন। এই সাদৃশ্যটি এত ভাল সূচনা নষ্ট করেছে যে এটি দেখতে কেবল দুঃখজনক। ভূমিকা একটি লাইব্রেরি ফাংশন নয়. তিনি গণনা করতে পারেন না এবং তিনি প্লে-লেভেল সিদ্ধান্ত নিতে পারেন না। খেলার সিদ্ধান্ত কি আমাকে মনে করিয়ে দিন?

ধন্যবাদ, আপনি সঠিক. কোন হোস্টে কোন কাজ এবং ভূমিকা পালন করতে হবে সে সম্পর্কে প্লে একটি সিদ্ধান্ত নেয় (আরো সঠিকভাবে, এতে তথ্য রয়েছে)।

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

কেন Ansible-এ প্রোগ্রাম করা বিপজ্জনক এবং কেন COBOL Ansible-এর চেয়ে ভাল আমরা ভেরিয়েবল এবং জিঞ্জা সম্পর্কে অধ্যায়ে কথা বলব। আপাতত, একটা কথা বলে রাখি - আপনার প্রতিটি গণনা গ্লোবাল ভেরিয়েবলের পরিবর্তনের একটি অমার্জনীয় চিহ্ন রেখে যায় এবং আপনি এটি সম্পর্কে কিছুই করতে পারবেন না। দুটি "চিহ্ন" ছেদ করার সাথে সাথেই সবকিছু চলে গেল।

স্ক্যামিশের জন্য নোট: ভূমিকা অবশ্যই নিয়ন্ত্রণ প্রবাহকে প্রভাবিত করতে পারে। খাওয়া delegate_to এবং এটা যুক্তিসঙ্গত ব্যবহার আছে. খাওয়া meta: end host/play. কিন্তু! মনে রাখবেন আমরা মৌলিক বিষয় শেখান? সম্পর্কে ভুলে গেছি delegate_to. আমরা সবচেয়ে সহজ এবং সবচেয়ে সুন্দর Ansible কোড সম্পর্কে কথা বলছি। যা পড়া সহজ, লিখতে সহজ, ডিবাগ করা সহজ, পরীক্ষা করা সহজ এবং সম্পূর্ণ করা সহজ। সুতরাং, আবার একবার:

play and only play সিদ্ধান্ত নেয় কোন হোস্টে কি চালানো হবে।

এই বিভাগে, আমরা খেলা এবং ভূমিকার মধ্যে বিরোধিতা মোকাবেলা করেছি। এখন কাজ বনাম ভূমিকা সম্পর্কে কথা বলা যাক।

কাজ এবং ভূমিকা

খেলা বিবেচনা করুন:

- hosts: somegroup
  pre_tasks:
    - some_tasks1:
  roles:
     - role1
     - role2
  post_tasks:
     - some_task2:
     - some_task3:

ধরা যাক আপনি foo করতে হবে. এবং এটা মনে হচ্ছে foo: name=foobar state=present. আমি এটা কোথায় লিখতে হবে? পূর্বে? পোস্ট? একটি ভূমিকা তৈরি করুন?

...এবং কাজগুলো কোথায় গেল?

আমরা আবার বেসিক দিয়ে শুরু করছি - প্লে ডিভাইস। আপনি যদি এই ইস্যুতে ভাসতে থাকেন, তাহলে আপনি অন্য সব কিছুর ভিত্তি হিসেবে খেলা ব্যবহার করতে পারবেন না এবং আপনার ফলাফল হবে "নড়বড়ে"।

প্লে ডিভাইস: হোস্ট নির্দেশিকা, নিজে খেলার জন্য সেটিংস এবং প্রি_টাস্ক, কাজ, ভূমিকা, পোস্ট_টাস্ক বিভাগ। খেলার জন্য বাকি প্যারামিটারগুলো এখন আমাদের কাছে গুরুত্বপূর্ণ নয়।

কাজ এবং ভূমিকা সহ তাদের বিভাগের ক্রম: pre_tasks, roles, tasks, post_tasks. যেহেতু শব্দার্থগতভাবে মৃত্যুদন্ডের ক্রম এর মধ্যে tasks и roles পরিষ্কার নয়, তাহলে সেরা অনুশীলন বলে যে আমরা একটি বিভাগ যোগ করছি tasks, শুধুমাত্র যদি না roles... আছে যদি roles, তারপর সমস্ত সংযুক্ত কাজ বিভাগে স্থাপন করা হয় pre_tasks/post_tasks.

যা অবশিষ্ট থাকে তা হল সবকিছু শব্দার্থগতভাবে পরিষ্কার: প্রথম pre_tasksতারপর, rolesতারপর, post_tasks.

কিন্তু আমরা এখনও প্রশ্নের উত্তর পাইনি: মডিউল কল কোথায়? foo লিখ? আমাদের কি প্রতিটি মডিউলের জন্য একটি সম্পূর্ণ ভূমিকা লিখতে হবে? নাকি সব কিছুর জন্য মোটা ভূমিকা থাকা ভালো? এবং যদি ভূমিকা না হয়, তাহলে আমি কোথায় লিখব - পূর্বে বা পোস্টে?

যদি এই প্রশ্নগুলির কোনও যুক্তিযুক্ত উত্তর না থাকে, তবে এটি অন্তর্দৃষ্টির অভাবের লক্ষণ, অর্থাৎ সেই একই "কাঁপানো ভিত্তি"। আসুন এটা বের করা যাক। প্রথম, একটি নিরাপত্তা প্রশ্ন: যদি খেলা আছে pre_tasks и post_tasks (এবং কোন কাজ বা ভূমিকা নেই), তারপর কিছু বিরতি হতে পারে যদি আমি প্রথম কাজটি সম্পাদন করি post_tasks আমি এটা শেষ পর্যন্ত সরানো হবে pre_tasks?

অবশ্যই, প্রশ্নের শব্দগুলি ইঙ্গিত দেয় যে এটি ভেঙে যাবে। কিন্তু ঠিক কি?

... হ্যান্ডলার। মূল বিষয়গুলি পড়া একটি গুরুত্বপূর্ণ সত্য প্রকাশ করে: প্রতিটি বিভাগের পরে সমস্ত হ্যান্ডলার স্বয়ংক্রিয়ভাবে ফ্লাশ করা হয়। সেগুলো. থেকে সমস্ত কাজ pre_tasks, তারপর অবহিত করা হয়েছে যে সমস্ত হ্যান্ডলার. তারপরে সমস্ত ভূমিকা এবং সমস্ত হ্যান্ডলার যে ভূমিকাগুলিতে বিজ্ঞাপিত হয়েছিল তা কার্যকর করা হয়। পরে post_tasks এবং তাদের হ্যান্ডলার।

এইভাবে, যদি আপনি একটি টাস্ক থেকে টেনে আনেন post_tasks в pre_tasks, তারপর সম্ভাব্যভাবে আপনি হ্যান্ডলারটি কার্যকর করার আগে এটি কার্যকর করবেন। উদাহরণস্বরূপ, যদি in pre_tasks ওয়েব সার্ভার ইনস্টল এবং কনফিগার করা হয়েছে, এবং post_tasks এটিতে কিছু পাঠানো হয়, তারপর এই কাজটি বিভাগে স্থানান্তর করুন pre_tasks এই সত্যের দিকে পরিচালিত করবে যে "প্রেরণ" করার সময় সার্ভারটি এখনও চালু হবে না এবং সবকিছু ভেঙে যাবে।

এখন আবার চিন্তা করা যাক, কেন আমাদের প্রয়োজন pre_tasks и post_tasks? উদাহরণস্বরূপ, ভূমিকা পালন করার আগে প্রয়োজনীয় সবকিছু (হ্যান্ডলার সহ) সম্পূর্ণ করার জন্য। ক post_tasks আমাদের ভূমিকা সম্পাদনের ফলাফলের সাথে কাজ করার অনুমতি দেবে (হ্যান্ডলার সহ)।

একজন চতুর উত্তরযোগ্য বিশেষজ্ঞ আমাদের বলবেন এটি কী। meta: flush_handlers, কিন্তু কেন আমাদের flush_handlers দরকার যদি আমরা খেলার অংশগুলি সম্পাদনের আদেশের উপর নির্ভর করতে পারি? তাছাড়া, মেটা: ফ্লাশ_হ্যান্ডলারের ব্যবহার ডুপ্লিকেট হ্যান্ডলারের সাথে আমাদের অপ্রত্যাশিত জিনিস দিতে পারে, ব্যবহার করার সময় আমাদের অদ্ভুত সতর্কতা দেয় when у block ইত্যাদি আপনি যত ভালোভাবে উত্তর দিতে পারবেন, একটি "কঠিন" সমাধানের জন্য আপনি তত বেশি সূক্ষ্ম নাম দিতে পারবেন। এবং একটি সহজ সমাধান - প্রাক/ভুমিকা/পোস্টের মধ্যে একটি প্রাকৃতিক বিভাজন ব্যবহার করে - সূক্ষ্মতা সৃষ্টি করে না।

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

এখন "ভুমিকা বা টাস্ক" প্রশ্নের উত্তরটি ইতিমধ্যে খেলার মধ্যে রয়েছে - যদি সেখানে কাজ থাকে তবে আপনাকে সেগুলিকে কার্যগুলিতে যুক্ত করতে হবে। যদি ভূমিকা থাকে তবে আপনাকে একটি ভূমিকা তৈরি করতে হবে (এমনকি একটি কাজ থেকেও)। আমি আপনাকে মনে করিয়ে দিই যে কাজ এবং ভূমিকা একই সময়ে ব্যবহার করা হয় না।

Ansible এর মূল বিষয়গুলি বোঝা আপাতদৃষ্টিতে স্বাদের প্রশ্নগুলির যুক্তিসঙ্গত উত্তর প্রদান করে।

কাজ এবং ভূমিকা (দ্বিতীয় অংশ)

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

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

এখন, মনোযোগ। এ থেকে ভূমিকায় কী করা যায়? পার্শ্ব প্রতিক্রিয়া কল করার জন্য আপনাকে সর্বদা স্বাগত জানাই, এটি সমগ্র উত্তরের সারমর্ম - পার্শ্ব প্রতিক্রিয়া তৈরি করা। পার্শ্ব কারণ আছে? প্রাথমিক। কিন্তু "একটি মান পাস করুন এবং এটি ফেরত দিন" - সেখানেই এটি কাজ করে না। প্রথমত, আপনি একটি ভূমিকা একটি মান পাস করতে পারবেন না. আপনি ভূমিকার জন্য vars বিভাগে খেলার আজীবন আকার সহ একটি বিশ্বব্যাপী পরিবর্তনশীল সেট করতে পারেন। আপনি ভূমিকার অভ্যন্তরে একটি জীবনকাল সহ একটি বিশ্বব্যাপী পরিবর্তনশীল সেট করতে পারেন। অথবা এমনকি প্লেবুকের জীবনকালের সাথে (set_fact/register) কিন্তু আপনার "স্থানীয় ভেরিয়েবল" থাকতে পারে না। আপনি "একটি মান নিতে" এবং "এটি ফেরত" দিতে পারবেন না।

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

মোট: একটি ভূমিকা একটি ফাংশন নয়.

ভূমিকা সম্পর্কে ভাল কি? প্রথমত, ভূমিকার ডিফল্ট মান আছে (/default/main.yaml), দ্বিতীয়ত, ভূমিকাতে ফাইল সংরক্ষণের জন্য অতিরিক্ত ডিরেক্টরি রয়েছে।

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

ভূমিকা সম্পর্কে আর কি মহান? কারণ তাদের নিজস্ব ক্যাটালগ রয়েছে। এগুলি হল ভেরিয়েবলের জন্য ডিরেক্টরি, উভয় ধ্রুবক (অর্থাৎ ভূমিকার জন্য গণনা করা) এবং গতিশীল (একটি প্যাটার্ন বা একটি অ্যান্টি-প্যাটার্ন আছে - include_vars একসঙ্গে সঙ্গে {{ ansible_distribution }}-{{ ansible_distribution_major_version }}.yml.) এই জন্য ডিরেক্টরি files/, templates/. এছাড়াও, এটি আপনাকে আপনার নিজস্ব মডিউল এবং প্লাগইন থাকতে দেয় (library/) কিন্তু, একটি প্লেবুকের কাজগুলির সাথে তুলনা করে (যাতে এটিও থাকতে পারে), এখানে একমাত্র সুবিধা হল যে ফাইলগুলি এক গাদাতে ডাম্প করা হয় না, তবে বেশ কয়েকটি পৃথক গাদা।

আরও একটি বিশদ: আপনি এমন ভূমিকা তৈরি করার চেষ্টা করতে পারেন যা পুনরায় ব্যবহারের জন্য উপলব্ধ হবে (গ্যালাক্সির মাধ্যমে)। সংগ্রহের আবির্ভাবের সাথে, ভূমিকা বন্টন প্রায় ভুলে যাওয়া বিবেচনা করা যেতে পারে।

সুতরাং, ভূমিকাগুলির দুটি গুরুত্বপূর্ণ বৈশিষ্ট্য রয়েছে: তাদের ডিফল্ট রয়েছে (একটি অনন্য বৈশিষ্ট্য) এবং তারা আপনাকে আপনার কোড গঠন করার অনুমতি দেয়।

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

একটি কাজ হিসাবে import_role করা সম্ভব, কিন্তু আপনি যদি এটি লেখেন, তাহলে আপনি কেন এটি করতে চান তা আপনার নিজের সৌন্দর্যবোধকে ব্যাখ্যা করার জন্য প্রস্তুত থাকুন।

একজন বিচক্ষণ পাঠক বলতে পারেন যে ভূমিকাগুলি ভূমিকা আমদানি করতে পারে, ভূমিকাগুলির galaxy.yml এর মাধ্যমে নির্ভরতা থাকতে পারে এবং একটি ভয়ানক এবং ভয়ানকও রয়েছে include_role — আমি আপনাকে মনে করিয়ে দিচ্ছি যে আমরা বেসিক অ্যানসিবলে দক্ষতা উন্নত করছি, ফিগার জিমন্যাস্টিকসে নয়।

হ্যান্ডলার এবং কাজ

আসুন আরেকটি সুস্পষ্ট বিষয় নিয়ে আলোচনা করা যাক: হ্যান্ডলার। এগুলিকে কীভাবে সঠিকভাবে ব্যবহার করতে হয় তা জানা প্রায় একটি শিল্প। একটি হ্যান্ডলার এবং একটি ড্র্যাগের মধ্যে পার্থক্য কি?

যেহেতু আমরা মৌলিক বিষয়গুলি মনে রাখছি, এখানে একটি উদাহরণ দেওয়া হল:

- hosts: group1
  tasks:
    - foo:
      notify: handler1
  handlers:
     - name: handler1
       bar:

ভূমিকার হ্যান্ডলারগুলি rolename/handlers/main.yaml-এ অবস্থিত। হ্যান্ডলাররা সমস্ত খেলার অংশগ্রহণকারীদের মধ্যে গুঞ্জন করে: pre/post_tasks ভূমিকা হ্যান্ডলারদের টানতে পারে এবং একটি ভূমিকা নাটক থেকে হ্যান্ডলারদের টানতে পারে। যাইহোক, হ্যান্ডলারদের কাছে "ক্রস-রোল" কলগুলি একটি তুচ্ছ হ্যান্ডলারের পুনরাবৃত্তি করার চেয়ে অনেক বেশি wtf সৃষ্টি করে। (সর্বোত্তম অনুশীলনের আরেকটি উপাদান হ্যান্ডলারের নাম পুনরাবৃত্তি না করার চেষ্টা করা)।

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

কনফিগারেশনের সাথে পরিস্থিতি সমাধান করা যাবে না (আরো সঠিকভাবে, আপনি ফাইল ফ্ল্যাগ ইত্যাদি সহ নিজের জন্য একটি বিশেষ পুনঃসূচনা প্রোটোকল উদ্ভাবন করতে পারেন, তবে এটি আর কোনও রূপে 'মৌলিক উত্তরযোগ্য' নয়)। কিন্তু আরেকটি সাধারণ গল্প আছে: আমরা অ্যাপ্লিকেশন ইনস্টল করেছি, এটি রেকর্ড করেছি .service-ফাইল, এবং এখন আমরা এটি চাই daemon_reload и state=started. এবং এর জন্য প্রাকৃতিক জায়গা হ্যান্ডলার বলে মনে হয়। কিন্তু যদি আপনি এটিকে একটি হ্যান্ডলার না করে একটি টাস্কলিস্ট বা ভূমিকার শেষে একটি টাস্ক করেন, তাহলে এটি প্রতিবারই বুদ্ধিমত্তার সাথে কার্যকর করা হবে। মাঝখানে প্লেবুক ভেঙে গেলেও। এটি পুনঃসূচনা সমস্যাটি মোটেও সমাধান করে না (আপনি পুনঃসূচনা বৈশিষ্ট্যের সাথে একটি কাজ করতে পারবেন না, কারণ বুদ্ধিমত্তা হারিয়ে গেছে), তবে এটি অবশ্যই রাষ্ট্র = শুরু করা মূল্যবান, প্লেবুকগুলির সামগ্রিক স্থিতিশীলতা বৃদ্ধি পায়, কারণ সংযোগের সংখ্যা এবং গতিশীল অবস্থা হ্রাস পায়।

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

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

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

ক্ষয়কারী পাঠক ঠিকই উল্লেখ করেছেন যে আমরা আলোচনা করিনি listenযে একজন হ্যান্ডলার অন্য হ্যান্ডলারের জন্য সূচিত করতে পারে, যে একজন হ্যান্ডলার import_tasks অন্তর্ভুক্ত করতে পারে (যেটি with_items-এর সাথে অন্তর্ভুক্ত_রোল করতে পারে), যে Ansible-এ হ্যান্ডলার সিস্টেমটি টুরিং-সম্পূর্ণ, যে অন্তর্ভুক্ত_রোলের হ্যান্ডলাররা খেলা থেকে হ্যান্ডলারদের সাথে একটি অদ্ভুত উপায়ে ছেদ করে, ইত্যাদি .d - এই সব স্পষ্টতই "মৌলিক" নয়)।

যদিও একটি নির্দিষ্ট WTF আছে যা আসলে একটি বৈশিষ্ট্য যা আপনাকে মনে রাখতে হবে। আপনার টাস্ক সঙ্গে মৃত্যুদন্ড কার্যকর করা হয় delegate_to এবং এটি অবহিত করেছে, তারপর সংশ্লিষ্ট হ্যান্ডলার ছাড়াই কার্যকর করা হয় delegate_to, অর্থাৎ হোস্টে যেখানে খেলা নির্ধারিত হয়। (যদিও হ্যান্ডলারের অবশ্যই থাকতে পারে delegate_to একই)।

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

কম ifs (স্পষ্ট বা ঘোষণামূলক - আকারে when বা ফর্ম include_vars ভেরিয়েবলের সেট দ্বারা), ভূমিকা তত ভাল। কখনও কখনও আপনাকে শাখা তৈরি করতে হবে, কিন্তু, আমি আবার বলছি, যত কম আছে, তত ভাল। তাই এটি গ্যালাক্সি (এটি কাজ করে!) একটি গুচ্ছ সঙ্গে একটি ভাল ভূমিকা মত মনে হয় when পাঁচটি কাজ থেকে "নিজের" ভূমিকার চেয়ে কম পছন্দনীয় হতে পারে। যখন আপনি কিছু লিখতে শুরু করেন তখন গ্যালাক্সির সাথে ভূমিকাটি আরও ভাল হয়। যে মুহূর্তটি খারাপ হয়ে যায় তা হল যখন কিছু ভেঙ্গে যায় এবং আপনার সন্দেহ হয় যে এটি "গ্যালাক্সির সাথে ভূমিকা" এর কারণে। আপনি এটি খুলুন, এবং পাঁচটি অন্তর্ভুক্তি, আটটি টাস্ক শীট এবং একটি স্ট্যাক রয়েছে when'ওহ... এবং আমাদের এটা বের করতে হবে। 5টি কাজের পরিবর্তে, একটি রৈখিক তালিকা যাতে ভাঙার কিছু নেই।

নিম্নলিখিত অংশে

• ইনভেন্টরি, গ্রুপ ভেরিয়েবল, হোস্ট_গ্রুপ_ভারস প্লাগইন, হোস্টভারস সম্পর্কে একটু। স্প্যাগেটি দিয়ে কীভাবে গর্ডিয়ান গিঁট বাঁধবেন। স্কোপ এবং অগ্রাধিকার ভেরিয়েবল, উত্তরযোগ্য মেমরি মডেল। "তাহলে আমরা ডাটাবেসের জন্য ব্যবহারকারীর নাম কোথায় সংরক্ষণ করব?"
• jinja: {{ jinja }} — nosql notype nosense নরম প্লাস্টিকিন। এটি সর্বত্র রয়েছে, এমনকি যেখানে আপনি এটি আশা করেন না। সম্পর্কে একটু !!unsafe এবং সুস্বাদু ইয়ামল।

উত্স: www.habr.com