ইনসাইড প্লেবুক। নতুন Ansible ইঞ্জিন 2.9-এ নেটওয়ার্ক ফাংশন

Red Hat Ansible Engine 2.9-এর আসন্ন রিলিজ উত্তেজনাপূর্ণ উন্নতি নিয়ে আসে, যার কয়েকটি এই নিবন্ধে আলোচনা করা হয়েছে। বরাবরের মতো, আমরা সম্প্রদায়ের সহায়তায় প্রকাশ্যে উত্তরযোগ্য নেটওয়ার্কের উন্নতি ঘটাচ্ছি। আমাদের সাথে যোগ দিন - একবার দেখুন GitHub এ ইস্যু বোর্ড এবং জন্য উন্নয়ন পরিকল্পনা অধ্যয়ন Red Hat Ansible Engine 2.9-এর রিলিজ জন্য উইকি পাতায় উত্তরযোগ্য নেটওয়ার্ক.

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

• আরিস্তা ইওএস
• সিসকো আইওএস
• সিসকো আইওএস এক্সআর
• সিসকো এনএক্স-ওএস
• জুনিপার জুনোস
• VyOS

Ansible Automation সাবস্ক্রিপশনের মাধ্যমে Red Hat দ্বারা সম্পূর্ণরূপে সমর্থিত প্ল্যাটফর্মগুলির একটি সম্পূর্ণ তালিকার জন্য, এখানে প্রকাশিত.

আমরা কি শিখেছি

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

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

এক বছর আগে যখন আমরা আমাদের দীর্ঘমেয়াদী বৃদ্ধির পরিকল্পনা নিয়ে আলোচনা করেছি, তখন আমাদের কর্পোরেট ক্লায়েন্টরা নিম্নলিখিতগুলি চেয়েছিল:

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

তথ্যের উন্নতি

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

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

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

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

Ansible 2.9-এর প্রতিটি নেটওয়ার্ক ফ্যাক্ট মডিউল এখন একটি নেটওয়ার্ক ডিভাইসের কনফিগারেশন বিশ্লেষণ করতে পারে এবং স্ট্রাকচার্ড ডেটা ফেরত দিতে পারে - অতিরিক্ত লাইব্রেরি, উত্তরযোগ্য ভূমিকা বা কাস্টম পার্সার ছাড়াই।

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

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

তথ্য সংগ্রহ করার সময়:

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

- hosts: arista
  module_defaults:
    eos_facts:
      gather_subset: min
      gather_network_resources:
      - interfaces
  gather_facts: True

আপনি এই উদাহরণগুলিতে নতুন কিছু লক্ষ্য করেছেন, যথা - gather_facts: true নেটওয়ার্ক ডিভাইসের জন্য নেটিভ ফ্যাক্ট সংগ্রহের জন্য এখন উপলব্ধ।

সরাসরি নেটওয়ার্ক ফ্যাক্ট মডিউল ব্যবহার করে:

- name: collect interface configuration facts
  eos_facts:
    gather_subset: min
    gather_network_resources:
    - interfaces

প্লেবুক ইন্টারফেস সম্পর্কে নিম্নলিখিত তথ্য প্রদান করে:

ansible_facts:
   ansible_network_resources:
      interfaces:
      - enabled: true
        name: Ethernet1
        mtu: '1476'
      - enabled: true
        name: Loopback0
      - enabled: true
        name: Loopback1
      - enabled: true
        mtu: '1476'
        name: Tunnel0
      - enabled: true
        name: Ethernet1
      - enabled: true
        name: Tunnel1
      - enabled: true
        name: Ethernet1

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

ইন্টারফেস ফ্যাক্টগুলি উত্তরযোগ্য সঞ্চিত ভেরিয়েবলগুলিতে যোগ করা যেতে পারে এবং একটি রিসোর্স মডিউলে ইনপুট হিসাবে অবিলম্বে বা পরে ব্যবহার করা যেতে পারে eos_interfaces অতিরিক্ত প্রক্রিয়াকরণ বা রূপান্তর ছাড়া।

রিসোর্স মডিউল

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

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

একটি রিসোর্স মডিউল কী করে তা ব্যাখ্যা করার জন্য, আসুন একটি উদাহরণ প্লেবুক দেখি যা নতুন নেটওয়ার্ক রিসোর্স ফ্যাক্টস এবং মডিউল ব্যবহার করে একটি আইডমপোডেন্ট অপারেশন দেখায় eos_l3_interface.

- name: example of facts being pushed right back to device.
  hosts: arista
  gather_facts: false
  tasks:
  - name: grab arista eos facts
    eos_facts:
      gather_subset: min
      gather_network_resources: l3_interfaces

  - name: ensure that the IP address information is accurate
    eos_l3_interfaces:
      config: "{{ ansible_network_resources['l3_interfaces'] }}"
      register: result

  - name: ensure config did not change
    assert:
      that: not result.changed

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

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

নতুন রিসোর্স মডিউলগুলি আগেরগুলির থেকে কীভাবে আলাদা?

একজন নেটওয়ার্ক অটোমেশন ইঞ্জিনিয়ারের জন্য, Ansible 3 এবং পূর্ববর্তী সংস্করণের রিসোর্স মডিউলের মধ্যে 2.9টি প্রধান পার্থক্য রয়েছে।

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

2) সম্পদ মডিউল এখন একটি রাষ্ট্র মান অন্তর্ভুক্ত.

• merged: কনফিগারেশন প্রদত্ত কনফিগারেশনের সাথে একত্রিত হয় (ডিফল্ট);
• replaced: রিসোর্স কনফিগারেশন প্রদত্ত কনফিগারেশন দিয়ে প্রতিস্থাপিত হবে;
• overridden: রিসোর্স কনফিগারেশন প্রদত্ত কনফিগারেশন দিয়ে প্রতিস্থাপিত হবে; অপ্রয়োজনীয় সম্পদ উদাহরণ মুছে ফেলা হবে;
• deleted: রিসোর্স কনফিগারেশন ডিফল্টে মুছে/পুনরুদ্ধার করা হবে।

3) রিসোর্স মডিউল এখন স্থিতিশীল রিটার্ন মান অন্তর্ভুক্ত করে। যখন নেটওয়ার্ক রিসোর্স মডিউল নেটওয়ার্ক ডিভাইসে প্রয়োজনীয় পরিবর্তনগুলি করেছে (বা প্রস্তাব করেছে), এটি প্লেবুকে একই কী-মানের জোড়া ফিরিয়ে দেয়।

• before: টাস্কের আগে স্ট্রাকচার্ড ডেটা আকারে ডিভাইসে কনফিগারেশন;
• after: যদি ডিভাইসটি পরিবর্তিত হয় (অথবা পরীক্ষা মোড ব্যবহার করা হলে পরিবর্তিত হতে পারে), ফলে কনফিগারেশনটি কাঠামোগত ডেটা হিসাবে ফিরে আসবে;
• commands: যেকোনো কনফিগারেশন কমান্ড ডিভাইসটিকে পছন্দসই অবস্থায় আনতে চালিত হয়।

এই সবকিছুর অর্থ কী? এটা কেন গুরুত্বপূর্ণ?

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

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

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

Ansible Engine 2.9 এ কোন রিসোর্স মডিউল আসবে?

Ansible 2.9-এ কী ঘটবে তা বিস্তারিতভাবে বলার আগে, আসুন আমরা কীভাবে কাজের পুরো সুযোগকে ভাগ করেছি তা মনে রাখা যাক।

আমরা 7টি বিভাগ শনাক্ত করেছি এবং প্রতিটিতে নির্দিষ্ট নেটওয়ার্ক সংস্থান বরাদ্দ করেছি:

দ্রষ্টব্য: বোল্ডে সম্পদগুলি উত্তরযোগ্য 2.9-এ পরিকল্পিত এবং বাস্তবায়িত হয়েছিল।
এন্টারপ্রাইজ গ্রাহকদের এবং সম্প্রদায়ের প্রতিক্রিয়ার উপর ভিত্তি করে, প্রথমে নেটওয়ার্ক টপোলজি প্রোটোকল, ভার্চুয়ালাইজেশন এবং ইন্টারফেসের সাথে সম্পর্কিত সেই মডিউলগুলি মোকাবেলা করা যৌক্তিক ছিল।
নিম্নলিখিত রিসোর্স মডিউলগুলি Ansible Network টিম দ্বারা তৈরি করা হয়েছে এবং Red Hat দ্বারা সমর্থিত প্ল্যাটফর্মগুলির সাথে সামঞ্জস্যপূর্ণ:

নিম্নলিখিত মডিউলগুলি উত্তরযোগ্য সম্প্রদায় দ্বারা তৈরি করা হয়েছে:

• exos_lldp_global - এক্সট্রিম নেটওয়ার্ক থেকে।
• nxos_bfd_interfaces - সিসকো থেকে
• nxos_telemetry - সিসকো থেকে

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

উত্তরযোগ্য 2.10 এবং তার পরেও পরিকল্পনা

Ansible 2.9 প্রকাশিত হলে, আমরা Ansible 2.10-এর জন্য পরবর্তী রিসোর্স মডিউলের সেটে কাজ করব, যা নেটওয়ার্ক টপোলজি এবং নীতিকে আরও কনফিগার করতে ব্যবহার করা যেতে পারে, যেমন ACL, OSPF এবং BGP. উন্নয়ন পরিকল্পনা এখনও সামঞ্জস্য করা যেতে পারে, তাই যদি আপনার মন্তব্য থাকে, দয়া করে এটি রিপোর্ট করুন উত্তরযোগ্য নেটওয়ার্ক সম্প্রদায়.

সম্পদ এবং শুরু করা

Ansible Automation Platform সম্পর্কে প্রেস রিলিজ
উত্তরযোগ্য অটোমেশন প্ল্যাটফর্ম ব্লগ
উত্তরে কন্টেন্ট ডেলিভারির ভবিষ্যত
উত্তরযোগ্য প্রকল্প কাঠামো পরিবর্তনের প্রতিফলন

উত্স: www.habr.com